Hello,
1. Have you disabled circular logging on the exchange server?
This occurs because the ESE in Exchange has received the command from VERITAS Backup Exec to flush the logs, but did not respond to the command, because it considers the logs as necessary.
This can be a sign of some corruption, especially if no logs at all are being flushed and there's a massive accumulation of logs within Exchange 2000.
This condition can also occur if some other utility has marked a logs as being in use, but in fact they are not. This condition will prevent Exchange from flushing the logs.
To determine which log files have been committed to the Priv.edb, Pub.edb, or Dir.edb file, you can use the Eseutil utility to view the contents of the Edb.chk file. To dump the file to screen, run eseutil /mk edb.chk | more. If you do not run eseutil run from the folder where the Edb.chk file is located, you must provide the full path.
Work Around:
Running a backup with NTBackup will flush the logs. After this initial purging of the logs Backup Exec should operate without the problem reoccurring.
The following utilities can be used to help troubleshoot problems with Exchange 2000 or 5.5
Utilities for troubleshooting Exchange 5.5 or 2000 server
Error.exe - Converts store, MAPI, and database error coded to error message strings
Filever.exe - Displays the versions of .EXE and .DLL files
Isinteg.exe - Checks the integrity of the Information Store
Eseutil.exe - Offline database consistency checker
Mdbvue32.exe - Displays information about information stores and .PST and .OST files
Microsoft Knowledge Base Q182961: Using Eseutil to determine which logs have been committed.
If one or more Mailbox or Public folder stores are backed up from within a storage group but not all stores in that group are selected, then the logs for that group are not going to be flushed on either a Full or Incremental backup job.
In Exchange 2000, Storage Groups are a logical grouping of Information Stores (either Mailbox or Public folder) which share a common data path. Because of this, every store in a particular Storage Group shares the same set of log files. When a particular Information Store is selected for backup from in a Storage Group, but do not select all of the stores for that group, it is not possible for the logs to be purged (truncated) because the log files still contain transactions that may be needed to recover one of the other stores for that group which has not been backed up. This will be true in the case of either a Full or Incremental backup job, which are both expected to flush any committed logs. A Differential or copy job will never flush the log files and are not expected to.
NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered"and would be moved to"answered questions" pool.
