Re the comment below:-
> My guess is that you automatically allocate new db volumes as the db
> grows, the biggest volume was created last, and was never filled, there
> was never any need foor all of those pages....
Sadly this is not the case. The 5000Mb was the first to be created, and
when it got to about 80% full, I added another 2500, then 1000. They were
all on the same disk (a Raid 5 array!) but have now been moved onto one
seperate disk and all into one seperate 10000Mb database and log volume.
TSM is now mirroring the DB volume and log volume itself onto another
seperate disk.
I take it that when creating a new DB volume and deleting an old one, TSM
will not reorg the database. This can only be done during an unload/load.
The things that concerns me is that if the figures are correct (see
below)...
After they each finished there was a summary that showed number of
> bytes
> moved. In this case the results were as follows:-
>
> 5000Mb - 947,912,704
> 2500Mb - 2,621,440,000
> 1000Mb - 1,048,576,000
...only 20% of the 5000Mb volume had actual data in it. We are still seeing
bad performance problems and I'm wondering if this would have anything to
do with it.
We recently upgraded to 4.2.2.12 and had to do an auditdb which completed
fine. So before now, I wasn't worried, but now, who knows. I'll keep
plugging away.
Thanks to all
Farren Minns
John Wiley & Sons Ltd
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Fragmented Database Maybe?
On vrijdag, feb 28, 2003, at 16:37 Europe/Amsterdam, Farren Minns wrote:
> Hi All TSMers
>
> I'm Running TSM 4.2.2.12 on a Solaris 2.7 server (E250 400Mhz, 1GB
> mem). We
> have been having severe performance issues recently and moved our
> database
> volumes off onto a new disk. To do this we formatted a new db volume
> and
> copy, and then we deleted the original ones. TSM immediately went into
> action and moved the database volumes into the new volume.
>
> The volume sizes were 5000Mb
> 2500Mb
> 1000Mb
>
> After they each finished there was a summary that showed number of
> bytes
> moved. In this case the results were as follows:-
>
> 5000Mb - 947,912,704
> 2500Mb - 2,621,440,000
> 1000Mb - 1,048,576,000
>
> Now I can see that the figures for the 1000 and 2500 are correct, but
> the
> 5000 volume is way off! Any ideas why I am seeing this result. Is it
> just a
> bug or is the DB massively fragmented or something?
>
My guess is that you automatically allocate new db volumes as the db
grows, the biggest volume was created last, and was never filled, there
was never any need foor all of those pages....
I also guess all of these volumes were on one disk, as TSM tries to
allocate new pages in an RR fashion, this is a big performance hit.
> Also, is there anyway to see if indeed the database is fragmented?
>
Fragmentation is not regularly an issue on a database... IN my
experience, fragmentation is just something we'll have to accept and
well, take into account when tuning a system. It cannot be helped and
ehhh, we don't like to go of-line a day/week just to unload+load db....
> Many thanks to all who help as this is very puzzling.
>
> All the best
>
> Farren Minns - John Wiley & Sons Ltd
>
--
Met vriendelijke groeten,
Remco Post
SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl
High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
"I really didn't foresee the Internet. But then, neither did the
computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams
|
