I thought I saw a thread not too long ago about a problem with DBBackups running longer if you had DBCOPY volumes...? I was trying to search for the thread, but didn't see anything... Should looked at Tivoli knowledge base first...here's the APAR IC34146 (amongst others): APAR= IC34146 SER= PF PERF TSM SERVER DATABASE BACKUP MAY PERFORM SLOW IF DATABASE MIRRORS ARE DEFINED
Status: CLOSED Closed: 07/15/02 Apar Information: RCOMP= 5698ISMSV TSM SERVER 510 RREL= R51A FCOMP= 5698ISMSV TSM SERVER 510 PFREL= F999 TREL= T SRLS: NONE Return Codes: Applicable Component Level/SU: R51A PSY UP R51H PSY UP R51S PSY UP R51W PSY UP Error Description: While in the process of working through some database recovery procedures the customer noticed that their TSM database backups ran faster than they had seen them run in the past. At the end of their recovery procedure they added their db mirrors back to their server and noticed the TSM database backups slow to the run times they were seeing before. Analysis of this scenario by development found that the alternating reading of db volumes during a TSM server database backup when mirrored volumes were in place was keeping read ahead function from being exploited as it was without mirrored volumes in place. An alternate db read design needs to be developed to avoid this processing delay in applicable environments and ensure TSM server db backup processing performs the same whether mirrored volumes exist or not. Local Fix: Problem Summary: **************************************************************** * USERS AFFECTED: All users with mirrored log or data base * * volumes. * **************************************************************** * PROBLEM DESCRIPTION: Backup data base performance is poor. * **************************************************************** * RECOMMENDATION: * **************************************************************** The algorithm TSM Server used to alternate between log and data base mirrors was not optimized for sequential access. Temporary Fix: Comments: MODULES/MACROS: LVMREAD ICBACK Problem Conclusion: During backup of the database, the algorithm TSM server uses to alternate between log and database mirrors is optimized for sequential access. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU]On Behalf Of Alex Paschal Sent: Thursday, October 17, 2002 5:14 PM To: [EMAIL PROTECTED] Subject: Re: Slow DB backups. In addition to your dbbackup rate, have you taken a look at your vmstat for your memory and CPU params? Initially, you can look for paging, CPU%, and CPU WaitIO%. Are any of those pegged? That could also get you started zeroing in on the problem. Alex Paschal Storage Administrator Freightliner, LLC (503) 745-6850 phone/vmail -----Original Message----- From: Seay, Paul [mailto:seay_pd@;NAPTHEON.COM] Sent: Wednesday, October 16, 2002 11:08 PM To: [EMAIL PROTECTED] Subject: Re: Slow DB backups. Did you recently have a database expansion? Are you using RAW volumes or a JFS for the database? The layout of the above could really make a difference. You can all of a sudden get horrible performance. What you need to do is look at all of the database backup messages and see if the rate of a full or dbs type dump is consistent throughout, pages per 30 seconds. If you notice a steep drop off, that is your problem. Part of the database is on a configuration that is bad. We had this situation. There is also another little scenario that can really bust you if you do not realize what you are doing. If you increase the DB buffer pool and it causes the computational working set on an AIX TSM server to get larger than the default of 20 percent of memory you will page your butt off. This is easy to fix. On AIX, just use VMTUNE to set the maxperm (-P) and minperm (-p) parameters like Mark says. 40 and 10 are a good start. The other thing you can do that we found really speed up the backups was raising the maxfree and max page read ahead. Remember though, all of these parameters apply to JFS buffers. If you are using any JFS at all the maxperm and minperm could be factors. I saw the same things you did once my TSM server grew up. With Mark's suggestions mine purrs like a kitten now. What is your hardware? Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -----Original Message----- From: Suad Musovich [mailto:s.musovich@;AUCKLAND.AC.NZ] Sent: Wednesday, October 16, 2002 2:52 PM To: [EMAIL PROTECTED] Subject: Re: Slow DB backups. Depends if you are running other processes (especially expiration). Also you havent mentioned your HW configuration. On Thu, 2002-10-17 at 04:54, Dearman, Richard wrote: > I haven't done aTSM DB backup in the last few days. So I started one > today and it is moving very slow I have a 30GB database and it is only > reading at about 500KB/s. At this rate it will take hours to backup. > Before it would only take 45minutes. > > Is this normal? > > Thanks > ***************************EMAIL DISCLAIMER*************************** > This email and any files transmitted with it may be confidential and > are intended solely for the use of th individual or entity to whom > they are addressed. If you are not the intended recipient or the > individual responsible for delivering the e-mail to the intended > recipient, any disclosure, copying, distribution or any action taken > or omitted to be taken in reliance on it, is strictly prohibited. If > you have received this e-mail in error, please delete it and notify > the sender or contact Health Information Management 312.996.3941.
