Every SQL Server instance ships with a parallel command vocabulary that never appears in an ORM, a stored procedure, or an application query: the DBCC statements. They validate physical page structure, reclaim file space, evict cached plans, reseed identity columns, and report internal counters that no SELECT exposes — …

Corruption rarely announces itself. A bit flips on a SAN, a controller loses power mid-write, a driver mishandles a flush — and the damaged page sits unread for weeks until a query finally touches it and the database throws error 824. By then the corruption may already be inside every backup you keep. DBCC CHECKDB is …

A stored procedure that returned in 20 milliseconds yesterday is timing out today, and nothing in the code changed. The data did not grow meaningfully, the indexes are intact, and statistics look current — yet the query is suddenly scanning a million rows it used to seek. The usual culprit is a cached execution plan …

A one-time data load doubled a data file overnight, the load is done, the rows are deleted, and the file is now mostly empty space. The reflex — reach for DBCC SHRINKDATABASE and give the disk back — is one of the most common self-inflicted performance wounds in SQL Server administration. This post explains exactly …

A logging table grew to forty million rows, the bulk of it was archived out, and now only the last week's data remains — but the next insert still gets identity value 40,000,001, leaving a vast gap below it. Or a botched data load left the seed sitting far above the real maximum, and future inserts skip millions of …

Open the SQL Agent job history on an instance that has been running for a decade and you will still find DBCC DBREINDEX in a nightly maintenance step, quietly doing its job. It works — which is exactly why nobody has touched it. But it has been deprecated for the better part of twenty years, it locks tables it does not …

Duplicate and overlapping indexes waste storage, slow down every write, and split optimizer statistics across redundant copies. This T-SQL script compares each non-heap index in the current database on its first sixteen key columns and surfaces any pair of indexes that overlap, giving the DBA a short list of cleanup …

Knowing how much space each table and each index consumes is the foundation of capacity planning, archive policy, and index cleanup decisions on any SQL Server instance. This T-SQL script reads the partition-level storage statistics out of sys.dm_db_partition_stats and reports the size of every index — clustered, …

Before renaming a column, retiring a view, or dropping a stored procedure, every DBA needs the answer to one question: what else depends on this object? This T-SQL script reads sys.sql_expression_dependencies and reports every referencing-and-referenced pair in the current database, with optional filtering to a single …

"Where is every datetime column?" — "Which tables still use text instead of varchar(max)?" — "Are any columns using a deprecated user-defined type?" These are recurring DBA questions during schema audits, deprecation sweeps, and pre-migration assessments. This T-SQL script joins sys.columns to sys.types, sys.tables, …