破損したブロック相対dba：0x0724c078（ファイル28、ブロック2408568）
データファイルのバックアップ中に破損ブロックが見つかりました
blocknumの再読み込み= 2408568、ファイル= E：\ ORACLE \ ORADATA \ XXX \ XXX_BLOB16.DBF。 同じ破損データが見つかりました
状況は、手元にバックアップがないという事実によって複雑になりました。
次に、この状況から抜け出すための指示に従ってください。
RMANはこのブロックに依存しており、データベースをまったくバックアップしたくありませんでした。
詳細な報告が開始され、このユニットが何を指しているのかがわかりました。
SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = 28 AND 2408568 BETWEEN block_id AND block_id + blocks - 1; OWNER ---------------------------- SEGMENT_NAME ---------------------------- SEGMENT_TYPE ------------------ DOC_USER SYS_LOB0000075021C00003$$ LOBSEGMENT
次に、指定されたLOBセグメントがどのテーブルに属しているかがわかりました。
SELECT table_name, column_name FROM dba_lobs WHERE owner='DOC_USER' AND segment_name='SYS_LOB0000075021C00003$$'; TABLE_NAME ------------------- COLUMN_NAME ------------------- DOC_LARGE_PIC BINARY_DATA
DBMS_REPAIR-LOBフィールドの操作に関する制限のため、状況を明確にできませんでした。
ネットワークのオープンスペースで解決策が見つかりました。その本質は次のとおりです。
- 1.テーブルのエントリを交互にソートします。
- 2. beatられたブロックに関連するレコードにアクセスした場合、その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, BINARY_DATA L from DOC_USER.DOC_LARGE_PIC) 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; /
スクリプトは次の2つのエントリを正常に返しました。
Got ORA-1578 reading LOB at AAASUNAAQAAPf7hAAY Got ORA-1578 reading LOB at AAASUNAAQAAPf7hAAp
単純なクエリを使用して、PRIMARY KEYデータレコードが受信され、レコードが正常にワイプされました。
これが問題の解決策のように思えますが、RMANは頑固にこれらのブロックに置かれたデータベースを予約したくありませんでした。
V $ DATABASE_BLOCK_CORRUPTIONおよびRMAN VALIDATE DATAFILEのクエリは、ブロックが同じ状態のままであることを確認しました。
テーブルを作成して、テーブルスペース全体の目玉に叩きつけたくなかったので、ALTER TABLE XXX SHRINK SPACEを使用することにしました。
ALTER TABLE DOC_USER.DOC_LARGE_PIC ENABLE ROW MOVEMENT; ALTER TABLE DOC_USER.DOC_LARGE_PIC SHRINK SPACE CASCADE;
次に、RMANで問題ファイルのチェックを開始します。
RMAN VALIDATE DATAFILE 28;
この操作の後、V $ DATABASE_BLOCK_CORRUPTIONビューは非常に鮮明になりました。
さらに、データベースはRMANによって正常に予約され、欠落したレコードはレプリカから取り出されました。
更新
この問題は、サーバー上のディスクが崩れ始めた後に発生しました。
セクションのコピーは、サードパーティのユーティリティを使用して削除され、新しく組み立てられた新しいアレイに展開されました。
すべての操作は、1.5 TBの重量に基づいて実行されました。
テーブルの重量は70 GBです。
Oracle 11g R2のバージョン-この方法は10gに適用できると思います。
ALTER TABLE ... SHRINK SPACE CASCADEにはいくつかの制限があります。使用する前にドキュメントをよく理解することをお勧めします。