high log file usage during expir

[JonRoenick]

Should my log file climb to 95% by the time Expiration is finishing up? No other processes run during the 5 hours that Expiration runs, so i'm kind of worried.

 

[JeanSeb]

How big is your log, and how much objects are being expired ?

I would understand filling up a small to medium log, but not a 12 GB one...

 

[JonRoenick]

5GB log, about 5.5 million objects scanned, 510k expired.

 

[moon-buddy]

Maybe normal as I have seen my log (TSM version 5.4.3) grow during expiration. Sometimes a DB Incremental backup is triggered.

If you are worried, you may want to increase the log size if DB backup trigger is not enabled (which you should).

 

[JeanSeb]

I have recently filled up 11 GB logs in 7-8 hours during expiration after a major retention rules overhaul, I don't necessarily see a problem there. As for a dbbackup trigger, like moon-buddy said, you do not want to be running in rollforward mode without one, trust me.

 

[JonRoenick]

I'm pretty sure i just normal mode, not rollforward. I use TSM Manager 4.6 to do 99% of the things i do. I created a db backup trigger in TSM Manager, however when i do q status i still see that Database Backup Trigger: Disabled. I don't see any "enable" option in help either. What am i missing?

 

[dms19]

h define dbbackuptrigger

 

[JonRoenick]

Thanks. Says that it would only work if i use rollforward mode. Consultants set this up about 3 years ago. Not sure if i should change this without finding out their reasoning.

 

[JonRoenick]

Now that i think about, it does bring up a question: Since i am in normal mode the recovery log keeps only uncommitted transactions--right? Is there a way to manually commit them that i could script out and run every hour or so? Otherwise i'm just afraid the log will fill up again before my morning script has a chance to backup the db again.

 

[JeanSeb]

Rollforward: You can restore the TSM database up to the point of failure if it ever fails. (using log replay)
Normal: You can only restore your TSM database to the last full DB backup.

If you run in rollforward mode, the recovery get used to write transaction, and it will at some point fills up . That is where you want to have a dbbackuptrigger set so it expend itself automatically. If not your logs fill up, and you can't restart TSM unless you restore your DB.

 

[JonRoenick]

http://publib.boulder.ibm.com/tividd/td/SMAS4N/GC35-0315-01/en_US/HTML/a454g186.htm#HDRDBADV

I was going by the link above. The environment here is mostly suitable for using the Normal recovery mode. But i am still not sure if i can commit transactions to empty the log manually.... or is this a process that just has to happen overtime as the database has the resources to do accomplish the transactions (obviously not during expiration)?

 

[JeanSeb]

As far as I know, any transaction in the recovery log is uncommitted, and only db backups can commit transactions to the database and empty the recovery log.

 

[JonRoenick]

That is what i can't wrap my head around. The consultants told me that in past but i told them that the log empties itself! Here i have the messages since this afternoon when the log reached 94% and then how it started to shrink itself when i canceled expiration:

(Note: I have removed all the Session messages)
-----------------------
5/18/2010 3:00:20 PM ANR2997W The server log is 94 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:00:48 PM ANR2017I Administrator JROENICK issued command: select avail_space_mb,capacity_mb,max_extension_mb,max_reduction_mb,pct_utilized,max_pct_utilized,cache_hit_pct,last_backup_date,usable_pages,used_pages,num_backup_incr,backup_chg_mb from db
5/18/2010 3:00:49 PM ANR2017I Administrator JROENICK issued command: select fullpct from dbspacetrigger
5/18/2010 3:00:49 PM ANR2034E SELECT: No match found using this criteria.
5/18/2010 3:00:50 PM ANR2017I Administrator JROENICK issued command: select avail_space_mb,capacity_mb,max_extension_mb,max_reduction_mb,pct_utilized,max_pct_utilized,consumption_mb,consumption_date from log
5/18/2010 3:00:51 PM ANR2017I Administrator JROENICK issued command: select fullpct from logspacetrigger
5/18/2010 3:00:51 PM ANR2034E SELECT: No match found using this criteria.
5/18/2010 3:00:52 PM ANR2017I Administrator JROENICK issued command: select logmode from status
5/18/2010 3:01:10 PM ANR2017I Administrator JROENICK issued command: CANCEL EXPIRATION
5/18/2010 3:01:10 PM ANR4389I Expiration process cancelled.
5/18/2010 3:01:10 PM ANR2369I Database backup volume and recovery plan file expiration starting under process 507.
5/18/2010 3:01:13 PM ANR0937I Expiration process 507 is ending.
5/18/2010 3:01:13 PM ANR0406I Session 46892 started for node CHCTRACKIT2 (WinNT) (Tcp/Ip 10.1.100.26(4996)).
5/18/2010 3:01:13 PM ANR0403I Session 46892 ended for node CHCTRACKIT2 (WinNT).
5/18/2010 3:01:24 PM ANR2997W The server log is 94 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:02:29 PM ANR2997W The server log is 93 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:03:30 PM ANR2997W The server log is 93 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:04:20 PM ANR0406I Session 46907 started for node CHCPPDB (HPUX) (Tcp/Ip chcppdb.hospital.com(51519)).
5/18/2010 3:04:20 PM ANR0403I Session 46907 ended for node CHCPPDB (HPUX).
5/18/2010 3:04:31 PM ANR2997W The server log is 91 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:05:34 PM ANR2997W The server log is 91 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:06:35 PM ANR2997W The server log is 90 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:07:36 PM ANR2997W The server log is 90 percent full. The server will delay transactions by 30 milliseconds.
5/18/2010 3:08:38 PM ANR2997W The server log is 87 percent full. The server will delay transactions by 3 milliseconds.
5/18/2010 3:09:38 PM ANR2997W The server log is 86 percent full. The server will delay transactions by 3 milliseconds.
5/18/2010 3:10:39 PM ANR2997W The server log is 85 percent full. The server will delay transactions by 3 milliseconds.
5/18/2010 3:11:21 PM ANR0813I Inventory file expiration process 507 canceled prior to completion: examined 5251360 objects, deleting 470663 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered.
5/18/2010 3:11:21 PM ANR0987I Process 507 for EXPIRE INVENTORY running in the BACKGROUND processed 470663 items with a completion state of SUCCESS at 15:15:13.
5/18/2010 3:12:18 PM ANR2017I Administrator JROENICK issued command: select pct_utilized from log
5/18/2010 3:12:18 PM ANR2017I Administrator JROENICK issued command: select stgpool_name,pct_migr,migr_running,pct_utilized from stgpools p,devclasses r where (r.devclass_name=p.devclass) and (r.devtype='FILE' or p.devclass='DISK')
5/18/2010 3:15:03 PM ANR2997W The server log is 84 percent full. The server will delay transactions by 3 milliseconds.
5/18/2010 3:15:46 PM ANR2017I Administrator JROENICK issued command: select avail_space_mb,capacity_mb,max_extension_mb,max_reduction_mb,pct_utilized,max_pct_utilized,consumption_mb,consumption_date from log
---------------------

Again, the log was committing transactions and i only run db backup in the morning after migrating the storage pools to disk pools.

 

[BBB]

If your log is in normal mode and is filling up, you probably have something pinning the log, look for a long running client session or admin process.

No you can't manually commit things to reduce log usage.

Check out the log pinning and you might also need to increase your log size.