Database Corruption (SQL Server, MySQL, and Similar)
A production database that suddenly won't open is rarely a mystery about what happened — it's almost always a power loss mid-write, a failing disk, or a botched upgrade — but it's one of the few scenarios in this catalog where the engine's own built-in fix can do more damage than the original problem.
What's actually happening
Engines like SQL Server and MySQL's InnoDB storage engine maintain internal consistency checks — page checksums, transaction logs, structural metadata — specifically so that a torn write from an unexpected power loss, a silently failing underlying disk, or an interrupted upgrade or restore gets flagged as corruption rather than served up as valid data. Seeing an explicit corruption error is, in a real sense, the system working as intended: it's refusing to pretend everything is fine.
How recoverable this really is
This depends enormously on scope. A single corrupted page or table is a very different situation from a corrupted transaction log or damage at the storage layer underneath the database file itself. A database with a recent clean backup and an intact transaction log is usually a straightforward restore-and-replay, with little or no real data loss. One without a backup, where the only copy is the corrupted file itself, is a much harder job that has more in common with the RAID and storage-layer cases elsewhere in this catalog than with routine database administration.
The general approach
Stop any further write activity against the affected database immediately, since every additional write is a chance to compound the damage. Take a byte-level image of the underlying storage before running anything against it directly, the same principle used throughout the rest of this catalog for physically failing drives. Only after that should engine-native repair or recovery commands be attempted, and only against a copy.
Be careful with repair options like SQL Server's REPAIR_ALLOW_DATA_LOSS or MySQL's REPAIR TABLE — they do exactly what their names say, discarding corrupted rows or pages permanently to bring the database back online. That's sometimes the right tradeoff and sometimes destroys the exact data being saved. Run these against a copy of the database, never the live production file, and only after understanding precisely what each option discards.
Storage-layer corruption underneath a database shares its logic with RAID Array Failure and Virtual Machine Disk Corruption — in both cases, the container on top looks broken while the storage underneath may still be intact. For enterprise-scale storage recovery, the labs in our provider directory generally handle this kind of case.
This page describes the general situation, not a guaranteed fix for your specific case. If you'd rather have someone experienced take a look before you try anything, see what a hands-on evaluation looks like.