Oracle 11g DG新特性--Automatic block repair
Oracle 11g DG新特性--Automatic block repair
在oracle 11g DataGuard 中引入Automatic Block Media Repair，自動的塊恢復
如果在主庫發現有損壞的資料塊，該特性將通過後臺程式ABMR自動將物理備庫(physical standby)上的好的資料塊傳輸到主庫(primary database)上恢復
同樣的若物理備庫上發現資料塊損壞那麼也可以利用到以上特性來修復
此特性預設是開啟的
SQL> select * from v$version where rownum <=1;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
SQL> set linesize 132
SQL> column name format a30
SQL> column value format a25
SQL> select
2 x.ksppinm name,
3 y.ksppstvl value,
4 y.ksppstdf isdefault,
5 decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,
6 decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj
7 from
8 sys.x$ksppi x,
9 sys.x$ksppcv y
10 where
11 x.inst_id = userenv('Instance') and
12 y.inst_id = userenv('Instance') and
13 x.indx = y.indx and
14 x.ksppinm like '%_&par%'
15 order by
16 translate(x.ksppinm, ' _', ' ')
17 /
Enter value for par: auto_bmr
old 14: x.ksppinm like '%_&par%'
new 14: x.ksppinm like '%_auto_bmr%'
NAME VALUE ISDEFAULT ISMOD ISADJ
------------------------------ ------------------------- --------- ---------- -----
_auto_bmr enabled TRUE FALSE FALSE
_auto_bmr_bg_time 3600 TRUE FALSE FALSE
_auto_bmr_fc_time 60 TRUE FALSE FALSE
_auto_bmr_pub_timeout 10 TRUE FALSE FALSE
_auto_bmr_req_timeout 60 TRUE FALSE FALSE
_auto_bmr_sess_threshold 30 TRUE FALSE FALSE
_auto_bmr_sys_threshold 100 TRUE FALSE FALSE
7 rows selected.
下面我們做一個實驗：
主庫上建立實驗表
SQL> create table goolen as select * from dba_objects;
Table created.
SQL> select count(*) from goolen;
COUNT(*)
----------
74432
SQL> SELECT
2 dbms_rowid.rowid_relative_fno(rowid) REL_FNO,
3 dbms_rowid.rowid_block_number(rowid) BLOCKNO
4 from &table_name where rownum <=10;
Enter value for table_name: goolen
old 4: from &table_name where rownum <=10
new 4: from goolen where rownum <=10
REL_FNO BLOCKNO
---------- ----------
1 71969
1 71969
1 71969
1 71969
1 71969
1 71969
1 71969
1 71969
1 71969
1 71969
10 rows selected.
SQL> select dest_name,status,error,target,process from v$archive_dest where substr(dest_name,-1) in (1,2);
DEST_NAME STATUS ERROR TARGET PROCESS
------------------------------ --------- -------------------- ------- ----------
LOG_ARCHIVE_DEST_1 VALID PRIMARY ARCH
LOG_ARCHIVE_DEST_2 VALID STANDBY LGWR
+++備庫檢視此表是否已經同步到備庫
SQL> select count(*) from goolen;
COUNT(*)
----------
74432
+++我們看到備庫已經把這張表同步過來了
+++下面我們在主庫上人為破壞一個塊
RMAN> recover datafile 1 block 71969 clear;
Starting recover at 2013-12-27 11:17:02
using channel ORA_DISK_1
Finished recover at 2013-12-27 11:17:03
+++查詢一下
SQL> select count(*) from goolen;
COUNT(*)
----------
74432
++++然後我們檢視alter日誌中的資訊：
Corrupt block relative dba: 0x00411921 (file 1, block 71969)
Bad header found during multiblock buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x00411921
last change scn: 0x0002.1a0a61e7 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x99
consistency value in tail: 0x61e70601
check value in block header: 0xa7f1
computed block checksum: 0x8723
Reading datafile '/tol/oradata/test11g/system01.dbf' for corruption at rdba: 0x00411921 (file 1, block 71969)
Reread (file 1, block 71969) found same corrupt data
Starting background process ABMR
Fri Dec 27 11:17:22 2013
ABMR started with pid=116, OS id=4266
Auto BMR service is active.
Requesting Auto BMR for (file# 1, block# 71969)
Waiting Auto BMR response for (file# 1, block# 71969)
Auto BMR successful
+++在備庫模擬
++++在備庫手工損壞一個block
RMAN> recover datafile 1 block 71969 clear;
Starting recover at 2013-12-27 11:17:52
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1424 device type=DISK
Finished recover at 2013-12-27 11:18:04
+++dbv檢測
[oracle@dg_136 ~]$ dbv file=/tol/oradata/test11g/system01.dbf
DBVERIFY: Release 11.2.0.1.0 - Production on Fri Dec 27 11:20:21 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /tol/oradata/test11g/system01.dbf
Page 71969 is marked corrupt
Corrupt block relative dba: 0x00411921 (file 1, block 71969)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x00411921
last change scn: 0x0002.1a0a61e7 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x61e70601
check value in block header: 0x204b
computed block checksum: 0x82ae
DBVERIFY - Verification complete
Total Pages Examined : 256000
Total Pages Processed (Data) : 227158
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 14076
Total Pages Failing (Index): 0
Total Pages Processed (Other): 3459
Total Pages Processed (Seg) : 1
Total Pages Failing (Seg) : 0
Total Pages Empty : 11306
Total Pages Marked Corrupt : 1
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 436888803 (2.436888803)
++++查詢這張表
SQL> select count(*) from goolen;
COUNT(*)
----------
74432
++++但是在備庫的alter日誌裡面沒有發現相關的資訊
ORACLE 11g ACTIVE Data Guard 不僅提供了physical standby 可以open read-only ,還提供了一個無論是主備庫發現currupt block的情況下，在滿足一定條件下，透明的有ABMR後臺程式自動恢復該塊從另一方的可用的block.下面附上一段官方解釋，開始我的測試。
Automatic Block Repair
Automatic block repair allows corrupt data blocks to be automatically repaired as soon as the corruption is detected. This feature reduces the amount of time that data is inaccessible due to block corruption. This reduces block recovery time by using up-to-date good blocks in real-time, as opposed to retrieving blocks from disk or tape backups, or from Flashback logs.
Note:
Oracle Active Data Guard is packaged as a separate database option for Oracle Enterprise Edition. It requires a license for production database and all of the physical standby databases that are used for the Oracle Active Data Guard option.
if
A corrupt data block is discovered on a primary database
then
A physical standby database operating in real-time query mode can be used to repair corrupt data blocks in a primary database. If possible, any corrupt data block encountered when a primary database is accessed will be automatically replaced with an uncorrupted copy of that block from a physical standby database operating in real-time query mode. An ORA-1578 error is returned when automatic repair is not possible.
if
A corrupt data block is discovered on a physical standby database
then
The server attempts to automatically repair the corruption by obtaining a copy of the block from the primary database if the following database initialization parameters are configured on the standby database:
Configure the LOG_ARCHIVE_CONFIG parameter with a DG_CONFIG list
Configure a LOG_ARCHIVE_DEST_n parameter for the primary database
You can also manually repair a corrupted data block by using the RMAN RECOVER BLOCK command.
read more http://docs.oracle.com/cd/E11882_01/server.112/e17157/unplanned.htm#HAOVW141
PORA92 is primary site, SORA245 is standby site
搭建測試環境11G ADG 部門省略。
sys@PORA92>create tablespace tbs_test datafile '/oradata/pora92/pora92/tbs_test01.dbf' size 10m autoextend on maxsize 1g; Tablespace created. sys@PORA92>conn anbob Enter password: Connected. anbob@PORA92>create table testbmr tablespace tbs_test as select 1 id from dual ; Table created. anbob@PORA92>select distinct dbms_rowid.rowid_block_number(rowid) from testbmr; DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ------------------------------------ 131
1，測試主庫的currupt block auto repair
[oracle@dbserver92 ~]$ dd of=/oradata/pora92/pora92/tbs_test01.dbf bs=8192 seek=131 conv=notrunc count=1 if=/dev/zero 1+0 records in 1+0 records out 8192 bytes (8.2 kB) copied, 3.6111e-05 seconds, 227 MB/s [oracle@dbserver92 ~]$ dbv file='/oradata/pora92/pora92/tbs_test01.dbf' blocksize=8192 DBVERIFY: Release 11.2.0.4.0 - Production on Thu Feb 20 14:20:04 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /oradata/pora92/pora92/tbs_test01.dbf Page 131 is marked corrupt Corrupt block relative dba: 0x01400083 (file 5, block 131) Completely zero block found during dbv: DBVERIFY - Verification complete Total Pages Examined : 1280 Total Pages Processed (Data) : 0 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 127 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 1152 Total Pages Marked Corrupt : 1 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 1079914 (0.1079914) sys@PORA92>alter system flush buffer_cache; sys@PORA92>select * from anbob.testbmr; ID -------------------- 1 [oracle@dbserver92 ~]$ dbv file='/oradata/pora92/pora92/tbs_test01.dbf' blocksize=8192 DBVERIFY: Release 11.2.0.4.0 - Production on Thu Feb 20 14:21:48 2014 DBVERIFY - Verification complete Total Pages Examined : 1280 Total Pages Processed (Data) : 1 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 130 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 1149 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 1079997 (0.1079997)
alert log
===========================
ALTER SYSTEM: Flushing buffer cache
2014-02-20 14:22:23.779000 +08:00
Hex dump of (file 5, block 131) in trace file /oracle/diag/rdbms/pora92/pora92/trace/pora92_ora_21197.trc
Corrupt block relative dba: 0×01400083 (file 5, block 131)
Completely zero block found during buffer read
Reading datafile ‘/oradata/pora92/pora92/tbs_test01.dbf’ for corruption at rdba: 0×01400083 (file 5, block 131)
Reread (file 5, block 131) found same corrupt data (no logical check)
Starting background process ABMR
ABMR started with pid=32, OS id=21199
Automatic block media recovery service is active.
Automatic block media recovery requested for (file# 5, block# 131)
Automatic block media recovery successful for (file# 5, block# 131)
Automatic block media recovery successful for (file# 5, block# 131)
2，測試備庫的currupt block auto repair
– on standby site
>select name,log_mode,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE, REMOTE_ARCHIVE, DATABASE_ROLE from v$database; NAME LOG_MODE CONTROL OPEN_MODE PROTECTION_MODE REMOTE_A DATABASE_ROLE --------- ------------ ------- -------------------- -------------------- -------- ---------------- PORA92 ARCHIVELOG STANDBY READ ONLY WITH APPLY MAXIMUM PERFORMANCE ENABLED PHYSICAL STANDBY [oracle@dbserver58 ~]$ dd of=/oradata/sora245/tbs_test01.dbf bs=8192 seek=131 conv=notrunc count=1 if=/dev/zero 1+0 records in 1+0 records out 8192 bytes (8.2 kB) copied, 6.7053e-05 seconds, 122 MB/s [oracle@dbserver58 ~]$ dbv file='/oradata/sora245/tbs_test01.dbf' blocksize=8192 DBVERIFY: Release 11.2.0.4.0 - Production on Thu Feb 20 14:51:08 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /oradata/sora245/tbs_test01.dbf Page 131 is marked corrupt Corrupt block relative dba: 0x01400083 (file 5, block 131) Completely zero block found during dbv: DBVERIFY - Verification complete Total Pages Examined : 1280 Total Pages Processed (Data) : 0 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 130 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 1149 Total Pages Marked Corrupt : 1 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 1079997 (0.1079997) 因為備庫通常我們很少用select，先試一下此時通常的操作rman 會遭遇什麼？ RMAN> backup database; ... channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=/oradata/sora245/system01.dbf .. including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 20-FEB-14 channel ORA_DISK_1: finished piece 1 at 20-FEB-14 piece handle=/flrvarea/SORA245/SORA245/backupset/2014_02_20/o1_mf_ncsnf_TAG20140220T145617_9jc9rn1k_.bkp tag=TAG20140220T145617 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on ORA_DISK_1 channel at 02/20/2014 14:56:18 ORA-19566: exceeded limit of 0 corrupt blocks for file /oradata/sora245/tbs_test01.dbf
note:
now RMAN helped me to prove that there is a block corruption as the backup is failed with “ORA-19566: exceeded limit of 0 corrupt blocks”
Also, now Oracle reported the error in alert log as following
alert log
=====================
2014-02-20 15:22:53.353000 +08:00
Hex dump of (file 5, block 131) in trace file /oracle/diag/rdbms/sora245/sora245/trace/sora245_ora_2318.trc
Corrupt block relative dba: 0×01400083 (file 5, block 131)
Completely zero block found during backing up datafile
Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data
Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data
Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data
Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data
Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data
Deleted Oracle managed file /flrvarea/SORA245/SORA245/backupset/2014_02_20/o1_mf_nnndf_TAG20140220T152253_9jccbf9x_.bkp
sys@sora245>select * from anbob.testbmr;
ID
——————–
1
sys@sora245>alter system flush buffer_cache;
System altered.
sys@sora245>select dbms_rowid.ROWID_RELATIVE_FNO(rowid), dbms_rowid.rowid_block_number(rowid) from anbob.testbmr;
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
———————————— ————————————
5 131
sys@sora245>select * from anbob.testbmr;
ID
——————–
1
sys@sora245>select * from V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
——————– ——————– ——————– ——————– ———
5 131 1 0 ALL ZERO
NOTE:
這裡出了個小插曲， 可以查詢select,但是塊提示還是curuppted,此刻再次rman backup 還是報此塊損壞，exp 邏輯正常，而且alert 日誌也沒有出現abmr的日誌輸出。
下面檢視是不是禁用了ABMR?_auto_bmr 隱藏控制。和log_archive_config 引數archive_log_dest_N配置也是正常的
sys@sora245>@p bmr
old 4: and lower(n.ksppinm) like lower('%&1%')
new 4: and lower(n.ksppinm) like lower('%bmr%')
NAME VALUE
---------------------------------------- ----------------------------------------
_auto_bmr enabled
_auto_bmr_req_timeout 60
_auto_bmr_sess_threshold 30
_auto_bmr_pub_timeout 10
_auto_bmr_fc_time 60
_auto_bmr_bg_time 3600
_auto_bmr_sys_threshold 100
後來做了 dump block trace發現物理塊上是空塊，多次flush buffer cache的操作查詢仍然可以，那只有來自buffer cache,下面確認的確是。
sys@sora245>select file#,block#,status,objd,stale from v$bh where file#=5 and block#=131; FILE# BLOCK# STATUS OBJD S -------------------- -------------------- ---------- -------------------- - 5 131 mrec 87361 N
TIP:
mrec state means block in media recovery mode.
還曾經懷疑備庫的noformated block不可以被automatic repair，其實不是的。解決上面的問題是在主庫對該條記錄進行更新，如果發於standby 的block 是空或zero all,會自動re-formated.
-- on primary site sys@PORA92>update anbob.testbmr set id=3 where id=1; 1 row updated. sys@PORA92>commit; -- on standby site sys@sora245>select * from anbob.testbmr; ID -------------------- 3
後做了data block trace 發現塊是更新了，dbv, rman 也檢查正常通過了。下面來看一下buffer cache中flush 不掉的mrec block,通過重啟redo apply清除。
sys@sora245>select file#,block#,status,objd,stale from v$bh where file#=5 and block#=131; FILE# BLOCK# STATUS OBJD S -------------------- -------------------- ---------- -------------------- - 5 131 free 87361 N 5 131 mrec 87361 N 5 131 free 87361 N sys@sora245>alter database recover managed standby database cancel; sys@sora245>alter system flush buffer_cache; sys@sora245>select file#,block#,status,objd,stale from v$bh where file#=5 and block#=131; FILE# BLOCK# STATUS OBJD S -------------------- -------------------- ---------- -------------------- - 5 131 free 87361 N 5 131 free 87361 N 5 131 free 87361 N
對於上面的standby 端的automatic block repair 是失敗的，因為有BH中的mrec狀態 block，雖然後來通過primary site的塊更新覆蓋的standby 的block，在下一篇我會重新測試，如果bh 中沒有mrec的block 是不是可以觸發ABMR.
11G ADG automatic repair corrupt data blocks(ABMR自動壞塊修復)測試二
上一篇 11G ADG automatic repair corrupt data blocks(ABMR自動壞塊修復)測試一中，primary site 的ABMR 測試是成功的，而standby site 的ABMR沒有成功， 後來是懷疑buffer header中有mrec 的block, 現在我接著測試如果buffer header 中沒有此類block，ABMR是否成功?以前用bbed 標記corrupt block的方式， 如果有corrupt block時rman backup 又會怎麼樣？實驗開始..
sys@sora245>select dbms_rowid.ROWID_RELATIVE_FNO(rowid), dbms_rowid.rowid_block_number(rowid) from anbob.testbmr; DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ------------------------------------ ------------------------------------ 5 131 sys@sora245>select file#,block#,status,objd,stale from v$bh where file#=5 and block#=131; FILE# BLOCK# STATUS OBJD S -------------------- -------------------- ---------- -------------------- - 5 131 free 87361 N 5 131 xcur 87361 N sys@sora245>alter system flush buffer_cache; System altered. sys@sora245>select file#,block#,status,objd,stale from v$bh where file#=5 and block#=131; FILE# BLOCK# STATUS OBJD S -------------------- -------------------- ---------- -------------------- - 5 131 free 87361 N 5 131 free 87361 N [oracle@dbserver58 ~]$ dd of=/oradata/sora245/tbs_test01.dbf bs=8192 seek=131 conv=notrunc count=1 if=/dev/zero 1+0 records in 1+0 records out 8192 bytes (8.2 kB) copied, 3.8116e-05 seconds, 215 MB/s sys@sora245>select * from anbob.testbmr; ID -------------------- 3
alert log writen the following :
=======================================
Hex dump of (file 5, block 131) in trace file /oracle/diag/rdbms/sora245/sora245/trace/sora245_ora_10022.trc
Corrupt block relative dba: 0×01400083 (file 5, block 131)
Completely zero block found during multiblock buffer read
Reading datafile ‘/oradata/sora245/tbs_test01.dbf’ for corruption at rdba: 0×01400083 (file 5, block 131)
Reread (file 5, block 131) found same corrupt data (no logical check)
Automatic block media recovery requested for (file# 5, block# 131)
2014-02-21 13:41:02.134000 +08:00
Automatic block media recovery requested for (file# 5, block# 131)
Automatic block media recovery successful for (file# 5, block# 131)
Automatic block media recovery successful for (file# 5, block# 131)
TIP:
可以看到這次用了同樣的dd 破壞造成的物理corrupt block，buffer header中沒有mrec 狀態的block 時是可以成功自動repair的(select時).
BBED 構造邏輯currup block及rman 備份測試
[oracle@dbserver58 ~]$ bbed filename=/oradata/sora245/tbs_test01.dbf mode=edit Password: BBED: Release 2.0.0.0.0 - Limited Production on Fri Feb 21 16:46:05 2014 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. ************* !!! For Oracle Internal Use only !!! *************** BBED> set block 131 BLOCK# 131 BBED> dump File: /oradata/sora245/tbs_test01.dbf (0) Block: 131 Offsets: 0 to 511 Dba:0x00000000 ------------------------------------------------------------------------ 06a20000 83004001 a4951000 00000206 3fc50000 01000000 41550100 b77a1000 00000000 03003200 80004001 ffff0000 00000000 00000000 00000000 00800000 b77a1000 0a000800 a4030000 bc01c000 ff003f00 01200000 a4951000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00010100 ffff1400 771f631f 631f0000 01007a1f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> corrupt block 131 Block marked media corrupt. BBED> dump File: /oradata/sora245/tbs_test01.dbf (0) Block: 131 Offsets: 0 to 511 Dba:0x00000000 ------------------------------------------------------------------------ 06a20000 83000000 00000000 0000ff04 6fc60000 01000000 41550100 b77a1000 00000000 03003200 80004001 ffff0000 00000000 00000000 00000000 00800000 b77a1000 0a000800 a4030000 bc01c000 ff003f00 01200000 a4951000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00010100 ffff1400 771f631f 631f0000 01007a1f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> RMAN> backup datafile 5; Starting backup at 21-FEB-14 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=228 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00005 name=/oradata/sora245/tbs_test01.dbf channel ORA_DISK_1: starting piece 1 at 21-FEB-14 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on ORA_DISK_1 channel at 02/21/2014 16:50:14 ORA-19566: exceeded limit of 0 corrupt blocks for file /oradata/sora245/tbs_test01.dbf sys@sora245>alter system flush buffer_cache; System altered. sys@sora245>select * from anbob.testbmr; ID -------------------- 3 alert log ============================ Hex dump of (file 5, block 131) in trace file /oracle/diag/rdbms/sora245/sora245/trace/sora245_ora_10982.trc Corrupt block relative dba: 0x01400083 (file 5, block 131) Bad header found during backing up datafile Data in bad block: type: 6 format: 2 rdba: 0x00000083 last change scn: 0x0000.00000000 seq: 0xff flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x000006ff check value in block header: 0xc66f computed block checksum: 0x0 Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data Reread of blocknum=131, file=/oradata/sora245/tbs_test01.dbf. found same corrupt data Deleted Oracle managed file /flrvarea/SORA245/SORA245/backupset/2014_02_21/o1_mf_nnndf_TAG20140221T165012_9jg4t51o_.bkp 2014-02-21 16:50:47.965000 +08:00 ALTER SYSTEM: Flushing buffer cache 2014-02-21 16:50:49.831000 +08:00 Hex dump of (file 5, block 131) in trace file /oracle/diag/rdbms/sora245/sora245/trace/sora245_ora_10987.trc Corrupt block relative dba: 0x01400083 (file 5, block 131) Bad header found during multiblock buffer read Data in bad block: type: 6 format: 2 rdba: 0x00000083 last change scn: 0x0000.00000000 seq: 0xff flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x000006ff check value in block header: 0xc66f computed block checksum: 0x0 Reading datafile '/oradata/sora245/tbs_test01.dbf' for corruption at rdba: 0x01400083 (file 5, block 131) Reread (file 5, block 131) found same corrupt data (no logical check) Automatic block media recovery requested for (file# 5, block# 131) Automatic block media recovery requested for (file# 5, block# 131) Automatic block media recovery successful for (file# 5, block# 131) Automatic block media recovery successful for (file# 5, block# 131)
TIP:
可以看到bbed 只是修改了block的幾個標誌位造成corrupt block, rman 備份時會出錯，通過select 可以觸發ABMR,也會在primary site ,block 發現更新時覆蓋standby site的corrupt block,此時alert 無記錄。
轉載自：
http://www.anbob.com/archives/2156.html
http://www.anbob.com/archives/2163.html
About Me
|
........................................................................................................................ ● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除 ● 本文在itpub、部落格園、CSDN和個人微 信公眾號（ xiaomaimiaolhr）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162 ● 本文部落格園地址： http://www.cnblogs.com/lhrbest ● 本文CSDN地址： https://blog.csdn.net/lihuarongaini ● 本文pdf版、個人簡介及小麥苗雲盤地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址： http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ........................................................................................................................ ● QQ群號： 230161599 、618766405 ● 微 信群：可加我微 信，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友 （ 646634621 ），註明新增緣由 ● 於 2019-12-01 06:00 ~ 2019-12-31 24:00 在西安完成 ● 最新修改時間：2019-12-01 06:00 ~ 2019-12-31 24:00 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ........................................................................................................................ ● 小麥苗的微店： https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的資料庫類叢書： http://blog.itpub.net/26736162/viewspace-2142121/ ● 小麥苗OCP、OCM、高可用網路班： http://blog.itpub.net/26736162/viewspace-2148098/ ● 小麥苗騰訊課堂主頁： https://lhr.ke.qq.com/ ........................................................................................................................ 使用 微 信客戶端掃描下面的二維碼來關注小麥苗的微 信公眾號（ xiaomaimiaolhr）及QQ群（DBA寶典）、新增小麥苗微 信， 學習最實用的資料庫技術。
........................................................................................................................ |
 |
|
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2669159/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle 11G 新特性 Automatic block repairOracleBloCAI
- 11g Active Standby Database Automatic Block Corruption RepairDatabaseBloCAI
- oracle DG 11g新特性彙總Oracle
- Oracle 11g ADG Automatic Block Repair(ABMR自動塊修復)功能測試OracleBloCAI
- 11g DataGuard通過ABMR自動修復主庫壞塊 - Automatic Block Media RepairBloCAI
- 【ORACLE新特性】11G 分割槽新特性Oracle
- Oracle 11g 新特性Oracle
- Oracle 12c DG新特性Far SyncOracle
- oracle 11g 的新特性Oracle
- 【DATAGUARD】DG系列之11g新特性簡單介紹
- Oracle 11g 新特性簡介Oracle
- Oracle 11g 新特性之DRCPOracle
- Oracle 11g新特性：Result CacheOracle
- Oracle 11g 新特性(轉載)Oracle
- Oracle 11g新特性之SecureFilesOracle
- ORACLE 11G新特性之列新增操作Oracle
- Oracle 11g 新特性 -- SecureFiles 說明Oracle
- oracle 11g 新特性 表壓縮Oracle
- ORACLE DG 11G 搭建Oracle
- Oracle 11g 新特性 -- SQL Plan Management 示例OracleSQL
- 天天學習ORACLE（三）-11G新特性Oracle
- oracle 11g 新特性 磁碟組檢查Oracle
- oracle 10g R2 Block change tracking 新特性Oracle 10gBloC
- Oracle 11g 新特性 – HM（Hang Manager）簡介Oracle
- ORACLE 11g新特性-統計值掛起Oracle
- oracle 11g 新特性 data recover AdvisorOracle
- oracle 11g 新特性 Flashback Data Archive 說明OracleHive
- Oracle 11g的新特性分割槽：System PartitionOracle
- Automatic SQL Tuning in Oracle Database 11gSQLOracleDatabase
- 11g新特性--Oracle 11g 閃回資料歸檔Oracle
- oracle 11g dg搭建筆記Oracle筆記
- 新特性：/dev/shm對Oracle 11g的影響devOracle
- 【11g新特性】Oracle 加密表空間-可下載Oracle加密
- oracle 11G新特性--SYSASM 角色--用來管理ASMOracleASM
- oracle 11g R1 asm 磁碟組新特性OracleASM
- oracle 11g新特性之密碼大小寫敏感Oracle密碼
- 11g data guard 新特性
- 11g新特性--active dataguard