---
title: "DB24 | Docs - Integrity Maintenance"
description: "Everything you need to get started with DB24 — from installation guides and configuration to advanced features and best practices."
lang: en
json-ld: |
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "name": "DB24",
    "url": "https://db24.ai",
    "logo": "https://db24.ai/logo.png",
    "description": "Intelligent SQL Server Automation - Automate database management, enhance security, and optimize performance",
    "contactPoint": {
      "@type": "ContactPoint",
      "contactType": "sales",
      "email": "sales@db24.ai"
    },
    "sameAs": [
      "https://www.linkedin.com/company/db24"
    ]
  }
---

[![DB24 Logo](/lovable-uploads/152150d5-49f3-4c01-b0f4-8365df95171b.png)](/)DB24 Docs 

Installation 

Technical Documentation 

Features 

Maintenance 

[Overview ](/docs/maintenance-overview)[Index Maintenance ](/docs/index-maintenance)[Integrity Maintenance ](/docs/integrity-maintenance)[Statistics Maintenance ](/docs/statistics-maintenance)[File Size Maintenance ](/docs/file-size-maintenance)

[Overview ](/docs/overview)[Datastore ](/docs/datastore)[Runtimes ](/docs/runtimes)[Portal ](/docs/portal)[Integration ](/docs/integration)

Release Notes 

[Docs](/docs)maintenance 

# Integrity Maintenance

Copy Link

Last updated: May 13, 2026 

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

[Previous Index Maintenance ](/docs/index-maintenance)[Next Statistics Maintenance ](/docs/statistics-maintenance)