ORA-600 [17003]错误一例

一套AIX 上的10.2.0.4系统运行catupgrd.sql脚本时出现ORA-600 [17003]错误， 详细的日志如下：   ALTER TYPE lcr$_row_record ADD MEMBER FUNCTION * ERROR at line 1: ORA-00600: internal error code, arguments: [17003], [0x70000008E6DA8C8], [1], [1], [], [], [], [] 1. Provide a list of invalid objects taken before upgrade was initially attempted. spool invalid_pre.lst select substr(owner,1,12) owner, substr(object_name,1,30) object, substr(object_type,1,30) type, status from dba_objects where status <> 'VALID'; spool off 2. Provide output of select obj# ,name from obj$ where name in ('LCR$_ROW_LIST','LCR$_ROW_RECORD'); 3. Provide an output of : select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID in (select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_LIST') / 4. Run same SQL in step 3 in another database of the same version - 10.1.0.4 select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID in (select object_id from dba_objects where OBJECT_NAME='AQ$_REG_INFO') / Compare and verify that this object has as many parent entries in dependency$ as they are in a fresh Database of the same version. If they are not, alter compile this object,and using same query above to verify that parent rows are created. 5. To verify timestamp discrepancy, run SQL spool &spoolfilename set pagesize 10000 column d_name format a20 column p_name format a20 select do.obj# d_obj,do.name d_name, do.type# d_type, po.obj# p_obj,po.name p_name, to_char(p_timestamp,'DD-MON-YYYY HH24:MI:SS') "P_Timestamp", to_char(po.stime ,'DD-MON-YYYY HH24:MI:SS') "STIME", decode(sign(po.stime-p_timestamp),0,'SAME','*DIFFER*') X from sys.obj$ do, sys.dependency$ d, sys.obj$ po where P_OBJ#=po.obj#(+) and D_OBJ#=do.obj# and do.status=1 /*dependent is valid*/ and po.status=1 /*parent is valid*/ and po.stime!=p_timestamp /*parent timestamp not match*/ order by 2,1; SQL> select obj# ,name from obj$ where name in ('LCR$_ROW_LIST','LCR$_ROW_RECORD'); OBJ# NAME ---------- ------------------------------ 5738 LCR$_ROW_RECORD 5776 LCR$_ROW_RECORD 256054 LCR$_ROW_LIST SQL> select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status 2 3 psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po 4 where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID 5 and do.object_ID in (select object_id from dba_objects where 6 OBJECT_NAME='LCR$_ROW_LIST') 7 / no rows selected SQL> spool timestamp SQL> set pagesize 10000 column d_name format a20 column p_name format a20 select do.obj# d_obj,do.name d_name, do.type# d_type, po.obj# p_obj,po.name p_name, SQL> to_char(p_timestamp,'DD-MON-YYYY HH24:MI:SS') "P_Timestamp", to_char(po.stime ,'DD-MON-YYYY HH24:MI:SS') "STIME", decode(sign(po.stime-p_timestamp),0,'SAME','*DIFFER*') X from sys.obj$ do, sys.dependency$ d, sys.obj$ po where P_OBJ#=po.obj#(+) and D_OBJ#=do.obj# SQL> and do.status=1 /*dependent is valid*/ 2 3 4 5 6 7 8 and po.status=1 /*parent is valid*/ 9 10 11 and po.stime!=p_timestamp /*parent timestamp not match*/ 12 order by 2,1; no rows selected SQL> spool off Errors in file ora_594098.trc: ORA-07445: exception encountered: core dump [kgghstfel+0074] [SIGSEGV] [Address not mapped to object] [0x204000000208] [] [] 1. Install 10.2.0.1, install 10.2.0.4 2. run utlu102i.sql, check output. 3. change Oracle Home 10.1 to 10.2 4. startup upgrade and run catupgrd.sql SQL> set lines 200 SQL> col comp_name format a50 SQL> select comp_name,version,status from dba_registry; COMP_NAME VERSION STATUS -------------------------------------------------- ------------------------------ --------------------------------- Oracle XML Database 10.2.0.4.0 VALID Oracle Enterprise Manager 10.2.0.4.0 VALID Oracle Data Mining 10.2.0.4.0 VALID OLAP Catalog 10.2.0.4.0 VALID Oracle Text 10.2.0.4.0 VALID Spatial 10.2.0.4.0 VALID Oracle interMedia 10.2.0.4.0 VALID Oracle Database Catalog Views 10.2.0.4.0 VALID Oracle Database Packages and Types 10.2.0.4.0 INVALID Oracle Real Application Clusters 10.2.0.4.0 VALID JServer JAVA Virtual Machine 10.2.0.4.0 VALID Oracle XDK 10.2.0.4.0 VALID Oracle Database Java Packages 10.2.0.4.0 VALID OLAP Analytic Workspace 10.2.0.4.0 VALID Oracle OLAP API 10.2.0.4.0 VALID If the above query shows that everything is valid and is in proper version, it means, that we would need to correct the problem with lcr$_row_record before upgrade. I see that one component is invalid 'Database packages and types'. To resolve this, please perform the following: SQL> shutdown immediate SQL> startup upgrade SQL> @?/rdbms/admin/catproc.sql SQL> @?/rdbms/admin/utlrp.sql SQL> shutdown immediate SQL> startup SQL> set lines 200 SQL> col comp_name format a50 SQL> select comp_name,version,status from dba_registry; Recompiled also get ORA-00600: internal error code, arguments: [17003] SQL> alter type LCR$_ROW_RECORD compile; alter type LCR$_ROW_RECORD compile * ERROR at line 1: ORA-00600: internal error code, arguments: [17003], [0x70000007C3A0378], [1], [1], [], [], [], [] select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID = select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_RECORD'); SQL> select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, 2 D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP 3 from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po 4 where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID = 5 (select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_RECORD'); (select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_RECORD') * ERROR at line 5: ORA-01427: single-row subquery returns more than one row SQL> set lines 200 SQL> col comp_name format a50 SQL> select comp_name,version,status from dba_registry; SQL> col object_name format a20 SQL> select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID in (select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_RECORD');   MOS Bug Info:   Hdr: 6611530 10.2.0.2.0 RDBMS 10.2.0.2.0 AQ PRODID-5 PORTID-197 ORA-600 Abstract: ORA-600 17003 PROBLEM: -------- Customer was trying to apply the 10.2.0.3 patchset and kept getting ora-600 17003 errors running catproc.  They tested the running of catalog, catproc and utlrp in the 10.2.0.2 database version before upgrade and got the same error.  The errors are reproducing trying to compile at least these 2 objects: ALTER PACKAGE "SYS"."DBMS_AQADM_SYS" COMPILE BODY REUSE SETTINGS ALTER TYPE "SYS"."LCR$_ROW_RECORD" COMPILE SPECIFICATION REUSE SETTINGS This issue started in SR 6535356.994 and since the issue reproduces before upgrade it was determined that this isn't an upgrade issue. DIAGNOSTIC ANALYSIS: -------------------- Have reviewed alert.log and trace file. Had customer run hcheck - output will be uploaded. In the trace files, I couldn't find the handle for the second argument of the ora-600 17003 error, so can not determine the object. WORKAROUND: ----------- none known RELATED BUGS: ------------- Looks exactly like Bug 5857558.  Was going to try the generic fix in this bug but cannot determine the object because cannot find the handle in the trace files. REPRODUCIBILITY: ---------------- It is reproducible everytime they run catproc.  catalog runs fine. TEST CASE: ---------- none STACK TRACE: ------------ ksedst ksedmp ksfdmp kgeriv kgeasi kglget kglgob kgldpo0 kgldpo kgldon pl_don ptgxtn ptg_nd phdbte phncrr_check_remote_refs phncee_check_extra_errors phnr_resolve ph2exp ph2ext ph2osa ph2of1 ph2exp ph2ext ph2osa ph2of1 SUPPORTING INFORMATION: ----------------------- 24 HOUR CONTACT INFORMATION FOR P1 BUGS: ---------------------------------------- DIAL-IN INFORMATION: -------------------- IMPACT DATE: ------------ The query returned no rows: SQL> select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID = (select object_id from dba_objects where OBJECT_NAME='AQ$_SRVNTFN_MESSAGE');   2    3    4    5   / no rows selected Therefore, I have asked him to send up the files needed to set-up the system tablespace in-house.  Do you need any other tablespaces? Customer did the following: 1.    Recovered the database back to 10.2.0.2 before we ran catalog and catproc. 2. Performed the steps for dictionary fix as following ( he had tested this out ? please see dev.log with the test he did before this ): (1) update obj$ set status=5 where obj#=(select object_id from dba_objects where OBJECT_NAME='AQ$_SRVNTFN_MESSAGE');      commit;      select obj#, name, status from obj$ where obj# = (select object_id from dba_objects where OBJECT_NAME='AQ$_SRVNTFN_MESSAGE'); . (2) FLUSH the shared pool(or bounce the DB), to reflect this changed status in cache as well. . (3) alter type AQ$_SRVNTFN_MESSAGE compile; . (4) Check required dependency$ rows are recreated.      select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta, D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta, P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID = (select object_id from dba_objects where OBJECT_NAME='AQ$_SRVNTFN_MESSAGE'); . (5) ALTER PACKAGE "SYS"."DBMS_AQADM_SYS" COMPILE BODY REUSE SETTINGS;      select obj#, name, status from obj$ where obj# = (select object_id from dba_objects where OBJECT_NAME='DBMS_AQADM_SYS' and OBJECT_TYPE in ('PACKAGE BODY')); 3. Executed catalog 4. Executed catproc and encountered Ora-600 errors:     First error:        UPDATE SYS.AQ_SRVNTFN_TABLE tab            * ERROR at line 1: ORA-81: address range [0x60000000000DBDB0, 0x60000000000DBDB4) is not readable ORA-600: internal error code, arguments: [kksfbc-reparse-infinite-loop], [0x9FFFFFFFBE9CED88], [], [], [], [], [], []      Second error: Warning: Type created with compilation errors. Errors for TYPE LCR$_ROW_RECORD: LINE/COL ERROR -------- ----------------------------------------------------------------- 0/0      ORA-81: address range [0x60000000000DBD80, 0x60000000000DBD84)          is not readable          ORA-600: internal error code, arguments: [17003],          [0xC0000004F1DD89D0], [1], [1], [], [], [], [] Invalids after utlrp: SYS                STREAMS$_EVALUATION_CONTEXT      EVALUATION CONTEXT INVALID                    DBMS_STREAMS                     PACKAGE             INVALID                    DBMS_STREAMS_DATAPUMP            PACKAGE BODY        INVALID                    DBMS_STREAMS                     PACKAGE BODY        INVALID                    DBMS_LOGREP_IMP                  PACKAGE BODY        INVALID                    LCR$_ROW_RECORD                  TYPE                INVALID                    LCR$_ROW_RECORD                  TYPE BODY           INVALID                    AQ$_AQ_SRVNTFN_TABLE_F           VIEW                INVALID                    AQ$AQ_SRVNTFN_TABLE              VIEW                INVALID I then asked him to up the following parameters which did no good (didn?t think they would but wanted to try): shared_pool_size greater then 800M large_pool_size greater then 250M java_pool_size greater then 250M db_cache_size greater then 500M compatible set to 10.2.0.0 pga_aggregate_target greater then 1000M Then had him do the following: SQL> select distinct o.name, o.stime, d.p_timestamp from obj$ o, dependency$ d where o.stime != d.p_timestamp and o.type#=13 and o.obj#=d.p_obj# ;   2    3   NAME                           STIME     P_TIMESTA ------------------------------ --------- --------- AQ$_SRVNTFN_MESSAGE            08-NOV-07 11-NOV-06 SQL> startup restrict SQL> conn / as sysdba SQL> update dependency$ d set p_timestamp = (select stime from obj$ p where d.p_obj#=p.obj#)            where d.p_obj# in (select obj# from obj$ where type#=13) and d.p_timestamp != (select stime            from obj$ o where d.p_obj#=o.obj#); ENSURE BY THE PREVIOUS STATEMENT that only 1 rows are updated. --------- THIS RETURNED 3 rows therefore he rolled back and this is where we are now. /upload/bug6611530 directory: Dev.log ? gives the outputs after the dictionary patch was done alert_oasc1[1].log.11082007.txt ? the alert.log after the dictionary patch was done and the migration was then attempted oasc1_ora_3475.trc - The first trace file in the series You can see in the trace file the following 2 ora errors: ORA-600: internal error code, arguments: [kksfbc-reparse-infinite-loop], [0x9FFFFFFFBE9CED88], [], [], [], [], [], [] AND ORA-600: internal error code, arguments: [17003], [0xC0000004F1DD89D0], [1], [1], [], [], [], [] ---- where I still cannot find the handle in the trace file. The ora-600 kksfbc-reparse-infinite-loop occured after the data dictionary patching so I included it here for clarity.  Will work on that one after this is fixed (if it can be). Here is the results of the requested query.  Since this object has both an OBJECT_TYPE of TYPE and TYPE BODY there are 2 queries that were run: SQL> select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta,   2  D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta,   3   P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po   4  where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID =   5  (select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_RECORD' and OBJECT_TYPE = 'TYPE');     D_OBJ# ---------- OBJECT_NAME ------------------------------------------------------------------------------ -- DTYP                DSTA    D_TIMESTA     ORDER#     P_OBJ# ------------------- ------- --------- ---------- ---------- OBJECT_NAME ------------------------------------------------------------------------------ -- PTYP                PSTA    P_TIMESTA ------------------- ------- ---------    1462820 LCR$_ROW_RECORD TYPE                INVALID 09-NOV-07          2    3320201 LCR$_ROW_LIST TYPE                VALID   11-NOV-06    1462820 LCR$_ROW_RECORD TYPE                INVALID 09-NOV-07          1        309 STANDARD PACKAGE             VALID   18-APR-03    1462820 LCR$_ROW_RECORD TYPE                INVALID 09-NOV-07          0    1462817 LCR_ROW_LIB LIBRARY             VALID   15-NOV-03 SQL> SQL> select D_OBJ#, do.object_name, do.object_type dtyp, do.status dsta,   2  D_TIMESTAMP, ORDER#, P_OBJ#, po.object_name, po.object_type ptyp, po.status psta,   3   P_TIMESTAMP from dependency$ d, DBA_OBJECTS do, DBA_OBJECTS po   4  where D_OBJ# = do.object_ID and P_OBJ#= po.object_ID and do.object_ID =   5  (select object_id from dba_objects where OBJECT_NAME='LCR$_ROW_RECORD' and OBJECT_TYPE = 'TYPE BODY');     D_OBJ# ---------- OBJECT_NAME ------------------------------------------------------------------------------ -- DTYP                DSTA    D_TIMESTA     ORDER#     P_OBJ# ------------------- ------- --------- ---------- ---------- OBJECT_NAME ------------------------------------------------------------------------------ -- PTYP                PSTA    P_TIMESTA ------------------- ------- ---------    1462858 LCR$_ROW_RECORD TYPE BODY           INVALID 09-NOV-07          0    1462820 LCR$_ROW_RECORD TYPE                INVALID 09-NOV-07     可以尝试在startup upgrade模式下重新运行catproc.sql脚本来解决组件失效的问题(catproc.sql is to try validate the registry and that should resolve the issue)。