Specialist · database engines
With SQL Server and Exchange there will be no guessing about the state of a database; each keeps an exact record internally and would rather refuse a database outright. Each has its own built-in repair tools to bring data into consistency by deleting anything that does not pass the audit. So regardless of the tool we use to recover your databases, the first step is always to create images of all MDF, LDF and EDB files received from Exeter before applying any recovery method, and the repair is done on the copies. The original files sent by you are only accessed once, to create the images, after which they are set aside.
Talk it over with an engineer
0800 6890668
| What's wrong | What it usually means | Step one |
|---|---|---|
| SQL Server shows this database as Suspect | After stopping uncleanly (i.e. not shutting down properly), SQL Server was unable to replay its transaction logs. | Take a copy of your MDF and LDF files immediately |
| It shows "Recovery Pending" and has been stuck with no progress | Your start-up pass has got stuck: commonly that means you have a failing disk underneath | Have someone take a look at the storage too |
| You are seeing torn pages, or getting errors 823 and/or 824 | During a read the database engine encountered bad or damaged pages | Make no further attempts at recovery; image the files instead. |
| The 5171 error: ‘not a primary database file’ | Something broke in the header at the top of the MDF. | Fixed on a copy (i.e. not the original) to repair the header. |
| Stuck at Dirty Shutdown for an EDB file. | Logs outstanding never made it into the DB. | A simple, harmless header test as a place to start. |
| Someone has already gone ahead and run a "hard" repair. | The name REPAIR_ALLOW_DATA_LOSS is very descriptive regarding what it costs. | First get a quote, then send it in no matter what. |
Your device will be logged under its own case number on the day it comes into our lab. The engineer who works on your device identifies the problem with it, clearly states what we think has a good chance of coming back and provides you with one fixed quote. There are no charges for this assessment; there is no obligation for you to do anything; and paid work does not begin until you authorise us to start.
When data files, logs and backups are copied (or "imaged") from your media to new media in our imaging process, there will be no writes involved in creating the copy. When storage is failing it has to go through our server and RAID workflow first, which allows us to fix a sound copy of the original.
All items in the image (i.e. the copies) have their headers rebuilt and logs replayed where they are sound; if logs are unsound then special-purpose tools can extract table information, mailbox information and attachment information directly from the file's internal pages.
The final step in the restoration process is the engine's own acceptance, i.e. the database attaches or the store mounts and queries can run against it. Then the items you flagged as critical are reviewed manually. Sign-off happens after this step, not before.
You have access to a complete list of every item recovered from your device, which you approve prior to any fees being applied. The files will be returned via new media (brand new) with the return postage paid by us, and the case remains open for as long as it takes to confirm that all the files open properly on your own machine.
Where the bar actually sits: a file recovery operation is complete when the recovered data can be found in its original byte format. A real database recovery operation is only completed when the database engine is able to attach and mount the file, so that it can run queries without throwing errors. Consistency is what defines the distance between those two finish lines, and it is why MDFs 'restored' elsewhere continue to show up here, still unable to be attached.
Power went out in the middle of the night, and the database came back up as Suspect. The emergency repair was ready to go from an IT contractor, however forensic copies showed that the log would still replay. We worked on a copy of the database and were able to attach it at the first attempt; therefore that morning's bookings were delayed by twenty minutes instead of one full week.
Do the easy thing: take it offline and save copies of your MDF and LDF files in a safe place before you run one single command. Suspect simply states that SQL Server was unable to replay its log cleanly after an untidy shutdown (usually very recoverable). It will be lost forever when you make a "well-intentioned" repair run on the original files.
The data file will usually work by itself; it has almost all of the information and can usually be convinced to be attached without its log. Trade-offs are made here: all data that were in progress when the server crashed may come back in an incomplete form. We will show you exactly where that last point of completion was on your server.
In most cases, no. Dirty Shutdown is simply a statement that the database has one or more log files which are waiting to be written into the database. If a read-only header check is performed on the database, those remaining log files can be listed, and soft recovery will then replay all of the remaining log files. Almost always the mail itself will be fine; it's the attempt at using the hard-repair shortcut that represents the real danger.
Because the actual patient that you're trying to treat isn't the database; it's your storage system. The reason for repeated problems with corruption is almost always a bad hard drive, a degraded RAID set or a faulty "cache" which will be re-applying damage onto every new version of whatever was being "fixed". What appears to be a problem with your database is actually a server recovery in disguise. We work on both.
Every time a failing hardware component is powered back up, there is additional lost data. First open a case with us: the inspection (look over) is always at no cost, whichever way it goes.