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 <bjdboyer AT comcast DOT net> 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Stefan Folkerts
> Sent: Friday, April 14, 2017 2:02 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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 <bjdboyer AT comcast DOT net>
> 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."
> -??
> >
>
|
