Server Rename - Windows 2 Linux - db2move errors
In the process of a server rename from Windows to Linux for a CLM V6.0.2 environment.
JTS, QM and RM: IMPORT: table "RESOURCE"."RESOURCE" ERROR -3088. Check message file tab211.msg SQLCODE: -3088 - SQLSTATE: SQL3088N The source column specified to be loaded into database column "JZ_DISCRIMINATOR" is not compatible with the database column, but the database column is not nullable The tab211.msg file contains these messages: SQL3168W The PC/IXF column specified to be loaded into the database column "CHANGE_ID" is not compatible with the database column. Nulls will be inserted. SQL3088N The source column specified to be loaded into database column "JZ_DISCRIMINATOR" is not compatible with the database column, but the database column is not nullable. SQL3110N The utility has completed processing. "0" rows were read from the input file. CCM: * IMPORT: table "SCM "."BASELINE" WARNING 3107. Check message file tab26.msg SQL Warning! SQLCODE is 3107 SQL3107W At least 1 load message was encountered during LOAD processing Rows Read: 20839 Inserted: 0 Rejected: 20839 Committed: 20839 The tab26 file contains these errors: SQL3148W A row from the input file was not inserted into the table. SQLCODE "-180" was returned. SQL0180N The syntax of the string representation of a datetime value is incorrect. SQLSTATE=22007. IMPORT: table "MODEL "."CATEGORY" WARNING 3107. Check message file tab76.msg SQL Warning! SQLCODE is 3107 *** SQL3107W At least 1 load message was encountered during LOAD processing Rows Read: 83 Inserted: 83 Rejected: 0 Committed: 83 tab76.msg contains these errors: SQL3168W The PC/IXF column specified to be loaded into the database column "DEFAULT_CATEGORY" is not compatible with the database column. Nulls will be inserted. SQL3168W The PC/IXF column specified to be loaded into the database column "DEFAULT_TEAM_AREA_ITEM_ID" is not compatible with the database column. Nulls will be inserted. Any thoughts as to why I'm getting these errors? What's the best way to fix them? Thanks, Fran OK - so I've figured out what's going on. After using Data Studio and looking at the DDL, the tables with issues have several columns in a different order for the source and destination databases. For instance, in the RESOURCE.RESOURCE table (in JTS,CCM,QM and RM), the source and destination databases have 16 columns. The first 13 columns are the same. The final 3 in the source database are:
The final 3 columns in the destination database are:
DB2MOVE is trying to put data from APPLICATION_STORAGE_AREA_ATH_K into the Integer JZ_DISCRIMINATOR which is causing the error.
The tables in the source database on Windows were created as part of the original CLM V4.0.1 installation a few years ago. The database has been upgraded many times to get to V6.0.2.
The tables in the destination database on Linux were created using repotools on Linux in preparation for the server rename.
All of the data import errors in the other databases are similar situations.
I can think of several ways to fix this - but what's the best way? For future upgrades, will it matter what order the columns are in?
|
2 answers
This will end up as a DB2 that not many here are familiar with. Why don't you use the "repotools -export" and "repotools -import" commands for the task? I think the pair provides the most compatible way to move data across platforms.
Comments
Francis Kemp
commented May 23 '17, 9:10 a.m.
Currently prototyping the server rename using online backups. repotools is very slow and requires the jazz environment to be down to grab the backups.
|
I'm a little late to provide an answer but I have actually gone through a similar scenario in the past while bringing an external vendor SQL Server database into one of my customers Oracle environment. It was a very interesting project.
This is where /etc/hosts is your friend. Your new target server can be any name you like as your new server name but you can spoof it into believing that it is the old server name while you configure everything locally on the new target server or even a test server. Just be sure you also change the hosts files on any other system you will be using to interact with the the target server.
This will allow you to setup the source and target application installs, map to the existing databases (or, in your case, the restored copies of the databases) with the correct SQL drivers and then prepare for the server rename only on the new server. Then, once you have everything connected locally, you can begin the process of testing and verifying the entire procedure without impact to your current production environment.
If you are still have planning/strategic issues please feel free to ask. I will do what I can.
-michael
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.