8.0.3 to 9.0.0.x data migration dbreorg -G

Sort:
You are not authorized to post a reply.
Author
Messages
BrianP
Advanced Member
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
    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
      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
        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
          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
            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
              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
                You are not authorized to post a reply.