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: [email protected] Location: USA (EST/EDT) ---------------------------------------------------------- Date: Sat, 26 Nov 2011 19:23:53 +0000 From: "Prather, Wanda" <[email protected]> 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 | [email protected]<mailto:w= [email protected]> | 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>
