The RAID Controller Was Replaced, but the SQL Database Still Will Not Attach
The replacement controller may report the virtual disk online and the database files may be visible, yet SQL Server still rejects the file set and the production application remains unavailable. The remaining question is whether the controller reproduced the original array state or merely presented a plausible volume.
Do not recreate or re-import the array, clear metadata, force members online, rebuild logs, or repair the only database copy. Preserve every original member, both controller states, and every MDF, NDF, and LDF version.
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 controller replacement can change which members are included, how on-disk metadata is interpreted, which array generation is selected, or how the virtual disk is presented. Normal-looking filenames and sizes do not prove that their blocks match the state SQL Server used before the failure.
The attach error may arise from an incomplete or incorrect storage presentation, damaged database structures, mismatched files, or more than one layer. The storage result and database result must be tested separately.
What to record
- Original and replacement controller models, firmware, cache, and configuration records
- Virtual-disk and physical-member status before and after replacement
- Original bay, slot, serial number, capacity, and current status of every member
- Exact SQL attach and error-log messages plus database version, recovery model, sizes, and timestamps
- Every MDF, NDF, LDF, backup, snapshot, and recovered version
- Imports, clears, recreations, forced-online actions, rebuilds, log work, attaches, and repairs already attempted
- The tables, dates, records, and application functions required first
What not to do
- Recreate or re-import the array to test another configuration
- Clear foreign metadata before preserving both controller states
- Force members online or begin a rebuild
- Rebuild or delete the transaction log on the only copy
- Run database repair on files from an unvalidated volume
- Assume file visibility proves the replacement controller is presenting the original array
How ADR evaluates it
ADR compares the original member metadata, controller histories, and storage states to determine whether the replacement reproduced a defensible array. Members can be evaluated independently when the controller cannot be trusted.
Protected database copies are then examined against the SQL errors and business records required. A candidate is not accepted merely because SQL Server attaches it.
ADR can reconstruct and validate the array outside the controller, compare every recovered database-file version, and then choose an attach, repair, or extraction path from protected copies. The objective is usable business data, not another forced return to the failed production state.
What happens next
Attach failure after controller replacement does not establish that the database is lost. The result depends on member readability, the preserved controller states, prior writes or rebuild activity, available file versions, and which database structures remain internally consistent.