Preserve the complete SQL consistency errors and storage evidence, protect the available recovery sets, and assess a known-good isolated restore before considering repair. Do not run Windows disk repair while SQL Server is using the files. Non-repairing checks still need an agreed workload and permission scope.
This article uses SQL Server 2022 as its reference and is source-researched, untested guidance. It contains no executable repair command. Integrity checks, restores and any production containment action require an authorised DBA, resource planning and an isolated rehearsal where practicable.
Separate the error from its cause
Record the complete error, database name, affected operation and time. Preserve the SQL error log, relevant Windows events, storage observations and the full consistency-check output. A screenshot of the final summary can omit the page, object or allocation details needed to assess the problem.
Microsoft’s consistency-error investigation describes possible causes across the filesystem, storage hardware, drivers, memory and SQL Server. A database error does not establish that the guest operating system alone is responsible, nor that the storage array is necessarily defective.
Map the affected SQL files to their Windows volumes, virtual disks and storage backing. Record recent changes to that path, including guest drivers, host placement, storage maintenance and SQL updates. These are correlation inputs. A change occurring earlier is not proof that it caused the corruption.
Keep chronology explicit. Establish the last known successful integrity assessment, the earliest observed application error and the backup points still available. An error first noticed today can have existed in backups created earlier. Discovery time is not necessarily damage time.
Understand what CHECKDB establishes
DBCC CHECKDB checks several aspects of a database’s logical and physical consistency. The command reference defines its checks, options, permissions and limitations. The exact options used matter when interpreting a result.
For example, PHYSICAL_ONLY narrows the work to physical page/record structures and allocation consistency. It can be useful within a wider maintenance strategy, but a successful physical-only result is not equivalent to the full set of logical checks. Likewise, options that omit checks must remain visible in the evidence.
An informational log entry does not necessarily mean no errors were found. Microsoft documents a completion message that includes counts of errors and repairs, even though the message itself is informational S2. Read the counts and the associated output instead of judging only the event severity.
A check may fail to complete because of resource or access problems. That outcome is different from “completed and found no consistency errors”. Record completion status, chosen options and any limitations before interpreting the result.
This article deliberately does not provide a production command to run immediately. Even a check without repair can generate substantial I/O and use temporary resources. The DBA must choose the exact database, options, observation window and capacity before execution.
Read concrete signals before scheduling another check
Microsoft's investigation names errors including 605, 823, 824 and 825; retain the complete messages, database/file/page identifiers and time, not just the numbers S2. In existing CHECKDB completion messages, read the error and repair counts even if the event says informational. The vendor example includes “found 15 errors and repaired 3 errors”; those are source-example counts, not findings from a tested system here.
Untested, read-only SQL Server 2022 catalogue query, using an authorised role with visibility of the intended database R1:
SELECT name, state_desc, page_verify_option_desc
FROM sys.databases
WHERE name = N'LabOrders';
Microsoft recommends PAGE_VERIFY CHECKSUM; changing that setting is a separate DBA action. A reported checksum error is evidence to investigate the I/O path, not proof that a particular disk caused it S2.
For an isolated lab copy only, after confirming capacity and permissions, this untested diagnostic estimates CHECKDB's tempdb requirement without performing its consistency check. It needs an existing db_owner or sysadmin role and is not a zero-cost production probe S1:
DBCC CHECKDB (N'LabOrders') WITH ESTIMATEONLY;
Do not run chkdsk while SQL Server is running against the files. Microsoft warns that /f or /r can move file bytes and cause further corruption during SQL reads/writes. Any filesystem repair needs a separate shutdown, verified-backup and specialist plan; no repair command is supplied S2.
Plan the diagnostic workload
Establish whether suitable evidence already exists from a recent complete check. Re-running the same expensive task without reviewing its output can add load while providing little new information.
If another check is necessary, assess the database size, workload, free space and tempdb requirements. Microsoft documents an internal database snapshot in normal online checking and explains that alternative locking options change both concurrency and check coverage S1. Those are operational choices, not interchangeable ways to obtain the same result more quickly.
The documented estimate option estimates required tempdb space; it does not perform the consistency check. Preserve that distinction in any report. Likewise, elapsed time from a smaller restored copy cannot establish the runtime of a busy production database.
Where feasible, restore an independent copy onto a known suitable isolated path and assess it there. This can test the saved data while avoiding a large diagnostic workload on the failing service. It does not automatically explain whether the source storage is healthy or whether newer transactions are recoverable.
Use synthetic or authorised recovery data under the same confidentiality controls as production. A restored database is still sensitive even when it is used only for diagnosis. Do not place raw table contents or customer identifiers in a public article or general incident summary.
Preserve the recovery set before changing data
Inventory all accessible backup sets, the required log sequence, encryption protectors and restore instructions. Prevent routine rotation from accidentally removing potentially valuable recovery points while the incident is assessed, using a specifically approved retention decision.
Do not overwrite the only earlier backup with a new backup of an already damaged state. A current copy can still be valuable evidence, but it serves a different purpose from a known-good recovery point. Label each copy’s status rather than assuming “newest” means “best”.
Have the DBA assess whether additional recoverable log records can be preserved. Tail-log handling depends on the actual database and failure state. This guide supplies no generic command to change that state, detach files or force recovery.
Record dependencies beyond the database: application version, logins, keys, file attachments and external systems whose transactions must reconcile. A structurally consistent restored database can still represent a business state that needs investigation.
Evaluate a known-good restore
Choose candidate backup points from the evidence timeline. Restore each selected candidate to a separate, uniquely named destination through the supported procedure. Do not use the original database as the trial target.
Run the agreed integrity assessment on the restored copy and preserve its complete output. Microsoft’s VERIFYONLY reference is explicit that backup verification does not establish the structure of the data contained in the backup. Readable backup media can still contain a database with problems.
Then inspect known business records and relationships. Check the application operation that originally failed, using a controlled test. A structural check cannot know whether an invoice total, attachment or external payment acknowledgement agrees with the business requirement.
Compare the restored point with the required loss window. If the first acceptable copy is older than the agreed objective, report the gap plainly. The business owner must decide how to reconcile missing later work; a technically successful restore does not erase that loss.
Do not restore onto a storage path that remains implicated without a deliberate assessment. Microsoft advises resolving underlying hardware-related problems before restoring or otherwise repairing the database S2. Otherwise the replacement can encounter the same failure mechanism.
Keep repair as a specialist decision
The name REPAIR_ALLOW_DATA_LOSS describes a material consequence. Microsoft warns that repair can lose more data than restoration from the last known-good backup and is not a substitute for a supported restore S1.
If no acceptable restore exists, escalate with the preserved evidence and copies. The DBA and support specialist must determine which objects are affected, what a proposed repair would remove, whether an alternative recovery method is supported and how resulting business inconsistencies would be assessed.
The procedure must preserve the original state and be validated on a disposable copy before a production decision. A successful command completion is not proof that relationships between business records remain correct. Reconciliation can extend beyond SQL constraints and beyond the database itself.
Do not paste repair statements into an automated maintenance job. Do not casually place the database into emergency or single-user mode, rebuild a log, detach files or remove damaged pages. Those operations change access or recovery state and belong to an explicit case-specific plan.
Microsoft documents considering EMERGENCY mode to extract critical data before a last-resort repair. That belongs inside the specialist recovery plan, with preserved files and accepted consequences; it is not a routine diagnostic switch S1.
Investigate recurrence and intermittent findings
If errors appear in one run and disappear in another, preserve both results. Microsoft identifies intermittent findings as a reason to investigate the I/O path and caching rather than assume the first report was harmless S2.
Correlate SQL logs with Windows, guest-driver, hypervisor and storage events for the same interval. Give each layer’s owner the exact file and time mapping. A broad statement such as “the SAN is fine” is less useful than evidence about the affected path during the incident.
Review relevant SQL, operating-system, driver and firmware fixes against the exact installed versions. Do not apply every available update simultaneously and then claim to know which fault was corrected. Keep a cause hypothesis, approved change and verification result connected.
After recovery, establish a supported integrity-check and backup-verification routine with capacity, ownership and alert handling. A failed check should create an actionable incident. It must not trigger automatic data-loss repair.
Define completion at both technical and business levels
Technical acceptance includes a completed integrity assessment with its exact scope, stable storage observations, healthy application access and restored backup protection. Business acceptance includes representative records, required relationships and a documented decision about any lost or reconstructed work.
Retain the evidence showing why the selected copy was acceptable and why the suspected failure path is no longer in use or has been corrected. If the root cause remains uncertain, say so and define the monitoring and escalation that remain necessary.
No outcome is demonstrated by this article. Its value is a decision sequence that preserves choices: identify, collect, assess, rehearse, reconcile and only then authorise recovery.
Limitations
SQL Server 2022 is the reference scope. The troubleshooting article displayed 3 January 2025 and its referenced fix lists do not establish SQL Server 2025 coverage. ESTIMATEONLY, VERIFYONLY and an incomplete CHECKDB run are not clean integrity results.
Acceptance checklist
- Full errors, CHECKDB counts/options and storage chronology preserved.
- Known-good recovery sets and keys protected from accidental rotation.
- Restore/integrity assessment performed on the approved isolated path.
- Application reconciliation and the underlying fault investigated separately.
Learning notes
- A readable backup can contain structurally inconsistent data.
- The options used for a consistency check determine what its result covers.
- Repair completion and correct business records are different acceptance tests.
Related reading: SQL Point-in-Time Restore: Plan and Verify the Backup Chain; Restore a TDE Database Without the Original SQL Server; How to diagnose VMware and vSAN storage latency.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- DBCC CHECKDB (Transact-SQL) - SQL Server | Microsoft Learn
- Troubleshoot database consistency errors reported - SQL Server | Microsoft Learn
- RESTORE VERIFYONLY (Transact-SQL) - SQL Server | Microsoft Learn
Additional revision sources: