Ola Hallengren's July 2026 version history includes a fix for `DatabaseIntegrityCheck` when availability groups are in `RESOLVING` state. Integrity maintenance is often judged through one scheduled-job result, but a job can complete while a database is unavailable for selection or checking. The difference between job success and verified database coverage matters for operations, audit, and recovery confidence.
Why it matters in production
Teams need a per-database view of integrity evidence. Record the last completed CHECKDB, command type, target replica, duration, result, and any exclusion or skip reason. A schedule that runs every night provides no assurance for a database that has quietly missed several cycles because of role transitions, restore work, or configuration filters.
The command log should be treated as a control record. Compare the expected database list with commands actually executed, alert on missing or stale checks, and distinguish a deliberate offloaded check from a database that was never examined. Where full CHECKDB is too expensive, document the chosen alternative and its limitations rather than presenting lighter checks as equivalent.
Test behavior during failover and node maintenance. Observe which replica receives the command, how `RESOLVING` is reported, whether the job exits successfully, and how a catch-up run is initiated once the group is stable. Promote maintenance-solution updates through the same controlled process as other production automation.
Practical takeaway
The practical takeaway is that integrity belongs to each database, not to the job name. Track the last proven check, identify skipped databases, and run missing work after transient states clear. A green scheduler icon is useful, but only command-level coverage demonstrates that the estate was actually examined.