Well, in this situation, we discovered the dreaded "retrying 150GB file backup" as the problem. Ignoring the fact that the 150GB file is names as a "log" of some kind, once we added CHANGINGRETRIES 0, the backups have dropped in both time and size, no longer causing the pinning problem.
I don't have the authority to tell the app owner to look into why their "log" is 150GB! We just send them the bill ;---) Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services [email protected] - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html From: "Loon, EJ van - SPLXM" <[email protected]> To: [email protected] Date: 03/17/2010 09:29 AM Subject: Re: [ADSM-L] Long running backup pinning log Sent by: "ADSM: Dist Stor Manager" <[email protected]> Hi Zoltan! We were experiencing a lot of logpinning about a month ago which all seem related to a handful of clients. Investigation showed that nearly all of them were running with a half-duplex connection instead of a full duplex fixed rate. As soon as this was fixed by the client owner, backups were performing as expected and logpinning was gone too. Just an thought... Kind regards, Eric van Loon KLM Royal Dutch Airlines -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Zoltan Forray/AC/VCU Sent: maandag 8 maart 2010 15:53 To: [email protected] Subject: Re: Long running backup pinning log Thanks for the heads-up. Unfortunately, from reading the APAR, this box does not seem to have the symptoms. There is no significant gap in backing up each component of systemstate, unless this is hidden because of QUIET. We have changed this to VERBOSE to get more details on where it is slogging. >From what I see in the dsmsched log, this is what the last backup that finished (todays is still running), says: 01:43 - Backup started 01:47 - Systemstate backup finished 12:21 - d$ drive backup finished 12:25 - c$ drive backup finished Total objects examined - 72,395 Total objects backed up - 1,725 Total data backed-up (to paraphase) - 93.82Gb I did note the "Object compressed by" is 87%. Which brings me to the question - Is the "total amount backed up" after compression? My guess it lots of time spent in compression (IBM - how about some compression algorithm controls (low - medium - high). Haven't ruled out "retries" - will see when verbose is on. I don't see journaling making that much of a difference. The server has 2GB RAM of which 900M was free when I checked it this morning, so it doesn't seem to be constrained. The backup is currently running and the dsm service was using 10-20% CPU. Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services [email protected] - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html From: Andrew Raibeck <[email protected]> To: [email protected] Date: 03/05/2010 04:32 PM Subject: Re: [ADSM-L] Long running backup pinning log Sent by: "ADSM: Dist Stor Manager" <[email protected]> Hi Zoltan, Is the long-running backup working on system state? I haven't found a direct cause --> effect relationship to client APAR IC63094, but take a look at that APAR and see if, after applying the fix, the problem you are seeing goes away. I should mention to all: IC63094 describes a problem with long-running system state backups. This APAR may be of interest to you. Best regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Product Development Level 3 Team Lead Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus Internet e-mail: [email protected] IBM Tivoli Storage Manager support web page: http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_ Storage_Manager The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" <[email protected]> wrote on 2010-03-05 16:26:01: > [image removed] > > Long running backup pinning log > > Zoltan Forray/AC/VCU > > to: > > ADSM-L > > 2010-03-05 16:26 > > Sent by: > > "ADSM: Dist Stor Manager" <[email protected]> > > Please respond to "ADSM: Dist Stor Manager" > > I recently started having issues with my log going over 80% (5.5.3). Doing > a "show logpinned" usually points to a long (18-hours) running backup > session for one particular node. > > This is starting to happen more and more frequently. > > Once I kill the session, the log utilization drops to almost nothing since > there has been a DB backup run earlier in the day. > > Any suggestions on how to handle this besides killing the session? The > node is a standard 2K3 box using the 6.1.2.0 client. It is just a very > slow/busy box. The long backups (times vary from 11-19 hours) often dump > 120GB of data. > Zoltan Forray > TSM Software & Hardware Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > [email protected] - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://infosecurity.vcu.edu/phishing.html ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **********************************************************************
