ADSM-L

Re: [ADSM-L] TSM7.1.7 DB growing with Dedup

2017-04-20 08:29:57
Subject: Re: [ADSM-L] TSM7.1.7 DB growing with Dedup
From: Bill Boyer <bjdboyer AT COMCAST DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 20 Apr 2017 08:28:12 -0400
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." -??
>