在11g Active DataGuard中,如果我们使用real time的功能,我们就可以使用Automatic Block Media Repair的特性来修复主库的坏块. 因为当你使用了real time的功能后,你对主库的更新会迅速传到备库,此时主库出现坏块,我们可以相反的从备库上把已经applying的block在传回给主库。
1、open real time Feature
alter database recover managed standby database cancel;
alter database open read only;
alter database recover managed standby database using current logfile disconnect;
2、Identify the blocks allocated to a table that contains containing data.
You may use the following query to translate the rowid to a file# and block#
select rowid, dbms_rowid.rowid_block_number(rowid) blockno, dbms_rowid.rowid_relative_fno(rowid) fno
from test.test
where rownum < 100
/
3. Using the block from the datafile identified file# using DD utility at OS level.
dd if=/dev/zero f=/oradata/orcl/users.dbf count=1 seek=164 bs=8192 conv=notrunc
4. Check the datafile for corruption :
dbv file=/oradata/orcl/users.dbf blocksize=8192
5. Flush the buffer cache on primary database to force a re-read the data from disk
alter system flush buffer_cache;
6. Attempt to select from the table. No error should occur and the data should return as valid
select * from test.test
where dbms_rowid.rowid_block_number(rowid)=164
and dbms_rowid.rowid_relative_fno(rowid)=9
/
此时我们可以看到数据能够查询出来,那么看一下我们的后台alert日志,记录了下列内容:
Wed Jul 07 17:34:25 2012
ALTER SYSTEM: Flushing buffer cache
Wed Jul 07 17:35:09 2012
Hex dump of (file 9, block 164) in trace file /oracle/app/oracle/diag/rdbms/dg1/dg1/trace/dg1_ora_4391.trc
Corrupt block relative dba: 0x010000ab (file 9, block 164)
Completely zero block found during multiblock buffer read
Reading datafile '/oradata/orcl/users.dbf ' for corruption at rdba: 0x010000ab (file 9, block 164)
Reread (file 9, block 164) found same corrupt data
Starting background process ABMR
Wed Jul 07 17:35:09 2012
ABMR started with pid=55, OS id=4364
Auto BMR service is active.
Requesting Auto BMR for (file 9, block 164)
Waiting Auto BMR response for (file 9, block 164)
Auto BMR successful