We help IT Professionals succeed at work.

Questions on Exchange databases and transaction logs

bruce_77
bruce_77 asked
on
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?
Comment
Watch Question

Commented:
Hi,

The header of the EDB file contains the name of the current log file and the number of the last transaction written in the database. That permits to Exchange to know which of the transactions in the log have already been written in the base when you unmount and remount a database.

When the database is mounted, Exchange reads the EDB header and tries to open the matching log file. If the log file is missing the EDB can not be mounted and your need to use ESEUTIL to "force" a new header and give up the log.

An inconsistent state will occur if something is wrong during the writting of a transaction in the database. As an example, if the server crashes while Exchange is writting a transaction in the database and before this transaction could be committed then the database is in an inconsistent state (transaction not fully written and committed).

The fact that a transaction is in the log but has not been written at all in the database is not an inconsistent state. The uncommitted transaction will be read from the log and written.commited in the database when Exchange will mount the database.

Have a good day.

Author

Commented:
Thanks....ok, so here's a question. With Exchange 2010, we can restore from a lagged copy of the DB. Let's say, for example, I want to restore data from 13:00 Wednesday 8th December. I follow the instructions here:

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?

Commented:
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.

Author

Commented:
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?

Commented:
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.