Hi Wanda,

We run v6.2.3 and have had an open PMR for months now about performance issues, 
mostly concerning automatic reorganization, but that lead to our questioning 
whether it was causing other issues. As of now, we are being told by TSM 
developers that we need to adjust the DB2 buffer pools to give us better 
reorganization performance, which in turn, they say, should also give us better 
performance with our other admin tasks, but we are being told by the DB2 
developers that they recommend that we stay with the Automatic settings for the 
buffer pools, or take our chances with changing them ourselves. Neither team 
seems to be able to help us with what our optimal settings should be.

As you can imagine we are not in a happy place at the moment. I would 
definitely open a PMR. There are known issues about administrative task 
performance.

Best regards,
Pam

Pam Pagnotta
Sr. Systems Engineer 
Energy Enterprise Solutions (EES), LLC 
Supporting IM-621.1, Enterprise Service Center East
Contractor to the U.S. Department of Energy  
Office: 301-903-5508  
Email: pam.pagnotta AT hq.doe DOT gov 
Location: USA (EST/EDT) 



----------------------------------------------------------
Date:    Sat, 26 Nov 2011 19:23:53 +0000
From:    "Prather, Wanda" <wPrather AT ICFI DOT COM>
Subject: 6.2.2 Backup Stgpool Performance issue?

OK, here's another oddity.
Customer upgraded from 5.5 on Win2K3,  to 6.2.2 on Win2K8, 32G Ram.
Tapes are 3 IBM LTO4's in a TS3310.

Everything works great, except we appear to have a problem with BACKUP STGP= 
OOL running very slowly, on occasion, going tape to tape.

Other tape to tape processes (reclaim, for example) work fine.  BACKUP STGP= 
OOL running from diskpool to tape works fine.  But on some days, BACKUP STG= 
POOL running from tape to tape appears to just hang.  The output from Q PRO= C 
below shows it hanging on the same "current physical file" of 122GB, for = over 
12 hours, until we had to cancel it.

There were no other tape processes running, nor was expiration.  Over the 1=
2 hours there were occasional small client backups, but nothing intensive. =  
Sometimes after 3-4 hours, the process will "break free" and pick up speed=  
again, other days it won't.  Dedup not turned on.  At first I suspected a = bad 
LTO cartridge or a firmware problem, but we've updated the firmware, an= d this 
occurs on so many different cartridges that we've ruled that out.  I= 'm 
stumped.

I've calculated MB/sec throughput for every combination of disk-to-tape and=  
tape-to-tape processes and we are getting decent throughput, even on BACKU= P 
STGPOOL, except for these occasional hangups.

Anybody seen anything like this?  Otherwise I'm thinking it's time for a PM= R 
call and a trace...

>q proc

Process     Process Description      Status
  Number
--------     --------------------     -------------------------------------=
------------
      64     Backup Storage Pool      Primary Pool ORA-LTO4POOL, Copy Pool
                                       LTO4VAULT, Files Backed Up: 322963, = 
Bytes Backed
                                       Up: 2,178,940,551,897, Unreadable Fi=
les: 0,
                                      Unreadable Bytes: 0. Current Physical=  
File
                                       (bytes): 122,700,012,064 Current inp= ut 
volume:
                                       A00575L4. Current output volume(s): = 
A00578L4.





Wanda Prather  |  Senior Technical Specialist  | wprather AT icfi DOT 
com<mailto:w= prather AT icfi DOT com>  |  www.icf.com<http://www.icf.com> ICF 
International  | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410=
.539.1135 (o)
Connect with us on social media<http://www.icfi.com/social>