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" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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