ora00600内部错误代码oracle,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
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
Patch/Patch Set and Workaround Available
Corrupt index after PDML
executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze
1 of 1
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
Platforms
affected
Generic
(all / most platforms affected)
Fixed:
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
(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
Platforms
affected
Generic
(all / most platforms affected)
Fixed:
Interim patches may be available for earlier versions - click
to
check.
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
(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
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;
歡迎關注我的微信公眾號"IT小Chen"，共同學習，共同成長！！！
總結
以上是生活随笔為你收集整理的ora00600内部错误代码oracle,ORA-00600: 内部错误代码, 参数: [13013]的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： oracle+字段+virtual,Or
- 下一篇： forall oracle 游标,FOR