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?

So while the database is mounted it is ALWAYS in a dirty/inconsistent state because its open to accept transactions. When a backup is taken the database is backed up in a dirty state and along with that backup the current set of logs needed to bring that database into a consistent/clean state are copied as well. When the backup is restores the logs that accompany the backup MUST be played into the database so that is can be mounted and accept additional data flow Troy Werelius www.Lucid8.com Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope

Hi Troy Still not getting it, sorry :) Back to my example: 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? In relation to this transaction (user deleting an email), at what point is the DB dirty/inconsistent, and how does replaying that log file after the server crashes make it clean? This is the bit I don't understand - ok, so the user deletes an email, Exchange doesn't write this to the DB straight away but uses write-ahead logging to write this transaction to the log/memory. When the server comes up after the crash surely it would just come back up with that email still there? Why is it in an inconsistent state? Since the info hasn't been written to the DB that the email has been deleted, why is the email not deleted (if that makes sense)?

IF email is deleted at 10:00 and server crashed at 10:01. then that transaction would have already been written to the DB. When the server crashed, it would have been in a dirty shutdown, it was not shut down gracefully (unmount the store). It's in a dirty shutdown when the it has nt been shutdown gracefully. Sukh

Yes Sukh has it correct, the DB is ALWAYS in an inconsistent state when its ONLINE and only way to make it consistent is to do a graceful dismount of the database which would then commit any uncommitted logs. Since a BACKUP is taken while the DB is ONLINE the backup itself is inconsistent as well so when a recovery of that database is done the logs must be rolled up to make it consistent and only then can it be mounted. NOTE: If the logs are not available then you must to an eseutil /P to repair the DB but that is not recommended unless you have no other choice and after that you should also run eseutil /D and isinteg the DB as well. Then as soon as possible I would recommend that you create a new DB and migrate all the users to it and then retire the old DB that you were forced to run a /p onTroy Werelius www.Lucid8.com Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope

Thanks - but when you say consistent, consistent with what? Does anyone know the answer to this question: 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? In relation to this transaction (user deleting an email), at what point is the DB dirty/inconsistent, and how does replaying that log file after the server crashes make it clean? This is the bit I don't understand - ok, so the user deletes an email, Exchange doesn't write this to the DB straight away but uses write-ahead logging to write this transaction to the log/memory. When the server comes up after the crash surely it would just come back up with that email still there? Why is it in an inconsistent state? Since the info hasn't been written to the DB that the email has been deleted, why is the email not deleted (if that makes sense)?

ok putting all of the transaction questions aside for now. 1. When an Exchange database is mounted its ALWAYS in an inconsistent/dirty state, i.e. the database is OPEN Even if its sitting there and absolutley NO DATA is flowing and NO USERS are connected its DIRTY/INCONSISTENT because its OPEN 2. When a database is gracefully/properly dismounted its CLOSED aka consistentTroy Werelius www.Lucid8.com Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope

If the log is open and that delete transaction is in that current open log then exch crashes. It would not have applied that transaction. Exch knows it applied the last log before it crashed. So it's in a dirty shutdown. Now to get it in a clean shutdown, Exch knows that log it need. You then apply that log to Exch and it becomes clean again.Sukh

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?

complete transaction will in one log, they wont be split across to logs. For e.g, deleting a single email, transaction wont be half in lone log and another half in the other. Doesnt work like that.Sukh

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?

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? 2 different scenarios here, 2010 lag copied and 2007. Depending on the state exch is in, and what exch needs, it will ask for the logs file, 2007/2010 are similar in terms of transaction logs, but the lagged copies are different in that that they are not applied straight away. So for 13:00 lagged copy, it will have all the logs it needs, depending on what the lag time is, it wont want anything after that.Sukh

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? 2 different scenarios here, 2010 lag copied and 2007. Depending on the state exch is in, and what exch needs, it will ask for the logs file, 2007/2010 are similar in terms of transaction logs, but the lagged copies are different in that that they are not applied straight away. So for 13:00 lagged copy, it will have all the logs it needs, depending on what the lag time is, it wont want anything after that.Sukh