Specialist work · database engines
A database engine was designed to distrust itself, which is why SQL Server and Exchange won't accept a store at all rather than guess at what a damaged page once held. The repair switches they come with restore consistency only by discarding anything that doesn't add up. Here's the order of work that follows from this: the MDF, LDF and EDB files are imaged along with their logs before any utility runs; all repairs are run against the clone; and the media sent 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 will not replay cleanly after an unclean shut-down. | Copy the MDF file and the log file first. |
| Held in Recovery Pending | Startup cannot complete, and the disk underneath is usually failing. | Have the storage checked also. |
| Torn pages, or error 823 and 824 | A read hit pages which no longer checksum. | Stop retrying and image it. |
| Error 5171 — ‘not a primary database file’ | MDF header is damaged. | Rebuild that header on a clone |
| The store reports Dirty Shutdown | The logs have been created but the changes in them have not been committed | Read the header of the database files prior to doing anything else |
| Someone has previously performed a "hard" repair on the system | REPAIR_ALLOW_DATA_LOSS was originally named as such for its high price: lost data | Obtain a quote first; do not send your server, just its disks |
Nothing is chargeable until you say yes. Every item gets a case number of its own immediately upon receipt, an engineer determines what has failed, and you get a clear picture of which files have a real possibility of being recovered. The single quote that follows is fixed, written down and does not cost anything.
The data files, logs and any backups you send us are cloned read-only. And if the disks underneath are themselves failing, the server and RAID process comes first, so that what we repair is a healthy image.
On this clone alone, the headers are rebuilt and the logs rolled forward as far as they can be trusted; beyond that, we rely on information contained within the page structures of this file to read out all table, mailbox and attachment data.
No case will be closed without confirmation that the database is attached, the store mounted and that the query returned some rows. In addition, prior to closure of the case, the records you designated as critical will be manually opened and inspected.
You don't get charged anything until you've confirmed and authorised that everything is fine after seeing the entire list of what was recovered. Any recovered items are returned via brand-new storage media and the postage costs for these are covered by us. We do not consider a project complete here until we receive confirmation that you have been able to successfully access and review every item you received back.
Two different finish lines: a "file recovery" completes once the recovered data can be accessed by reading the data (bytes). However, a "database recovery" doesn't complete until the database management system has successfully attached the file, mounted the database store and executed a query without an error message. The space between these two finish lines is referred to as "consistency", which is why some so-called "recovered" MDF files reach this bench still refusing to attach.
An emergency repair had already been queued before the practice called, due to an overnight loss of power causing the database to become marked as Suspect. Forensic copies were made first, and they showed that replaying the transaction log was still possible. Attaching on that copy worked at the first attempt, leaving the morning's bookings twenty minutes delayed instead of a full week.
Put your database offline, and save (or create) protected copies of the MDF and its log prior to attempting any operation against this version of the database. A Suspect database indicates that SQL Server was unable to finish replaying its log, typically due to a crash or stoppage during a write. This condition is generally recoverable. However, if you apply a well-intentioned repair to the original database files, this is what will destroy your database.
Generally, yes. Tables, indexes, and page information exist within the MDF file itself. Therefore, the MDF can usually be brought to a state where SQL Server will attach it, even where no log survives. If there were pending transactions at the point of failure that partially wrote data into new pages, they are identified as such and marked accordingly. These issues do not preclude attaching the MDF to SQL Server.
Rarely. All a Dirty Shutdown records is that there are log records the store has yet to commit. When you read the header of a database in order to determine which log generations remain outstanding, nothing is changed; you are simply determining which generations need to be replayed. Once those remaining records are replayed (soft recovery), mailboxes, etc., should be operational. It is the attempt at performing a hard repair that typically causes mailbox losses.
Due to the fact that much of the time the problem does not reside in the database but rather in one or more of the drives used to store it. Much of the time damage that returns after each attempted repair is caused by a disk that is on its last leg, an array whose member(s) failed, or a cache in a controller that continues to write fresh errors into each repaired copy of the database. A good number of database jobs are really server recoveries, and both are addressed here.
Every additional power-up asks for even more of a drive that is already starting to fail. First open a case with us, and let the free diagnosis tell you how much remains.