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

 

ORA-00600:[kcbgcur_3]の解決例として、kcbgcur_3という関数にORA-00600エラが現れたとはある”CURRENT”状態にあるcache bufferにストレージされたのは予想したデータアドレスで、つまりTABLESPACE番号と関連するDBA(RDBA)。けどOracleはこのブロックが予想したオブジェクトに属していないと気づいた(実は別のData_object_idを見つけ出したから)。

一般的に、これはデータにロジックエラが現れたからである。主な原因は以下の通り：
1. Lost Writeがひどくて、ロジックの整合性を失った。
2. Oracle自身のbugによってロジックの整合性を失った。
この例でkcbgcur_3に関するargumentはORA-00600: internal error code, arguments: [kcbgcur_3], [91738], [1], [0], [0], [], [], []がデータベースバーションは9.2.0.8である。， 付録のkcbgcur_3のargument情報解析に参考して、各argumentの意味は

Arg [a] 91738 つまりobject_id
Arg [b] 1一時的な相手と意味する
91738でobject_idがエラ相手を獲得できる。相手のタイプによって、異なるリカバリ方法を実行してください。

この例のstack callは以下の通り:
—– Call Stack Trace —–
calling call entry argument values in hex
location type point (? means dubious value)
——————– ——– ——————– —————————-
ksedmp+0148 bl ksedst 102973B94 ?
ksfdmp+0018 bl 01FD34D8
kgerinv+00e8 bl _ptrgl
kgeasnmierr+004c bl kgerinv 000000079 ? 000000000 ?
000000000 ? 70000086D814308 ?
000000079 ?
kcbassertsd4+010c bl kgeasnmierr 110006728 ? 1103FCB28 ?
10302D894 ? 400000004 ?
000000000 ? 00001665A ?
000000000 ? 000000001 ?
kcbgcur+0b90 bl kcbassertsd4 FFFFFFFFFFE8150 ?
8448448400000000 ?
101083D80 ? 1101FB1D0 ?
FFFFFFFFFFFF0000 ?
000000000 ?
ktbgcur+0064 bl kcbgcur FFFFFFFFFFE8550 ? 11042B5B0 ?
FFFFFFFFFFE8260 ? 000000010 ?
kdislink+00ec bl ktbgcur 000000000 ? 000000000 ?
000000000 ? 110002E40 ?
kdisle+3e8c bl kdislink 000000020 ? 110405C30 ?
70000087CC49528 ?
70000087CC48830 ?
kdiins0+17a0 bl kdisle 700000884D0E400 ?
FFFFFFFFFFE8C78 ?
FFFFFFFFFFE8D60 ?
100000000000001 ?
2000000000002 ? 11041A738 ?
FFFFFFFFFFFFFFFF ?
000000000 ?
kauxsin+2088 bl kdiins0 700000884D0E400 ? 000000000 ?
000000B40 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 2000000000000 ?
insidx+08fc bl kauxsin 700000884D115B8 ?
FFFFFFFFFFF86DC ?
F2FFFFFFFF8530 ? 1103CEF18 ?
1103CEFA0 ? 1103CEFC8 ?
1103CEED8 ? 000000000 ?
insflush+0204 bl insidx 700000884D1DEB0 ?
insrow+01ec bl insflush 1103CEDF0 ? 000000000 ?
10009E1D4 ? FFFFFFFFFFF90A0 ?
000000000 ?
insdrv+05f4 bl insrow 1103CEDF0 ? FFFFFFFFFFF90A0 ?
000000000 ?
insexe+0648 bl insdrv 1103CEDF0 ?
opiexe+1e44 bl insexe 700000884DCD2D8 ?
700000884DCCE88 ?
opiodr+08cc bl _ptrgl
ttcpip+0cc4 bl _ptrgl
opitsk+0d60 bl ttcpip 11000D3B0 ? 000000000 ?
付録

kcbgcur_3 ORA-00600についての詳しい情報、そのエラargument情報の意味は以下の通り：

10gR2とその後は:

Arg [a] Object Id passed to the cache by the layer accessing the cache.
Arg [b] Class of the block.
Arg [c] Flags which define characteristics of buffer usage
Arg [d] 1 for a temporary object.

10gR1の情報は：

Arg [a] Object Id passed to the cache by the layer accessing the cache.
Arg [b] Class of the block.
Arg [c] 1 for a temporary object.

Oracle 9.Xの情報は：

Arg [a] Object Id passed to the cache by the layer accessing the cache.
Arg [b] 1 for a temporary object.

Oracle 8.0.4から8.1.7までの情報は：

Arg [a] Class of the block.
Arg [b] Tablespace number.
Arg [c] Relative DBA.
Arg [d] Object Id in the cache buffer at the time of the error.
Arg [e] Object Id passed to the cache by the layer accessing the cache. Indicates if this is a temporary or a permanent object.
Arg [f] In version 8.0.4 to 8.1.5, this is 1 for a permanent object. In version 8.1.6 and 8.1.7, this is 1 for a temporary object.

Oracle 8.0.3の情報は:
Arg [a] Class of the block.
Arg [b] Tablespace number.
Arg [c] Relative DBA.
Arg [d] Object Id in the cache buffer at the time of the error.
Arg [e] Object Id passed to the cache by the layer accessing the cache.

kcbgcur_3に関連するBUGリストは以下の通り：

13467683
11902008
11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP04, 12.1.0.0
Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368
12.1.0.0
SMON may crash with ORA-00600 [kcbgcur_3] or ORA- 600 [kcbnew_3] during Transaction recovery
7227645
11.1.0.7, 11.2.0.1
OERI[kcbgcur_3]/OERI[kcb_check_objd_typ] during INSERT on freelist-managed segment
6444339
10.2.0.5, 11.2.0.1
Truncate/purge does not clean AQ dependencies properly
6337376
11.1.0.7
OERI:kcbgcur_3 / ORA-8103 after truncating a partition table with LOBs
5909305
11.1.0.6
Change to DML (TM) lock modes for foreign key constraints
5303237
11.1.0.6
ORA-600 [kcbgtcr_5] during create queue table
8778379
10.2.0.5
Fix event 10227 in 10.2 ORA-600[kcbgcur_3] or ORA- 600[kcbgcur_9]
3963135
10.1.0.5, 10.2.0.1
OERI[kcbgcur_3] / OERI:25027 during bitmap index updates
2784201
9.2.0.5, 10.1.0.2
OERI:[ktspfupdst-1] on INSERT into LOB after TRUNCATE with ASSM
3693283
9.0.1.0
TRUNCATE can cause SMON to crash the instance with OERI:[KTSF_RSP2]
1148416
8.1.6.1, 8.1.7.0
Buffer cache corruption can occur using GLOBAL TEMPORARY TABLES
689973
8.0.4.4, 8.0.5.1, 8.0.6.0
OERI:KCBGCUR_3 during DROP/CREATE table with concurrent queries.

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

ORA-00600[2256]エラが現れて、関連する情報は以下の通り：
ORA-00600: internal error code, arguments: [2256], [0], [1073741824], [5], [40009], [], [], []

複数のargumentの意味：

ora-600 [2256][0][1073741824][1][293672646]

ERROR:
ORA-600 [2256][a][b][c][d][e]

VERSIONS:
versions 7.3.X, 8.0.X, 8.1.X

DESCRIPTION:
This exception indicates that you attempted to ADJUST_SCN but the level
supplied would be less that the current SCN.

ARGUMENTS:
a. Requested SCN WRAP
b. Requested SCN BASE
c. Current SCN WRAP
d. Current SCN BASE = [293672646]

 

ORA-00600[2662]エラのように、そのエラはシステムSCNで解決できる。

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

exp TC/TC direct=true
imp TC/TC show=y full=y
^
Import fails as the export file is corrupt:
IMP-9: abnormal end of export file

00009, 00000, “abnormal end of export file”
// *Cause: The export file is probably from an aborted Export session.
// *Action: If so, retry the export and import. Otherwise, report this as an
// Import bug and submit the export file that caused this error to
// customer support.

IMP-00009 abnormal end of export file，このエラはimpでデータをインポートする時に一部の情報が空っぽあるいは識別できないから、エラになった。以下のような場合によく現れる：
 Impが正確ではない buffer / commitなどのバラメタを利用していたから
 違ったexp-impツール組合を使ったから
 exp/dmpファイル自身がこわれた

前述した1、2の場合に、使っているexp/impバーションあるいはバラメタを調整すれば避けられる。
けど、exp/dmpファイル自身がこわれた場合に対して、データを再びエクスポートするしかない。データをエクスポートできない場合に、exp/dmpファイルのデータを使っていれば、DULのツールでこわれたexp/dmpファイルのデータを抽出する。

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

 

Oracleデータベースが起動できないときに、大体は以下の状況に分けられる：

• バラメタ設定が間違えた
• コントロールファイルが壊れた
• ログファイルがこわれた
• データファイルヘッダがこわれた
• データディクショナリーがこわれた
• UNDO損害
• SMONがトランザクションをロールバックするときにトラブルが起きた

 

異なるエラORA-00600/ORA-07445などに対して、異なった対応法も挙げられる：

ORACLEで現れたデータブロック損害/診断corruptionはいろいろあるが、症状に分けると、以下の通りになる：
 ORA-01578エラ
 ORA-600[61xx]エラ
 ORA-600[3339]あるいはORA-600[3398]
 ORA-600[2130],ORA-600[2845],ORA-600[4147]エラなど
 SELECT が探し出したエラデータ

このようなORACLEデータブロックがこわれたトラブルに対して、以下のような使いやすいステップがある：
1、データベースがオープンした状態ではブロックが位置しているデータファイル番号、ブロック番号を判断する必要がある（テーブルあるいはインディクス）。ORA-1578エラあるいはORA-600が報告した変数情報に対して、以下のSQLで位置を確かめる

SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = &fileid
and &blockid between block_id AND block_id + blocks – 1;

2、前のステップに獲得したSEGMENT_TYPEによって、以下のSEGMENT_TYPEの場合は再構造できる：
 index
 データはテーブルを再び獲得できるあるいはテーブルを再構造できる
 SYSTEMというロールバックセグメントを除いて、セグメントをロールバック。t
 一時的なテーブル

3、ステップ２インポートに属していなければ、以下の情報を確認してください：
 データベースはアーカイブモードか
 export /sqlldrを含んで、テーブルのバックアップデータがあるか。
 そのテーブルに NOT NULLセグメントに基づくインディクスがあるか？
 このようなインディクスがあれば、UNIUQEに属しているか？

4、前にこのレポジトリにブロックが壊れたことがあるかを確かめてください。経験豊かなDBAはalert.logで大体の状況を把握できるが、前にこのようなトラブルが現れたことがあれば、次のアドバイスに参考してください：

5、ユーザーがアーカイブモードを使っているなら、今後の診断のために、アーカイブredoとオンラインログを格納してください。アーカイブモードでなければすべてのオンラインログをバックアップしてください。

6、場合によると10210,10211と10212 eventでエラの原因も見つけ出せる。Oracle自身でトラブルを引き起こしたわけではない場合に、トラブルがあるデータブロックをダンプして、OS、ストレージと巻コントローラーのログで分析してください。メモリー損害の場合に、_db_block_cache_protectを使ってください。けど、すべてのプラットフォームも_db_block_cache_protectを支持しているわけではない。

7、ある場合に、ユーザーがアーカイブモードでトラブルが再び現れたときにリカバリできないことを避けられる。

必要な証拠

1、 ORACLE TRACEとALERTファイルを含んで、このようなトラブルの源を診断して、報告に別のデータブロックがこわれたかを確認する。
2、OSでこわれたデータブロックをダンプする
Unix: dd if=badfile.dbf count=5 bs=2048 skip=75

アドバイス

1、traceあるいはredoログダンプするときに、ユーザーの予想を調整してください：
 リカバリする方法を考えるではなく、原因を探し出してください
 証拠があるが、決定的な結論を下せる訳ではない。

2、時にデータブロックがメモリーでこわれた。例えばORA-600[3398]、これを検証するには：
 analyze table X validate structure cascade;
 alter system flush buffer_cache;
 OSでそのデータブロックをダンプして分析する

後処置

1、本質を探す、例えば：
 すべての損害はある設備、コントローラーで起こる。
 四つブロックごとに一つのブロックが壊れる。
 データブロック自身に何の問題もないが、現れる位置を間違えた。
 データブロックは健全だが、別のところにトラブルが起こった。

2、損害/こわれたブロックがあるデータブロックを避けて、テーブルを再構造する：
10231 level 10トランザクションで全テーブルスキャンのCTASを実行する
ROWIDを構造してこわれたブロックにアクセスすることを避ける
【データリカバリ】ROWIDを構造することで、バックアップなしにORA-1578、ORA-8103、ORA-1410などトラブルを避ける。

3、 10210、10211及び10212でデータブロックをアップグレードして、こわれたブロックの詳しい内容を確かめる。10231 eventを使ってください。

ほかのツール

ほかのツールはdul、oranum、orapatch、bbedなどORACLE内部的なツールを含んでいる。

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

 

ORA-01221エラは8iによく現れるが、10gの後にめったり現れない。

Error: ORA 1221
Text: datafile <name> is not the same file to a background process
——————————————————————————-
Cause: When the database writer opens the datafile, it is accessing a
different physical file than the foreground doing the recovery.
The time-stamp set in the file header by the foreground was not found
by the background.
It may be that the background process could not read the file at all.
Action: Look in the DBWR trace file for the error it received when attempting
to read the file header.
Reconfigure the operating system as needed to have the filename
successfully access the same file when opened by a background process.
Hdr: 4395739 10.1.0.3 RDBMS 10.1.0.3 RECOVERY PRODID-5 PORTID-219 ORA-1221
Abstract: AFTER RESIZING A DATAFILE, OTHER DATAFILE IS CORRUPT ORA-1237 ORA-1221

If datafile is resized beyond space available, error occurs, database crashes
and a different datafile shows ORA-1221 corruption

Hdr: 706775 8.0.3.2.0 RDBMS 8.0.3.2.0 PRODID-5 PORTID-89 ORA-1221
Abstract: ORA-470, ORA-449 AND ORA-1221 ON STARTUP
Symptom(s)
~~~~~~~~~~

When recreating a controlfile, you receive the following errors:

ORA-01503: CREATE CONTROLFILE failed
ORA-01227: log is inconsistent with other logs

When trying to open the database after a failed controlfile creation you may receive:

ORA-01221: data file 1 is not the same file to a background process
Change(s)
~~~~~~~~~~

You issued exec sys.dbms_backup_restore.zerodbid(fno => 0) while the database was open.
Cause
~~~~~~~
Database Corruption Will Occur During the Cloning Process when the Above Command
is Performed with the Database Mounted.

The function dbms_backup_recovery.zeroDbid must never be invoked while the database is open
as this could damage it (impossible to mount and dismount the database).

(Internal Note)

Fix
~~~~

Recreate the controlfile with the SET DATABASE option:

CREATE CONTROLFILE REUSE SET DATABASE “RPT1” RESETLOGS ARCHIVELOG

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

あるユーザーが11.1.0.6のシステムが電源を切れた後に再起動するときにORA-600 [4194]エラが現れた：

Starting background process QMNC
Wed Dec 10 21:26:24 2014
QMNC started with pid=21, OS id=2932
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc (incident=33600227):
ORA-00600: 内部エラコード　バラメタ: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600227\erp_smon_3612_i33600227.trc
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery stopped at EOT rba 1.129.16
Block recovery completed at rba 1.129.16, scn 0.1309041534
Doing block recovery for file 3 block 121
Block recovery from logseq 1, block 127 to scn 1309041531
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery completed at rba 1.128.16, scn 0.1309041533
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc:
ORA-01595: 释放区 (2) セグメントをロールバックするときに(8) エラが現れた
ORA-00607: データブロックを変更するときに内部的なエラが現れる
ORA-00600: 内部エラコード　バラメタ: [4194], [60], [59], [], [], [], [], []
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Wed Dec 10 21:26:26 2014
Trace dumping is performing id=[cdmp_20141210212626]
Wed Dec 10 21:26:31 2014
Sweep Incident[33600227]: completed
Wed Dec 10 21:26:31 2014
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_m004_4524.trc (incident=33600347):
ORA-00600: 内部エラコード　バラメタ: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600347\erp_m004_4524_i33600347.trc
Trace dumping is performing id=[cdmp_20141210212632]
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534

ump of buffer cache at level 4 for tsn=2, rdba=12587290
BH (0x000000016BFB7308) file#: 3 rdba: 0x00c0111a (3/4378) class: 32 ba: 0x000000016B7EA000
set: 11 bsz: 8192 bsi: 0 sflg: 2 pwc: 51 lid: 0x00000000,0x00000000
dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3
hash: [0x00000001E2F7DCC0,0x00000001E2F7DCC0] lru: [0x000000016BFB74C8,0x000000016BFB7268]
obj-flags: object_ckpt_list
ckptq: [0x000000016BF8F7F8,0x000000016BFB7478] fileq: [0x00000001E3BDB698,0x000000016BFB7488] objq: [0x000000016BFEAFC8,0x000000016BF821D8]
use: [0x00000001D8653448,0x00000001D8653448] wait: [NULL]
st: XCURRENT md: EXCL tch: 0
flags: buffer_dirty mod_started gotten_in_current_mode
change state: ACTIVE
change count: 1
LRBA: [0x14.7d.0] LSCN: [0x0.4e0c7c32] HSCN: [0x0.4e0c7c32] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 2 rdba: 0x00c0111a (3/4378)
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
*** ktuc_diag_dmp: dump of redo for rdba 0x00c0111a
Cleaning up copy latch 0
Copy latch cleanup completed
DUMP REDO
Opcodes *.*
DBAs (file#, block#):
(3, 4378) .
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
**NOTE: Only Dumping Redo less then 12 hours**
Times: 12/10/2014 21:23:27 thru eternity

*** 2014-12-11 09:23:27.382
SCN Start Scan Point: scn: 0x0000.4e0bd8c2 (1309399234)
INCARNATION:
START: scn: 0x0000.4e0662ee (1309041390) Timestamp: 12/10/2014 21:26:17
END: scn: 0xffff.ffffffff
descrip:”Thread 0001, Seq# 0000000018, SCN 0x00004e0bd8c2-0x00004e0c295e”

REDO RECORD – Thread:1 RBA: 0x000012.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0bd8c4 SUBSCN: 1 12/11/2014 09:19:10
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:”Thread 0001, Seq# 0000000019, SCN 0x00004e0c295e-0x00004e0c79f5″

REDO RECORD – Thread:1 RBA: 0x000013.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c2960 SUBSCN: 1 12/11/2014 09:20:14
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:”Thread 0001, Seq# 0000000020, SCN 0x00004e0c79f5-0xffffffffffff”

REDO RECORD – Thread:1 RBA: 0x000014.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c79f7 SUBSCN: 1 12/11/2014 09:23:13
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
END OF DUMP REDO
Incident 35120409 created, dump file: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_35120409\erp_ora_548_i35120409.trc
ORA-00600: 内部エラコード　バラメタ: [4194], [60], [59], [], [], [], [], []

Error 607 in redo application callback
Dump of change vector:
TYP:0 CLS:32 AFN:3 DBA:0x00c0111a OBJ:4294967295 SCN:0x0000.4e0662ff SEQ: 2 OP:5.1
ktudb redo: siz: 208 spc: 1094 flg: 0x0012 seq: 0x91a4 rec: 0x3b
xid: 0x0008.01d.001511ce
ktubl redo: slt: 29 rci: 0 opc: 11.1 objn: 74 objd: 74 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c0111a.91a4.39
prev ctl max cmt scn: 0x0000.4e065bc8 prev tx cmt scn: 0x0000.4e065be6
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 12587289 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 0
op: L itl: xid: 0x000d.012.000346f7 uba: 0x00c01d8e.1899.2a
flg: C— lkc: 0 scn: 0x0000.4e0c7c3e
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x00400222 hdba: 0x00400221
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 8(0x8) flag: 0x2c lock: 0 ckix: 0
ncol: 10 nnew: 9 size: 0
Vector content:
col 1: [ 2] c1 02
col 2: [ 2] c1 02
col 3: [ 2] c5 15
col 4: [ 2] c1 02
col 5: [ 1] 80
col 6: [ 2] c3 02
col 7: [ 5] c4 06 4a 13 0b
col 8: [32]
2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d
2d 2d 2d 2d 2d 2d 2d
col 9: [ 1] 80
Block after image is corrupt:
buffer rdba: 0x00c0111a
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000016B7EA000 to 0x000000016B7EC000
16B7EA000 0000A202 00C0111A 4E0662FF 04020000 [………b.N….]

ORA-00600: 内部エラコード　バラメタ: [4194]エラは前に何度も言ったが、
【Oracleデータリカバリ】BBEDでORA-600[4193]とORA-600[4194]をリカバリする例
【Oracleデータリカバリ】ORA-600[4194]エラ例

ORA-600[4194]内部的なエラは常にredo記録とロールバック記録がマッチできないから引き起こしたものである。OracleはUndo record numberをテストしているときに、比redo changeとセグメントロールバックセグメントのundo record numberを比べて、二つには相違があったら、4194エラになる。そのエラargument[a][b]，aはロールバックブロックの最大undo record numberで，bはredoログのundo record numberである。このエラはロールバックセグメントとredo logローグファイルのエラで引き起こした。
ORA-00600[4194]エラの根本的な原因は redo記録とロールバックセグメントの記録が一致していないから(rollback/undo)である。ORACLEがundo記録をテストする時に、該当する変化はundoデータブロックの最大undo記録に応用する必要がある。エラが現れたら、ORA-00600[4194]と報告する

ORA-600[4194]の二つの意味：
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block

以上はtraceでUNDOトラブルを引き起こす可能性があるデータブロック見つけ出した。そのブロックはrdba: 0x00c0111a (3/4378)。このトラブルはEVENTを設定して、バラメタあるいはBBEDでリカバリできる。

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

 

ORACLEで作成したデータブロック損害/こわれた診断corruptionは色々あるが、症状によって分類すると、大体以下の通り：
 ORA-01578エラ
 ORA-600[61xx]エラ
 ORA-600[3339]あるいはORA-600[3398]
 ORA-600[2130],ORA-600[2845],ORA-600[4147]エラなど
 SELECT クエリで誤ったデータを探し出す

ORACLEデータブロック損害/こわれた診断の解決策は、以下のような方法がある：
1.データベースをオープンしたまま、そのブロック損害とこわれたブロックがあるデータファイル番号、ブロック番号を判断する必要があって、それに、具体的な相手に探してください（テーブルあるいはインディクス）。ORA-1578エラとORA-600が報告した変数情報によって、以下のようなSQLを実行してください。

SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = &fileid
and &blockid between block_id AND block_id + blocks – 1;

2、前のステップのSEGMENT_TYPEによって， もし以下のようなSEGMENT_TYPEであれば、再構造できる。：
 index
 データが再び獲得できるテーブルと再構造できるテーブル
 SYSTEMを除き、ロールバックセグメント
 順列セグメント, sort segment
 一時的なテーブル

3、 ステップ２にあるタイプに属していなければ、以下の情報を確認してください：
 データベースはアーカイブモードにあるか
 export /sqlldrを含んで、テーブルのバックアップデータがあるか
 NOT NULLセグメントに基づくインディクスがあるか
 このようなインディクスがあれば、それはUNIUQEかを確認してください？

4、このリポジトリが前にブロック損害/ブロックがこわれた場合が現れたかを確認してください。これについて、経験豊かなDBAはalert.logで大体な情報を獲得できる。もしこのようなトラブルがあれば、後のアドバイスを参考してください。

5、もしユーザーがアーカイブモードにいるなら、後の診断のために、アーカイブモードredoとオンラインログを格納してください。もしアーカイブモードでなくれば、すべてのオンラインログを格納してください。

6、できれば10210,10211と10212 eventを作成して、エラソースを獲得してください。もし現場エンジニアはORACLE自身でトラブルを起こしたと疑っていれば、トラブルがあるデータブロックをダンプして、OSとストレージ、巻管理のログで分析してください。メモリー損害の場合には_db_block_cache_protect を確認してください。けどすべてのプラットフォームも_db_block_cache_protectを支持しているとは限らない。

7、ある場合には、アーカイブモードで後のトラブルが起こったら、アーカイブモードで再びトラブルが起きた時にリカバリできないことを避けられる。

必要とする証拠

1、 ORACLE TRACEとALERTファイルは診断の源である。そして、報告で別のデータブロックがこわれているかを分析する。
2、OSでこわれたデータブロックをダンプする
Unix: dd if=badfile.dbf count=5 bs=2048 skip=75

あとのアドバイス

1、traceを分析しているときあるいはログをダンプしているときにユーザーの予想とユーザーに示したい情報を調整してください：
 まずはリカバリするを判断することじゃなくて、原因を探し出してください
 これらの証拠を研究しているが、これらの証拠は決定的な結論を下せるわけではない。

2、時に、データブロックがメモリーでこわれた。例えばORA-600[3398]、この状況をテストするには：
 analyze table X validate structure cascade;
 alter system flush buffer_cache;
 OSでデータブロックをダンプして、分析する。

あとの処置

1、本質をさがす、例えば：
 すべての損害はある裸の設備にあるいはコントローラーに起こる。
 四つのブロックごとに一つこわれたブロックがある
 データブロック自身には問題はないが現れた位置が誤った。
 データブロックは何のトラブルもないが、ほかのトラブルが起きた。

2、 存在を避けて、損害/こわれたブロックでテーブルを再構造する：
10231 level 10トランザクションで全テーブルスキャンのCTASを作成する
ROWIDを構造することでこわれたデータブロックをアクセスすることを避けられる。 【データリカバリ】 ROWIDを構造することでバックアップなしにORA-1578、ORA-8103、ORA-1410などのロジック/物理こわれたブロックのトラブルを避けられる

3、 10210、10211および10212を使って、そしてデータブロックをアップグレードして、ブロックのより詳しい情報を獲得する。10231 eventを使ってもいい。

ほかのツール

ほかの選べるツールはdul、oranum、orapatch、bbedなども含んでいる。これらもORACLE内部ツールである。

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

 

たまにはORA-01122,ORA-01110,ORA-01200エラが現れる、例えば：

ORA-01122: database file 9 failed verification check
ORA-01110: data file 9: ‘/u02/oradata/orcl/users01.dbf ‘
ORA-01200: actual file size of 64000 is smaller than correct size of 65600
[oracle@mlab2 ~]$ oerr ora 1122
01122, 00000, “database file %s failed verification check”
// *Cause: The information in this file is inconsistent with information
// from the control file. See accompanying message for reason.
// *Action: Make certain that the db files and control files are the correct
// files for this database.
[oracle@mlab2 ~]$ oerr ora 1110
01110, 00000, “data file %s: ‘%s'”
// *Cause: Reporting file name for details of another error. The reported
// name can be of the old file if a data file move operation is
// in progress.
// *Action: See associated error message.
[oracle@mlab2 ~]$ oerr ora 1200
01200, 00000, “actual file size of %s is smaller than correct size of %s blocks”
// *Cause: The size of the file as returned by the operating system is smaller
// than the size of the file as indicated in the file header and the
// control file. Somehow the file has been truncated. Maybe it is the
// result of a half completed copy.
// *Action: Restore a good copy of the data file and do recovery as needed.

バックアップもアーカイブバックアップもある場合に、バックアップをリカバリすることでトラブルをリカバリできる。この記事ではバックアップがない場合に、トラブルを解決するために、いろんな方法を検討する。SYSTEMテーブルスペースのデータファイルに対して同じ方法を使わないでください。

まずはデータベースごとに対してコールドバックアップする。ORA-01110 とORA-01122のエラを分析して、トラブルが起きたファイル番号を見つけ出せる。例えば、以下の例にはFILE#=9ファイルがエラになった：

ORA-01122: database file 9 failed verification check
ORA-01110: data file 9: ‘/u02/oradata/orcl/users01.dbf ‘

前の例にはORA-01200: actual file size of 64000 is smaller than correct size of 65600，つまりファイル実際のサイズは64000*db_block_size+一つのOracle BLock=64000 * 8192 + 8192 =524296192
ls -ltr データファイルで再びサイズを確認できる。

けど、ORACLEがデータファイルヘッダから獲得したデータファイルの理論的なサイズは65600 –> 65000 * 8192 +8192=532488192 bytesである。

二つの結果を比べてみれば、65600-64000=1600のブロックの差があるかも知れないので、ddで調整することより、今のデータファイルに追加できる。当然、追加したは空のブロックである。
例えば：

dd if=<locationf datafile having problem> of=<output/target datafile> count=< > bs=<db_block_size in bytes>

dd if=/u02/oradata/orcl/users01.dbf of=/tmp/corr_temp.DBF count=64000 bs=8192

1600の空のブロックを新しいデータファイルに追加する
dd if=/dev/zero of=<location of datafile> bs=<db_block_size in bytes> seek=<Actual block number reported + 1 > count=<Difference in number of block>

例えばdd if=/dev/zero of=/u02/oradata/careware/users01.dbf bs=8192 seek=64001 count=1600 conv=notrun

データを起動した時にデータファイルヘッダとコントロールファイル情報だけをテストするから、前のの操作はORACLEテストを騙すことができる。けど、データベースを起動した後にすべての使用可能なデータをエクスポートして、データベースを再構造してください。

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

$ oerr ora 704
00704, 00000, “bootstrap process failure”
// *Cause: Failure in processing bootstrap data – see accompanying error.
// *Action: Contact your customer support representative.

$ oerr ora 39700
39700, 00000, “database must be opened with UPGRADE option”
// *Cause: A normal database open was attempted, but the database has not
// been upgraded to the current server version.
// *Action: Use the UPGRADE option when opening the database to run
// catupgrd.sql (for database upgrade), or to run catalog.sql
// and catproc.sql (after initial database creation).

Recovery of Online Redo Log: Thread 1 Group 3 Seq 9 Reading mem 0
Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\orcl\REDO03.LOG
Tue Dec 10 09:33:56 2013
Completed redo application
Tue Dec 10 09:33:56 2013
Completed crash recovery at
Thread 1: logseq 9, block 5, scn 10226857380
0 data blocks read, 0 data blocks written, 2 redo blocks read
Tue Dec 10 09:33:56 2013
Thread 1 advanced to log sequence 10 (thread open)
Thread 1 opened at log sequence 10
Current log# 1 seq# 10 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\orcl\REDO01.LOG
Successful open of redo thread 1
Tue Dec 10 09:33:57 2013
SMON: enabling cache recovery
Tue Dec 10 09:33:57 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_1596.trc:
ORA-00704: プログラムをガイドすることが失敗した
ORA-39700: UPGRADE オプションでデータベースを起動してください

Tue Dec 10 09:33:57 2013
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Tue Dec 10 09:33:57 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mman_4060.trc:
ORA-00704: bootstrap process failure

Tue Dec 10 09:33:57 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_dbw0_1800.trc:
ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option

The following is observed in the sqlplus session

SQL> startup;
ORACLE instance started.

Total System Global Area 1954160640 bytes
Fixed Size 2227752 bytes
Variable Size 1325400536 bytes
Database Buffers 620756992 bytes
Redo Buffers 5775360 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Process ID: 22861
Session ID: 1705 Serial number: 5

以上のORA-00704とORA-39700 二つのエラは一般的にデータベースデータディクショナリーを誤った操作した場合に、バーション違ったにもひどいトラブルがあるかも知れない。

一般的、正確なORACLE PATHを調整してください。同時に、ディクショナリーをアップグレードするスクリプトを再び実行する。例えば、 catupgrd.sql； まだ解決出来ない場合には、人工的にpatch データディクショナリーを調整してください。

 

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

ORA-00600[4000]はOracle カーネルトランザクションのundoモジュールエラ情報の内部的なエラ情報である。一般的にはORA-00600[4000]エラは一つのargumentをつきそっている。そのarg[a]はUndo segment number USNと示している。

古いバーションにはテーブルスペースでインポートして、それにインポートしたテーブルはDMLがあるときに、BUGによってエラになる。エラになった場合に、ファイル1371820.8を参考してください。

9iあとのバーションにはORA-00600[4000]エラになったら、一般的にその原因は電源が切れたあるいはトラブルによるOracleのundo segmentをこわれた。インスタンスをまともに示していないまま、データをオープンするときに現れる。

以下はORA-00600[4000]のBUG リスト：

 

NB	Bug	Fixed	Description
	16761566	11.2.0.4, 12.1.0.2, 12.2.0.0	Instance fails to start with ORA-600 [4000] [usn#]
	13910190	11.2.0.3.BP15, 11.2.0.4, 12.1.0.1	ORA-600 [4000] from plugged in tablespace in Exadata
	14741727	11.2.0.2.9, 11.2.0.2.BP19, 11.2.0.3.BP12, 11.2.0.3.BP13, 12.1.0.1	Fixes for bug 12326708 and 14624146 can cause problems – backout fix
+	10425010	11.2.0.3, 12.1.0.1	Stale data blocks may be returned by Exadata FlashCache
*	9145541	11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.1	OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g
	12353983		ORA-600 [4000] with XA in RAC
	7687856	11.2.0.1	ORA-600 [4000] from DML on transported ASSM tablespace
	2917441	11.1.0.6	OERI [4000] during startup
	3115733	9.2.0.5, 10.1.0.2	OERI[4000] / index corruption can occur during index coalesce
	2959556	9.2.0.5, 10.1.0.2	STARTUP after an ORA-701 fails with OERI[4000]
	1371820	8.1.7.4, 9.0.1.4, 9.2.0.1	OERI:4506 / OERI:4000 possible against transported tablespace
+	434596	7.3.4.2, 8.0.3.0	ORA-600[4000] from altering storage of BOOTSTRAP$

 

ORA-00600[4000]をリカバリする方法はADJUST_SCNトランザクション、_MINIMUM_GIGA_SCNでSCNを修正する、ほかの隠しバラメタを使う、あるいはundo segment/ITL に対して人工的にBBEDで修正するなどの方法がある。

 

Bug 16761566 – INSTANCE FAILED TO START WITH ORA-600 [4000] [USN#]

SYSTEMスペーステーブルに対して実行してくださいexec dbms_space_admin.tablespace_fix_segment_extblks(‘SYSTEM’);の場合にはトラブルがあるかもしれない

 

 

ORA-01092: ORACLE instance terminated. Disconnection forcedORA-00704: bootstrap process failureORA-00600: internal error code, arguments: [4000], [170], [], [], [], [], [], [], [], [], [], []

 

だから、どんな場合にもSYSTEMテーブルスペースに実行しないでください。DBMS_SPACE_ADMIN.TABLESPACE_FIX_SEGMENT_EXTBLKS 。

このトラブルを修正するために、PITR point in time recovery を使ってください。バックアップがなければ、人工的にbootstrap$のsegment headerを修正するしかない。