Oracle Databaseの運用において、データ破損は避けたい事態ですが、万が一の際にはOracleデータリカバリアドバイザー (Data Recovery Advisor, DRA) が強力な解決策となります。本記事では、DRAを使用してデータブロック破損を特定し、自動修復する手順を解説します。
データリカバリアドバイザーとは、Oracleの自己診断機能の一つです。データベースの破損を自動検出し、RMAN（Recovery Manager）と連携して最適な復旧手段を提示・実行します。手動での複雑なコマンド操作を最小限に抑え、迅速な復旧を支援します。
Oracleデータベースの完全リカバリ手順：RMANによる復旧フロー
Oracleデータベースに障害が発生した際、適切なバックアップとアーカイブログを利用することで、障害直前の状態まで戻す「完全リカバリ」が可能です。本記事では、Oracle Database 19cにおけるRMANを活用した完全リカバリの手順…
oracle-master00000.com
2025.03.23
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
データリカバリアドバイザーによる復旧のクイックステップ
障害発生から復旧までの最短手順です。
- 状態確認:
VALIDATE DATABASEで破損の有無を確認 - 障害特定:
LIST FAILUREで破損個所をリストアップ - 診断・提案:
ADVISE FAILUREで推奨される修復方法を表示 - 修復実行:
REPAIR FAILUREで自動修復を適用 - 完了確認: 再度
LIST FAILUREを実行し、障害が消えたことを確認
1. データ破損の確認と診断
破損が疑われる場合、まず現在の破損状況を可視化します。
破損ブロックの確認用SQL
以下のSQLで V$DATABASE_BLOCK_CORRUPTION ビューを問い合わせます。
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
RMANによる検証
RMANでデータベース全体の検証を行い、破損ブロックの場所を特定します。
# RMANに接続
rman target /
# 検証の実行
RMAN> VALIDATE DATABASE;
検証により破損が見つかった場合、アラートログ（alert_<SID>.log）にも ORA-01578 エラーが記録されます。
RMAN> VALIDATE DATABASE;
validateを25-03-10で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: データファイルの検証を開始しています
チャネルORA_DISK_1: 検証のためのデータファイルを指定しています
入力データファイル ファイル番号=00001 名前=/u01/app/oracle/oradata/V19/system01.dbf
入力データファイル ファイル番号=00003 名前=/u01/app/oracle/oradata/V19/sysaux01.dbf
入力データファイル ファイル番号=00004 名前=/u01/app/oracle/oradata/V19/undotbs01.dbf
入力データファイル ファイル番号=00005 名前=/u01/app/oracle/oradata/V19/test_tbs.dbf
入力データファイル ファイル番号=00007 名前=/u01/app/oracle/oradata/V19/users01.dbf
チャネルORA_DISK_1: 検証が完了しました。経過時間: 00:00:15
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1 OK 0 18146 149764 2276316
ファイル名: /u01/app/oracle/oradata/V19/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 81290
Index 0 13395
Other 0 36929
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
3 OK 0 23005 93450 2276451
ファイル名: /u01/app/oracle/oradata/V19/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 7162
Index 0 2820
Other 0 60453
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4 OK 0 416 92800 2276453
ファイル名: /u01/app/oracle/oradata/V19/undotbs01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 0
Index 0 0
Other 0 92384
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
5 FAILED 0 4609 12800 2273949
ファイル名: /u01/app/oracle/oradata/V19/test_tbs.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 7935
Index 0 0
Other 1 256
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
7 OK 0 101 641 1252497
ファイル名: /u01/app/oracle/oradata/V19/users01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data 0 60
Index 0 15
Other 0 464
検証により1つ以上の破損したブロックが見つかりました
詳細はトレース・ファイル/u01/app/oracle/diag/rdbms/v19/v19/trace/v19_ora_2652.trcを参照してください
チャネルORA_DISK_1: データファイルの検証を開始しています
チャネルORA_DISK_1: 検証のためのデータファイルを指定しています
現行の制御ファイルを検証に組み込んでいます
バックアップ・セットに現行のSPFILEを組み込んでいます
チャネルORA_DISK_1: 検証が完了しました。経過時間: 00:00:01
List of Control File and SPFILE
===============================
File Type Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE OK 0 2
Control File OK 0 646
validateを25-03-10で終了しました
RMAN> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO CON_ID
---------- ---------- ---------- ------------------ --------- ----------
5 140 1 0 ALL ZERO 0
また、アラートログを確認して、データ破損の詳細情報を取得します。
tail -f $ORACLE_BASE/diag/rdbms/<DB_NAME>/<INSTANCE_NAME>/trace/alert_<INSTANCE_NAME>.log【アラートログの出力例】
2025-03-10T20:11:51.450587+09:00
Hex dump of (file 5, block 140) in trace file /u01/app/oracle/diag/rdbms/v19/v19/trace/v19_ora_2641.trc
Corrupt block relative dba: 0x0140008c (file 5, block 140)
Completely zero block found during user buffer read
Reading datafile '/u01/app/oracle/oradata/V19/test_tbs.dbf' for corrupt data at rdba: 0x0140008c (file 5, block 140)
Reread (file 5, block 140) found same corrupt data (no logical check)
2025-03-10T20:11:51.532326+09:00
Corrupt Block Found
TIME STAMP (GMT) = 03/10/2025 20:11:50
CONT = 0, TSN = 6, TSNAME = TEST_TBS
RFN = 5, BLK = 140, RDBA = 20971660
OBJN = 74185, OBJD = 74185, OBJECT = TAB24, SUBOBJECT =
SEGMENT OWNER = TEST1, SEGMENT TYPE = Table Segment
Errors in file /u01/app/oracle/diag/rdbms/v19/v19/trace/v19_ora_2641.trc (incident=12441):
ORA-01578: Oracleデータ・ブロックに障害が発生しました(ファイル番号5、ブロック番 号140)
ORA-01110: データファイル5: '/u01/app/oracle/oradata/V19/test_tbs.dbf'
Incident details in: /u01/app/oracle/diag/rdbms/v19/v19/incident/incdir_12441/v19_ora_2641_i12441.trc
2025-03-10T20:11:53.566649+09:00
*****************************************************************
An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error, when
analysis of the redo logs will help Oracle Support with the
diagnosis.
It is recommended that you retain all the redo logs generated (by
all the instances) during the past 12 hours, in case additional
redo dumps are required to help with the diagnosis.
*****************************************************************
2025-03-10T20:11:55.773636+09:00
Corrupt block relative dba: 0x0140008c (file 5, block 140)
Completely zero block found during validation
Reread of blocknum=140, file=/u01/app/oracle/oradata/V19/test_tbs.dbf. found same corrupt data
Reread of blocknum=140, file=/u01/app/oracle/oradata/V19/test_tbs.dbf. found same corrupt data
Reread of blocknum=140, file=/u01/app/oracle/oradata/V19/test_tbs.dbf. found same corrupt data
Reread of blocknum=140, file=/u01/app/oracle/oradata/V19/test_tbs.dbf. found same corrupt data
Reread of blocknum=140, file=/u01/app/oracle/oradata/V19/test_tbs.dbf. found same corrupt data
2. データリカバリアドバイザーを使用した修復手順
DRAを活用した具体的な復旧フローです。
手順2.1: 障害の特定
現在発生している障害を確認します。
RMAN> LIST FAILURE;
RMAN> LIST FAILURE;
データベース・ロール: PRIMARY
List of Database Failures
=========================
障害ID 優先度ステータス 検出時間 サマリー
------ -------- --------- -------- -------
41 HIGH OPEN 25-03-10 データファイル5: '/u01/app/oracle/oradata/V19/test_tbs.dbf'には破損したブロックが1つ以上含まれています
手順2.2: 修復方法の提案
DRAに推奨される修復方法を分析させます。
RMAN> ADVISE FAILURE;
出力結果に「自動修復オプション」が表示されます。通常、ブロックメディアリカバリが提示されます。
RMAN> ADVISE FAILURE;
データベース・ロール: PRIMARY
List of Database Failures
=========================
障害ID 優先度ステータス 検出時間 サマリー
------ -------- --------- -------- -------
41 HIGH OPEN 25-03-10 データファイル5: '/u01/app/oracle/oradata/V19/test_tbs.dbf'には破損したブロックが1つ以上含まれています
自動修復オプションを分析中です。これには少し時間がかかる場合があります
チャネルORA_DISK_1の使用
自動修復オプションの分析が完了しました
必須の手動アクション
========================
no manual actions available
Optional Manual Actions
=======================
no manual actions available
自動修復オプション
========================
オプション 修復 説明
------ ------------------
1 ブロック140 (ファイル5)のブロック・メディア・リカバリを実行します
計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます
Repair script: /u01/app/oracle/diag/rdbms/v19/v19/hm/reco_3085682433.hm
手順2.3: 修復の実行
提示されたスクリプトを実行して修復します。
RMAN> REPAIR FAILURE;
確認プロンプトで YES を入力すると、必要なリストアとメディアリカバリが自動的に実行されます。
RMAN> REPAIR FAILURE;
計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます
Repair script: /u01/app/oracle/diag/rdbms/v19/v19/hm/reco_3085682433.hm
修復スクリプトの内容:
# block media recovery
recover datafile 5 block 140;
この修復を実行しますか(YESまたはNOを入力してください)。 YES
修復スクリプトを実行しています
recoverを25-03-10で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_1: ブロックをリストアしています
チャネルORA_DISK_1: バックアップ・セットからリストアするブロックを指定しています
データファイル00005のブロックをリストアしています
チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/product/19.0.0/dbhome_1/dbs/013k1688_1_1_1から読取り中です
チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/product/19.0.0/dbhome_1/dbs/013k1688_1_1_1 タグ=TAG20250310T195656
チャネルORA_DISK_1: バックアップ・ピース1からブロックをリストアしました
チャネルORA_DISK_1: ブロックのリストアが完了しました。経過時間: 00:00:01
メディア・リカバリを開始しています
メディア・リカバリが完了しました。経過時間: 00:00:03
recoverを25-03-10で終了しました
障害の修復が完了しました
手順2.4: 修復結果の確認
再度障害リストを確認し、ステータスがクリアされたことを確認します。
RMAN> LIST FAILURE;
RMAN> LIST FAILURE;
データベース・ロール: PRIMARY
指定に一致する障害が見つかりません
3. 運用上の注意点とFAQ
破損データの復旧におけるリスク
- バックアップの必要性: DRAによる復旧には、破損ブロック以前の時点のバックアップが必要です。バックアップが存在しない場合、修復できない可能性があります。
- 戻し方: 本手順はデータ復旧（修復）のみを行うため、誤った修復によるロールバック（取り消し）は通常行いません。操作前に必ず最新のバックアップを取得してください。
FAQ
Q1: DRAは常に自動で修復してくれますか？ A1: いいえ。破損状況によっては手動での介入が必要な場合もありますが、DRAは「何が起きているか」「どうすべきか」を提示するため、作業ミスを大幅に減らせます。
Q2: ORA-01578が発生した場合、即座にREPAIR FAILUREを使えますか？ A2: まずはリストア・リカバリ計画を立てるために ADVISE FAILURE を実行し、最適なパスを確認することを推奨します。
Q3: 破損が多発している場合はどうすべきですか？ A3: ディスク故障の予兆である可能性があります。LIST FAILURE の結果だけでなく、OS側のログやストレージのヘルスチェックを併せて確認してください。
4. まとめ
データリカバリアドバイザーを活用すれば、コマンドの組み立てミスを抑え、安全に破損ブロックを復旧可能です。
LIST FAILURE: 障害を見つけるADVISE FAILURE: 修復の道筋を確認するREPAIR FAILURE: 安全に修復する
日頃からRMANによる定期的なバックアップを取得しておくことが、この強力なツールを有効活用するための大前提となります。
本記事は Oracle Database 19c を対象に解説します（他バージョンは画面や既定値が異なる場合があります）。
[参考]
Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド 19c
Oracle RMAN バックアップのやり方と基本コマンド
Oracle データベースの運用において、データの保護は最優先事項です。Oracle RMAN（Recovery Manager）は、効率的なOracle バックアップと迅速なリカバリを実現するための標準ツールです。本記事では、初心者から中…
oracle-master00000.com
2025.02.27
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント