A different problem than the one a few weeks gone by.
DB backup finished, leaving log usage at 0.1 % used. No sessions running, so I
started an expiration process. After 30 minutes, this is what I saw:
tsm: GLASSHOUSE>q pr
Process Process Description Status
Number
-------- --------------------
-------------------------------------------------
873 Backup Storage Pool Primary Pool SERVDISKPOOL, Copy Pool
OFFSITEPOOL,
Files Backed Up: 43179, Bytes Backed Up:
145,892,524,032, Unreadable Files: 0,
Unreadable
Bytes: 0. Current Physical File (bytes):
2,147,143,680 Current output volume:
C31199.
874 Backup Storage Pool Primary Pool SERVDISKPOOL, Copy Pool
OFFSITEPOOL,
Files Backed Up: 12475, Bytes Backed Up:
137,712,177,152, Unreadable Files: 0,
Unreadable
Bytes: 0. Current Physical File (bytes):
1,384,419,328 Current output volume:
C32082.
875 Backup Storage Pool Primary Pool SERVDISKPOOL, Copy Pool
OFFSITEPOOL,
Files Backed Up: 48409, Bytes Backed Up:
160,964,038,656, Unreadable Files: 0,
Unreadable
Bytes: 0. Current Physical File (bytes):
3,980,283,904 Current output volume:
C32083.
878 Expiration Examined 207408 objects, deleting 207376
backup
objects, 0 archive objects, 0 DB backup
volumes,
0 recovery plan files; 0 errors
encountered.
tsm: GLASSHOUSE>q sess
Sess Comm. Sess Wait Bytes Bytes Sess
Platform Client Name
Number Method State Time Sent Recvd Type
------- ------ ------ ------ ------- ------- -----
-------- -------------------
388,208 Tcp/Ip Run 0 S 63.7 M 150 Admin
Linux86 SERVERGRAPH
442,970 Tcp/Ip Run 0 S 134.3 K 2.2 K Admin
AIX FRED
443,069 Tcp/Ip IdleW 8.9 M 38.4 K 1.2 K Admin
AIX AILIAS
445,050 Tcp/Ip IdleW 15 S 4.3 K 405 Node
SUN SOL- JON
ARIS
tsm: GLASSHOUSE>q log
Available Assigned Maximum Maximum Page Total
Used Pct Max.
Space Capacity Extension Reduction Size Usable
Pages Util Pct
(MB) (MB) (MB) (MB) (bytes) Pages
Util
--------- -------- --------- --------- ------- ---------
--------- ----- -----
12,788 12,788 0 6,996 4,096 3,273,216
1,482,016 45.3 92.1
I cancelled the expiration and the runaway log stopped running.
My thinking is that the expiration is feverishly writing its transaction to the
log. Since there are no other sessions accessing the log, there are no
interrupts to trigger a commit. So the log keeps filling, triggering and
retriggering DB backups. If my thinking is correct, this is a design feature
in the pre-DB2 b-tree DB, not easily remedied. Just something to constantly
monitor.
Anybody have any thoughts on this?
Fred Johanson
TSM Administrator
University of Chicago
773-702-8464
