Checking which transaction log has been committed - urgent


We are running Exchange 2007 SP1 in SCC A/A/P. We have one store per SG.

One of our stores' transaction logs were being generated quickly today. Last night's backups worked fine, so no issue there. So someone moved the oldest transaction logs (via explorer) to another drive to ensure the store didn't dismount.

Whatever caused the log generation has also stopped, so we are ok in that respect. However, the problem is that if one of the logs that was not moved hasn't been commited yet, we will have problems.

Is there anyway to check which logs have been committed on a live store? I know there is eseutil /mk, but that only works when the store is dismounted.

Secondly, if I was to run a backup now to flush the logs altogether, would there be an issue because some logs are in one place and the rest in another?

Any help appreciated!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Exchange doesn't "commit" log files unless you are using log shipping technology (which you are not)

Exchange actually write simultaneously to the DB and to the log file.

The log files are needed in case of a "dirty shutdown"  for recovery so if you take a full backup now you would be safe

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
john2188Author Commented:
Hi Akhater

I was under the impression that Exchange will write information to the logs first and these will be commited to the database once it is less busy, and you can use the CHK file to find out which log file has been commited?
Check this

Normal Logging

The following steps illustrate the process of "normal logging" where data is written to transaction log files:

   1. The user sends a message.
   2. MAPI calls the information store to tell it that the user is sending the message.
   3. The information store starts a transaction in the database engine and makes the corresponding changes to the data.
   4. The database engine records the transaction in memory by dirtying a new page in memory.
   5. Simultaneously, the database engine secures the transaction in the transaction log file and creates a log record. When the database engine reaches the end of a transaction log file, it rolls over and creates a new log file in sequence.
   6. The database engine writes the dirty page to the database file on the hard disk.
   7. The checkpoint file is updated.
sorry I had to leave, just to make sure we are the same wave length. What I meant is that changes are written to "in memory" db & log simultaneously & then writted to the edb file from memory & not from log files.
So log files are used only in the case of crash or log shipping technology.
Dismounting mounting will insure that all memory is committed, backing up would also put you in safe state.
If the logs were moved a few minutes/hours ago then chances are these changes were also comitted.
john2188Author Commented:
Thanks, I actually never knew that!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.