bruce_77
asked on
Questions on Exchange databases and transaction logs
Hi
Environment is Exchange 2007
I understand that when a change occurs within, this change is written to the server memory and also the transaction log....once the server has some time/resources, this change is then actually written into the database using the info in the memory. Transaction logs are only used in case the server crashes, for instance.
Let's say at 10.00, a user deletes an email. This is written to memory/transaction logs, but at 10.01 the server crashes.
When the server comes back up again, it will need to replay the transaction log pertaining to that change otherwise it will be in Dirty Shutdown/inconsistent state. But I don't understand this, what is the DB in an inconsistent state in relation to?
Again, another example is when Backup Exec takes a backup of the database and transaction logs. If we restore the EDB file only, then it won't mount, we need to transaction logs too....but why?
Environment is Exchange 2007
I understand that when a change occurs within, this change is written to the server memory and also the transaction log....once the server has some time/resources, this change is then actually written into the database using the info in the memory. Transaction logs are only used in case the server crashes, for instance.
Let's say at 10.00, a user deletes an email. This is written to memory/transaction logs, but at 10.01 the server crashes.
When the server comes back up again, it will need to replay the transaction log pertaining to that change otherwise it will be in Dirty Shutdown/inconsistent state. But I don't understand this, what is the DB in an inconsistent state in relation to?
Again, another example is when Backup Exec takes a backup of the database and transaction logs. If we restore the EDB file only, then it won't mount, we need to transaction logs too....but why?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi again,
Of course ESEUTIL will not commit any transaction that can not be entirely read from the logs.
So if you delete transaction logs created after 13:00 and the last remaining one contains a part of a transaction spread accross log files that you have deleted, then this transaction will not be written at all in the database.
So don't worry, Your database will always be consistent.
Have a good day.
Of course ESEUTIL will not commit any transaction that can not be entirely read from the logs.
So if you delete transaction logs created after 13:00 and the last remaining one contains a part of a transaction spread accross log files that you have deleted, then this transaction will not be written at all in the database.
So don't worry, Your database will always be consistent.
Have a good day.
ASKER
So what's the difference between an Exchange 2010 lag copy database that only has log files up to 13.00 (which supposedly mounts fine) and an Exchange 2007 database from a crashed server that has lost files after 13.00?
In both cases, the DB's are in dirty shutdown, but in 2010 replaying the files up to 13.00 makes it clean shut down, but with 2007 it may drop an error saying more logs required?
In both cases, the DB's are in dirty shutdown, but in 2010 replaying the files up to 13.00 makes it clean shut down, but with 2007 it may drop an error saying more logs required?
Hi again,
The difference is not structural. The EDB files are the same, the log files are the same.
The difference is that Exchange 2010 contains a specific way of processing a lagged copy. ESEUtil permits you to replay a part of the log files and give up the missing ones and force a clean state of the lagged DB to allow you to mount it. That process is not allowed on normal DB in Exchange 2010/2007.
For normal DB ESEUTIL does not allow you to replay a part of the log files. If some log files are missing you need to force a clean state saying ESEUTIL to force the header in the EDB file and give up the whole log replay. On a normal DB there is only 2 cases :
1) you have all the log files and then you can ask ESEUTIL to replay the log and lead the DB to a clean state with all the data recovered.
2) you're missing some log files and then you can ask ESEUTIL to give up with log replay and force a clean state without any log file replayed and accept data lose.
If your question is "why there is no lagged db in Exchange 2007 if DB files are almost the same" the answer is probably that Microsoft had enough work to do with the big changes between 2003 and 2007 and had no time to work on a lagged DB solution.
By the way, the lagged copy is a functionnality associated with the fact that backup-less solution are now supported in Exchange 2010.
In Exchange 2007 there was no backup-less solution and then lagged copy was not an important functionnality.
The difference is not structural. The EDB files are the same, the log files are the same.
The difference is that Exchange 2010 contains a specific way of processing a lagged copy. ESEUtil permits you to replay a part of the log files and give up the missing ones and force a clean state of the lagged DB to allow you to mount it. That process is not allowed on normal DB in Exchange 2010/2007.
For normal DB ESEUTIL does not allow you to replay a part of the log files. If some log files are missing you need to force a clean state saying ESEUTIL to force the header in the EDB file and give up the whole log replay. On a normal DB there is only 2 cases :
1) you have all the log files and then you can ask ESEUTIL to replay the log and lead the DB to a clean state with all the data recovered.
2) you're missing some log files and then you can ask ESEUTIL to give up with log replay and force a clean state without any log file replayed and accept data lose.
If your question is "why there is no lagged db in Exchange 2007 if DB files are almost the same" the answer is probably that Microsoft had enough work to do with the big changes between 2003 and 2007 and had no time to work on a lagged DB solution.
By the way, the lagged copy is a functionnality associated with the fact that backup-less solution are now supported in Exchange 2010.
In Exchange 2007 there was no backup-less solution and then lagged copy was not an important functionnality.
ASKER
http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/eliminating-traditional-backups-using-native-exchange-2010-functionality-part4.html
As part of the instructions, I delete any transaction logs from 13:00 onwards. The article says I need to run eseutil /r to replay the remaining logs files to the DB and bring it to consistent state. But isn't there a chance that there was a transaction spread across some logs that finished/ closed at 13.01...in which case, I would need the log file from 13.01 to bring the DB to a consistent state?