You're welcome Bill. And yes, you need to bring down TSM for an offline reorg, they are very fast however, especially if you run them on SSD's as a target location for the reorg and you do it one table at a time so you can stop after 2 if you are running out of time for instance and do the others in another window.
I've seen massive performance enhancements after an offline reorg. I would recommend using the analyze_db2_formulas.pl script, the output is very usefull and looks like this: tsminst1@hostname:~/20170420-0818> cat summary.out BEGIN SUMMARY "db2 alter tablespace BFABFIDXSPACE reduce max" will return = 28.2G to the operating system file system "db2 alter tablespace BFBFEXTIDXSPACE reduce max" will return = 31.5G to the operating system file system BF_BITFILE_EXTENTS needs to be reorganized. estimated savings Table 5 GB, Index 2 GB BF_QUEUED_CHUNKS needs to be reorganized. estimated savings Table 1 GB, Index 163 GB Total estimated savings 171 GB END SUMMARY tsminst1@hostname:~/20170420-0818> You can see what tablespaces need a reorg and what need a reduce max. The reduce max estimates can be a bit to optimistic but still, never good indication or where your attention should be. Good luck Stefan On Thu, Apr 20, 2017 at 2:28 PM, Bill Boyer <[email protected]> wrote: > Offline re-org? Does that mean TSM needs to be down? I'm going to be > verifying the DB2 database version/stats this morning. > > Thanks! > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Stefan Folkerts > Sent: Friday, April 14, 2017 2:02 AM > To: [email protected] > Subject: Re: [ADSM-L] TSM7.1.7 DB growing with Dedup > > Hi Bill, > > I don't know what is going on the the protect stgpool command vs replicate > node in regards to DB usage but the conversion growth...i've been there a > few times before, it happens with every conversion because the directory > containerpool stores it's metadata differently than the filepool. > It's more efficient in the end but during the conversion you need extra > space on the database filesystems. > > You can however reclaim that space, I use offline reorgs and reduce max > commands on the tablespaces that hold the old filepool metadata. > > http://www-01.ibm.com/support/docview.wss?uid=swg21683633 > > Every conversion I have done has ended up with at least 30% less database > space used but not on it's own, they all need some help. > You can run those reorgs and reduce max commands half way during the > conversion without problems if you are running out of space. Well, at least > that has been my experience. > > If you are having issues with this I suggest you contact IBM support, they > can determine what tables to reorg and reduce max to get the maximum amount > of space (and performance) back. > > I would also check out this page : > http://www-01.ibm.com/support/docview.wss?uid=swg1IT15619 > I would advise you to run those selects on the database (might take a day > to complete), we have a few cases of orphaned chunks that according to us > MIGHT to be related (IBM is investigating) to the use of the protect > stgpool command, if you have them I would also suggest asking IBM for > support. > > > > On Wed, Apr 12, 2017 at 9:03 PM, Bill Boyer <[email protected]> wrote: > > > I converted a server over to directory container polls and replication. > > Their previous FILE stgpool was around 140TB of data. After defining > > everything I used the TSMOC dialogs to enable replication and then > > started running the CONVERT STGPOOL command. At the start of this I > > had 430GB of available DBSPACE. I was only running the PROTECT > > schedules. The REPLICATE schedule was marked inactive until the > > convert completed. I stopped the convert when I got down to only 70GB > > of DBspace left and around 40TB to convert. Since then the DB has been > > shrinking about 2-4GB per day. We're ordering more SSD drives so we > > can increase the DBSPACE but I may run out of space before then. > > > > > > > > Is the fact that all nodes are set for replication holding on to some > > DB and DIR pool space? And my target container pool seems to be a lot > > different used% even though my PROTECT processes are running to > > completion. > > > > > > > > I'm thinking if I remove replication from all the nodes until I'm done > > with the conversion it should help? Then change each node back for > > replication and start the schedule. > > > > > > > > TIA, > > > > Bill Boyer > > > > "There are seldom good technological solutions to behavioral problems." > -?? > > >
