DB24 | Docs - Integrity Maintenance

Integrity Maintenance

Integrity maintenance runs DBCC CHECKDB against each eligible database to detect physical corruption, logical inconsistencies, and allocation errors. DB24 automates scheduling, configuration, error capture, and alerting — so corruption findings surface immediately rather than being buried in SQL Server logs.

Eligibility

Only databases that pass all of the following conditions are included in an integrity check run.

Condition	Rule
Access	The service account must have access (`HAS_DBACCESS() = 1`)
System databases	`tempdb` is always excluded
Exclusions	Not listed in the exclusions table
AG role	Databases are tracked per role (instance, primary, secondary) — see configuration below

Configuration

All parameters are configurable per scope — instance-wide, primary, or secondary — via cfg.Maintenance.

Parameter	Description
`RunMaintenanceIntegrity`	Master on/off switch. Automatically overridden to `1` if `BackupPreferred = 1` — see note below
`BackupPreferred`	When enabled, integrity checks run on whichever replica is handling backups, regardless of the `RunMaintenanceIntegrity` setting
`PhysicalOnly`	Limits the check to physical structure only — faster, but skips logical consistency checks. When disabled, `DATA_PURITY` checks are included instead
`NoIndex`	Skips integrity checks on non-clustered indexes for user tables — reduces runtime on large databases
`ExtendedLogicalChecks`	Enables additional logical checks on indexed views, XML indexes, and spatial indexes
`TabLock`	Uses table-level locks during the check — can improve performance but increases blocking risk

BackupPreferred behaviour: In an Availability Group, you typically want integrity checks to run on the same replica that takes backups — often a secondary. Setting BackupPreferred = 1 ensures this happens even if RunMaintenanceIntegrity is off for that scope. The two settings work together to give you flexible AG-aware scheduling without needing to manually track which replica is active.

Runtime Behaviour

Maintenance window is enforced per database. The window is checked at the start of every database iteration. If the window closes mid-run, the current database is aborted and all remaining databases are skipped.

Disk space is checked before every database. Free space is verified across all volumes hosting the database's files before DBCC CHECKDB is executed. If any volume breaches the configured threshold, the database is skipped and processing continues with the next. Each volume breach is logged once per run.

If a database is skipped due to insufficient disk space, DBCC CHECKDB is not executed — meaning potential corruption may go undetected until the next successful run. DB24 logs a warning in this case to flag that follow-up is recommended.

Error Handling and Alerting

DB24 distinguishes between two types of failure:

Confirmed corruption — DBCC CHECKDB completes and returns rows with a non-null RepairLevel. This indicates actual physical or logical corruption. The full DBCC output is captured and stored for investigation, and a critical warning is raised immediately.

Execution failure — DBCC CHECKDB fails to complete (e.g. due to memory pressure, a command error, or an environmental issue) but returns no corruption rows. A warning is still raised, but is categorised separately from confirmed corruption to avoid false alarms.

In both cases, the outcome — including the exact command executed, start/end time, and error details — is written to the maintenance log.

What Gets Checked

By default, DB24 runs:

DBCC CHECKDB ([DatabaseName]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, TABLERESULTS;

The exact command varies based on your configuration. PHYSICAL_ONLY, NOINDEX, EXTENDED_LOGICAL_CHECKS, and TABLOCK are each appended when their corresponding setting is enabled. DATA_PURITY is included when PhysicalOnly is off.