Transaction log full

[Jcage]

Our transaction log usually fills up to between 30 and 40% full between database backups. Early this morning I was called because the log had become 92% full. It has NEVER been tha full and nothing has changed as far as backups and clients go. What could have caused it to go so high.

 

[toxy13]

many many TSM requests (sql commands, queries ...) can fill your tsm log, use your actlog to find out whats happend!

 

[Jcage]

many many TSM requests (sql commands, queries ...) can fill your tsm log, use your actlog to find out whats happend!

I've been going through the log from the night before and comparing it. I don't see any huge differences.

 

[Jcage]

Our database is 85% full, would that have any effect on the log ?

 

[toxy13]

Our database is 85% full, would that have any effect on the log ?

No, it don't.

 

[toxy13]

Have you changed the logmode to rollforward/normal?
Or did you backup have many many small files to backup up?

 

[Jcage]

Have you changed the logmode to rollforward/normal?
Or did you backup have many many small files to backup up?

There were a number of backups going on. We have 100's of unix and windows servers attached to TSM but there was nothing unusual and the logmode wasn't changed.

 

[moon-buddy]

When was the last full DB backup? If the full DB backup did not happen, then you will see the logs fill up.

 

[Jcage]

When was the last full DB backup? If the full DB backup did not happen, then you will see the logs fill up.

We have a full database backup run every afternoon. The only unusual activity I noticed was space reclamation running for about 2 hours longer than it should have. Would this impact the log ?

 

[toxy13]

We have a full database backup run every afternoon. The only unusual activity I noticed was space reclamation running for about 2 hours longer than it should have. Would this impact the log ?

Yes it would, the server writes all definitions for the reclaimed files first to the logfile - after a DB backup the logfile will cleared.

Did you have the problems only one times?

 

[Jcage]

Yes it would, the server writes all definitions for the reclaimed files first to the logfile - after a DB backup the logfile will cleared.

Did you have the problems only one times?

Yeah only the one time however I did lower the space reclamation threshold last night which would have caused it to run longer. I guess that could be it ?

 

[toxy13]

I did lower the space reclamation threshold last night

I think, that was your problem - the lower reclaim will cause more logfile entries!

 

[Jcage]

I think, that was your problem - the lower reclaim will cause more logfile entries!

Thanks for the help !

 

[toxy13]

Thanks for the help !

fine ;-)

now have a nice weekend, don't think about logfiles ^^

 

[moon-buddy]

May I suggest increasing your log file size or enabling log extension so you won't be jumping around in the middle of the night?

 

[ypcat]

It is also possible for certain TDP's to pin the log. In order to find out which session is having issues you can run the undocumented command:

show logpinned.

This will show you exactly what is pinning the log.

 

[Jcage]

I found out exactly what had happened. On any given night we expire between 200,000 and 300,000 objects. The night the log filled up we expired 1.5 million objects.