8.0.3 to 9.0.0.x data migration dbreorg -G

 6 Replies
 0 Subscribed to this topic
 10 Subscribed to this forum
Sort:
Author
Messages
BrianP
Advanced Member Send Private Message
Posts: 35
Advanced Member

We are Unix / Oracle 10g.  During the copy processes we are getting ORA-01400 (Null / Not Null) error and the process defaults to dbcopy.  The job ends up in the waiting queue as needs recovery.  Lawson suggests doing dbreorg -g then recover the job.  This process seems to work, but I would like to know if anyone else has experienced this issue.  It appears when the process defaults to dbcopy the insert to the target db is successfull and the offending field is a space (not null).

Brad Schauer
Veteran Member Send Private Message
Posts: 76
Veteran Member
Brian, can you post the entire error message? Does this happen with all copy jobs or just specific jobs? Brad
BrianP
Advanced Member Send Private Message
Posts: 35
Advanced Member
Here is the error message: BEGIN: Job Submitted: Wed May 27 15:09:36 2009 Step 1: UG990 Started. . . . . .: Wed May 27 15:35:21 2009 Token Command. . . . . .: /lawq/lawqas/qas9/obj/UG990.gnt Executable Command . . .: /lawq/genqas/bin/lacobrts lacobrts /lawq/lawqas/qas9/obj/UG990.gnt qas9 lawdev AMCALENDAR 1 Process ID . . . . . . .: 21578 Program Messages: ** Creating .prt and .dtl files PROCESSING copy - AMCALENDAR Upgrade ID....: Upgrade System Code...: AM Object........: AMCALENDAR Flags.........: Routine.......: Copy #> Copy - 05/27/09 15:35:23 UPGRADING ALL DATA + sqldbcopy -d -h lawqdb-250:6536 -l read_qas8 ORA10 qas8 qas9 AMCALENDAR + 2> /lawq/lawqas/qas8/work/UPGRADE/AMCALENDAR.out + dbcopy -c -d QAS8 QAS9 AMCALENDAR + 1> /lawq/lawqas/qas8/work/UPGRADE/AMCALENDAR.out WARNING: SqlDbCopy failed. Override to DBCOPY successful. The file /lawq/lawqas/qas8/work/UPGRADE/AMCALENDAR.serr contains the following error text: Connecting to destination database... Done Reading and sorting file(s) in the dictionary. This might take a moment... Done Number of data locations used by Lawson files: 1 Specified degree of parallelism: 1 ==> Actual degree of parallelism: 1 ---------------------------------------------------------------------------- File AMCALENDAR - Processing... Error: executeInsertAsSelect() failed on table: AMCALENDAR Error state: 23000 Error code: 1400 ORA-01400: cannot insert NULL into ("LAWQAS"."AMCALENDAR"."DEPR_CALC_FL") File AMCALENDAR - Finished Result: Failed Time to drop and recreate table: 2983 ms Total database time for file AMCALENDAR: 2983 ms Status: 1 of 1 Lawson files processed Total elapsed time: 0:0:9.706 ----------------------------------------------------------- File AMCALENDAR Copying 2335 Statistics record written: Add: 2335 Mod: 0 Dup: 0 Elapsed Time . . . . . .: 00:00:23 ERROR: Stopped On Exit 1. Elapsed Time: 00:00:23 END: Job Ended: Wed May 27 15:35:44 2009
Brad Schauer
Veteran Member Send Private Message
Posts: 76
Veteran Member
Thanks Brian, is this happening with just this one copy job? Did you say that when the job fails over to dbcopy the records load just fine? Brad
BrianP
Advanced Member Send Private Message
Posts: 35
Advanced Member

Yes, this occurrs for each table where a null value exists in the source. In our previous version (8.0.3env/8.0.3apps - nulls were valid). We have already upgraded to LSF 9.0.0.x/8.0.3apps (Feb. 2009).

BrianP
Advanced Member Send Private Message
Posts: 35
Advanced Member
When the job(s) fail over to dbcopy the null issue is resolved and all records are accounted for in the new db. At this point the only validation i am doing is record count. This default clogges up the waiting queue with 'Needs recovery' (+300) however a simple delete is working fine.
Brad Schauer
Veteran Member Send Private Message
Posts: 76
Veteran Member
If you look at AMCALENDAR on the source side, do you have records where the DEPR-CALC-FL is blank? I just checked an AM upgrade I ran using sqldbcopy, we had records on AMCALENDAR where the DEPR-CALC-FL was blank and the job ran just fine, it moved the records into the target product line. What MSP is your application at on the source side? Is there any additional good info written to ladb.log? Brad