ADSM-L

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

2017-04-14 06:41:56
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 08:02:08 +0200
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." -??
>