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@vm.marist.edu] On Behalf Of Allen S. Rout Sent: Monday, April 23, 2012 9:39 AM To: ADSM-L@vm.marist.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.