【Oracleデータリカバリ】Redo LogベッドブロックCorruptionの解決例 ORA-16038 ORA-00354 ORA-00353 ORA-00367 ORA-01624

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

 

データベースがあるredo logファイルを起動するときに、ログ損害/ベッドブロックが現れて、以下のエラになるかもしれない:

 

ORA-16038 log %s sequence# %s cannot be archived
ORA-354 corrupt redo log block header
ORA-353 log corruption near block  change time
ORA-367 checksum error in log file header

[oracle@mlab2 ~]$ oerr ora 16038
16038, 00000, “log %s sequence# %s cannot be archived”
// *Cause: An attempt was made to archive the named file, but the
// file could not be archived. Examine the secondary error
// messages to determine the cause of the error.
// *Action: No action is required.

[oracle@mlab2 ~]$ oerr ora 354
00354, 00000, “corrupt redo log block header”
// *Cause: The block header on the redo block indicated by the accompanying
// error, is not reasonable.
// *Action: Do recovery with a good version of the log or do time based
// recovery up to the indicated time. If this happens when archiving,
// archiving of the problem log can be skipped by clearing the log
// with the UNARCHIVED option. This must be followed by a backup of
// every datafile to insure recoverability of the database.
[oracle@mlab2 ~]$ oerr ora 353
00353, 00000, “log corruption near block %s change %s time %s”
// *Cause: Some type of redo log corruption has been discovered. This error
// describes the location of the corruption. Accompanying errors
// describe the type of corruption.
// *Action: Do recovery with a good version of the log or do incomplete
// recovery up to the indicated change or time.
www.askmac.cn
[oracle@mlab2 ~]$ oerr ora 367
00367, 00000, “checksum error in log file header”
// *Cause: The file header for the redo log contains a checksum that does
// not match the value calculated from the file header as read from
// disk. This means the file header is corrupted
// *Action: Find the correct file and try again.

【Oracleデータリカバリ】ORA-00600 [6749]一例

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

 

From 掲示板ユーザー:

 

 

RAC 環境

 

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

PL/SQL Release 11.2.0.3.0 – Production

CORE    11.2.0.3.0      Production

TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 – Production

NLSRTL Version 11.2.0.3.0 – Production

 

 

午後でアラームログに以下の情報が現れた:

 

Thread 1 advanced to log sequence 16646 (LGWR switch)

Current log# 102 seq# 16646 mem# 0: +ORADATA/portaldb/redo02.log

Thu Sep 04 16:48:52 2014

Errors in file /oracle/diag/rdbms/portaldb/portaldb1/trace/portaldb1_ora_40698472.trc  (incident=642694):

ORA-00600: internal error code, arguments: [6749], [3], [37923665], [163], [], [], [], [], [], [], [], []

Incident details in: /oracle/diag/rdbms/portaldb/portaldb1/incident/incdir_642694/portaldb1_ora_40698472_i642694.trc

Thu Sep 04 16:48:56 2014

Dumping diagnostic data in directory=[cdmp_20140904164856], requested by (instance=1, osid=40698472), summary=[incident=642694].

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Thu Sep 04 16:48:58 2014

Sweep [inc][642694]: completed

Sweep [inc2][642694]: completed

Thu Sep 04 16:53:14 2014

Thread 1 advanced to log sequence 16647 (LGWR switch)

Current log# 103 seq# 16647 mem# 0: +ORADATA/portaldb/redo103.log

 

 

找到了portaldb1_ora_40698472.trc (大约1.9G) 和portaldb1_ora_40698472_i642694.trc(11M左右) 两个文件 ;

 

oracle@ptdb1:/home/oracle/awrrpt_pack$du -sm portaldb1_ora_40698472.trc

1830.01 portaldb1_ora_40698472.trc

 

oracle@ptdb1:/home/oracle/awrrpt_pack$du -sm portaldb1_ora_40698472_i642694.trc

11.46   portaldb1_ora_40698472_i642694.trc

 

 

portaldb1_ora_40698472.trcこのファイルはリカバリ出来ないから。前にある大切な行をコピした;

 

UMP REDO

Opcodes 11.*

DBAs (file#, block#):

(9, 174929) .

SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff

**NOTE: Only Dumping Redo less then 12 hours**

Times: 09/04/2014 04:41:29 thru eternity

Initial buffer sizes: read 1024K, overflow 832K, change 805K

Thread 1 low checkpoint scn: 0x0001.4c4c6be0

Thread 2 low checkpoint scn: 0x0001.4c4cb42f

SCN Start Scan Point: scn: 0x0001.4c4cb42f (5575062575)

Initial buffer sizes: read 1024K, overflow 832K, change 805K

Initial buffer sizes: read 1024K, overflow 832K, change 805K

INCARNATION:

START: scn: 0x0000.00000001 (1) Timestamp:  06/01/2013 17:58:46

END: scn: 0xffff.ffffffff

descrip:”Thread 0001, Seq# 0000016485, SCN 0x00014c4c6be0-0x00014c4f53f2″

descrip:”Thread 0002, Seq# 0000018304, SCN 0x00014c4cb42f-0x00014c4ea321″

 

*** 2014-09-04 16:41:30.442

*Error – Unable to open log for Thread 2 at SCN: scn: 0x0001.4c4ea321 (5575189281)

END OF DUMP REDO

Dumping current redo log in thread 1

Initial buffer sizes: read 1024K, overflow 832K, change 805K

 

DUMP OF REDO FROM FILE ‘+ORADATA/portaldb/redo02.log’

Opcodes 11.*

DBAs (file#, block#):

(9, 174929) .

RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff

SCNs: scn: 0x0001.4c4cb42f (5575062575) thru scn: 0xffff.ffffffff

Times: 09/04/2014 04:41:29 thru eternity

FILE HEADER:

Compatibility Vsn = 186646528=0xb200000

Db ID=663718102=0x278f88d6, Db Name=’PORTALDB’

Activation ID=663749334=0x279002d6

Control Seq=1800459=0x1b790b, File size=1024000=0xfa000

File Number=102, Blksiz=512, File Type=2 LOG

descrip:”Thread 0001, Seq# 0000016641, SCN 0x0001502f1901-0xffffffffffff”

thread: 1 nab: 0xffffffff seq: 0x00004101 hws: 0x1 eot: 1 dis: 0

resetlogs count: 0x30b21356 scn: 0x0000.00000001 (1)

prev resetlogs count: 0x0 scn: 0x0000.00000000

Low  scn: 0x0001.502f1901 (5640231169) 09/04/2014 16:39:02

Next scn: 0xffff.ffffffff 01/01/1988 00:00:00

Enabled scn: 0x0000.00000001 (1) 06/01/2013 17:58:50

Thread closed scn: 0x0001.502f1901 (5640231169) 09/04/2014 16:39:02

 

 

20:05:59 sys@PORTALDB> column SEGMENT_NAME format a60

20:07:10 sys@PORTALDB> column owner format a10

20:07:38 sys@PORTALDB> column TABLESPACE_NAME format a10

20:07:49 sys@PORTALDB> SELECT tablespace_name,segment_type,owner,segment_name FROM dba_extents  wHERE file_id =9   and 174929 between block_id AND block_id + blocks – 1;

 

TABLESPACE SEGMENT_TYPE       OWNER      SEGMENT_NAME

———- —————— ———- ————————————————————

NEANDS     TABLE              NEANDS3    M_PRODUCT_ALIAS           //该表为条码表

 

Elapsed: 00:00:04.09

 

 

20:08:07 sys@PORTALDB>  select table_name, iot_name from all_tables where table_name=’M_PRODUCT_ALIAS’;

 

TABLE_NAME           IOT_NAME

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

M_PRODUCT_ALIAS

 

21:59:18 sys@PORTALDB> select do.owner,do.object_name, do.object_type,sysind.flags

22:10:33   2       from dba_objects do, sys.ind$ sysind

22:10:33   3       where do.object_id = sysind.obj#

22:10:33   4       and bitand(sysind.flags,4096)=4096;

 

no rows selected

 

その中portaldb1_ora_40698472_i642694.trcファイルの文を確認してください。それが原因かもしれないから。Trcファイルとこのテーブルを開發者に渡した。

 

*** 2014-09-04 16:48:52.213

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

—– Current SQL Statement for this session (sql_id=f40kjffsrvhvp) —–

UPDATE M_PRODUCT_ALIAS A SET A.IS_TOWMS = ‘N’ WHERE A.M_PRODUCT_ID = :B1

 

ここまでまだわからない。トラブルをここに掲載して、みんなの力を貸して下さい

 

 
odm finding :
Format: ORA-600 [6749] [a]

VERSIONS:
versions 7.3 to 8.1

DESCRIPTION:

This internal occurs during the row change for update or delete.
Some reported problems are consistent read issue, some bugs are related to
row corruption on the block.

FUNCTIONALITY:
ROW DELETE

IMPACT:
PROCESS FAILURE
ROW CORRUPTION
[6749], [3], [37923665], [163], [], [], [], [], [], [], [], []
3は row no longer exists 行が存在していないと意味している

37923665 はdba
C は行のslot number

11.2.0.3 で該当するBugがないから、そのテーブルに対してANALYZE TABLE <table_name> VALIDATE STRUCTURE CASCADEする;そしてflush buffer_cacheする;エラがまだ残っていれば、テーブルを再構造してください。
7705591 Corruption with self-referenced row in MSSM tablespace. Wrong Results / OERI[6749] / ORA-8102
UPDATE M_PRODUCT_ALIAS A SET A.IS_TOWMS = ‘N’ WHERE A.M_PRODUCT_ID = :B1

Dump continued from file: /oracle/diag/rdbms/portaldb/portaldb1/trace/portaldb1_ora_40698472.trc
ORA-00600: internal error code, arguments: [6749], [3], [37923665], [163], [], [], [], [], [], [], [], []
pin: ‘kduwh18: kdu_array_flush’ waiters: 1
addr: 0x7000001ff813088 obj: 161302 cls: DATA bscn: 0x1.50311147
buffer tsn: 15 rdba: 0x0242ab51 (9/174929)
scn: 0x0001.50311147 seq: 0x01 flg: 0x04 tail: 0x11470601
frmt: 0x02 chkval: 0x2018 type: 0x06=trans data
ock header dump: 0x0242ab51
Object id on Block? Y
seg/obj: 0x27616 csc: 0x01.503110d9 itc: 8 flg: – typ: 1 – DATA
fsl: 0 fnx: 0x0 ver: 0x01

0x158:pri[163] offs=0x85c
tab 0, row 163, @0x85c
tl: 2 fb: –HDFL– lb: 0x1

 

【Oracle Asmデータリカバリ】ORA-00600 [kfdAuDealloc2]エラ解析

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

 

あるユーザーのASMインスタンスがORA-00600 [kfdAuDealloc2]エラになった、具体的なログは以下の通り:

 

Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb6_15539.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [35], [272], [748], [], [], [], [], [], [], [], []
NOTE: stopping process ARB6
ERROR: ORA-600 thrown in ARB2 for group number 1
Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb2_15523.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [148], [270], [720], [], [], [], [], [], [], [], []
NOTE: stopping process ARB2
ERROR: ORA-600 thrown in ARB3 for group number 1
Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb3_15527.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [196], [271], [0], [], [], [], [], [], [], [], []
NOTE: stopping process ARB3
ERROR: ORA-600 thrown in ARB5 for group number 1
Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb5_15535.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [363], [272], [1], [], [], [], [], [], [], [], []
NOTE: stopping process ARB5


Errors in file /u02/oracle/ASM/diag/asm/+asm/+ASM/trace/+ASM_rbal_27162.trc (incident=674120):
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [101], [335], [300], [], [], [], [], [], [], [], []
Incident details in: /u02/oracle/ASM/diag/asm/+asm/+ASM/incident/incdir_674120/+ASM_rbal_27162_i674120.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ERROR: An unrecoverable error has been identified in ASM metadata. The instance will be taken down.
Sun Nov 25 20:51:11 2012
NOTE: AMDU dump of disk group DWHCTL1 created at /u02/oracle/ASM/diag/asm/+asm/+ASM/incident/incdir_674120
NOTE: starting check of diskgroup DWHCTL1
ERROR: file +dwhctl1.330.797592669: F330 PX11 => D0 A7650 => F385 PX135: fnum mismatch
ERROR: file +dwhctl1.330.797592669: F330 PX12 => D0 A7651 => F385 PX136: fnum mismatch


 

kfdAuDealloc2はKernel Files Disk AU DEALLOCateと意味している。それはASM DISKのAUを回収するために使われている 。このエラになった場合は ASM metadataのallocation tableがロジックデータが一致していないと意味している。

関連するbug :

 

Bug 5682184 OERI[kfdAuDealloc2] from resize/drop more than 16TB ASM file

Bug 10621169 I/O errors during RAC ASM recovery may drop redo and cause metadata corruptions / ORA-600

BUG 10017130 – ORA-600 [KFDAUDEALLOC2] DURING REBALANCE AFTER ADDING DISKS

 

このエラになったら、人工的にasm metadataをpatchしてください。

【データリカバリ】ORA-600[4xxx]エラを解決してデータベースを起動する

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

 

Recovering a Dropped Table from a Full Database Backup using manual backup and recovery procedures (Doc ID 96197.1)

You cannot follow the note exactly as this note is for a valid full backup where you have all logs needed for point in time recovery – the changes you need to make are in the summary steps above.
Once you have done the recovery we can attempt a force open (you will have to do the restore/recovery again for sys, sysaux and undo because you have done an open resetlogs on the restored database):

YOU ARE ADVISED TO TAKE A FULL COLD OS BACKUP OF THE DATABASE BEFORE PROCEEDING WITH THE FORCE OPEN.

To force open a database:

  1. if you are using AUM you need to identify ALL rollback segments listed in your dictionary (system dbfs):

On unix, you can use the unix strings command to extract the rollback segments:

$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU

where system01.dbf is the name of the datafile for the SYSTEM tablespace – if you have > 1 system dbf then you need to do this for each file, writing to a different listSMUn file each time.

  1. Mount the database and create a pfile (if you dont already have one)

SQL>create pfile=’init<sid>.ora’ from spfile;

Edit the pfile – add :

_allow_resetlogs_corruption=true
undo_management=MANUAL
_corrupted_rollback_segments=<list>

Where <list> is the list of rollback segment names extracted as above with ‘$’ appended to each name eg

_corrupted_rollback_segments=(_SYSSMU1$, _SYSSMU2$………_SYSSMU10$)

  1. Remount the instance using the amended pfile and then do the following:

SQL>recover database using backup controlfile until cancel;
SQL>cancel
SQL>alter database open resetlogs;

If this works then you can EXPORT the database contents – the database will have to be completely rebuilt and the data re-imported.
IF this fails then I need to see the failure (ORA-1555, ORA-600[2662], ORA-600[4194], Ora-600[4000] are common errors raised during force open), along with the alert log extract showing the start up after setting these hidden parameters. Please remember to REMOVE the hidden parameters after you have exported – the should never be used without advice from Oracle Support.

 

【Oracle ASMデータリカバリ】oracleasm deletediskに削除されたASM Diskをどうやってリカバリできるか

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

まず、asmlibを使うことを勧めない。具体的な原因はWhy ASMLIB and why not?に参考してください。

 

けどasmlibを使った場合に、ユーザーがoracleasm deletediskの誤操作でASM Diskの asmlibマックを削除したら、以下の方法でリカバリできる:

  1. backup database using RMAN
  2. dismount the active Disk group
    3. Create KFED following ‘unpublished’ Note 284646.1 Creating and using the kfed utility to view ASM disk header 4. Follow same note to perform kfed read on the affected disk headers.
    5. Examine the output to verify that the header appears similar to the following:

kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0 kfbh.check: 3808867501 ; 0x00c: 0xe306b4ad kfbh.fcn.base: 1463 ; 0x010: 0x000005b7
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLCLRD ; 0x000: length=8 kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000

The value ORCLCLRD is set after using /etc/init.d/oracleasm deletedisk 6. Assuming that kfbh.type = KFBTYP_DISKHEAD

and that kfdhdb.driver.provstr: = ORCLCLRD
for each disk this operation will be successful.
7. kfed read <device name> > fix.txt
8. Edit fix.txt to change only ORCLCLRD to ORCLDISK 9. kfed merge <device name> text=fix.txt
10. etc/init.d/oracleasm listdisk
11. etc/init.d/oracleasm force-renamedisk

This command requires 2 arguments the first is the full path to the disk the second is the LABEL that will be stamped on the disk.

 

【Oracle ASMデータリカバリ】ORA-00600 [KFRVALACD30]エラ解析

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

あるユーザーがORA-00600 [kfrValAcd30]に遭遇して、ASMインスタンスが实例が起動できなくなった。その前にユーザーが電源を切って、オペレーションシステムを再起動した。

そのエラのstack callは以下の通り:

STACK TRACE:
————
skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp
<- ksfdmp <- dbgexPhaseII <- dbgexProcessError <- dbgeExecuteForError
<- dbgePostErrorKGE
<- 1615 <- dbkePostKGE_kgsf <- kgeadse <- kgerinv_internal <-
kgerinv
<- kgeasnmierr <- kfrValAcd <- kfrgnr <- kfrgnc <- kfrPass1
<- kfrcrv <- kfcMountPriv <- kfcMount <- kfgInitCache <-
kfgFinalizeMount
<- 2149 <- kfgscFinalize <- kfgForEachKfgsc <- kfgsoFinalize <-
kfgFinalize
<- kfxdrvMount <- kfxdrvEntry <- opiexe <- opiosq0 <- kpooprx
<- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino
<- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main <- libc_start_main <- start

kfrValAcd Reap the current log read I/O.

 

そのエラの原因はdiskgroupをリカバリするときに、ACD記録seq=111と気づいた。けど実際にACDの記録はseq=6である。

 

このトラブルに対して、 PRMツールでそのトラブルdiskgroupのデータファイルを抽出して、Diskgroupを再構造する。

PRM FOR ORACLEについて http://parnassusdata.com/に参考してください。

 

【Oracle ASMデータリカバリ】ORA-00600 [KFCEMA02]エラ解析

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

今度、ORA-00600 [KFCEMA02]を引き起こしたのはbug  6163771を含むバーションで起こった。ASMインスタンス崩壊したあと、diskgroupをmountしたが、失敗した。ORA-00600 [KFCEMA02]エラになった。

ORACLEがいろんなプラットフォームでbug  6163771に対していろんなバチを提供しているが、これはせいぜい予防するだけで、実際にリカバリ出来ない。このトラブルはとびきり特別だから、特別な内部ツールFACPしかリカバリできない。このツールはASM checkpoint情報をリカバリできる。その機能はASM Diskgroupの特性metadataソースデータをリカバリする。

 

ORA-00600: internal error code, arguments: [kfcema02], [0], [165057275], [], [], [], [], [], [], [], [], []

 

【ORACLEデータベースリカバリ】ORA-00600[KCLCHKBLK]

 

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

 

ORA-600: internal error code, arguments: [kclchkblk_3/4]エラに関する症状は以下の通り:

 

  • バックアップからデータベースをrestoreして、それにincomplete recovery不完全リカバリするとき
  • Resetlogsオプションでデータベースを起動する
  • データベースを起動したあと、いかのエラになるかもしれない:
    • ORA-00600 [kclchkblk_4]
      ORA-00600 [2662]
  • そのエラスタックstack traceはkclchkblk kcbzib kcbgcur ktfbhget ktftfcload

 

そのえらを引き起こした原因は:

 

ORA-600[KCLCHKBLK_4]は一時的なファイルのブロックのSCNが高すぎたから引き起こした。ORA-600[2662]エラもそれに似た原因である。

このトラブルはRESETLOGSを起動したあと、一時ファイルtemporary fileが正確初期化されていないからだ。

このORA-00600[KCLCHKBLK]のKCLCHKBLKは check block scn after a disk read

ORA-600 [kclchkblk_3] [a] [b] [c]と意味している。

The error is reported when the block SCN is less than the last block SCN.
Called by the cache layer after reading a block from disk.

The block SCN is checked to make sure it is not greater than the recent
SCN and not less than the last block SCN seen.

ARGUMENTS:
Arg [a]  Current SCN WRAP
Arg [b]  Current SCN BASE
Arg [c]  Block type

FUNCTIONALITY:
Check Block scn

IMPACT:
MEMORY CORRUPTION
POSSIBLE PHYSICAL CORRUPTION

 

 

 

 

今までしているORA-00600[KCLCHKBLK3/4]に関するBUGリストは以下の通り:

 

NB Bug Fixed Description
17273253 12.1.0.1.1 Various ORA-600 corruption errors with ASM
14034244 11.2.0.3.BP09, 11.2.0.4, 12.1.0.1 Lost write type corruption using ASM in 11.2.0.3
12718090 11.2.0.3.1, 11.2.0.3.BP02, 11.2.0.4, 12.1.0.1 ORA-600 [kclchkblk_3] can occur in RAC
+ 10425010 11.2.0.3, 12.1.0.1 Stale data blocks may be returned by Exadata FlashCache
* 10205230 11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1 ORA-600 / corruption possible during shutdown in RAC
10071193 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 Lost write / ORA-600 [kclchkblk_3] / ORA-600 [3020] in RAC – superceded
+ 8597106 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 Lost Write in ASM when normal redundancy is used
12905058 11.2.0.3.1, 11.2.0.3.BP02, 11.2.0.4.1, 11.2.0.4.BP02 Rare ASM corruption after disk resync
4767885 10.2.0.1 OERI [kclchkblk_3] possible in RAC
3601253 9.2.0.6, 10.1.0.2 OERI[kclchkblk_3] possible accessing transported tablespace in RAC
2000029 9.0.1.3, 9.2.0.1 OERI:KCLCHKBLK_3 possible in RAC after reconfiguration

 

 

NB Bug Fixed Description
14351566 11.2.0.3.8, 11.2.0.3.BP21, 11.2.0.4, 12.1.0.1 ORA-600 [kclchkblk_4] when doing flash back

 

NB Bug Fixed Description
10112810 11.2.0.3, 12.1.0.1 ORA-600[kjbcrc:g] / ORA-600[kclchkblk_2] / [kjbconvert:modes] With Flash Cache Enabled on RAC
2873045 9.2.0.4, 10.1.0.2 OERI:[KCLCHKBLK_2] possible in RAC

 

【Oracleデータベースリカバリ】I_OBJ1、I_OBJ2、I_OBJ3、I_OBJ4、I_OBJ5などSYSインディクスのリカバリ

 

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

 

I_OBJ1、I_OBJ2、I_OBJ3、I_OBJ4、I_OBJ5、これら全部もOBJ$テーブルのインディクスで、壊された場合に、厄介になる。OracleがこれらのオブジェクトのDDLに対して厳しい制限をつけているから、そう簡単にリカバリできない。
以下の例のように:

*** 2012-01-31 05:59:24.837

Doing block recovery for file 25 block 2256706

Block header before block recovery:

buffer tsn: 0 rdba: 0x06626f42 (25/2256706)

scn: 0x08b7.b1dff478 seq: 0x01 flg: 0x04 tail: 0xf4780601

frmt: 0x02 chkval: 0x8da3 type: 0x06=trans data

Doing block recovery for file 25 block 2256706

Block header before block recovery:

buffer tsn: 0 rdba: 0x06626f42 (25/2256706)

 

 

——————–

It looks like PMON is trying to recover a block, and is unable to do so.

select * from dba_extents where 2256706 between block_id and block_id +

blocks

SQL> i

2 and file_id = 25;

SYS I_OBJ5

INDEX SYSTEM

70 25

2256640 1048576 128

25

 

 

以上は25番ファイルの2256706にエラになった。該当するオブジェクトはSYSのインディクスi_obj5である。けど、これはディクショナリーテーブルOBJ$のインディクスだから、再構造できない:

 

 

No ddl is allowed for i_obj5 as it is needed for warm start:

SQL> drop index i_obj5;

drop index i_obj5

*

ERROR at line 1:

ORA-00701: object necessary for warmstarting database cannot be altered

 

alter system set events ‘10293 trace name context forever, level 1’;

and also get 3 PMON errorstack at level 5133 in 1 min intervals.

dbv userid=sys/pass file= blocksize= start=2256706 end=2256706

 

 

以上はインディクスに対して、どんなオペレーションを実行しても、ORA-701エラになる。これで、特別な手段でI_OBJ1、I_OBJ2、I_OBJ3、I_OBJ4、I_OBJ5などSYSインディクスをリカバリしてください。

 

【Oracleデータリカバリ】ORA-01122,ORA-01110,ORA-01200エラ解析

プロの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.

 

ORA-1200エラに対するディスクライブは、今のデータファイルの実際サイズがデータファイルヘッダにディスクライブされたヘッダの数より小さい場合に、ここでディスクライブした実際のサイズはOSのシステム使用によって獲得した。これはデータファイルが切断されたと意味している。

 

 

バックアップもアーカイブも完全な場合に、バックアップでリカバリするだけでトラブルを解決できる。この文で紹介した方法はバックアップがない場合に限って運用できる。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の検証に騙せる。けどデータベースを起動したあと、データベースを再構造することを勧めている。。

 

 

 

沪ICP备14014813号-2

沪公网安备 31010802001379号