4 Replies Latest reply: Apr 25, 2013 2:28 AM by KR10822864 RSS

    ORA-600 [17069] error while running catrelod.sql to downgrade 11g database

    Bhavi Savla
      Hi,
      We are downgrading our 11.2.0.2 database to 10.2.0.4. We have successfullly run catdwgrd.sql without any errors in 11g env. While running catrelod.sql in 10g env we are facing the following error:
      SQL> @?/rdbms/admin/catrelod.sql
      
      TIMESTAMP
      --------------------------------------------------------------------------------
      COMP_TIMESTAMP RELOD__BGN 2013-04-24 20:15:39 2456407 72939
      
      DOC>#######################################################################
      DOC>#######################################################################
      DOC>  The following statement will cause an "ORA-01722: invalid number"
      DOC>  error if the database server version is not 10.0.0.
      DOC>  Shutdown ABORT and use a different script or a different server.
      DOC>#######################################################################
      DOC>#######################################################################
      DOC>#
      
      no rows selected
      
      DOC>#######################################################################
      DOC>#######################################################################
      DOC>  The following statement will cause an "ORA-01722: invalid number"
      DOC>  error if the database has not been opened for MIGRATE.
      DOC>
      DOC>  Perform a "SHUTDOWN ABORT"  and
      DOC>  restart using MIGRATE.
      DOC>#######################################################################
      DOC>#######################################################################
      DOC>#
      
      no rows selected
      
      
      Session altered.
      
      
      Session altered.
      
      
      no rows selected
      
      DECLARE
      *
      ERROR at line 1:
      ORA-00600: internal error code, arguments: [17069], [0x170FB8CA8], [], [], [],
      [], [], []
      I have checked the trace file in udump but it dint give any readable information.

      Please find below environment details.

      OS : RHEL 5 64 bit
      11g Database : 11.2.0.2
      10g Database : 10.2.0.4

      Kindly assist.
        • 1. Re: ORA-600 [17069] error while running catrelod.sql to downgrade 11g database
          KR10822864
          check :ORA-600/ORA-7445/ORA-700 Error Look-up Tool

          support.oracle.com
          • 2. Re: ORA-600 [17069] error while running catrelod.sql to downgrade 11g database
            KR10822864
            Whenever an ORA-600 error is raised a trace file is generated and an entry written to the alert.log with details of the trace file location. Starting with Oracle Database 11g Release 1, the diagnosability infrastructure was introduced which places the trace and core files into a location controlled by the DIAGNOSTIC_DEST initialization parameter when an incident, such as an ORA-600 is created. For earlier versions, the trace file will be written to either USER_DUMP_DEST (if the error was caught in a user process) or BACKGROUND_DUMP_DEST (if the error was caught in a background process like PMON or SMON). The trace file contains vital information about what led to the error condition

            please post 40 lines of alert log info .

            MOS Note:ORA-600 [17069] "Failed to pin a library cache object after 50 attempts" [ID 39616.1]

            "Look in the trace file for the text 'LIBRARY OBJECT HANDLE: handle=170fb8ca8'"

            if not found any massages like above please raise SR@support.oracle.com.
            • 3. Re: ORA-600 [17069] error while running catrelod.sql to downgrade 11g database
              Bhavi Savla
              KR10822864 wrote:
              Whenever an ORA-600 error is raised a trace file is generated and an entry written to the alert.log with details of the trace file location. Starting with Oracle Database 11g Release 1, the diagnosability infrastructure was introduced which places the trace and core files into a location controlled by the DIAGNOSTIC_DEST initialization parameter when an incident, such as an ORA-600 is created. For earlier versions, the trace file will be written to either USER_DUMP_DEST (if the error was caught in a user process) or BACKGROUND_DUMP_DEST (if the error was caught in a background process like PMON or SMON). The trace file contains vital information about what led to the error condition

              please post 40 lines of alert log info .

              MOS Note:ORA-600 [17069] "Failed to pin a library cache object after 50 attempts" [ID 39616.1]

              "Look in the trace file for the text 'LIBRARY OBJECT HANDLE: handle=170fb8ca8'"

              if not found any massages like above please raise SR@support.oracle.com.
              Hi KR,
              Thanks for your help. As suggested I have checked the trace file to search and found the below info. I suppose it is some kind of lock but not sure about it. Please let me know if the following makes sense:
                  SO: 0x21158a6e0, type: 3, owner: 0x211006f28, flag: INIT/-/-/0x00
                  (call) sess: cur 211572570, rec 211572570, usr 211572570; depth: 0
                    ----------------------------------------
                    SO: 0x21158a9b8, type: 3, owner: 0x21158a6e0, flag: INIT/-/-/0x00
                    (call) sess: cur 211572570, rec 0, usr 211572570; depth: 1
                      ----------------------------------------
                      SO: 0x1727a2618, type: 54, owner: 0x21158a9b8, flag: INIT/-/-/0x00
                      LIBRARY OBJECT PIN: pin=1727a2618 handle=170fb8ca8 mode=S lock=171243e98
                      user=211572570 session=211572570 count=1 mask=001d savepoint=0x43 flags=[00]
                      ----------------------------------------
                      SO: 0x171243e98, type: 53, owner: 0x21158a9b8, flag: INIT/-/-/0x00
                      LIBRARY OBJECT LOCK: lock=171243e98 handle=170fb8ca8 mode=S
                      call pin=0x1727a2618 session pin=(nil) hpc=0000 hlc=0000
                      htl=0x171243f18[0x17278a310,0x17278a310] htb=0x17278a310 ssga=0x172789928
                      user=211572570 session=211572570 count=1 flags=PNC/[0400] savepoint=0x43
                      LIBRARY OBJECT HANDLE: handle=170fb8ca8 mtx=0x170fb8dd8(0) cdp=0
                      name=SYS.STANDARD
                      hash=51570e225ed8a9a803b7318f191e0a8d timestamp=04-18-2006 00:00:00
                      namespace=TABL flags=KGHP/TIM/SML/[02000000]
                      kkkk-dddd-llll=0000-001d-001d lock=S pin=S latch#=3 hpc=0004 hlc=0004
                      lwt=0x170fb8d50[0x170fb8d50,0x170fb8d50] ltm=0x170fb8d60[0x170fb8d60,0x170fb8d60]
                      pwt=0x170fb8d18[0x170fb8d18,0x170fb8d18] ptm=0x170fb8d28[0x170fb8d28,0x170fb8d28]
                      ref=0x170fb8d80[0x170fb8d80,0x170fb8d80] lnd=0x170fb8d98[0x170f05b50,0x170fa6858]
                        LIBRARY OBJECT: object=170e82de8
                        type=PCKG flags=EXS/LOC[0005] pflags=NST/IVR[0201] status=VALD load=0
                        DATA BLOCKS:
                        data#     heap  pointer    status pins change whr
                        ----- -------- -------- --------- ---- ------ ---
                            0 170e831f8 170e82fc0 I/P/A/-/-    0 NONE   00
                    ----------------------------------------
                    SO: 0x21158e470, type: 5, owner: 0x21158a6e0, flag: INIT/-/-/0x00
                    (enqueue) CU-70E88BC0-00000001    DID: 0001-001F-00000004
                    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x2
                    res: 0x17677adc8, mode: X, lock_flag: 0x0
                    own: 0x211572570, sess: 0x211572570, proc: 0x211006f28, prv: 0x17677add8
                    ----------------------------------------
                    SO: 0x177f82c28, type: 59, owner: 0x21158a6e0, flag: INIT/-/-/0x00
                    cursor enqueue
                    child: 170e89348, flag: 53, number: 0
                    parent: 170e89738
              • 4. Re: ORA-600 [17069] error while running catrelod.sql to downgrade 11g database
                KR10822864
                yes ,170fb8ca8 This is a LIBRARY OBJECT HANDLE

                according to MOS doc, It is possible to get this error on a long running process if the dependent object has been dropped or recompiled.
                If the error occurs on a procedure, attempt to recompile the procedure.

                For repeatable occurrences, please submit the trace files and alert.log to Oracle Support for further analysis