4 Replies Latest reply: Feb 27, 2013 6:52 AM by 528473 RSS

    Datapump issue while import through EM

    528473
      Hi
      I have just installed Oracle 10.2.0.1 on Windows 2003 32 bit on Vmware. When im trying to import the data to this database through EM i am getting the following error.

      Master table "SYSTEM"."IMPORT1" successfully loaded/unloaded
      Starting "SYSTEM"."IMPORT1":
      Job "SYSTEM"."IMPORT1" stopped due to fatal error at 10:27:34
      Job "SYSTEM"."IMPORT1" stopped due to fatal error at 10:27:34

      The export is done through EM from Oracle 10.2.0.1 on Windows 2003 32 bit ( this is not on Vmware)

      Need help
        • 1. Re: Datapump issue while import through EM
          Richard Harrison .
          Hi,
          Is there a trace file generated on the database server, in either the bdump or udump directories?

          Regards,
          Harry
          • 2. Re: Datapump issue while import through EM
            528473
            There are trc files generated in bdump & udump

            Udump file is as follows
            ------------------------------
            Dump file f:\oracle\product\10.2.0\admin\mocl\udump\mocl_ora_2028.trc
            Wed Feb 27 10:38:16 2013
            ORACLE V10.2.0.1.0 - Production vsnsta=0
            vsnsql=14 vsnxtr=3
            Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
            With the Partitioning, OLAP and Data Mining options
            Windows Server 2003 Version V5.2 Service Pack 2
            CPU : 4 - type 586, 1 Physical Cores
            Process Affinity : 0x00000000
            Memory (Avail/Total): Ph:3695M/4095M, Ph+PgF:5211M/5971M, VA:1309M/2047M
            Instance name: mocl

            Redo thread mounted by this instance: 0 <none>

            Oracle process number: 15

            Windows thread id: 2028, image: ORACLE.EXE (SHAD)


            *** SERVICE NAME:() 2013-02-27 10:38:16.122
            *** SESSION ID:(159.1) 2013-02-27 10:38:16.122
            kccsga_update_ckpt: num_1 = 8, num_2 = 0, num_3 = 0, lbn_2 = 0, lbn_3 = 0
            *** 2013-02-27 10:38:26.840
            Successfully allocated 3 recovery slaves
            Using 364 overflow buffers per recovery slave
            Thread 1 checkpoint: logseq 140, block 2, scn 833954
            cache-low rba: logseq 140, block 6318
            on-disk rba: logseq 141, block 93195, scn 836186
            start recovery at logseq 140, block 6318, scn 0
            ----- Redo read statistics for thread 1 -----
            Read rate (ASYNC): 104120Kb in 0.81s => 125.53 Mb/sec
            Total physical reads: 106419Kb
            Longest record: 20Kb, moves: 0/21836 (0%)
            Change moves: 8/41 (19%), moved: 0Mb
            Longest LWN: 3426Kb, moves: 24/325 (7%), moved: 24Mb
            Last redo scn: 0x0000.000cc303 (836355)
            ----------------------------------------------
            ----- Recovery Hash Table Statistics ---------
            Hash table buckets = 32768
            Longest hash chain = 2
            Average hash chain = 709/706 = 1.0
            Max compares per lookup = 1
            Avg compares per lookup = 14016/14947 = 0.9
            ----------------------------------------------
            *** 2013-02-27 10:38:27.778
            KCRA: start recovery claims for 709 data blocks
            *** 2013-02-27 10:38:28.043
            KCRA: blocks processed = 709/709, claimed = 709, eliminated = 0
            *** 2013-02-27 10:38:28.137
            Recovery of Online Redo Log: Thread 1 Group 1 Seq 140 Reading mem 0
            *** 2013-02-27 10:38:28.449
            Recovery of Online Redo Log: Thread 1 Group 2 Seq 141 Reading mem 0
            *** 2013-02-27 10:38:28.761
            Recovery of Online Redo Log: Thread 1 Group 3 Seq 142 Reading mem 0
            ----- Recovery Hash Table Statistics ---------
            Hash table buckets = 32768
            Longest hash chain = 2
            Average hash chain = 709/706 = 1.0
            Max compares per lookup = 2
            Avg compares per lookup = 12818/14721 = 0.9
            ----------------------------------------------
            tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x1)
            tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x1)
            --------------------------------------------------------------------------------------------------------------------
            --------------
            Cdump has many trc files like the one below

            ump file f:\oracle\product\10.2.0\admin\mocl\bdump\mocl_lgwr_1972.trc
            Wed Feb 27 10:38:29 2013
            ORACLE V10.2.0.1.0 - Production vsnsta=0
            vsnsql=14 vsnxtr=3
            Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
            With the Partitioning, OLAP and Data Mining options
            Windows Server 2003 Version V5.2 Service Pack 2
            CPU : 4 - type 586, 1 Physical Cores
            Process Affinity : 0x00000000
            Memory (Avail/Total): Ph:3634M/4095M, Ph+PgF:5137M/5971M, VA:1261M/2047M
            Instance name: mocl

            Redo thread mounted by this instance: 1

            Oracle process number: 6

            Windows thread id: 1972, image: ORACLE.EXE (LGWR)


            *** 2013-02-27 10:38:29.417
            *** SERVICE NAME:() 2013-02-27 10:38:29.417
            *** SESSION ID:(166.1) 2013-02-27 10:38:29.417
            LGWR: Archivelog for thread 1 sequence 143 will NOT be compressed
            tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x1)
            tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x1)
            Maximum redo generation record size = 156160 bytes
            Maximum redo generation change vector size = 150672 bytes
            tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x10)
            tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x10)
            *** 2013-02-27 09:49:10.547
            LGWR: Archivelog for thread 1 sequence 144 will NOT be compressed
            *** 2013-02-27 09:52:49.469
            LGWR: Archivelog for thread 1 sequence 145 will NOT be compressed
            • 3. Re: Datapump issue while import through EM
              Richard Harrison .
              Hi,
              That doesn't look related. Are there not any trace files called dw0*.trc or dm*.trc?

              Do you know which directory the datapump would be using? The default is DATA_PUMP_DIR i think if you don't specify it - any logs in this directory?

              Regards,
              Harry
              • 4. Re: Datapump issue while import through EM
                528473
                Hi
                Now i m getting the error but the process is restarting after that. But always that error is 1st.