溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

如何處理oracle中出現(xiàn)的壞塊

發(fā)布時(shí)間:2021-11-10 13:55:43 來(lái)源:億速云 閱讀:198 作者:小新 欄目:關(guān)系型數(shù)據(jù)庫(kù)

這篇文章主要為大家展示了“如何處理oracle中出現(xiàn)的壞塊”,內(nèi)容簡(jiǎn)而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“如何處理oracle中出現(xiàn)的壞塊”這篇文章吧。

在oracle數(shù)據(jù)文件中出現(xiàn)一個(gè)或多個(gè)數(shù)據(jù)塊壞塊時(shí)的處理方法.當(dāng)出現(xiàn)數(shù)據(jù)塊壞塊出誤時(shí)對(duì)于每一個(gè)壞塊都提供了以下信息:
1.包含這個(gè)壞塊的數(shù)據(jù)文件的絕對(duì)文件號(hào)可以標(biāo)示為"AFN".
2.包含這個(gè)壞塊的數(shù)據(jù)文件的文件名可以標(biāo)示為"FILENAME"(如果知道文件號(hào)但不知道文件名那么可以執(zhí)行select name from v$datafile where file#=&AFN來(lái)得到文件名,如果文件號(hào)在v$datafile中沒(méi)有記錄且AFN比參數(shù)db_files參數(shù)的值還大那么這個(gè)文件可能是臨時(shí)文件.如果是這種情況可以執(zhí)行select name from v$tempfile where file#=(&AFN-&DB_FILES_value)
3.數(shù)據(jù)文件中壞塊的塊號(hào)可以標(biāo)示為"BL"
4.受壞塊影響的表空間號(hào)和表空間名稱(chēng)可以標(biāo)示為"TSN"和"TABLESPACE_NAME".可以執(zhí)行select ts# "TSN" from v$datafile where file#=&AFN;select tablespace_name from dba_data_files where file_id=&AFN來(lái)查詢.
5.出現(xiàn)壞塊的表空間的數(shù)據(jù)塊大小可以標(biāo)示為"TS_BLOCK_SIZE".對(duì)于oracle9i來(lái)說(shuō)可以執(zhí)行select block_size from dba_tablespace where tablespace_name=(select tablespace_name from dba_data_files where file_id=&AFN);來(lái)查詢數(shù)據(jù)塊大小.對(duì)于oracle7.8.0和8.1在數(shù)據(jù)庫(kù)中每一個(gè)表空間都有相同的數(shù)據(jù)塊大小.對(duì)于這些版本可以使用show parameter db_block_size來(lái)顯示數(shù)據(jù)塊大小.

例如:ora-1578錯(cuò)識(shí)信息
ORA-01578: ORACLE data block corrupted (file # 7, block # 12698)
ORA-01110: data file 22: /oracle1/oradata/V816/oradata/V816/users01.dbf
從上面的錯(cuò)識(shí)信息可知:絕對(duì)文件號(hào)AFN是22,相對(duì)文件號(hào)RFN是7,數(shù)據(jù)塊BL是12698,文件名FILENAME是/oracle1/oradata/V816/oradata/V816/users01.dbf,表空間號(hào)和表空間名可以用上面的查詢得到.

處理壞塊的步驟
導(dǎo)致壞塊的原因有許多種例如:
壞的 IO 硬件/固件
OS 問(wèn)題
Oracle 問(wèn)題
對(duì)于執(zhí)行過(guò)“UNRECOVERABLE”或“NOLOGGING”操作的數(shù)據(jù)庫(kù)進(jìn)行恢復(fù)在這種情況下可能產(chǎn)生 ORA-1578 錯(cuò)誤

在遇到壞塊時(shí),我們通常無(wú)從了解根本原因,并且在大多數(shù)情況下,當(dāng)前最迫切的是重新啟動(dòng)數(shù)據(jù)庫(kù)并使其運(yùn)行起來(lái).
1. 確定壞塊問(wèn)題的范圍,并確定這些問(wèn)題是持久性問(wèn)題還是暫時(shí)性問(wèn)題
如果問(wèn)題涉及范圍很大,或錯(cuò)誤不穩(wěn)定,則關(guān)鍵在于先識(shí)別原因(檢查硬件等).這點(diǎn)很重要.因?yàn)槿绻堑讓佑布霈F(xiàn)錯(cuò)誤.恢復(fù)系統(tǒng)便毫無(wú)意義

2.更換或拆下任何有問(wèn)題的或可疑的硬件

3.確定受到影響的數(shù)據(jù)庫(kù)對(duì)象有哪些

4.選擇最合適的數(shù)據(jù)庫(kù)恢復(fù)/數(shù)據(jù)搶救選項(xiàng)

確定壞塊問(wèn)題的范圍
每次發(fā)生壞塊錯(cuò)誤時(shí),都應(yīng)記下完整的錯(cuò)誤消息,并查看該實(shí)例的告警日志和跟蹤文件,以了解任何相關(guān)的錯(cuò)誤.首先進(jìn)行這些步驟非常重要,這可以評(píng)估該損壞是單個(gè)塊,還是由于UNRECOVERABLE操作產(chǎn)生的錯(cuò)誤,或是更嚴(yán)重的問(wèn)題.

使用DBVERIFY掃描受影響的文件以及一切重要的文件也是不錯(cuò)的辦法,這樣可以檢查是否有其他壞塊,從而確定問(wèn)題的范圍.一旦確定了損壞的文件/塊組合列表,即可使用以下步驟來(lái)幫助確定應(yīng)采取何種措施:
1.完整記錄初始錯(cuò)誤,以及發(fā)生錯(cuò)誤的應(yīng)用程序的詳細(xì)信息
2.及時(shí)地保存從告警日志中首次 (FIRST) 記錄到問(wèn)題前數(shù)小時(shí)到當(dāng)前時(shí)間點(diǎn)所提取的內(nèi)容
3.保存告警日志中提到的任何跟蹤文件
4.記錄最近遇到的任何 OS 問(wèn)題
5.記錄是否正在使用任何特殊功能,例如:ASYNC IO、快速寫(xiě)入磁盤(pán)選項(xiàng)等
6.記錄當(dāng)前的備份位置(日期、類(lèi)型等)
7.記錄數(shù)據(jù)庫(kù)是否處于ARCHIVELOG 模式,例如:在SQL*Plus(或 Server Manager)中運(yùn)行“ARCHIVE LOG LIST”

更換或拆下可疑硬件
大多數(shù)壞塊問(wèn)題是由故障硬件導(dǎo)致的.如果出現(xiàn)硬件錯(cuò)誤或可疑組件,最好進(jìn)行修復(fù),或者在執(zhí)行恢復(fù)操作之前,確保在單獨(dú)的磁盤(pán)子系統(tǒng)上有足夠的可用空間用于恢復(fù),您可以使用以下步驟移動(dòng)數(shù)據(jù)文件:
1.確保要遷移的文件已離線或數(shù)據(jù)庫(kù)實(shí)例處于 MOUNT 狀態(tài)(未打開(kāi))
2. 將該數(shù)據(jù)文件物理還原(或復(fù)制)到新位置 例如:/newlocation/myfile.dbf
3.將該文件的新位置告知 Oracle.
例如:ALTER DATABASE RENAME FILE '/oldlocation/myfile.dbf' TO '/newlocation/myfile.dbf';
(請(qǐng)注意,您不能對(duì)臨時(shí)文件進(jìn)行重命名,而應(yīng)刪除臨時(shí)文件并在新位置重新創(chuàng)建)
4.使相關(guān)數(shù)據(jù)文件/表空間上線(如果數(shù)據(jù)庫(kù)已打開(kāi))

注意:
如果存在多個(gè)錯(cuò)誤(不是由于 NOLOGGING操作導(dǎo)致的)或受影響文件所在的OS層面出現(xiàn)錯(cuò)誤或錯(cuò)誤是暫時(shí)性的且游離不定,那么,如果不解決底層問(wèn)題或準(zhǔn)備另外的磁盤(pán)空間,那么進(jìn)行任何操作都是毫無(wú)意義的.

如果使用了任何特殊IO選項(xiàng),例如direct IO,async IO或類(lèi)似的選項(xiàng),最好將其禁用,以消除這些選項(xiàng)成為潛在問(wèn)題原因的可能性

確定受影響的對(duì)象有哪些
在決定如何恢復(fù)之前,最好先確定哪些對(duì)象受到了影響,因?yàn)閴膲K可能發(fā)生在那些容易被重新創(chuàng)建的對(duì)象中.例如,對(duì)于只有5行數(shù)據(jù)的表中發(fā)生的壞塊,刪除并重新創(chuàng)建表可能要比執(zhí)行恢復(fù)快得多.

對(duì)于每個(gè)壞塊,請(qǐng)收集下表中的信息.進(jìn)行此操作的步驟如下所述。
1.初始錯(cuò)誤
2.絕對(duì)文件號(hào)AFN
3.相關(guān)文件號(hào)RFN
4.塊編號(hào)BL
5.表空間
6.段類(lèi)型
7.段所有者.名稱(chēng)
8.相關(guān)對(duì)象
9.恢復(fù)選項(xiàng)

在Oracle8/8i/9i/10g中;絕對(duì)文件號(hào)和相關(guān)文件號(hào)通常是一樣的,但也可能不同(尤其是在數(shù)據(jù)庫(kù)是由Oracle7遷移而來(lái)的情況下).要獲得正確的AFN和RFN編號(hào),否則您可能最終搶救的是錯(cuò)誤的對(duì)象.

下列查詢將顯示數(shù)據(jù)庫(kù)中數(shù)據(jù)文件的絕對(duì)和相關(guān)文件號(hào):
SELECT tablespace_name, file_id "AFN", relative_fno "RFN" FROM dba_data_files;

在Oracle8i/9i/10g中:除了上述關(guān)于Oracle8 的說(shuō)明外,從 Oracle8i開(kāi)始將擁有臨時(shí)文件.下列查詢將顯示數(shù)據(jù)庫(kù)中臨時(shí)文件的絕對(duì)和相關(guān)文件號(hào):
SELECT tablespace_name, file_id+value "AFN", relative_fno "RFN"
FROM dba_temp_files, v$parameter WHERE name='db_files';

在Oracle7中:“絕對(duì)文件號(hào)”和“相關(guān)文件號(hào)”使用相同的文件號(hào)

“段類(lèi)型”,“所有者”,“名稱(chēng)”和“表空間”
在給定壞塊的絕對(duì)文件號(hào)“&AFN”和塊編號(hào)“&BL”的情況下,下列查詢將顯示對(duì)象的段類(lèi)型,所有者和名稱(chēng),數(shù)據(jù)庫(kù)必須打開(kāi)才能使用此查詢:
SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = &AFN
and &BL between block_id AND block_id + blocks - 1;

如果壞塊位于臨時(shí)文件中,則上述查詢將不會(huì)返回任何數(shù)據(jù),對(duì)于臨時(shí)文件,“段類(lèi)型”應(yīng)為“TEMPORARY”

如果上述查詢未返回行,也可能是因?yàn)閴膲K是本地管理表空間 (Locally Managed Tablespace, LMT)中的段頭.當(dāng)壞塊為L(zhǎng)MT中的段頭塊時(shí),上述查詢將在alert.log 中生成一個(gè)壞塊消息,但查詢不會(huì)失敗.在這種情況下,請(qǐng)使用以下查詢:
SELECT owner, segment_name, segment_type, partition_name
FROM dba_segments
WHERE header_file = &AFN and header_block = &BL;

按段類(lèi)型分類(lèi)的“相關(guān)對(duì)象”和可能的“恢復(fù)選項(xiàng)”:
相關(guān)對(duì)象和能夠使用的恢復(fù)選項(xiàng)取決于SEGMENT_TYPE.對(duì)于各種最常見(jiàn)的段類(lèi)型,其他查詢和可能的恢復(fù)選項(xiàng)如下所示:
CACHE
如果段類(lèi)型為 CACHE,請(qǐng)?jiān)俅螜z查您是否輸入了正確的 SQL語(yǔ)句 和參數(shù)。
恢復(fù)選項(xiàng):可能需要恢復(fù)數(shù)據(jù)庫(kù)。

CLUSTER
如果段類(lèi)型為 CLUSTER,則應(yīng)確定它包含哪些表。
例如:
SELECT owner, table_name
FROM dba_tables
WHERE owner='&OWNER'
AND cluster_name='&SEGMENT_NAME';

恢復(fù)選項(xiàng):
如果所有者為“SYS”可能需要恢復(fù)數(shù)據(jù)庫(kù)。

對(duì)于非數(shù)據(jù)字典cluster,可能的選項(xiàng)包括:
恢復(fù)或 搶救cluster中所有表的數(shù)據(jù),然后重新創(chuàng)建cluster及其所有表,
cluster可能包含多個(gè)表,因此在做出決策之前,最好先收集cluster中每個(gè)表的信息。

INDEX PARTITION
如果段類(lèi)型為INDEX PARTITION,請(qǐng)記錄名稱(chēng)和所有者,然后確定哪些分區(qū)受到影響:
SELECT partition_name
FROM dba_extents
WHERE file_id = &AFN
AND &BL BETWEEN block_id AND block_id + blocks - 1;
然后按照處理INDEX段的步驟繼續(xù)下面的操作.
恢復(fù)選項(xiàng):
使用下列語(yǔ)句可以重建索引分區(qū):
ALTER INDEX xxx REBUILD PARTITION ppp;

INDEX
如果段類(lèi)型為INDEX,對(duì)于非字典INDEX或INDEX PARTITION,確定索引位于哪個(gè)表中:
例如:
SELECT table_owner, table_name
FROM dba_indexes
WHERE owner='&OWNER'
AND index_name='&SEGMENT_NAME';
并確定索引是否支持約束:
例如:
SELECT owner, constraint_name, constraint_type, table_name
FROM dba_constraints
WHERE owner='&TABLE_OWNER'
AND constraint_name='&INDEX_NAME';

CONSTRAINT_TYPE 的可能值包括:
P 索引支持主鍵約束。
U 索引支持唯一約束。
如果索引支持主鍵約束(類(lèi)型“P”),則確認(rèn)主鍵是否被任何外鍵約束引用:
例如:
SELECT owner, constraint_name, constraint_type, table_name
FROM dba_constraints
WHERE r_owner='&TABLE_OWNER'
AND r_constraint_name='&INDEX_NAME'
選項(xiàng):
如果所有者為“SYS”,可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典索引,可能的選項(xiàng)包括:
恢復(fù)或 重建索引(任何相關(guān)聯(lián)的約束會(huì)隨之禁用/啟用)

ROLLBACK
如果段類(lèi)型為ROLLBACK,因?yàn)?ROLLBACK 段壞塊需要特殊處理。
選項(xiàng)可能需要恢復(fù)數(shù)據(jù)庫(kù)。

TYPE2 UNDO
TYPE2 UNDO 是系統(tǒng)管理的undo段,它是 rollback段的一種特殊形式.這些段的壞塊需要特殊處理.
選項(xiàng)可能需要恢復(fù)數(shù)據(jù)庫(kù)。

TABLE PARTITION
如果段類(lèi)型為T(mén)ABLE PARTITION,請(qǐng)記錄名稱(chēng)和所有者,然后確定哪些分區(qū)受到影響:
SELECT partition_name
FROM dba_extents
WHERE file_id = &AFN
AND &BL BETWEEN block_id AND block_id + blocks - 1;
然后按照處理TABLE段的步驟繼續(xù)下面的操作.
選項(xiàng):
如果所有壞塊均位于同一個(gè)分區(qū),則此時(shí)可以采取的一個(gè)做法是用一個(gè)空表EXCHANGE壞塊所在的分區(qū),這可以讓?xiě)?yīng)用程序繼續(xù)運(yùn)行(無(wú)法訪問(wèn)壞塊所在的分區(qū)中的數(shù)據(jù)),然后可以從之前的空表中提取任何未損壞的數(shù)據(jù)

TABLE
如果所有者為“SYS”,可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典 TABLE 或 TABLE PARTITION,確定表中存在哪些索引:
例如:
SELECT owner, index_name, index_type
FROM dba_indexes
WHERE table_owner='&OWNER' AND table_name='&SEGMENT_NAME';
并確定表中是否存在任何主鍵:
例如:SELECT owner, constraint_name, constraint_type, table_name
FROM dba_constraints
WHERE owner='&OWNER'
AND table_name='&SEGMENT_NAME' AND constraint_type='P';
如果存在主鍵,則確認(rèn)它是否被任何外鍵約束引用:
例如:
SELECT owner, constraint_name, constraint_type, table_name
FROM dba_constraints
WHERE r_owner='&OWNER'
AND r_constraint_name='&CONSTRAINT_NAME';
選項(xiàng):
如果所有者為“SYS”,可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典表,可能的選項(xiàng)包括:
恢復(fù)或 搶救表(或分區(qū))中的數(shù)據(jù),然后重新創(chuàng)建表(或分區(qū))或忽略壞塊(例如:使用DBMS_REPAIR標(biāo)記需要跳過(guò)的問(wèn)題塊)

IOT(索引組織表)
IOT 表中的壞塊應(yīng)按照表或分區(qū)表中的處理方式來(lái)處理。
唯一的例外是如果 PK 損壞。
IOT表的PK就是表本身它不能被刪除和重新創(chuàng)建
選項(xiàng):
如果所有者為“SYS”,可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典表,可能的選項(xiàng)包括:
恢復(fù)或 搶救表(或分區(qū))中的數(shù)據(jù),然后重新創(chuàng)建表(或分區(qū))或忽略壞塊(DBMS_REPAIR不適用于IOT)

LOBINDEX
確定LOB屬于哪個(gè)表:
SELECT table_name, column_name
FROM dba_lobs
WHERE owner='&OWNER' AND index_name='&SEGMENT_NAME';
如果表的所有者為“SYS”可能需要恢復(fù)數(shù)據(jù)庫(kù)。
不可以重建 LOB 索引,因此您必須將該問(wèn)題作為受影響的表中LOB列上的壞塊來(lái)處理。
選項(xiàng):
如果所有者為“SYS”可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典表,可能的選項(xiàng)包括:
恢復(fù)或 搶救表(及其 LOB 列)中的數(shù)據(jù),然后重新創(chuàng)建表,忽略壞塊的做法通常不可取,除非不大可能對(duì)表中的問(wèn)題列執(zhí)行任何進(jìn)一步的 DML 操作。

LOBSEGMENT
確定 LOB 屬于哪個(gè)表:
例如:
SELECT table_name, column_name
FROM dba_lobs
WHERE owner='&OWNER'
AND segment_name='&SEGMENT_NAME';
如果表的所有者為“SYS”,可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典表,要查找引用損壞的 LOB 塊的具體行可能比較困難,因?yàn)閳?bào)告的錯(cuò)誤中不會(huì)顯示表中的哪一行數(shù)據(jù)包含損壞的 LOB 數(shù)據(jù)。
通??梢詤⒖及l(fā)生該錯(cuò)誤的應(yīng)用程序日志、任何SQL_TRACE、會(huì)話的10046 跟蹤文件(如果有),或通過(guò)在會(huì)話中設(shè)置事件“1578 trace name errorstack level 3”,查看是否有助于標(biāo)識(shí)當(dāng)前的 SQL/綁定/行。
例如:
ALTER SYSTEM SET EVENTS '1578 trace name errorstack level 3';
然后等待應(yīng)用程序觸發(fā)該錯(cuò)誤,并查找跟蹤文件。
如果沒(méi)有任何線索,您可以構(gòu)建 PLSQL 塊,逐行掃描問(wèn)題表以提取 LOB 列數(shù)據(jù),掃描將一直循環(huán)進(jìn)行,直至發(fā)生錯(cuò)誤。此方法可能需要一段時(shí)間,但它應(yīng)該可以找到引用了損壞的 LOB 塊的數(shù)據(jù)行的主鍵或 ROWID。
例如:
set serverout on
exec dbms_output.enable(100000);
declare
error_1578 exception;
pragma exception_init(error_1578,-1578);
n number;
cnt number:=0;
badcnt number:=0;
begin
for cursor_lob in (select rowid r, &LOB_COLUMN_NAME L
from &OWNER .. &TABLE_NAME) loop
begin
n := dbms_lob.instr(cursor_lob.L, hextoraw('AA25889911'), 1, 999999);
exception
when error_1578 then
dbms_output.put_line('Got ORA-1578 reading LOB at ' ||
cursor_lob.R);
badcnt := badcnt + 1;
end;
cnt := cnt + 1;
end loop;
dbms_output.put_line('Scanned ' || cnt || ' rows - saw ' || badcnt ||
' errors');
end;
/
損壞的 LOB 塊可能僅顯示為舊版本(為保證一致性讀?。?且該塊未被重新使用,在這種情況下,所有表中所有行都可以訪問(wèn),但一旦該塊被回收重新使用,就不可以插入/更新 LOB 列了。
選項(xiàng):
如果所有者為“SYS”,可能需要恢復(fù)數(shù)據(jù)庫(kù)。
對(duì)于非字典表,可能的選項(xiàng)包括:
恢復(fù)或搶救表(及其 LOB 列)中的數(shù)據(jù),然后重新創(chuàng)建表或忽略壞塊(不可以在 LOB 段上使用 DBMS_REPAIR)

TEMPORARY
如果段類(lèi)型為T(mén)EMPORARY,則壞塊不會(huì)影響永久對(duì)象.檢查發(fā)生問(wèn)題的表空間是否正在被用作TEMPORARY表空間:
SELECT count(*) FROM dba_users
WHERE temporary_tablespace='&TABLESPACE_NAME';
選項(xiàng):
如果是 TEMPORARY_TABLESPACE,則可能可以創(chuàng)建新的臨時(shí)表空間,并將所有用戶切換到該表空間,然后刪除有問(wèn)題的表空間。
如果不是臨時(shí)表空間,則該塊不會(huì)再被讀取,而且會(huì)在下次使用時(shí)被重新格式化 — 如果問(wèn)題的根本原因已經(jīng)得到解決,則不應(yīng)再發(fā)生該錯(cuò)誤。
通常情況下,不需要進(jìn)行任何還原,但如果磁盤(pán)可能有問(wèn)題,且表空間包含有用數(shù)據(jù),則最好對(duì)數(shù)據(jù)庫(kù)中受影響的文件進(jìn)行恢復(fù)

“無(wú)返回行”
如果沒(méi)有包含壞塊的extent,則首先再次檢查查詢中使用的參數(shù).如果您確定文件號(hào)和塊編號(hào)是正確的,且不屬于 DBA_EXTENTS 中的某個(gè)對(duì)象,則執(zhí)行以下操作:
再次檢查相關(guān)文件是否為臨時(shí)文件。請(qǐng)注意,臨時(shí)文件的文件號(hào)取決于數(shù)據(jù)庫(kù)初始化參數(shù) DB_FILES,因此對(duì)該參數(shù)的任何更改都會(huì)改變錯(cuò)誤中報(bào)告的絕對(duì)文件號(hào)。

DBA_EXTENTS 不包含本地管理表空間中用于本地空間管理的塊

如果您在數(shù)據(jù)庫(kù)運(yùn)行查詢語(yǔ)句的時(shí)間點(diǎn)與出錯(cuò)的時(shí)間點(diǎn)不相同,那么問(wèn)題對(duì)象可能已經(jīng)被刪除,因此針對(duì) DBA_EXTENTS 的查詢可能不會(huì)顯示任何行。

如果您正在調(diào)查的錯(cuò)誤由 DBVERIFY 報(bào)告,則 DBV 將檢查所有塊,而不管它們是否屬于某個(gè)對(duì)象。因此,壞塊可能存在于數(shù)據(jù)文件中,但卻未被任何對(duì)象使用。
選項(xiàng):
未使用的 Oracle 塊上的錯(cuò)誤可以忽略,因?yàn)槿绻枰褂迷搲K,Oracle 會(huì)創(chuàng)建新的塊映像(格式化),因此,該塊上的任何問(wèn)題將永不會(huì)被讀取。
如果您懷疑該塊可能是空間管理塊,則可以使用 DBMS_SPACE_ADMIN 包來(lái)幫助您進(jìn)行檢查:
exec DBMS_SPACE_ADMIN.TABLESPACE_VERIFY('&TABLESPACE_NAME');
以上命令會(huì)將不一致寫(xiě)入跟蹤文件,但如果遇到致命的壞塊,它將報(bào)告如下錯(cuò)誤:
ORA-03216: Tablespace/Segment Verification cannot proceed
位圖空間管理塊上發(fā)生的錯(cuò)誤通??梢酝ㄟ^(guò)運(yùn)行以下命令來(lái)修正:
exec DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS('&TABLESPACE_NAME');
對(duì)于每個(gè)壞塊,如果需要嘗試并確定實(shí)際壞塊原因,則收集如下物理證據(jù)也是一個(gè)比較好的方法:
i) 壞塊及位于其任意一側(cè)的塊的操作系統(tǒng) HEX 轉(zhuǎn)儲(chǔ)。
在 UNIX 上:
dd if=&FILENAME bs=&TS_BLOCK_SIZE skip=&BL-1 count=3 of=BL.dd
例如:對(duì)于BL=1224:
dd if=ts11.dbf bs=4k skip=1223 count=3 of=1223_1225.dd
在 VMS 上:
其中 XXXX=操作系統(tǒng)塊編號(hào)(512 字節(jié)塊中)
要計(jì)算此值,用報(bào)告的塊編號(hào)乘以“&TS_BLOCK_SIZE/512”。

ii) 處于 ARCHIVELOG 模式時(shí),復(fù)制出錯(cuò)時(shí)間前后的歸檔日志文件的安全副本,最好包括報(bào)告錯(cuò)誤前數(shù)小時(shí)的日志文件。并且,保存問(wèn)題數(shù)據(jù)文件在出錯(cuò)前的所有副本,因?yàn)橹暗臄?shù)據(jù)文件映像以及 redo 記錄有助于找出錯(cuò)誤原因DBV 通??捎糜跈z查問(wèn)題是否存在于文件的備份副本中).理想的情況是獲得沒(méi)有報(bào)告壞塊的數(shù)據(jù)文件備份映像,以及從該時(shí)間點(diǎn)開(kāi)始到首次報(bào)告壞塊時(shí)間之后不久的時(shí)段內(nèi)的所有 redo 記錄。

iii) 獲得問(wèn)題塊的 Oracle 轉(zhuǎn)儲(chǔ):
ALTER SYSTEM DUMP DATAFILE '&FILENAME' BLOCK &BL;

(4) 選擇恢復(fù)選項(xiàng)

現(xiàn)在,最佳的恢復(fù)選項(xiàng)取決于受影響的對(duì)象。前面第 (3) 部分中的說(shuō)明應(yīng)該已經(jīng)重點(diǎn)介紹了針對(duì)每個(gè)受影響對(duì)象的主要可用選項(xiàng)。選擇的實(shí)際恢復(fù)方法可能包含以下一種或多種混合方法:
是否需要進(jìn)行任何恢復(fù)操作?
如果錯(cuò)誤發(fā)生在TEMPORARY 表空間中,或位于不再屬于任何數(shù)據(jù)庫(kù)對(duì)象的塊中,則無(wú)需進(jìn)行任何操作.

可以使用完全恢復(fù)嗎?
要選用完全恢復(fù),必須滿足如下條件:
數(shù)據(jù)庫(kù)處于 ARCHIVELOG 模式(“ARCHIVE LOG LIST”命令顯示 Archivelog模式)

擁有受影響文件的完好備份。請(qǐng)注意,在某些情況下,壞塊可能已經(jīng)存在,但在很長(zhǎng)一段時(shí)間內(nèi)未被發(fā)現(xiàn)。如果最近的數(shù)據(jù)文件備份仍包含壞塊,那么只要您擁有所有必需的歸檔日志,就可以嘗試使用更早的備份。
(通??梢允褂?DBV START= / END= 選項(xiàng)來(lái)檢查位于某個(gè)備份文件的恢復(fù)副本中的特定塊是否損壞)

從備份時(shí)間開(kāi)始到當(dāng)前時(shí)間點(diǎn)的所有歸檔日志均可用

當(dāng)前的在線日志均可用且完好無(wú)缺

錯(cuò)誤不是由運(yùn)行NOLOGGING 操作之后執(zhí)行的恢復(fù)所導(dǎo)致的
如果滿足上述條件,完全恢復(fù)通常是首選方法
但請(qǐng)注意:
(a) 如果事務(wù)回滾已發(fā)現(xiàn)壞塊位于對(duì)象上,而非 rollback 段本身,則 undo 操作可能已被放棄。在這種情況下,可能需要在恢復(fù)完成后重建索引/檢查數(shù)據(jù)完整性。

(b) 如果要恢復(fù)的文件包含自上次備份以來(lái)執(zhí)行的 NOLOGGING 操作的數(shù)據(jù),在使用了數(shù)據(jù)文件或數(shù)據(jù)庫(kù)恢復(fù)的情況下,這些塊將被標(biāo)記為“壞塊”。在某些情況下,這會(huì)使情況更加糟糕。

如果執(zhí)行數(shù)據(jù)庫(kù)恢復(fù)后壞塊仍然存在,則表示所有備份都包含壞塊,底層錯(cuò)誤仍存在,或問(wèn)題通過(guò)redo 重現(xiàn)。在這些情況下,需要選擇其他一些恢復(fù)選項(xiàng)。

如果不需要從對(duì)象本身提取任何數(shù)據(jù),能否刪除或重新創(chuàng)建該對(duì)象?
您可以刪除對(duì)象或從腳本/最近導(dǎo)出的副本重新創(chuàng)建對(duì)象。一旦刪除一個(gè)對(duì)象后,該對(duì)象中的塊將被標(biāo)記為“空閑”,并且該塊在被分配到新對(duì)象時(shí)將被重新格式化.明智的做法是,對(duì)表進(jìn)行重命名,而不是刪除,除非您完全確定不再需要其中的數(shù)據(jù)。

對(duì)于表分區(qū),只需要?jiǎng)h除受影響的分區(qū)。例如:ALTER TABLE ...DROP PARTITION ...

如果壞塊影響到分區(qū)段頭,或者包含分區(qū)頭的文件處于離線狀態(tài),則 DROP PARTITION 可能會(huì)失敗。在這種情況下,首先將其更換為具有相同定義的表,之后仍然可以刪除該分區(qū)。
例如:ALTER TABLE ..EXCHANGE PARTITION ..WITH TABLE ..;
最常見(jiàn)的可重建對(duì)象為索引。始終在處理表中的索引問(wèn)題之前處理表壞塊

對(duì)于任何段,如果您擁有壞塊的絕對(duì)文件號(hào)和塊號(hào),則可使用以下快速提取對(duì)象 DDL 的方法:
set long 64000
select dbms_metadata.get_ddl(segment_type, segment_name, owner)
FROM dba_extents
WHERE file_id=&AFN AND &BL BETWEEN block_id AND block_id + blocks -1;

是否需要在重新創(chuàng)建對(duì)象之前搶救數(shù)據(jù)?
如果問(wèn)題位于定期更新的關(guān)鍵應(yīng)用表上,則可能需要盡可能多地?fù)尵缺碇袛?shù)據(jù),然后重新創(chuàng)建該表。

當(dāng)前忽略壞塊是否可???
在某些情況下,最直接的選項(xiàng)可能就是忽略壞塊,并阻止應(yīng)用程序?qū)λM(jìn)行訪問(wèn)。

最后的選項(xiàng)
將數(shù)據(jù)庫(kù)或表空間恢復(fù)到較早的時(shí)間點(diǎn)(通過(guò)時(shí)間點(diǎn)恢復(fù))或還原出現(xiàn)壞塊前的冷備份或使用現(xiàn)有導(dǎo)出文件

完全恢復(fù)
如果數(shù)據(jù)庫(kù)處于ARCHIVELOG 模式下,且擁有受影響文件的完好備份,則恢復(fù)通常為首選方法.這不保證可以解決問(wèn)題,但的確可以有效的解決大部分壞塊問(wèn)題.如果恢復(fù)再次引發(fā)問(wèn)題,則返回到以上選項(xiàng)列表并選擇其他方法.

如果使用的是Oracle9i(或更高版本),則可以使用RMAN BLOCKRECOVER命令執(zhí)行塊級(jí)恢復(fù)。

如果使用的是較早版本的Oracle,則可以執(zhí)行數(shù)據(jù)文件恢復(fù)(數(shù)據(jù)庫(kù)其他部分可以繼續(xù)運(yùn)行),或數(shù)據(jù)庫(kù)恢復(fù)(需要關(guān)閉數(shù)據(jù)庫(kù))

如果使用的是Oracle 11g(或更高版本,則可以使用“Data Recovery Advisor(數(shù)據(jù)恢復(fù)指導(dǎo))”.

塊級(jí)恢復(fù)
自O(shè)racle9i版本起,RMAN允許恢復(fù)單個(gè)塊,同時(shí)數(shù)據(jù)庫(kù)的其他部分(包括數(shù)據(jù)文件中的其他塊)仍可以進(jìn)行正常訪問(wèn).請(qǐng)注意,塊級(jí)恢復(fù)只能將塊完全恢復(fù)到當(dāng)前時(shí)間點(diǎn).要使用此選項(xiàng)恢復(fù)單個(gè)塊,不一定要使用 RMAN 進(jìn)行備份.
例如:
實(shí)際情況是,文件6的塊30上發(fā)生ORA-1578錯(cuò)誤,可能是由于介質(zhì)問(wèn)題導(dǎo)致的壞塊,且您擁有該文件的完好冷備份映像,并已還原到“.../RESTORE/filename.dbf”.假設(shè)所有歸檔日志均存在(位于默認(rèn)位置),則可以通過(guò)RMAN使用以下命令序列執(zhí)行塊級(jí)恢復(fù):
rman nocatalog
connect target
catalog datafilecopy '.../RESTORE/filename.dbf';
run {blockrecover datafile 6 block 30;};
此操作將使用注冊(cè)的數(shù)據(jù)文件備份映像和任何需要的歸檔日志來(lái)執(zhí)行塊恢復(fù),僅將有問(wèn)題的塊恢復(fù)到當(dāng)前時(shí)間點(diǎn).

數(shù)據(jù)文件恢復(fù)
數(shù)據(jù)文件恢復(fù)包括下列步驟.如果有多個(gè)文件,則針對(duì)每個(gè)文件重復(fù)執(zhí)行這些步驟,或參閱下面的“數(shù)據(jù)庫(kù)恢復(fù)”.當(dāng)數(shù)據(jù)庫(kù)處于 OPEN 或 MOUNTED 狀態(tài)時(shí),均可使用這些步驟.
使受影響的數(shù)據(jù)文件離線
例如:ALTER DATABASE DATAFILE 'name_of_file' OFFLINE;

將文件復(fù)制到安全位置(以防備份損壞)

將文件的最新備份還原到完好的磁盤(pán)上

使用DBVERIFY檢查還原的文件是否有壞塊

假設(shè)還原的文件完好,則將數(shù)據(jù)文件重命名并保存到新位置(如果不是原來(lái)的位置)
例如:ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';

恢復(fù)數(shù)據(jù)文件
例如:RECOVER DATAFILE 'name_of_file';

使數(shù)據(jù)文件上線
例如:ALTER DATABASE DATAFILE 'name_of_file' ONLINE;

數(shù)據(jù)庫(kù)恢復(fù)
數(shù)據(jù)庫(kù)恢復(fù)通常包含以下步驟:
關(guān)閉數(shù)據(jù)庫(kù)(使用選項(xiàng) immediate 或 abort)

將待恢復(fù)的所有文件的當(dāng)前副本復(fù)制到安全位置

將備份文件還原到完好的磁盤(pán)上

請(qǐng)勿還原控制文件或在線REDO 日志文件

使用DBVERIFY檢查還原的文件

啟動(dòng)數(shù)據(jù)庫(kù)到MOUNT狀態(tài)(startup mount)

對(duì)任何需要重新定位的數(shù)據(jù)文件進(jìn)行重命名
例如:ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';

確保所有必需的文件在線
例如:ALTER DATABASE DATAFILE 'name_of_file' ONLINE;

恢復(fù)數(shù)據(jù)庫(kù)
例如:RECOVER DATABASE

打開(kāi)數(shù)據(jù)庫(kù)
例如:ALTER DATABASE OPEN;

一旦執(zhí)行了完全恢復(fù),最好在允許使用之前先檢查數(shù)據(jù)庫(kù):
針對(duì)每個(gè)問(wèn)題對(duì)象運(yùn)行“ANALYZE <table_name> VALIDATE STRUCTURE CASCADE”,檢查表/索引是否存在不匹配。如果有任何 und 操作曾被放棄,此命令可能會(huì)顯示不匹配,此時(shí)需要重建索引。

在應(yīng)用程序級(jí)別檢查表中數(shù)據(jù)的邏輯完整性。

重建索引
損壞對(duì)象為用戶索引時(shí),如果底層表沒(méi)有損壞,則可以刪除并重建該索引。

如果底層表也已經(jīng)損壞,則應(yīng)在重建任何索引之前先解決該表的壞塊。

如果收集的信息表示索引有從屬外鍵約束,則需要執(zhí)行以下操作:
ALTER TABLE <child_table> DISABLE CONSTRAINT <fk_constraint>;

使用以下命令重建主鍵
ALTER TABLE

DISABLE CONSTRAINT <pk_constraint>; DROP INDEX <index_name>; CREATE INDEX <index_name> .. with appropriate storage clause ALTER TABLEENABLE CONSTRAINT <pk_constraint>;

啟用外鍵約束
ALTER TABLE <child_table> ENABLE CONSTRAINT <fk_constraint>;

對(duì)于索引分區(qū),以執(zhí)行以下命令:
ALTER INDEX ...REBUILD PARTITION ...;

注意:
(1) 不要使用“ALTER INDEX .. REBUILD”命令重建損壞的非分區(qū)索引,這一點(diǎn)非常重要,因?yàn)榇瞬僮魍ǔ?huì)嘗試從包含壞塊的現(xiàn)有索引段中構(gòu)建新索引..“ALTER TABLE ... REBUILD ONLINE”和“ALTER INDEX ... REBUILD PARTITION ...”不會(huì)從舊索引段中構(gòu)建新索引,因此可以使用。

(2) 如果新索引包含的列為現(xiàn)有索引的子集,則 Create INDEX 可以使用現(xiàn)有索引中的數(shù)據(jù),因此,如果您有兩個(gè)損壞的索引,應(yīng)在重建之前將兩個(gè)都刪除。

(3) 重建索引時(shí),請(qǐng)確保使用正確的存儲(chǔ)選項(xiàng)。

搶救表中數(shù)據(jù)
如果損壞的對(duì)象為T(mén)ABLE 或 CLUSTER 或 LOBSEGMENT,則必須明白,壞塊內(nèi)的數(shù)據(jù)已經(jīng)丟失.部分?jǐn)?shù)據(jù)可能可以從塊的HEX轉(zhuǎn)儲(chǔ)中,或從索引涵蓋的列中搶救回來(lái).

由于可能需要從索引中搶救壞塊中的數(shù)據(jù),因此最好不要?jiǎng)h除任何現(xiàn)有索引,直至所有需要的數(shù)據(jù)提取完成。

從包含壞塊的表中提取數(shù)據(jù)有多種方法。選擇最恰當(dāng)?shù)姆椒?詳細(xì)信息如下所述.這些方法的目的是從可訪問(wèn)的表塊中提取盡可能多的數(shù)據(jù).通常,將損壞的表重命名是一個(gè)比較好的方法,這樣就可以使用正確的名稱(chēng)創(chuàng)建新對(duì)象.
例如:RENAME TO <emp_corrupt>;

從壞塊表中提取壞塊周?chē)鷶?shù)據(jù)的方法
(1) 從Oracle 7.2開(kāi)始(包括 Oracle 8.0、8.1 和 9i)可以跳過(guò)表中的壞塊。
這是到目前為止最簡(jiǎn)單的提取表數(shù)據(jù)的方法,用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS or Event 10231

如果壞塊位于IOT overflow 段,則應(yīng)使用相同的方法,不同的是使用Event 10233和全索引掃描

請(qǐng)注意,此方法只適用于塊的“包裝”已被標(biāo)記為“壞塊”的情況。例如:如果塊報(bào)告 ORA-1578 錯(cuò)誤。如果問(wèn)題為 ORA-600 或其他非ORA-1578 錯(cuò)誤,則通??梢允褂?DBMS_REPAIR 將表中壞塊標(biāo)記為“軟壞塊”。這樣在您訪問(wèn)該數(shù)據(jù)塊時(shí),系統(tǒng)將顯示 ORA-1578錯(cuò)誤,從而可以使用 DBMS_REPAIR.SKIP_CORRUPT_BLOCKS。

注意:被“FIX_CORRUPT_BLOCKS”程序標(biāo)記為“壞塊”的塊在任何還原/恢復(fù)操作之后還將被標(biāo)記為“壞塊”.

使用DBMS_REPAIR進(jìn)行此操作概括起來(lái)步驟如下:
使用DBMS_REPAIR.ADMIN_TABLES 創(chuàng)建管理表

使用DBMS_REPAIR.CHECK_OBJECT 找到問(wèn)題塊

在損壞問(wèn)題塊之前將其中所有完好的數(shù)據(jù)導(dǎo)出。

使用DBMS_REPAIR.FIX_CORRUPT_BLOCKS將找到的問(wèn)題塊標(biāo)記為“壞塊”,然后它們就會(huì)顯示 ORA-1578

如果需要,使用 DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳過(guò)表中的壞塊。

(2) 從 Oracle 7.1 開(kāi)始,可以使用 ROWID 范圍掃描.此功能的語(yǔ)法較為復(fù)雜,但可以使用 ROWID提示選擇壞塊周?chē)臄?shù)據(jù).

(3) 如果存在主鍵,則可以通過(guò)此索引選擇表數(shù)據(jù)。也可以通過(guò)任何其他索引選擇一些數(shù)據(jù)。此方法較慢,花費(fèi)時(shí)間較長(zhǎng),通常只有 Oracle 7.0 版本才使用

(4) 有多種搶救程序/PLSQL 腳本可用于搶救表中的數(shù)據(jù)。與上述方法相比,這些方法在設(shè)置和使用方面需要花費(fèi)更長(zhǎng)的時(shí)間,但常常能夠處理除 ORA-1578 之外的各類(lèi)壞塊

從包含損壞的LOBSEGMENT 塊的表中提取數(shù)據(jù)的方法:
在 LOB 段上不可以使用 DBMS_REPAIR,如果壞塊 LOB 塊未被表中的任何行引用,則應(yīng)該可以使用 CREATE TABLE as SELECT (CTAS)來(lái)按選擇創(chuàng)建表,或按原樣導(dǎo)出/刪除/導(dǎo)入該表。

如果壞塊LOB 塊被某個(gè)行引用,則應(yīng)該可以使用不包括問(wèn)題行的WHERE謂詞進(jìn)行選擇或?qū)С?/p>

注意:可以將問(wèn)題行的LOB列值更新為NULL,從而使SELECT操作不再返回ORA-1578錯(cuò)誤,但是壞塊將等待被重新使用,隨著對(duì)行中的 LOB列進(jìn)行INSERT或UPDATE操作,當(dāng)有問(wèn)題的塊被重新使用時(shí),最后還是會(huì)報(bào)ORA-1578錯(cuò)誤,那時(shí)的情況比已知行出現(xiàn)壞塊更糟糕.因此,只有您打算立刻重新創(chuàng)建表,才應(yīng)該將LOB列設(shè)為NULL.

從壞塊本身提取數(shù)據(jù)
由于壞塊本身已經(jīng)“損壞”,則從該塊中提取的任何數(shù)據(jù)都應(yīng)被視為可疑數(shù)據(jù),從壞塊本身獲取數(shù)據(jù)行的主要方法包括:
對(duì)于 TABLE 的塊,Oracle Support 可以使用一款嘗試解釋塊內(nèi)容的工具。

使用表中現(xiàn)有索引,利用落在壞塊內(nèi)的ROWID 來(lái)提取索引所涵蓋的列數(shù)據(jù),上文提到的 ROWID 范圍掃描文章在接近結(jié)束時(shí)對(duì)此內(nèi)容有所介紹:
對(duì)于 Oracle8/8i,請(qǐng)參閱 Document 61685.1
對(duì)于 Oracle7,請(qǐng)參閱 Document 34371.1

在 redo 流上可以使用 LogMiner 來(lái)查找向問(wèn)題塊加載數(shù)據(jù)的初始插入/更新操作。此處的主要因素是數(shù)據(jù)實(shí)際被放入問(wèn)題塊的時(shí)間.例如,行2可能在昨天已插入,而行1可能在1年前已插入.

忽略壞塊
出錯(cuò)時(shí)可以忽略壞塊并接受報(bào)告的錯(cuò)誤,或在應(yīng)用程序級(jí)別阻止對(duì)出問(wèn)題的塊行進(jìn)行訪問(wèn)。
例如:如果問(wèn)題塊/行位于子表中,則可以在應(yīng)用程序級(jí)別阻止對(duì)父表中對(duì)應(yīng)行的訪問(wèn),從而子行就永不會(huì)被訪問(wèn)(但要注意級(jí)聯(lián)類(lèi)約束)

這樣做可能不利于批量訪問(wèn)數(shù)據(jù)的報(bào)告和其他任務(wù),因此,為了阻止塊在被訪問(wèn)時(shí)報(bào)錯(cuò),前面所述的DBMS_REPAIR選項(xiàng)也不失為一個(gè)可取的方法.使用這種方法標(biāo)記并跳過(guò)壞塊提供了一種短期的解決方案.從而在計(jì)劃停機(jī)時(shí)可以嘗試進(jìn)行完全數(shù)據(jù)搶救和/或恢復(fù),或留出更多時(shí)間在第二個(gè)(克?。?shù)據(jù)庫(kù)上嘗試其他恢復(fù)選項(xiàng).但請(qǐng)注意,使用DBMS_REPAIR.FIX_CORRUPT_BLOCKS標(biāo)記塊壞塊將導(dǎo)致標(biāo)記的塊在恢復(fù)后還是“壞塊”。

忽略壞塊對(duì)于快速老化且即將被清除的數(shù)據(jù)而言是比較好的選擇(例如,在按日期分區(qū)的表中,較老的分區(qū)將在某時(shí)間點(diǎn)被刪除).

忽略LOB段上的壞塊
在應(yīng)用程序級(jí)別,可以忽略損壞的LOB列,直到可以重新構(gòu)建該表.確保不出現(xiàn)上述“警告”中的情形的一種方法是確保應(yīng)用程序只能通過(guò)表上的包含WHERE 謂詞的視圖來(lái)訪分表中的數(shù)據(jù).
例如:假設(shè)表 MYTAB(a number primary key,b clob)有一行或多行指向損壞的 LOB 數(shù)據(jù)。
ALTER TABLE MYTAB ADD ( BAD VARCHAR2(1) );

CREATE VIEW MYVIEW AS SELECT a,b FROM MYTAB WHERE BAD is null;

對(duì)任何問(wèn)題行設(shè)置 BAD='Y'

如果只通 MYVIEW 訪問(wèn) MYTAB,該行將永不可見(jiàn),因此也無(wú)法更新,從而實(shí)現(xiàn)了壞塊條目隔離,直到問(wèn)題解決.

很明顯,此示例更多的是一個(gè)設(shè)計(jì)時(shí)解決方案,但某些應(yīng)用程序可能已有類(lèi)似機(jī)制,且可能只通過(guò)某個(gè)視圖(或通過(guò) RLS 策略)訪問(wèn)數(shù)據(jù),從而提供某些選項(xiàng)來(lái)隱藏問(wèn)題行。

針對(duì)忽略壞塊的警告
雖然可以忽略壞塊,但需要注意的是,壞塊在運(yùn)行DBVERIFY,RMAN 備份時(shí)仍然會(huì)以警告/錯(cuò)誤等形式出現(xiàn)。請(qǐng)務(wù)必仔細(xì)記錄您將在這些工具中看到的任何壞塊,尤其是您期望在使用RMAN時(shí)跳過(guò)的任何塊(例如,設(shè)置了 MAX_CORRUPT),并確保在清除壞塊后移除任何對(duì)錯(cuò)誤的“接受”選項(xiàng).
例如:假設(shè)壞塊已處理為忽略壞塊,并在應(yīng)用程序級(jí)別跳過(guò)問(wèn)題行。RMAN可能被配置為在備份時(shí)接受壞塊。然后在稍后的表重組期間重新創(chuàng)建表。如果 RMAN 配置未及時(shí)更新以反映目前已無(wú)任何錯(cuò)誤,則 RMAN 可能會(huì)忽略稍后出現(xiàn)的某些其他壞塊。

此外,還有重要的一點(diǎn)需要注意,忽略table段中的壞塊可能導(dǎo)致查詢返回不一致的結(jié)果。
例如:設(shè)置了 SKIP_CORRUPT 的表可能出現(xiàn)不同的結(jié)果,具體取決于是使用了了索引掃描還是表訪問(wèn),其他報(bào)告可能只是報(bào)錯(cuò).。

請(qǐng)注意,如果忽略壞塊但使用DBMS_REPAIR.FIX_CORRUPT_BLOCKS標(biāo)記,系統(tǒng)會(huì)向壞塊中寫(xiě)入redo信息,這可能會(huì)限制后續(xù)的恢復(fù)選項(xiàng).

最后的選項(xiàng)
如果你有standby環(huán)境(物理或邏輯),請(qǐng)首先對(duì)其進(jìn)行檢查。

無(wú)論問(wèn)題發(fā)生在何種類(lèi)型的塊上,均可使用一種可能的選項(xiàng),即將數(shù)據(jù)庫(kù)或問(wèn)題表空間恢復(fù)到出現(xiàn)壞塊之前的某個(gè)時(shí)間點(diǎn).此選項(xiàng)的困難之處在于,并不總能知道問(wèn)題首次出現(xiàn)的時(shí)間.

DBVERIFY通??捎糜跈z查還原的文件是否存在壞塊.尤其是,START= / END= DBV選項(xiàng)可用于在還原的備份映像上快速進(jìn)行首次測(cè)試,以檢查問(wèn)題塊本身是否出錯(cuò)。

下面列出了一些可用于進(jìn)行恢復(fù)操作的最終選項(xiàng),當(dāng)出現(xiàn)其中一種或多種情況:
您丟失了非常重要的數(shù)據(jù)文件(或數(shù)據(jù)文件出現(xiàn)壞塊),而沒(méi)有問(wèn)題文件的正常備份(無(wú)壞塊)
既不處于ARCHIVELOG 模式,也沒(méi)有自文件創(chuàng)建以來(lái)的全部歸檔日志
完全恢復(fù)后仍重復(fù)出現(xiàn)問(wèn)題

最后的機(jī)會(huì):
請(qǐng)注意,如果丟失了數(shù)據(jù)文件的所有副本,但仍具有自文件創(chuàng)建以來(lái)的全部歸檔日志,則仍有可能恢復(fù)該文件。
例如:
ALTER DATABASE CREATE DATAFILE '....'[as '...'] ;

RECOVER DATAFILE '....'

ALTER DATABASE DATAFILE '....'ONLINE;
如果您遇到這種情況,請(qǐng)?jiān)诶^續(xù)下面的操作之前先嘗試使用這些步驟來(lái)恢復(fù)數(shù)據(jù)文件。

如果您到達(dá)這一步,就說(shuō)明沒(méi)有其他辦法可以將文件恢復(fù)到當(dāng)前時(shí)間點(diǎn).此時(shí)最好關(guān)閉實(shí)例,并對(duì)當(dāng)前數(shù)據(jù)庫(kù)進(jìn)行備份,以便在選用的措施失敗后仍然能夠回退到當(dāng)前時(shí)間點(diǎn).(例如:如果發(fā)現(xiàn)備份壞塊).

可用的一些選項(xiàng)概述如下:
恢復(fù)到早期的冷備份
例如:如果處于 NOARCHIVELOG 模式
從冷備份建立克隆數(shù)據(jù)庫(kù)
并提?。▽?dǎo)出)問(wèn)題表
或傳輸問(wèn)題表空間

使用基于時(shí)間點(diǎn)的恢復(fù)將數(shù)據(jù)庫(kù)恢復(fù)到一致的時(shí)間點(diǎn)
需要完好備份和任何所需的歸檔日志
必須還原所有文件且將整個(gè)數(shù)據(jù)庫(kù)前滾到恰當(dāng)?shù)臅r(shí)間點(diǎn)。
可以在克隆數(shù)據(jù)庫(kù)中執(zhí)行基于時(shí)間點(diǎn)的恢復(fù),然后將問(wèn)題表空間傳輸?shù)絾?wèn)題數(shù)據(jù)庫(kù),或?qū)?wèn)題表利用導(dǎo)出/導(dǎo)入工具從克隆數(shù)據(jù)庫(kù)導(dǎo)入到問(wèn)題數(shù)據(jù)庫(kù).

表空間基于時(shí)間點(diǎn)的恢復(fù)
可以僅對(duì)受影響的表空間執(zhí)行基于時(shí)間點(diǎn)的恢復(fù).

從邏輯導(dǎo)出/副本重新創(chuàng)建數(shù)據(jù)庫(kù)
需要具有完好的數(shù)據(jù)庫(kù)邏輯備份
注意:要使用此選項(xiàng),必須重新創(chuàng)建數(shù)據(jù)庫(kù)。
與其他選項(xiàng)一樣,可以在克隆數(shù)據(jù)庫(kù)中進(jìn)行重新創(chuàng)建,只為獲得問(wèn)題表的完好映像.

總之做好備份是DBA最重要的工作.

以上是“如何處理oracle中出現(xiàn)的壞塊”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對(duì)大家有所幫助,如果還想學(xué)習(xí)更多知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI