Power Is Back, but SQL Server Still Will Not Start the Production Database
The server restarted after the outage, but SQL Server cannot bring the production database online and the application, records, or users it supports remain unavailable. At this point another restart is not a recovery plan: the failed layer may be the RAID, controller cache, filesystem, transaction log, database files, or several of them at once.
Stop repeated restarts, repair commands, log rebuilding, detach-and-attach attempts, and restores to the affected storage. Preserve the present volume, every MDF, NDF, and LDF version, available backups, and the storage state that existed before and after power returned.
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
SQL Server uses the transaction log and database pages to reach a consistent startup state. An abrupt power loss can interrupt writes, but it can also expose an incomplete RAID rebuild, stale controller cache, unreadable sectors, filesystem damage, or storage that returned in a different state.
A Recovery Pending, suspect, attach, I/O, or log error shows where SQL Server stopped. It does not prove that SQL Server is where the damage began. The storage and database layers must be separated before either is modified.
What to record
- Exact SQL Server, Windows, application, controller, and storage errors
- The database state, SQL Server version, size, recovery model, and last normal access
- Paths, sizes, and timestamps for every MDF, NDF, and LDF version
- Available backups, snapshots, replicas, exports, and the last verified recovery point
- RAID level, controller, cache state, member status, UPS events, and power-return sequence
- Every restart, rebuild, filesystem check, restore, attach, repair, or log action already attempted
- The applications, tables, dates, and records the business needs first
What not to do
- Keep restarting SQL Server or the host to see whether recovery completes
- Run repair with data-loss options on the only database copy
- Delete, rename, or rebuild the transaction log by trial and error
- Restore a backup onto the affected storage as a test
- Run filesystem repair before protecting the volume
- Assume the RAID is sound because the server boots or the files are visible
How ADR evaluates it
ADR first establishes whether the storage presenting the database files is stable, complete, and from one coherent point in time. Original members, controller state, and the affected volume are protected before database structures are changed.
Database work then proceeds from protected copies. Alternate file sets, logs, backups, and internal pages are compared against the tables, dates, relationships, and records the business actually requires.
ADR can evaluate the member set or source volume, preserve each database-file state, and determine whether the outage must be corrected at the storage, filesystem, log, or database layer. The objective is a defensible working database when possible—or the priority business records that remain recoverable when it is not.
What happens next
A database that will not start after power returns is not necessarily lost. The result depends on the storage state, completed and interrupted writes, readable database pages, available logs and backups, and any changes made after the outage.