oracle中RMAN備份和檢查邏輯壞塊

來源:互聯網
上載者:User

1. RMAN備份時是預設檢查物理壞塊。

2. 如果要檢查邏輯壞塊,可以用如下語句:

$ rman target /
RMAN> backup check logical validate database;

註上述語句,只是檢查,不會備份的。

3. 如果要在備份的同時,進行邏輯壞塊檢查,可以用:

$ rman target /
RMAN> backup check logical database;

4.如果發現壞邏輯如何處理,下面補充一篇教程。


利用RMAN檢測資料庫壞塊的指令碼

雖然我們也可以通過dbv(db file verify)工具做到對單個資料檔案的壞塊檢測,但是直接使用RMAN的”backup validate check logical database;”結合V$DATABASE_BLOCK_CORRUPTION視圖要方便地多。

1) $ rman target / nocatalog

2) RMAN> run {
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
backup validate check logical database;
}

3) select * from V$DATABASE_BLOCK_CORRUPTION ;

REM www.askmaclean.com & www.askmaclean.com

4) If V$DATABASE_BLOCK_CORRUPTION contains rows please run this query to
find the objects that contains the corrupted blocks:

SELECT e.owner,
       e.segment_type,
       e.segment_name,
       e.partition_name,
       c.file#,
       greatest(e.block_id, c.block#) corr_start_block#,
       least(e.block_id + e.blocks - 1, c.block# + c.blocks - 1) corr_end_block#,
       least(e.block_id + e.blocks - 1, c.block# + c.blocks - 1) -
       greatest(e.block_id, c.block#) + 1 blocks_corrupted,
       null description
  FROM dba_extents e, v$database_block_corruption c
 WHERE e.file_id = c.file#
   AND e.block_id <= c.block# + c.blocks - 1
   AND e.block_id + e.blocks - 1 >= c.block#
UNION
SELECT s.owner,
       s.segment_type,
       s.segment_name,
       s.partition_name,
       c.file#,
       header_block corr_start_block#,
       header_block corr_end_block#,
       1 blocks_corrupted,
       'Segment Header' description
  FROM dba_segments s, v$database_block_corruption c
 WHERE s.header_file = c.file#
   AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner,
       null segment_type,
       null segment_name,
       null partition_name,
       c.file#,
       greatest(f.block_id, c.block#) corr_start_block#,
       least(f.block_id + f.blocks - 1, c.block# + c.blocks - 1) corr_end_block#,
       least(f.block_id + f.blocks - 1, c.block# + c.blocks - 1) -
       greatest(f.block_id, c.block#) + 1 blocks_corrupted,
       'Free Block' description
  FROM dba_free_space f, v$database_block_corruption c
 WHERE f.file_id = c.file#
   AND f.block_id <= c.block# + c.blocks - 1
   AND f.block_id + f.blocks - 1 >= c.block#
 order by file#, corr_start_block#;

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

補充:


啟動 backup 於 28-11月-04
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在啟動 full 資料檔案備份組
通道 ORA_DISK_1: 正在指定備份組中的資料檔案
輸入資料檔案 fno=00028 name=E:ORACLEORADATAORABD02TS_TEST01.DBF
通道 ORA_DISK_1: 正在啟動段 1 於 28-11月-04
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 11/28/2004 15:45:
51
ORA-19566: 超出損壞塊限制 0 (檔案 E:ORACLEORADATAORABD02TS_TEST01.DBF)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
掃描資料庫的物理錯誤和邏輯錯誤
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
RMAN> backup validate  datafile 28;

啟動 backup 於 28-11月-04
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在啟動 full 資料檔案備份組
通道 ORA_DISK_1: 正在指定備份組中的資料檔案
輸入資料檔案 fno=00028 name=E:ORACLEORADATAORABD02TS_TEST01.DBF
通道 ORA_DISK_1: 備份組已完成, 經過時間:00:00:01
完成 backup 於 28-11月-04

注意:在rman validate操作期間會產生一些文本,看起來像是建立了一個備份組

但只是一個掃描錯誤的操作,在rman操作期間不會產生任何備份檔案片

RMAN>

SQL> select * from V$BACKUP_CORRUPTION;

     RECID      STAMP  SET_STAMP  SET_COUNT     PIECE#      FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# MARKED
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ------------
         1  543426383  543426382         31          1         28         20          1                  0 YES    FRACTURED

經過時間:  00: 00: 00.00
SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
---------- ---------- ---------- ------------------ ------------------
        28         20          1                  0 FRACTURED

經過時間:  00: 00: 00.00
SQL>
 
先看一下壞塊是在表上還是索引上吧。

SELECT segment_name,segment_type,extent_id,block_id, blocks
from dba_extents t
where file_id = 6
AND 187 between block_id and (block_id + blocks - 1) ;

運氣好,在索引上的話,直接重建就好了
例如:
我的資料庫出現ORA-01578錯誤:資料區塊損壞(檔案號8,塊號36385)

用以下語句查詢:
     SELECT segment_name,segment_type FROM dba_extents  WHERE file_id=8 AND 36385 BETWEEN block_id AND block_id + blocks -1;

結果為:
segment_name     segment_type
-----------------------     ------------------------
  PK_KC03                    INDEX

有的文章介紹說如果segment_type為INDEX的話,只要刪除該索引再重建即可
使用:
alter index pk_kc03 rebuild nologging;
or
alter index pk_kc03 rebuild


 dbms_repair.skip_corrupt_blocks過程設定表在讀取資料時,跳過壞塊
————————-——————————————————————————————————
 
 
 

四月 16 16:30:19 ur_bak01: NetWorker savegroup: (alert) urmdborafull completed, total 2 client(s), 0 Hostname(s) Unresolved, 1 Failed, 1 Succeeded. (ur_mdb01 Failed)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t2 channel at 03/20/2009 13:49:09
ORA-19566: exceeded limit of 0 corrupt blocks for file /dev/vg_mdb02/rdata_2g_050
ORA-000060: Deadlock detected. More info in file /oracle/app/oracle/admin/uradt/udump/uradt_ora_3035.trc.
***
Corrupt block relative dba: 0x1a43d4e3 (file 105, block 251107)
Fractured block found during backing up datafile
Data in bad block -
 type: 0 format: 0 rdba: 0x00000000
 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
 consistency value in tail: 0x00000000
 check value in block header: 0x0, block checksum disabled
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of blocknum=251107, file=/dev/vg_mdb02/rdata_2g_050. found same corrupt data
Thu Apr 16 16:31:04 2009
 
 


用dbv檢查發現有至少有45個壞塊:
 
[oracle@ur_mdb01 /oracle$]dbv file=/dev/vg_mdb02/rdata_2g_050 BLOCKSIZE=8192
 
DBVERIFY: Release 9.2.0.6.0 - Production on Mon Apr 20 09:55:07 2009
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = /dev/vg_mdb02/rdata_2g_050
Page 251107 is influx - most likely media corrupt
***
Corrupt block relative dba: 0x1a43d4e3 (file 105, block 251107)
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: 0x00000000
 check value in block header: 0x0, block checksum disabled
 spare1: 0x0, spare2: 0x0, spare3: 0x0
***
 
Page 251108 is marked corrupt
***
Corrupt block relative dba: 0x1a43d4e4 (file 105, block 251108)
Bad header found during dbv:
Data in bad block -
 type: 181 format: 6 rdba: 0x00000000
 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
 consistency value in tail: 0x00000000
 check value in block header: 0x0, block checksum disabled
 spare1: 0x7, spare2: 0xc, spare3: 0x0
***
 
……
 
Corrupt block relative dba: 0x1a43d56f (file 105, block 251247)
Bad header found during dbv:
Data in bad block -
 type: 65 format: 5 rdba: 0x527002c2
 last change scn: 0x3131.02063033 seq: 0x30 flg: 0x31
 consistency value in tail: 0x3635032d
 check value in block header: 0x180, block checksum disabled
 spare1: 0x50, spare2: 0x72, spare3: 0x430
***
 
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 262016
Total Pages Processed (Data) : 60240
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 568
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 201163
Total Pages Marked Corrupt   : 45
Total Pages Influx           : 11
Highest block SCN            : 10816042273 (2.2226107681)
 
 

經檢查,發現這些壞塊上沒有任何資料對象:
方法1.可以找到這個資料檔案所在的資料表空間,這個資料表空間下的所有對象:如果都是表,可以對這些表都做一次全部掃描,發現沒有報錯。如果都是索引,可以都走一次iff,沒有報錯的話,說明對象都不在壞塊上。

方法2.用
select * from dba_extents where file_id=壞塊file_id
and 壞塊block_id between block_id and block_id+blocks-1;
如果所有的壞塊執行這個sql檢查出來的結果都是返回0行,說明沒有對象在壞塊上。
 

我們用格式化的方式來清除這樣的壞塊:
--預估剩餘空間大小:

SQL> select tablespace_name,file_id,sum(bytes)/1024/1024 size_m from dba_free_space
  2  where file_id=105 group by tablespace_name,file_id;
 
TABLESPACE_NAME                   FILE_ID     SIZE_M
------------------------------ ---------- ----------
LOG_P8                                105       1643
 
SQL>
 

 
--建立一個表在這個資料表空間上,用於做資料區塊的格式化:

SQL> create table for_fix(n number,c varchar2(4000)) nologging tablespace LOG_P8;
 
Table created.
 
SQL>
SQL>
SQL>
 
--填充滿這個表:
SQL> alter table for_fix allocate extent(datafile '/dev/vg_mdb02/rdata_2g_050' size 1643m);
 
Table altered.
 
SQL>
SQL> insert into for_fix select rownum,rpad('dedwedew',3900) from dba_objects;
 
7285 rows created.
 
SQL> /
 
7285 rows created.
 
SQL> /
 
……
 
SQL>  insert into for_fix select * from for_fix where rownum<=1000000;
 
1000000 rows created.
 
Elapsed: 00:00:06.96
SQL> /
 
1000000 rows created.
 
Elapsed: 00:00:03.50
SQL> /
 
10000 rows created.
 
Elapsed: 00:00:14.03
……
 
SQL> insert into for_fix select * from for_fix where rownum<=50000;
 
50000 rows created.
 
Elapsed: 00:00:39.28
SQL>
SQL>
 
……
 
SQL> insert into for_fix select * from for_fix where rownum<=1;
 
1 row created.
 
Elapsed: 00:00:00.00
SQL> /
 
1 row created.
 
Elapsed: 00:00:00.00
SQL> /
 
1 row created.
 
Elapsed: 00:00:00.00
SQL> /
 
1 row created.
 
Elapsed: 00:00:00.00
SQL> /
 
1 row created.
 
Elapsed: 00:00:00.01
SQL> /
insert into for_fix select * from for_fix where rownum<=1
*
ERROR at line 1:
ORA-01653: unable to extend table SYS.FOR_FIX by 128 in tablespace LOG_P8
 
 
Elapsed: 00:00:00.00
SQL>
SQL>
SQL> commit;
 
Commit complete.
 
Elapsed: 00:00:00.07
SQL>
SQL>
 
--記住,這裡一定要做checkpoint,將所有的資料重新整理到資料檔案,不然不能保證所有的壞塊被格式化:

SQL> alter system checkpoint;
 
System altered.
 
Elapsed: 00:00:04.25
SQL> /
 
System altered.
 
Elapsed: 00:00:00.15
SQL> /
 
System altered.
 
Elapsed: 00:00:00.14

填充滿這個表後,所以的塊都被得到格式化,包括壞塊也被格式化了。此時我們用dbv再次檢查:
 
[oracle@ur_mdb01 /oracle$]
dbv file=/dev/vg_mdb02/rdata_2g_050 BLOCKSIZE=8192
 
DBVERIFY: Release 9.2.0.6.0 - Production on Mon Apr 20 13:30:43 2009
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = /dev/vg_mdb02/rdata_2g_050
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 262016
Total Pages Processed (Data) : 260715
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 1181
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 120
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 10816271785 (2.2226337193)
[oracle@ur_mdb01 /oracle$]

壞塊已經處理掉了,測試rman備份正常。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.