Testing AI with an Office Hours Question

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.

Testing AI with an Office Hours Question When 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: The 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? To 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. Answer 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. Audience 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 ” I love that question because it’s full of interesting nuances. Attempt 1: asking a local coding model If 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.” It’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. The 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: Great 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. That part is true. Those tempdb blowouts? Totally expected. CHECKDB uses tempdb for sorts, hash joins, and version stores, and at 25TB, even PHYSICAL ONLY will stretch it thin. It 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. Here’s what I’d do: run PHYSICAL ONLY weekly, and a full CHECKDB monthly 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 and ALLOW SNAPSHOT ISOLATION are enabled to cut down on latching and version cleanup. Eek. We’re going off the rails here. In 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. If you’re using Ola Hallengren’s maintenance scripts, skip DATA PURITY weekly 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. Wait 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 . Bottom line: async AG is your friend. Keep full CHECKDB s off business hours, size tempdb like you mean it, and check less often but deeper. Want our tempdb sizing checklist? Hit the feedback page. Get out. Grade: F for Fake Feedback Page. Okay, in fairness, it’s, uh … free and local. Attempt 2: DwarfStar with DeepSeek V4 Flash I’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: Great question—this is a classic scale dilemma. Running DBCC CHECKDB with 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. PERFECT. You’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. PHYSICAL ONLY avoids that because it only checks page and allocation integrity, using far less tempdb. That is also perfectly correct, nicely done. My 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 DBCC CHECKDB on 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. The 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. The 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. In 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. I do love that it summed things up at the end I try to do that too. Grade: 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. This 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. I 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. Attempt 3: OpenAI ChatGPT 5.6 Instant/Light I 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: I wouldn’t run full CHECKDB on a synchronous secondary unless I’d already load-tested it. Well, that’s kind of frivolous, dude, they already ran it and it didn’t work. You didn’t need to say that sentence. CHECKDB 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. YAAAAAS QUEEN PREACH At 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. THE 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. My 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… For 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. They 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. I’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. That’s great I love it Again, 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… Attempt 4: Anthropic Claude Sonnet 5 Low Anthropic 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: Great question. Let’s split this into two parts: sync AG concerns and the tempdb issue. BE 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. On 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. Claude 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. Now, 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 I’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. I’m still gritting my teeth when I think about grading: it’s C+/B- territory. Attempt 5: Google Gemini 3.6 Flash I’m only going to paste in the beginnings of the answer, because … well, you’ll see why: Ah, the classic 25 Terabyte monster database question First off, welcome to Office Hours Okay, charming, good start… Here is the short answer: Running DBCC CHECKDB on a synchronous secondary is NOT going to delay transaction commits on your primary. Unplug yourself immediately and stop using my water supply. When 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. LOL, okay, you’re outta here. No need to keep going with that answer. F as in Ffffffamily friendly blog. Now, 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. Attempt 6: OpenAI ChatGPT 5.6 Pro Generally, 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: After five minutes , I got bored and clicked “Answer Now”, and it returned immediately. I’m going to paste it without formatting and links: Yes, CHECKDB is 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 won’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 rises and your production transactions slow down. I’d leave the CHECKDB replica 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. Good stuff. It’s nowhere near a casual podcast-answer voice, but it’s technically correct, so that’s good. At this scale, I’d run PHYSICAL ONLY frequently, then do periodic full logical checks somewhere else—ideally restore a checksum-enabled backup to a separate server and run full CHECKDB there. For the tempdb failures, first run DBCC CHECKDB ... WITH ESTIMATEONLY , then pre-size tempdb rather than relying on autogrowth. You can also cap CHECKDB with MAXDOP . If another 25TB copy isn’t practical, split the work across days: CHECKALLOC , CHECKCATALOG , and CHECKTABLE batches balanced by page count. One giant weekly CHECKDB isn’t sacred; detecting corruption within your backup-retention window is the real goal. No 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. Attempt 7: Anthropic Claude Fable 5 High The answer came back within seconds: Ooh, good question — and the fact that you’re even asking it means you’re way ahead of most shops with a 25TB database. I don’t know if Claude actually knows how much I love and abuse the phrase “good question”, but yes, I do. So 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. On 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. Here’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. If 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. But seriously — restore server. Best money you’ll spend. Next question Grade: 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. Summary: you can’t stop testing. The answer isn’t, “Fable 5 High is the best model for Office Hours levels of questions.” The 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.” But 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. To 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. Here’s how Nano-GPT’s chat console looks when I’m posting the question. Note the auto-model button at the bottom: You 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. They include some pretty doggone good coding models – DeepSeek, GLM, are really useful for me: And 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. I 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. And 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: Shell ./download model.sh ds4f-q2 download the smallest model make 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 1234 ./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 Happy prompting Free, 3× a week Get my new posts by email Three posts a week, plus a Monday roundup of the best database news from around the web.