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 AT VM.MARIST DOT EDU]On Behalf Of
Alex Paschal
Sent: Thursday, October 17, 2002 5:14 PM
To: ADSM-L AT VM.MARIST DOT EDU
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 AT NAPTHEON DOT COM]
Sent: Wednesday, October 16, 2002 11:08 PM
To: ADSM-L AT VM.MARIST DOT EDU
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 AT AUCKLAND.AC DOT NZ]
Sent: Wednesday, October 16, 2002 2:52 PM
To: ADSM-L AT VM.MARIST DOT EDU
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.
|
