We have already encountered this situation although TSM was not part of
the picture.  Oracle data that was written directly to the DD was not
deleted by the RMAN cleanup process.  Our DD utilization at the
replication client was above 95% and we needed to reclaim space.  We
deleted several TB of old data and the DBAs implemented RMAN cleanup.
We had to wait for the snapshots to expire, then had to wait for the
Tuesday DD cleaning process.  With daily snapshots/one week retention it
took about two weeks for deleted files to finally stop using space.

Jim Schneider

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf Of
Allen S. Rout
Sent: Monday, April 23, 2012 9:39 AM
To: ADSM-L AT vm.marist DOT edu
Subject: Re: [ADSM-L] DataDomain and dedup per node

On 04/19/2012 10:04 AM, Schneider, Jim wrote:
> The most serious problem we have encountered is the effect of 
> reclamation on backup throughput.  We have a 1 GB backup network that 
> is used for servers to write directly to the Data Domain, bypassing
TSM.
> When only one client is writing directly to the DD we see backup 
> network utilization around 85%.  When reclamation is running the 
> client gets 5% backup network utilization.  I've cancelled reclamation

> and watched the client throughput increase, then drop again when 
> autoreclamation restarts.  We now only run reclamation when the 
> client's 1 TB daily backup is complete (a 4- to 5-hour process).
>

Another axis on which reclamation will affect your DD behavior is the
amount of dead space due to uncleaned snapshots.   You can think of this
as analogous to PENDING physical volumes.. Below I've included a
terribly contrived example, which I hope is at least a little clear.

The key is that there's a gap of formally unusued, but not-yet-available
space on the DD.  The size of this gap is related to the churn rate of
the files.  If you reclaim madly, you'll eventually make that gap grow,
a lot.

OTOH, some of that space will dedupe (I'd guess that copying 'most of' a
file from A to B on the DD ought to dedupe pretty darn well. :)

----

Say you run snapshots daily and keep 7.  You write one volume a day,
keep two weeks of them.  You've got REUSEDELAY set to 5, and we'll start
on a Sunday, Jan 1.

So, at day 14 two Sundays downrange, you've got files

/ddfiles/vol01  -> vol14   present in TSM, on the filesystem

On Monday the 15th, vol01 is PENDING to TSM, but still present on the
filesystem.

On Saturday the 20th, vol01 is deleted from the filesystem, but
referenced by the snapshot you took on the 19th.  Gotta keep it around.

On Friday the 26th, this is _still_ true.  vol01 is deleted but still
referenced by an active snapshot.  It's now in the company of
vol02-vol06.  Sometime that day, though the snapshot from the 19th will
expire.  BUT WAIT THERE'S MORE...

You don't get the space back from the expired snapshot until the cleanup
on (by default) the following Tuesday. So on January 30th, if all goes
well, you'll run the administrative process which returns to you the
space occupied by vol01.


We're accustomed to thinking in terms of volumes and reusedelays:  this
is really just another few iterations of that, but it's important to
keep in mind that they sum.


  - Allen S. Rout

**********************************************************************
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.