All of the PROCESSes listed write information to the log. Expiration is
the most DB intensive certainly.
What kind of log are you using, "Normal" or "Roll Forward"?
The SERVERGRAPH session is just an information gathering session, like
any user logged on. The TSM server only received 150 bytes from it.
It is not a client backing up data, it is an admin (Sess Type Admin). I
do not think that is related to your log growth in any significant way.
Check your performance tuning in general
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Fred Johanson
Sent: Monday, November 23, 2009 3:27 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Log pinned
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
IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security numbers,
account numbers, or personal identification numbers. Delivery, and or timely
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends
that you do not send time sensitive
or action-oriented messages to us via electronic mail.
This message is intended for the addressee only and may contain privileged or
confidential information. Unless you are the intended recipient, you may not
use, copy or disclose to anyone any information contained in this message. If
you have received this message in error, please notify the author by replying
to this message and then kindly delete the message. Thank you.
|
