In part 3 of the series we will actually attempt to migrate the data.
Migrating Connections DB from Oracle to DB2
In my experience the database migration is always most time consuming, so I always do the database first
Use the text file of Commands that we created in part 2.
- Back up the exisitng Connections databases
- Drop database, create database, app grants (for homepage also initdata, and re org and run stats)
- CR update scripts
- Pre DB fixer script
- Run the DBT command
- 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
I run the commands one database at a time. This made it much easier for troubleshooting issues and ensuring that each database was in a consistent migrated state before moving onto the next – if I had issues I made notes in the commands text file and moved on to the next DB.
Homepage took a very long time to migrate as there was a LOT of data here, the other DBs I had issues with were Files, Wikis and Blogs which are the ones that IBM expect to cause issues. I will use Blogs as an example on how to troubleshoot later.
I also had some DBs that were already using DB2 like IBM Docs, Surveys app for Communities and ProjectExec – we backed these up also and migrated them across to the server in the sameway that we would do a normal DB migration – Droped, restored and checked the DB roles and permission. These all came across with no issues.
Troubleshooting
It goes without saying that you should ALWAYS RUN THIS ON A TEST / DEV SERVER FIRST!
If i could have this as scrolling flashing marquee text with it playing a siren I would. I CAN NOT emphasise enough how important it is that you should run this in a test environment – which we did 3 times before actually doing it for real.
The most troubleshooting I did on this project revolved around the dbt transfer script (see example below).
The database schemas are quite different between types and even between OS versions so there will be a lot of tinkering to resolve the problems. Typically its where one DB type expects a NULL and the other expects a NOTNULL
Firstly run the script
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
If there are problems it will be shown in the console and written out to a log file.
for example you may see an error like this:
[07/20/16 13:22:56.756 PDT] com.ibm.db2.jcc.am.SqlIntegrityConstraintViolationException: Error for batch element #50: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=3, TABLEID=5, COLNO=1, DRIVER=3.65.110
All of these issues I saw related to the NULL / NOTNULL issue.
The next step is to make a note of the tablespace id, table id and column number as we need those for an sql query.
Fire up your DB client and run the following query
SELECT C.TABSCHEMA, C.TABNAME, C.COLNAME FROM SYSCAT.TABLES AS T, SYSCAT.COLUMNS AS C WHERE T.TBSPACEID = 3 AND T.TABLEID = 5 AND C.COLNO = 1 AND C.TABSCHEMA = T.TABSCHEMA AND C.TABNAME = T.TABNAME
Use the TBSPACEID, TABLEID & COLNO from the error message
The query will report back the DBName (as the TABSCHEMA), the table name (as TABNAME) and the column name (as COLNAME)
TABSCHEMA TABNAME COLNAME --------- --------------- -------- BLOGS ROLLERLOGINNAME USERNAME
Now you have the name of table and column with the null/not null issue.
The next step is to edit the createDB.sql script to make the change in the example here remove the not null from the username field as below.
create table BLOGS.rollerloginname ( userid varchar(48) not null, username varchar(255), ORG_ID varchar(36) not null ) IN BLOGSREGTABSPACE@
Once that change has been made the process needs to start again…
- Drop database, create database, app grants (for homepage also initdata, and re org and run stats)
- CR update scripts
- Pre DB fixer script
- Run the DBT command
Rinse and repeat until the DB transfers all the tables over correctly. This part of the process took the longest. Working out which tables to remove the not nulls from was SO time consuming. I kept a record of all the tables / columns I changed for my records more than anything else, at least the Post DB fixer script puts things back to the way it should be – and if you do hit issues with that you can manually fix them as you have a record.
ALTER TABLE BLOGS.ROLLERLOGINNAME ALTER COLUMN USERNAME SET NOT NULL;
So hurrah .. after all of that mucking about we have the Connections 5 data from Oracle on AIX in to DB2 on Windows – now what?
Well I backed it ALL up, including the existing V5 DB2 databases Docs, FEB and Projexec and migrated it to Version 5.5.
On the whole this part of the process wasn’t too bad and it was a good test for a real live migration ..
Migrating to Live
The whole migrating to live took about 21 hours in total – including waiting time for the DBs to transfer and the steps were are follows
On the Live5 machines
- Stop Connections
- Backup the File system
- Back up the DB2 databases that need migrating (FEB, Docs, Projexec)
On the Dev5 DB machine (that I had been using for testing)
- Drop database, create database, app grants (for homepage also initdata, and re org and run stats)
- CR update scripts
- Pre DB fixer script
- Run the DBT command
- 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
- Restore the backed up Live DB2 databases (FEB, Docs, Projexec)
- Backup the DBs – so we now have a FULL set of V5 DB2 data
- Copy backups to LIVE 55 DB2 machine
On the Live5.5 machines
- Stop Connections
- Drop the DB2 databases
- Restore the V5 DB2 databases
- Set numb dbs to at least 25
- Run the upgrade scripts to update them to V5.5 – ran these manually not using the GUI as the amount of data caused issues
- Run the CR updates
- Run the Docs DB2 Fixes
- Run the FEB DB fixer from the FEB admin GUI
- Started Connections
- Cleared the scheduled tasks
- Post migration steps
- Restarted Connections
And we were live 🙂
This took WAY longer than it should have done because of all the issues we had with the DBT to begin with .. but hopefully info in these posts will hope anyone who needs to do this pre PINK.
This was a LONG journey – but we all learned a lot in the process of doing this .. the main lesson learnt was don’t attempt this unless you HAVE to 🙂
If you missed the other 2 parts of this series you can find them here: