Database engines · specialist casework
Those flags are the engine being careful. SQL Server and Exchange will turn a store away rather than invent the contents of a page they cannot verify, and that caution leaves your rows and mailboxes intact. The repair switches they ship reach consistency by a blunter road: anything that will not reconcile is dropped. So the work here runs the other way about. MDF, NDF, LDF and EDB files sent in from across Birmingham, with their full log sets, are imaged the moment they arrive, the tools only ever touch the copy, and what you posted is read once and put away.
Tell an engineer what it is doing
0800 6890668
| What you see | What is behind it | What to do |
|---|---|---|
| Suspect next to the database name | Log replay did not complete after an unclean stop | Secure copies of both files first |
| Recovery Pending on restart | Start-up never finishes; the disk beneath is usually on the way out | Check the storage, not only the file |
| Errors 823 and 824, or torn pages | A page has failed its own checksum on read | Stop retrying and take an image |
| Error 5171 — ‘not a primary database file’ | Damage to the MDF header | Header rebuilt against an image |
| Exchange reports Dirty Shutdown | Some log generations never committed | Read the header first, repair nothing |
| Somebody has already forced a repair | REPAIR_ALLOW_DATA_LOSS does what it says | Get it to us |
Every item gets a case number of its own the day it lands. An engineer then works out what has actually failed and tells you plainly which files have a real chance of coming back and which do not. Only then does a price follow: one figure, fixed, in writing, and it costs you nothing to see it. Nothing is charged until you say yes.
Data files, logs and any backup media you send are copied read-only, once. Where the disks holding them are failing too, the drive and array work comes first; there is no sense repairing an image taken off a dying member.
All of it on the image, none on your file. Headers are rebuilt, then logs rolled forward no further than they can be trusted. Past that point the work goes down into the page structures themselves, lifting tables, mailboxes and attachments out one at a time.
A job is not closed on our say-so. It has to attach, mount and answer a query with rows on the bench before anything goes back, and the records you told us were critical get opened one at a time and read.
No invoice is raised until the full list of recovered files has sat in front of you and you have said go ahead. Your data comes back on media we buy new, posted at our expense, and the job is not closed here until every file has opened on your own machine.
Where the job actually ends: file recovery is finished when the bytes read back. Database recovery is finished only when the engine takes the file back, mounts the store and returns rows to a query without complaint. Between those two points sits consistency, which is why MDF files that someone else has already called recovered arrive here still refusing to attach.
The practice rang with its database marked Suspect after an overnight power cut, and an emergency slot was already open. Forensic copies came first, and on those copies the transaction log still replayed. Attaching against one worked at the first attempt, so the morning's bookings ran twenty minutes late rather than a week.
Stop the instance, then put safe copies of the MDF and its log somewhere else before a single command runs against either. Suspect means the engine gave up part-way through log replay after a bad stop, and that is usually a recoverable state. Databases get lost at the next step, when somebody points a repair at the live files.
Usually, yes. Rows, indexes and page structures all sit inside the data file, so an MDF can generally be worked into a state SQL Server will attach with no log present at all. What you may lose is the tail: any transaction still open at the moment the server died can come back half written, and we tell you precisely where that line falls.
Rarely. Dirty Shutdown means the store came down with log generations still uncommitted, no more than that. A header read harms nothing and names the missing generations; where they survive, soft recovery folds them back and the store mounts. Mailboxes usually come through. They go when a hard repair is reached for.
Because the database is rarely the thing that broke. The disks beneath it are. Damage that comes back after each repair nearly always traces to a disk shedding sectors, an array left running a member down, or a controller cache writing fresh errors into every copy you mend. A fair share of the database work that reaches this bench turns out to be server work, and both are done here.
Every extra power-up takes something off a drive that is already going. Leave it switched off and let the free diagnosis say what still reads.