SQL Server Scripts

Decode PLE and Buffer Cache Hit Ratio via cntr_type Codes

Sun, 06 Sep 2026 00:00:00 +0000

How many seconds should a data page sit in the buffer pool before SQL Server decides it isn't needed anymore, and where does that number actually come from? Page life expectancy is one row among hundreds returned by sys.dm_os_performance_counters, and reading it correctly — along with its neighbor, buffer cache hit ratio — depends entirely on a column most ad hoc queries against this view skip past: cntr_type. Get that column wrong and a perfectly healthy instance can look like it's in crisis, or the reverse.

Audit Server Configuration Drift with sys.configurations

Mon, 24 Aug 2026 00:00:00 +0000

Running sp_configure and getting back a success message is not the same thing as a setting actually taking effect. Between the moment a value is changed and the moment SQL Server is actually running it sits a gap — one a busy DBA can close with a single RECONFIGURE, or forget entirely until a restart months later flips a setting no one meant to touch yet. sys.configurations is where that gap is visible: its value and value_in_use columns don't have to match, and when they don't, this script says exactly why not and what to do about it.

Find Ad Hoc Plan Cache Bloat with sys.dm_exec_cached_plans

Thu, 13 Aug 2026 00:00:00 +0000

Not every plan in SQL Server's cache earns its place. A query compiled once — because its literal values were hard-coded into the text instead of passed as parameters — gets a full compiled plan cached right alongside plans an application reuses thousands of times a day. sys.dm_exec_cached_plans is where that difference becomes measurable: usecounts shows whether a plan was ever looked up again, and size_in_bytes shows exactly how many bytes it's still holding in memory for the privilege of never running twice.

Age Open Transactions with sys.dm_tran_active_transactions

Sun, 02 Aug 2026 00:00:00 +0000

A transaction that never commits keeps every log record written after it pinned in place, no matter how much work piles up behind it. sys.dm_tran_active_transactions lists every transaction currently open on the instance, but on its own it only shows a transaction ID and a start time — pairing it with sys.dm_tran_session_transactions and sys.dm_exec_sessions turns that anonymous row into a specific session, login, and elapsed duration worth investigating.

Purpose and Overview

The transaction log can only truncate up to the oldest point still needed for recovery, and an open transaction — no matter how small the actual data change behind it — holds that point fixed wherever it began. A transaction log backup running on schedule and a CHECKPOINT completing normally free nothing if a session opened a transaction ten minutes ago and hasn't committed or rolled back since. The log keeps growing, autogrow events start firing, and the eventual full-log error traces back to a single session that most routine monitoring never surfaces directly.

Rank Expensive Queries with sys.query_store_runtime_stats

Sun, 26 Jul 2026 00:00:00 +0000

Query Store buckets runtime statistics into fixed time intervals, which means a query that ran steadily all week doesn't produce one row of history — it produces one row per interval, split further by execution outcome. Averaging those rows unweighted is how a "most expensive queries" report quietly gets the ranking wrong on a busy instance. sys.query_store_runtime_stats is the catalog view holding that interval-level detail, and joined correctly to plan, query, and query text — with a weighted rollup across execution counts — it produces the resource-consumption ranking a DBA actually wants.

Rank Top Memory Consumers with sys.dm_os_memory_clerks

Mon, 20 Jul 2026 00:00:00 +0000

Buffer pool counters explain data cache pressure but go silent the moment memory trouble comes from somewhere else. sys.dm_os_memory_clerks is the DMV that covers everything the buffer pool doesn't — plan cache, In-Memory OLTP, Query Store, query memory grants, Extended Events sessions — by reporting pages_kb per clerk. Grouping those rows by type produces a ranked list of exactly which internal SQL Server subsystem is holding the most memory right now.

Break Down Buffer Pool Memory by Database

Sun, 12 Jul 2026 00:00:00 +0000

sys.dm_os_buffer_descriptors is the DMV that maps SQL Server's data cache down to the individual page level — one row per 8 KB page currently held in the buffer pool, tagged with the database_id and file_id it belongs to. Rolling those rows up with a simple GROUP BY database_id turns millions of individual page entries into a short, sortable list showing exactly how much of the instance's memory each database is holding onto right now.

Measure Disk I/O Performance per Database File

Fri, 03 Jul 2026 00:00:00 +0000

I/O latency is where disk bottlenecks hide. SQL Server accumulates every millisecond of file-level read and write wait in sys.dm_io_virtual_file_stats — one row per database file, reset at each service restart. Joining that DMV to sys.master_files replaces raw file IDs with physical paths and file types, and dividing accumulated stall by operation count converts totals into the average milliseconds per read and per write that a storage or DBA team can act on.

Detect Suspect Database Pages with msdb.dbo.suspect_pages

Thu, 02 Jul 2026 00:00:00 +0000

Storage errors do not always surface as immediate failures. When SQL Server encounters an 823, 824, or 825 error reading or writing a database page, it records the offending page in msdb.dbo.suspect_pages — a system table that accumulates page-level I/O failures across service restarts. Querying this table is the fastest first-pass for any corruption investigation, answering whether bad pages exist and which databases are affected before committing to a full DBCC CHECKDB run.

Configure Database Mail and Send a Test Message

Wed, 01 Jul 2026 00:00:00 +0000

Database Mail ships disabled; enabling it and wiring up an SMTP account, a profile, and a public principal grant are the steps that stand between a fresh SQL Server instance and sp_send_dbmail working reliably. The configuration script below executes all four setup calls inside msdb, fires a test message, and queries msdb.dbo.sysmail_event_log to confirm the message reached the SMTP relay — all in one repeatable script.

Purpose and Overview

Sending email from SQL Server — for Agent job failures, custom monitoring alerts, or ad hoc DBA notifications — runs through a single pathway: an SMTP account registered in msdb, wrapped in a named profile, and exposed to the Database Mail service via a principal-profile grant. When any of those three links is missing or misconfigured, sp_send_dbmail accepts the call and silently queues the message, but the mail never leaves the server. The only diagnostic path is msdb.dbo.sysmail_event_log.

Apply Row and Page Compression to Tables and Indexes

Tue, 30 Jun 2026 00:00:00 +0000

Storage budgets shrink faster than databases grow. Uncompressed tables and indexes often carry two to four times the physical page count that row or page compression would require — a gap that widens with every batch load or continuous INSERT. sys.dm_db_index_physical_stats joined to sys.partitions surfaces every uncompressed index and heap in a database in one pass, and the script below converts that inventory into ready-to-execute ALTER INDEX REBUILD and ALTER TABLE REBUILD statements sorted by object size so the highest-impact targets come first.

List All Tables Across All Databases in SQL Server

Mon, 29 Jun 2026 00:00:00 +0000

A cross-database table inventory is one of the most common ad hoc requests in any SQL Server environment — and one of the few queries that cannot be answered by staying inside a single database context. sys.databases exposes every online database on the instance; three-part name references to sys.tables inside dynamic SQL pull the user-table list from each one. The script below accumulates results in a temp table and returns them sorted by database, schema, and table name, with a second variant that narrows results to a specific table name for cross-database search.

System-Versioned (Temporal) Tables in SQL Server

Fri, 19 Jun 2026 00:00:00 +0000

Every UPDATE and DELETE on a system-versioned table leaves behind a complete, queryable history of the previous row — automatically, with no triggers and no audit-table plumbing. SQL Server records the period each row version was valid and answers point-in-time questions through a single FOR SYSTEM_TIME clause. This is the temporal-tables feature, available since SQL Server 2016.

Purpose and Overview

A system-versioned temporal table is a user table that keeps a full history of data changes so you can analyze the data as it existed at any point in the past, not just as it is now. The feature is implemented as a pair of tables: the current table holds the present rows, and a linked history table stores prior versions. The Database Engine manages the relationship — on every update or delete, it closes the old row in the history table and stamps a new period of validity.

SQL Server Database Schema and Data Dictionary Queries

Thu, 18 Jun 2026 00:00:00 +0000

Documenting a database starts with a data dictionary: every table, every column, its data type, length, nullability, and default. SQL Server exposes this through the ANSI-standard INFORMATION_SCHEMA views, which produce a portable schema report that reads almost like English and runs unchanged on other ISO-compliant database engines.

Purpose and Overview

INFORMATION_SCHEMA is a set of views defined by the ISO SQL standard and implemented in a special schema present in every SQL Server database. Their purpose is insulation: they present an internal, system-table-independent view of metadata, so applications keep working even when the underlying system tables change between releases. That portability is the main reason to reach for them — a data-dictionary query written against INFORMATION_SCHEMA will run on SQL Server, PostgreSQL, MySQL, and other engines that implement the standard.

How to Update Statistics in SQL Server

Wed, 17 Jun 2026 00:00:00 +0000

A query that ran in milliseconds last month now scans a million rows and spills to tempdb. Nothing changed in the code — but the data grew, and the statistics the optimizer relies on went stale, so its row estimates drifted far from reality and it chose a bad plan. Refreshing statistics is the fix, and knowing how and when to do it is core DBA work.

Purpose and Overview

SQL Server's query optimizer is cost-based: it estimates how many rows each operator will process and picks a plan accordingly. Those estimates come from statistics objects — histograms and density vectors that describe the distribution of values in a column or index. When data changes but statistics do not, estimates degrade, and the optimizer can choose nested loops where a hash join belongs, or under-size a memory grant.

sp_pkeys and Primary Key Metadata in SQL Server

Tue, 16 Jun 2026 00:00:00 +0000

Which columns make up a table's primary key, and in what order are they declared? For a single table, the system stored procedure sp_pkeys answers in one line; for a database-wide inventory, the catalog views behind it give you full control. This post covers both, from the quick lookup to the complete metadata query.

Purpose and Overview

sp_pkeys returns primary key information for one table in the current database. It is an ODBC-catalog procedure — the T-SQL equivalent of the SQLPrimaryKeys ODBC function — and its result set is deliberately compact: TABLE_QUALIFIER, TABLE_OWNER, TABLE_NAME, COLUMN_NAME, KEY_SEQ, and PK_NAME. The KEY_SEQ column is the one that matters most: it gives the sequence number of each column within a multicolumn primary key, so a composite key returns one row per column in declared order.

sysindexes vs sys.indexes: Legacy and Modern Catalog Views

Mon, 15 Jun 2026 00:00:00 +0000

Plenty of SQL Server scripts still in circulation read rowcnt and dpages straight out of sysindexes — a habit inherited from SQL Server 2000, where that table was the canonical place to find row counts and page totals. The object survives only as the sys.sysindexes compatibility view, is flagged for removal, and returns inaccurate numbers for partitioned tables. This post shows the modern replacement and how to migrate.

Purpose and Overview

In SQL Server 2000, sysindexes was a real system table with one row per index and heap, and DBAs leaned on its rowcnt, dpages, reserved, and used columns for quick size and row-count reports. SQL Server 2005 rebuilt the metadata layer, and sysindexes was retained only as sys.sysindexes, a backward-compatibility view. Microsoft's documentation is explicit: this feature is included for backward compatibility, will be removed in a future version, and should not be used in new development.

SQL Server Catalog Views: sys.tables, sys.indexes, sys.objects

Sun, 14 Jun 2026 00:00:00 +0000

The sys catalog views are the supported, forward-compatible way to read SQL Server metadata, and three of them — sys.objects, sys.tables, and sys.indexes — answer most day-to-day questions about what lives in a database. This script joins them into one inventory of every user table, its schema, its row count, and each index defined on it.

Purpose and Overview

sys.objects is the base catalog view: it contains one row for every user-defined, schema-scoped object in a database — tables, views, stored procedures, functions, constraints, triggers, and more — each identified by a unique object_id. sys.tables is a derived view built on top of it. It returns every column sys.objects returns, plus table-specific columns such as temporal_type and is_memory_optimized, but only for rows where the object is a user table. sys.indexes then carries one row per index or heap of each tabular object, keyed back to the table by object_id.

SQL Server DBCC Commands: The Complete DBA Reference Guide

Mon, 08 Jun 2026 00:00:00 +0000

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 — and a DBA who does not know which one to reach for in an incident reaches for the wrong one. This guide maps the DBCC surface area by family, shows a representative statement for each, and links to deep dives on the commands you run most.

SQL Server DBCC CHECKDB: Complete Guide and Repair Options

Sun, 07 Jun 2026 00:00:00 +0000

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 the one statement that finds the damage early, while you still have a clean restore point, and this guide covers how to run it and what its repair options actually do.

SQL Server DBCC FREEPROCCACHE: Clear the Plan Cache Safely

Sat, 06 Jun 2026 00:00:00 +0000

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 compiled for the wrong parameter value, and DBCC FREEPROCCACHE is the scalpel that removes it. The danger is using it as a sledgehammer.

SQL Server DBCC SHRINKDATABASE: When and When Not to Shrink

Fri, 05 Jun 2026 00:00:00 +0000

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 what shrinking does to your indexes, when it is genuinely the right call, and how to reclaim space the few times you must without wrecking performance.

SQL Server DBCC CHECKIDENT: Check and Reseed Identity

Thu, 04 Jun 2026 00:00:00 +0000

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 values. DBCC CHECKIDENT closes both gaps in a single statement, and knowing how to check before you reseed keeps it from creating a worse problem than it solves.

DBCC DBREINDEX vs ALTER INDEX REBUILD in SQL Server

Wed, 03 Jun 2026 00:00:00 +0000

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 need to lock, and it cannot do the things modern index maintenance takes for granted. This post compares it to its replacement and shows the one-afternoon migration to ALTER INDEX.

SQL Server Duplicate and Overlapping Index Detection Script

Mon, 25 May 2026 00:00:00 +0000

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 candidates.

Purpose and Overview

sp_BlitzIndex does deep usage and statistics analysis across every index. sp_SQLskills_finddupes factors in INCLUDE columns and sort direction. The script below fills a narrower role between them: a portable, dependency-free first pass for the single most common form of index redundancy — two non-heap indexes on the same table that share a leading key column. The output is a candidate list ready for human triage, not a drop list to apply unattended.

SQL Server Get Table and Index Storage Size Report Script

Sun, 24 May 2026 00:00:00 +0000

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, non-clustered, and the heap row that represents the table itself — in both kilobytes and megabytes, schema- and table-named for easy review.

Purpose and Overview

Backup windows that creep, restore tests that get skipped, archive policies that never get written — all three trace back to the same missing input: a current, per-object inventory of bytes-on-disk. sys.dm_db_partition_stats carries the page counts that answer the question; sp_spaceused only aggregates at the table or database level and loses the index-by-index detail this kind of capacity work needs. The query below converts those page counts to KB and MB for every index and every table in the current database, ready to paste into the next capacity-planning spreadsheet.

SQL Server Object Dependencies Report: Find All References

Sat, 23 May 2026 00:00:00 +0000

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 object name — the safe-refactoring impact analysis report.

Purpose and Overview

SQL Server tracks expression-level dependencies between user objects in the catalog view sys.sql_expression_dependencies. Every reference from a stored procedure, function, view, trigger, default, computed column, or check constraint to another object — table, view, function, procedure, type, or column — produces a row. The view supersedes the legacy sys.sql_dependencies view (deprecated in SQL Server 2008) and the older sp_depends stored procedure (which has always been unreliable for cross-database and late-bound references). Modern dependency tracking is metadata-only, schema-bound-aware, and accurate across cross-database name resolutions.

SQL Server Find Columns by Data Type Across the Database

Fri, 22 May 2026 00:00:00 +0000

"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, and sys.schemas to produce the canonical answer: every column in the current database with its full type signature.

Purpose and Overview

Which columns survived the move from text to varchar(max)? Which fields still carry the deprecated Money_T UDT three releases after it was officially retired? Did a recent merge silently reintroduce datetime on a column the design review thought it had migrated to datetime2? A single catalog-view query against sys.columns and sys.types answers all three — and every other question of the form "where is every column of type X in this database?" — without an INFORMATION_SCHEMA round trip or a manual table-by-table sweep.

SQL Server List All Foreign Keys with Referenced Tables

Thu, 21 May 2026 00:00:00 +0000

Every database with foreign keys eventually needs a single inventory: every constraint, its parent table and column, and the referenced table and column on the other side. This T-SQL script joins sys.foreign_keys to sys.foreign_key_columns, sys.tables, and sys.columns to produce the canonical foreign-key map of the current database — one row per column in every multi-column foreign key.

Purpose and Overview

The first symptom that a referential boundary has slipped is usually subtle: a DELETE on a parent table that ran in seconds last quarter now takes minutes, or a join across the foreign key plans an unexplained scan on the child side. Almost every diagnosis trails back to the same short list — a constraint disabled by an unattended deployment, a NOT TRUSTED flag left behind by a WITH NOCHECK bulk load, or a duplicate FK shadowing the one the optimizer was relying on. The inventory query below — sys.foreign_keys joined to sys.foreign_key_columns, sys.tables, and sys.columns — produces the complete relationship map in a single pass, so the foreign key in question is one filter away.

SQL Server VLF Count Report: Virtual Log File Analysis

Mon, 18 May 2026 00:00:00 +0000

Excessive virtual log files (VLFs) inside the transaction log slow down database recovery, backup, and restore operations — often by minutes on large logs — and the problem compounds silently every time autogrowth fires with a small increment. This script queries DBCC LOGINFO across every online database on the instance, counts VLFs and active VLFs per database, and assigns a health assessment so DBAs can prioritize remediation.

Purpose and Overview

A SQL Server transaction log is internally divided into virtual log files. SQL Server creates VLFs automatically when the log file grows, and the number of VLFs per growth event depends on the size of the growth increment — small increments create fewer but more numerous VLFs over time, while a single large pre-allocation creates just a handful. When a log accumulates hundreds or thousands of VLFs, SQL Server must scan every VLF header during recovery, log backup, and restore, adding overhead that scales linearly with VLF count. Paul S. Randal of SQLskills.com documented the authoritative research on VLF overhead and the recommended thresholds in his foundational VLF series.

SQL Server Database File Space Usage Report

Sun, 17 May 2026 00:00:00 +0000

Running out of space inside a data or log file halts SQL Server transactions immediately — and discovering that a volume is full only after an outage is too late. This script queries sys.master_files and sys.dm_os_volume_stats across every online database on the instance to report each file's allocated size, space actually written, free space inside the file, percent used, autogrowth configuration, and the amount of free space remaining on the underlying disk volume.

SQL Server Max Server Memory Calculator Script

Sat, 16 May 2026 00:00:00 +0000

Every SQL Server installation ships with max server memory set to its default value of 2,147,483,647 MB — effectively unlimited — which allows the Buffer Pool to consume all available RAM and starve the operating system of the memory it needs for network stack, disk I/O, and other critical processes. This script reads total physical RAM from sys.dm_os_sys_info, applies Jonathan Kehayias's widely-adopted OS reservation formula, and compares the recommended cap to the current sp_configure setting so DBAs can see at a glance whether action is needed.

SQL Server Identify Heap Tables Without Clustered Indexes

Fri, 15 May 2026 00:00:00 +0000

A heap table — a table with no clustered index — stores rows in no particular order, forces full table scans for most non-indexed queries, and accumulates forwarded records every time an UPDATE causes a row to outgrow its page. This script queries sys.tables, sys.indexes, sys.partitions, sys.allocation_units, and sys.dm_db_index_physical_stats to identify every heap in the current database, report its size and row count, and surface forwarded record counts so DBAs can prioritize which heaps need a clustered index.

SQL Server Copy-Only Backup Script for Dev Restore

Mon, 20 Apr 2026 00:00:00 +0000

A copy-only backup is a special SQL Server backup that is independent of the normal backup sequence. It does not reset the differential base or interrupt the transaction log backup chain, making it the correct choice when you need an ad-hoc backup for a development or test environment restore without affecting production recovery options.

Purpose and Overview

In a standard SQL Server backup strategy, full backups establish a new differential base and log backups form a continuous chain. If you take an unplanned full backup mid-schedule, the next differential backup becomes larger than expected because the base changed. If you take an unplanned log backup, you may break an automated restore chain that depends on log sequence numbers.

SQL Server: Find Databases With No Recent Backup

Sun, 19 Apr 2026 00:00:00 +0000

Finding databases that have not been backed up recently is one of the most important checks a DBA can run. A database that grows unnoticed without a backup is a data loss event waiting to happen. This script queries msdb.dbo.backupset against sys.databases to surface any online user database with no full backup in the last 24 hours, or that has never been backed up at all.

Purpose and Overview

SQL Server does not alert you by default when a database backup is overdue. If a scheduled backup job fails silently or a new database is created without being added to the backup plan, that database will accumulate changes with no recovery point. The only way to detect this proactively is to query the backup history in msdb.

SQL Server Foreign Keys Without Indexes Script

Sat, 18 Apr 2026 00:00:00 +0000

Foreign keys enforce referential integrity, but SQL Server does not automatically create indexes on the referencing (child) columns. An unindexed foreign key column forces a full table scan every time a join or a DELETE on the parent table triggers a referential check. This script identifies all foreign key columns in the current database that have no supporting index, and generates the CREATE INDEX statements to fix them.

Purpose and Overview

When you run a DELETE on a parent table, SQL Server must verify that no child rows reference the deleted parent. If the child table's foreign key column has no index, SQL Server performs a full table scan on the child table for every deleted parent row. On large tables this can make simple deletes extremely slow and cause blocking on the child table.

SQL Server Backup Compression: Enable and Verify