The SQL Database Files Exist, but the Business Still Cannot Use the Data
A database can be “broken” in several different ways. SQL Server may be unable to attach it, startup recovery may stop, consistency checks may report damaged pages, the log may disagree with the data files, or a flawed RAID reconstruction may return normal-looking but incorrect blocks. The next step depends on which layer failed.
Do not keep trying unrelated repairs on the same files. Preserve every MDF, NDF, LDF, backup, recovered version, and the storage state that produced them before choosing a recovery path.
What this condition means
This page is a decision point, not a single diagnosis. If SQL Server reports Recovery Pending, the engine cannot begin or complete startup recovery. If it rejects an attach, the file set or its internal relationships may be inconsistent. Page errors can reflect database damage or an incorrect storage reconstruction.
The first defensible question is whether the storage beneath the database is stable and coherent. Only then can an attach, repair, log, extraction, or application-level problem be evaluated against trustworthy source data.
What to record
- Exact SQL Server state, attach message, error-log entries, and DBCC output
- Database version, size, recovery model, application, and last known working time
- Every MDF, NDF, LDF, backup, snapshot, and recovered file version
- RAID, controller, SAN, NAS, VM, filesystem, power, and media history
- Every rebuild, restore, repair, attach, detach, log, or file-recovery attempt
- The tables, dates, records, and business functions needed first
What not to do
- Run multiple repair methods against the only database copy
- Delete or rebuild logs by trial and error
- Assume a mounted volume or correctly sized MDF proves the storage is correct
- Discard earlier recovered versions
- Restore or write repaired output onto the affected storage
How ADR evaluates it
ADR first identifies which storage and database-file versions are available and whether the underlying volume is trustworthy. That keeps a storage reconstruction problem from being mistaken for SQL corruption.
The exact SQL condition then determines the path: startup recovery analysis, attach evaluation, page-level database analysis, log-versus-data-file comparison, or extraction of priority business records.
ADR can compare the storage state, file versions, SQL messages, internal structures, and the business records required first. The objective is not to make one copy open at any cost; it is to select the most defensible source and recover usable data from it.
What happens next
The existence of damaged or rejected database files does not establish that all records are lost. The result depends on the underlying storage, alternate file versions, internally consistent pages and logs, prior intervention, and the business data that must be recovered.