ORA-00600: 内部错误代码, 参数: [13013]

ORA-00600: 内部错误代码, 参数: [13013]

数据库版本：Oracle 11.2.0.1.0

数据库服务器操作系统：Windows server 2008

错误号(1)：ORA-00600: internal error code, arguments: [13013], [5001], [267], [8460734], [2], [8460734], [17], [], [], [], []

详细报错如下:

Mon May 30 11:40:28 2016

Errors in file e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_2184.trc  (incident=93782):

ORA-00600: internal error code, arguments: [13013], [5001], [267], [8460734], [2], [8460734], [17], [], [], [], [], []

Incident details in: e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_93782\klnew_smon_2184_i93782.trc

Non-fatal internal error happenned while SMON was doing logging scn->time mapping.

SMON encountered 3 out of maximum 100 non-fatal internal errors.

Mon May 30 11:40:30 2016

问题现象(1)：

SMON encountered 3 out of maximum 100 non-fatal internal errors.

数据库运行一段时间，实例自动关闭；

查看：klnew_smon_2184_i93782.trc

========= Dump for incident 93782 (ORA 600 [13013]) ========

*** 2016-05-30 11:40:28.480

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session (sql_id=dma0vxbwh325p) -----

update smon_scn_time

   set time_mp      = :1,

       time_dp      = :2,

       scn          = :3,

       scn_wrp      = :4,

       scn_bas      = :5,

       num_mappings = :6,

       tim_scn_map  = :7

 where scn = (select min(scn) from smon_scn_time)

错误号(2)：ORA-00600: internal error code, arguments: [13011], [267], [8460734], [2], [8460734], [17], [], [], [], [], [], []

详细报错如下：

Mon May 30 11:30:24 2016

Errors in file e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_2184.trc  (incident=93780):

ORA-00600: internal error code, arguments: [13011], [267], [8460734], [2], [8460734], [17], [], [], [], [], [], []

Incident details in: e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_93780\klnew_smon_2184_i93780.trc

Non-fatal internal error happenned while SMON was doing logging scn->time mapping.

SMON encountered 1 out of maximum 100 non-fatal internal errors.

Mon May 30 11:30:26 2016

问题现象(2)：

SMON encountered 3 out of maximum 100 non-fatal internal errors.

数据库运行一段时间，实例自动关闭；

查看klnew_smon_2184_i93780.trc：

========= Dump for incident 93780 (ORA 600 [13011]) ========

*** 2016-05-30 11:30:24.650

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session (sql_id=gm9t6ycmb1yu6) -----

delete from smon_scn_time where scn = (select min(scn) from smon_scn_time)

错误号(3)：ORA-00600: internal error code, arguments: [13013], [5001], [456], [4338038], [0], [4338038], [17], [], [], [], [], []

详细报错如下：

Fri May 27 17:25:50 2016

Errors in file e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_516.trc  (incident=90132):

ORA-00600: internal error code, arguments: [13013], [5001], [456], [4338038], [0], [4338038], [17], [], [], [], [], []

Incident details in: e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_90132\klnew_smon_516_i90132.trc

Non-fatal internal error happenned while SMON was doing flushing of monitored table stats.

SMON encountered 1 out of maximum 100 non-fatal internal errors.

问题现象(3)：

数据库无法通过shutdown immediate方式关闭，只能通过shutdown abort关闭

查看：klnew_smon_516_i90132.trc

========= Dump for incident 90132 (ORA 600 [13013]) ========

*** 2016-05-27 17:25:50.929

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session (sql_id=3c1kubcdjnppq) -----

update sys.col_usage$

   set equality_preds    = equality_preds +

                           decode(bitand(:flag, 1), 0, 0, 1),

       equijoin_preds    = equijoin_preds +

                           decode(bitand(:flag, 2), 0, 0, 1),

       nonequijoin_preds = nonequijoin_preds +

                           decode(bitand(:flag, 4), 0, 0, 1),

       range_preds       = range_preds + decode(bitand(:flag, 8), 0, 0, 1),

       like_preds        = like_preds + decode(bitand(:flag, 16), 0, 0, 1),

       null_preds        = null_preds + decode(bitand(:flag, 32), 0, 0, 1),

       timestamp         = :time

 where obj# = :objn

   and intcol# = :coln

解决方案：

ORA-00600: [13013], [5001], [267]

ORA-00600: [13011], [267]

select * from dba_objects where object_id=267;

select * from dba_ind_columns where table_name='SMON_SCN_TIME';

ORA-00600: [13013], [5001], [456]

select * from dba_objects where object_id=456;

select * from dba_ind_columns where table_name='COL_USAGE$';

select dbms_metadata.get_ddl('INDEX','I_COL_USAGE$','SYS') from dual;

唯一索引里出现了重复数据

删除索引I_COL_USAGE$，重建非唯一索引；

其中MOS中查询有关ORA-00600[13013]问题相关信息；

 

New and Improved: ORA-600 [13013] "Unable to get a Stable set of Records" (文档 ID 1438920.1)

转到底部

---

修改时间: 2015-11-18 类型: TROUBLESHOOTING

***Checked for relevance on 10-Jul-2015*** Note: For additional ORA-600 related information please read Note: 146580.1 PURPOSE: This article is a new and improved copy of OERI Note: 28185.1 which is designed to pilot a new feature to help identify known bugs for ORA-600[13013] issues. If you do not want to use the new feature, please use the original Note: 28185.1. The new feature available in this version of the OERI note provides a list of conditions most commonly identified for bugs related to this error. These conditions can be used to narrow down the possible cause of the error. Our goal with this pilot is to determine if this level of detail will lead our readers to a quicker resolution. After having used this new feature, please email Vickie.Carbonneau with your feedback. Please provide answers to the following: Did this new feature help you identify the issue? Did it save you research time? Do you feel more confident with applying a patch/patch set or using the workaround(if provided)? Would you use this new feature again? This article has been published because the ORA-600 error has been reported in at least one confirmed bug. ERROR: Format: ORA-600 [13013] [a] [b] [c] [d] [e] [f] VERSIONS: versions 6.0 and above DESCRIPTION: During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable set of rows that conform to the WHERE clause. ARGUMENTS: The number of arguments and their meaning vary depending on the Oracle  Server release and the object types relating to the error. 2 Argument format ================= This format relates to Oracle Server 8.0.4 and above and Index Only Tables (IOT) Arg [a] Passcount Arg [b] Code 5 Argument format ================= This format relates to Oracle Server 6.0 to 7.3.4 Arg [a] Passcount Arg [b] Code Arg [c] Tablespace Decimal Relative DBA (RDBA) of block containing the row to be updated Arg [d] Row Slot number Arg [e] Decimal RDBA of block being updated (Typically same as [c]) 6 Argument format ================= This format relates to Oracle Server 8.0.3 and above Arg [a] Passcount Arg [b] Data Object number Arg [c] Tablespace Decimal Relative DBA (RDBA) of block containing the row to be updated Arg [d] Row Slot number Arg [e] Decimal RDBA of block being updated (Typically same as [c]) Arg [f] Code FUNCTIONALITY: Update Execute IMPACT: PROCESS FAILURE POSSIBLE INDEX CORRUPTION SUGGESTIONS: This error could indicate a corrupt index. Check for corrupted indices using the following command : ANALYZE TABLE VALIDATE STRUCTURE CASCADE; Where is the table being updated. Drop and recreate any indexes that show problems. On Parallel Server instances (OPS - Oracle Server <= 7.X) this can be due to an inappropriate setting of max_commit_propagation_delay. Setting this parameter to 0 can avoid this error. For 7.3.2 releases please see ALERT: 40673.1 ALERT: Incorrect Results or Internal Errors from Indexed Table Access If the Known Issues section below does not help in terms of identifying a solution, please submit the trace files and alert.log to Oracle Support Services for further analysis.   KNOWN BUGS: Select the items that meet the conditions of your environment at the time of the error for a list of possible bugs. To see details about each condition, click on the plus sign. You can restrict the list below to conditions likely to affect one of the following versions by clicking the relevant button:                Conditions for Version 11.2.0.1     ERROR The second argument is [5001] and the 6th argument is [17] The second argument is [5001] and the 6th argument is [3]     OBJECT Bitmap indexes are used Error logging is being used SQL is using hidden columns Target table has a NOT NULL added column with default value There is a specially added column being updated Supplemental logging is being used for the hidden column A trigger is being used in the SQL     SQL SQL contains one or more DELETE statements SQL contains a MERGE which has a view with a GROUP BY SQL contains MERGE statement with UPDATE SQL contains MERGE statement with update or delete clauses Only one row is updated or deleted by the SQL SQL contains UPDATE statement SQL contains UPDATE and a LONG column is being updated UPDATE SQL specifies rowid to be updated     TRACEFILE Execution plan shows "PX COORDINATOR FORCED SERIAL"     CONFIGURATION The initialization parameter Parallel_max_servers is set to a low number Matches Article Id Type Description 1 of 1 9469117.8 Patch/Patch Set and Workaround Available Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze 1 of 1 9229891.8 Patch or Patch Set Available Bitmap index corruption by update or delete with error logging

 

 

 

Bug 9469117 - Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze (文档 ID 9469117.8)

转到底部

---

修改时间: 2013-6-28 类型: PATCH

Bug 9469117  Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze  This note gives a brief overview of bug 9469117.   The content was last updated on: 28-JUN-2013  Click here for details of each of the sections below.  This bug is marked as an important issue. Affects: Product (Component) Oracle Server (Rdbms) Range of versions believed to be affected Versions BELOW 12.1 Versions confirmed as being affected 11.2.0.1 11.1.0.7 11.1.0.6 10.2.0.5 10.2.0.4 10.2.0.3 Platforms affected Generic (all / most platforms affected) Fixed: This issue is fixed in 12.1.0.1 (Base Release) 11.2.0.2 (Server Patch Set) 11.2.0.1 Bundle Patch 4 for Exadata Database 10.2.0.5.4 Database Patch Set Update 11.2.0.1 Patch 9 on Windows Platforms 10.2.0.5 Patch 5 on Windows Platforms Symptoms: Related To: Corruption (Index) Error May Occur Internal Error May Occur (ORA-600) Wrong Results ORA-1499 / ORA-8102 ORA-600 [kdsgrp1] ORA-600 [qertbFetchByRowID] ORA-600 [13013] Parallel Query (PQO) Merge SQL (MERGE .. USING) PARALLEL_MAX_SERVERS UPDATE DELETE MERGE Description Index maintenance is not being done for UPDATE/DELETE/MERGE statements that UPDATE/DELETE only one row when a parallel plan (PDML) is executed in serial; e.g., there are not enough parallel server processes.    Example: alter session enable parallel dml; update tbug set col1=30 where col1=9; -> this statement is executed in                                          serial instead of parallel and                                          updates one row only as col1 is a                                          unique key. As the index is inconsistent with the table, this results in a corrupt index causing wrong results or errors like: ORA-600 [kdsgrp1] ORA-600 [qertbFetchByRowID] ORA-600 [13013] with error code 17 KDCMPF11 by an update ORA-8102 ORA-1499 by "analyze table validate structure cascade" with          a trace file containing error messages like:             "Table/Index row count mismatch"             "row mismatch in index" Workaround To avoid the problem:   Make sure that there are enough parallel server processes (increase parallel_max_servers)   or   Execute the DML statement in serial (disable Parallel DML). To repair the index inconsistency, Drop/Create the index. Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support. References Bug:9469117 (This link will only work for PUBLISHED bugs) Note:245840.1 Information on the sections in this article

 

 

 

Bug 9229891 - Bitmap index corruption by update or delete with error logging (文档 ID 9229891.8)

转到底部

---

修改时间: 2016-5-27 类型: PATCH

Bug 9229891  Bitmap index corruption by update or delete with error logging  This note gives a brief overview of bug 9229891.   The content was last updated on: 29-MAR-2016  Click here for details of each of the sections below. Affects: Product (Component) Oracle Server (Rdbms) Range of versions believed to be affected Versions BELOW 12.1 Versions confirmed as being affected 11.2.0.1 11.1.0.7 10.2.0.4 Platforms affected Generic (all / most platforms affected) Fixed: The fix for 9229891 is first included in 12.1.0.1 (Base Release) 11.2.0.2 (Server Patch Set) 11.1.0.7 Patch 28 on Windows Platforms Interim patches may be available for earlier versions - click here to check. Symptoms: Related To: Corruption (Index) Internal Error May Occur (ORA-600) Wrong Results Error May Occur ORA-1499 ORA-600 [13013] Bitmap Indexes DBMS_ERRLOG UPDATE DELETE Description A Bitmap index can be missing keys after UPDATE or DELETE when error logging is used (DBMS_ERRLOG.CREATE_ERROR_LOG). Wrong result or next errors can be produced:    ORA-1499 by "analyze validate structure cascade" and trace file has:          "row not found in index"        ORA-600[13013] with error code 17 (KDCMPF11) by an update Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support. References Bug:9229891 (This link will only work for PUBLISHED bugs) Note:245840.1 Information on the sections in this article

 

 

High Executions Of Statement "delete from smon_scn_time..." (文档 ID 375401.1)

转到底部

---

修改时间: 2013-3-2 类型: PROBLEM

In this Document Symptoms Cause Solution APPLIES TO: Oracle Database - Enterprise Edition - Version 10.1.0.2 to 10.2.0.4 [Release 10.1 to 10.2] Information in this document applies to any platform. SYMPTOMS A delete from smon_scn_time is performing excessive gets and executions as viewed from AWR report: Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s)  205,501,888 30,508 6,736.00 54.05 9,733.97 61,180.96  delete from smon_scn_time where...  The AWR report shows the following SQL with  an excessive amount of executions: delete from smon_scn_time where thread=0 and time_mp = (select min(time_mp) from smon_scn_time where thread=0); CAUSE There are inconsistencies between the indexes and table smon_scn_time. The delete statement deletes the oldest rows from smon_scn_time to clear space for new rows.  SMON wakes up every 5 minutes and checks how many on-disk mappings we have--the max is 144000. The new mappings are then added for the last period (since SMON last updated), and if this is over 144000, SMON will then issue the delete statement: delete from smon_scn_time where thread=0 and time_mp = (select min(time_mp) from smon_scn_time where thread=0) There will be an execution of this each time SMON wakes to update smon_scn_time, and if one deletion does not free enough mappings, then there will be multiple executions. What happens is due to the inconsistency between the table and indexes the delete returns zero rows; so the delete statement is executed continuously to reduce the smon_scn_time below the maximum 14400 mappings. When table smon_scn_time is analyzed we see the inconsistency: SQL> analyze table smon_scn_time validate structure cascade; analyze table smon_scn_time validate structure cascade * ERROR at line 1 : ORA-01499: table/Index Cross Reference Failure - see trace file SOLUTION To implement the solution, please execute the following steps: 1. Ensure you have a usable backup in case of failures 2. Drop and recreate the indexes on table smon_scn_time connect / as sysdba drop index smon_scn_time_scn_idx; drop index smon_scn_time_tim_idx; create unique index smon_scn_time_scn_idx on smon_scn_time(scn); create unique index smon_scn_time_tim_idx on smon_scn_time(time_mp); analyze table smon_scn_time validate structure cascade;

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29785807/viewspace-2118427/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29785807/viewspace-2118427/