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: [email protected] Supported Platform for CPU2TSM:: http://www.cristie.se/cpu2tsm-supported-platforms ________________________________________ Från: Harris, Chad [[email protected]] Skickat: den 4 oktober 2011 16:38 Till: [email protected] Ä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
