Specialist work · database engines
A database engine is built to distrust itself, which is why SQL Server and Exchange will refuse a store outright rather than guess at what a damaged page once held. The repair switches they ship restore consistency the only way they can, by discarding whatever no longer adds up. That sets the order of work here: MDF, LDF and EDB files are imaged with their logs before any utility runs, every repair is aimed at the clone, and the media sent in from Maidenhead is read once, then set aside.
Describe the fault to an engineer
0800 6890668
| The symptom | The likely cause | Start here |
|---|---|---|
| The database has been flagged Suspect | The log would not replay cleanly after an unclean stop | Copy the MDF and the log first |
| Held in Recovery Pending | Start-up cannot complete, and the disk underneath is usually failing | Have the storage examined as well |
| Torn pages, or error 823 and 824 | A read hit pages that no longer checksum | Stop the retries and image it |
| Error 5171 — ‘not a primary database file’ | The MDF header is damaged | Rebuild that header on a clone |
| The store reports Dirty Shutdown | Log generations are still uncommitted | Read the header before anything else |
| Someone has already run a hard repair | REPAIR_ALLOW_DATA_LOSS is named after its cost | Send it to us |
Nothing becomes chargeable until you have said yes to it. Each item takes a case number of its own the moment it arrives, an engineer establishes what has actually failed, and you are given a candid view of which files stand a realistic chance of returning. The single quote that follows is fixed, written down, and costs nothing.
Data files, logs and any backups you send are cloned read-only. If the underlying disks are themselves failing, the server and RAID process comes first, so that what we repair is a healthy image.
On the clone and nowhere else: headers are rebuilt and logs rolled forward as far as they can be trusted. Beyond that, the work moves into the file’s own page structures, from which tables, mailboxes and attachments are read out.
We do not close a case on our own say-so. The database has to attach, the store has to mount, queries have to come back with rows, and whichever records you named as critical are opened by hand and checked first.
Nothing is billed until you have seen the recovered file list in full and told us to go ahead. What comes back arrives on new media, with the return journey at our cost, and the case stays open at this end until you have opened every file yourself.
Two different finish lines: a file recovery ends when the bytes are readable again. A database recovery ends only when the engine will attach the file, mount the store and answer queries without complaint. The distance between those two points is consistency, and it explains why so-called ‘recovered’ MDF files reach this bench still refusing to attach.
An emergency repair was already queued when the practice rang, the overnight power cut having left the database marked Suspect. Forensic copies were taken first, and they showed the transaction log would still replay. Attaching on that copy worked at the first attempt, which left the morning's bookings twenty minutes behind rather than a week.
Take the database offline, then set aside protected copies of the MDF and its log before any command is run against it. Suspect is only the engine reporting that it could not finish replaying the log after an unclean stop, and that is generally recoverable. What destroys databases is a well-intentioned repair applied to the original files.
In most cases, yes. The tables, indexes and pages live in the data file itself, so an MDF can usually be brought to a state the engine will attach even where no log survives. The exception is a transaction still open when the server stopped, which may return half-written; we mark exactly where that boundary fell.
Seldom. Dirty Shutdown records nothing worse than logs the store has yet to commit. Reading the header changes nothing and shows which generations are outstanding, after which soft recovery brings them in. Mailboxes normally survive; what loses them is reaching for a hard repair.
Because the fault is seldom in the database at all; it is in the disks holding it. Damage that reappears after every repair almost always comes from a drive on its way out, an array still running a member short, or a failing controller cache writing fresh errors into each mended copy. A good number of database jobs are really server recoveries, and both are handled here.
Each further power-up asks more of a drive that has already begun to fail. Open the case first and let the free diagnosis tell you what is left.