国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

實踐篇—壞塊處理方法

IT那活兒 / 2642人閱讀
實踐篇—壞塊處理方法
點擊上方“IT那活兒”，關注后了解更多精彩內容！！！
壞塊的原因


造成數據塊損壞的原因多種多樣，可是因為物理原因導致，也可能人為原因或Oracle bug導致。


壞塊的種類


物理壞塊（也可以稱為介質壞塊）指的是塊格式本身是壞的，塊內的數據沒有任何意義。

邏輯壞塊，指的是塊內的數據在邏輯是存在問題。(內容)


檢查機制


物理一致性檢查利用校驗和字段工作，主要側重于檢查硬件故障并不關心內容正確與否。

邏輯一致性檢查就是側重于內容的檢查，內容檢查要比校驗和檢查復雜的多。



避免壞塊


壞塊不能避免，只能盡量減少發生壞塊。                                                                


物理檢查參數

通過設置初始化參數db_block_checksum=typical/full/false來啟用、關閉物理一致性檢查，啟用該參數這會 增加1%～2%的負載，Oracle推薦啟用該參數。在Oracle9i、10g中,默認是啟用的。11g是typical。注意TRUE (implying TYPICAL)也就是說true<->typical。
在該參數設置為typical和full時，當讀入時候重新計算校驗和寫出時候的校驗對比，如果不同則認為是塊損壞。如果設置為FULL模式，則基于update/delete應用程序語句級別的改變發生后，校驗值會被重新計算并寫入。同時對于日志塊，在寫入之前，同樣會生產校 驗值并寫入到塊頭。該參數主要是防止IO硬件和IO子系統的錯誤。如果設置為OFF則只對系統表空間有效。
邏輯檢查參數

通過設置參數db_block_checking=true可以啟用數據塊的邏輯一致性檢查。啟用該參數這會 增加1%～10%的負載，尤其DML操作越密集性能影響越大。在Oracle10g中這個參數 默認值是false,這將意味這數據庫只對System表空間做邏輯一致性檢查。
模擬壞塊

物理壞快通過dd即可，邏輯壞塊需要通過bbed這些非oracle官方支持的工具模擬
此處模擬物理壞塊，注意，在沒有備份的情況下，物理壞塊基本無救，但是我們需要對壞塊進行跳過處理。（通過dul，bbed來恢復。）
>create tablespace crpt_ts datafile /u01/app/oracle/oradata/orcl/crpt_ts.dbf size 100M;
>create table scott.crpt tablespace crpt_ts as select * from dba_objects where rownum <3000;
> select distinct dbms_rowid.rowid_block_number(rowid) b_no ,dbms_rowid.rowid_relative_fno(rowid) f_no from scott.crpt order by 1;

      B_NO F_NO
---------- ----------
       131      7
       132      7
……………………省略……………………………..
       171      7

39 rows selected.
SYS@ orcl>select a.file_id,a.block_id,a.blocks,b.name from dba_extents a,v$datafile b where a.file_id=b.file# and a.owner=SCOTT and a.segment_name=CRPT order by a.block_id;

   FILE_ID BLOCK_ID BLOCKS NAME
---------- ---------- ---------- --------------------------------------------------
   7    128         8 /u01/app/oracle/oradata/orcl/crpt_ts.dbf
   7    136         8 /u01/app/oracle/oradata/orcl/crpt_ts.dbf
   7    144         8 /u01/app/oracle/oradata/orcl/crpt_ts.dbf
   7    152         8 /u01/app/oracle/oradata/orcl/crpt_ts.dbf
   7    160         8 /u01/app/oracle/oradata/orcl/crpt_ts.dbf
   7    168         8 /u01/app/oracle/oradata/orcl/crpt_ts.dbf
6 rows selected.
---破壞137,158 數據塊的內容
seek=n從輸出文件開頭跳過 n個blocks 個塊后再開始復制。
conv=notrunc不截短輸出文件
dd if=/dev/zero of=/u01/app/oracle/oradata/orcl/crpt_ts.dbf bs=8192 conv=notrunc seek=137 count=1
dd if=/dev/zero of=/u01/app/oracle/oradata/orcl/crpt_ts.dbf bs=8192 conv=notrunc seek=158 count=1
也可以這樣：
? dd of=/u01/app/oracle/oradata/orcl/crpt_ts.dbf bs=8192 conv=notrunc seek=158 <? > Corrupt me! 
> EOF


此時dbv命令已經可以檢查出兩個壞塊了：


[oracle@cuug101 script]$ dbv file=/u01/app/oracle/oradata/orcl/crpt_ts.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Tue May 15 16:25:24 2018

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
…………………省略………………….
Total Pages Empty            : 12629
Total Pages Marked Corrupt : 2
Highest block SCN            : 12592990 (0.12592990)


啟動數據庫已經發現無法對有壞塊的對象進行全表掃描：


SYS@ orcl>select count(*) from scott.crpt;
select count(*) from scott.crpt
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 7, block # 137)
ORA-01110: data file 7: /u01/app/oracle/oradata/orcl/crpt_ts.dbf


通過告警日志看出數據庫在file 7block 137中的checksum的值和讀取時重新計算的值已經不同，由于兩次checksum值不同（即異或結果為非0），說明數據塊被修改過，數據塊為壞塊(corruption)。

alert.log中的相關信息。
ORA-01578: ORACLE data block corrupted (file # 7, block # 137)
ORA-01110: data file 7: /u01/app/oracle/oradata/orcl/crpt_ts.dbf
Hex dump of (file 7, block 158) in trace file /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_259354/orcl_m000_5108_i259354_a.trc
Corrupt block relative dba: 0x01c0009e (file 7, block 158)
Completely zero block found during validation
SYS@ orcl>select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
7   137        1   0 ALL ZERO
7   158        1   0 ALL ZERO
解決，查看塊的對象，這里很明顯是個表對象，如果是索引可以重建，如果是表，則有可能會丟數據,
SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME
FROM DBA_EXTENTS A
WHERE FILE_ID = 7
AND 137 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
/

OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
------------------------------ -------------------- ------------------ ------------------------------
SCOTT CRPT TABLE        CRPT_TS
如果是表，則先進行修復塊，如果修復失敗，則可以通過設置事件跳過壞塊，然后在imp回去，我們用dbms_repair來跳過這個壞塊（實際上如果只是checksum壞了，可以修改checksum為正確的值。但實際情況下，checksum壞了往往意味著壞內的數據已經壞了，大多數情況下只能丟棄），exp和dbms_repair都只是跳過壞塊，但是還是數據丟失。如果有備份，則選擇用備份恢復，畢竟備份的數據沒有問題（沒有壞塊），如果沒備份，通過設置事件來在exp的過程中跳過壞塊導出表，在重新導入expdp 自動檢測到壞塊并跳過壞塊,注意expdp雖然可以跳過壞塊，但是如果壞的是段頭，則導出的數據失敗。
[oracle@cuug101 ~]$ exp system/oracle file=crpt.dmp tables=scott.crpt

[oracle@cuug101 ~]$ expdp system/oracle dumpfile=crpt.dmp tables=scott.crpt

Export: Release 11.2.0.4.0 - Production on Tue May 15 23:49:52 2018

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

. . exporting table                           TEST
EXP-00056: ORACLE error 1578 encountered
ORA-01578: ORACLE data block corrupted (file # 7, block # 137)
ORA-01110: data file 4: /u01/app/oracle/oradata/orcl/users01.dbf
Export terminated successfully with warnings.
SYS@ orcl>alter system  set events=10231 trace name context forever,level 10;
注意：導完以后別忘記關閉事件
alter system set events=10231 trace name context off;
System altered.
[oracle@cuug101 exp]$ expdp system/oracle dumpfile=crpt.dmp tables=scott.crpt
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "SCOTT"."CRPT"                              262.7 KB 2842 rows
Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
[oracle@cuug101 exp]$ impdp system/oracle dumpfile=crpt.dmp remap_table=scott.crpt:crpt1
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "SCOTT"."CRPT1"                           262.7 KB 2842 rows
注意原有的表空間里面對應的數據文件還是壞塊，此時 可以將導出的表空間的數據，通過remap_tablespace=crpt:crpt1-------------crpt1表空間需要先建立。
remap_schema=scott:scott1------------scott1用戶需要先建立。（當然了因為crpt的所有對象都屬于scott，所以只需要執行一個scott:scott1），如果還有其他用戶的表，可以remap_schema=scott:scott1,sun:sun1
這樣crpt1的數據就跟crpt一樣，直接刪除crpt表空間即可。
使用dbms_repair


SYS@ orcl>select table_name, skip_corrupt from dba_tables where table_name = CRPT AND owner=SCOTT;
TABLE_NAME SKIP_COR
------------------------------ --------
CRPT DISABLED


創建管理表


set serveroutput on
begin
dbms_repair.admin_tables (
table_name => REPAIR_TABLE,
table_type => dbms_repair.repair_table,
action => dbms_repair.create_action,
tablespace => CRPT_TS);
end;
/


檢查壞塊


declare

rpr_count int;
begin
rpr_count := 0;
dbms_repair.check_object (
schema_name => SCOTT,
object_name => CRPT,
repair_table_name => REPAIR_TABLE,
corrupt_count => rpr_count);
dbms_output.put_line(repair count:  || to_char(rpr_count));
end;
repair count:2


查看損壞塊的信息


SYS@ orcl>col object_name for a20
SYS@ orcl>col CORRUPT_DESCRIPTION for a50
SYS@ orcl>col REPAIR_DESCRIPTION for a40
SYS@ orcl>col CORRUPT_DESCRIPTION for a20
SYS@ orcl>select object_name, block_id, corrupt_type, marked_corrupt,corrupt_description,repair_description from repair_table;

OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR CORRUPT_DESCRIPTION REPAIR_DESCRIPTION
-------------------- ---------- ------------ ---------- -------------------- ----------------------------------------
CRPT 137 6148 TRUE      mark block software corrupt
CRPT 158 6148 TRUE      mark block software corrupt


1. 定位壞塊：只有將壞塊信息寫入定義的REPAIR_TABLE后，才能處理壞塊。


（skip/noskip） 

SYS@ orcl> declare
fix_count int;
begin
fix_count := 0;
dbms_repair.fix_corrupt_blocks (
schema_name => SCOTT,
object_name => CRPT,
object_type => dbms_repair.table_object,
repair_table_name => REPAIR_TABLE,
fix_count => fix_count);
dbms_output.put_line(fix count:  || to_char(fix_count));
end;
SYS@ orcl>/
fix count: 0

PL/SQL procedure successfully completed.
2. 跳過壞塊：我們前面雖然定位了壞塊，但是，如果我們訪問這個表還是會得到錯誤信息，所以需要skip處理。
begin
dbms_repair.skip_corrupt_blocks (
schema_name => SCOTT,
object_name => CRPT,
object_type => dbms_repair.table_object,
flags => dbms_repair.skip_flag);
end;
8     /

PL/SQL procedure successfully completed.

SYS@ orcl>select table_name, skip_corrupt from dba_tables where table_name = CRPT AND owner=SCOTT;

TABLE_NAME SKIP_COR
------------------------------ --------
CRPT ENABLED

select count(*) from crpt;


SYS@ orcl>select count(*) from scott.crpt;

COUNT(*)
----------
2842
3. rman中有blockrecover來恢復壞塊，但是如果沒有備份無法實現。
---使用rman檢查數據文件是否有壞塊
backup check logical validate datafile 500;

RMAN> backup check logical validate datafile 500;

Starting backup at 02-MAR-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=8190 instance=cxbdzxdb1 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=00500 name=+DG_DATA_SSD_2/CXBDZXDB/DATAFILE/tbs_index.257.1065130555
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:36
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
500  FAILED 0              145285       3932160         11215813018512
File Name: +DG_DATA_SSD_2/CXBDZXDB/DATAFILE/tbs_index.257.1065130555
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0              1657837
Index 1              2124520
Other 0              4518

validate found one or more corrupt blocks
See trace file /oracle/app/oracle/diag/rdbms/cxbdzxdb/cxbdzxdb1/trace/cxbdzxdb1_ora_35457316.trc for details
Finished backup at 02-MAR-21


--執行完成后執行


set line 300
select * from V$database_block_corruption;
SQL> set line 300
SQL> select * from V$database_block_corruption;
FILE#     BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE CON_ID
---------- ---------- ---------- ------------------ ------------------ ----------
500 1042393 1 1.1216E+13 CORRUPT 0


---查詢文件號對應的數據文件


select 
file_id,FILE_NAME,TABLESPACE_NAME,BYTES/1024/1024,STATUS,AUT
OEXTENSIBLE,ONLINE_STATUS from dba_data_files where 
file_id=856;
---查詢索引對應的table
set linesize 300
col owner for a30
col table_name for a30
col index_name for a30
col partitioned for a30
select owner,table_name,index_name,status,partitioned,uniqueness,tablespace_name from dba_indexes where  owner=POLICY and index_name=IDX_PLC_RATION_TOPID order by 3;
---讀取索引ddl語句
set long 3000
select 
dbms_metadata.get_ddl(INDEX,IDX_PLC_RATION_TOPID,POLICY
) a from dual;
-----重建索引
drop index policy.IDX_PLC_RATION_TOPID;
CREATE INDEX "POLICY"."IDX_PLC_RATION_TOPID" ON 
"POLICY"."PLC_RATION" ("TOPID") TABLESPACE "TBS_INDEX" 
parallel 12 ;
----壞塊查詢
4. 通過dbv和rman blockrecover對Oracle數據庫壞塊進行修復。
(1)rman備份時alert.log報如下錯誤：
Fri Jul 2 12:41:36 2010
Hex dump of (file 12, block 2718618) in trace file /u01/app/oracle/admin/bi/udump/bi_ora_31213.trc
Corrupt block relative dba: 0x03297b9a (file 12, block 2718618)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x03297b9a
last change scn: 0x0002.482fc15b seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x77b20601
check value in block header: 0x253
computed block checksum: 0xb6e9
Reread of blocknum=2718618, file=/u01/oradata/BI/estaging_user01.712.714072365. found same corrupt data
Reread of blocknum=2718618, file=/u01/oradata/BI/estaging_user01.712.714072365. found same corrupt data
Reread of blocknum=2718618, file=/u01/oradata/BI/estaging_user01.712.714072365. found same corrupt data
Reread of blocknum=2718618, file=/u01/oradata/BI/estaging_user01.712.714072365. found same corrupt data
Reread of blocknum=2718618, file=/u01/oradata/BI/estaging_user01.712.714072365. found same corrupt data


(2)查詢數據庫，可知含有壞塊的對象：


SQL> col SEGMENT_NAME format a20
col PARTITION_NAME format a10
select owner,segment_name,partition_name from dba_extents where file_id = 12 and 2718618 between block_id and block_id + blocks-1;
OWNER SEGMENT_NAME PARTITION_
-------------------- -------------------- ----------
ESTAGING LOG_RECORD_DETAIL_4 P20100630


(3)但全表掃描卻沒有任何問題：


SQL> select count(*) from ESTAGING.LOG_RECORD_DETAIL_4 partition (P20100630)；
COUNT(*)
----------
449937
SQL> select count(*) from ESTAGING.LOG_RECORD_DETAIL_4;
COUNT(*)
----------
42049608


(4)使用dbv檢查發現有一個壞塊(耗時較長)：


$ dbv file=/u01/oradata/BI/estaging_user01.712.714072365 BLOCKSIZE=8192
DBVERIFY: Release 10.2.0.4.0 - Production on Fri Jul 2 14:15:49 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oradata/BI/estaging_user01.712.714072365
Page 2718618 is influx - most likely media corrupt
Corrupt block relative dba: 0x03297b9a (file 12, block 2718618)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x03297b9a
last change scn: 0x0002.482fc15b seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x77b20601
check value in block header: 0x253
computed block checksum: 0xb6e9
DBVERIFY - Verification complete
Total Pages Examined : 2748160
Total Pages Processed (Data) : 2462446
Total Pages Failing (Data) : 0
Total Pages Processed (Index)：235234
Total Pages Failing (Index)：0
Total Pages Processed (Other)：24969
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 25510
Total Pages Marked Corrupt : 1
Total Pages Influx : 1
Highest block SCN : 1229607770 (2.1229607770)


(5)使用rman檢查含有壞塊的數據文件(耗時較長)，， 期間觀察alert.log會發現同樣的提示：


RMAN> backup validate datafile 12;
這個時候訪問v$database_block_corruption可以看到詳細的壞塊的信息：
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
12 2718618 1 0 FRACTURED
(6)使用rman進行塊恢復：
RMAN> blockrecover datafile 12 block 2718618 from backupset;
(7)塊恢復后，執行BLOCKRECOVER CORRUPTION LIST，會自動按照V$DATABASE_BLOCK_CORRUPTION進行修復(耗時較長)：
RMAN> BLOCKRECOVER CORRUPTION LIST;
(8)這個時候再訪問v$database_block_corruption就看不到詳細的壞塊信息了：
SQL> select * from v$database_block_corruption;
no rows selected


(9)再使用dbv檢查發現沒有壞塊了(耗時較長)：


$ dbv file=/u01/oradata/BI/estaging_user01.712.714072365 BLOCKSIZE=8192
DBVERIFY: Release 10.2.0.4.0 - Production on Fri Jul 2 15:38:15 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oradata/BI/estaging_user01.712.714072365
DBVERIFY - Verification complete
Total Pages Examined : 2749440
Total Pages Processed (Data) : 2463763
Total Pages Failing (Data) : 0
Total Pages Processed (Index)：235250
Total Pages Failing (Index)：0
Total Pages Processed (Other)：24981
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 25446
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Highest block SCN : 1230819157 (2.1230819157)


注意如果沒有rman的備份，無法執行上面的語句，退一步講，如果這是你有手工的熱備，可以將熱備catalog datafilecopy xxxxxx;轉換成一個rman備份。

然后也可以用blockrecover了。

本 文 原 創 來 源：IT那活兒微信公眾號（上海新炬王翦團隊）

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129729.html

相關文章

  • 微軟為OCP計算項目推出云SSD存儲新規范

    摘要：微軟正在繼續向提交潛在的新規范。微軟方面表示，預計在未來幾個月內完成規范，并在今年晚些時候推出。此外，微軟還在推進另一個開放計算貢獻的項目。去年年底，微軟推出了加密微控制器標準。微軟正在繼續向Open Compute Project提交潛在的新規范。在美國圣何塞舉行的Open Compute Project（OCP）美國峰會上，微軟推出了Project Denali，一項用于SSD固件接口標...

    mmy123456 評論0 收藏0

  • Java異常處理 10 個最佳實踐

    摘要：為可恢復的錯誤使用檢查型異常，為編程錯誤使用非檢查型錯誤。檢查型異常保證你對錯誤條件提供異常處理代碼，這是一種從語言到強制你編寫健壯的代碼的一種方式，但同時會引入大量雜亂的代碼并導致其不可讀。在編程中選擇檢查型異常還是運行時異常。 異常處理是Java 開發中的一個重要部分。它是關乎每個應用的一個非功能性需求，是為了處理任何錯誤狀況，比如資源不可訪問，非法輸入，空輸入等等。Java提供了...

    Forelax 評論0 收藏0

  • Java 異常處理的 9 個最佳實踐

    摘要：異常處理的個最佳實踐原文地址翻譯出處在中，異常處理是個很麻煩的事情。使用描述性消息拋出異常這個最佳實踐背后的想法與前兩個類似。當你以錯誤的格式提供時，它將被類的構造函數拋出。類提供了特殊的構造函數方法，它接受一個作為參數。 Java 異常處理的 9 個最佳實踐 原文地址：https://dzone.com/articles/9-...翻譯出處：https://www.oschina.n...

    sihai 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<