Re: Delete volume problem
On Apr 3, 2008, at 10:52 AM, Thomas Denier wrote: -Wanda Prather wrote: - No good way around it, except to run your DELETE VOLUMES serially and with NOTHING ELSE going on. Or upgrade past the bug. Search www.ibm.com: IC50659 If I understand the problem correctly, even having nothing else going on is insufficient. Some of our tape storage pools have three day reusedelay settings, so a volume deletion can occur when there is no current server activity, as a delayed result of a volume being emptied three days earlier. The automatic removal of volumes that had been in empty-Pending state is not an issue: deleting volumes containing data (DISCARDdate=Yes) is a problem, because of the intensity of the database operation. Richard Sims
Re: Delete volume problem
-Wanda Prather wrote: - >No good way around it, except to run your DELETE VOLUMES serially >and with NOTHING ELSE going on. Or upgrade past the bug. Search >www.ibm.com: IC50659 If I understand the problem correctly, even having nothing else going on is insufficient. Some of our tape storage pools have three day reusedelay settings, so a volume deletion can occur when there is no current server activity, as a delayed result of a volume being emptied three days earlier.
Re: Delete volume problem
Been there..done thatread the book...saw the movie. I feel your pain. We had the same problem and had to do this - over a long holiday.the non-full audit ran 4-days when the DB was only 80GB. Now up to 160GB. I would not want to perform a full audit at this point. "Mcnutt, Larry E." <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 04/02/2008 04:21 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Delete volume problem We have a database corruption problem that apparently was a result of a failed "delete volume". We are at version 5.3.3.0. The effects we experience are that expiration logs a few thousand errors daily, and we cannot run "delete file" for some defunct nodes. The solution from TSM support is to upgrade to at least 5.4.1.2 and then run an auditdb. I have verified on a test instance that this solution works, but it takes almost 24 hours to run. The TSM database is 70GB at 90 percent. Looking forward to the outage in June. Larry McNutt -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: Wednesday, April 02, 2008 2:03 PM To: ADSM-L@VM.MARIST.EDU Subject: Delete volume problem We have a 5.3.4.0 TSM server running under mainframe Linux. We are in the process of migrating some of our offsite copies to newer tape technology. Yesterday I finished backing up all the data in one of our primary tape pools to a new copy storage pool. This morning I started deleting the volumes from the old copy storage pool previously used for offsite copies of the same primary pool. The first couple of 'delete volume' commands worked fine. The third one was running when our automation started a snapshot database backup. The snapshot process froze with 0 of 0 pages backed up. The 'delete volume' process froze. A number of migration processes running at the time stopped moving data. Node sessions went into permanent run status and stopped moving data. I executed a 'cancel process' command for the 'delete volume' process. It had no visible effect. A little while later I issued a 'cancel process' command for the snapshot process. It caused the status reported by 'query process' to change to 'Cancel pending' but otherwise had no visible effect. I finally shut down the TSM server. I then had to wait some minutes for a defunct dsmserv process to go away before I could restart the TSM server. Later in the day our automation ran an incremental database backup. Once the backup process was safely under way I tried another 'delete volume' command. The 'delete volume' process deleted a few hundred files and then froze. Migration processes and node sessions stopped moving data. The database backup continued to run until it had written all the necessary database pages and dismounted the output tape. It then froze. I was once again unable to cancel either the database backup or the 'delete volume' process. I had the same problem with a defucnt dsmserv process when I stopped the server for the second time that day. Are there any other TSM functions that cannot co-exist safely with 'delete volume' processes? We are preparing to upgrade our TSM server to 5.4.2.0. Will the de facto rules about when to run 'delete volume' processes be different under this release? - 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 / The Timken Corporation
Re: Delete volume problem
I am not sure how you try to delete thoose volumes, but. This should work. Create a OS script with multiple lines like: Dsmadsmc -id=x -password=y del vol xyz discarddata=yes wait=y Dsmadsmc -id=x -password=y del vol zyx discarddata=yes wait=y Etc. If you create a script in TSM or run multiple del vol commands in a macro you will get the deadlock you are seeing. Been there.. //Henrik -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: den 2 april 2008 22:21 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Delete volume problem No good way around it, except to run your DELETE VOLUMES serially and with NOTHING ELSE going on. Or upgrade past the bug. Search www.ibm.com: IC50659 On 4/2/08, David Longo <[EMAIL PROTECTED]> wrote: > > I think there is an occasional problem with "Delete Volume" > at that TSM server version that can hang things. > > I seem to recall is fixed in TSM 5.3.5.x or close. > > David Longo > > >>> Thomas Denier <[EMAIL PROTECTED]> 4/2/2008 2:02 > >>> PM > >>> > We have a 5.3.4.0 TSM server running under mainframe Linux. We are in > the process of migrating some of our offsite copies to newer tape > technology. Yesterday I finished backing up all the data in one of our > primary tape pools to a new copy storage pool. This morning I started > deleting the volumes from the old copy storage pool previously used > for offsite copies of the same primary pool. The first couple of > 'delete volume' commands worked fine. The third one was running when > our automation started a snapshot database backup. > The snapshot process froze with 0 of 0 pages backed up. The 'delete > volume' process froze. A number of migration processes running at the > time stopped moving data. Node sessions went into permanent run status > and stopped moving data. I executed a 'cancel process' command for the > 'delete volume' process. It had no visible effect. A little while > later I issued a 'cancel process' command for the snapshot process. It > caused the status reported by 'query process' to change to 'Cancel > pending' but otherwise had no visible effect. I finally shut down the > TSM server. I then had to wait some minutes for a defunct dsmserv > process to go away before I could restart the TSM server. > > Later in the day our automation ran an incremental database backup. > Once the backup process was safely under way I tried another 'delete > volume' command. The 'delete volume' process deleted a few hundred > files and then froze. Migration processes and node sessions stopped > moving data. The database backup continued to run until it had written > all the necessary database pages and dismounted the output tape. It > then froze. I was once again unable to cancel either the database > backup or the 'delete volume' process. I had the same problem with a > defucnt dsmserv process when I stopped the server for the second time > that day. > > Are there any other TSM functions that cannot co-exist safely with > 'delete volume' processes? We are preparing to upgrade our TSM server > to 5.4.2.0. Will the de facto rules about when to run 'delete volume' > processes be different under this release? > > > > # > This message is for the named person's use only. It may contain > private, proprietary, or legally privileged information. > No 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. > # > --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you.
Re: Delete volume problem
No good way around it, except to run your DELETE VOLUMES serially and with NOTHING ELSE going on. Or upgrade past the bug. Search www.ibm.com: IC50659 On 4/2/08, David Longo <[EMAIL PROTECTED]> wrote: > > I think there is an occasional problem with "Delete Volume" > at that TSM server version that can hang things. > > I seem to recall is fixed in TSM 5.3.5.x or close. > > David Longo > > >>> Thomas Denier <[EMAIL PROTECTED]> 4/2/2008 2:02 PM > >>> > We have a 5.3.4.0 TSM server running under mainframe Linux. We are > in the process of migrating some of our offsite copies to newer tape > technology. Yesterday I finished backing up all the data in one of > our primary tape pools to a new copy storage pool. This morning I > started deleting the volumes from the old copy storage pool > previously used for offsite copies of the same primary pool. The > first couple of 'delete volume' commands worked fine. The third one > was running when our automation started a snapshot database backup. > The snapshot process froze with 0 of 0 pages backed up. The 'delete > volume' process froze. A number of migration processes running at the > time stopped moving data. Node sessions went into permanent run > status and stopped moving data. I executed a 'cancel process' command > for the 'delete volume' process. It had no visible effect. A little > while later I issued a 'cancel process' command for the snapshot > process. It caused the status reported by 'query process' to change to > 'Cancel pending' but otherwise had no visible effect. I finally > shut down the TSM server. I then had to wait some minutes for a > defunct dsmserv process to go away before I could restart the TSM > server. > > Later in the day our automation ran an incremental database backup. > Once the backup process was safely under way I tried another 'delete > volume' command. The 'delete volume' process deleted a few hundred > files and then froze. Migration processes and node sessions stopped > moving data. The database backup continued to run until it had > written all the necessary database pages and dismounted the output > tape. It then froze. I was once again unable to cancel either the > database backup or the 'delete volume' process. I had the same > problem with a defucnt dsmserv process when I stopped the server > for the second time that day. > > Are there any other TSM functions that cannot co-exist safely with > 'delete volume' processes? We are preparing to upgrade our TSM > server to 5.4.2.0. Will the de facto rules about when to run > 'delete volume' processes be different under this release? > > > > # > This message is for the named person's use only. It may > contain private, proprietary, or legally privileged information. > No 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: Delete volume problem
We have a database corruption problem that apparently was a result of a failed "delete volume". We are at version 5.3.3.0. The effects we experience are that expiration logs a few thousand errors daily, and we cannot run "delete file" for some defunct nodes. The solution from TSM support is to upgrade to at least 5.4.1.2 and then run an auditdb. I have verified on a test instance that this solution works, but it takes almost 24 hours to run. The TSM database is 70GB at 90 percent. Looking forward to the outage in June. Larry McNutt -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: Wednesday, April 02, 2008 2:03 PM To: ADSM-L@VM.MARIST.EDU Subject: Delete volume problem We have a 5.3.4.0 TSM server running under mainframe Linux. We are in the process of migrating some of our offsite copies to newer tape technology. Yesterday I finished backing up all the data in one of our primary tape pools to a new copy storage pool. This morning I started deleting the volumes from the old copy storage pool previously used for offsite copies of the same primary pool. The first couple of 'delete volume' commands worked fine. The third one was running when our automation started a snapshot database backup. The snapshot process froze with 0 of 0 pages backed up. The 'delete volume' process froze. A number of migration processes running at the time stopped moving data. Node sessions went into permanent run status and stopped moving data. I executed a 'cancel process' command for the 'delete volume' process. It had no visible effect. A little while later I issued a 'cancel process' command for the snapshot process. It caused the status reported by 'query process' to change to 'Cancel pending' but otherwise had no visible effect. I finally shut down the TSM server. I then had to wait some minutes for a defunct dsmserv process to go away before I could restart the TSM server. Later in the day our automation ran an incremental database backup. Once the backup process was safely under way I tried another 'delete volume' command. The 'delete volume' process deleted a few hundred files and then froze. Migration processes and node sessions stopped moving data. The database backup continued to run until it had written all the necessary database pages and dismounted the output tape. It then froze. I was once again unable to cancel either the database backup or the 'delete volume' process. I had the same problem with a defucnt dsmserv process when I stopped the server for the second time that day. Are there any other TSM functions that cannot co-exist safely with 'delete volume' processes? We are preparing to upgrade our TSM server to 5.4.2.0. Will the de facto rules about when to run 'delete volume' processes be different under this release? - 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 / The Timken Corporation
Re: Delete volume problem
I think there is an occasional problem with "Delete Volume" at that TSM server version that can hang things. I seem to recall is fixed in TSM 5.3.5.x or close. David Longo >>> Thomas Denier <[EMAIL PROTECTED]> 4/2/2008 2:02 PM >>> We have a 5.3.4.0 TSM server running under mainframe Linux. We are in the process of migrating some of our offsite copies to newer tape technology. Yesterday I finished backing up all the data in one of our primary tape pools to a new copy storage pool. This morning I started deleting the volumes from the old copy storage pool previously used for offsite copies of the same primary pool. The first couple of 'delete volume' commands worked fine. The third one was running when our automation started a snapshot database backup. The snapshot process froze with 0 of 0 pages backed up. The 'delete volume' process froze. A number of migration processes running at the time stopped moving data. Node sessions went into permanent run status and stopped moving data. I executed a 'cancel process' command for the 'delete volume' process. It had no visible effect. A little while later I issued a 'cancel process' command for the snapshot process. It caused the status reported by 'query process' to change to 'Cancel pending' but otherwise had no visible effect. I finally shut down the TSM server. I then had to wait some minutes for a defunct dsmserv process to go away before I could restart the TSM server. Later in the day our automation ran an incremental database backup. Once the backup process was safely under way I tried another 'delete volume' command. The 'delete volume' process deleted a few hundred files and then froze. Migration processes and node sessions stopped moving data. The database backup continued to run until it had written all the necessary database pages and dismounted the output tape. It then froze. I was once again unable to cancel either the database backup or the 'delete volume' process. I had the same problem with a defucnt dsmserv process when I stopped the server for the second time that day. Are there any other TSM functions that cannot co-exist safely with 'delete volume' processes? We are preparing to upgrade our TSM server to 5.4.2.0. Will the de facto rules about when to run 'delete volume' processes be different under this release? # This message is for the named person's use only. It may contain private, proprietary, or legally privileged information. No 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. #
Delete volume problem
We have a 5.3.4.0 TSM server running under mainframe Linux. We are in the process of migrating some of our offsite copies to newer tape technology. Yesterday I finished backing up all the data in one of our primary tape pools to a new copy storage pool. This morning I started deleting the volumes from the old copy storage pool previously used for offsite copies of the same primary pool. The first couple of 'delete volume' commands worked fine. The third one was running when our automation started a snapshot database backup. The snapshot process froze with 0 of 0 pages backed up. The 'delete volume' process froze. A number of migration processes running at the time stopped moving data. Node sessions went into permanent run status and stopped moving data. I executed a 'cancel process' command for the 'delete volume' process. It had no visible effect. A little while later I issued a 'cancel process' command for the snapshot process. It caused the status reported by 'query process' to change to 'Cancel pending' but otherwise had no visible effect. I finally shut down the TSM server. I then had to wait some minutes for a defunct dsmserv process to go away before I could restart the TSM server. Later in the day our automation ran an incremental database backup. Once the backup process was safely under way I tried another 'delete volume' command. The 'delete volume' process deleted a few hundred files and then froze. Migration processes and node sessions stopped moving data. The database backup continued to run until it had written all the necessary database pages and dismounted the output tape. It then froze. I was once again unable to cancel either the database backup or the 'delete volume' process. I had the same problem with a defucnt dsmserv process when I stopped the server for the second time that day. Are there any other TSM functions that cannot co-exist safely with 'delete volume' processes? We are preparing to upgrade our TSM server to 5.4.2.0. Will the de facto rules about when to run 'delete volume' processes be different under this release?
