Database Corruption (SQL Server, MySQL, and Similar)
A production database that suddenly will not open can be suffering from logical corruption, an incomplete transaction or upgrade, storage faults, memory or controller errors, or application-level damage. The first job is to preserve evidence and determine the scope before using any repair option that may discard data.
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 unnecessary write activity and preserve the database files, logs, backups and relevant storage state before attempting destructive repair. If the underlying storage shows read errors or other signs of failure, image or clone that layer first. On healthy enterprise storage, a consistent copy or supported backup/snapshot may be more appropriate than blindly imaging an entire device; the key principle is to preserve an untouched recovery point before repair.
Be careful with destructive engine-specific repair options. SQL Server's REPAIR_ALLOW_DATA_LOSS, for example, may deallocate damaged structures to restore consistency. MySQL recovery procedures depend on the storage engine — REPAIR TABLE is not a general InnoDB corruption remedy — so the exact vendor documentation and engine matter. 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.