Why are the Domino transaction logs not inactivated on the Tivoli Storage Manager Server after running the Data Protection for Domino command 'domdsmc inactivatelog'.
Because there is a single shared transaction log for all logged databases on a Domino server, log files cannot be inactivated (and allowed to expire) until all databases that require that log file for recovery are inactive.
The 'Domdsmc inactivatelog' command queries the database backups on the Tivoli Storage Manager server to determine which log files are required by any active database backup. This command inactivates the log files that are no longer needed (for example, due to a database backup becoming inactive).
First, run the command 'domdsmc inactivatelog' to ensure that all logs have been inactivated.
Next, run the command 'domdsmc query logarchive' to determine if the logs were inactivated from the Tivoli Storage Manager Server. If not, determine the oldest log listed in the 'q logarchive' output still listed as active.
- For example, if the oldest active log was: S0003340.TXN archived on 1/17/2012
- the numerical portion of this name represents the log extent number
Then, trace the 'domdsmc inactivatelog' command. For example:
domdsmc inactivatelog -traceflag=service,api -tracefile=/home/notes/dpdom-ina.trc
Finally, search the trace for any active databases still referencing the oldest log extent by searching for "DB Log Extent : 3340"
- Remove the leading zero's from the log extent number before searching
- Be sure to match the spacing in the search
- More than one database may still need this oldest log
In the example trace, we see:
Domino specific object information:
Relative Name :
<--- /* Database */
Title : email@example.com
Backup Stamp : 01/16/2012 06:43:33
Logged? : Yes
DATA object size : 0.280231936
Database size : 0.280231936
Agent V.R.M.L : 188.8.131.52
ADSM API V.R.L : 5.2.2
Domino Version : 166
Domino Log Type : 1
DB Log Extent : 3340 <--- /* log extent number */
Therefore, in this case, the transaction log backup for S0003340.TXN (and all subsequent logs in the same log sequence) was not inactivated by 'domdsmc inactivatelog' because database backup 'epost\postmast.nsf' which was backed up on 01/16/2012 still needs log extent 3340 (i.e. S0003340.TXN).