• Search Forums
    Advanced Search Topics Posts
Prev
Next
Forums Integration / Customization S3 Application Upgrades

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
5/27/2009 8:01 PM

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
6/1/2009 2:32 PM
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
6/1/2009 3:30 PM
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
6/1/2009 3:33 PM
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
6/1/2009 3:36 PM

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
6/1/2009 3:42 PM
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
6/1/2009 4:31 PM
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