Re: Space reclamation is ended for volume
Hi Mik, In order to preserve the existing backuped data on the volume, I can suggest you this : 1) Put the tape in readOnly mode: upd vol Volume_Name access=reado 2) Protect current valid datas : Move data Volume_name --> It move all good datas, even the ones that have not been copied yet. --> It flags bad files as damaged 3) audit the tape and fix it : audit vol volume_name fix=yes 4) restore the destroyed datas (when a copy of them exist) : restore vol Volume_Name Hope it helps, Emmanuel -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de mik Envoyé : jeudi 12 décembre 2013 11:10 À : ADSM-L@VM.MARIST.EDU Objet : [ADSM-L] Space reclamation is ended for volume Hi Eric van Loon and thanks for the reply, I have already try the audit volume and audit volume fix=yes and no error on th file, i don"t understand. Regars, Mickael. +-- |This was sent by bobpatrick808...@yahoo.fr via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Re: Space reclamation is ended for volume
Hi Mickael! Audit the volume like this: Audit vol S:\TSM_FILE_DEVCLASS\16AA.BFS This will show you the files which are corrupted on the volume. It could be that the volume was corrupted after a successful backup stgpool, so first try a restore: Restore volume S:\TSM_FILE_DEVCLASS\16AA.BFS If the restore is successful the volume should be empty afterwards, if not you will have to perform an audit again but with the fix=yes: Upd vol S:\TSM_FILE_DEVCLASS\16AA.BFS access=readonly Audit vol S:\TSM_FILE_DEVCLASS\16AA.BFS fix=yes Bear in mind that the corrupted files will be deleted from TSM. If these files are Backup/archive client files it's not a very big issue: they will be backed up again during the next backup cycle. Are the files part of a TDP backup then things are different, in that case your whole backup series is corrupted and you will have to schedule a new full backup for that TDP client a.s.a.p. Kind regards, Eric van Loon AF/KLM Storage Engineering -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of mik Sent: donderdag 12 december 2013 9:54 To: ADSM-L@VM.MARIST.EDU Subject: Space reclamation is ended for volume Hi everybody, My problem __ ANRD_1627081930 (ssrecons.c:784) Thread<52>: Byte count mismatch for object 0.206273217 source: 0.62939, target: 0.920075 (PROCESS: 327) ANRD Thread<52> issued message from: (PROCESS: 327) ANR1092E Space reclamation is ended for volume S:\TSM_FILE_DEVCLASS\16AA.BFS. An internal server error was detected. (PROCESS: 327) ANRD Thread<52> issued message 1092 from: (PROCESS: 327) __ I try to update volume S:\TSM_FILE_DEVCLASS\16AA.BFS access=readonly and perform a move data but i have this ANR0984I Process 54 for MOVE DATA started in the BACKGROUND at 09:32:18. ANR1140I Move data process started for volume S:\TSM_FILE_DEVCLASS\16AA.BFS (process ID 54). ANR8340I FILE volume S:\TSM_FILE_DEVCLASS\4508.BFS mounted. ANR8340I FILE volume S:\TSM_FILE_DEVCLASS\16AA.BFS mounted. ANR0513I Process 54 opened output volume S:\TSM_FILE_DEVCLASS\4508.BFS. ANR0512I Process 54 opened input volume S:\TSM_FILE_DEVCLASS\16AA.BFS. ANRD_1627081930 (ssrecons.c:784) Thread<59>: Byte count mismatch for object 0.206273217 source: 0.62939, target: 0.920075 ANRD Thread<59> issued message from: ANR1156W Move data process terminated for volume S:\TSM_FILE_DEVCLASS\16AA.BFS - internal server error detected. ANRD Thread<59> issued message 1156 from: ANR0985I Process 54 for MOVE DATA running in the BACKGROUND completed with completion state FAILURE at 09:32:18. ANR0514I Session 995 closed volume S:\TSM_FILE_DEVCLASS\16AA.BFS. ANR0514I Session 995 closed volume S:\TSM_FILE_DEVCLASS\4508.BFS. Anyone have a idea to correct this error? Regards, Mickael. +-- |This was sent by bobpatrick808...@yahoo.fr via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
Re: Space reclamation is ended for volume
Try to use audit volume with fix=yes... Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank Kuwait, www.ahliunited.com.kw -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of mik Sent: 12 12 2013 11:54 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Space reclamation is ended for volume Hi everybody, My problem __ ANRD_1627081930 (ssrecons.c:784) Thread<52>: Byte count mismatch for object 0.206273217 source: 0.62939, target: 0.920075 (PROCESS: 327) ANRD Thread<52> issued message from: (PROCESS: 327) ANR1092E Space reclamation is ended for volume S:\TSM_FILE_DEVCLASS\16AA.BFS. An internal server error was detected. (PROCESS: 327) ANRD Thread<52> issued message 1092 from: (PROCESS: 327) __ I try to update volume S:\TSM_FILE_DEVCLASS\16AA.BFS access=readonly and perform a move data but i have this ANR0984I Process 54 for MOVE DATA started in the BACKGROUND at 09:32:18. ANR1140I Move data process started for volume S:\TSM_FILE_DEVCLASS\16AA.BFS (process ID 54). ANR8340I FILE volume S:\TSM_FILE_DEVCLASS\4508.BFS mounted. ANR8340I FILE volume S:\TSM_FILE_DEVCLASS\16AA.BFS mounted. ANR0513I Process 54 opened output volume S:\TSM_FILE_DEVCLASS\4508.BFS. ANR0512I Process 54 opened input volume S:\TSM_FILE_DEVCLASS\16AA.BFS. ANRD_1627081930 (ssrecons.c:784) Thread<59>: Byte count mismatch for object 0.206273217 source: 0.62939, target: 0.920075 ANRD Thread<59> issued message from: ANR1156W Move data process terminated for volume S:\TSM_FILE_DEVCLASS\16AA.BFS - internal server error detected. ANRD Thread<59> issued message 1156 from: ANR0985I Process 54 for MOVE DATA running in the BACKGROUND completed with completion state FAILURE at 09:32:18. ANR0514I Session 995 closed volume S:\TSM_FILE_DEVCLASS\16AA.BFS. ANR0514I Session 995 closed volume S:\TSM_FILE_DEVCLASS\4508.BFS. Anyone have a idea to correct this error? Regards, Mickael. +-- |This was sent by bobpatrick808...@yahoo.fr via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
Re: Space Reclamation Eating Tapes
On Nov 28, 2005, at 11:42 AM, Sung Y Lee wrote: It has been my experience that, if primary tape pool maxscratch value is set greater than tapes used when reclamation kicks off, it mounts a brand new scratch tapes. ... I've never seen that behavior - that would result in a large number of tapes in Filling state, and that does not happen. TSM requests a fresh tape when the would-be candidate filling tape is in an unusable state (as from previous tape errors) or that volume is in use (current output volume or being dismounted). If a TSM instance was always calling for new volumes, that would constitute a violation of its design, and should be reported as a defect. In any case, this thread is largely proceeding without substantive information. We need to see the results of analyses which examined tape states, Activity Log, and volume contents. Richard Sims
Re: Space Reclamation Eating Tapes
It has been my experience that, if primary tape pool maxscratch value is set greater than tapes used when reclamation kicks off, it mounts a brand new scratch tapes. I suspect that there is some logical reason how tapes are reclaimed ... such as why not taking already used tape. However I have had success by lowering the maxscratch count less than tapes used will allow TSM not to use new scratch tapes but use already used tapes. Now, if one is using collocation, I tried to think of a reason why one would starting reclamation. My experience shows that since any gain of tapes by performing reclamation of collocation pool is short lived because TSM will shortly attempt to use new scratch tapes. Sung Y. Lee "ADSM: Dist Stor Manager" wrote on 11/28/2005 09:21:45 AM: > I recently migrated our Windows 2K3 TSM server from 5.2.1.3 to 5.3.2.0 > and since then, it seems that whenever I kick off space reclamation for > my primary tape storage pools, it eats up scratch tapes, instead of > freeing them up. Is there a reason for this? I understand that > occasionally TSM will need a scratch tape to combine other tapes, but it > should then free those other tapes up and return them to the scratch > pool. I've checked the reuse delay on the storage pools, and they are > set to 0, so I know that isn't the problem. > > > Mel Dennis
Re: Space Reclamation Eating Tapes
Such as? :) Mel Dennis Systems Engineer - IT743 Siemens Power Generation 4400 Alafaya Trail Orlando, FL 32826 MC Q1-110 Tel: (407) 736-2360 Win: 439-2360 Fax: (407) 736-5069 Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos, Karel Sent: Monday, November 28, 2005 9:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Space Reclamation Eating Tapes Things have changed in 5.3. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Melburn W IT743 Sent: maandag 28 november 2005 15:35 To: ADSM-L@VM.MARIST.EDU Subject: Re: Space Reclamation Eating Tapes Don't think that is it, I only have 2 storage pools out of like 12 that have collocation turned on (these storage pools are for large file servers). So collocation shouldn't be affecting most of them. Mel Dennis Systems Engineer - IT743 Siemens Power Generation 4400 Alafaya Trail Orlando, FL 32826 MC Q1-110 Tel: (407) 736-2360 Win: 439-2360 Fax: (407) 736-5069 Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos, Karel Sent: Monday, November 28, 2005 9:30 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Space Reclamation Eating Tapes Sounds like a collocation problem. Q stg / q node / q collocgroup. Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Melburn W IT743 Sent: maandag 28 november 2005 15:22 To: ADSM-L@VM.MARIST.EDU Subject: Space Reclamation Eating Tapes I recently migrated our Windows 2K3 TSM server from 5.2.1.3 to 5.3.2.0 and since then, it seems that whenever I kick off space reclamation for my primary tape storage pools, it eats up scratch tapes, instead of freeing them up. Is there a reason for this? I understand that occasionally TSM will need a scratch tape to combine other tapes, but it should then free those other tapes up and return them to the scratch pool. I've checked the reuse delay on the storage pools, and they are set to 0, so I know that isn't the problem. Mel Dennis
Re: Space Reclamation Eating Tapes
Things have changed in 5.3. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Melburn W IT743 Sent: maandag 28 november 2005 15:35 To: ADSM-L@VM.MARIST.EDU Subject: Re: Space Reclamation Eating Tapes Don't think that is it, I only have 2 storage pools out of like 12 that have collocation turned on (these storage pools are for large file servers). So collocation shouldn't be affecting most of them. Mel Dennis Systems Engineer - IT743 Siemens Power Generation 4400 Alafaya Trail Orlando, FL 32826 MC Q1-110 Tel: (407) 736-2360 Win: 439-2360 Fax: (407) 736-5069 Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos, Karel Sent: Monday, November 28, 2005 9:30 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Space Reclamation Eating Tapes Sounds like a collocation problem. Q stg / q node / q collocgroup. Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Melburn W IT743 Sent: maandag 28 november 2005 15:22 To: ADSM-L@VM.MARIST.EDU Subject: Space Reclamation Eating Tapes I recently migrated our Windows 2K3 TSM server from 5.2.1.3 to 5.3.2.0 and since then, it seems that whenever I kick off space reclamation for my primary tape storage pools, it eats up scratch tapes, instead of freeing them up. Is there a reason for this? I understand that occasionally TSM will need a scratch tape to combine other tapes, but it should then free those other tapes up and return them to the scratch pool. I've checked the reuse delay on the storage pools, and they are set to 0, so I know that isn't the problem. Mel Dennis
Re: Space Reclamation Eating Tapes
Don't think that is it, I only have 2 storage pools out of like 12 that have collocation turned on (these storage pools are for large file servers). So collocation shouldn't be affecting most of them. Mel Dennis Systems Engineer - IT743 Siemens Power Generation 4400 Alafaya Trail Orlando, FL 32826 MC Q1-110 Tel: (407) 736-2360 Win: 439-2360 Fax: (407) 736-5069 Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos, Karel Sent: Monday, November 28, 2005 9:30 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Space Reclamation Eating Tapes Sounds like a collocation problem. Q stg / q node / q collocgroup. Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Melburn W IT743 Sent: maandag 28 november 2005 15:22 To: ADSM-L@VM.MARIST.EDU Subject: Space Reclamation Eating Tapes I recently migrated our Windows 2K3 TSM server from 5.2.1.3 to 5.3.2.0 and since then, it seems that whenever I kick off space reclamation for my primary tape storage pools, it eats up scratch tapes, instead of freeing them up. Is there a reason for this? I understand that occasionally TSM will need a scratch tape to combine other tapes, but it should then free those other tapes up and return them to the scratch pool. I've checked the reuse delay on the storage pools, and they are set to 0, so I know that isn't the problem. Mel Dennis
Re: Space Reclamation Eating Tapes
Sounds like a collocation problem. Q stg / q node / q collocgroup. Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Melburn W IT743 Sent: maandag 28 november 2005 15:22 To: ADSM-L@VM.MARIST.EDU Subject: Space Reclamation Eating Tapes I recently migrated our Windows 2K3 TSM server from 5.2.1.3 to 5.3.2.0 and since then, it seems that whenever I kick off space reclamation for my primary tape storage pools, it eats up scratch tapes, instead of freeing them up. Is there a reason for this? I understand that occasionally TSM will need a scratch tape to combine other tapes, but it should then free those other tapes up and return them to the scratch pool. I've checked the reuse delay on the storage pools, and they are set to 0, so I know that isn't the problem. Mel Dennis
Re: Space reclamation error for volumes dedicated to directory structure storage ....
I upgraded one server to 5.3.1.3 a couple of weeks ago. Had one occurance of something similar; only my reclaim just said "internal server error" and died. Restarting reclaim didn't fix it. But my reclaim was appending data to a "filling" tape that was almost full. I directed it to a different tape with MOVE DATA instead of reclaim, and it finished OK. Have seen nothing else strange. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of PAC Brion Arnaud Sent: Thursday, September 15, 2005 9:10 AM To: ADSM-L@VM.MARIST.EDU Subject: Space reclamation error for volumes dedicated to directory structure storage Hi all, Since upgrade to TSM 5.3.1, I'm facing a strange problem affecting reclamation on specific copypool dedicated to directories structure. What happens is as follows : 09/15/05 09:34:28 ANR0984I Process 375 for SPACE RECLAMATION started in the BACKGROUND at 09:34:28. (PROCESS: 375) 09/15/05 09:34:28 ANR4931I Reclamation process 375 started for copy storage pool COPYLTO2_DIR automatically, threshold=70, offsiteRclmLimit=No Limit, duration=None. (PROCESS: 375) 09/15/05 09:34:28 ANR1040I Space reclamation started for volume 000559, storage pool COPYLTO2_DIR (process number 375). (PROCESS: 375) 09/15/05 09:35:19 ANR8337I LTO volume 000507 mounted in drive LTO2DR7 (/dev/rmt23). (PROCESS: 375) 09/15/05 09:35:30 ANR1340I Scratch volume 000507 is now defined in storage pool COPYLTO2_DIR. (PROCESS: 375) 09/15/05 09:35:30 ANR0513I Process 375 opened output volume 000507. (PROCESS: 375) 09/15/05 09:55:04 ANR1173E Space reclamation for offsite volume(s) cannot copy file in storage pool DISKPOOL_DIR: Node X, Type Backup, File space \\X\i$, fsId 5, File name \SMSPKGI$\PAC00055\BW\PLANNING\ MAP. (PROCESS: 375) 09/15/05 09:55:04 ANR0102E asalloc.c(8720): Error 1 inserting row in table "AS.Segments". (PROCESS: 375) Snipped, lots of ANR1173/ANR0102 errors .. I already spoke with IBM, and they told me to issue "REPAIR stgvol" command against the volume being reclamed : 09/15/05 12:22:50 ANR2017I Administrator X issued command: REPAIR STGVOLS voln=000559 (SESSION: 54405) 09/15/05 12:22:50 ANR0984I Process 387 for REPAIR STGVOL started in the BACKGROUND at 12:22:50. (SESSION: 54405, PROCESS: 387) 09/15/05 12:22:50 ANR4752I REPAIR STGVOL process 387 started for 1 volumes. (SESSION: 54405, PROCESS: 387) 09/15/05 12:23:24 ANR4757I REPAIR STGVOL finished evaluating volume 000559, no repair was needed. (SESSION: 54405, PROCESS: 387) 09/15/05 12:23:24 ANR4754I REPAIR STGVOL process 387 ended, processed 1 of 1 total volumes with 0 repaired. (SESSION: 54405, PROCESS: 387) 09/15/05 12:23:24 ANR0987I Process 387 for REPAIR STGVOL running in the BACKGROUND processed 1 items with a completion state of SUCCESS at 12:23:24. (SESSION: 54405, PROCESS: 387) So, it looks like the volume is OK. It's now the second time within 2 weeks that this happens (on different volumes, but always for that storage pool), and I can't figure out what the problem is. Someone having an idea ? Just for info : if I kill the reclamation process and let it automatically start again (even without performing repair stgvol), I don't get any error anymore ... Cheers. Arnaud ** Panalpina Management Ltd., Basle, Switzerland, CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 Direct: +41 (61) 226 19 78 e-mail: [EMAIL PROTECTED] **
Re: Space reclamation
Hi Moses I agree with Richard. (Input files damaged). If you want to reclaim the tapes for re-use, an easy way is to check them into your library, update the volume access to readw, then use the move data command to empty the tape/s Regards Steve Hartland Lechabile Storage Solutions 0824645461 -Original Message- From: Moses Show [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 15, 2004 5:49 PM To: [EMAIL PROTECTED] Subject:Re: Space reclamation Thank you "Mike Bantz" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 15/06/2004 16:40 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject Re: Space reclamation "Offsite volume SPL500L1" is the main clue here - some of your offsite tapes need reclamation, but for fairly obvious reasons that reclamation can't happen right now. Check in those tapes to your library and the reclamation will start up for 'em, even if they're not being marked for vaultretr status or are empty. If you have no plans on bringing them back just for reclamation, I wouldn't worry too much about it. HTH, Mike Bantz -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Moses Show Sent: Tuesday, June 15, 2004 9:35 AM To: [EMAIL PROTECTED] Subject: Space reclamation Earlier on this morning we commenced a Space reclamation job but we being given multiple messages referring to different volume numbers, of the following type ANR1163W Offsite volume SPL500L1 still contains files which could not be moved. However after struggling for a little while we rebooted the server and thses messages appeared to stop. Can anyody shed any light as to why this has happened ? == This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system. == The St. Paul Travelers e-mail system made this annotation on 06/15/2004, 11:31:19 AM. == This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system. == The St. Paul Travelers e-mail system made this annotation on 06/15/2004, 11:45:23 AM.
Re: Space reclamation
Well normally offsite reclamation will use the onsite tapes as input. So you normally don't checkin your offsite tapes for offsite reclamation - they stay offsite and the process reads your onsite tapes. I would check the activity log for other error messages. -Original Message- From: Mike Bantz [mailto:[EMAIL PROTECTED] Sent: June 15, 2004 10:40 AM To: [EMAIL PROTECTED] Subject: Re: Space reclamation "Offsite volume SPL500L1" is the main clue here - some of your offsite tapes need reclamation, but for fairly obvious reasons that reclamation can't happen right now. Check in those tapes to your library and the reclamation will start up for 'em, even if they're not being marked for vaultretr status or are empty. If you have no plans on bringing them back just for reclamation, I wouldn't worry too much about it. HTH, Mike Bantz -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Moses Show Sent: Tuesday, June 15, 2004 9:35 AM To: [EMAIL PROTECTED] Subject: Space reclamation Earlier on this morning we commenced a Space reclamation job but we being given multiple messages referring to different volume numbers, of the following type ANR1163W Offsite volume SPL500L1 still contains files which could not be moved. However after struggling for a little while we rebooted the server and thses messages appeared to stop. Can anyody shed any light as to why this has happened ? == This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system. == The St. Paul Travelers e-mail system made this annotation on 06/15/2004, 11:31:19 AM.
Re: Space reclamation
>Earlier on this morning we commenced a Space reclamation job but we being >given multiple messages referring to different volume numbers, of the >following type > >ANR1163W Offsite volume SPL500L1 still contains files > which could not be moved. > >However after struggling for a little while we rebooted the server and thses >messages appeared to stop. >Can anyody shed any light as to why this has happened ? Well, the Messages manual pretty much explains why this can happen. In http://people.bu.edu/rbs/ADSM.QuickFacts I include some supplementary info. You probably have some onsite volumes (used as representatives of the contents of the offsite volume being reclaimed) which are unavailable or which contain damaged files. Check your Activity Log history for past tape problems, as well as do Query Volume for volumes which are Unavailable or Destroyed. Richard Sims
Re: Space reclamation
Thank you "Mike Bantz" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 15/06/2004 16:40 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject Re: Space reclamation "Offsite volume SPL500L1" is the main clue here - some of your offsite tapes need reclamation, but for fairly obvious reasons that reclamation can't happen right now. Check in those tapes to your library and the reclamation will start up for 'em, even if they're not being marked for vaultretr status or are empty. If you have no plans on bringing them back just for reclamation, I wouldn't worry too much about it. HTH, Mike Bantz -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Moses Show Sent: Tuesday, June 15, 2004 9:35 AM To: [EMAIL PROTECTED] Subject: Space reclamation Earlier on this morning we commenced a Space reclamation job but we being given multiple messages referring to different volume numbers, of the following type ANR1163W Offsite volume SPL500L1 still contains files which could not be moved. However after struggling for a little while we rebooted the server and thses messages appeared to stop. Can anyody shed any light as to why this has happened ? == This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system. == The St. Paul Travelers e-mail system made this annotation on 06/15/2004, 11:31:19 AM. == This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system. == The St. Paul Travelers e-mail system made this annotation on 06/15/2004, 11:45:23 AM.
Re: Space reclamation
"Offsite volume SPL500L1" is the main clue here - some of your offsite tapes need reclamation, but for fairly obvious reasons that reclamation can't happen right now. Check in those tapes to your library and the reclamation will start up for 'em, even if they're not being marked for vaultretr status or are empty. If you have no plans on bringing them back just for reclamation, I wouldn't worry too much about it. HTH, Mike Bantz -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Moses Show Sent: Tuesday, June 15, 2004 9:35 AM To: [EMAIL PROTECTED] Subject: Space reclamation Earlier on this morning we commenced a Space reclamation job but we being given multiple messages referring to different volume numbers, of the following type ANR1163W Offsite volume SPL500L1 still contains files which could not be moved. However after struggling for a little while we rebooted the server and thses messages appeared to stop. Can anyody shed any light as to why this has happened ? == This communication, together with any attachments hereto or links contained herein, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is STRICTLY PROHIBITED. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments hereto or links herein, from your system. == The St. Paul Travelers e-mail system made this annotation on 06/15/2004, 11:31:19 AM.
Re: Space Reclamation Failure Question
Whatever was transferred has been transferred. It doesn't "wipe out" the reclamation that had been done before the failure. More examination of the actlog may reveal reason for failure. Could be as simple as tape error or a restore needed a tape that reclamation was using and preempted the reclamation process. David B. Longo System Administrator Health First, Inc. 3300 Fiske Blvd. Rockledge, FL 32955-4305 PH 321.434.5536 Pager 321.634.8230 Fax:321.434.5509 [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 02/12/04 09:29AM >>> I received the following error: ANR0986I Process 700 for SPACE RECLAMATION running in the BACKGROUND processed 160232 items for a total of 79,052,641,621 bytes with a completion state of FAILURE at 19:48:48. What happens to the tapes that had data transferred to them before the failure occurred? Since the reclamation failed, will those tapes go back to scratch??? Thanks, Marc - The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. ## This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ##
Re: Space reclamation running since 23Dec2003
Looks like there is probably some data that is lost on that tape, unless you have a copy storage pool... To get around that you will want to take the recl up to 100 to pause reclamation, then if you have a copy storage pool, and this tape is in the primary pool mark the volume destroyed, rebuild the volume from the copy pool if you have a copy storage pool, and this tape is in the copy pool mark the volume destroyed, run another backup storage pool to recreate the data on the tape... if you do NOT have a copy storage pool, run an "audit volume" against the tape... fix=yes will delete the bad data run a move data to clear the tape resumre reclamation as normal... hope this helps... Dwight Peter Duempert <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .de> cc: Sent by: "ADSM: Subject: Space reclamation running since 23Dec2003 Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 01/05/2004 11:25 AM Please respond to Peter Duempert Hi TSM'ers, here a sequence of what had happened with a TSM-SERVER 5.1.8.1 on an IBM H70 under AIX 4.3.3-11 and 6 months old 3584-LTO2 library with 4 drives 1. SPACE RECLAMATION started as follows: 23.12.2003 03:16:14 ANR1040I Space reclamation started for volume 373ABW, storage pool LTO_EC (process number 254). 23.12.2003 03:16:14 ANR1044I Removable volume 373ABW is required for space reclamation. 23.12.2003 03:16:16 ANR1142I Moving data for collocation cluster 1 of 23.12.2003 03:39:22 ANR8337I LTO volume 373ABW mounted in drive LTO_3 (/dev/rmt4). 23.12.2003 03:41:32 ANR1142I Moving data for collocation cluster 2 of 6412 on volume 373ABW. 2. Reading errors started rzds3# grep ANR8359 q.actl.20031223.redu 23.12.2003 19:51:55 ANR8359E Media fault detected on LTO volume 373ABW in drive LTO_3 (/dev/rmt4) of library 3584. 23.12.2003 21:32:05 ANR8359E Media fault detected on LTO volume 373ABW in drive LTO_3 (/dev/rmt4) of library 3584. ... and continued rzds3# grep ANR8359 q.actl.2003122*.redu | wc -l 28 rzds3# grep ANR8359 q.actl.2003123*.redu | wc -l 10 rzds3# grep ANR8359 q.actl.200401*.redu | wc -l 14 Until today I got 52 READING-errors, which show up as well in the AIX-based "errpt. 3. The current state tsm: DS3>q proc 254 ProcessProcess Description Status Number - 254Space Reclamation Volume 373ABW (storage pool LTO_EC), Moved Files: 907296, Moved Bytes: 30,652,121,214, Unreadable Files: 558, Unreadable Bytes: 22,733,876. Current Physical File (bytes): None Current input volume: 373ABW. Current output volume: 368ABW. tsm: DS3>q vol 373ABW f=d Volume Name: 373ABW Storage Pool Name: LTO_EC Device Class Name: LTOCL Estimated Capacity (MB): 181,698.7 Pct Util: 12.9 Volume Status: Full Access: Read-Only Pct. Reclaimable Space: 90.2 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 497 Write Pass Number: 1 Approx. Date Last Written: 29.10.2003 10:31:42 Approx. Date Last Read: 05.01.2004 17:37:16 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 53 Volume Location: Last Update by (administrator): Last Update Date/Time: 08.07.2003 06:53:37 tsm: DS3>q actlog begint=18:00 s=ANR1142I Date/TimeMessage -- 05.01.2004 18:00:58 ANR1142I Moving data for collocation cluster
Re: space reclamation on a server storage pool?
John Zlatko is right. Since only TSM1 knows what is on the virtual volume, only TSM1 can perform reclamation of the virtual volume. The TSM designers then had a design choice about how this is acomplished. The obvious way is for reclamation of the virtual volume to be accomplished by mounting the virtual volume to be reclaimed on TSM1 as input, along with a scratch virtual volume for the output. This involves two physical tape mounts on TSM2, but crucially the data would have to pass over the network from TSM2 to TSM1 when it was read and then from TSM1 to TSM2 when it was written. The way it is actually implemented avoids this duplication. TSM uses the fact that the virtual volume is a copy storage pool volume and therefore all the data containted within it will also typically be located on a primary storage pool volume held locally on TSM1. By using this data instead of the data held on the virtual volume, only the writing of the data is performed over the network. So the process has actually been optimised to reduce network utilisation. However, it should be remembered that reclamation of the virtual volume alone is useless without also separately performing reclamtion of the physical volumes on TSM2 in the way that you describe. Going slightly off-topic, it is debatable whether using the primary storage pool volumes as source for the reclamation is optimal in most real-world scenarios. Since the primary storage pool (physical) volumes will typically be co-located and the copy storage pool (virtual) volumes typically won't be, the 50% reduction in network utilisation is more than negated by the increased number of physical tape mounts required. That is to say the mount of a virtual volume as source typically requires only one physical tape mount on the destination server, whereas to mount the physical volumes required from the primary storage pool requires as many tape mounts as there are nodes whose data is contained in the virtual volume (assuming co-location at the node level). Having said that, if there are a large number of virtual volumes to be reclaimed, TSM will optimise the tape mounts from the primary storage pool to ensure each physical volume is only mounted once. With all that said, I've spent five years struggling to get my head round TSM server-to-server comms and now we're just about to rip it out in favour of SAN-based off-siting of data with library-sharing based on Gresham EDT and ACSLS! Neil Schofield Yorkshire Water Services Ltd. Visit our web site to find out about our award winning Cool Schools community campaign at http://www.yorkshirewater.com/yorkshirewater/schools.html The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
Re: space reclamation on a server storage pool?
Because only the DB of TSM1 knows what is in that virtual volume. From TSM2's perspective this is single file and that's it. If that file was Oracle data file, would you expect TSM to know what is the content of it?! Zlatko Krastev IT Consultant John C Dury <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 08.10.2003 07:31 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:space reclamation on a server storage pool? We have 2 systems. TSM1 and TSM2. TSM2 is used solely as an offsite system to backup our primary tape storage pool on TSM1. When I run reclamation on the server storage pool on TSM1, the process requests a mount on TSM2 and a mount on TSM1. It appears to be copying data from the mount on TSM1 to TSM2. Why wouldn't reclamation mount 2 tapes on TSM2 and copy the data that way instead of through the network which is going to be much slower. Essentially it seems like it is going to copy the exact same data from TSM1 to TSM2 two times because it gets copied once during the BACKUP STG command, and then again during the space reclamation of the server storage pool. This seems like a great waste of time when the exact same data should already be on the TSM2 system and could be moved directly from 1 tape to another where it would be considerably faster. Does this make sense? Why would it be done this way? John
Re: Space reclamation
From: Chandrasekhar, C.R [mailto:[EMAIL PROTECTED] > For auto reclamation you must have minimum two tape drives in > your library. This is only partially correct. You can set up automated reclamation for one-drive libraries, but only for primary tape pools; see the relevant admin's guide for details on single-drive reclamation schemes. -- Mark Stapleton ([EMAIL PROTECTED]) Berbee Information Networks Office 262.521.5627
Re: Space reclamation
Questions: (j) Can I use reclaimation when I have got only i1 tape drive and the reclamation pool is to another sequential stgpool? We can do manual reclamation using file device class(sequential), ref Admin guide for instructions. (ii) what is the meaning of insufficient mount points in the message. For info, my client nodes are defined with a max no of 2 mount points. For auto reclamation you must have minimum two tape drives in your library. (iii) Why TSM is not loading the required volume when the tape is alaready in the library? Library does not have two drives to load source and target tapes for auto reclamation. CRC, C.R.Chandrasekhar. Systems Executive. Tivoli Certified Consultant (TSM). TIMKEN Engineering & Research - INDIA (P) Ltd., Bangalore. Phone No: 91-80-5536113 Ext:3032. Email:[EMAIL PROTECTED] -Original Message- From: RAMNAWAZ NAVEEN [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 6:12 PM To: [EMAIL PROTECTED] Subject: Space reclamation Hi, I am quite new to TSM and trying to configure some setups by myself & currebntly facing some problems. My setup is as follows: I run a daily backup for around 200 GB on LTO tapes. I permanently have 3 tapes in a 3590 library defined to a stgpool (UATPOOL). I want to keep the last 3 copies. So I am using the expiry features and want to use reclamation to recover the recalimable space so that my automated backups goes continuosly on these 3 volumes. My problem is that I am geeting the following messages : ANR1040I Space reclamation started for volume UATHOT01, storage pool UAT_POOL (process number 39). ANR1044I Removable volume UATHOT01 is required for space reclamation. ANR0985I Process 39 for SPACE RECLAMATION running in the BACKGROUND completed with completion state FAILURE at 16:13:35. ANR1082W Space reclamation terminated for volume UATHOT01 - insufficient number of mount points available for removable media. ANR1042I Space reclamation for storage pool UAT_POOL will be retried in 60 seconds. ANR1043I Space reclamation retry delay ended; checking volume reclamation status for storage pool UAT_POOL. Questions: (j) Can i use reclaimation when i have got only i1 tape drive and the reclamation pool is to another sequential stgpool? (ii) what is the meaning of insufficient mount points in the message. For info, my client nodes are defined with a max no of 2 mount points. (iii) Why TSM is not loading teh required volume when the tape is alaready in the library? All assistance will be much appreciated Thansk & regards ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
Re: Space reclamation
In my environment i have only one tape drive. To enable tape reclamation for a storage pool that has only one mount point, you can define a sequential reclamation storage pool with a file device class. (read " Reclaiming volumes in a storage pools with one drive " from Administrator guide.pdf) N.Savva TSM Administrator RAMNAWAZ NAVEEN <[EMAIL PROTECTED] To: [EMAIL PROTECTED] U>cc: Sent by: "ADSM: Dist bcc: Stor Manager" Subject: Space reclamation <[EMAIL PROTECTED]> 21/07/2003 03:42 μμ Please respond to "ADSM: Dist Stor Manager" Hi, I am quite new to TSM and trying to configure some setups by myself & currebntly facing some problems. My setup is as follows: I run a daily backup for around 200 GB on LTO tapes. I permanently have 3 tapes in a 3590 library defined to a stgpool (UATPOOL). I want to keep the last 3 copies. So I am using the expiry features and want to use reclamation to recover the recalimable space so that my automated backups goes continuosly on these 3 volumes. My problem is that I am geeting the following messages : ANR1040I Space reclamation started for volume UATHOT01, storage pool UAT_POOL (process number 39). ANR1044I Removable volume UATHOT01 is required for space reclamation. ANR0985I Process 39 for SPACE RECLAMATION running in the BACKGROUND completed with completion state FAILURE at 16:13:35. ANR1082W Space reclamation terminated for volume UATHOT01 - insufficient number of mount points available for removable media. ANR1042I Space reclamation for storage pool UAT_POOL will be retried in 60 seconds. ANR1043I Space reclamation retry delay ended; checking volume reclamation status for storage pool UAT_POOL. Questions: (j) Can i use reclaimation when i have got only i1 tape drive and the reclamation pool is to another sequential stgpool? (ii) what is the meaning of insufficient mount points in the message. For info, my client nodes are defined with a max no of 2 mount points. (iii) Why TSM is not loading teh required volume when the tape is alaready in the library? All assistance will be much appreciated Thansk & regards ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ Privileged/Confidential information may be contained in this message and may be subject to legal privilege. Access to this e-mail by anyone other than the intended recipient is unauthorised. If you are not the intended recipient (or responsible for delivery of the message to such person), you may not use, copy, distribute or deliver to anyone this message (or any part of its contents) or take any action in reliance on it. In such case, you should destroy this message, and notify us immediately. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail from any computer. If you or your employer does not consent to internet e-mail messages of this kind, please notify us immediately. All reasonable precautions have been taken to ensure no viruses are present in this e-mail. As we cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments we recommend that you subject these to your virus checking procedures prior to use. The views, opinions, conclusions and other information expressed in this electronic mail are not given or endorsed by Laiki Group unless otherwise indicated by an authorised representative independent of this message. *
Re: Space Reclamation problem
Bingo! Thank you very much!!! Mark -Original Message- From: David Longo [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 11:44 AM To: [EMAIL PROTECTED] Subject: Re: Space Reclamation problem Do a "query restore" and see if any restartable restores are there. If so and they aren't being used then use "cancel restore x" where x is the session number - note should shoule include the "-" in front of the session number. David B. Longo System Administrator Health First, Inc. 3300 Fiske Blvd. Rockledge, FL 32955-4305 PH 321.434.5536 Pager 321.634.8230 Fax:321.434.5509 [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 07/09/03 11:39AM >>> Hello all, I have a problem with reclaiming two tapes. This is the message I get on the server console: ANR0984I Process 2134 for SPACE RECLAMATION started in the BACKGROUND at 11:28:00. ANR1040I Space reclamation started for volume 000975, storage pool NTWTAPE (process number 2134). ANR1044I Removable volume 000975 is required for space reclamation. ANR1171W Unable to move files associated with node WKS00102, filespace \\wks00102\c$ fsId 1 on volume 000975 due to restore in progress. ANR0985I Process 2134 for SPACE RECLAMATION running in the BACKGRUND completed with completion state FAILURE at 11:28:00. ANR1089W Space reclamation terminated for volume 000975 - lock conflict. I checked current sessions and there are no restores in progress. The server is at 5.1.6.4. Any help would be appreciated Mark Remeta Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately. ## This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ## Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: Space Reclamation problem
Hi, I think there is a restartable restore session on your tsm server that has created a lock file for that particular tape. so use the command "query restore" to find any restartable restore session is available on your tsm server and cancel the session using "cancel restore" command. Hope this should solve your problem regards N.Suresh -Original Message- From: Remeta, Mark [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 5:40 PM To: [EMAIL PROTECTED] Subject: Space Reclamation problem Hello all, I have a problem with reclaiming two tapes. This is the message I get on the server console: ANR0984I Process 2134 for SPACE RECLAMATION started in the BACKGROUND at 11:28:00. ANR1040I Space reclamation started for volume 000975, storage pool NTWTAPE (process number 2134). ANR1044I Removable volume 000975 is required for space reclamation. ANR1171W Unable to move files associated with node WKS00102, filespace \\wks00102\c$ fsId 1 on volume 000975 due to restore in progress. ANR0985I Process 2134 for SPACE RECLAMATION running in the BACKGRUND completed with completion state FAILURE at 11:28:00. ANR1089W Space reclamation terminated for volume 000975 - lock conflict. I checked current sessions and there are no restores in progress. The server is at 5.1.6.4. Any help would be appreciated Mark Remeta Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: Space Reclamation problem
Do a "query restore" and see if any restartable restores are there. If so and they aren't being used then use "cancel restore x" where x is the session number - note should shoule include the "-" in front of the session number. David B. Longo System Administrator Health First, Inc. 3300 Fiske Blvd. Rockledge, FL 32955-4305 PH 321.434.5536 Pager 321.634.8230 Fax:321.434.5509 [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 07/09/03 11:39AM >>> Hello all, I have a problem with reclaiming two tapes. This is the message I get on the server console: ANR0984I Process 2134 for SPACE RECLAMATION started in the BACKGROUND at 11:28:00. ANR1040I Space reclamation started for volume 000975, storage pool NTWTAPE (process number 2134). ANR1044I Removable volume 000975 is required for space reclamation. ANR1171W Unable to move files associated with node WKS00102, filespace \\wks00102\c$ fsId 1 on volume 000975 due to restore in progress. ANR0985I Process 2134 for SPACE RECLAMATION running in the BACKGRUND completed with completion state FAILURE at 11:28:00. ANR1089W Space reclamation terminated for volume 000975 - lock conflict. I checked current sessions and there are no restores in progress. The server is at 5.1.6.4. Any help would be appreciated Mark Remeta Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately. ## This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ##
Re: Space reclamation of offsite copy pool takes forever
Are you running with colocation enabled anywhere? For best reclaim performance, I have found that having colocation enabled=yes on both onsite and offsite pools works the best. Why? Reduction of tape mounts. Cost? Need more tapes, especially in offsite pool. Per pool: Keep in mind that onsite reclamation is 1 process PER tape: find a tape needing reclaim->mount tape->relocate data->dismount. Offsite reclamation is 1 process for ALL tapes: find all tapes needing reclaim->select tape x(these appear to be done in age order)->figure out where all local copies of data are stored->until x is finished(mount onsite tape->relocate data->dismount onsite->next local tape)->next tape x (offiste tape) So it's concievable and likely that one onsite tape could be mounted several times because some of it's files are on multiple offsite tapes. Al "Brazner, Bob" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 11/11/02 05:44 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Space reclamation of offsite copy pool takes forever Reclamation of our offsite copy pool is taking forever. Right now, we have 200+ volumes in that pool. Normally, threshold is set at 60% and I get maybe 8 or 9 volumes returned after processing for 7 hours (on beefy AIX, with TSM at 5.1.5). Lately I've tried setting the threshold at 99, then 98, then 97, etc., but I don't see much improvement in overall freeing up of tapes. It appears that most of the time is taken up with mounting input volumes. Even though we have a 3494, I'd say 80% of the time is spent waiting for tape mounts. Is there any way to get space reclamation to free up offsite tapes faster? Note, for my onsite tape pool, I do not see this problem (e.g., I can easily free up 30 tapes in 5 hours or less). Bob Brazner Johnson Controls, Inc. (414) 524-2570
Re: Space reclamation of offsite copy pool takes forever
Bob, IMHO, you are working too hard. 66% reclaim level will reclaim 3 tapes to get 2 scratches, so must write 1 full tape's worth of data. 80% will reclaim 5 tapes to get 4 scratches, so must write 1 full tape... 90% will reclaim 10 tapes to get 9 scratches, so must write 1 full tape ... So, number1 recommendation from me would be to buy some more tapes and increase your reclaim level. Now the reclaim process will process lots of individual tapes to build that 1 output tape,as you have noted. Thus run it as infrequently as possible to get the maximum value from each pass. I'd suggest kicking it off over the weekend and just letting it go till Monday morning - depending on your load of course. Cancel it then if it hasn't finished. After all, the easiest way to reclaim data is to just let it expire. Regards Steve Harris AIX and TSM Admin Queensland Health, Brisbane Australia. >>> [EMAIL PROTECTED] 12/11/2002 9:44:27 >>> Reclamation of our offsite copy pool is taking forever. Right now, we have 200+ volumes in that pool. Normally, threshold is set at 60% and I get maybe 8 or 9 volumes returned after processing for 7 hours (on beefy AIX, with TSM at 5.1.5). Lately I've tried setting the threshold at 99, then 98, then 97, etc., but I don't see much improvement in overall freeing up of tapes. It appears that most of the time is taken up with mounting input volumes. Even though we have a 3494, I'd say 80% of the time is spent waiting for tape mounts. Is there any way to get space reclamation to free up offsite tapes faster? Note, for my onsite tape pool, I do not see this problem (e.g., I can easily free up 30 tapes in 5 hours or less). Bob Brazner Johnson Controls, Inc. (414) 524-2570 ** This e-mail, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this e-mail is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. **
Re: Space reclamation of offsite copy pool takes forever
This is why I do not use the reclaimation process. I have written a process that does MOVE DATA vv reconstruct=yes commands for the volumes that have less than a reclamation number. I set the reclamation in the storage pool to 100 so they will not reclaim. Then I can run as many simultaneously as my drives can handle, usually 5 to 6. Yes, from the same storage pool. We actually do this because we use closed box and the tapes may return before they are empty, so 14 days before there return I move the data to new volumes going offsite. I also have a second threshold. If the tape has been offsite more than say 14 days and is less than say 10% utilized I reclaim them as well. There are many beauties to this process and only a couple negatives. You get your tapes refreshed at the offsite no matter what. You can use closed box. Keeps the tapes full at whatever level you want. Allows you to have a built in scratch pool for disaster recovery. Keeps collocated volumes down to a minimum (fewer mounts). On the negative side, it requires tape drives. The process is home grown using TSM selects and AIX KSH scripts. We use separate pools for database and exchange backups or similar type data. Those backups do not have to be recycled before return because there are always full copies of these offsite. Maybe ITSM development will take a look at doing something like this in the future. This is the case for smaller storage pools and more of them. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Brazner, Bob [mailto:Bob.Brazner@;JCI.COM] Sent: Monday, November 11, 2002 6:44 PM To: [EMAIL PROTECTED] Subject: Space reclamation of offsite copy pool takes forever Reclamation of our offsite copy pool is taking forever. Right now, we have 200+ volumes in that pool. Normally, threshold is set at 60% and I get maybe 8 or 9 volumes returned after processing for 7 hours (on beefy AIX, with TSM at 5.1.5). Lately I've tried setting the threshold at 99, then 98, then 97, etc., but I don't see much improvement in overall freeing up of tapes. It appears that most of the time is taken up with mounting input volumes. Even though we have a 3494, I'd say 80% of the time is spent waiting for tape mounts. Is there any way to get space reclamation to free up offsite tapes faster? Note, for my onsite tape pool, I do not see this problem (e.g., I can easily free up 30 tapes in 5 hours or less). Bob Brazner Johnson Controls, Inc. (414) 524-2570
Re: Space reclamation of offsite copy pool takes forever
Hello, Have you first tried to see what current reclaimable spaces are available for offsite volumes. Here's a select command which will list all the offsite volumes in the order of pct_reclaimable. Command: select volume_name, stgpool_name, access, pct_reclaim from volumes where stgpool_name='OFF3494' order by pct_reclaim desc Modify the stgpool name for your server It is possible that you don't have any offsite volumes reach are reclaimable at your reclaimable threshold and yes reclaimable process can take a very long time. Sometimes, I was lucky to get even 3 tapes back running thru the night. Also make sure expiration is running. Sung Y. Lee E-mail [EMAIL PROTECTED] "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation of offsite copy pool takes forever Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 11/11/2002 05:44 PM Please respond to "ADSM: Dist Stor Manager" Reclamation of our offsite copy pool is taking forever. Right now, we have 200+ volumes in that pool. Normally, threshold is set at 60% and I get maybe 8 or 9 volumes returned after processing for 7 hours (on beefy AIX, with TSM at 5.1.5). Lately I've tried setting the threshold at 99, then 98, then 97, etc., but I don't see much improvement in overall freeing up of tapes. It appears that most of the time is taken up with mounting input volumes. Even though we have a 3494, I'd say 80% of the time is spent waiting for tape mounts. Is there any way to get space reclamation to free up offsite tapes faster? Note, for my onsite tape pool, I do not see this problem (e.g., I can easily free up 30 tapes in 5 hours or less). Bob Brazner Johnson Controls, Inc. (414) 524-2570
Re: space reclamation when using server-to-server communication
Where do your virtual volumes go ??? (straight to tape or first to a buffer diskpool ???) If they go straight to tape there is the possibility that your second virtual volume to be reclaimed ends up being on the physical volume to which your first reclamation process opened its output volume. (thus the output voume gets closed on the remote server because the tape is rewound to find the second input/reclamation volume) What is the mount retention of your device class for your virtual volumes ??? Generally virtual volumes are only used for a unit of work (or until their estimated capacity is reached), since your reclamation processes are actually TWO different processes I would expect TSM to close that output virtual volume at the end of the first process and thus terminate its use. I would not expect the second process to pick that back up and try to use it... and this might be what is going on in that the virtual volume is closed upon completion of the first reclamation and then the second process tries to use it but it is closed... Try this, if your mount retention for your device class for your virtual volumes isn't zero, try setting it to zero. This way upon completion of the first reclamation every one / all routines involved will agree to close out that virtual volume, then when your second reclamation initiates it will call for a new scratch. NOW for the flip side of my twisted thinking... if your mount retention IS currently zero, try setting it up to 1 or 2, IF currently zero it ~might~ be triggering an early close of the volume even though the one environment knows it has additional work to go to it. BUT generally I'd expect the normal flow of things to be: upon completion of the first reclamation task, the output virtual volume to be closed (since that is a completed unit of work) and upon the initiation of the second reclamation task, a new output virtual volume to be opened... Dwight -Original Message- From: Sascha Braeuning [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 2:35 AM To: [EMAIL PROTECTED] Subject: space reclamation when using server-to-server communication Hello TSMers, I've got a problem with my space reclamation for virtual volumes. We use two TSM Servers Version 4.2.2.0 (OS Sun Solaris 2.7). They do server-to-server communication. When space reclamation starts for the first reclaimable virtual volume in a storage pool, everything looks fine. Then the second reclaimable virtual volume starts their reclamation process and I allways get an ANRD error. Here is what TSM reports: ANR8340I SERVER volume TBS.BFS.032957914 mounted. ANR8340I SERVER volume TBS.BFS.033992020 mounted. ANR1340I Scratch volume TBS.BFS.033992020 is now defined in storage pool REMOTE_UNIX. ANR0986I Process 360 for SPACE RECLAMATION running in the background processed 34 items for a total of 1.997.933 bytes with a completion state of SUCCESS at 14:05:16. ANR1041I Space reclamation ended for volume TBS.BFS.032957914. ANR0984I Process 361 for SPACE RECLAMATION started in the background at 14:05:16. ANR1040I Space reclamation started for volume TBS.BFS.033704013 storage pool REMOTE_UNIX (process number 361). ANR1044I Removable volume TBS.BFS.033704013 is required for space reclamation. ANR8340I SERVER volume TBS.BFS.033704013 mounted. ANR1341I Scratch volume TBS.BFS.032957914 has been deleted from storage pool REMOTE_UNIX. ANR8213E Session 93 aborted due to send error; error 32. ANRD pvrserv.c(918): ThreadId <43> ServWrite: Error writing SERVER volume TBS.BFS.033992020 rc=30. ANR1411W Access mode for volume TBS.BFS.033992020 now set to read-only due to write error. When I move data from TBS.BFS.033992020, no problems occured. Can anybody explain, what happened at the server? MfG/regards Sascha Brduning Sparkassen Informatik, Fellbach OrgEinheit: 6322 Wilhelm-Pfitzer Str. 1 70736 Fellbach Telefon: (0711) 5722-2144 Telefax: (0711) 5722-1634 Mailadr.: [EMAIL PROTECTED]
Re: space reclamation when using server-to-server communication
Sascha Maybe this helps: APAR= IX78238 ANRD PVRSERV.C(833): SERVWRITE: ERROR WRITING SERVER VOLUME X. RC=30 WHEN COMMTIMEOUT VALUE < TIME REQUIRED TO MOUNT TAPE. APAR= IC22660 ANRD PVRSERV.C(833): SERVWRITE: ERROR WRITING SERVER VOLUME X. RC=30 WHEN COMMTIMEOUT VALUE < TIME REQUIRED TO MOUNT TAPE. LOCAL FIX: Increase the commtimeout value on the source server. Jeroen -Original Message- From: Sascha Braeuning [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 9:35 AM To: [EMAIL PROTECTED] Subject: space reclamation when using server-to-server communication Hello TSMers, I've got a problem with my space reclamation for virtual volumes. We use two TSM Servers Version 4.2.2.0 (OS Sun Solaris 2.7). They do server-to-server communication. When space reclamation starts for the first reclaimable virtual volume in a storage pool, everything looks fine. Then the second reclaimable virtual volume starts their reclamation process and I allways get an ANRD error. Here is what TSM reports: ANR8340I SERVER volume TBS.BFS.032957914 mounted. ANR8340I SERVER volume TBS.BFS.033992020 mounted. ANR1340I Scratch volume TBS.BFS.033992020 is now defined in storage pool REMOTE_UNIX. ANR0986I Process 360 for SPACE RECLAMATION running in the background processed 34 items for a total of 1.997.933 bytes with a completion state of SUCCESS at 14:05:16. ANR1041I Space reclamation ended for volume TBS.BFS.032957914. ANR0984I Process 361 for SPACE RECLAMATION started in the background at 14:05:16. ANR1040I Space reclamation started for volume TBS.BFS.033704013 storage pool REMOTE_UNIX (process number 361). ANR1044I Removable volume TBS.BFS.033704013 is required for space reclamation. ANR8340I SERVER volume TBS.BFS.033704013 mounted. ANR1341I Scratch volume TBS.BFS.032957914 has been deleted from storage pool REMOTE_UNIX. ANR8213E Session 93 aborted due to send error; error 32. ANRD pvrserv.c(918): ThreadId <43> ServWrite: Error writing SERVER volume TBS.BFS.033992020 rc=30. ANR1411W Access mode for volume TBS.BFS.033992020 now set to read-only due to write error. When I move data from TBS.BFS.033992020, no problems occured. Can anybody explain, what happened at the server? MfG/regards Sascha Bräuning Sparkassen Informatik, Fellbach OrgEinheit: 6322 Wilhelm-Pfitzer Str. 1 70736 Fellbach Telefon: (0711) 5722-2144 Telefax: (0711) 5722-1634 Mailadr.: [EMAIL PROTECTED]
Re: Space reclamation runs, but tapes don't free up
You can find it documented in the back of the Admin. Reference. I did an audit before upgrading from 4.1.1.5 to 5.1.1.2 and I had to do it again on 5.1.1.6. So if you are going to do an audit, I would recommend waiting until you are on 5.1.1.6 On Wed, 2 Oct 2002, Johnn D. Tan wrote: > Paul: > > What is the exact syntax for auditdb? I've seen you mention it twice > now. I'm on 4.1.3 server (migrating to 5.1.1.6 tomorrow!) and don't > see this mentioned anywhere. This is part of 4.2 and later? > > johnn > > > >My recommendations is for people to get to 4.2.2.12 or higher for those of > >us on 4.2 and get the backupgroups cleaned up before attempting a 5.1.1.6 > >migration. This probably includes running an auditdb before starting the > >ugprade as well. > > > >Paul D. Seay, Jr. > >Technical Specialist > >Naptheon Inc. > >757-688-8180 > > > > > >-Original Message- > >From: Burton, Robert [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, October 02, 2002 9:30 AM > >To: [EMAIL PROTECTED] > >Subject: Re: Space reclamation runs, but tapes don't free up > > > > > >There is a known problem opened with IBM on this... We were told to upgrade > >to tsm 4.2.2.4 or higher...this seemed to clean up most but not all these > >problems... If you q content on the tape it is empty, yet if you try to do > >reclamation or delete it you are informed that there is still data on it > >We were told we would have to issue an auditdb to clean it up...this would > >knock our production server off the air for over 27 hrs...so we opted no to > >do this > > > >When we tried to upgrade from tsm 4.2.2.4 to tsm 5.1.0.0 we experienced the > >following problem: > > > >Item PQ64254 > > > > > > > > APAR Identifier .. PQ64254 Last Changed..02/09/12 > > ANRD IMINIT.C GROUP.MEMBERS ERROR 8 UPGRADEDB > > > >We were informed to upgrade to 5.1.1.4 or higher and run a cleanup > >backupgroups commandthis also fixed nothing > > > >I have an additiona PMR opened with IBM on this problem and am waiting to > >hear back... > > > >thanks > >Robert Burton > >Enterprise Storage Network Analyst > >Royal Bank of Canada > >315 Front St West > >Toronto, On, M5V 3A4 > >* 416-348-3849 > >* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > >-Original Message- > >From: John Naylor [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, October 02, 2002 8:53 AM > >To: [EMAIL PROTECTED] > >Subject: Re: Space reclamation runs, but tapes don't free up > > > > > >Michael, > >Why has your tape got a status of filling ? > >That would be a reason why it would not return to scratch > >Are all your problem tapes like that? > > > > > > > > > >Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM > > > >Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > >To: [EMAIL PROTECTED] > >cc:(bcc: John Naylor/HAV/SSE) > >Subject: Re: Space reclamation runs, but tapes don't free up > > > > > > > >We are having a similar problem with our server (v4.2.2.12, on OS/390 > >v2.10). > > > >Here is my problem: > > > >The reclaim runs, and ends, but the tapes are not being updated as empty. If > >I run an audit of the tape volume, it will then go to empty, and be deleted > >during our next MOVEDRMEDIA command. Here is an expamle of one tape that we > >ran the audit on: > > > > > > > >Before Audit query: > > Volume Name: 321343 > > Storage Pool Name: DEV_TAPEOS > > Device Class Name: 3590_OFFSITE_COPY > > Estimated Capacity (MB): 9,216.0 > > Pct Util: 0.0 > > Volume Status: Filling > >Access: Offsite > >Pct. Reclaimable Space: 100.0 > > Scratch Volume?: Yes > > In Error State?: No > > Number of Writable Sides: 1 > > Number of Times Mounted: 2 > > Write Pass Number: 1 > > Approx. Date Last Written: 08/01/2002 01:20:28 > >Approx. Date Last Read: 08/01/2002 00:31:52 > > Date Became Pending: > >Number of Write Errors: 0 > > Number of Read Errors: 0 > > Volume Location: TSM390 > >ast Update by (administrator): MOOREH > > Last Update Date/Time: 08
Re: Space reclamation runs, but tapes don't free up
Paul: What is the exact syntax for auditdb? I've seen you mention it twice now. I'm on 4.1.3 server (migrating to 5.1.1.6 tomorrow!) and don't see this mentioned anywhere. This is part of 4.2 and later? johnn >My recommendations is for people to get to 4.2.2.12 or higher for those of >us on 4.2 and get the backupgroups cleaned up before attempting a 5.1.1.6 >migration. This probably includes running an auditdb before starting the >ugprade as well. > >Paul D. Seay, Jr. >Technical Specialist >Naptheon Inc. >757-688-8180 > > >-Original Message- >From: Burton, Robert [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 02, 2002 9:30 AM >To: [EMAIL PROTECTED] >Subject: Re: Space reclamation runs, but tapes don't free up > > >There is a known problem opened with IBM on this... We were told to upgrade >to tsm 4.2.2.4 or higher...this seemed to clean up most but not all these >problems... If you q content on the tape it is empty, yet if you try to do >reclamation or delete it you are informed that there is still data on it >We were told we would have to issue an auditdb to clean it up...this would >knock our production server off the air for over 27 hrs...so we opted no to >do this > >When we tried to upgrade from tsm 4.2.2.4 to tsm 5.1.0.0 we experienced the >following problem: > >Item PQ64254 > > > > APAR Identifier .. PQ64254 Last Changed..02/09/12 > ANRD IMINIT.C GROUP.MEMBERS ERROR 8 UPGRADEDB > >We were informed to upgrade to 5.1.1.4 or higher and run a cleanup >backupgroups commandthis also fixed nothing > >I have an additiona PMR opened with IBM on this problem and am waiting to >hear back... > >thanks >Robert Burton >Enterprise Storage Network Analyst >Royal Bank of Canada >315 Front St West >Toronto, On, M5V 3A4 >* 416-348-3849 >* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > >-Original Message- >From: John Naylor [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 02, 2002 8:53 AM >To: [EMAIL PROTECTED] >Subject: Re: Space reclamation runs, but tapes don't free up > > >Michael, >Why has your tape got a status of filling ? >That would be a reason why it would not return to scratch >Are all your problem tapes like that? > > > > >Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM > >Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] >cc:(bcc: John Naylor/HAV/SSE) >Subject: Re: Space reclamation runs, but tapes don't free up > > > >We are having a similar problem with our server (v4.2.2.12, on OS/390 >v2.10). > >Here is my problem: > >The reclaim runs, and ends, but the tapes are not being updated as empty. If >I run an audit of the tape volume, it will then go to empty, and be deleted >during our next MOVEDRMEDIA command. Here is an expamle of one tape that we >ran the audit on: > > > >Before Audit query: > Volume Name: 321343 > Storage Pool Name: DEV_TAPEOS > Device Class Name: 3590_OFFSITE_COPY > Estimated Capacity (MB): 9,216.0 > Pct Util: 0.0 > Volume Status: Filling >Access: Offsite >Pct. Reclaimable Space: 100.0 > Scratch Volume?: Yes > In Error State?: No > Number of Writable Sides: 1 > Number of Times Mounted: 2 > Write Pass Number: 1 > Approx. Date Last Written: 08/01/2002 01:20:28 >Approx. Date Last Read: 08/01/2002 00:31:52 > Date Became Pending: >Number of Write Errors: 0 > Number of Read Errors: 0 > Volume Location: TSM390 >ast Update by (administrator): MOOREH > Last Update Date/Time: 08/01/2002 01:34:34 > > >After Audit query: >Volume Name: 321343 > Storage Pool Name: DEV_TAPEOS > Device Class Name: 3590_OFFSITE_COPY >Estimated Capacity (MB): 0.0 > Pct Util: 0.0 > Volume Status: Empty > Access: Offsite > Pct. Reclaimable Space: 0.0 >Scratch Volume?: Yes >In Error State?: No > Number of Writable Sides: 1 >Number of Times Mounted: 2 > Write Pass Number: 1 > Approx. Date Last Written: 08/01/2002 01:20:28 > Approx. Date Last Read: 08/01/2002 00:31:52 >Date Became Pending: > Number of Write Errors: 0 > Number of Read Errors: 0 >Volume Location: TSM390 >Last Up
Re: Space reclamation runs, but tapes don't free up
My recommendations is for people to get to 4.2.2.12 or higher for those of us on 4.2 and get the backupgroups cleaned up before attempting a 5.1.1.6 migration. This probably includes running an auditdb before starting the ugprade as well. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Burton, Robert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: Re: Space reclamation runs, but tapes don't free up There is a known problem opened with IBM on this... We were told to upgrade to tsm 4.2.2.4 or higher...this seemed to clean up most but not all these problems... If you q content on the tape it is empty, yet if you try to do reclamation or delete it you are informed that there is still data on it We were told we would have to issue an auditdb to clean it up...this would knock our production server off the air for over 27 hrs...so we opted no to do this When we tried to upgrade from tsm 4.2.2.4 to tsm 5.1.0.0 we experienced the following problem: Item PQ64254 APAR Identifier .. PQ64254 Last Changed..02/09/12 ANRD IMINIT.C GROUP.MEMBERS ERROR 8 UPGRADEDB We were informed to upgrade to 5.1.1.4 or higher and run a cleanup backupgroups commandthis also fixed nothing I have an additiona PMR opened with IBM on this problem and am waiting to hear back... thanks Robert Burton Enterprise Storage Network Analyst Royal Bank of Canada 315 Front St West Toronto, On, M5V 3A4 * 416-348-3849 * [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -Original Message- From: John Naylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 8:53 AM To: [EMAIL PROTECTED] Subject: Re: Space reclamation runs, but tapes don't free up Michael, Why has your tape got a status of filling ? That would be a reason why it would not return to scratch Are all your problem tapes like that? Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: John Naylor/HAV/SSE) Subject: Re: Space reclamation runs, but tapes don't free up We are having a similar problem with our server (v4.2.2.12, on OS/390 v2.10). Here is my problem: The reclaim runs, and ends, but the tapes are not being updated as empty. If I run an audit of the tape volume, it will then go to empty, and be deleted during our next MOVEDRMEDIA command. Here is an expamle of one tape that we ran the audit on: Before Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 9,216.0 Pct Util: 0.0 Volume Status: Filling Access: Offsite Pct. Reclaimable Space: 100.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 ast Update by (administrator): MOOREH Last Update Date/Time: 08/01/2002 01:34:34 After Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 0.0 Pct Util: 0.0 Volume Status: Empty Access: Offsite Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 Last Update by (administrator): MOOREH Last Update Date/Time: 09/27/2002 09:49:11 I do have an ETR open with IBM on this issue. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation runs, but tapes don't free up Dist St
Re: Space reclamation runs, but tapes don't free up
If a tape is EMPTY, but the access is OFFSITE, TSM won't delete the tape until the access if change to READWRITE, or the MOVE DRMEDIA to bring the tape back onsite. Until then, the tape will remain EMPTY and won't go scratch. Bill Boyer DSS, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Moore Sent: Wednesday, October 02, 2002 9:11 AM To: [EMAIL PROTECTED] Subject: Re: Space reclamation runs, but tapes don't free up Yes.. I now have approximately 200 tapes in this status, and so far the only fix is to audit each volume. IBM/Tivoli is looking into how they are getting in this state. I am waiting on some trace parms from them. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 John Naylor cc: Sent by: "ADSM: Dist Stor Subject: Re: Space reclamation runs, but tapes don't free up Manager" <[EMAIL PROTECTED]> 10/02/02 08:53 AM Please respond to "ADSM: Dist Stor Manager" Michael, Why has your tape got a status of filling ? That would be a reason why it would not return to scratch Are all your problem tapes like that? Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: Space reclamation runs, but tapes don't free up We are having a similar problem with our server (v4.2.2.12, on OS/390 v2.10). Here is my problem: The reclaim runs, and ends, but the tapes are not being updated as empty. If I run an audit of the tape volume, it will then go to empty, and be deleted during our next MOVEDRMEDIA command. Here is an expamle of one tape that we ran the audit on: Before Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 9,216.0 Pct Util: 0.0 Volume Status: Filling Access: Offsite Pct. Reclaimable Space: 100.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 ast Update by (administrator): MOOREH Last Update Date/Time: 08/01/2002 01:34:34 After Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 0.0 Pct Util: 0.0 Volume Status: Empty Access: Offsite Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 Last Update by (administrator): MOOREH Last Update Date/Time: 09/27/2002 09:49:11 I do have an ETR open with IBM on this issue. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation runs, but tapes don't free up Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 10/01/02 08:13 PM Please respond to "ADSM: Dist Stor Manager" System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation threshold - 60%). The space reclamation process mounts a number of tapes, and a good number of bytes get moved, but the count continues to grow. My onsite tape backup pool does not suffer from this problem. I'm not seeing the number of ANR1341I messages (Scratch volume has been deleted from storage pool ) t
Re: Space reclamation runs, but tapes don't free up
There is a known problem opened with IBM on this... We were told to upgrade to tsm 4.2.2.4 or higher...this seemed to clean up most but not all these problems... If you q content on the tape it is empty, yet if you try to do reclamation or delete it you are informed that there is still data on it We were told we would have to issue an auditdb to clean it up...this would knock our production server off the air for over 27 hrs...so we opted no to do this When we tried to upgrade from tsm 4.2.2.4 to tsm 5.1.0.0 we experienced the following problem: Item PQ64254 APAR Identifier .. PQ64254 Last Changed..02/09/12 ANRD IMINIT.C GROUP.MEMBERS ERROR 8 UPGRADEDB We were informed to upgrade to 5.1.1.4 or higher and run a cleanup backupgroups commandthis also fixed nothing I have an additiona PMR opened with IBM on this problem and am waiting to hear back... thanks Robert Burton Enterprise Storage Network Analyst Royal Bank of Canada 315 Front St West Toronto, On, M5V 3A4 * 416-348-3849 * [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -Original Message- From: John Naylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 8:53 AM To: [EMAIL PROTECTED] Subject: Re: Space reclamation runs, but tapes don't free up Michael, Why has your tape got a status of filling ? That would be a reason why it would not return to scratch Are all your problem tapes like that? Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: Space reclamation runs, but tapes don't free up We are having a similar problem with our server (v4.2.2.12, on OS/390 v2.10). Here is my problem: The reclaim runs, and ends, but the tapes are not being updated as empty. If I run an audit of the tape volume, it will then go to empty, and be deleted during our next MOVEDRMEDIA command. Here is an expamle of one tape that we ran the audit on: Before Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 9,216.0 Pct Util: 0.0 Volume Status: Filling Access: Offsite Pct. Reclaimable Space: 100.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 ast Update by (administrator): MOOREH Last Update Date/Time: 08/01/2002 01:34:34 After Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 0.0 Pct Util: 0.0 Volume Status: Empty Access: Offsite Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 Last Update by (administrator): MOOREH Last Update Date/Time: 09/27/2002 09:49:11 I do have an ETR open with IBM on this issue. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation runs, but tapes don't free up Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 10/01/02 08:13 PM Please respond to "ADSM: Dist Stor Manager" System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation thresh
Re: Space reclamation runs, but tapes don't free up
Yes.. I now have approximately 200 tapes in this status, and so far the only fix is to audit each volume. IBM/Tivoli is looking into how they are getting in this state. I am waiting on some trace parms from them. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 John Naylor cc: Sent by: "ADSM: Dist Stor Subject: Re: Space reclamation runs, but tapes don't free up Manager" <[EMAIL PROTECTED]> 10/02/02 08:53 AM Please respond to "ADSM: Dist Stor Manager" Michael, Why has your tape got a status of filling ? That would be a reason why it would not return to scratch Are all your problem tapes like that? Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: Space reclamation runs, but tapes don't free up We are having a similar problem with our server (v4.2.2.12, on OS/390 v2.10). Here is my problem: The reclaim runs, and ends, but the tapes are not being updated as empty. If I run an audit of the tape volume, it will then go to empty, and be deleted during our next MOVEDRMEDIA command. Here is an expamle of one tape that we ran the audit on: Before Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 9,216.0 Pct Util: 0.0 Volume Status: Filling Access: Offsite Pct. Reclaimable Space: 100.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 ast Update by (administrator): MOOREH Last Update Date/Time: 08/01/2002 01:34:34 After Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 0.0 Pct Util: 0.0 Volume Status: Empty Access: Offsite Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 Last Update by (administrator): MOOREH Last Update Date/Time: 09/27/2002 09:49:11 I do have an ETR open with IBM on this issue. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation runs, but tapes don't free up Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 10/01/02 08:13 PM Please respond to "ADSM: Dist Stor Manager" System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation threshold - 60%). The space reclamation process mounts a number of tapes, and a good number of bytes get moved, but the count continues to grow. My onsite tape backup pool does not suffer from this problem. I'm not seeing the number of ANR1341I messages (Scratch volume has been deleted from storage pool ) that I would expect. Nor, am I seeing the expected number of ANR1342I messages (Scratch volume is now pending - volume will be deleted from storage pool after the reuse delay period for this storage pool has elapsed). I should be seeing one or both messages for each offsite volume reclaimed, right? Because my offsite tapes are not getting reclaimed in a timely fashion, I'm faced with a lack of scratch tapes every day. Any ideas anyone? Bob Brazner Johnson Controls, Inc. (414) 524-2570
Re: Space reclamation runs, but tapes don't free up
Michael, Why has your tape got a status of filling ? That would be a reason why it would not return to scratch Are all your problem tapes like that? Michael Moore <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: Space reclamation runs, but tapes don't free up We are having a similar problem with our server (v4.2.2.12, on OS/390 v2.10). Here is my problem: The reclaim runs, and ends, but the tapes are not being updated as empty. If I run an audit of the tape volume, it will then go to empty, and be deleted during our next MOVEDRMEDIA command. Here is an expamle of one tape that we ran the audit on: Before Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 9,216.0 Pct Util: 0.0 Volume Status: Filling Access: Offsite Pct. Reclaimable Space: 100.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 ast Update by (administrator): MOOREH Last Update Date/Time: 08/01/2002 01:34:34 After Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 0.0 Pct Util: 0.0 Volume Status: Empty Access: Offsite Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 Last Update by (administrator): MOOREH Last Update Date/Time: 09/27/2002 09:49:11 I do have an ETR open with IBM on this issue. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation runs, but tapes don't free up Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 10/01/02 08:13 PM Please respond to "ADSM: Dist Stor Manager" System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation threshold - 60%). The space reclamation process mounts a number of tapes, and a good number of bytes get moved, but the count continues to grow. My onsite tape backup pool does not suffer from this problem. I'm not seeing the number of ANR1341I messages (Scratch volume has been deleted from storage pool ) that I would expect. Nor, am I seeing the expected number of ANR1342I messages (Scratch volume is now pending - volume will be deleted from storage pool after the reuse delay period for this storage pool has elapsed). I should be seeing one or both messages for each offsite volume reclaimed, right? Because my offsite tapes are not getting reclaimed in a timely fashion, I'm faced with a lack of scratch tapes every day. Any ideas anyone? Bob Brazner Johnson Controls, Inc. (414) 524-2570 ** 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. **
Re: Space reclamation runs, but tapes don't free up
We are having a similar problem with our server (v4.2.2.12, on OS/390 v2.10). Here is my problem: The reclaim runs, and ends, but the tapes are not being updated as empty. If I run an audit of the tape volume, it will then go to empty, and be deleted during our next MOVEDRMEDIA command. Here is an expamle of one tape that we ran the audit on: Before Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 9,216.0 Pct Util: 0.0 Volume Status: Filling Access: Offsite Pct. Reclaimable Space: 100.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 ast Update by (administrator): MOOREH Last Update Date/Time: 08/01/2002 01:34:34 After Audit query: Volume Name: 321343 Storage Pool Name: DEV_TAPEOS Device Class Name: 3590_OFFSITE_COPY Estimated Capacity (MB): 0.0 Pct Util: 0.0 Volume Status: Empty Access: Offsite Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 2 Write Pass Number: 1 Approx. Date Last Written: 08/01/2002 01:20:28 Approx. Date Last Read: 08/01/2002 00:31:52 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: TSM390 Last Update by (administrator): MOOREH Last Update Date/Time: 09/27/2002 09:49:11 I do have an ETR open with IBM on this issue. Michael Moore VF Services Inc. 121 Smith Street Greensboro, NC 27420-1488 Voice: 336-332-4423 Fax: 336-332-4544 "Brazner, Bob" cc: Sent by: "ADSM: Subject: Space reclamation runs, but tapes don't free up Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 10/01/02 08:13 PM Please respond to "ADSM: Dist Stor Manager" System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation threshold - 60%). The space reclamation process mounts a number of tapes, and a good number of bytes get moved, but the count continues to grow. My onsite tape backup pool does not suffer from this problem. I'm not seeing the number of ANR1341I messages (Scratch volume has been deleted from storage pool ) that I would expect. Nor, am I seeing the expected number of ANR1342I messages (Scratch volume is now pending - volume will be deleted from storage pool after the reuse delay period for this storage pool has elapsed). I should be seeing one or both messages for each offsite volume reclaimed, right? Because my offsite tapes are not getting reclaimed in a timely fashion, I'm faced with a lack of scratch tapes every day. Any ideas anyone? Bob Brazner Johnson Controls, Inc. (414) 524-2570
Re: Space reclamation runs, but tapes don't free up
Lets make sure you have no volumes in a pending state. Issue this Select Select stgpool_name, volume_name from volumes where status='PENDING' order by stgpool_name, volume_name For each of these you can issue a delete volume vvv and they will immediately return to the scratch pool if they are in the library. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Brazner, Bob [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 8:14 PM To: [EMAIL PROTECTED] Subject: Space reclamation runs, but tapes don't free up System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation threshold - 60%). The space reclamation process mounts a number of tapes, and a good number of bytes get moved, but the count continues to grow. My onsite tape backup pool does not suffer from this problem. I'm not seeing the number of ANR1341I messages (Scratch volume has been deleted from storage pool ) that I would expect. Nor, am I seeing the expected number of ANR1342I messages (Scratch volume is now pending - volume will be deleted from storage pool after the reuse delay period for this storage pool has elapsed). I should be seeing one or both messages for each offsite volume reclaimed, right? Because my offsite tapes are not getting reclaimed in a timely fashion, I'm faced with a lack of scratch tapes every day. Any ideas anyone? Bob Brazner Johnson Controls, Inc. (414) 524-2570
Re: Space reclamation runs, but tapes don't free up
First thing that comes to mind is EXPIRE INVENTORY. Are you running inventory expiration regularly? John -Original Message- From: Brazner, Bob [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 8:14 PM To: [EMAIL PROTECTED] Subject: Space reclamation runs, but tapes don't free up System is TSM 4.1.2.0 on AIX 4.3.3. I run reclamation daily on my tape backup copy pool, but the backlog of unreclaimed tapes continues to grow (as determined by SQL select looking for volumes in the pool that meet my reclamation threshold - 60%). The space reclamation process mounts a number of tapes, and a good number of bytes get moved, but the count continues to grow. My onsite tape backup pool does not suffer from this problem. I'm not seeing the number of ANR1341I messages (Scratch volume has been deleted from storage pool ) that I would expect. Nor, am I seeing the expected number of ANR1342I messages (Scratch volume is now pending - volume will be deleted from storage pool after the reuse delay period for this storage pool has elapsed). I should be seeing one or both messages for each offsite volume reclaimed, right? Because my offsite tapes are not getting reclaimed in a timely fashion, I'm faced with a lack of scratch tapes every day. Any ideas anyone? Bob Brazner Johnson Controls, Inc. (414) 524-2570 ** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company **
Re: Space reclamation of copypool
Besides making rec=100, you have to cancel the
process.
Here is an example using a shell script:
dsmadmc -id=your _id -pa=your_pa q pr | grep -i
"space reclamation" > $tmpdir/process9
if test -s $tmpdir/process
then exec 5<$tmpdir/process
read -r -u5 line
proc=${line%%Space*}
comma=`echo $proc | grep "," | wc -l`
if [ $comma -eq 0 ] ; then
process=$proc
else
process=${proc%%,*}${proc##*,}
fi
print $(date) "Cancelling TSM process $process
on $server ..." >> $maste
rdir/master.log
dsmadmc -id=your _id -pa=your_pa cancel pr
$process>>$tmpdir/end_space_reclaim.log
else print $(date) "No space reclamation processes
found on $server." >> $mas
terdir/master.log
continue
fi
--- Halvorsen Geirr Gulbrand <[EMAIL PROTECTED]> wrote:
> Hello everyone,
> I have the following problem with Space Reclamation
> of my copypool.
> To start reclamation I have a script running UPDATE
> STG COPYPOOL RECLAIM=50
> Three hours later, I run another script to stop
> reclamation - UPDATE STG
> COPYPOOL RECLAIM=100
> but reclamation never stops. This affects all of my
> daily operations
> (migration, backup stgp..) because the
> reclamation process uses both drives.
> Question is, why does space reclamation not stop
> after updating?
> Is there a way of canceling the process (by TSM
> script)?
>
> Best regards
> Geirr G. Halvorsen
=
Thanks,
Manuel J Sanchez
Senior UNIX SA
Assurant Group
(305) 252-7035 x32153
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
Re: Space reclamation of copypool
Hi Geirr! Updating the storagepool does not stop reclamation immediately. TSM stops reclaiming when the reclamation of the current volume has finished. Do you see different behavior? Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Halvorsen Geirr Gulbrand [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 11:15 To: [EMAIL PROTECTED] Subject: Space reclamation of copypool Hello everyone, I have the following problem with Space Reclamation of my copypool. To start reclamation I have a script running UPDATE STG COPYPOOL RECLAIM=50 Three hours later, I run another script to stop reclamation - UPDATE STG COPYPOOL RECLAIM=100 but reclamation never stops. This affects all of my daily operations (migration, backup stgp..) because the reclamation process uses both drives. Question is, why does space reclamation not stop after updating? Is there a way of canceling the process (by TSM script)? Best regards Geirr G. Halvorsen ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Space reclamation of copypool
Space reclamation is based upon a threshold. Just because the threshold is reduced doesn't mean active sessions are cancelled. If you want to cancel the session issue a cancel process command against the process ID. -- Joshua S. Bassi IBM Certified - AIX 4/5L, SAN, Shark eServer Systems Expert -pSeries HACMP Tivoli Certified Consultant - ADSM/TSM Cell (415) 215-0326 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Halvorsen Geirr Gulbrand Sent: Thursday, August 01, 2002 2:15 AM To: [EMAIL PROTECTED] Subject: Space reclamation of copypool Hello everyone, I have the following problem with Space Reclamation of my copypool. To start reclamation I have a script running UPDATE STG COPYPOOL RECLAIM=50 Three hours later, I run another script to stop reclamation - UPDATE STG COPYPOOL RECLAIM=100 but reclamation never stops. This affects all of my daily operations (migration, backup stgp..) because the reclamation process uses both drives. Question is, why does space reclamation not stop after updating? Is there a way of canceling the process (by TSM script)? Best regards Geirr G. Halvorsen
Re: Space reclamation to tapepool
You cannot have "migration" back to disk pool - TSM will not allow you to create closed loop of pools and pool of type DISK cannot be set as reclamation pool. You have to define pool over devclass of type FILE and set it as reclamation pool to the tape pool. And the size of file pool does not need to be large as for the disk one. Its size can be no larger than ammount of data to be reclaimed from a tape. Example: DLT 8000 with estimated capacity 80GB, reclamation threshold 60% gives 80GB*(100-60%)=32GB reclaimable data. If you are in heavy constraint you can shrink further reclamation pool but either reclamation will run in two passes or you have to increase reclamation threshold. Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Space reclamation to tapepool Hello TSM'rs I have a question. Here's my senario, We backup to disk. Then Migrate to tape once the backups complete. I have a single drive tape. the disk capacity is not enough to create another stgpool. I want to execute the processes of space reclamation to the tapes. Do I have some risk if it emigrates again from the tapepool to the diskpool for tapes with 2% use? That cautions should take? your assistance is greatly appreciated. Thanks, Carlos R. Bravo Arredondo [EMAIL PROTECTED] Tel. (55) 51741924
Re: space reclamation question
We used to do this by starting a move data on volume XXX, then looking in the activity log for messages like "Volume 12345 is expected to be mounted". Those messages listed the OTHER volumes that held pieces of files from volume XXX. Ugly... worked, though. > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > Thomas Denier > Sent: Monday, September 10, 2001 1:57 PM > To: [EMAIL PROTECTED] > Subject: Re: space reclamation question > > > Quoting Zlatko Krastev/ACIT <[EMAIL PROTECTED]>: > > > the one which is below the reclamation threshold (the source) - > > look at "q vol" > > and a scratch or private volume for the stg pool (the destination) - > > "def vol" or "upd stg maxscratch=" > > Backup files are sometimes segmented and spread across two or more > storage pool volumes. If a volume below the reclamation threshold > contains one segment of such a file the volumes containing the > other seqments will also be required as input volumes for reclamation. > I don't know of any elegant way to identify the other volumes in such > cases. The ugly way I am aware of starts by running a pair of "query > content" commands with "count=1" and "count=-1" against the below > threshold volume to find out whether that volume starts or ends with > a segmented file. If it does, one can run similar commands against > the other volumes in the same storage pool and look for matching > file names. >
Re: space reclamation question
Quoting Zlatko Krastev/ACIT <[EMAIL PROTECTED]>: > the one which is below the reclamation threshold (the source) - > look at "q vol" > and a scratch or private volume for the stg pool (the destination) - > "def vol" or "upd stg maxscratch=" Backup files are sometimes segmented and spread across two or more storage pool volumes. If a volume below the reclamation threshold contains one segment of such a file the volumes containing the other seqments will also be required as input volumes for reclamation. I don't know of any elegant way to identify the other volumes in such cases. The ugly way I am aware of starts by running a pair of "query content" commands with "count=1" and "count=-1" against the below threshold volume to find out whether that volume starts or ends with a segmented file. If it does, one can run similar commands against the other volumes in the same storage pool and look for matching file names.
Re: space reclamation question
Yep, the one which is below the reclamation threshold (the source) - look at "q vol" and a scratch or private volume for the stg pool (the destination) - "def vol" or "upd stg maxscratch=" ;-) Sorry, cannot be more precise. "Guan, Phillip" <[EMAIL PROTECTED]> on 08.09.2001 21:03:01 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:space reclamation question Hi all, Is there a way to predict which library volume will be needed to do the space reclamation? Thanks. Best regards, Phillip
Re: Space reclamation processes
Richard, Wow! You have "advantageous times" - emphasis on the plural?!?! hehe Seriously, I recently "lucked out" and got my DBA group to schedule backups around a daily maintenance schedule - it only took 7 months of pleading and the implementation of a new DR process (thankfully mandated from "above") to force the issue. I now have a single "advantageous time" and things are running well. MO On Tuesday, June 19, 2001, at 05:11 AM, Richard Sims wrote: >> we have a library with four DLT drives. During the expire inventory, >> several space reclamation processes start, using all drives in the >> library. >> I'd like to keep two drives free for migration. >> Is there a way of limiting the number of drives used by space >> reclamation? > > Stefano - You are letting your reclamations have their way with your > server > by virtue of not controlling the Reclamation Threshold value. > Keep it at 100% until you want Reclamation to occur, by storage pool, > which will then use two drives at a time. Many of us use Admin > Schedules > to let reclamation run at advantageous times. > > Richard Sims, BU >
Re: Space reclamation processes
>we have a library with four DLT drives. During the expire inventory, >several space reclamation processes start, using all drives in the library. >I'd like to keep two drives free for migration. >Is there a way of limiting the number of drives used by space reclamation? Stefano - You are letting your reclamations have their way with your server by virtue of not controlling the Reclamation Threshold value. Keep it at 100% until you want Reclamation to occur, by storage pool, which will then use two drives at a time. Many of us use Admin Schedules to let reclamation run at advantageous times. Richard Sims, BU
Re: Space reclamation processes
Stefano You must have reclamation processes going against more than one storage pool. So the answer is during the time you want to reserve 2 drives for migration update "your pool" recl=100 for all except one tape pool at a time. John ProtoTipo srl <[EMAIL PROTECTED]> on 06/19/2001 11:34:55 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSEG) Subject: Space reclamation processes Hi all, we have a library with four DLT drives. During the expire inventory, several space reclamation processes start, using all drives in the library. I'd like to keep two drives free for migration. Is there a way of limiting the number of drives used by space reclamation? I know there's a device class MOUNTLIMIT parameter, but it affects also other processes such as migration... Thanks in advance, Stefano ** 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 and Southern Electric are trading names of Scottish and Southern Energy Group. **
Re: Space Reclamation Processes
Stefano Reclamation processing starts whenever a storage pool contains volumes which are eligible for migration. That is to say volumes whose 'Percent Reclaimable Space' exceeds the 'Reclamation Threshold' parameter for the storage pool. You will get one process for each storage pool containing eligible volumes. Since the expiration processing will potentially create volumes eligible for reclamation in all storage pools, you are seeing multiple reclamation processes starting as a result. In order to limit your TSM server to one reclamation process at a time, you must ensure that only one storage pool contains eligible volumes. Setting the reclamation threshold for a storage pool to 100% will inhibit all reclamation processing for that storage pool. By scheduling adjustments to reclamation thresholds throughout the day/week/month, you can ensure only one reclamation process. For example: Script scheduled on Monday: UPDATE STGPOOL TAPEPOOL_1 RECLAMATION=60 UPDATE STGPOOL TAPEPOOL_2 RECLAMATION=100 UPDATE STGPOOL TAPEPOOL_3 RECLAMATION=100 Script scheduled on Wednesday: UPDATE STGPOOL TAPEPOOL_1 RECLAMATION=100 UPDATE STGPOOL TAPEPOOL_2 RECLAMATION=60 UPDATE STGPOOL TAPEPOOL_3 RECLAMATION=100 Script scheduled on Friday: UPDATE STGPOOL TAPEPOOL_1 RECLAMATION=100 UPDATE STGPOOL TAPEPOOL_2 RECLAMATION=100 UPDATE STGPOOL TAPEPOOL_3 RECLAMATION=60 You may also wish to consider running your expiration processing at set times of the day, too. To do this, create an admin schedule to run an EXPIRE INVENTORY daily at a given time. You can then set the server option EXPINTERVAL to 0 to inhibit automatic expiration. Hope this helps. Neil The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
