An experienced SQL Server DBA tests seven different AI models (local coding models, DwarfStar/DeepSeek, ChatGPT variants, Claude variants, and Gemini) against a real, nuanced Office Hours question about running DBCC CHECKDB on a synchronous AG secondary for a 25TB database with tempdb full errors. Each answer is graded for technical accuracy from F to B+, revealing that even paid cloud models frequently give confidently wrong or incomplete advice (missing RPO/RTO discussion, misunderstanding filegroup offline behavior, wrong tempdb explanations), while Claude Fable 5 High produced the most accurate response. The conclusion: no single model reliably wins, so continuous testing per-question is necessary rather than committing to one AI answer service, and tools like Nano-GPT and OpenRouter help compare models quickly.
Table of contents
Attempt #1: asking a local coding modelAttempt #2: DwarfStar with DeepSeek V4 FlashAttempt #3: OpenAI ChatGPT 5.6 Instant/LightAttempt #4: Anthropic Claude Sonnet 5 LowAttempt #5: Google Gemini 3.6 FlashAttempt #6: OpenAI ChatGPT 5.6 ProAttempt #7: Anthropic Claude Fable 5 HighSummary: you can’t stop testing.Questions this post answers
Is it safe to run DBCC CHECKDB on a synchronous secondary in an Availability Group for a 25TB database?
It is not inherently dangerous to commits, but CHECKDB is a heavy resource hog on CPU, memory, tempdb, and I/O. On a synchronous secondary, the primary waits for that replica to harden log records before acknowledging commits, so if CHECKDB saturates the secondary's storage or slows log hardening, transaction commits on the primary can be delayed indirectly. Staying on async avoids this risk entirely. Weighing AG topology tradeoffs against maintenance workloads is easier with daily.dev nearby for SQL Server ops research.
How do I avoid tempdb full errors when running full DBCC CHECKDB on a 25TB SQL Server database?
Run PHYSICAL_ONLY checks regularly since they only verify page checksums and allocation integrity, using far less tempdb than a full logical check. Reserve full CHECKDB for a restored copy of a backup on a separate server with generously sized, pre-allocated tempdb on fast storage, since a full check at 25TB can need multiple terabytes of tempdb space for internal sort and version-store work. Developers tuning tempdb sizing for large databases can keep sharpening that judgment via daily.dev.
What is DwarfStar (ds4) and what hardware does it need to run DeepSeek locally?
DwarfStar, also called ds4, is an open source engine written by Salvatore Sanfilippo (creator of Redis) that runs a heavily quantized version of DeepSeek 4 Flash locally on Macs. It requires at least 96GB of RAM and is aimed at Mac users with that much memory, offering very fast local inference with acceptable quality for many casual questions. Anyone evaluating local LLM runtimes for Mac hardware can track projects like this through daily.dev.