SQL Reports Corruption, and Required Patient Records Are Inaccessible
The healthcare or dental application cannot reliably reach current patient, scheduling, treatment, billing, document, or imaging-reference data, and SQL Server reports corruption, suspect status, Recovery Pending, failed recovery, or an attachment error. The immediate task is to preserve the complete source and determine whether the failure begins in the database, the filesystem, the virtual machine, or the storage beneath it.
Stop DBCC repair with data-loss options, detach-and-attach experiments, transaction-log replacement, restores to the affected system, RAID rebuilds, filesystem repair, and repeated restarts. Preserve the original storage state and every MDF, NDF, LDF, backup, snapshot, export, application-data folder, document or image repository, and recovered copy.
Tell an ADR technician what the system reports and what has already been attempted. The failed system does not have to be brought online first.
What this condition means
A database error does not prove that the first failed layer is SQL Server. Incomplete RAID reconstruction, unstable members, controller changes, missing virtual disks, filesystem damage, interrupted writes, or a damaged VM can present database files that SQL Server correctly refuses to use.
A database that attaches or changes to an online state is not automatically a complete patient record. Required information may span data files, transaction logs, application tables, linked documents and images, configuration, and separate repositories. Recovery must be evaluated against the patients, dates, encounters, appointments, treatments, claims, payments, reports, and linked records the organization actually needs.
What to record
- Healthcare or dental application, version, SQL Server version, database names, recovery model if known, and last normal access
- Patients, date ranges, encounters, appointments, clinical or treatment records, claims, payments, documents, images, reports, or other data required first
- Exact SQL Server, application, Windows, virtualization, controller, RAID, filesystem, and storage errors
- Paths, sizes, and timestamps for every MDF, NDF, LDF, backup, snapshot, export, database copy, application-data folder, document repository, and imaging repository
- Server or VM topology, controller, RAID level, volume, member identities, replacement drives, and current state
- Every restart, rebuild, repair, attach, log change, restore, filesystem check, controller change, drive replacement, migration, or write already attempted
- Authorized access, custody, confidentiality, destination, and onsite requirements
What not to do
- Run DBCC repair with data-loss options on the only database copy
- Delete, rename, rebuild, or substitute the transaction log by trial and error
- Keep detaching, attaching, or restarting SQL Server against the same source files
- Restore an older backup over the affected database or volume
- Run filesystem repair or repeat a RAID rebuild before protecting the storage
- Assume the database is complete merely because it attaches
- Write repaired, extracted, or recovered output to the failed storage
How ADR evaluates it
ADR first protects the storage and every available database state. RAID, volume, filesystem, VM, database, and application conditions are separated so database repair is not attempted against files recovered from an incomplete or changing source.
Database work then proceeds from protected copies. Available pages, allocation structures, logs, backups, exports, application tables, and linked repositories are evaluated against the authorized patients, dates, records, relationships, and operational priorities—not merely whether SQL Server accepts the database.
ADR can begin with the protected member set or source volume, every database and log version, backups and snapshots, exact errors, application and repository relationships, prior actions, and the records required first. The failed server does not have to boot, the array does not have to be forced online, and the original SQL instance does not have to start before recovery begins.
What happens next
SQL corruption does not establish that the required patient records are lost. The practical result depends on the preserved storage and database states, readable page and log structures, linked repositories, available backups and exports, prior intervention, and whether the required records remain internally consistent.