Re: 'Maximum Scratch Volumes Allowed' clarrification
Gordon, The data will stay in the existing storage pool until it is moved manually... BTW: Rebinding applies to data retention (ie: number of versions and days to keep), and actually refers to files being re-attached to a new (different) management class. So, changing the details of a management class doesnt cause rebinding (but the new details apply to whatever is attached to that management class). Changing your INCLUDE /filespec MGMTCLASS will result in files in /filespec being changed to the new management class (aka rebinding), (or changing your default management class) and thus be at the mercy of the new retention details. Hope this make sense... ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli ADSM: Dist Stor Manager [EMAIL PROTECTED] wrote on 14/10/2003 11:30:23 AM: We have monthly incremental backups running for some of our nodes which are registered to a seperate policy domain. Data for this domain is suppose to go to a seperate storage pool but I've discovered a couple of errors in the copy destination field for two management classes. I need to modify the copy destination field for the Backup Copy Group to point to the correct storage pool but wonder what effect this will have on the data currently stored in the wrong are? I take it the next time the files are backed-up they will be rebound to the new storage pool, will the files already stored in the incorrect storage pool get moved across automatically or will they just sit there?
Re: 'Maximum Scratch Volumes Allowed' clarrification
I think that makes sense Deon, I'll change the management class settings and then move the files manually to the correct storage pool. Thanks for the info. Gordon [EMAIL PROTECTED] OM To: [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED]Subject: Re: 'Maximum Scratch Volumes Allowed' clarrification EDU 14/10/2003 04:09 PM Please respond to ADSM-L Gordon, The data will stay in the existing storage pool until it is moved manually... BTW: Rebinding applies to data retention (ie: number of versions and days to keep), and actually refers to files being re-attached to a new (different) management class. So, changing the details of a management class doesnt cause rebinding (but the new details apply to whatever is attached to that management class). Changing your INCLUDE /filespec MGMTCLASS will result in files in /filespec being changed to the new management class (aka rebinding), (or changing your default management class) and thus be at the mercy of the new retention details. Hope this make sense... ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli ADSM: Dist Stor Manager [EMAIL PROTECTED] wrote on 14/10/2003 11:30:23 AM: We have monthly incremental backups running for some of our nodes which are registered to a seperate policy domain. Data for this domain is suppose to go to a seperate storage pool but I've discovered a couple of errors in the copy destination field for two management classes. I need to modify the copy destination field for the Backup Copy Group to point to the correct storage pool but wonder what effect this will have on the data currently stored in the wrong are? I take it the next time the files are backed-up they will be rebound to the new storage pool, will the files already stored in the incorrect storage pool get moved across automatically or will they just sit there? -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: 'Maximum Scratch Volumes Allowed' clarrification
Thanks for the reply John. There is 5 nodes associated with this particular tape storage pool, with a total figure of 14 filespaces shared between them. The re-use delay parameter is currently at 0 and the migration processes is set to 1. I did have migration processes at 2 but scaled it back to 1 to see if that would help with the tape use. I'll keep looking and see if there is anything else out of the ordinary. Thanks, Gordon [EMAIL PROTECTED] THERN.CO.UK To: [EMAIL PROTECTED] Sent by:cc: [EMAIL PROTECTED]Subject: Re: 'Maximum Scratch Volumes Allowed' clarrification 10/10/2003 06:06 PM Please respond to ADSM-L Gordon, Maxscratch is just a value you set high enough to prevent failures due to running out of storage. It will not use more tapes Look at your reuse delay values Try a move data against the 6 empty filling tapes The number of filling tapes in a collocated pool should bear some relationship to either the number of nodes or filespaces depending on the type of collocation. If you have multiple filling tapes for the same node/filespace then you probably have scheduling issues John Gordon Woodward [EMAIL PROTECTED]@vm.marist.edu on 10/10/2003 12:23:15 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:'Maximum Scratch Volumes Allowed' clarrification Hi all, I'm after some clarrification about the stgp maxscratch setting for one of our storage pools. We recently decommissioned a server and removed all it's data out of TSM, thus freeing up a lot of tapes for other uses, but I'm now finding that our collocated storage pool has decided to hoard all our scratch tapes for itself, even though it doesn't put any data in them. Our collocated tape storage pool currently has 32 tapes allocated to it,11 of which are filling with only 5 tapes of those having data on them. The Maximum Scratch Volumes Allowed setting for this storage pool is set to 100, which is a tad excessive so I want to pull it back to a smaller number. Would setting this maxscratch paramater back down to say 5 be reasonable without causing other problems? This particular storage pool is lucky to fill one tape a night and it reclaims about 1 tape a day, I don't want it to keep stealing all available scratch tapes for itself as our tape library is already at capacity. Thanks in advance! Gordon Woodward -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. ** -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: 'Maximum Scratch Volumes Allowed' clarrification
Okay, I've figured out the culprit to my problem. I queried the contents of some of the filling tapes which had basically no data on them and found they were storing data for nodes which are not suppose to be going to this storage pool. We have monthly incremental backups running for some of our nodes which are registered to a seperate policy domain. Data for this domain is suppose to go to a seperate storage pool but I've discovered a couple of errors in the copy destination field for two management classes. I need to modify the copy destination field for the Backup Copy Group to point to the correct storage pool but wonder what effect this will have on the data currently stored in the wrong are? I take it the next time the files are backed-up they will be rebound to the new storage pool, will the files already stored in the incorrect storage pool get moved across automatically or will they just sit there? Gordon [EMAIL PROTECTED] THERN.CO.UK To: [EMAIL PROTECTED] Sent by:cc: [EMAIL PROTECTED]Subject: Re: 'Maximum Scratch Volumes Allowed' clarrification 10/10/2003 06:06 PM Please respond to ADSM-L Gordon, Maxscratch is just a value you set high enough to prevent failures due to running out of storage. It will not use more tapes Look at your reuse delay values Try a move data against the 6 empty filling tapes The number of filling tapes in a collocated pool should bear some relationship to either the number of nodes or filespaces depending on the type of collocation. If you have multiple filling tapes for the same node/filespace then you probably have scheduling issues John Gordon Woodward [EMAIL PROTECTED]@vm.marist.edu on 10/10/2003 12:23:15 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:'Maximum Scratch Volumes Allowed' clarrification Hi all, I'm after some clarrification about the stgp maxscratch setting for one of our storage pools. We recently decommissioned a server and removed all it's data out of TSM, thus freeing up a lot of tapes for other uses, but I'm now finding that our collocated storage pool has decided to hoard all our scratch tapes for itself, even though it doesn't put any data in them. Our collocated tape storage pool currently has 32 tapes allocated to it,11 of which are filling with only 5 tapes of those having data on them. The Maximum Scratch Volumes Allowed setting for this storage pool is set to 100, which is a tad excessive so I want to pull it back to a smaller number. Would setting this maxscratch paramater back down to say 5 be reasonable without causing other problems? This particular storage pool is lucky to fill one tape a night and it reclaims about 1 tape a day, I don't want it to keep stealing all available scratch tapes for itself as our tape library is already at capacity. Thanks in advance! Gordon Woodward -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. ** -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: 'Maximum Scratch Volumes Allowed' clarrification
Gordon, Maxscratch is just a value you set high enough to prevent failures due to running out of storage. It will not use more tapes Look at your reuse delay values Try a move data against the 6 empty filling tapes The number of filling tapes in a collocated pool should bear some relationship to either the number of nodes or filespaces depending on the type of collocation. If you have multiple filling tapes for the same node/filespace then you probably have scheduling issues John Gordon Woodward [EMAIL PROTECTED]@vm.marist.edu on 10/10/2003 12:23:15 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:'Maximum Scratch Volumes Allowed' clarrification Hi all, I'm after some clarrification about the stgp maxscratch setting for one of our storage pools. We recently decommissioned a server and removed all it's data out of TSM, thus freeing up a lot of tapes for other uses, but I'm now finding that our collocated storage pool has decided to hoard all our scratch tapes for itself, even though it doesn't put any data in them. Our collocated tape storage pool currently has 32 tapes allocated to it,11 of which are filling with only 5 tapes of those having data on them. The Maximum Scratch Volumes Allowed setting for this storage pool is set to 100, which is a tad excessive so I want to pull it back to a smaller number. Would setting this maxscratch paramater back down to say 5 be reasonable without causing other problems? This particular storage pool is lucky to fill one tape a night and it reclaims about 1 tape a day, I don't want it to keep stealing all available scratch tapes for itself as our tape library is already at capacity. Thanks in advance! Gordon Woodward -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. **
'Maximum Scratch Volumes Allowed' clarrification
Hi all, I'm after some clarrification about the stgp maxscratch setting for one of our storage pools. We recently decommissioned a server and removed all it's data out of TSM, thus freeing up a lot of tapes for other uses, but I'm now finding that our collocated storage pool has decided to hoard all our scratch tapes for itself, even though it doesn't put any data in them. Our collocated tape storage pool currently has 32 tapes allocated to it,11 of which are filling with only 5 tapes of those having data on them. The Maximum Scratch Volumes Allowed setting for this storage pool is set to 100, which is a tad excessive so I want to pull it back to a smaller number. Would setting this maxscratch paramater back down to say 5 be reasonable without causing other problems? This particular storage pool is lucky to fill one tape a night and it reclaims about 1 tape a day, I don't want it to keep stealing all available scratch tapes for itself as our tape library is already at capacity. Thanks in advance! Gordon Woodward -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
