ADSM-L

Re: Ramifications of delete vol xxxxxx discardd=y

2007-03-09 12:10:22
Subject: Re: Ramifications of delete vol xxxxxx discardd=y
From: David McClelland <David.McClelland AT REUTERS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 9 Mar 2007 17:09:50 +0000
Ouch - if this is the case I'm beginning understand... How about the
"update vol xxx acc=destroyed" followed by "restore stgpool xxx" process
as a mechanism not to lose any data?

DMc

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bell, Charles (Chip)
Sent: 09 March 2007 16:09
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Ramifications of delete vol xxxxxx discardd=y

I understand your question, and "why" you would ask...   :)

This is why...

03/09/07   10:05:26  ANR2017I Administrator BC03CB1 issued command: MOVE
DATA
v00040  (SESSION: 41055)
03/09/07   10:05:26  ANR2232W This command will move all of the data
stored
on volume V00040 to other volumes within the same storage pool; the data
will be inaccessible to users until the operation completes. (SESSION:
41055)
03/09/07   10:05:28  ANR1157I Removable volume V00040 is required for
move
                      process. (SESSION: 41055)
03/09/07   10:05:28  ANR0984I Process 308 for MOVE DATA started in the
                      BACKGROUND at 10:05:28. (SESSION: 41055, PROCESS:
308)
03/09/07   10:05:28  ANR1140I Move data process started for volume
V00040
                      (process ID 308). (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:37  ANR8337I 3592 volume V00220 mounted in drive
3592_13
                      (/dev/rmt21). (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:37  ANR0513I Process 308 opened output volume V00220.
                      (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:37  ANR8337I 3592 volume V00040 mounted in drive 3592_1
                      (/dev/rmt9). (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:37  ANR0512I Process 308 opened input volume V00040.
(SESSION: 41055, PROCESS: 308)
03/09/07   10:05:38  ANR8944E Hardware or media error on drive 3592_1
                      (/dev/rmt9) with volume V00040(OP=READ, Error
Number=
                      110, CC=0, KEY=03, ASC=11, ASCQ=00,
 
SENSE=70.00.03.00.00.00.00.12.00.00.00.00.11.00.00.00.00-
                      .00.00.00.00.00.00.00.00.00, Description=An
undetermined error has occurred). Refer to Appendix D in the 'Messages'
manual for recommended action. (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:38  ANR8359E Media fault detected on 3592 volume V00040
in
                      drive 3592_1 (/dev/rmt9) of library 3584_VTL1.
(SESSION: 41055, PROCESS: 308)
03/09/07   10:05:38  ANR8944E Hardware or media error on drive 3592_1
                      (/dev/rmt9) with volume V00040(OP=READ, Error
Number=
                      110, CC=0, KEY=03, ASC=11, ASCQ=00,
 
SENSE=70.00.03.00.00.00.00.12.00.00.00.00.11.00.00.00.00-
                      .00.00.00.00.00.00.00.00.00, Description=An
undetermined error has occurred). Refer to Appendix D in the 'Messages'
manual for recommended action. (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:38  ANR8359E Media fault detected on 3592 volume V00040
in
                      drive 3592_1 (/dev/rmt9) of library 3584_VTL1.
(SESSION: 41055, PROCESS: 308)
03/09/07   10:05:38  ANR8944E Hardware or media error on drive 3592_1
                      (/dev/rmt9) with volume V00040(OP=READ, Error
Number=
                      110, CC=0, KEY=03, ASC=11, ASCQ=00,
 
SENSE=70.00.03.00.00.00.00.12.00.00.00.00.11.00.00.00.00-
                      .00.00.00.00.00.00.00.00.00, Description=An
undetermined error has occurred). Refer to Appendix D in the 'Messages'
manual for recommended action. (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:38  ANR8359E Media fault detected on 3592 volume V00040
in
                      drive 3592_1 (/dev/rmt9) of library 3584_VTL1.
(SESSION: 41055, PROCESS: 308)
03/09/07   10:05:39  ANR8944E Hardware or media error on drive 3592_1
                      (/dev/rmt9) with volume V00040(OP=READ, Error
Number=
                      110, CC=0, KEY=03, ASC=11, ASCQ=00,
 
SENSE=70.00.03.00.00.00.00.12.00.00.00.00.11.00.00.00.00-
                      .00.00.00.00.00.00.00.00.00, Description=An
undetermined error has occurred). Refer to Appendix D in the 'Messages'
manual for recommended action. (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:39  ANR8359E Media fault detected on 3592 volume V00040
in
                      drive 3592_1 (/dev/rmt9) of library 3584_VTL1.
(SESSION: 41055, PROCESS: 308)
03/09/07   10:05:39  ANR1141I Move data process ended for volume V00040.
                      (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:39  ANR0985I Process 308 for MOVE DATA running in the
                      BACKGROUND completed with completion state FAILURE
at
                      10:05:39. (SESSION: 41055, PROCESS: 308)
03/09/07   10:05:39  ANR0514I Session 41055 closed volume V00040.
(SESSION:
                      41055)
03/09/07   10:05:39  ANR0514I Session 41055 closed volume V00220.
(SESSION:
                      41055)
03/09/07   10:05:39  ANR8468I 3592 volume V00040 dismounted from drive
3592_1
                      (/dev/rmt9) in library 3584_VTL1. (SESSION: 41055,

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David McClelland
Sent: Friday, March 09, 2007 10:00 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Ramifications of delete vol xxxxxx discardd=y

I'm not quite sure I'm understanding *why* you'd want to delete the data
on the volume in the first place - if you simply wanted to return the
physical volume to the scratch pool, wouldn't a 'move data' of its
contents to another volume achieve that without getting the sledgehammer
out?

DMc

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thorneycroft, Doug
Sent: 09 March 2007 15:43
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Ramifications of delete vol xxxxxx discardd=y

Just a  note, Only active files will be backed up, you'll lose all
inactive versions.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Bob Booth
Sent: Friday, March 09, 2007 7:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Ramifications of delete vol xxxxxx discardd=y


On Fri, Mar 09, 2007 at 09:35:14AM -0600, Bell, Charles (Chip) wrote:
> Quick question. If I delete a volume to get it back from a read-only 
> access state into the scratch pool, will the next incremental backup 
> for the node data affected back up those files again? Does the 
> database know that there are no longer references for that node data 
> on primary storage? If not, what is the alternative than 'delete vol',
restoring the vol from copy stgpool?

The data will be backed up once again by TSM.  If you do a delete volume
on the primary, the references to the copy data will also be deleted,
and a backup stg will pick that up as well.

hth,

bob



This email was sent to you by Reuters, the global news and information
company. 
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which
Reuters Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building,
South Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered
No: 3296375 Registered in England and Wales
-----------------------------------------
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the individual
or entity named in the address. If you are not the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this information is strictly prohibited. If you received this
information in error, please notify the sender and delete this
information from your computer and retain no copies of any of this
information.



This email was sent to you by Reuters, the global news and information company. 
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, 
except where the sender specifically states them to be the views of Reuters 
Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters 
Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South 
Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales