If the server crashed so the logs will lost in this crash!.
Also if you manually copy these logs it will be invaluable as the database signature will be changed, If there's a way to change the signature number it may works but I'm not aware of that.You should have a full backup taken to use in restoration process and logs are important in the recovery to not lose your messages and changes since the last full backup.
But if you have only a database crash or corruption and you have all logs available from first created log you may have a chance as below:
What happens when the database file is lost? If we have all the log files still available it should be possible to retrieve all information. “everything is logged in the log files, even the creation of database files!”
If you dismount the database, delete the database file “mailbox database.edb” or whatever name you have given the database and try to mount the database again, the following error is raised:
Error message when a mailbox database appears to be missing
In my humble opinion, the yellow exclamation mark should be replaced with a very large red “X” since this is a very important message. When you click “Yes” a new mailbox will be created in the same location as the “old” database. This is a completely new database. Although it has the same name “mailbox database.edb” as in the previous step, it has new signatures, which Exchange Server uses to link databases and log files file together. Recovery of old log files will not result in information being replayed into the database because it is another database in this scenario. And remember, since all information is logged into the log file the creation of this new database is also logged. Choose No, and then delete the checkpoint file E00.chk and try to mount the database again. No error message is raised and the database is mounted. Even better, when you log on to your test mailbox you will see that no information is lost either!
This is what happens when you do click “Yes”: during the mount process Exchange Server cannot find the database file and it cannot find the checkpoint file.
Therefore it starts to recover all information by replaying the available log files. It starts with the oldest log file E0000000001.log which also contains the creation of the initial database file. All information in the other log files is replayed into this database until it reaches the end of the last log file E00.log. The database is mounted and ready to use.
When Exchange Server cannot find the database file but it does find the checkpoint file it will not replay the log files. It starts at the end of the last log file E00.log and it will create a new database.
How can you tell which files belong together?
Dismount the Exchange Server’s database, open a command prompt in the database’s directory and check the header information using the ESEUTIL tool. You will find the following information:
Code:
K:\sg1>eseutil /mh "mailbox database.edb"
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: mailbox database.edb
DB Signature: Create time:08/25/2008 22:54:52 Rand:4416518 Computer:
Log Signature: Create time:08/25/2008 22:54:50 Rand:4412688 Computer:
Operation completed successfully in 0.140 seconds.
K:\sg1>Code:
L:\sg1>eseutil /ml e000000001a.log
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.
Signature: Create time:08/25/2008 22:54:50 Rand:4412688 Computer:
1 k:\sg1\Mailbox Database.edb
Signature: Create time:08/25/2008 22:54:52 Rand:4416518 Computer:
Operation completed successfully in 0.60 seconds.
L:\sg1>As you can see both the log file signature and the database signature match, so these files belong together. When you (accidentally) create a new mailbox you will find other information in the database header:
Code:
L:\sg1>eseutil /ml e000000001c.log
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.
Signature: Create time:08/25/2008 22:54:50 Rand:4412688 Computer:
1 k:\sg1\Mailbox Database.edb
Signature: Create time:09/02/2008 07:27:28 Rand:963593 Computer
:
Operation completed successfully in 0.70 seconds.
L:\sg1>Key take-a-way: the checkpoint file determines if log files are replayed and where log file replay will start and therefore what happens during the mounting process.
-----------------------------
As used in Microsoft® Exchange Server , the word recovery must be distinguished from the word restore. Restore is the act of putting database and log files back into place on a server, and recovery is the act of replaying transaction logs into the restored database.
First Can you please share some information like what you means by crash (Is it Exchange Server failure or OS failure?), Your Exchange version (2003, 2007, 2010). DO you have backup for your OS or just the transaction logs ? Does this server running another roles or just the mailbox role?
Here is how to repair an Exchange database that won't start:
1. Make a copy of the database files before you repair them. (cause you never know)
If you're not sure where your database files are, or what they are called, you can find out in Exchange System Manager by accessing the database properties. The Database page lists the paths and names.
2. Verify that you have sufficient disk space to do the repair. As a general rule of thumb, you should have the equivalent of 20% of the database size. If you don't have that much free space on the drive where the database files are, you can use command line switches to redirect the temporary files created during repair to a different drive.
3. Run Eseutil in /P (repair) mode.
The easiest way to do this is to have both database files (.EDB and .STM) in the same directory (which they usually are). If they're in different places, you're going to have to point to the files on the command line.
Eseutil is located in the \exchsrvr\bin directory
Example:
eseutil /p c:\exchsrvr\mdbdata\db1.edb /sd:\exchsrvr\mdbdata\db1.stm /te:\temp.edb
This command line will repair DB1.EDB located on C: along with its matching .STM file located on D: and will put the temporary file on the E: drive.
If your streaming database file (.STM) is not matched to the database file (.EDB) or it has a problem that is blocking repair, you can add the /i switch to the repair command line.
The /i option ignores the signature mismatch error in the check phase. The database and streaming file will receive new signatures in the repair phase.
Repair can take a while--hours. When it finishes, it will leave you with a very detailed log file of what it did called .integ.raw.
Not quit finished yet, there are two more steps to complete.
4. Run Eseutil in /D (defragment) mode.
Repair may leave index and space allocation problems in the database. Along with compacting the physical size of the file, defragmentation rebuilds the indexes and space trees.
To defragment the database, you need space equivalent to 110% the size of the database.
As with repair, you can redirect the temporary file to a different drive if necessary, but this will take considerably longer.
5. Run Isinteg in -fix -test alltests mode.
Note: when you run Eseutil, you can move database files to temporary locations to make repairs. But to run Isinteg, you must put the database back in the location from which it is normally mounted.
At the end of an Isinteg fix run, you will probably see hundreds of warnings. This is normal as Isinteg was originally created as an internal test utility. Just make sure that at the end of a successful Isinteg run, you have zero errors reported. If there is even one error, you should run Isinteg again.
If a few runs of Isinteg do not decrease the error count down to zero, then you should not rely on this database in production. You should move mailboxes from it.
Some say you should expect to spend an hour per gigabyte of data to get through the whole repair process.
It took me 3 hours on a 9gb database though.
6. It is now safe to go home and get a heart attack.
Recovering an Exchange Database
http://technet.microsoft.com/en-us/l...CHG.65%29.aspx
Exchange Server Log File Replay
http://www.simple-talk.com/sysadmin/...g-file-replay/
Restoring Exchange Server 2003 on SBS 2003
http://www.youtube.com/watch?v=KQWrY_3pLRw&feature=related
Exchange 2007 Database Backup and Restore
http://technet.microsoft.com/en-us/library/bb124515%28EXCHG.80%29.aspx
- Soft Recovery A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file copy backup of a database.
- Hard recovery A transaction log replay process that occurs after restoring a database from an online backup.
First Can you please share some information like what you means by crash (Is it Exchange Server failure or OS failure?), Your Exchange version (2003, 2007, 2010). DO you have backup for your OS or just the transaction logs ? Does this server running another roles or just the mailbox role?
Here is how to repair an Exchange database that won't start:
1. Make a copy of the database files before you repair them. (cause you never know)
If you're not sure where your database files are, or what they are called, you can find out in Exchange System Manager by accessing the database properties. The Database page lists the paths and names.
2. Verify that you have sufficient disk space to do the repair. As a general rule of thumb, you should have the equivalent of 20% of the database size. If you don't have that much free space on the drive where the database files are, you can use command line switches to redirect the temporary files created during repair to a different drive.
3. Run Eseutil in /P (repair) mode.
The easiest way to do this is to have both database files (.EDB and .STM) in the same directory (which they usually are). If they're in different places, you're going to have to point to the files on the command line.
Eseutil is located in the \exchsrvr\bin directory
Example:
eseutil /p c:\exchsrvr\mdbdata\db1.edb /sd:\exchsrvr\mdbdata\db1.stm /te:\temp.edb
This command line will repair DB1.EDB located on C: along with its matching .STM file located on D: and will put the temporary file on the E: drive.
If your streaming database file (.STM) is not matched to the database file (.EDB) or it has a problem that is blocking repair, you can add the /i switch to the repair command line.
The /i option ignores the signature mismatch error in the check phase. The database and streaming file will receive new signatures in the repair phase.
Repair can take a while--hours. When it finishes, it will leave you with a very detailed log file of what it did called .integ.raw.
Not quit finished yet, there are two more steps to complete.
4. Run Eseutil in /D (defragment) mode.
Repair may leave index and space allocation problems in the database. Along with compacting the physical size of the file, defragmentation rebuilds the indexes and space trees.
To defragment the database, you need space equivalent to 110% the size of the database.
As with repair, you can redirect the temporary file to a different drive if necessary, but this will take considerably longer.
5. Run Isinteg in -fix -test alltests mode.
Note: when you run Eseutil, you can move database files to temporary locations to make repairs. But to run Isinteg, you must put the database back in the location from which it is normally mounted.
At the end of an Isinteg fix run, you will probably see hundreds of warnings. This is normal as Isinteg was originally created as an internal test utility. Just make sure that at the end of a successful Isinteg run, you have zero errors reported. If there is even one error, you should run Isinteg again.
If a few runs of Isinteg do not decrease the error count down to zero, then you should not rely on this database in production. You should move mailboxes from it.
Some say you should expect to spend an hour per gigabyte of data to get through the whole repair process.
It took me 3 hours on a 9gb database though.
6. It is now safe to go home and get a heart attack.
Recovering an Exchange Database
http://technet.microsoft.com/en-us/l...CHG.65%29.aspx
Exchange Server Log File Replay
http://www.simple-talk.com/sysadmin/...g-file-replay/
Restoring Exchange Server 2003 on SBS 2003
http://www.youtube.com/watch?v=KQWrY_3pLRw&feature=related
Exchange 2007 Database Backup and Restore
http://technet.microsoft.com/en-us/library/bb124515%28EXCHG.80%29.aspx
Comments
Post a Comment