ADSM-L

Re: DB2 high speed SP switch backups dead slow.

2003-09-12 13:02:43
Subject: Re: DB2 high speed SP switch backups dead slow.
From: Zlatko Krastev <acit AT ATTGLOBAL DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 12 Sep 2003 20:00:56 +0300
Long, long time ago, in ancient Rome there was a sentence - "divide and
conquer". Unfortunately I did not see this aproach used while it helps
most of the time.
Why not to isolate each part of the data route and ensure it is working at
best possible throughput? This might help to identify the bottleneck. The
subject is stating the "SP switch" backups are slow but are they due to
switch problems or for other reason(s)?!?

1. What is the speed when DB2 backup is performed to a file within the
same system? If its is good proceed with next, if not - investigate.
Information to be considered:
- number of disks (Shark is Shark, but how many ranks are used for DB and
what nodes/applications are accessing the same rank)
- number of tablespaces, managed by system or managed by database
- tablespace(s) page size
- what is the load on the DB2 during backup (the SP is not bought for
nothing)
- what is the load on the processors, HBAs and hdisks/vpaths before and
during backup

2. Number one advice when network problems are suspected - run FTP and
measure the performance. If the FTP is performing fine (this is a SP
switch on the end, it ought to achieve about 95-100 MB/s) stop blaming the
network. If FTP is slow, the TSM will also be slow without any fault on
its side - investigate the switch or TCP/IP stack.

3. Check for IP addressing problems (apologies if sounds silly or
offending) - if TCPServeraddress points to Ethernet address instead of
css0 address, obviously the speed would be lower by an order.
BTW: Miles, in your example TCPS=127.0.0.1 and switch is not used at all,
so the example does not relate to "switch" problem of the subject.

4. Check the speed of a backup performed by a client running on same
system as TSM server - will drop the network from the equation. If
performance is poor, the TSM server has to be tuned. If performance is
good - investigate other parts.

Zlatko Krastev
IT Consultant






Muthyam Reddy <MREDDY AT JOY DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10.09.2003 22:18
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        DB2 high speed SP switch backups dead slow.


** High Priority **

Hi TSMers,
I hope someone got experiance on same before .

This is problem about db2(7.1) backups on high speed switch to TSM
.Present we are taking 430Gb of data to tsm which is taking 14 hrs to
finish.recently I have changed couple of paramters on 'css' and 'no' to
improve performance based on IBM docs.Still my backups takes same time.
no doubt I missed some parts on TSM/AIX/db2  to lubricate.
Please can any one dump some ideas to fix this this and how long its
taking in ur environment same setup.
We are using four session on db2(7.1) and copying to tape pools directly.


please send ur back times with same environments.

please send me some tips to make my backups fast.

please write if wants information.

thanks and regards
muthyam

<Prev in Thread] Current Thread [Next in Thread>