ORA-00600:
内部错误代码
,
参数
: [4194]
或[4193
]
数据库版本：
Oracle
11.2.0.1.0
数据库服务器操作系统：
Windows
server 2008
问题现象：
alter
database open
resetlogs;
时报错如下
ORA-1092 signalled during: ALTER DATABASE OPEN...
Doing block recovery for file 3 block 261754
No block recovery was needed
Errors in file e:\app\administrator\diag\rdbms\klnew\klnew\trace\
klnew_ora_2072.trc
(incident=92624):
ORA-00600:
内部错误代码, 参数:
[4194]
, [], [], [], [],
[], [], [], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00600:
内部错误代码, 参数:
[4194]
, [], [], [], [], [], [], [], [], [],
[], []
Incident details in:
e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_92624\
klnew_ora_2072_i92624.trc
Doing block recovery for file 3 block 261754
No block recovery was needed
No Resource Manager plan active
Errors in file
e:\app\administrator\diag\rdbms\klnew\klnew\trace\klnew_smon_3776.trc (incident=87732):
ORA-00600: internal error code, arguments:
[4193]
, [], [], [], [],
[], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\klnew\klnew\incident\incdir_87732\klnew_smon_3776_i87732.trc
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x66288933]
[PC:0x9237D88, kgegpa()+38]
Dump file e:\app\administrator\diag\rdbms\klnew\klnew\trace\alert_klnew.log
解决方案：
解决问题时间充足时，可以通过
trace
日志找到损坏的回滚段，通过隐含参数屏蔽损坏的回滚段；
需要尽快解决问题时，可以直接通过隐含参数屏蔽所有的回滚段，之后启动数据库，创建新的
UNDO
表空间；
设置
undo_management由原来的
auto
改成
manual(undo_tablespace= SYSTEM)
，后可以启动数据库，但是执行
Expdp
或应用进行前台操作时，会报错：
ORA-01552:
cannot use
system rollback segment for non-system tablespace 'TEMP';
ORA-01552:
cannot use system rollback segment
for non-system tablespace 'NNC_DATA01';
1：
查看正在使用的回滚段
select segment_name, tablespace_name, status from dba_rollback_segs;
2:
使用
_corrupted_rollback_segments
参数可以使数据库在启动的时候
,
忽略损坏的回滚段
,
使数据库正常启动
.
*._corrupted_rollback_segments=(
_SYSSMU1_3086899707$,_SYSSMU2_1531987058$,_SYSSMU3_478608968$,_SYSSMU4_1451910634$,_SYSSMU5_2520346804$,_SYSSMU6_1439239625$,_SYSSMU7_1101470402$,_SYSSMU8_1682283174$,_SYSSMU9_3186340089$,_SYSSMU10_378818850$
)
另外
:
_offline_rollback_segments
参数可以让指定的回滚段处于
OFFLINE
状态
3: undo_management改回
audo
；
此时启动数据库会自动创建另一个回滚段，其他的
10
个回滚段会自动
offline;
4：创建新的
UNDO
表空间
create tablespace undotbs2 datafile 'D:\APP_10.2.0.4\CJC_DATAFILE\UNDOTBS02.DBF' size 10M autoextend on;
alter system set undo_tablespace=UNDOTBS2 scope=spfile;
5：
Drop
tablespace <undo tablespace
name
> including contents
and
datafiles
</undo tablespace
1.数据库开启的情况下，重建undotbs，然后重新指定到新undotbs上。
2.未打开情况下，修改undo_management 参数为 manual或者（也有说并且的）提供新的回滚段。
其中
:
4193：表示undo和redo不一致（Arg [a] Undo record seq number，Arg [b] Redo
record seq number ）；
4194：表示undo和redo不一致（Arg [a] Maximum Undo record number in Undo block，Arg [b] Undo record number from Redo block）
其中
MOS
中查询有关
ORA-00600[4194]
问题相关信息；
转到底部
|
修改时间
:
|
2015-11-20
|
|
类型
:
|
REFERENCE
|
| | |
|
|
Note: For additional ORA-600 related
information please read
Note:146580.1
PURPOSE:
This article discusses the internal error "ORA-600 [4194]",
what
it means and possible actions. The information here is only applicable
to the versions listed and is provided only for guidance.
ERROR:
Format: ORA-600 [4194] [a]
[b]
VERSIONS:
versions 6.0 to 12.1
DESCRIPTION:
A
mismatch has been detected between Redo records and rollback (Undo)
records.
We
are validating the Undo record number relating to the change being
applied against the maximum undo record number recorded in the undo
block.
This error is reported when the validation fails.
ARGUMENTS:
Arg
[a] Maximum Undo record number in Undo block
Arg
[b] Undo record number from Redo block
FUNCTIONALITY:
Kernel Transaction Undo called from Cache layer
IMPACT:
PROCESS FAILURE
POSSIBLE ROLLBACK SEGMENT CORRUPTION
SUGGESTIONS:
This error may indicate a rollback segment corruption.
This may require a recovery from a database backup depending on
the
situation.
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 Issues:
You can restrict the list below to issues likely to affect one of the
following versions by clicking the relevant button:
The list below is restricted to show
only bugs believed to affect version 11.2.0.1.
Other bugs may affect this version but have not been confirmed as being
relevant yet.
There is 1 bug listed.
|
NB
|
Prob
|
Bug
|
Fixed
|
Description
|
|
II
|
12821418
|
11.2.0.3.8, 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1
|
Direct NFS appears to be sending zero length
windows to storage device. It may also cause Lost Writes
|
·
'*'
indicates
that an alert exists for that issue.
·
'+'
indicates
a particularly notable issue / bug.
·
See
Note:1944526.1
for details of other symbols used
![]()
REFERENCES
BUG:792610
- ROLLBACK SEGMENT CORRUPTION, WHEN RETRY
MULTI-ROW INSERT AFTER AN INTERNAL ERROR
NOTE:146580.1
-
What is an ORA-600 Internal Error?
NOTE:281429.1
-
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors
Without Using Unsupported parameter
NOTE:3210520.8
-
Bug 3210520 - OERI[kjccqmg:esm] / OERI[4194] / corruption possible in RAC
NOTE:69863.1
-
ALERT: Apparent data corruptions involving Solaris 2.6, ISM & DR on
Starfire
NOTE:792610.8
-
Bug 792610 - Rollback segment corruption OERI:4194 can occur if block
checking detects a corrupt block
NOTE:8240762.8
-
Bug 8240762 - Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600
[4137] / SMON may spin to recover transaction
|
未找到您要查找的产品
?
在社区中提问
...
|
Bug 12821418 - Direct NFS appears to be sending zero length
windows to storage device. It may also cause Lost Writes (
文档
ID
12821418.8)
|
转到底部
|
|
|
修改时间
:
|
2015-11-6
|
|
类型
:
|
PATCH
|
| | |
|
|
Bug 12821418 Direct
NFS appears to be sending zero length windows to storage device. It may also
cause Lost Writes
This
note gives a brief overview of bug 12821418.
The content was last updated on: 28-OCT-2015
Click
here
for details of each of the
sections below.
There are additional notes on this bug in
Note:1589411.1
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:
|
The fix for 12821418 is first
included in
|
|
Interim patches may be available for earlier versions - click
here
to
check.
Description
This bug is only
relevant when using Direct NFS (dNFS)
"Direct NFS: channel id 1 path *** to filer *** PING timeout"
errors in the database alert log and database hangs.
This may also cause Lost Writes as described in Note:1589411.1
with the following symptoms:
Wrong results
ORA-1499 by analyze validate structure cascade
ORA-8102
ORA-600 [kdsgrp1]
ORA-600 [qertbFetchByRowID]
ORA-600 [25027]
ORA-600 [kcbz_check_objd_typ_3]
ORA-8103
ORA-1410
ORA-600 [kclchkblk_3]
ORA-600 [4137]
ORA-600 [4193]
ORA-600 [4194]
and during recovery:
ORA-600 [3020] with or without message KCOX_FUTURE: CHANGE IN FUTURE OF BLOCK
ORA-00752 (when DB_LOST_WRITE_PROTECT is enabled - 11g)
ORA-600 [6102]
Rediscovery Notes
Direct NFS: channel id 1 path *** to filer *** PING timeout
errors in the database alert log and database hangs.
Workaround
Disable Direct NFS
Further details on this issue can be found in
Note:1589411.1
|
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:12821418
(This link
will only work for PUBLISHED bugs)
Note:245840.1
Information on the sections in this article
|
|
ORA-600 [4193] "seq# mismatch while
adding undo record" (
文档
ID 39282.1)
|
转到底部
|
|
|
修改时间
:
|
2016-3-29
|
|
类型
:
|
REFERENCE
|
| | |
|
|
|
Note: For additional ORA-600 related
information please read
'*'
indicates
that an alert exists for that issue.
·
Note:1944526.1
for details of other symbols used
<1span style="font-size:11.0pt;font-family:" color:white;"="">REFERENCES
NOTE:146580.1
-
What is an ORA-600 Internal Error?
NOTE:8240762.8
-
Bug 8240762 - Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600
[4137] / SMON may spin to recover transaction
|
未找到您要查找的产品?在社区中提问...
|
Bug 21977392 - ORA-600 [4193] ORA-600 [ktbair1] ORA-600 [1234]
ORA-600 [6856] block type 'ktu undo block' on recovery of encrypt datafile (
文档
ID
21977392.8)
|
转到底部
|
|
|
修改时间
:
|
2016-5-27
|
|
类型
:
|
PATCH
|
| | |
|
|
Bug 21977392 ORA-600
[4193] ORA-600 [ktbair1] ORA-600 [1234] ORA-600 [6856] block type 'ktu undo
block' on recovery of encrypt datafile
This
note gives a brief overview of bug 21977392.
The content was last updated on: 18-APR-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.2
|
|
Versions
confirmed as being affected
|
|
|
Platforms affected
|
Generic (all / most platforms affected)
|
Fixed:
|
The fix for 21977392 is first
included in
|
|
Interim patches may be available for earlier versions - click
here
to
check.
Description
This bug is only relevant
when using Transparent Data Encryption
Media recovery crashes in a redo callback routine with some ORA600.
The errors are usually ORA-600 [4193] and/or ORA-600 [ktbair1] or
ORA-600 [1234] ORA-600 [6856].
Rediscovery Notes
- Media recovery crashes in a redo callback routine with some ORA600.
- The errors are usually ORA-00600:[4193] and/or ORA-00600:[ktbair1].
- The ORA-600 [4193] has these characteristics:
- ORA-10560: block type 'KTU UNDO BLOCK'
- ORA-600 [4193] in parallel recovery slave
- call stack:
-> ksvrdp -> krp_slave_main -> krp_slave_apply ->
-> kcbr_media_apply -> kcbr_apply_change ->
-> kcoapl -> kturdb -> ORA-00600:[4193]
- the ORA-600 incident tracefile shows a dump of the ktudb
from the redo change vector, and all the contents look
like garbage, eg the "flg" field has bits set other than
these bits: 0x1FFF for example:
----
*** ktuc_diag_dmp: dump of current change vector
ktudb redo: siz: 45736 spc: 47634 flg: 0x2740 seq: 0x6253 rec: 0x7f
xid: 0xd29a.4e93.24dbeb07
Unexpected kcocv element following ktudb structure:
----
this is also the case for ORA-600 [1234].
- the ORA600 incident tracefile also shows the details of the
block involved:
*** ktuc_diag_dmp: dump of buffer cache for rdba 0x010a63c2
and there will be a redo dump started but it may not be
complete, eg:
DUMP REDO
Opcodes *.*
DBAs (file#, block#):
(4, 680898) .
- if the redo dumps shows the problematic change vector header,
then it will be encrypted (ENC:1).
- The ORA-00600:[ktbair1] has these characteristics:
- ORA-00600:[ktbair1] in parallel recovery slave
- call stack:
-> ksvrdp -> krp_slave_main -> krp_slave_apply ->
-> kcbr_media_apply -> kcbr_apply_change ->
-> kcoapl -> kdxlup -> ktbair2 -> ORA600:[ktbair1]
- the ORA600 tracefile shows the dump of the problematic change
vector header, and it is encrypted (ENC:1), eg:
Error 600 in redo application callback:
Dump of change vector:
CON_ID:0 TYP:0 CLS:1 AFN:7 DBA:0x034cd2b9 OBJ:166589
SCN:0x0000.17a2e5a8 SEQ:1 OP:10.18 ENC:1 RBL:0 FLG:0x0000
index redo (kdxlup): update keydata, count=2
KTB Redo
op: 0x0e ver: 0x00
compat bit: 0 (pre-11) padding: 0
op: [ktbdir] invalid op: 0x0e
and there will be a redo dump started but it may not be
complete, eg:
DUMP REDO
Opcodes *.*
DBAs (file#, block#):
(7, 55366329) .
this is also the case for ORA-600 [6856]
- the database is using encryption
- dump the redo manually for the specific block involved:
- see the incident tracefile DUMP REDO, DBAs to find the file#
and block# to dump
- see the alert log to find which log was being applied at the
time of the OR6000 - this is the logfile to dump
syntax:
alter session set "_sga_clear_dump"=TRUE;
alter system dump logfile ''
dba min dba max ;
the redo dump should confirm the problematic change vector is
encrypted (ENC:1), and
the redo dump should confirm the problematic change vector is
very near to the start of the log - this is a very important
characteristic of this bug, if the problematic change vector
is NOT near to the start of the log, then it's unlikely that
this bug is involved.
note: this redo dump needs to be done on the customer system
because the encryption wallet (and its password) is
needed to decrypt the encrypted change vector data.
Workaround
If problem is encountered in a physical standby database,
refresh the affected files from the primary database
Note:
Any patch/fix for this bug will *not* "repair" already badly encrypted redo.
|
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:21977392 (This link
will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article
|
欢迎关注我的微信公众号"IT小Chen"，共同学习，共同成长！！！
|
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29785807/viewspace-2118457/
，如需转载，请注明出处，否则将追究法律责任。
