Repairing a Damaged Exchange Database
| Exchange 2003 post SP1 is far more "self healing" than previous versions; however, at times when corruption will occur and you will need to manually repair the databases offline. Two prime command-line tools are available for use with errors that can occur at the page, database, or application store level: ESEutil and ISinteg. ESEutil checks and fixes individual database tables, whereas ISinteg checks and fixes links between tables. It is always best to restore from a backup whenever possible. A repair may delete an unknown number of corrupted data pages and/or links to bring the database back to an operational state, and these may not be immediately obvious. Consider a repair a last option. If you restore from a backup, you ensure that you have a good, clean, stable database that will start and run on your server. In almost every circumstance, it is faster and more reliable to restore from a backup than to perform a hard repair on the database. Repair requires both considerable disk space (for the original, copy, temp, and restored database) and time. Depending on the source and destination (for example, from tape to HDD, between disks, or within the same partition), transfer rates can be as slow as 36GB per hour. The repair process itself can run at approximately 46GB per hour, and the ISinteg check at a similar 36GB per hour. If this is not run on separate hardware, the process can impact the server's capability to service "normal" operations. It is worth warning here that ESEutil commands can be dangerous to the uninitiated. ESEutil can be looked at from several aspects: The harmless /m options, such as /mh, that provide an extensive read-out of information about the database; those manually run actions that occur as part of Exchange's own processes, such as the /cc command that ensures consistency; the more risky operations that affect the data, such as the /d defragment option, which performs a special operation to compact the databases; and the high-risk operations such as /p, which does a page level repair. The tools should not be used indiscriminately, and you should make sure that you have an offline copy of your databases and logs before running these commands. For example, consider an offline defragmentation only if you are moving an Exchange Server database or after a database repair. Performing offline defragmentation when it is not required could affect performance. Additionally, because offline defragmentation actually creates the new database, database files, and log file signatures, a new defragmented database file will have a different database signature. Because the databases and transaction logs point to each other based on signatures, all previous backups of this database are invalidated by the offline defragmentation. You should create new backups of Exchange Server 2003 databases immediately after offline defragmentation. Overall, ESEutil is a rich tool that any operator involved in Exchange recovery processes needs to be familiar with. Table 13.4 explains some of the command-line options, their functions, and descriptions.
After ESEutil has been run in a mode that affects the data, ISinteg should be run until it reports that there are zero errors. Note If ISinteg is run multiple times and does not correct the database corruption, you must use the ExMerge utility, which can skip individual corrupt messages, to extract data from the database to .pst files or another database. ESEUTIL /rESEutil /r performs soft recovery to bring a single database into a consistent or Clean Shutdown state. This is a nontrivial operation to repair the database after a restore. ESEutil takes the parameters /r [Base log file number. Usually E00] /i. ESEUTIL /pThe /p option used on its own discards corrupt pages while overwriting the database. There is no guarantee that the database will be usable if critical or sufficient pages are discarded, so there is serious potential to lose the database altogether. If the operation was not run on a copy, it would be catastrophic. The use of ESEutil /p should be considered an absolute last resort measure only. ESEutil /d /p on the other hand has a different result. The /d tells ESEutil to defragment the designated database. The /p option used after the /d instructs ESEutil to leave the newly created defragmented database in the temporary work area and not to overwrite the original database. Note that the order of the command-line options is important. ISINTEGISinteg is the tool that sees and treats the Exchange database as a relational database. ISinteg scans the tables and B-trees that organize the ESE pages into their logical structures. It looks at the mailboxes, public folders, and other parts of the information store, checking for orphans, incorrect values, and broken references. ISinteg builds an Exchange database, Refer.mdb, of reference counts. It then browses the tables, compares the counts found to the counts in the reference database, and, if running with the -fix switch, updates these counts to the values it considers correct. What appears valid to ESEutil from a physical data point of view might not be valid from a logical database view. Because ISinteg focuses on the logical level, it can repair and recover data that ESEutil can't. Valid data that was unavailable because of a broken reference in the database may be made available again after ISinteg repairs the link. ISinteg has two modes. The default Test mode, which runs the specified tests and reports the results, and the Fix mode, where ISinteg runs the specified tests and attempts to fix any errors. Table 13.5 shows some of the operator options.
It is important to run ISinteg until it no longer reports any errors. Running the command once will not guarantee that the Information Store is functioning properly. The process can take some time depending on the size of the Information Store and the power and resources of the computer on which it is run. |
EAN: 2147483647
Pages: 253