Email: service@parnassusdata.com 7 x 24 online support!

ORA-00600: 内部エラー・コード, 引数: [4097]

ORA-00600: 内部エラー・コード, 引数: [4097]

プロのOracle Databaseの復旧サービスを提供
携帯番号: +86 13764045638 メール:service@parnassusdata.com

 

ORA-00600: 内部エラー・コード, 引数: [4097]

 

Linux10.2.0.4システムが異常リカバリした(_allow_resetlogs_corruption隠しバラメタで起動した後にORA-00600:[40xx]に関連する内部的なエラを現れた。作成して新たな取り消しテーブルスペースに切り替える)ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []内部的なエラが現れた。その内部的なエラは(non-fatal)百回以上に現れたときに、アラームログで記録が現れる。
それにインディクスをcrashさせるかもしれない。具体的なログは以下の通り:

 

Errors in file /s01/10gdb/admin/clinica/bdump/clinica_smon_21463.trc:
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Tue Jan 4 23:13:19 2011
Non-fatal internal error happenned while SMON was doing logging scn->time mapping.
SMON encountered 1 out of maximum 100 non-fatal internal errors.

clinica_smon_21463.trc:
Dump of buffer cache at level 4 for tsn=1, rdba=8388633
BH (0x91fdf428) file#: 2 rdba: 0x00800019 (2/25) class: 19 ba: 0x91c62000
set: 3 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2
hash: [fcf7dd68,fcf7dd68] lru: [91fdf5b8,91fdf398]
ckptq: [NULL] fileq: [NULL] objq: [f5b53d60,f5b53d60]
use: [fa694970,fa694970] wait: [NULL]
st: XCURRENT md: SHR tch: 0
flags: gotten_in_current_mode
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 1 rdba: 0x00800019 (2/25)
scn: 0x0000.0352d07c seq: 0x01 flg: 0x00 tail: 0xd07c2601
frmt: 0x02 chkval: 0x0000 type: 0x26=KTU SMU HEADER BLOCK

/* ここであるtsn=1,file#=2のデータブロックをダンプした。
このタイプはKTU SMU HEADER BLOCKでつまりあるロールバックセグメントヘッダ
*/

Hex dump of block: st=0, typ_found=1
……………………
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Current SQL statement for this session:
insert into smon_scn_time (thread, time_mp, time_dp, scn, scn_wrp, scn_bas, num_mappings, tim_scn_map)
values (0, :1, :2, :3, :4, :5, :6, :7)
—– Call Stack Trace —–
calling call entry argument values in hex
location type point (? means dubious value)
——————– ——– ——————– —————————-
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
ksfdmp()+21 call ksedmp() 000000003 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
kgeriv()+176 call ksfdmp() 000000003 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
kgesiv()+119 call kgeriv() 0068C97C0 ? 2ABDF1D42BF0 ?
000000000 ? 0F4A33EA0 ?
7FFFF53BC100 ? 000000000 ?
ksesic0()+209 call kgesiv() 0068C97C0 ? 2ABDF1D42BF0 ?
000001001 ? 000000000 ?
7FFFF53BCEE0 ? 000000000 ?
ktugti()+3200 call ksesic0() 000001001 ? 0068C9940 ?
000000000 ? 00000009A ?
000000010 ? 101010101010101 ?
ktsftcmove()+4149 call ktugti() 0B73F111C ? 7FFFF53BD278 ?
7FFFF53BD280 ? 000000000 ?
7FFFF53BD27C ? 7FFFF53BD270 ?
ktsf_gsp()+1937 call ktsftcmove() 00000000A ? 000000000 ?
000000000 ? 000000000 ?
7FFFF53BD27C ? 7FFFF53BD270 ?
kdtgsp()+512 call ktsf_gsp() 000000000 ? 7FFFF53BF460 ?
000000024 ? 000000002 ?
7FFFF53BF460 ? 000000000 ?
kdccak()+111 call kdtgsp() 2ABDF1D6A2D8 ? 7FFF00000000 ?
2ABDF1D68530 ? 000000002 ?
7FFFF53BF460 ? 000000000 ?
kdcgcs()+5419 call kdccak() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
kdcgsp()+1372 call kdcgcs() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
kdtInsRow()+1808 call kdcgsp() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
insrow()+342 call kdtInsRow() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
insdrv()+594 call insrow() 2ABDF1D6A2D8 ? 7FFFF53BFCC8 ?
000000000 ? 0F4A33DE0 ?
2ABDF1D6A370 ? 000000000 ?
inscovexe()+404 call insdrv() 2ABDF1D6A2D8 ? 7FFFF53BFCC8 ?
000000000 ? 2ABDF1D6D908 ?
2ABDF1D6A370 ? 000000000 ?
insExecStmtExecIniE call inscovexe() 0F4A33DE0 ? 0F4A3C230 ?
ngine()+85 7FFFF53C0EF0 ? 2ABDF1D69F20 ?
2ABDF1D6A370 ? 000000000 ?
insexe()+386 call insExecStmtExecIniE 0F4A33DE0 ? 0F4A3C230 ?
ngine() 2ABDF1D69F20 ? 2ABDF1D69F20 ?
2ABDF1D6A370 ? 000000000 ?
opiexe()+9182 call insexe() 0F4A333A8 ? 7FFFF53C0EF0 ?
0F4A33DE0 ? 2ABDF1D69F20 ?
2ABDF1D6A370 ? 2ABDF1D69F20 ?
opiall0()+1842 call opiexe() 000000049 ? 000000003 ?
7FFFF53C12F8 ? 000000001 ?
…………..
そのORA-00600:[4097]内部的なエラに対して、metalinkのNote [ID 1030620.6]でworkaroundの方法を紹介した:
An ORA-600 [4097] can be encountered through various activities that use
rollback segments.

Solution Description:
=====================

The most likely cause of this is BUG 427389. This BUG is fixed in
version 7.3.3.3. The BUG is caused when Rollback Segments are dropped and
recreated after a shutdown abort. It is encountered through a very specific
set of circumstances:

When an instance has a rollback segment offline and the instance crashes, or
the user does a shutdown abort, the rollback segment wrap number does not get
updated. If that segment is then dropped and recreated immediately after the
instance is restarted, the wrap number could be lower than existing wrap
numbers. This will cause the ORA-600[4097] to occur in subsequent
transactions using Rollback.

To avoid encountering this bug, rollback segments should only be dropped and
recreated after the instance has been shutdown normal and restarted. If you
have already encountered the bug, use the following workaround:

Select segment_name, segment_id from dba_rollback_segs;

Drop all Rollback Segments except for SYSTEM.

Recreate dummy (small) rollback segments with the same names in their place.

Then, recreate additional rollback segments you want to keep with their
permanent storage parameters.

Now drop the dummy ones. This should ensure that the segment_ids are not
reused.

If you ever want to add a rollback segment you have to use the workaround steps
again. If you do not fill the dummy slots you may see the problem re-appear.
異常リカバリする前に既存したトラブルがあったrollback segmentをドロップして、このトラブルを避けられる。10gの場合にAMU(automatic managed undo)で同じようなこともできる:
SQL> alter system set “_smu_debug_mode”=4;
System altered.

/*人工的にロールバックセグメントを管理するために、 SMU debugモードを4と設定してください。*/

SQL> set heading off

SQL> select ‘drop rollback segment “‘||segment_name||'”;’ from dba_rollback_segs where segment_name!=’SYSTEM’;

drop rollback segment “_SYSSMU1$”;
drop rollback segment “_SYSSMU2$”;
drop rollback segment “_SYSSMU3$”;
drop rollback segment “_SYSSMU4$”;
drop rollback segment “_SYSSMU5$”;
drop rollback segment “_SYSSMU6$”;
drop rollback segment “_SYSSMU7$”;
drop rollback segment “_SYSSMU8$”;
drop rollback segment “_SYSSMU9$”;
drop rollback segment “_SYSSMU10$”;
drop rollback segment “_SYSSMU11$”;
drop rollback segment “_SYSSMU12$”;
drop rollback segment “_SYSSMU13$”;
drop rollback segment “_SYSSMU14$”;
drop rollback segment “_SYSSMU15$”;
drop rollback segment “_SYSSMU16$”;
drop rollback segment “_SYSSMU17$”;
drop rollback segment “_SYSSMU18$”;
drop rollback segment “_SYSSMU19$”;
drop rollback segment “_SYSSMU20$”;
drop rollback segment “_SYSSMU21$”;
drop rollback segment “_SYSSMU22$”;
drop rollback segment “_SYSSMU23$”;
drop rollback segment “_SYSSMU24$”;
drop rollback segment “_SYSSMU25$”;
drop rollback segment “_SYSSMU26$”;
drop rollback segment “_SYSSMU27$”;
drop rollback segment “_SYSSMU28$”;
drop rollback segment “_SYSSMU29$”;
drop rollback segment “_SYSSMU30$”;

30 rows selected.

/* 以上のdrop rollback segmentロールバックセグメントのコマンドを実行する
既存する取り消しテーブルスペースのロールバックスペースがofflineできるがdropできない。
実際にやるべきことも前のundoテーブルスペースにトラブルがあるセグメントをドロップする。
*/

SQL> alter rollback segment “_SYSSMU30$” offline;
Rollback segment altered.

SQL> drop rollback segment “_SYSSMU30$”;
drop rollback segment “_SYSSMU30$”
*
ERROR at line 1:
ORA-30025: DROP segment ‘_SYSSMU30$’ (in undo tablespace) not allowed

SQL> alter rollback segment “_SYSSMU30$” online;
Rollback segment altered.
以上のdropトラブルロールバックセグメントをリカバリした後に、システムに二度とORA-00600:[4097]内部エラを現れていない。インスタンスは正常にリカバリした。そして、前の”_smu_debug_mode”UNDO、debugモードを管理する隠しバラメタをもう一度設定してください。