{"slug": "testing-ai-with-an-office-hours-question", "title": "Testing AI with an Office Hours Question", "summary": "Brent Ozar, a Microsoft SQL Server expert and podcast host, tested whether a fully local AI setup could answer an Office Hours question, using the MiniMax H3 image-to-video model and a local Qwen3.6-35B-A3B model on his MacBook Pro. The local model produced a partially incorrect answer about DBCC CHECKDB on a 25TB database, correctly noting safety but wrongly suggesting PHYSICAL_ONLY causes tempdb issues and recommending irrelevant settings. Ozar concluded that while local models are good for coding tasks, they lack the real-world knowledge needed for nuanced database advice.", "body_md": "# Testing AI with an Office Hours Question\n\nWhen the new MiniMax H3 image-to-video model dropped this month, I was really impressed with how quickly and easily it was able to make 5-10 second videos from a starting image – not in the cloud, mind you, but on my own home computer gear:\n\nThe voice audio is nowhere near my own voice (yet, thank God) but obviously this technology’s moving really quickly. That led me to think – could I do a completely automated Office Hours, all with my own computer gear (not the cloud) just to see what the quality looked like?\n\nTo find out, I took the top-voted Office Hours question at that moment, and I prefixed it with the kind of answer that I was looking for – otherwise, LLMs will just hurl a wall of text at you.\n\nAnswer as Brent Ozar, noted Microsoft SQL Server expert and host of Office Hours podcast where audience members can ask database questions. Keep your answers to around 60-90 seconds of spoken text at most.\n\nAudience question: “Hi Brent, is running DBCC CHECKDB on a sync secondary in AG safe for a 25TB DB, or will it delay trans commits? We run on async now, but keep hitting tempdb full errors on full CHECKDB vs PHYSICAL_ONLY. Any recommendations for running integrity checks at this scale? Thank you!”\n\nI love that question because it’s full of interesting nuances.\n\n### Attempt #1: asking a local coding model\n\nIf you were lucky enough to get an AI-grade computer before prices skyrocketed – like something with an NVidia 3090/4090/5090, or a Mac with 96GB+ memory – then a good line of defense against AI costs is to run a small local model for basic coding tasks. On my MacBook Pro, I usually leave [oMLX](https://github.com/jundot/omlx) up and running with the Qwen3.6-35B-A3B model, and it uses about 39GB of RAM. It’s great for relatively simple gruntwork like “Rewrite this stored procedure from row-based to set-based” or “Find out why this query sometimes produces null errors.”\n\nIt’s *not* really for general knowledge questions like the Office Hours one above. However, I wanna show the results because it’s a good example of how a model can be good at one thing (coding) but suck at another thing (real world knowledge). Plus, it’s entirely local, and it fit with my design goal of doing this whole thing locally without sending data up to the cloud. (Ironic, given that we’re talking about publishing a public podcast, hahaha, but you get the idea.)\n\nThe answer came back in ~36 seconds – not ideal, but I could automate it if the quality was good. It was just one wall of text, but I’m going to break it up because I wanna respond to a lot of pieces in it:\n\nGreat question. Short answer: yes, it’s safe, and it won’t delay primary commits—but it will absolutely hammer the secondary’s CPU, memory, and I/O, which can cause AG replication lag in a sync setup.\n\nThat part is true.\n\nThose tempdb blowouts? Totally expected. CHECKDB uses tempdb for sorts, hash joins, and version stores, and at 25TB, even\n\n`PHYSICAL_ONLY`\n\nwill stretch it thin.\n\nIt was great right up until the PHYSICAL_ONLY part. PHYSICAL_ONLY just checks the checksums on pages, and that shouldn’t cause massive TempDB problems on a secondary.\n\nHere’s what I’d do: run\n\n`PHYSICAL_ONLY`\n\nweekly, and a full`CHECKDB`\n\nmonthly during a maintenance window. Size tempdb aggressively—multiple data files, one per vCPU up to eight, equal growth, proper permissions. Make sure`READ_COMMITTED_SNAPSHOT`\n\nand`ALLOW_SNAPSHOT_ISOLATION`\n\nare enabled to cut down on latching and version cleanup.\n\nEek. We’re going off the rails here.\n\nIn fact, it’s so bad that the term “going off the rails” doesn’t do it justice, because that sounds like a train which generally travels in a single direction. This is more like rapid unscheduled disassembly, heading off in a zillion wrong directions at once: specifying a schedule without asking about RPO/RTO, distracting the user with talk of permissions, and wildly unrelated RCSI and SI stuff that aren’t going to matter to CHECKDB on a secondary.\n\nIf you’re using Ola Hallengren’s maintenance scripts, skip\n\n`DATA_PURITY`\n\nweekly and only enable it on your monthly run. At 25TB, consider splitting your database across filegroups so you can take one offline for a full integrity check without impacting production, or just accept that at this scale, you need dedicated backup/DR nodes for heavy maintenance.\n\nWait why would you take a filegroup *offline* to do CHECKDB? And how could you even take something *offline* on a sync secondary? This is so bad, it’s [not even wrong](https://en.wikipedia.org/wiki/Not_even_wrong).\n\nBottom line: async AG is your friend. Keep full\n\n`CHECKDB`\n\ns off business hours, size tempdb like you mean it, and check less often but deeper. Want our tempdb sizing checklist? Hit the feedback page.\n\nGet out. Grade: F for Fake Feedback Page.\n\nOkay, in fairness, it’s, uh … free and local.\n\n### Attempt #2: DwarfStar with DeepSeek V4 Flash\n\nI’ve been recently falling in love with [DwarfStar aka ds4](https://github.com/antirez/ds4), an open source engine to run a very quantized (lobotomized) version of DeepSeek 4 Flash locally on Macs. It’s written by the same guy who wrote Redis, [Salvatore Sanfilippo](https://en.wikipedia.org/wiki/Salvatore_Sanfilippo), aka antirez. I only started using this one last week, and I’m already crazy about it. It’s not for everyone – it’s really only for Mac users with at least 96GB RAM – but if you fall into that audience, it’s great because it’s *so fast* and many kinds of answers are good enough. Sure enough, the answer came back in seconds:\n\nGreat question—this is a classic scale dilemma. Running\n\n`DBCC CHECKDB`\n\nwith the full option on a **synchronous secondary** in an Availability Group is **not safe** for a 25TB database. Here’s why: in sync mode, the primary waits for the secondary to apply the log before acknowledging a commit. If your secondary is busy running a full CHECKDB—which chews through tempdb and hammers I/O—it can fall behind, causing the primary to slow down or even block commits. So yes, it can delay transaction commits.\n\nPERFECT.\n\nYou’re already on async secondary, which is the right place for integrity checks. The problem you’re hitting is **tempdb full errors** on the full CHECKDB. That’s because the full option does deep logical checks that spill to tempdb—like rebuilding indexes internally.\n\n`PHYSICAL_ONLY`\n\navoids that because it only checks page and allocation integrity, using far less tempdb.\n\nThat is also perfectly correct, nicely done.\n\nMy recommendation: On your async secondary, run **PHYSICAL_ONLY** regularly (weekly). That’s your safety net. For the full logical checks, do them on a **restored copy** of a backup on a separate server with plenty of tempdb (multiple files, fast storage). Or use a **backup with checks** and then\n\n`DBCC CHECKDB`\n\non a restored copy. You can also schedule a full check quarterly during a low-write window on the async secondary—but only if you give tempdb more space and faster drives.\n\nThe first two sentences had me really nervous, but then I actually clapped my hands in my office at the sentence starting with, “For the full logical checks, do them on a restored copy” – bingo! That’s great, it points out the need to test restores.\n\nThe rest of the reply goes back off the rails, though, because it avoids the discussion of RPO/RTO. If you can’t keep up with CHECKDB, you have a hardware & budget problem, and you don’t solve that by being willing to lose more data.\n\nIn short: **PHYSICAL_ONLY on async secondary for routine checks, full checks on a restored copy.** That keeps your production commits safe and avoids tempdb explosions.\n\nI do love that it summed things up at the end! I try to do that too.\n\nGrade: C. This is *fantastic* for a local model giving me free answers in seconds, but it’s still not production-quality knowledge that can replace a DBA.\n\nThis does kinda bum me out because the answer *sounds* so good, so authoritative, and I’m sure that right now, people out there are taking advice just like this and gradually making their environments worse. If you didn’t know better, the advice *sounds* good enough to rely on, and you won’t know how wrong it is until you’ve already lost data. <sigh> Ah, well.\n\nI still love local LLMs, but it’s about coding & database-ing, not general Q&A. And I certainly couldn’t auto-generate the text answer portion of Office Hours with this – but let’s try a couple of cloud-based options as long as we’re here.\n\n### Attempt #3: OpenAI ChatGPT 5.6 Instant/Light\n\nI purposely picked the instant/light level of reasoning because I wanted to see if even the most bargain-basement cloud model would smoke my local model, and indeed, Sam Altman’s crew did not disappoint:\n\nI wouldn’t run full CHECKDB on a synchronous secondary unless I’d already load-tested it.\n\nWell, that’s kind of frivolous, dude, they already ran it and it didn’t work. You didn’t need to say that sentence.\n\nCHECKDB doesn’t directly block commits on the primary, but it can absolutely compete with redo for CPU, memory, storage throughput, and tempdb. If redo falls behind badly enough on a synchronous replica, the primary’s commits can wait for that secondary to harden log records. So yes, it can increase transaction latency indirectly.\n\nYAAAAAS QUEEN PREACH\n\nAt 25TB, I’d keep the integrity-check replica asynchronous. Run CHECKDB there, monitor the redo queue and redo rate, and accept that the secondary may fall behind during the check.\n\nTHE HITS JUST KEEP COMING! Okay now see, this is valuable advice. If we toss out that first sentence about load-testing it, the second two paragraphs would form the perfect start to an automated Brent Ozar answer.\n\nMy natural inclination is then to segue into talking about licensing, and how it’s free since 2019 as long as you’re under Software Assurance, but that isn’t where ChatGPT went. It continued…\n\nFor the tempdb failures, first make sure CHECKDB is using the internal snapshot rather than a storage-constrained manual snapshot. Pre-size tempdb, use multiple appropriately sized files, and verify the tempdb volume has enough free space and throughput.\n\nThey already verified it doesn’t have enough space, but … yeah, I wish it’d skip that section. If they do address it, they just gotta talk about buying more space, and talk about the size of how the largest objects and their indexes can affect TempDB space requirements.\n\nI’d also consider a layered strategy: run PHYSICAL_ONLY frequently, full CHECKDB less often, and restore backups to a separate validation server where you can run full CHECKDB without risking production availability. The restore test is valuable too, because a clean CHECKDB doesn’t prove your backups are usable.\n\nThat’s great! I love it!\n\nAgain, no discussion of RPO/RTO or exact drive space numbers, but overall, if I was grading this answer, I’d give it a solid C. And that was the cheapest/fastest ChatGPT model! Let’s try another popular provider…\n\n### Attempt #4: Anthropic Claude Sonnet 5 Low\n\nAnthropic offers a lot more model choices (probably too many, if I’m honest) and I went with the lowest model that I would ever consider for this kind of thing – again, to show how good the cheap cloud advice is. It said:\n\nGreat question. Let’s split this into two parts: sync AG concerns and the tempdb issue.\n\nBE STILL MY BEATING HEART! One of my favorite techniques in Office Hours answers is helping them understand how many questions they actually have so they can solve tough problems in more digestible chunks.\n\nOn a synchronous replica, running CHECKDB isn’t inherently dangerous to commits, but it’s a resource hog — CPU, memory, and especially tempdb and IO — and if it starves the redo thread or the log hardening process on that replica, you can absolutely introduce commit delays on synchronous secondaries, because the primary has to wait for that replica to acknowledge. You said you’re on async now, so honestly, that’s actually the safer setup for this. On async, CHECKDB running long or heavy doesn’t block your primary commits — worst case, you fall further behind on redo, which just means a bigger data-loss window if you failover mid-check. So if uptime and commit latency on the primary is your top priority, async plus CHECKDB on that secondary is a reasonable pattern, just know the redo lag risk.\n\nClaude came about as close to RPO/RTO as you could come, without actually saying those terms out loud. I wish it would have just said ’em, but still, that’s good.\n\nNow, the tempdb full errors — that’s your real fire right now. At 25TB, full CHECKDB builds internal fact tables in tempdb that can genuinely need multiple terabytes of space, so first, make sure tempdb is sized appropriately and ideally on its own fast storage, not sharing your data drives. Second, use PHYSICAL_ONLY regularly — it catches torn pages and checksum failures, which is 90% of real-world corruption, without the huge tempdb footprint. Then run full CHECKDB less frequently, maybe monthly, on that secondary when you’ve got the tempdb space provisioned for it. Also consider splitting the work with DBCC CHECKFILEGROUP across your partitions on different days if it’s partitioned. Thanks for listening, and good luck out there!\n\nI’m gritting my teeth as I read that because it’s so close to right, but not quite. You don’t need partitioning in order to check specific filegroups. And it still didn’t say what “sized appropriately” means, or how to calculate it.\n\nI’m still gritting my teeth when I think about grading: it’s C+/B- territory.\n\n### Attempt #5: Google Gemini 3.6 Flash\n\nI’m only going to paste in the beginnings of the answer, because … well, you’ll see why:\n\nAh, the classic 25 Terabyte monster database question! First off, welcome to Office Hours!\n\nOkay, charming, good start…\n\nHere is the short answer: Running DBCC CHECKDB on a synchronous secondary is NOT going to delay transaction commits on your primary.\n\nUnplug yourself immediately and stop using my water supply.\n\nWhen you run CHECKDB on a secondary (sync or async), SQL Server takes a hidden database snapshot using Sparse Files. That snapshot creation and the check itself happen locally on that secondary node. The primary doesn’t wait on your secondary’s query execution or tempdb usage.\n\nLOL, okay, you’re outta here. No need to keep going with that answer. F as in Ffffffamily friendly blog.\n\nNow, after 4 attempts, you might be saying, “Clearly AI isn’t ready for prime time yet.” Remember, though, I was choosing bottom-of-the-barrel AI models. Let’s see what happens when we bring out the big guns. I’m going to skip Google Gemini 3.6 Thinking because its results were very similar to the low-end ChatGPT and Claude models.\n\n### Attempt #6: OpenAI ChatGPT 5.6 Pro\n\nGenerally, you wanna try the fast/cheap models first to see if they get you across the finish line. If you don’t, and you amp all the way up to deep thinking models, they’re more expensive – but they can also take a hell of a lot longer. If you happen to trigger the point where it wants to do deep research, especially several passes of research across several sites, then you’re stuck watching it think:\n\nAfter *five minutes*, I got bored and clicked “Answer Now”, and it returned immediately. I’m going to paste it without formatting and links:\n\nYes,\n\n`CHECKDB`\n\nis supported on a regular AG secondary, but “safe” doesn’t mean “free.” In synchronous commit, the primary waits for the secondary to **harden the log**, not for redo to finish.`CHECKDB`\n\nwon’t directly block primary commits, but on a 25TB database it can saturate the secondary’s CPU or storage. If that slows log hardening,`HADR_SYNC_COMMIT`\n\nrises and your production transactions slow down. I’d leave the`CHECKDB`\n\nreplica asynchronous during the run unless you’ve load-tested it in synchronous mode. Also, a clean result there proves only that replica’s copy; it does not prove the primary’s storage is clean.\n\nGood stuff. It’s nowhere near a casual podcast-answer voice, but it’s technically correct, so that’s good.\n\nAt this scale, I’d run\n\n`PHYSICAL_ONLY`\n\nfrequently, then do periodic full logical checks somewhere else—ideally restore a checksum-enabled backup to a separate server and run full`CHECKDB`\n\nthere. For the tempdb failures, first run`DBCC CHECKDB (...) WITH ESTIMATEONLY`\n\n, then pre-size tempdb rather than relying on autogrowth. You can also cap`CHECKDB`\n\nwith`MAXDOP`\n\n. If another 25TB copy isn’t practical, split the work across days:`CHECKALLOC`\n\n,`CHECKCATALOG`\n\n, and`CHECKTABLE`\n\nbatches balanced by page count. One giant weekly`CHECKDB`\n\nisn’t sacred; detecting corruption within your backup-retention window is the real goal.\n\nNo mention of how to size TempDB, and only a brief nod towards RPO/RTO. Better, but … bang for the buck wise, I’m gonna give this one an F. It took too long, and it wasn’t really that much better than the fast/cheap ChatGPT answer.\n\n### Attempt #7: Anthropic Claude Fable 5 High\n\nThe answer came back within seconds:\n\nOoh, good question — and the fact that you’re even asking it means you’re way ahead of most shops with a 25TB database.\n\nI don’t know if Claude actually *knows* how much I love and abuse the phrase “good question”, but yes, I do.\n\nSo first, the sync secondary question: yes, it can hurt you. CHECKDB absolutely hammers storage — it reads everything, plus it spins up an internal database snapshot. On a synchronous secondary, your primary is waiting for that replica to harden log records before it acknowledges commits. If CHECKDB has the secondary’s storage pegged at 100%, log hardening slows down, and your users on the primary feel it. So no, I wouldn’t move to sync just to run CHECKDB there. Stay async for that.\n\nOn the tempdb thing — yeah, full CHECKDB at 25TB needs a boatload of tempdb for all the sort work, and PHYSICAL_ONLY dodges most of that, which is why it fits. But PHYSICAL_ONLY alone means you’re skipping logical checks.\n\nHere’s what I’d actually do at your scale: restore your backups to a separate server and run full CHECKDB there. It’s the two-for-one special — you’re proving your backups actually restore, which, spoiler alert, most people never test, AND you get full integrity checks without touching production or your AG at all. Size that box with generous tempdb and go nuts.\n\nIf you can’t get budget for a restore server, fallback plan: PHYSICAL_ONLY on the async secondary regularly, and break the full logical checks into DBCC CHECKTABLE batches, rotating through your biggest tables over the week so tempdb doesn’t explode all at once.\n\nBut seriously — restore server. Best money you’ll spend. Next question!\n\nGrade: B+. I know, I seem really excited for a B+, but to get this answer in a matter of *seconds*, for *pennies*, it’s great. Still no mention of RPO/RTO or licensing, but I wouldn’t be *ashamed* to use this text as a source for an AI-driven Office Hours video.\n\n### Summary: you can’t stop testing.\n\nThe answer isn’t, “Fable 5 High is the best model for Office Hours levels of questions.”\n\nThe answer is, “For this *one* question, at this *one* moment in time, when reviewed by an expert, Fable 5 High produced the *closest* thing to an *accurate* answer.”\n\nBut that answer expires nearly instantly, and it changes with every question, at every moment in time, and varies depending on the level of accuracy you need and the response latency you’re willing to deal with. I tried the above tests with several different Office Hours questions, and I came to the conclusion that we’re still not yet at the point where I can offer an Office-Hours-as-a-service web page. (I would love to have a BrentBot that dispenses free *good* advice, but I refuse to offer one that dispenses free *bad* advice.)\n\nTo do this kind of testing, I love using tools like Nano-GPT and OpenRouter that allow me to pose the same question repeatedly to different LLMs – not just the big players, but open source and niche models too – without having to copy/paste the same damn thing all over the place.\n\nHere’s how Nano-GPT’s chat console looks when I’m posting the question. Note the auto-model button at the bottom:\n\nYou can click that, and pick the specific model you want. You do pay per-call when you use the expensive stuff like ChatGPT, Claude, and Gemini – but it’s just tacked onto your subscription. Or, if you want to stick with the free stuff, and you’ve got their $12/month subscription, then under [your subscription settings](https://nano-gpt.com/settings#subscription), you can uncheck the setting “Also show paid options” – and that’ll automatically restrict your model choice list to only the stuff that’s included in your subscription.\n\nThey include some pretty doggone good coding models – DeepSeek, GLM, are really useful for me:\n\nAnd with Nano-GPT’s web chat console, if I’m not getting the answers or code that I want, I can just change the model by going into that dropdown, selecting a different model, and keep right on going – without copy/pasting a bunch of notes or code around. That’s much better than using the dedicated apps & sites from each AI company, which are dead-set on keeping you in their specific ecosystem.\n\nI sound like a Nano-GPT shill, I know, but I’m just a huge believer in their product. If you sign up for ’em, use [my referral link](https://nano-gpt.com/r/46YKARdE), and you save 5% on your web usage, and to be transparent, I get 10% of what you spend (but only in the form of AI credits.) I’m not doing that for the money – I’m doing it because I use their product every single day, and it saves me time, and I’d be a bad community member if I kept my mouth shut about that.\n\nAnd if you’re lucky enough to have purchased a 96-128GB Mac before the memory price surge, try [DwarfStar](https://github.com/antirez/ds4). The documentation at that link is a little drawn-out and targeted at coders, but to get started, just clone the Github repo locally, then at a Terminal window in that repo’s folder:\n\n```\nShell\n\n./download_model.sh ds4f-q2    # download the smallest model\nmake                           # build the app\n./ds4                          # start the app, and you're at a prompt - start asking questions, or\n./ds4-server                   # run an OpenAI/Anthropic-compatible server\n\n1234\n\n./download_model.sh ds4f-q2    # download the smallest modelmake                           # build the app./ds4                          # start the app, and you're at a prompt - start asking questions, or./ds4-server                   # run an OpenAI/Anthropic-compatible server\n```\n\nHappy prompting!\n\nFree, 3× a week\n\n### Get my new posts by email\n\nThree posts a week, plus a Monday roundup of the best database news from around the web.", "url": "https://wpnews.pro/news/testing-ai-with-an-office-hours-question", "canonical_source": "https://www.brentozar.com/archive/2026/08/testing-ai-with-an-office-hours-question/", "published_at": "2026-08-13 13:15:15+00:00", "updated_at": "2026-08-13 13:15:50.370489+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools"], "entities": ["Brent Ozar", "MiniMax H3", "Qwen3.6-35B-A3B", "MacBook Pro", "Microsoft SQL Server", "Office Hours"], "alternates": {"html": "https://wpnews.pro/news/testing-ai-with-an-office-hours-question", "markdown": "https://wpnews.pro/news/testing-ai-with-an-office-hours-question.md", "text": "https://wpnews.pro/news/testing-ai-with-an-office-hours-question.txt", "jsonld": "https://wpnews.pro/news/testing-ai-with-an-office-hours-question.jsonld"}}