Hi all,
I am planning on doing a data migration of approximately 630 application groups (140GB) of data from an old system-
Dual Quad Core with 4GB memory
Windows 2003
DB2 9.7
CMOD 8.4.1.4
Dual 6 core with 64GB memory
Windows 2003
DB2 10.5
CMOD 9.5.0.2
Both systems are using cache and I just want to make sure that the query I plan on running against each application group will work. I've confirmed with IBM that it should be okay I just wanted to bounce it off everyone here for additional feedback:
arsdoc get -h CMODInstance -G AppGroup -o AppGroup -v
it is a 1:1 ratio which should make the loading easier. Let me know what everyone thinks. Thanks!
Hi,
If you keep the same user name, same instance and same directory structure, then what you could do is the following:
- Backup / Restore your database from source to target (You could do that with db2move for example, or simply with normal DB2 backup / restore)
- You might need to upgrade your database if you choose the backup/restore method
- Copy your cache directory from source to target
- Copy the registry entries for CMOD from source to target (I mean the part which concerns your CMOD instance)
- Run the upgrade procedure for CMOD V9.5 on the target
Then you should be ready quite quickly.
If that's not a possible way to do it.
Then of course you can use the "arsdoc get / arsload" proven method, but that's quite slow.
Kind regards,
Alessandro
As usually Allesandro, you're to the rescue
1
Quote from: Alessandro Perucchi on July 07, 2015, 08:52:45 AM
Hi,
If you keep the same user name, same instance and same directory structure, then what you could do is the following:
Everything is the same, all CMOD objects, DB2 was upped to 10.5, PDF indexer was installed, able to start the app with no issues. I expored all objects from CMOD 8.4 to localhost and tried importing into 9.5, and I got an error exporting, due to date incompatibilities between 8.4 and 9.5
- Backup / Restore your database from source to target (You could do that with db2move for example, or simply with normal DB2 backup / restore) <--This is done on a nightly basis
- You might need to upgrade your database if you choose the backup/restore method , - yep, we went with 10.5
- Copy your cache directory from source to target Cache directory currently exists on D:\arscache on the old server, should I move it to the new server?
- Copy the registry entries for CMOD from source to target (I mean the part which concerns your CMOD instance) <- This should be good
- Run the upgrade procedure for CMOD V9.5 on the target < - This has been, which I believe maybe casing issues exporting objects.
Then you should be ready quite quickly.
If that's not a possible way to do it.
Then of course you can use the "arsdoc get / arsload" proven method, but that's quite slow.
Side note- Would my arsdoc methode work:: arsdoc get -h CMODInstance -G AppGroup -o AppGroup -v
Kind regards,
Alessandro
8)
Just one question... you are going from Windows 2003 to Windows 2003??? Why not Windows 2008 or 2012?
The customer just got done putting together a monster server running 08, dual 6 core xeons, 64GB's, TBs of space..etc....
Over the past few weeks I havent really had much exposure to the ars.stash file and I think that is where my issue lays. Here's from my putty window:
So heres my question, can I just move the arscache directory over to the new file system, export all the objects, and bobs you uncle?
Windows filesystems don't have the concept of symbolic links, so the retr directory is full of text files containing the location of the actual file. If the filesystem letter / name / subdirectories are identical, it should work. If they're different, it's a world of hurt. :)
Good luck!
-JD.
Interesting.
We have C: and D:
D: contains arscache1
So what your saying is that if i backup the old directory, and copy the existing directory in, bobs your uncle and we should be set?
ugh symbolic links
unix
tsm
lab services
nightmares.
Hi All, This is exactly what I did for this procedure:
Its a fresh new "monster server"
1) Installed DB2 10.5
2) Installed DB2 FP5
3) Activated DB2
3) Licensed DB2
4) Using the configurator, setup everything as needed
Issued the following steps:
Set CMOD Codepage to 1208 via Registry Editor
update db cfg for "ARCHIVE" using NEWLOGPATH NULL
arsdb.exe -I ARCHIVE Prepare Instance instance
arssyscr -I ARCHIVE -l -u To update the System Log Application Group and Folder
arssyscr -I ARCHIVE -a -u To update the System Load Application Group and Folder
arsdb -I ARCHIVE -efv To Drop Indexes
arsdb -I ARCHIVE -rfv To Create Indexes
arsdb -I ARCHIVE -mv to create DB2 Run stats
Fired up arssocd and bingo, she works (Keep in mind, local server/local db)
Now, we are migrating from 8.4.1.8 to 9.5, and the application groups will not migrate due to the time change. I've already opened a PMR for support and have receieved much feedback from veterans on this site. My question is this.
It is a windows environment, C: D: C: is where all the base code is and D: is where arscache1 is located. Can I just copy the old aka existing prodcuting arscache1 to D:, import all the objects, and bobs your uncle? anything else i should be worried about
Hi,
I don't understand something...
You want to move the cache from old D: to new D:
Which is fine.
BUT in order that this step works, it means that you need to have the DB2 database backup on the old, and restored in the new server.
That means, the steps you've described:
arsdb.exe -I ARCHIVE Prepare Instance instance
arssyscr -I ARCHIVE -l -u To update the System Log Application Group and Folder
arssyscr -I ARCHIVE -a -u To update the System Load Application Group and Folder
arsdb -I ARCHIVE -efv To Drop Indexes
arsdb -I ARCHIVE -rfv To Create Indexes
arsdb -I ARCHIVE -mv to create DB2 Run stats
doesn't make sense at all, since it means you have here a new instance!!
It only makes sense, if you want to check that a new instance works, but after that you will need to scratch your DB, and restore the old DB...
and when the restore is done, only then, you can run the CMOD upgrade steps:
Steps found in this link: http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg21686051#841X (http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg21686051#841X)
Before running these steps, if you use a simple "backup / restore" from DB2, then you might need to upgrade the DB2 Instance after the restore.
Thanks Allesandro. So what you are saying is that I need to Delete the instance, copy the OLD ARCHIVE DB / D:/ to the new server, start up ARSSOCKD, and it's off to the races
My only concern is that I am not upgrading, I am migrating from old hardware to new server should that make a difference?
1) uninstall CMOD on my new box
2) delete "ARCHIVE"
3) Backup and restore archive from the old server
4) Copy D:\ARSCACH1 from old server to new server
5) issue any other remaining commands
6) Start ARSSOCKD, begin testing
You told us that you are on the old box with CMOD 8.4.1.4 and the new monster one with 9.5.0.2.
How can it be no upgrade?
You must in a way or another go from CMOD 8.4.1.4 to 9.5.0.2, even if you do a backup / restore, this step doesn't change at all.
1) Keep CMOD V9.5.0.2 on your monster new server
2) Backup and restore archive from the old server
3) Copy D:\ARSCACH1 from old server to new server
4) issue any other remaining commands (like Upgrade from DB2, if needed)
5) Upgrade CMOD V8.4.1.4 to V9.5.0.2
6) Start ARSSOCKD, begin testing
Or have I wrongly understood, you want to stay on 8.4.1.4 in the new monster server?
I believe these are my steps :)
Keep CMOD V9.5.0.2 on new hardware
Backup and restore ARCHIVE from OLD SERVER (PROD) to new server (New PROD)
Copy D:\ARSCACHE1 to new server
Start ARSSOCKD, begin testing,
Hi! Not really my busines, but why use 8.4 for development or to anything else, quite a big step to 9.5...
Prefer to do a second instance in the monster server, or best of cause to have a test or development server. Migrating/upgrading is quite smooth as drive letters are kept same. Otherwise its complicated.
So I did the db2move and it worked fine. I copied ARSCACHE1 from the old server to the new, same drive letters and all. Am I doing something wrong?
At the end we did this:
1. Install CMOD 9.5.
2. Drop any database instances created during Step 1.
3. Create an empty database instance using DB2 tools.
4. Use db2move to import data, creating the database tables in the process.
5. Use CMOD commands (arsdb) to recreate system tables/indexes and update the database schema to that used by CMOD 9.5.