copying part of AGs to new server

[Michel de Kraker]

Goodday all,

March 1st 2017  i copied an entire production CMOD Environment (db2 and tsm stgpool) to another system for testing purposes etc.
Now i want to migrate all documents loaded since March 1st 2017 in the production environment , to the test server to have it uptodate again.

I was thinking about arsadmin retrieve (production server) and then arsadmin store (test environment). Is this a working solution or are there any other ideas for this? Maybe via arsxml ?

Thx,

Michel.

[jsquizz]

Not aware of a way to do this with arsxml, I am pretty sure that won't work.

I would do a retrieve, and then arsload to load them back up. Shouldn't be that bad.

How many objects, GB/TB of data are you working with?

[Michel de Kraker]

thankyou jsquizz for your reaction. 

So you mean the following sequence? :

arsadmin retrieve
then arsload the extracted documents.

Can you select a search date in the arsadmin retrieve document?

We are talking about approx. 20-30GB of data.

Does anyone else have any other thoughts besides the arsadmin retrieve option?
I've done this a few years ago , and had a lot of issues with resources with arsload .

Kind regards,

Michel.

[ronankivr]

You can also use arsdoc get and arsload to perform this.

[Michel de Kraker]

Thx all for replies , very much appreciated.

I think the best way to go is arsdoc get and arsload. I will test this procedure.

Can someone provide me with an example of this? I just found out (since i am working with cmod 8.5 , i know , out of support :-) ) , that i need to identify all fields with the arsdoc get command. Looks  a bit timeconsuming to sort this all out. Is there another way perhaps with arsdoc get?

Kind regards,

Michel.

[Norbert Novotny]

You can also use arsdoc get and arsload to perform this.

I think that would be way too sloooow; assuming you have copied the database (respective segment tables), the arsadmin retrieve and store is the right way to go. As hint, (As Alessandro suggested once to me) use multiple doc_names on the command line (e.g. 1000+ should not be an issue on Unix) will increase the export speed.

[Justin Derrick]

There *are* limitations in SQL statement size, as well as inside the UNIX shell, *and* in the arsdoc command itself...  You can change the maximum SQL statement size in DB2, and the shell 'environment' size in AIX.  (Older versions of AIX needed a reboot, but I'm not sure that it's required anymore.) 

As for arsdoc, I think the limit is hard coded, and the only solution is to reduce the size of the SQL command you're trying to pass to the database.

-JD.

[Michel de Kraker]

Thx norbert for this reply.

I like the arsadmin retrieve and arsload method.
But with what command/procedure i will export the part of the table and store it in the new server?

Kind regards,

Michel.

You can also use arsdoc get and arsload to perform this.

I think that would be way too sloooow; assuming you have copied the database (respective segment tables), the arsadmin retrieve and store is the right way to go. As hint, (As Alessandro suggested once to me) use multiple doc_names on the command line (e.g. 1000+ should not be an issue on Unix) will increase the export speed.

[Michel de Kraker]

Goodday to you all.

Getting more and more to a solution for my problem of copying data from 1 server to another.

I would like to have a discussion on a scenario for copying a full cmod environment (CMOD 8.5.0.6 , TSM 7.1)

Last monday i made a fresh copy of the full cmod environment.  serverA to serverB

So serverB is in sync with CMOD DB2 and TSM until last monday.
ServerB is now active on another LPAR.

Now i want to synchronise serverA with serverB the coming 2 months. This is because (a part of) serverB will be in production on another site end of august.
Until end of august i should sync serverA with serverB so all filespaces on the TSM server will be in sync.

The plan is as follows:

Keep TSM serverA with TSM serverB in sync until 30-08.
On 30-08 i will make a full DB2 backup of CMOD DB2 serverA and restore this backup on CMOD DB2 serverB.

I know CMOD DB2 keeps a record of TSM filespaces and the CMOD documents. So when i restore the CMOD DB2 on CMOD serverB i have a complete working CMOD environment on ServerB (Both CMOD DB2 and TSM)

Am is missing something here or does this sound like a eligable approach.

Opinions and remarks greatly appreciated.

Kind regards,

Michel.   

[Norbert Novotny]

Hi Michael, not sure if this is not a bit too late reply 
What you have describe in terms of copy / cloning the complete CMOD that works and yes I am using it just like you described.
However when are you trying to copy only partial database e.g. documents archive after the date X
I would scripted with DB2 export index table by index table (a dynamic SQL (sql generating sql) would help) and as part of export you can place restrictions (where clause) with your where mydate >= X.
then use arsadmin retrieve and store for matching doc_names.
One warning: Don't forget about resources and doc_name1 files they are not listed in index segments but rather in arsres. The doc_name1 are not listed at all in CMOD but are not vital, however nice to have  the doc_names (in case of AFP or PDFs)
Good luck,
N.

[Alessandro Perucchi]

One warning: Don't forget about resources and doc_name1 files they are not listed in index segments but rather in arsres. The doc_name1 are not listed at all in CMOD but are not vital, however nice to have  the doc_names (in case of AFP or PDFs)

I would just put a word of warning here... if you see in TSM/Cache/... a file where it finished with a 1 like for example: 123FAA1, then I would not considere it as "nice to have" anymore, but I will copy it in the new system.
I have learned that CMOD use it from time to time for some actions/tests... therefore PLEASE consider these files as important as the Objects of your archive.