368 5.11 Fixing failed databases
After applying the new setting, the Store begins to generate events the
next time it runs background maintenance. Except on very large or heavily
loaded servers, many of these tasks complete quickly. The obvious exception
is background defragmentation. This is the most intense activity and can last
a number of hours, depending on whatever other load the server is under,
hardware configuration, and the size of the databases that the Store processes.
5.11 Fixing failed databases
A database failure has always been the source of bad dreams for Exchange
administrators. It’s not just the failure and the work required to restore ser-
vice to users theres the inevitable inquiry as to why the failure occurred—was
it a software bug, fault in a disk drive or controller, a lapse in administrative
procedures, or something else that needs to be understood and protected
against in the future. Database failures were reasonably common in the early
days of Exchange (4.0 through 5.5 and even into 2000), but things have
improved significantly as the software matured and, even more importantly,
hardware (especially disks and controllers) has become much more reliable.
At this point, its fair to assert that a database failure comes as a surprise
rather than a common occurrence for most Exchange administrators, assum-
ing that normal best practice in hardware maintenance and monitoring is
carried out. Even so, it’s good to be aware of the tools that you can use to
recover from a database failure should the need arise.
Transaction logging is one of the great strengths of the Exchange Store.
With a full set of transaction logs and some good backups, you should be
able to handle the vast majority of failures. Simply swap in some new hard-
ware to replace the dud components, restore the database from backup,
replay the transaction logs to bring the database up to date, and restart ser-
vices. Of course, there are different variations on the restore theme, including
dial-tone restores (to restart services with blank mailboxes and eventually
recover the missing contents behind the scenes as users continue to work),
but everything revolves around the ability to restore a copy of the failed data-
base from a backup successfully. Troubles truly begin if you discover that you
cant restore the database from a backup or Exchange refuses to start up with
the backup copy. Not having a good backup to restore from, finding that the
backup media is damaged, or perhaps that the backup failed for some reason
and no one noticed are all reasons to update your resume.
Even with the reliability and robustness of todays hardware, nothing
quite beats the feeling of confidence that a good backup brings—or the calm-
ness that happens when you know that solid backups are available in an off-
site location. But lets assume that you have managed to restore a copy but
that Exchange wont mount the database for some reason. What can you do
then? The answer lies in two utilities that have been part of the product since

Get Microsoft Exchange Server 2007: Tony Redmond's Guide to Successful Implementation now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.