Re: copypool volumes requested instead of primary pool
yes, that appears to be the case, damaged files on tapes. Not sure why so many on that particular day but we have identified somethanks for your help. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, January 14, 2008 2:13 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] copypool volumes requested instead of primary pool On Jan 14, 2008, at 2:53 PM, Park, Rod wrote: > ... why would it request the copypool if primary tape is available and > read/writable in the library? > Rod - The most common reason is that a file on the volume is Damaged. Use the Query CONtent VolName ... DAmaged=Yes command to so determine. Also watch out for files spanning volumes where the companion volume is not available. There should be evidence of problems in the Activity Log. I regular administration tasks, perform do 'Query Volume ACCess=UNAVailable,DESTroyed' to look for anomalies. Richard Simshttp://people.bu.edu/rbs/ This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Re: copypool volumes requested instead of primary pool
-Rod Park wrote: - >We have a situation where dba's are doing a full db restore to a >client. The client is requesting and using primary tapes, but it >is also requesting copypool tapes that are offsite. All of the >primary tapes are online r/w in the library and some are actually >in use that has the same db file that the restore is requesting >but the restore never asks for the primary tape, it goes for the >copypool tape immediately. AIX, sever version 5.3.3.1, oracle/tdp >version 5.3anybody else seen this, why would it request the >copypool if primary tape is available and read/writable in the >library? Are any of the primary pool tapes in use by other processes or sessions? Do the offsite tapes have access settings that imply that they are available for mounting? If the answer to both questions is yes, it is perfectly reasonable for the TSM server to request mounting of a copy pool tape rather than delay a restore by waiting for another session or process to finish using a primary pool tape.
Re: copypool volumes requested instead of primary pool
On Jan 14, 2008, at 2:53 PM, Park, Rod wrote: ... why would it request the copypool if primary tape is available and read/writable in the library? Rod - The most common reason is that a file on the volume is Damaged. Use the Query CONtent VolName ... DAmaged=Yes command to so determine. Also watch out for files spanning volumes where the companion volume is not available. There should be evidence of problems in the Activity Log. I regular administration tasks, perform do 'Query Volume ACCess=UNAVailable,DESTroyed' to look for anomalies. Richard Simshttp://people.bu.edu/rbs/
copypool volumes requested instead of primary pool
We have a situation where dba's are doing a full db restore to a client. The client is requesting and using primary tapes, but it is also requesting copypool tapes that are offsite. All of the primary tapes are online r/w in the library and some are actually in use that has the same db file that the restore is requesting but the restore never asks for the primary tape, it goes for the copypool tape immediately. AIX, sever version 5.3.3.1, oracle/tdp version 5.3anybody else seen this, why would it request the copypool if primary tape is available and read/writable in the library? Thanks, Rod. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
