Hi Chad,
If you have enough scratch tapes to use reuse delay on Primary Pool it will 
save you time if a DB corruption happened.

But maybe you should have different reuse delay values on Copypool and primary 
pool?
Let's say you only have 1-2 days on Primary Pool in case of the DB need to be 
recovered to early morning and longer retention on Copypool if a disaster 
happened.

Best Regards
Christian Svensson

Cell: +46-70-325 1577
E-mail: Christian.Svensson AT cristie DOT se
Supported Platform for CPU2TSM:: 
http://www.cristie.se/cpu2tsm-supported-platforms

________________________________________
Från: Harris, Chad [ceh AT INDIANA DOT EDU]
Skickat: den 4 oktober 2011 16:38
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: Reuse Delay

Good Morning/Afternoon/Evening fellow TSM Adminers,

I have a question to pose to the group about the Reuse Delay parameter and what 
is the best way to utilize or not utilize it on your storage pools.  I have 
come across two different schools of thought on this subject and before I do 
something rash and change a config setting, that might regret changing later, I 
thought I would pose the question to the group.

One school of thought on this subject is to keep the reuse delay parameter of 
your primary pool set to zero days while setting the reuse delay parameter to 5 
on your copy pools.  The idea behind this being that even if you do need to 
restore your database to an older version the file references that are no 
longer available in your primary pool will still be available in your copy pool 
while letting you reuse volumes in your primary pools sooner.

The second school of thought is that the reuse delay on your primary pool and 
your copy pool should both be the same giving you the greatest chance to cover 
your posterior in the event of a database meltdown since you will have two 
copies of the files that an older database version might reference.

With all this in mind, I just wanted to see what method other TSM Admins 
thoughts about this are and what they are using in their environments.

Thanks,
Chad Harris