【Oracle ASMデータリカバリ】ORA-15038: disk ‘XXXXXXX’ mismatch on ‘Time Stamp’ with Target Disk Groupエラ解析

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

 

Diskgroupをmountするときに、以下のようなエラが現れた、以下の文を読んでください:

 

SQL> alter diskgroup DATA mount;

alter diskgroup DATA mount

*

ERROR at line 1:

ORA-15032: not all alterations performed

ORA-15040: diskgroup is incomplete

ORA-15042: ASM disk “17” is missing from group number “1”

ORA-15042: ASM disk “16” is missing from group number “1”

ORA-15042: ASM disk “15” is missing from group number “1”

ORA-15042: ASM disk “14” is missing from group number “1”

ORA-15042: ASM disk “13” is missing from group number “1”

ORA-15038: disk ‘ORCL:DATA25’ mismatch on ‘Time Stamp’ with target disk group [1861040353] [1861808156]

ORA-15038: disk ‘ORCL:DATA24’ mismatch on ‘Time Stamp’ with target disk group [1861040353] [1861808156]

ORA-15038: disk ‘ORCL:DATA23’ mismatch on ‘Time Stamp’ with target disk group [1861040353] [1861808156]

ORA-15038: disk ‘ORCL:DATA22’ mismatch on ‘Time Stamp’ with target disk group [1861040353] [1861808156]

ORA-15038: disk ‘ORCL:DATA21’ mismatch on ‘Time Stamp’ with target disk group [1861040353] [1861808156]

 

[oracle@mlab2 ~]$ oerr ora 15042

15042, 00000, “ASM disk \”%s\” is missing from group number \”%s\” ”

// *Cause:  The specified disk, which is a necessary part of a diskgroup,

//          could not be found on the system.

// *Action: Check the hardware configuration.

//

[oracle@mlab2 ~]$ oerr ora 15038

15038, 00000, “disk ‘%s’ mismatch on ‘%s’ with target disk group [%s] [%s]”

// *Cause:  An attempt was made to mount into a disk group a disk whose

//          recorded allocation unit size, metadata block size, physical

//          sector size, or creation time stamp was inconsistent with the other

//          disk group members.

// *Action: Check if the system configuration has changed. Verify disk

//          discovery string.

//

 

 

 

一般的に、そのエラはOSレベルの多パス配置にトラブルが起こった。あるノートに大量なストレージが現れたことに引き起こした。

例えば:

 

 

NOTE: cache opening disk 11 of grp 1: DATA2 label:DATA2 <<<<<<<<<<<<<<<<<< 5 NOTE: cache opening disk 12 of grp 1: DATA20 label:DATA20 >

NOTE: cache opening disk 13 of grp 1: DATA3 label:DATA3 <<<<<<<<<<<<<<<<<<<<<< 6

NOTE: cache opening disk 14 of grp 1: DATA4 label:DATA4

NOTE: cache opening disk 15 of grp 1: DATA5 label:DATA5

NOTE: cache opening disk 16 of grp 1: DATA6 label:DATA6

NOTE: cache opening disk 17 of grp 1: DATA7 label:DATA7

NOTE: cache opening disk 18 of grp 1: DATA8 label:DATA8

NOTE: cache opening disk 19 of grp 1: DATA9 label:DATA9

 

 

 

そしてkfedでDISK HEADERを検証する、以下のスクリプトを使ってください:

#! /bin/sh

rm /tmp/kfed_DH.out /tmp/kfed_FS.out /tmp/kfed_BK.out /tmp/kfed_FD.out /tmp/kfed_DD.out /tmp/kfed_PST.out

for i in `ls /dev/asm-disk*`

do

echo $i >> /tmp/kfed_DH.out

kfed read $i >> /tmp/kfed_DH.out

echo $i >> /tmp/kfed_FS.out

kfed read $i blkn=1 >> /tmp/kfed_FS.out

echo $i >> /tmp/kfed_BK.out

kfed read $i aun=1 blkn=254 >> /tmp/kfed_BK.out

echo $i >> /tmp/kfed_FD.out

kfed read $i aun=2 blkn=1 >> /tmp/kfed_FD.out

echo $i >> /tmp/kfed_DD.out

kfed read $i aun=2 blkn=2 >> /tmp/kfed_DD.out

echo $i >> /tmp/kfed_PST.out

kfed read $i aun=1 blkn=2 >> /tmp/kfed_PST.out

done

 

ORA-08103エラを診断する

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

 

ORA-08103エラの診断は8103エラのERROR STACK TRACEを作成する必要がある。TRACEで8103オブジェクトを引き起こした具体的なOBJとOBJDを記録する・これはcorruptionを含むかもしれないオブジェクトをより容易く探し出せる。けどフォアグラウンドプロセスがORA-08103になるから、バックグラウンドでTRACEファイルを作成しない、これは8103を設定し、ERRORSTACKのEVENTS引き起こす必要がある:

 

ALTER SYSTEM SET  EVENTS  ‘ 8103 TRACE NAME ERRORSTACK LEVEL 3’;

解決策は:
1. OBJDとDBAで具体的なテーブル名とブロック番号を探し出す

  1. できればそのテーブルをanalyze .. validate structureしてください
    3. できればそのテーブルを含むtablespaceに対して dbms_space_admin.ASSM_TABLESPACE_VERIFYしてください
    4. できればそのテーブルあるいは関するパーティションを移して、このトラブルを避けてみてください
    5. できればそのテーブルあるいはパーティションをMSSMテーブルスペースに移して、このトラブルを避けられる

execute dbms_space_admin.tablespace_verify(‘&tablespace_name’)
oradebug setmypid
oradebug tracefile_name

 

execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS)
oradebug setmypid
oradebug tracefile_name

 

[oracle@nas ~]$ oerr ora 8103

08103, 00000, “object no longer exists”

// *Cause: The object has been deleted by another user since the operation

// began, or a prior incomplete recovery restored the database to

// a point in time during the deletion of the object.

// *Action: Delete the object if this is the result of an incomplete

// recovery.

 

@ Using the call stack trace arguments to identify the block producing the ORA-8103.

 

@ struct kcbds

@ {

@ ktid kcbdstid; /* full relative DBA plus object number */

@ …..@ struct ktid /* relative dba + objd */

@ {

@ kdbafr dbr_ktid; /* a relative dba */

@ kobjd objd_ktid; /* data object number */

@ kobjn objn_ktid; /* dictionary object number */@ struct kdbafr /* full relative dba */

@ {

@ ktsn tsn_kdbafr; 4bytes /* a tablespace number */

@ krdba dba_kdbafr; 4bytes /* a relative dba */

@ };

 

@ alter session set db_file_multiblock_read_count=1;

@ alter session set events ‘8103 trace name errorstack level 3’;

 

@ kcbgtcr(kcbds *ds,…

 

@ ktecgshx(sdes, …)

@ kcbds *sdes;

 

@ ktecgetsh(cdes, …)

@ kcbds *cdes;

 

@ Example from a trace file with function ktecgshx being called by kteinicnt1:

 

@ kteinicnt1()+796 CALL ktecgshx() FFFFFFFF7FFF8F78 ?

@ 000000003 ? 000000004 ?

@ 0000001BC ? 000000000 ?

@ 1007AA000 ?

 

@ Argument/Register addr=0xFFFFFFFF7FFF8F78.

@ Dump of memory from 0xFFFFFFFF7FFF8F38 to 0xFFFFFFFF7FFF9078

@ FFFFFFFF7FFF8F30 00000000 00000000 [……..]

@ FFFFFFFF7FFF8F40 00000000 00000000 FFFFFFFF 00000001 […………….]

@ FFFFFFFF7FFF8F50 00000000 00000000 00000000 00000000 […………….]

@ Repeat 1 times

@ FFFFFFFF7FFF8F70 00000000 00000000 0000000C 01006402 […………..d.]

After increase in load, queries against ASSM table intermittently fail with ORA-8103 when executed in

parallel if there are concurrent updates performed on the table.

 

This appears to only manifest when access is in parallel.

 

Cause

 

This is caused by Bug 5637976 ORA-8103 EVEN WITH THE WORKAROUND FROM Bug 3569503 fixed in 11.1g.

 

Concurrent inserts and direct path exports on an ASSM table causes ORA-8103/ORA-1410.

This is due to the fact that newly formatted blocks between low and high water mark do not get flushed to disk and query sees old copies from disk.

 

Rediscovery Information:

  1. Concurrent inserts and exports on ASSM tables
  2. ORA-8103/ORA-1410
  3. redo dump shows ‘ktspbfredo – Format Pagetable Datablock’ for that rdba

 

REDO RECORD – Thread:2 RBA: 0x00045b.001887a1.0028 LEN: 0x008c VLD: 0x01

SCN: 0x0578.6eddf7be SUBSCN: 1 07/19/2012 12:11:00

CHANGE #1 TYP:1 CLS: 4 AFN:370 DBA:0x5ca5f32e OBJ:1638047 SCN:0x0578.6eddf7bd SEQ: 1 OP:13.17

ktsphfredo – Format Pagetable Segment Header

StartDBA 0x5ca5f32b nblks: 32 ForceL3 :1 Tsn: 15 objd: 1638047

 

REDO RECORD – Thread:2 RBA: 0x00045b.001887a5.0198 LEN: 0x008c VLD: 0x01

SCN: 0x0578.6eddf7c7 SUBSCN: 1 07/19/2012 12:11:00

CHANGE #1 TYP:1 CLS: 4 AFN:284 DBA:0x4718cbee OBJ:1638047 SCN:0x0578.6eddf7c2 SEQ: 1 OP:13.17

ktsphfredo – Format Pagetable Segment Header

 

BH (70000039ffb5108) file#: 370 rdba: 0x5ca5f32e (370/2487086) class: 7 ba: 70000039f230000

set: 94 blksize: 32768 bsi: 0 set-flg: 0 pwbcnt: 0

dbwrid: 5 obj: 1638047 objn: 148393 tsn: 15 afn: 370

hash: [700000fde5e6380,700000fde5e6380] lru: [7000005e7fcbdc0,700000b91fb4ce8]

lru-flags: hot_buffer

ckptq: [NULL] fileq: [NULL] objq: [700000f7c3f8288,70000063cfbac28]

st: SCURRENT md: NULL tch: 2 le: 70000069bff76a0

flags: remote_transfer

LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

buffer tsn: 15 rdba: 0x5ca5f32e (370/2487086)

scn: 0x0578.6eded558 seq: 0x01 flg: 0x00 tail: 0xd5582401

frmt: 0x02 chkval: 0x0000 type: 0x24=PAGETABLE EXTENT MAP BLOCK

Hex dump of block: st=0, typ_found=1

 

EMB Dump:

Map Header:: next 0x4718cbee #extents: 1112 obj#: 1638047 flag: 0x10000000

Inc # 0

Extent Map

—————————————————————–

0x5ca5f32b length: 32

0x5ceff1eb length: 32

0x5d15360b length: 32

0x5d5ddbcb length: 32

0x5d9d106b length: 32

0x5dc000ab length: 32

0x5e09e1ab length: 32

0x5e4a8c0b length: 32

0x5e80d24b length: 32

0x5ec9a10b length: 32

0x5f009feb length: 32

0x5f40b74b length: 32

0x5f895f2b length: 32

0x5fd254cb length: 32

 

BH (700000dbcfc0ea8) file#: 284 rdba: 0x4718cbee (284/1625070) class: 7 ba: 700000dbc750000

set: 67 blksize: 32768 bsi: 0 set-flg: 0 pwbcnt: 0

dbwrid: 2 obj: 1638047 objn: 148393 tsn: 15 afn: 284

hash: [700000fdc387588,700000fdc387588] lru: [7000002f1fbcf90,700000a77fcfc30]

lru-flags: hot_buffer

ckptq: [NULL] fileq: [NULL] objq: [700000fc67dd420,700000453fb1828]

st: SCURRENT md: NULL tch: 143 le: 700000665fd8200

flags: remote_transfer

LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

buffer tsn: 15 rdba: 0x4718cbee (284/1625070)

scn: 0x0578.6ee3867a seq: 0x01 flg: 0x00 tail: 0x867a2401

frmt: 0x02 chkval: 0x0000 type: 0x24=PAGETABLE EXTENT MAP BLOCK

Hex dump of block: st=0, typ_found=1

 

EMB Dump:

Map Header:: next 0x00000000 #extents: 1983 obj#: 1638047 flag: 0x10000000

Inc # 0

Extent Map

—————————————————————–

0x4718cbeb length: 32

0x475b598b length: 32

0x47989f6b length: 32

0x47d84f2b length: 32

 

ORA-8103 – objd: 1638108 objn: 1338416 tsn: 15 rdba: 0x4b8bf059

 

ksedmp: internal or fatal error

ORA-08103: object no longer exists

Current SQL statement for this session:

 

—– Call Stack Trace —–

calling              call     entry                argument values in hex

location             type     point                (? means dubious value)

——————– ——– ——————– —————————-

ksedst+001c          bl       ksedst1              000000001 ? 000000000 ?

ksedmp+0290          bl       ksedst               104C23090 ?

ksddoa+0308          bl       _ptrgl

ksdpcg+0104          bl       ksddoa               110490160 ? 11048ACB8 ?

ksdpec+00e8          bl       ksdpcg               FFFFFFFFFFEEF20 ?

700000010007FE0 ?

FFFFFFFFFFEEFF0 ?

ksfpec+00a4          bl       03F37234

kgesev+007c          bl       _ptrgl

ksesec0+0048         bl       kgesev               000007FE8 ? 104FD1FE0 ?

000000000 ? 000000000 ?

FFFFFFFFFFEF410 ?

kteinicnt1+0384      bl       01FC3F98

qertbFetch+0288      bl       03F386EC

qertqoFetch+0298     bl       01FC3FD8

qerpx_resume+0370    bl       01FC3FD8

qerpxFetch+0e08      bl       qerpx_resume         000000000 ? 11055A520 ?

rwsfcd+0054          bl       _ptrgl

insfch+00b4          bl       _ptrgl

insdrv+042c          bl       insfch               104C2BAE8 ? 000000000 ?

inscovexe+02d8       bl       insdrv               1104A81B0 ?

insExecStmtExecIniE  bl       _ptrgl

ngine+005c

insexe+0318          bl       insExecStmtExecIniE  000000000 ? 000000400 ?

ngine                11048A818 ?

opiexe+2840          bl       insexe               1104BF320 ? FFFFFFFFFFF1678 ?

opipls+1888          bl       opiexe               FFFFFFFFFFF29C8 ?

FFFFFFFFFFF2AB0 ?

FFFFFFFFFFF2968 ?

opiodr+0b2c          bl       _ptrgl

rpidrus+01dc         bl       opiodr               66FFFF47D0 ? 6FFFF4800 ?

FFFFFFFFFFF5900 ? A00000000 ?

skgmstack+00c8       bl       _ptrgl

rpidru+0088          bl       skgmstack            000000003 ? 000000003 ?

000000002 ? 000000000 ?

FFFFFFFFFFF50B0 ?

rpiswu2+0368         bl       _ptrgl

rpidrv+097c          bl       rpiswu2              70000100553C598 ? 000000000 ?

700000010003520 ? 110566428 ?

110566464 ? 96FFFF5B30 ?

1104C6010 ? 000000000 ?

 

Argument/Register addr=0x0FFFFFFFFFFEF410.

Dump of memory from 0x0FFFFFFFFFFEF3D0 to 0x0FFFFFFFFFFEF510

FFFFFFFFFFEF3D0 00000000 00000000 00000001 1048A818 [………….H..]

FFFFFFFFFFEF3E0 00000000 00002000 00000001 1019C060 […… ……..`]

FFFFFFFFFFEF3F0 0FFFFFFF FFFEF5E0 48220080 00000B9D [……..H”……]

FFFFFFFFFFEF400 00000000 00000000 00000000 00000000 […………….]

FFFFFFFFFFEF410 0000000F 4B8BF059 0018FEDC 00146C30 [….K..Y……l0]

FFFFFFFFFFEF420 00080003 00007FE8 00000000 100733A8 […………..3.]

 

00146C30=> 1338416=> ORA-8103 – objd: 1638108 objn: 1338416

 

kjbhistory[0xbf059.12e0000,(pkey 4294967295.0)(where 1)]

*** 2012-07-19 15:05:23.818

GLOBAL CACHE ELEMENT DUMP (address: 70000018cfe95a0):

id1: 0xbf059 id2: 0x12e0000 pkey: INVALID block: (302/782425)

lock: NC rls: 0x0000 acq: 0x0003 latch: 20

flags: 0xc1 fair: 0 recovery: 0 fpin: ‘ktewh25: kteinicnt’

bscn: 0x578.6ee51801 bctx: 0 write: 0 scan: 0x0 xflg: 0 xid: 0x0.0.0

lcp: 700000fd843f070 lnk: [700000fd843f090,700000fd843f090] lch: [700000bdbfbb338,700000bdbfbb338]

seq: 25664 hist: 7 352 477 329 144:6 384 7 352 477 329

LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:

flg: 0x00080000 state: READING mode: EXCL

pin: ‘ktewh25: kteinicnt’

addr: 700000bdbfbb228 obj: 1638108 cls: SEG HEAD bscn: 0x577.a4f2674f

 

Note= OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution (Doc ID 8103.1)

==>

Cause

ORA-8103 is caused by an invalid block type. The block header has an invalid block type or the

block type inside the block is not expected; e.g. a data block (Type=6) was expected but the

actual block information is not a data block (Type!=6).

 

ORA-8103 is also caused by an unexpected data_object_id where it is changing for the involved

objects while the affected SQL statement is executed.

 

$sqlplus / as sysdba

 

Note: please replace literal ‘<owner>’ with actual owner

 

——————–<

set lines 500

set long 9999

set pages 999

set serveroutput on size 1000000

set feedback off

SET MARKUP HTML ON SPOOL ON HEAD “<TITLE>SQL*Plus Report</title><STYLE TYPE=’TEXT/CSS’><!–BODY {background: ffffc6} –></STYLE>”

spool query_result.html

set echo off

alter session set nls_date_format = ‘yyyy/mm/dd hh24:mi:ss’;

SELECT * FROM DBA_TAB_MODIFICATIONS where table_owner = ‘<owner>’

and table_name in (‘RAW_BORM’,’MG_34_FEE_DTL’,’RAW_BOIS’,’MG_34_CA_AMT_BK’,’RAW_BLDVNI’);

spool off

SET MARKUP HTML OFF

set echo on

——————–>

 

  1. run the hcheck script against the database “using note hcheck.sql” script to check for

known problems in Oracle8i, Oracle9i, Oracle10g and Oracle 11g (Doc ID 136697.1) and provide the output to SR.

Please do not provide a print screen, but the spool file obtained

 

  1. set event for ORA 8103 to capture the errorstack

alter system set events=’8103 trace name errorstack, level 3′;

 

  1. wait for the error to reproduce and upload the trace file created for the error

 

【データリカバリ】ORA-8103エラを解析する

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

 

ORA-8103は我々Database Consultant がよく見られるトラブルである。

ORA-8103の 原因は主に二つがある:

  • データブロックのタイプが無効的なものあるいはブロックタイプがOracleが予想したものと違っている。例えばOracleがデータタイプをdata(type=6)と見なしているが実際にはそうじゃない。
  • データブロックのdata_object_id とデータディクショナリーのdata_object_idがマッチしていない。

 

ORA-8103トラブルに対して、以下の処置を勧めている:

ORA-08103トラブルの診断は8103エラのERROR STACK TRACEを作成して、TRACEで8103を引き起こしたOBJとOBJDを記録する。これはcorruptionがある相手を定義できる。

トラブルはフォアグラウンドプロセスがORA-08103エラになった場合に、バックグラウンドでTRACEファイルを作成しない。それで、人工的に8103を設定して、ERRORSTACKのEVENTSを引き起こす必要がある:

ALTER SYSTEM SET EVENTS ‘8103 TRACE NAME ERRORSTACK LEVEL 3’;

解決策は以下の通り:
1. OBJDとDBAで具体的テーブル名とブロック名を探し出す
2. できればそのテーブルをanalyze .. validate structureしてください
3. できればそのテーブルを含むtablespaceに対して dbms_space_admin.ASSM_TABLESPACE_VERIFYしてください
4. できればそのテーブルを関するパーティションに移して、トラブルを避けてみてください
5. できれば。そのテーブルあるいはパーティションをMSSMテーブルスペースに移してトラブルを避けてください

execute dbms_space_admin.tablespace_verify(‘&tablespace_name’)
oradebug setmypid
oradebug tracefile_name

execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS)
oradebug setmypid
oradebug tracefile_name

 

 

異なる analyze validate structureした結果に対して、初期的な結論を下せる:

 

flush buffer cacheを実行したあと再びanalyze validate structureするときにORA-8103エラが現れないとは:

これは正常の現象かもしれない。前に言ったORA-8103はオブジェクトがDROP/TRUNCATEされて、SELECTがORA-8103になった。一般的にCall Stackはプロセスがプロセスがそのセグメントヘッダをアクセスできる。より多くの情報はBUG 7441661に参考できる。

これもbuffer cacheだけに起こるかもしれない。flush buffer_cacheで解決できるなら、大体こういう場合に限っている。それにいつもBuffer Cacheが管理するBUGである 。

 

 

flush buffer cacheを実行したら、再びanalyze validate structureするときにORA-8103なったとは:

該当するデータブロックをダンプするときに、そのブロックがロジックに一致している。(bed/dbvツールで検証できる)。Lost Writeの可能性もあって、ほかのオブジェクトに再びフォーマットされない。

ここでLost Writeを判断する大事な手段とはブロックにrecover/blockrecoverする。もしリカバリできるなら、ORA-8103エラがLost Writeで引き起こした。そうでなければ99%はBUGによるものである。

よくある状況はほかのツールでデータベースを起動したままにデータベースをコピしてたが、ツールのBUGによって、古いバーションのblockを新たなデータベースにコピするかもしれない。

 

もう一つの可能は extentレベルが一致していない。同じデータブロックが同時に二つのデータセグメントに属していて、あとのセグメントに上書きされるかもしれない。このようなロジックエラがテーブルスペースレベルのエクステント情報に起こるから、リカバリするだけで修復できない。dba_extents/dba_segments/dba_free_spaceなどのインメージを検証することによって、これらのブロックが複数のオブジェクトに属しているかを確認できる。あるいはあるデータブロックが同時にdba_extents/dba_segments/dba_free_space 三つのインメージに現れたが、 used extentがdba_free_spaceに現れるはずがないから。それにfree extentもdba_extentsに現れるわけがない。Recyclebinのオブジェクトの影響を除いて、大多数の場合に、こういうロジックが一致していない状況はextent overlap と呼ばれている。これは一般的にOracle Space Managementスペース管理のBUG。

 

ORA-8103エラに対する診断プロセスで、トラブルのOBJDを探し出すことはとっても大切である。けど、ORA-8103エラとBUGとつながるとはとっても難しい。

これはredo dumpに関わっている。一部のBUGで、変数が古いから、作成したobjd構造が削除されていない。そしてブロックのobjdが間違えたと気づいた。それはORA-8103あるいはORA-1410かもしれない。これは後のロジックエラを引き起こしたからTRACE/REDO LOG DUMPで原始なトラブルの場合を見つかりにくくなった。これもロジックエラの分析と処置は物理的なエラより難しいと言った理由である。

 

Macleanの経験は大量なOracle DBを持っている環境で、一年に何度ロジック/物理ベッドブロックが現れるのはごく普通なことである。物理的な場合に対して、バックアップすればいい。ロジックベッドブロックの場合にやることがあんまりない。

 

ORA-8103のBug Noteを読んで、 LOB、APPEND INSERT、PARALLEL INSERT、exchange partition 、Split partition、advanced compression、HCC 混ぜた列凍結をするのはORA-8103になるかもしれない。けど実際には以上の操作を諦めるわけにはいかない。

 

今までORA-8103に関するBUGリスト:

 

NB Bug Fixed Description
13910420 11.2.0.3.BP09, 12.1.0.0 ORA-8103 during insert / update of basicfile LOB in assm segment using space search cache
13725395 11.2.0.3.BP07, 11.2.0.4, 12.1.0.0 ORA-600 [kdzhFindHeadPiece: unnewed > 1] from load into HCC table
13700577 11.2.0.3.BP07, 11.2.0.4, 12.1.0.0 PQ slave dies with ORA-600 [kdblddr_2]
12747437 12.1.0.0 ORA-600 [ktspfmdb:objdchk_kcbnew_3] after purging single consumer queue table
12582839 11.2.0.3, 12.1.0.0 ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace
12321309 12.1.0.0 ORA-600 / ORA-8103 UNUSABLE state of partitioned index is not carried across by TABLESPACE transport using DataPump
11937253 11.2.0.2.6, 11.2.0.2.BP11, 11.2.0.3, 12.1.0.0 A Parallel query fails with ORA-8103 on an Active Dataguard Enviroment.
11850492 11.2.0.3, 12.1.0.0 ORA-8103 ORA-600 ORA-3113 on temporary tables using INDEX FAST FULL SCAN and DIRECT read
10385812 11.2.0.3, 12.1.0.0 ORA-1410 or ORA-8103 by queries with DIRECT READ while concurrent DIRECT INSERT
10329146 11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.0 Lost write in ASM with multiple DBWs and a disk is offlined and then onlined
+ 10209232 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.0 ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
10136415 11.2.0.3, 12.1.0.0 ORA-8103 on Partitioned IOT after partition maintenance
9965085 11.2.0.3, 12.1.0.0 ORA-1578 / ORA-8103 Temporary table block corruption / space wastage from PDML
9659614 10.2.0.5.3, 11.2.0.2, 11.2.0.3.5, 11.2.0.3.BP05, 12.1.0.0 Large trace file for ORA-8103
9651350 11.2.0.2.2, 11.2.0.2.BP05, 11.2.0.3, 12.1.0.0 Large redo dump and ORA-308 might be raised due to ORA-8103
9275027 11.2.0.2, 12.1.0.0 ORA-600 [kcbnew_3] can occur after TRUNCATE / DROP
9272086 11.1.0.7.4, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0 ORA-8103 by a query on DBA_EXTENTS. Trace file with Block type: 0x44=NGLOB: Extent Map
8754670 11.2.0.2, 12.1.0.0 IMP-17 / ORA-8103 transporting a large dictionary managed tablespace
8740993 11.1.0.7.8, 11.2.0.2, 12.1.0.0 ORA-1410 / ORA-8103 on ADG STANDBY during table scan after DROP/TRUNCATE/SHRINK in PRIMARY
8725282 11.2.0.1.BP08, 11.2.0.2, 12.1.0.0 Corruption from cross platform transport of tablespace with securefile objects
8716064 11.2.0.2, 12.1.0.0 Analyze Table Validate Structure fails on ADG standby with several errors
+ 8597106 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0 Lost Write in ASM when normal redundancy is used
8428523 11.2.0.2, 12.1.0.0 Alter Table Rename causes wrong results/ora-8103/hangs on ADG Standby.
7710827 11.2.0.2, 12.1.0.0 Index rebuild or Merge partition causes wrong results in concurrent reads instead of ORA-8103
7519406 10.2.0.5.1, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0 Larger trace than needed for ORA-8103 under kteinicnt1
P 12330911 12.1 EXADATA LSI firmware for lost writes
8876094 11.1.0.7.2, 11.2.0.2 ORA-8103 by DBA_UNDO_EXTENTS or DBMS_SPACE_ADMIN.TABLESPACE_VERIFY on Block type: 0x25
9167831 11.2.0.2 ORA-8103 instead of ORA-1410
7650993 11.1.0.7.1, 11.2.0.1 ORA-8103 in a select at ADG standby database from table stored in ASSM tablespace
7432556 11.1.0.7.1, 11.2.0.1 ORA-8103 by Parallel Query on Partitioned Tables in BIGFILE Tablespaces
7390324 11.2.0.1 ANALYZE signals OERI [kcbgtcr_12]/ORA-8103 on bitmap index
7117200 11.2.0.1 ORA-8103 after TSPITR/PLUGIN tablespace from a restored Level 1 Backup
8825048 11.1.0.7.3 ORA-308/ORA-27037 when dumping archived log for ORA-8103. Dump when event 10736 level 4 is set
6337376 11.1.0.7 OERI:kcbgcur_3 / ORA-8103 after truncating a partition table with LOBs
9711472 11.1.0.6 ORA-8103 on operations for a partitioned LOB if any different partition is dropped
5637976 10.2.0.4, 11.1.0.6 ORA-8103/ORA-1410 from concurrent INSERT / export on ASSM tables
5083393 10.2.0.4, 11.1.0.6 DBA_FREE_SPACE FILE_ID / REL_FNO may be wrong
4592596 10.2.0.4, 11.1.0.6 Corruption (ORA-1410 / ORA-8103) from multi-table insert with direct load
6864586 10.2.0.5 ORA-8103 on partitioned table with a LOB column during analyze table with concurrent add/drop partition.
3569503 9.2.0.6, 10.2.0.4 PQ may signal a false ORA-8103 under load
13618170 ORA-8103 for create index online when the fix of bug 10027403 is installed
3966709 9.2.0.7, 10.1.0.4, 10.2.0.1 Range/object reuse prematurely (ORA-8103)
3868753 9.2.0.7, 10.1.0.5, 10.2.0.1 Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103
+ 5523799 Various OERI (eg kcbgtcr_12) using ASSM managed segments – superceded
P* 6047085 Linux x64-64: SGA corruption / crash following any ORA-7445
* 3785200 9.2.0.6, 10.1.0.2 Corruption possible in automatic space managed segments
3083560 9.2.0.5, 10.1.0.2 ORA-1410 / ORA-8103 from direct path export if concurrent DML occurs
2619867 9.2.0.3, 10.1.0.2 OERI:[KCBGTCR_12] / ORA-8103 / ORA-1410 SELECTing from bitmap managed segment
2551000 9.2.0.4, 10.1.0.2 False ORA-1410 / ORA-8103 possible from ANALYZE COMPUTE/ESTIMATE STATISTICS
2333731 9.2.0.2 ORA-8103 possible in PQ slave
2105419 9.0.1.3, 9.2.0.1 ORA-8103 possible from PQ on bitmap managed segments with concurrent inserts
1998455 8.1.7.3, 9.0.1.3, 9.2.0.1 OERI:KCBGTCR_4 possible from long running DDL if referenced object dropped/truncated
1804299 9.0.1.1, 9.2.0.1 Rollback of Direct load can corrupt BITMAP managed segments / ORA-8103
1698789 9.2.0.1 Wrong results, ORA-1410, ORA-8103, OERI:25012 on SELECT of UNSCOPED REF with ROWID
1504967 9.2.0.1 ORA-8103 possible on READ ONLY standby after TRUNCATE on primary
1400739 8.1.7.1, 9.0.1.0 Block corruption/OERI:2023 /ORA-8103 can occur if TRUNCATE is interrupted (Ctrl-C)
1283521 8.1.7.0 ORA-8103 can occur on TRUNCATED cluster table
589855 7.3.3.6, 7.3.4.1 ORA:1578 or ORA:8103 selecting invalid ROWID
P 1053863 8.0.5.2, 8.0.6.2 NCR: ORA-8103 / corrupt read possible using async IO

 

 

【データリカバリ】ROWIDを構造することで、バックアップなしにORA-1578、ORA-8103、ORA-1410などロジック/物理的なベッドブロックトラブルを避ける

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

 

バックアップなしにORA-1578、ORA-8103、ORA-1410エラになると、以下のようなPL/SQLでROWIDを構造することで大部分の非ベッドブロックデータを救える。一般的に二つの状況に分けられる:インディクスががある場合とインディクスを使えなくて、dbms_rowid.ROWID_CREATEでROWIDを構造する必要がある場合である。

 

インディクスがある場合に対して、MOSのスクリプトをそのままに運用できる:

 

 

REM Create a new table based on the table that is producing errors with no rows:

create table 
as
select *
from   
where  1=2;

REM Create the table to keep track of ROWIDs pointing to affected rows:

create table bad_rows (row_id rowid
                      ,oracle_error_code number);
set serveroutput on

DECLARE
  TYPE RowIDTab IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
  CURSOR c1 IS select /*+ index(tab1) */ rowid
  from  tab1
  where  is NOT NULL;
  r RowIDTab;
  rows NATURAL := 20000;
  bad_rows number := 0 ;
  errors number;
  error_code number;
  myrowid rowid;
BEGIN
  OPEN c1;
  LOOP
   FETCH c1 BULK COLLECT INTO r LIMIT rows;
   EXIT WHEN r.count=0;
   BEGIN
    FORALL i IN r.FIRST..r.LAST SAVE EXCEPTIONS
     insert into 
     select /*+ ROWID(A) */ 
     from  A where rowid = r(i);
   EXCEPTION
   when OTHERS then
    BEGIN
     errors := SQL%BULK_EXCEPTIONS.COUNT;
     FOR err1 IN 1..errors LOOP
      error_code := SQL%BULK_EXCEPTIONS(err1).ERROR_CODE;
      if error_code in (1410, 8103, 1578) then
       myrowid := r(SQL%BULK_EXCEPTIONS(err1).ERROR_INDEX);
       bad_rows := bad_rows + 1;
       insert into bad_rows values(myrowid, error_code);
      else
       raise;
      end if;
     END LOOP;
    END;
   END;
   commit;
  END LOOP;
  commit;
  CLOSE c1;
  dbms_output.put_line('Total Bad Rows: '||bad_rows);
END;
/
 
 
 
インディクスがないあるいはインディクスがこわれた場合に以下の方法を使ってください:
 
 
インスタンスデータを作成する

create table maclean_tab1 (t1 int,t2 date default sysdate) tablespace users
partition by range(t1) 
(partition p1 values less than (10000),
partition p2 values less than (20000),
partition p3 values less than (30000),
partition p4 values less than (40000),
partition p5 values less than (50000),
partition p6 values less than (60000),
partition p7 values less than (70000),
partition p8 values less than (80000),
partition p9 values less than (90000),
partition p10 values less than (100000),
partition p11 values less than (110000),
partition p12 values less than (120000),
partition p13 values less than (130000),
partition p14 values less than (140000),
partition p15 values less than (150000),
partition p16 values less than (160000))
;

insert into maclean_tab1(t1) select rownum from dual connect by level<160000; commit; SQL> select count(*) from maclean_tab1;

  COUNT(*)
----------
    159999

exec dbms_stats.gather_table_stats(USER,'MACLEAN_TAB1');   

SQL> alter system flush buffer_cache;

System altered.

SQL> /

System altered.

そして一部のブロックをサンプリングして、こわれたブロックは10個のブロックに関している

set linesize 200 pagesize 1400

select dbms_rowid.rowid_block_number(rowid) blkid,
       dbms_rowid.rowid_relative_fno(rowid) rfile
  from maclean_tab1 sample(0.01)
 where rownum <= 200 group by dbms_rowid.rowid_block_number(rowid), dbms_rowid.rowid_relative_fno(rowid) order by 1; BLKID RFILE ---------- ---------- 741833 4 741850 4 741994 4 742030 4 742085 4 742141 4 742159 4 742172 4 742173 4 742179 4 ベッドブロックを作成する [oracle@vrh8 udump]$ rman target / RMAN> blockrecover datafile 4 block 741833,741850,741994,742030,742085,742141,742159,742172,742173,742179 clear;

Starting blockrecover at 21-APR-13
using channel ORA_DISK_1
Finished blockrecover at 21-APR-13

SQL> select count(*) from maclean_tab1;
select count(*) from maclean_tab1
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 741833)
ORA-01110: data file 4:
'/s01/oradata/G10R25/datafile/o1_mf_users_8nx5srgb_.dbf'

blockrecover datafile block clearで一連のベッドブロックを構造した、それにバックアップもない。以下のスクリプトで大多数のデータを救える。

実際の操作



drop table maclean_tab_backup;

create table maclean_tab_backup 
tablespace users 
nologging compress pctfree 0 pctused 99        --可以注释掉的
 as select * from maclean_tab1 where 1=0;

drop table bad_rows;
create table bad_rows (row_id rowid,oracle_error_code varchar2(50))
tablespace users 
nologging compress pctfree 0 pctused 99        --可以注释掉的;

set serveroutput on;
set timing on;

DECLARE
  TYPE RowIDTab IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
  CURSOR Crowid_info IS
    select Do.DATA_OBJECT_ID dataid,
           DE.FILE_ID        fid,
           DE.BLOCK_ID       blkid,
           DE.BLOCKS         blkcnt
      from dba_objects DO, dba_extents DE
     where DO.OBJECT_NAME = 'MACLEAN_TAB1' 
     --and DE.PARTITION_NAME='&PARTITION_NAME'          --パーティションを指定したら、ノートをキャンセルする
       and nvl(DO.SUBOBJECT_NAME,'-1') = nvl(DE.PARTITION_NAME,'-1')
       and DO.OBJECT_NAME = DE.SEGMENT_NAME
       and DO.owner = 'SYS'
     order by 1, 2, 3 asc;
  bad_rows   number := 0;
  errors     varchar2(500);
  error_code varchar2(500);
  myrowid    rowid;
BEGIN
  /* Maclean Liu https://www.askmac.cn * Copy Right 2013-4-20 */ 
  execute immediate 'alter session set commit_write=''batch,nowait'' ';
  for i in Crowid_info loop
    for j in 0 .. i.blkcnt - 1 loop
      for z in 0 .. 2000 loop
        begin
          myrowid := dbms_rowid.ROWID_CREATE(1,
                                             i.dataid,
                                             i.fid,
                                             i.blkid + j,
                                             z);
          insert into maclean_tab_backup
            select /*+ ROWID(A) */
             *
              from maclean_tab1 A
             where rowid = myrowid;
        EXCEPTION
          when OTHERS then
            BEGIN
              errors     := SQLERRM;
              error_code := SQLCODE;
              if (error_code like '%1410%' or error_code like '%8103%' or  error_code like '%1578%') then
                bad_rows := bad_rows + 1;
                insert into bad_rows values (myrowid, error_code);
                commit;
              else
                raise;
              end if;
            END;
            commit;
        end;
      end loop;
    end loop;
  end loop;
  dbms_output.put_line('Total Bad Rows: ' || bad_rows);
  commit;
END;
/

Elapsed: 00:01:10.16

SQL> select count(*) from maclean_tab_backup;

  COUNT(*)
----------
    155921

 ===>10個のブロックのデータをなくした
 
 
原始スクリプトは以下の通り:
ステップ1 バックアップテーブルを作成する

create table 
as
select *
from   
where  1=2;

ステップ2 bad_rowsテーブルを作成する

create table bad_rows (row_id rowid,oracle_error_code varchar2(50));
ステップ3  以下のスクリプトを運用する

DECLARE
  TYPE RowIDTab IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
  CURSOR Crowid_info IS
    select Do.DATA_OBJECT_ID dataid,
           DE.FILE_ID        fid,
           DE.BLOCK_ID       blkid,
           DE.BLOCKS         blkcnt
      from dba_objects DO, dba_extents DE
     where DO.OBJECT_NAME = '&TABNAME' 
     --and DE.PARTITION_NAME='&PARTITION_NAME'           
       and nvl(DO.SUBOBJECT_NAME,'-1') = nvl(DE.PARTITION_NAME,'-1')
       and DO.OBJECT_NAME = DE.SEGMENT_NAME
       and DO.owner = '&OWNER'
     order by 1, 2, 3 asc;
  bad_rows   number := 0;
  errors     varchar2(500);
  error_code varchar2(500);
  myrowid    rowid;
BEGIN
  /* Maclean Liu https://www.askmac.cn * Copy Right 2013-4-20 */ 
  execute immediate 'alter session set commit_write=''batch,nowait'' ';
  for i in Crowid_info loop
    for j in 0 .. i.blkcnt - 1 loop
      for z in 0 .. 2000 loop
        begin
          myrowid := dbms_rowid.ROWID_CREATE(1,
                                             i.dataid,
                                             i.fid,
                                             i.blkid + j,
                                             z);
          insert into &backup_table
            select /*+ ROWID(A) */
             *
              from &source_table A
             where rowid = myrowid;
        EXCEPTION
          when OTHERS then
            BEGIN
              errors     := SQLERRM;
              error_code := SQLCODE;
              if (error_code like '%1410%' or error_code like '%8103%' or  error_code like '%1578%') then
                bad_rows := bad_rows + 1;
                insert into bad_rows values (myrowid, error_code);
                commit;
              else
                raise;
              end if;
            END;
            commit;
        end;
      end loop;
    end loop;
  end loop;
  dbms_output.put_line('Total Bad Rows: ' || bad_rows);
  commit;
END;
/


【Oracleデータリカバリ】ORA-08102エラを診断する

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

 

 

 

[oracle@mlab2 ~]$ oerr ora 81020

 

8102, 00000, “index key not found, obj# %s, file %s, block %s (%s)”//

*Cause:  Internal error: possible inconsistency in index//

*Action:  Send trace file to your customer support representative,

along//           with information on reproducing the error

 

ORA-8102エラが現れた原因はテーブルあるいはLOB SEGMENTでキー値が存在しているが、インディクスから見つからないとエラになる。

TRACEの部分は大体以下の通り:

 

 

oer 8102.<code> – obj# <object id>, rdba: <rdba value>(afn <file#>, blk# <block#>)kdk key 8102.2:ncol: <number of columns in the key including the rowid>, len: <key length>key: (<length>):<hexadecimal value>

 

 

その中 obj#は影響を受けたobject_idで、 rdbaがデータデータブロックアドレスで、AFNは絶対ファイル番号で、blk#はそのkeyが置くべきインディクスのブロック番号である。

例えば:

 

SQL> DELETE dept WHERE deptno=10;DELETE dept WHERE deptno=10*ERROR at line 1:ORA-08102: index key not found, obj# 46115, file 5, block 90 (2) Traceファイルで以下の内容が現れる:oer 8102.2 – obj# 46115, rdba: 0x02c0005a(afn 5, blk# 90)kdk key 8102.2:ncol: 3, len: 16key: (16):06 c5 02 01 01 27 02 04 c3 02 32 33 06 02 c0 00 4a 00 05

 

まずは影響を受けたインディクスを探し出す

エラ情報とtraceで影響を受けたインディクスのobj#を指定する:

 

SELECT *FROM   dba_objectsWHERE  object_id = 46115;

 

ANALYZE TABLEを使って

VALIDATE STRUCTURE CASCADE;コマンドで検証して、テーブルとインディクスが一致していないであればORA-1499エラになる:

ANALYZE TABLE

VALIDATE STRUCTURE CASCADE;

全テーブルスキャンとインディクススキャンの結果も比べられる:

 

SELECT /*+ FULL(t1) */ <indexed column list>FROM <Table name> t1MINUSSELECT /*+ index(t <Index name>) */ <indexed column list>FROM <Table name> t;

 

 

例えばテーブルの名前は DEPT, Index Name 为I_DEPT1, インディクスI_DEPT1 はDEPTNO, DNAME.

SELECT /*+ FULL(t1) */ deptno, dnameFROM dept t1MINUSSELECT /*+ index(t I_DEPT1) */ deptno, dnameFROM dept t;

 

そのクエリの実行計画は損害したインディクスを使ったことを確保する必要がある。実行計画にI_DEPT1があるかどうかという方法で確認できる。

 

ORA-8102はORACLEのbugあるいはハードウェアI/Oエラで引き起こした。

ハードウェアあるいはI/Oサブシステムが書き込みをなくしたので、ブロックロジックエラになる。Lost Ioが起きて、keyに対する修正あるいはOracleのデータファイルに書き込まれていない。

 

 ORA-8102の解決策

 

もしテーブルとインディクスが一致していないからORA-8102エラを引き起こしたことを確認できたら、dropとインディクス再構造で大体解決できる。

 

けど損害がテーブルに起きたら、解決策はテーブルの損害ブロックを独立で修正するあるいはテーブルを再構造する。

エラが起こったのはLOB Indexの場合、LOBを移動してLOB INDEXを再構造する。

 

alter table &table_owner.&table_with_lobmove LOB (&&lob_column) store as (tablespace &tablespace_name);

 

NB Bug Fixed Description
14222244 11.2.0.4, 12.1.0.1 Adding a column with DEFAULT and NOT NULL constraint disabled causes problems – superseded
13073122 11.2.0.4, 12.1.0.1 ORA-8102 signaled by q000* processes operating on queues with retention
+ 17761775 11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.BP03, 12.1.0.2 ORA-600 [kclchkblkdma_3] ORA-600 [3020] or ORA-600 [kcbchg1_16] Join of temp and permanent table in RAC might lead to corruption
17449815 12.1.0.2, 12.2.0.0 ORA-8102 ORA-1499 after ORA-1/ORA-2291 by MERGE with DML ERROR LOGGING
16844448 11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4, 12.1.0.2 ORA-600 [3020] after flashback database in a RAC
13708951 11.2.0.4, 12.1.0.1 ORA-8102 on UPDATE statement with subquery for an indexed column
13146182 11.2.0.2.11, 11.2.0.2.BP17, 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1 ORA-1499 ORA-8102 ORA-600 [kdsgrp1] Bitmap Index / Table mismatch
P 12330911 12.1.0.1 EXADATA LSI firmware for lost writes
11778458 11.2.0.3, 12.1.0.1 Wrong Results / ORA-1802 on TO_CHAR with CURSOR_SHARING
10633840 11.2.0.2.7, 11.2.0.2.BP17, 11.2.0.3, 12.1.0.1 ORA-1502 on insert statement on INTERVAL partitioned table. ORA-8102 / ORA-1499 Index inconsistency
10245259 11.2.0.2.BP03, 11.2.0.3, 12.1.0.1 PARALLEL INSERT with +NOAPPEND hint or if PARALLEL INSERT plan is executed in SERIAL corrupts index and causes wrong results
+ 10209232 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1 ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
+ 9734539 11.2.0.2, 12.1.0.1 ORA-8102 / ORA-1499 corrupt index after update/merge using QUERY REWRITE
+ 9469117 10.2.0.5.4, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze
+ 9231605 11.1.0.7.4, 11.2.0.1.3, 11.2.0.1.BP02, 11.2.0.2, 12.1.0.1 Block corruption with missing row on a compressed table after DELETE
+ 8951812 11.2.0.2, 12.1.0.1 Corrupt index by rebuild online. Possible OERI [kddummy_blkchk] by SMON
8847637 11.2.0.3, 12.1.0.1 ORA-7445[kxibPut] caused by merge stmt and online index rebuild
8720802 10.2.0.5, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1 Add check for row piece pointing to itself (db_block_checking,dbv,rman,analyze)
+ 8546356 10.2.0.5.1, 11.2.0.1.3, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1 ORA-8102/ORA-1499/OERI[kdsgrp1] Composite Partitioned Index corruption after rebuild ONLINE in RAC
7710827 11.2.0.2, 12.1.0.1 Index rebuild or Merge partition causes wrong results in concurrent reads instead of ORA-8103
7705591 10.2.0.5, 11.2.0.1.1, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 Corruption with self-referenced row in MSSM tablespace. Wrong Results / OERI[6749] / ORA-8102
+ 17752121 11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.BP03 ORA-600 [kclchkblkdma_3] ORA-600 [3020] RAC diagnostic/fix to avoid a block being modified in Shared Mode and prevent corruption
16922996 11.2.0.4 ORA-8102 ORA-1499 Internal rollback in Parallel DML may cause index inconsistency
8588540 11.1.0.7.2, 11.2.0.1 Corruption / ORA-8102 in RAC with loopback DB links between instances
8514561 11.2.0.1 ORA-8102 updating a table with function based index and TYPE columns and a TRIGGER
+ 7329252 10.2.0.4.4, 10.2.0.5, 11.1.0.7.5, 11.2.0.1 ORA-8102/ORA-1499/OERI[kdsgrp1] Index corruption after rebuild index ONLINE
6057203 10.2.0.4, 11.1.0.7, 11.2.0.1 Corruption with zero length column (ZLC) / OERI [kcbchg1_6] from Parallel update
5621677 10.2.0.4, 11.1.0.6 Logical corruption with PARALLEL update
5181547 10.2.0.4, 11.1.0.6 Index corruption after insert-only merge /*+ append */ or PDML into table
5179313 10.2.0.4, 11.1.0.6 INSERT /*append parallel*/ can corrupt an index
4883635 10.2.0.4, 11.1.0.6 MERGE (with DELETE) can produce wrong results or Logical corruption in chained rows
* 4570793 10.2.0.2 Index corruption from array inserts (ORA-8102/ORA-1499)
4246090 9.2.0.8, 10.1.0.5, 10.2.0.1 IOT corruption from buffered INSERT with function based index (ORA-8102)
3573604 10.1.0.4, 10.2.0.1 A transported bitmap index can give various OERI errors / ORA-8102
3365045 9.2.0.6, 10.1.0.3, 10.2.0.1 Functional index on DATE column can depend on NLS_DATE_FORMAT (ORA-8102 on DML)
3352413 9.2.0.6, 10.1.0.3, 10.2.0.1 An ORA-8102 error can occur on ATEMPIND$ during a user UPDATE with CONSTRAINTS
3069818 10.1.0.4, 10.2.0.1, 9.2.0.6 Corruption possible modifying a migrated or chained row
2485931 9.2.0.2, 10.1.0.2 ORA-8102 from IOT DML with concurrent MOVE ONLINE
2293492 9.0.1.4, 9.2.0.2, 10.1.0.2 Fatal error during COMMIT / ROLLBACK may cause permanent corruption (eg: ORA-8102)
2511906 9.2.0.2 ORA-8102 possible on update of IOT
2405013 9.2.0.2 ORA-8102 on ALTER TABLE MOVE PARTITION COMPRESS UPDATE GLOBAL INDEXES
2271722 9.0.1.4, 9.2.0.1 ORA-8102 possible on update of IOT with OVERFLOW
2165461 9.2.0.1 Direct load to table with DESCENDING index may cause subsequent ORA-8102 errors
2131767 9.2.0.1 Parallel create of FUNCTIONAL INDEX on PARTITION table can product corrupt index (ORA-8102)
2456255 9.0.1.0 ORA-8102 on DELETE from PARTITIONED table with index
1667103 8.1.7.2, 9.0.1.0 Update of an IOT with CONCATENATION using a SECONDARY index signals ORA-8102
1388843 8.1.7.3, 9.0.1.0 UNIQUE/PK constraints ENFORCED with NON-UNIQUE COMPRESSED indexes allow duplicates / ORA-8102
536567 7.3.4.4, 8.0.4.3, 8.0.5.1, 8.0.6.0 Corrupt index from PARALLEL Index build/rebuild of CONCAT index if FFS used and leading columns are NULL.

 

【Oracleデータリカバリ】データブロック損害/ベッドブロック診断

プロの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 で誤ったデータを探し出す

 

このようなトラブルに対して、以下のような方法を使ってください:

1、データベースが起動したままであれば、そのブロック損害/ベッドブロックが存在しているデータファイル番号、ブロック番号を判断する必要がある。そして具体的なオブジェクトの位置を探し出す(テーブルあるいはインディクス)。ORA-1578エラあるいはORA-600の変数情報を参考して、以下のようなSQLを使ってください。

 

SELECT tablespace_name, segment_type, owner, segment_nameFROM dba_extentsWHERE file_id = &fileidand &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あるいはredoログをダンプすることを分析するときに、ユーザーの予想を調整してください:

  • 私たちはリカバリすることではなく、原因を判断することを優先している。
  • すべての証拠があって、決定的な結論を下せない。

 

 

2、時々、メモリーでデータブロックがこわれた、例えばORA-600[3398]、このような状況を検証するために:

  • analyze table X validate structure cascade;
  • alter system flush buffer_cache;
  • OS視角でそのデータブロックをダンプして分析できる

 

後始末処置

 

1、本質を探す、例えば:

  • すべての損害がある設備あるいはコントロールに現れる。
  • 四つのブロックごとに一つのベッドブロックが現れる
  • データブロック自身問題内容が、現れる位置が間違えた
  • データブロックの一部が健康であった、ほかのところに違っている

 

2、 損害/ベッドブロックを避けてテーブルを再構造する:

10231 level 10トランザクションで全テーブルスキャンのCTASを実行する

ROWIDを構造することで、ベッドブロックにアクセスすることを避ける。

 

3、10210、10211及び10212で、そしてデータブロックをアップグレードしてください。10231 eventも考えてください

 

ほかのツール

 

他にもdul、oranum、orapatch、bbedなど、Oracle内部的なツールも使用可能である

 

【Oracleデータリカバリ】ORA-01115、ORA-01110、ORA-27091、ORA-27070、OSD-04006、O/S-Error

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

 

あるユーザーがwindows 2003のデータベースはストレージトラブルで、システムテーブルスペースにsystem.dbfがIOトラブルが現れた。データベースを起動するときに、エラになる:

 

 

ORA-01115: IO error reading block from file 15 ORA-01110: data file … ORA-27091: unable to queue I/O ORA-27070: async read/write failed OSD-04006: ReadFile() failure, unable to read from file O/S-Error: (OS 121) The semaphore timeout period has expired.

以上ORA-01115、ORA-01110、ORA-27091、ORA-27070、OSD-04006、O/S-Error などのエラが根本的にはOracleデータベースと関係ない。トラブルの本質はWindowsで該当するディスクドライブのファイルが読み取れない。これもOS bug あるいは該当するディスクに物理的なトラブルが現れた。このトラブルに対してOSの視角で解決策を求めてください。うまくいかない場合に、特別な解決策を考えてください。 ‘

 

Error: OSD 4006
Text: ReadFile() failure, unable to read from file
—————————————————————————
Cause: Unexpected return from Windows NT system service ReadFile()
Action: Check OS error code and consult Windows NT documentation

This is due to a problem in Windows such that when Oracle attempted to access the data file on that device, it could not because the device timed out. This suggests that Windows has run out of asynchronous I/O buffers or there is a communications delay on the device.

There is nothing you’re going to be able to do at the database level to resolve this error, unless you move the data files to another drive. Ask the O/S system administrator to run diagnostics tools to check for possible faulty hardware and disk corruption on the disk device where the error is showing in the loader log. If the error persists, then log a call with Microsoft Support.

Oracle processes may encounter various (OS 1117) errors on a Windows 2003 Server. The text of the (OS 1117) error can be seen as follows:

C:\>net helpmsg 1117
The request could not be performed because of an I/O device error.
This error may manifest itself in different ways, depending on which Oracle process encounters the error:

Oracle RDBMS Instance Encounters (OS 1117) error

  1. If an Oracle RDBMS instance encounters the error, you may see messages such as the following in the alert log for the RDBMS instance:

==========================================================================

Fri Jul 13 01:21:33 2007
Errors in file d:\oracle\db\product\admin\mydb\bdump\mydb1_lmon_4608.trc:
ORA-27091 : unable to queue I/O
ORA-27070 : async read/write failed
OSD-04006: ReadFile() failure, unable to read from file
O/S-Error: (OS 1117) The request could not be performed because of an I/O device error.
==========================================================================

Oracle ASM Instance Encounters (OS 1117) errors

  1. If an Oracle ASM instance encounters the error, you may see similar errors in the ASM instance’s Alert log:

============================================
Fri Jul 13 01:22:10 2007
Errors in file d:\oracle\asm\product\admin\+asm\bdump\+asm1_gmon_3836.trc:
ORA-27091 : unable to queue I/O
ORA-27070 : async read/write failed
OSD-04016: Error queuing an asynchronous I/O request.
O/S-Error: (OS 1117) The request could not be performed because of an I/O device error.
============================================

CRS Daemon (crsd.exe) encounters 1117 errors
3. If you are running in an Oracle Clusterware environment, then you may also see errors in the crsd.log and/or certain resource logs, indicating a problem accessing the OCR (Oracle Cluster Registry). An example of those errors would be:

================================================
2007-07-13 01:21:51.766: [ OCROSD][4272]utwrite:4: Problem writing the buffer phy offset 184320 and oserror 1117
2007-07-13 01:21:51.766: [ OCROSD][4352]utwrite:4: Problem writing the buffer phy offset 184320 and oserror 1117
2007-07-13 01:21:51.766: [ OCRRAW][4352]beginlog: problem 26 clearing the log metadata buffer
2007-07-13 01:21:51.766: [ OCRRAW][4352]proprdkey: Problem in begin log
2007-07-13 01:21:51.766: [ OCRRAW][4352]proprseterror: Error in accessing physical storage [26] Marking context invalid.
================================================

CSS Daemon (ocssd.exe) encounters 1117 errors

  1. Also, in an Oracle Clusterware environment, the Cluster Synchronization Services daemon (ocssd.exe) may experience problems accessing the voting disk. If this occurs, you will see an error in the ocssd.log similar to the following:

============================================
[ CSSD]2007-07-13 01:22:12.501 [4052] >ERROR: Internal Error Information:
Category: 1234
Operation: scls_block_write
Location: WriteFile
Other: unable to write block(s)
Dep: 1117

[ CSSD]2007-07-13 01:22:12.501 [4052] >ERROR: clssnmvReadBlocks: read failed 1 at offset 533 of \\.\votedsk2
[ CSSD]2007-07-13 01:22:12.501 [4052] >TRACE: clssnmDiskStateChange: state from 4 to 3 disk (1/\\.\votedsk2)
[ CSSD]2007-07-13 01:22:12.501 [2200] >TRACE: clssnmDiskPMT: disk offline (1/\\.\votedsk2)
[ CSSD]2007-07-13 01:22:12.501 [2200] >ERROR: clssnmDiskPMT: Aborting, 1 of 2 voting disks unavailable
[ CSSD]2007-07-13 01:22:12.501 [2200] >ERROR: ###################################
[ CSSD]2007-07-13 01:22:12.501 [2200] >ERROR: clssscExit: CSSD aborting
[ CSSD]2007-07-13 01:22:12.501 [2200] >ERROR: ###################################
==============================================

  1. When you are running in an Oracle Clusterware environment, if the ocssd process encounters an I/O error when accessing the Voting Disk, the CSS daemon will evict the node from the cluster. This is done by signalling the Oracle Fence Driver (OraFencedrv.sys) to reboot the machine. When the fence driver reboots the machine, this will be seen as a bugcheck with stop code 0x0000ffff. You will be able to see this in the System Log with a message such as:

The computer has rebooted from a bugcheck.
The bugcheck was: 0x0000ffff (0x0000000000000000, 0x0000000000000000,
0x0000000000000000, 0x0000000000000000).
A dump was saved in: C:\WINDOWS\MEMORY.DMP.

Note that the bugcheck is expected behavior when ocssd.exe (the Cluster Synchornization Services daemon) encounters an I/O error when accessing the voting disk. The node experiencing the I/O error is intentionally rebooted to avoid a split-brain and possible data corruption when access to the voting disk is lost.
CHANGES

You may encounter this error after upgrading the Microsoft Storport driver to version 5.2.3790.4021 or later.

CAUSE

Reference Microsoft KB article#932755, available at the following URL:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;932755

Per that article, one of the changes introduced in this version of the Storport driver is the following:

=========================================================
If a target returns a SCSI status of BUSY or Task Set Full, the port driver retries the command immediately. Storport retries the command an unlimited number of times. Therefore, if the busy status continues, the system could eventually experience problems.

This update configures the following behavior:

  • It limits the number of retries. The default is 20.
  • If the target returns a status of BUSY, the Storport driver performs a time-based pause before the Storport driver retries the command.
  • If the target returns a status of Task Set Full, the Storport driver performs an I/O completion-based pause before the Storport driver retries the command.
    =========================================================

Therefore, prior to upgrading the Storport driver, if a storage path had become saturated, the Storport driver would immediately continue to retry – indefinitely. This would result in slow I/O and perhaps a hang or spin scenario, but no error would be returned.

With the later version of the Storport driver, the retries are limited to 20 retries by default, with a pause between each retry. After 20 failures with a device busy status, the (OS 1117) error is returned to applications waiting on I/O. For more information on changes to the Storport driver, you must contact Microsoft.

SOLUTION

This is an I/O performance problem. You will need to increase the performance/capacity of the storage system to avoid the prolonged BUSY status. Specific solutions will vary, depending on your storage vendor, so the storage vendor may need to be contacted to assist with tuning the storage. One potential solution includes implementing multi-pathing technology to improve the throughput of the storage.

 

【Oracle数据恢复】ORA-00600:[2846]与ORA-01498

当使用updatable snapshot且C_MLOG# cluster受损时可能出现

 

ORA-00600: internal error code, arguments: [2846], [1], [65535], [1], [8192], [8192]
kdcchk: error when looking at index with key:
col 0; len 16; (16): 43 4c 49 45 4e 54 5f 47 52 50 5f 45 4e 54 52 59
col 1; len 6; (6):44 41 44 4d 49 4e
kdcchk: index points to block 0x00401667 slot 0x0 chain length is 1
kdcchk: chain pointer 0x00401667.0 points to row which does not match!

Running ANALYZE CLUSTER C_MLOG# VALIDATE STRUCTURE causes:
ORA-01498: block check failure - see trace file
kdbchk: the amount of space used is not equal to block size
used=413 fsc=838 avsp=6823 dtl=8096
Block header dump: rdba: 0x00401667
Object id on Block? Y
seg/obj: 0x84 csc: 0x00.5ac50c6 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x4016de ver: 0x01

这一般说明C_MLOG#簇受损了; 具体的解决方案包括:

1、从簇表中将数据抽取出来
2、DROP掉原表、簇索引和簇
3、重建这些cluster簇
4、把数据插会原表

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件,其具有全程图形化界面、简单高效等特点。
欢迎下载使用ORACLE PRM。 下载地址:http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

了解RMAN遇到的Ora-19566

在做rman备份时用户经常可能遇到ORA-19566错误,Exceeded Limit Of 0 Corrupt Blocks,该错误说明在备份过程中遇到坏块(一般就是ORA-1578 所指物理坏块):

 

RMAN-06554: WARNING: file 15 is in backup mode
RMAN-06554: WARNING: file 16 is in backup mode
RMAN-06554: WARNING: file 17 is in backup mode
RMAN-06554: WARNING: file 18 is in backup mode
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on ch1 channel at 09/01/2007 19:38:44
ORA-19566: exceeded limit of 0 corrupt blocks for file


使用dbv工具检测也会发现坏块

dbv file=new.dbf

 blocksize=16384 DBVERIFY: Release 9.2.0.4.0 - Production on Thu Aug 30 18:06:59 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = new.dbf Page 91880 is influx - most likely media corrupt
***
Corrupt block relative dba: 0x048166e8 (file 18, block 91880)
Fractured block found during dbv: Data in bad block -
type: 0 format: 0 rdba: 0x00000000
last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00 consistency value in tail: 0x00000001
check value in block header: 0x0, block checksum disabled spare1: 0x0, spare2: 0x0, spare3: 0x0
***
DBVERIFY - Verification complete
Total Pages Examined : 128000 Total Pages Processed (Data) : 10475 Total Pages Failing (Data) : 0
Total Pages Processed (Index): 1154 
Total Pages Failing (Index): 0
Total Pages Processed (Other): 645 
Total Pages Processed (Seg) : 0 
Total Pages Failing (Seg) : 0 
Total Pages Empty : 115725 Total Pages Marked Corrupt : 1 Total Pages Influx : 1 

 

但是实际使用脚本去定位坏块所在数据段segment时却找不到:

SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents
WHERE file_id = 18
and 91880 between block_id AND block_id + blocks - 1;

 

这一般说明坏块是游离的,不位于任何数据段segment上,可以通过3种方法来修复坏块:

  1. block recover
  2. 通过在游离块上建立数据对象来绕过该问题
  3. 通过resize数据文件 来绕过该问题。

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

 

 

 

ORA-01173

SQL> alter database open; 
alter database open 
* 
ERROR at line 1: 
ORA-01092: ORACLE instance terminated. Disconnection forced

And in the alert log: 


Wed Apr 23 13:08:13 2008 
Errors in file /strdv901/strdv9db/10.2.0/admin/STRDV9_soa048/udump/strdv9_ora_23033.trc: 
ORA-00704: bootstrap process failure 
ORA-00604: error occurred at recursive SQL level 2 
ORA-01173: data dictionary indicates missing data file from system tablespace 
Wed Apr 23 13:08:13 2008 
Error 704 happened during db open, shutting down database 
USER: terminating instance due to error 704 
Wed Apr 23 13:08:13 2008 
Errors in file /strdv901/strdv9db/10.2.0/admin/STRDV9_soa048/bdump/strdv9_mman_23015.trc: 
ORA-00704: bootstrap process failure 
Instance terminated by USER, pid = 23033 
ORA-1092 signalled during: alter database open...


Error:  ORA 1173 
Text:  data dictionary indicates missing data file from system tablespace
-------------------------------------------------------------------------------
Cause:  Either the database has been recovered to a point in time in the future of the control file or a datafile from the system tablespace was omitted from the create control file command previously issued.
Action: For the former problem you need to recover the database from a more recent control file. 
           For the latter problem, simply recreate the  control file checking to be sure that you include all the datafiles in the system tablespace.
SQL> alter database open; 
alter database open 
* 
ERROR at line 1: 
ORA-01092: ORACLE instance terminated. Disconnection forced

And in the alert log: 


Wed Apr 23 13:08:13 2008 
Errors in file /strdv901/strdv9db/10.2.0/admin/STRDV9_soa048/udump/strdv9_ora_23033.trc: 
ORA-00704: bootstrap process failure 
ORA-00604: error occurred at recursive SQL level 2 
ORA-01173: data dictionary indicates missing data file from system tablespace 
Wed Apr 23 13:08:13 2008 
Error 704 happened during db open, shutting down database 
USER: terminating instance due to error 704 
Wed Apr 23 13:08:13 2008 
Errors in file /strdv901/strdv9db/10.2.0/admin/STRDV9_soa048/bdump/strdv9_mman_23015.trc: 
ORA-00704: bootstrap process failure 
Instance terminated by USER, pid = 23033 
ORA-1092 signalled during: alter database open...


Error: ORA 1173 
Text: data dictionary indicates missing data file from system tablespace
-------------------------------------------------------------------------------
Cause: Either the database has been recovered to a point in time in the future of the control file or a datafile from the system tablespace was omitted from the create control file command previously issued.
Action: For the former problem you need to recover the database from a more recent control file. 
 For the latter problem, simply recreate the control file checking to be sure that you include all the datafiles in the system tablespace.

 

 

该ORA-01173错误也可能与UNDO损坏相关,需要专家手动Patch undo来修复。

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

沪ICP备14014813号-2

沪公网安备 31010802001379号