Author Topic: 'export' of all data from one OD-instance to another  (Read 3222 times)

jine01

  • Newbie
  • *
  • Posts: 8
    • View Profile
'export' of all data from one OD-instance to another
« on: October 31, 2017, 05:03:17 AM »
Hi

We've been asked to do an 'export' of all data from one OD-instance to another.
We're using OAM to store the data, which all concludes of AFP-documents.

They want us to convert about 2500 Application groups, and have about 2.100.000 loads, which
is about 2TB of data in OAM.

I have 2 questions..

1) Does anyone have experience in doing such a conversion and would like to share the experience about
- What to consider ?
- How long time would we estimate for such an activity?
(We know that the time estimation includes tape wait/tape mount and so forth)

 Did any of you get some help from IBM or any of IBM's business partner.

2) Is it anyone who has tried to use the new function in z/OS 2.3, using two
oam-plexes in the same lpar ?

Jimmy N

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 1204
    • View Profile
Re: 'export' of all data from one OD-instance to another
« Reply #1 on: October 31, 2017, 07:33:05 AM »
Quote
2) Is it anyone who has tried to use the new function in z/OS 2.3, using two
oam-plexes in the same lpar ?

In a conversation last week with OAM Level 2 I asked this very question.

The answer is absolutely you can have two different OAMplexes active in the same LPAR.

Ed
#zOS #ODF

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: 'export' of all data from one OD-instance to another
« Reply #2 on: October 31, 2017, 08:09:31 AM »
We've completed 3 migrations from one OD instance to another.  Two were from Windows to z/OS and one was from AIX to z/OS, the most recent about 2 years ago going from an 8.4 Windows to an 9.5 z/OS server. 1,400 AGs and 1TB+ of data Going from CMOD to CMOD was much nicer than our other migrations from other products.  We did not use IBM services for this last migration.
XML export and XML import to move AGs , Apps, users etc... generally worked well though we ran into some issues with XML export from the 8.4 server.
We planned on using ARSADMIN retrieve and ARSADMIN store to move the data however we were able to copy the 1TB of data in the source OD (stored in cache) to a temp location and just ran ARSADMIN stores against those copies.  Total time to move the data was approximately 2 weeks with most of the migrations run during business hours.  The whole project took about 2 months planning and another 1 month to move production.
I would think going from OAM to OAM could make things quicker.

We haven't had the chance to try two OAMs yet.

jine01

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: 'export' of all data from one OD-instance to another
« Reply #3 on: November 02, 2017, 04:50:51 AM »
Hi Ed
Thanks for the reply, it was nice to hear
Jimmy N

jine01

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: 'export' of all data from one OD-instance to another
« Reply #4 on: November 02, 2017, 06:08:31 AM »
Hi Greg

Thanks for your reply
I have further questions

A What do you get out from Arsadmin retrieve?

B how can you use it to load Ondemand?

C Can I use it to load in an existing Ondemand?

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: 'export' of all data from one OD-instance to another
« Reply #5 on: November 02, 2017, 10:30:02 AM »
With ARSADMIN RETRIEVE you will get the object from OAM as a file.
For example you've loaded a document with load-id of 1122-93-0-8FAA-20171102113800-20171102113800-5571
If you issue ARSADMIN Retrieve -g apgroup -h instance -m 2 -n 93-0 8FAAA 8FAA1 -d /u/temp   (not the exact syntax)
You will get two files in /u/temp named 8FAAA and 8FAA1
Now if you issue:
ARSADMIN store -g newapgroup -h newinstance -m 2 -n<new primary - secondary storage> 8FAAA 8FAA1
  (Run this command from /u/temp or direct the input using -d )
This will store the document in OAM for the new OD instance in the primary storage set for that application group.
You then need to move the index data from the old instance to the new.  We used a form of DB2 unload -> DB2 load with modifications.
A few things to note for this method.  You should be extremely comfortable working with DB2 as it requires a fair amount of manipulation of tables and values.  You should also need to be comfortable with the inner workings of CMOD, how various tables, objects, settings.... are referenced/used and you have to account for resources if you are using them.
The Pro's we found using this method is it's quick, Most the of work can be scripted, Requires little or no actual down time, avoids the complications of moving AFP docs, and when done correctly preserves original expiration dates.
Con:   Can be complicated and requires good advance planning, potential for really messing things up, and requires thorough verification
 If you aren't pressed for time and expiration doesn't matter I'm sure an XML import/export to mirror the AGs and APs then some sort of straight up Doc get and Reload would be the easiest.




Justin Derrick

  • IBM Content Manager OnDemand Consultant
  • Administrator
  • Hero Member
  • *****
  • Posts: 2231
  • CMOD Guru for hire...
    • View Profile
    • Tenacious Consulting
Re: 'export' of all data from one OD-instance to another
« Reply #6 on: November 02, 2017, 01:45:01 PM »
It would probably be way better to use arsdoc get to pull out documents and reload them on the other side.  That method is supported.  Tweaking the database tables isn't.  :)  The only big caveat to migrating data this way on z/OS is the MIPS you burn up re-compressing the data for storage.

-JD.
IBM CMOD Professional Services: http://TenaciousConsulting.com
Call:  +1-866-533-7742  or  eMail:  jd@justinderrick.com
IBM CMOD Wiki:  https://CMOD.wiki/
FREE IBM CMOD Education & Webinars:  https://CMOD.Training/

Interests: #AIX #Linux #Multiplatforms #DB2 #TSM #SP #Performance #Security #Audits #Customizing #Availability #HA #DR

jine01

  • Newbie
  • *
  • Posts: 8
    • View Profile
Re: 'export' of all data from one OD-instance to another
« Reply #7 on: November 07, 2017, 01:45:49 AM »
Hello guys

thank you for the answers
It looks like we're going to go for arsdoc and arsload.

Best Regards
Jimmy N