In part 2 of this series we will cover preparing the system and the commands and files required.
There is a fair bit of file creation to do and configuring of the Database Transfer Tool (DBT)
Migrating Connections DB from Oracle to DB2
Step 3 – Prepare a system to recieve the data
As I stated previously do not think you can recycle an existing Connections server if it has been installed with the DB type you are migrating away from as it causes issues with files particually.
In my case I had an existing V5 dev system using the test oracle DB. I backed it all up – Existing DB2 databases, Docs configuration files, file system (connections shared data) and docs/viewer shares – we will need this later.
Blow that system away and rebuild a clean, fresh V5 system – should only take a few hours 🙂
Once you have a clean V5 system – make sure it all works .. then back up the empty DBs and filesystem files.
Its essential that you know the system works before attempting to migrate data.
Step 4 – Prepare files and commands
4.1 Prepare the Database Transfer Tool
Create the DBT_HOME directory
On the db2 server create the DBT_HOME directory under <CONNECTIONS_ROOT>\ConfigEngine\lib
On my system this was D:\IBM\Connections\ConfigEngine\lib\DBT_HOME
Under DBT_HOME create additional directories of files to hold the xml files required for migration and logs for all logs relating to the migration
Locate the dbt.jar from the Connections machine (<CONNECTIONS_ROOT>\ConfigEngine\lib in my case D:\IBM\Connections\ConfigEngine\lib) and copy it to the newly created DBT_HOME directory on the DB2 server.
Create the XML files required
Create an XML document for each application DB that is to be copied over and place it in the the DBT_HOME\files folder
D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\files
Example below of the activites.xml :
<dbTransfer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <database role="source" driver="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@oracledbhost:port:dbinstancename" userId="OAUSER" schema="ACTIVITIES" dbType="oracle"/> <database role="target" driver="com.ibm.db2.jcc.DB2Driver" url="jdbc:db2://db2host:50000/opnact" userId="db2admin" schema="ACTIVITIES" dbType="DB2"/> <table sourceName="activities.system_lastmod" exclude="true"/> </dbTransfer>
The source in this example is is oracle the target is db2
Once completed you will have the follwing xml documents in the DBT_HOME\files directory
- activities.xml
- blogs.xml
- dogear.xml
- files.xml
- forum.xml
- homepage.xml
- metrics.xml
- mobile.xml
- people.xml
- sncom.xml
- sncomcal.xml
- wikis.xml
Ensure the DB drivers are accessible
It is essential that the oracle drivers are accessible by the DB2 (target) server.
Oracle driver & DB2 driver paths – we need these later.
D:\IBM\Oracle\ojdbc6.jar D:\IBM\SQLLIB\java\db2jcc.jar
V5 & V5.5 Wizards are required
When building the commands to migrate the DB some scripts are missing from the V5 Wizards directory. After speaking with IBM its safe to use the V5.5 wizard files for the missing scripts.
Replace the connections.sql scripts
Replace the SQL scripts given to you by IBM into the relevant directories .. in my case they were for files, wikis and blogs
4.2 Prepare the commands required
Prepare the commands for each DBÂ they will comprise of the following:
drop database, create database, app grants (for homepage also initdata, and re org and run stats)
CR update scripts
Pre DB fixer script
the DBT command string which has the following syntax
java -cp <path to DBT home>\DBT_HOME\dbt.jar;<Oracle driver>\ojdbc6.jar;<db2 driver>\db2jcc.jar com.ibm.wps.config.db.transfer.CmdLineTransfer -logDir <path to DBT home\logs>\DBT_HOME\logs -xmlfile <path to DBT home\files>\DBT_HOME\files\<application xml>.xml -sourcepassword sourcepassword -targetpassword targetpassword
Application specific scripts (IBM provided addional fixup scripts for Blogs, Files and Wikis for me)
Post DB fixer script
Re org script
Run stats script
== Activities Example== cd C:\InstallTemp\Connections\V5\Wizards\connections.sql\activities\db2 db2 -td@ -vf dropDb.sql db2 -td@ -vf createDb.sql db2 -td@ -vf appGrants.sql cd C:\InstallTemp\Connections\V5\CR3\50cr3-database-updates\50cr3-database-updates\From-50\db2\ db2 -td@ -vf 50-CR1-activities-db2.sql cd C:\InstallTemp\Connections\V55\connections.sql\activities\db2 db2 -tvf predbxfer50.sql cd C:\InstallTemp\Connections\V5\Wizards\jvm\win\jre\bin java -cp D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\dbt.jar;D:\IBM\Oracle\ojdbc6.jar;D:\IBM\SQLLIB\java\db2jcc.jar com.ibm.wps.config.db.transfer.CmdLineTransfer -logDir D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\logs -xmlfile D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\files\activities.xml -sourcepassword sourcepassword -targetpassword targetpassword cd C:\InstallTemp\Connections\V55\connections.sql\activities\db2 db2 -tvf postdbxfer50.sql cd C:\InstallTemp\Connections\V5\Wizards\connections.sql\activities\db2 db2 -td@ -vf reorg.sql db2 -td@ -vf runstats.sql
note: The RED section of the example script above should be run in a standard command window. The other scripts should be run from a db2cmd window.
I have a long list of commands in a text file that contains one of these blocks for each application a example of this can be downloaded here to use as a template for the syntax – note: that you should use this at your own risk, take advice from IBM and ensure that all the paths and passwords are set correctly before running.
One of the main reasons for dropping and creating manually is that the gui db wizards seem to have real issues – unsure why, but when we ran the db scripts manually they worked no issue – also there is an advantage that if we do see problems the script logs can be piped to a specific file. This was very helpful with all of the troubleshooting we had to do. If you do see issues with any of the commands they can be piped to a log to send to IBM – for example:
db2 -td@ -vf createDb.sql > C:\Install\temp\activities_createDb.txt
This was a lifesaver / timesaver for troubleshooting any db commands – as each command can be output to easily isolate what the issue is.
Step 5 – BACKUP
Before we start to do anything we are going to make some backups. Stop the existing V5 DEV server now we know its working and back it up. Take a copy of the clean DBs (including additional DBs such as FEB for surveys, CONCORD for Docs and any 3rd party tool DBs such as PROJEXEC etc.) and the file system (Connections data\shared, docs share, viewer share etc.). In my case I had to prove that it was working prior to the DB migration so this back up was essential.
If you are going to run a test against your live systems data ensure that you also get a good back up of the file system when the system is down, if possible run the test when the live system is down (out of hours / on a weekend etc.) as the DB peice of the migration is very time consuming and you may need to troubleshoot issues.
The basic rule of thumb is treat this test like any normal Connections DB migration or update Stop it all and back it up.
What’s next?
Now we are all prepared .. we can attempt a test at the data migration .. check back in a few days for part 3 of Migrating Connections DB from Oracle to DB2 – where the fun really begins