Checking which transaction log has been committed - urgent

Hi

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!
john2188Asked:
Who is Participating?
 
AkhaterConnect With a Mentor Commented:
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
0
 
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?
0
 
AkhaterCommented:
Check this http://support.microsoft.com/kb/271987

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.
0
 
AkhaterCommented:
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.
0
 
john2188Author Commented:
Thanks, I actually never knew that!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.