You need to isolate the data for that server/filespace in the copypool in
order to delete ONLY that data. I've used this brute force method before:
Turn colocation on for the copypool at client/filespace level as needed.
find copypool volumes containing data for the client using: select
volume_name from volumeusage where node_name='...client name...' and
stgpool_name='...blah...' and filespace_name='..fs name as needed'
MOVE DATA for each of these volumes (this should create a new set of
tapes containing only the data for the specific node
UPD vol ...blah... ACC=reado for output volumes from step 3
Turn off colocation on copypool
Optionally, Q CON for each volume from step 3 to verify what's on each
volume from step 3
DEL VOL DISCARDD=YES for each volume from step 3
If someone's got a better way, please let me know!
Over a year ago I submitted these enhancement requests
Add the NODENAME= parameter to the MOVE DATA command (we got a partial
solution with the MOVE NODEDATA, but it only works for primary pools)
Add the STGPOOL= parameter to the DELETE FILESPACE command (this would
eliminate the steps above)
By allowing MOVE NODEDATA to work with copypools and by providing the
enhanced DELETE FILESPACE, we gain much needed ability to manage our
backend storage.
--
Al
John Naylor <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
02/05/03 04:51 AM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Move nodedata
Can't you just delete the volumes in the old copy storage pool ?
That seems too easy, so I could be wrong
"Zlatko Krastev/ACIT" <[EMAIL PROTECTED]> on 02/05/2003 06:15:11 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: John Naylor/HAV/SSE)
Subject: Re: Move nodedata
Bruce,
your mistake is *by design*. You can move data (with both "move data" and
"move nodedata") between *primary* pools. Copypools *do not* contain
node's data, they contain primary pools' data copies.
To achieve the goal I would suggest you the following:
1. create new primary pool (if not done already)
2. create new policy domain, set its copygroups to point new primary pool
and move the node into it
3. export the node's data, delete filespaces ...
4. ... and import it back (sorry I know it is time consuming and might
look silly)
5. backup the primary pool to second copypool (C1_FS_DRMP)
Now what am I proposing:
- in step 3 the data will be deleted from both originating primary pool
and the "source" copypool. This is the only way I know to clean up the
copypool.
- in step 4 the data will be imported back into the server but in new
primary pool.
- steps 3-4 result similar to "move nodedata" but with deletion from
copypool
- step 5 is explanatory by itself
If you can afford the data to stay in old copypool until it expires on its
own you can use "move nodedata" and "backup stgpool" to finish faster. If
you insist to clean the old copypool and have copies only in primary pools
and new copypool then you have to go down the export-import road.
Zlatko Krastev
IT Consultant
"Kamp, Bruce" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03.02.2003 14:03
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Move nodedata
I need to move a couple of nodes from one offsite copy pool to another
offsite copy pool. I tried using the move nodedata command but It gives
me
the following error:
ANR1719E Storage pool C1_FS_DRMP specified on the MOVE NODEDATA command is
not a
valid pool name or pool type.
ANS8001I Return code 3.
This is the command I was using: move nodedata tsmserv from=drmpool
to=C1_FS_DRMP TYPE=any
>From reading the help is it my understanding that I can not do this with
the
move nodedata?
If not. Will this work?
1. Bind nodes to new management class.
2. Use move nodedata command to move onsite data to new storage pool.
3. Use backup stgpool from new onsite storage pool to new offsite copy
storage pool.
4. This is the step I'm not sure about! How do I remove the data from
the
old offsite storage pool?
Thanks,
--------------------------------------
Bruce Kamp
Midrange Systems Analyst II
Memorial Healthcare System
E: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
P: (954) 987-2020 x4597
F: (954) 985-1404
---------------------------------------
**********************************************************************
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.
**********************************************************************
