I have posted many times in the past saying you should never do a
database unload/reload to gain performance. But this just might be the
one case where it might make sense - the remaining half of a split
server. But before you do something that drastic, dangerous, and time
consuming, look for the things that are easier to fix.
My basic metric of whether or not you are in trouble is, how long does
expiration take? If you start it daily, the closer it is to 24 hours
running time, the closer you are to doomsday. Never-ending expiration is
the classic symptom of TSM Server Meltdown.
But on the other hand, if your expiration runs nice and fast, your
server and its database are probably OK. Look to clients as the problem.
They can't all squeeze in the door at once, so don't let them try. If
they use the client-polling scheduler, how long is the backup window,
and what is your setting for Schedule Randomization Percentage? Make it
as high as possible - SET RANDOMIZE 50. This will also help if you are
having any kind of a network bottleneck.
Look at these clients on a micro level. About how much are they each
actually backing up? If it's not much, then your theory might be
right, that they are very busy downloading their lists of backed up
files. In that case, load spreading will be the best thing you could
do. You might consider a schedule where not every client does a full
"Incremental" every night - perhaps they only do one every other night
and on the other nights they do an "incrbydate" backup which is much
faster, because it goes only by the timestamps in the file system.
Not to ask the obvious, but what's your Database Cache Hit Percentage?
(Q DB F=D) If it's below 99%, it needs help. Even (especially) a badly
fragmented database will run a lot faster if you have it swimming in
cache.
Look at other differences between your two instances - are they
basically different types of clients?
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
============The short fortuneteller who escaped from prison=============
======================was a small medium at large.======================
On Tue, 13 Jan 2004, Andy Carlson wrote:
>We are having terrible performance with one of our instances of TSM. I
>have suspicions, but I want to hear what you guys say. Here is what we
>have:
>
>2 instances of TSM - TSMI and TSMU (TSMI is the problem)
>
>TSM 5.2.1.1
>AIX 51.ML4
>RS/6000 P670 - 8 processors, 16GB memory
>Fastt700 SAN
>STK9840 Tape drives
>
>The Database is 85% of 88GB (with room to expand another 50GB or so).
>
>Right at this moment, we have 233 sessions with TSMI. The backup
>sessions grind to a halt for hours at a time, with nothing apparently
>happening. I suspect that the directory trees are being downloaded and
>built, but not sure
>
>When we split TSMI and TSMU, we created the TSMU instance, and did a
>full backup on all the servers that moved there. The TSMI database is a
>restored copy of the original database, with the TSMU stuff deleted out.
>
>Any ideas would be greatly appreciated.
>
>
>Andy Carlson |\ _,,,---,,_
>Senior Technical Specialist ZZZzz /,`.-'`' -. ;-;;,_
>BJC Health Care |,4- ) )-,_. ,\ ( `'-'
>St. Louis, Missouri '---''(_/--' `-'\_)
>Cat Pics: http://andyc.dyndns.org/animal.html
>
|
