We currently use CMOD 8.3 fp4 and TSM 5.3 doing stores to a Centera device. We wish to migrate to a different cas; is it possible to somehow move the objects to a different storage device transparently to CMOD, eg. keep the storage node identifiers the same, just have TSM re-locate the objects to a different device?
Thanks.
-walt
Hi Walt.
Is there a specific reason you want to keep the node id's the same? I've been approached about something very similar (but still different), and I've recommended a process where they extract data from the centera, put it into the new node, then tweak the node name in the database to reflect it's new location. It's transparent to the end user, has virtually no chance of data loss, and is instantly reversible should something go wrong.
-JD.
Hi JD,
When I mention node id, I mean the 2nd qualifier in the object id, nnnn-X where X is the id# of the storage node. I would think since it is in the name that it cannot change. When you say 'tweak', is there a utility for doing that? When you say extract data from the centera, is this via a TSM facility or ars utility. The intent is to get rid of the centera in favor of a different storage mechanism (TBD). I appreciate your input.
Thanks,
-walt
Hi Walt.
The object id you're talking about is built from the values in the database tables. Changing the tables changes the object id (and by extension, the load ID).
In terms of 'utilities', I usually custom-build scripts (or sometimes I modify existing ones) for a particular purpose. Those scripts use the IBM ars* programs as much as possible to keep your system in a state that IBM will support -- but I collect information from DB2, TSM, and the filesystem to get the job done safely, quickly, and entirely automatically.
In this situation, I'd use arsadmin retrieve and arsadmin store to pick the items up, and put them into newly configured and defined TSM nodes. The database changes are made with SQL statements for speed, but can also be done with arsdoc for full logging.
There are a few opportunities to consider when making this move, because it's a major one:
- Giving each AG it's own node gives you very fine-grained control over retention without the hassle of implementing Records Manager.
- If you have a large system, this may present an opportunity to offload the TSM component to another system, like the purpose-built IBM DR550.
- If your system is more than a few years old, and you have data that isn't compressed with OD77, you could save a substantial amount of storage space by re-compressing your data.
- Since you're shuffling all this data around, it might be a good opportunity to improve performance by reviewing your retrieval patterns, and 'backfilling' your cache filesystem for Folders that hit TSM a lot.
Good luck!
Ok. trying to play with the arsadmin for moving stuff. Run from command line:
arsadmin retrieve -g Dev-Documents3 -n 7-0 -m 2 -u xxxx -p xxxx -h ARCHIVE 5501-7-0-5FAA-14385-14385
I get:
An unexpected error occurred. Contact your System Administrator and/or consult the System Log. File=arsadmin.c, Line=1234
Unable to retrieve the object >5501-7-0-5FAA-14385-14385<
and:
Object >5501-7-0-5FA< in Application Group >YGA< not found in node >oddevt1< Srvr->o
ddevaix 10.19.2.146<-|
|ARCHIVE|05/20/09 12:49:03|2002980|ADMIN||2|20|SM Error: ANS1302E (RC2) No objects on server match query
, RC=2, Reason=0, File=arssmsms.C, Line=861 Srvr->oddevaix 10.19.2.146<-|
Yet, I can issue a arsdoc get with same load-id and group and it works. There is no example in the manual of arsadmin, but I see nothing wrong the syntax..... Tried variations....
ANy ideas?
Thanks,
-walt
Hi Walt.
For arsadmin, you only need to use the Object ID -- '123FAAA'.
Good luck!
-JD.