Specialist work · SQL and Exchange
Both SQL Server and Exchange audit themselves ruthlessly, and each would rather reject a database outright than make assumptions about it. Their own repair switches restore consistency by throwing away whatever will not balance. That fixes our running order: MDF, LDF and EDB files are imaged before a utility touches anything, and all repair work happens on the copies. Your originals are read once, then left alone.
Run the problem past an engineer
0800 6890668
| The problem | What's behind it | First move |
|---|---|---|
| SQL Server marks the database Suspect | After an abrupt stop, the transaction log would not replay | Get the MDF and LDF copied now |
| Stuck in Recovery Pending | Start-up has stalled, usually because the disk beneath is dying | The storage needs looking at too |
| Error 823 or 824, or torn pages | SQL ran into corrupt pages while reading | Stop retrying; image the files |
| Error 5171 — ‘not a primary database file’ | Damage in the MDF header | Rebuild the header on a copy |
| The EDB sits in Dirty Shutdown | Logs are still waiting to be committed | Start with a read-only header check |
| A hard repair has been run already | The name REPAIR_ALLOW_DATA_LOSS tells you the price | Post it anyway |
Every item gets its own case number on the day it lands here. An engineer traces the fault, gives you a plain assessment of what is realistically recoverable, and puts one fixed price in writing. The diagnosis is free, you are under no obligation, and chargeable work starts only when you say go.
Every data file, log and backup is cloned with no writes at all. Where the disks themselves are failing, our server and RAID process runs first, so we repair a sound copy.
Copies only: headers rebuilt, and logs replayed wherever they can be trusted. Where they cannot, specialist tools go straight into the file’s own page structures and lift out tables, mailboxes and attachments.
We are not finished until the engine says so: the file attaches, the store mounts, queries return results, and anything you called critical is opened and checked by hand. Only then does the job get signed off.
You get the full list of recovered files first, and nothing is charged until you approve it. Data goes back on fresh media, return postage paid, and the job stays open on our side until you confirm every file opens at your end.
The bar is higher than it looks: file recovery is over once the bytes come back. A database is not finished until the engine will attach it, mount it and run queries against it without objecting. Consistency is the gap between those two endings, which is why ‘recovered’ MDF files keep turning up on this bench still refusing to attach.
The mains dropped overnight and the database came up Suspect. An IT contractor had the emergency repair queued; copies taken forensically showed the log would replay after all. We ran it on the copy, it attached on the first go, and the morning's bookings started twenty minutes down rather than a week.
Keep it simple: bring it offline and put safe copies of the MDF and LDF somewhere before you type a single command. Suspect only means the engine could not replay its log tidily after a rough shutdown, which is usually very fixable. Databases are lost for good by well-meant repairs run on the originals.
Usually, yes. Nearly all of it sits in the data file, and that can normally be brought back to an attachable state even with no log at all. One caveat: transactions still open at the moment of failure can return part-written. We will show you exactly where that cut-off landed.
Rarely. A Dirty Shutdown state simply means log files are still queued for the database. A read-only header check lists what's outstanding, and soft recovery replays it. The mail is almost always intact — the danger lies in jumping to a hard repair.
Because the database is rarely the real patient — the storage beneath it is. Corruption that comes back again and again nearly always traces back to a dying disk, an array running degraded, or a cache gone bad stamping new damage into each 'repaired' copy. Plenty of database faults are server recoveries in another coat, and we cover both.
Switch a failing device on again and you lose a little more. Open a case before you do — the diagnosis is free, whatever it finds.