ADSM-L

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

2017-04-14 06:43:35
Subject: Re: [ADSM-L] TSM7.1.7 DB growing with Dedup
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 14 Apr 2017 09:25:47 +0200
Bill, I forgot to link this document from IBM, some good info here :
https://www-01.ibm.com/support/docview.wss?uid=swg21992410



On Fri, Apr 14, 2017 at 8:02 AM, Stefan Folkerts <stefan.folkerts AT gmail DOT 
com>
wrote:

> 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."
>> -??
>>
>
>