>> 連載トップページに戻る

 

基本からわかる!高性能×高可用性データベースシステムの作り方

第11回 バックアップ/リカバリ(6)データファイルよりも小さな粒度でのリストア/リカバリ


著者紹介


日下部 明 (くさかべ あきら)

日本オラクル Oracle Database担当。Oracle GRID Centerのラインマネージャとしてオラクルの持つ最新技術をパートナー各社と共同で検証し、多くのホワイトペーパーを執筆・レビューしてきました。以後、Oracle Databaseのセキュリティ製品のリリースマネージャを担当。これらの経験を元にミッションクリティカルな案件のソリューションデザインの提案などを担当しています。著書に「これは使えるOracle新機能活用術」(翔泳社)。


第11回 バックアップ/リカバリ(6)データファイルよりも小さな粒度でのリストア/リカバリ


第10回までは、リストアはファイル単位で行うという暗黙の仮定を置いていました。RMANでバックアップを取得する最小単位は1本のデータファイルですが、リストア/リカバリの最小単位はデータファイルではありません。RMANはデータファイルよりも小さな単位である特定のデータブロックをリストア/リカバリすることが可能です。これをブロック・メディア・リカバリと呼びます。

Oracle Databaseは複数のデータファイルで構成されていますが、データファイル以上の単位でリストア/リカバリするためには、そのデータファイルを含む領域を一旦アクセスできない状態にする必要があります。


リストア対象 RMANコマンド 前提
CDB全体 RMAN> RESTORE DATABASE; OracleインスタンスをSHUTDOWNしてMOUNTで起動
PDB RMAN> RESTORE PLUGGABLE DATABASE xx; 該当PDBをMOUNT状態
表領域 RMAN> RESTORE TABLESPACE xx; 該当表領域をOFFLINE
データファイル RMAN> RESTORE DATAFILE xx; 該当表領域をOFFLINE 該当表領域の全データファイルをOFFLINE
データブロック RMAN> RECOVER DATAFILE xx BLOCK yy; データファイルがONLINEのまま可能

ブロック・メディア・リカバリでは、リカバリ対象のデータブロック以外の正常なデータブロックへのアクセスは可能にしたままリストア/リカバリすることが可能です。そのため、リカバリ対象のデータブロックにアクセスしないSQLは実行可能です。また、データファイル単位のリストア/リカバリよりも短時間でリカバリが完了します。

2 ブロック・メディア・リカバリの実行

ブロック・メディア・リカバリではRECOVERコマンドにどのデータファイルのどのデータブロックをリカバリするかを指定します。そのためには、破損が発生したデータブロックを把握する必要があります。SQL実行時に破損が検出されると、そのSQLのエラーとして破損データブロックの情報が出力されます。

SQL> r
  1  select c1,
  2         DBMS_ROWID.ROWID_RELATIVE_FNO(rowid) fno ,
  3         DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) bno
  4* from t1
select c1,
       *
行1でエラーが発生しました。:
ORA-01578: Oracleデータ・ブロックに障害が発生しました(ファイル番号18、ブロック番号131) ORA-01110: データファイル18:
'/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'

Oracle Databaseサーバー側に出力される情報としてはOracleインスタンスのalertファイルと、V$DATABASE_BLOCK_CORRUPTIONビューがあります。

2019-03-11T13:29:00.884624+09:00
Corrupt Block Found
         TIME STAMP (GMT) = 03/11/2019 13:29:00
         CONT = 3, TSN = 6, TSNAME = USERS2
         RFN = 18, BLK = 131, RDBA = 75497603
         OBJN = 89853, OBJD = 89853, OBJECT = T1, SUBOBJECT =
         SEGMENT OWNER = BKTEST, SEGMENT TYPE = Table Segment
Errors in file /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/trace/sidb18a_ora_6726.trc  (incident=93361) (PDBNAME=SIPDB1):
ORA-01578: Oracleデータ・ブロックに障害が発生しました(ファイル番号18、ブロック番号131)
ORA-01110: データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'
SIPDB1(3):Incident details in: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/incident/incdir_93361/sidb18a_ora_6726_i93361.trc
SQL> SELECT FILE#,BLOCK#,BLOCKS FROM V$DATABASE_BLOCK_CORRUPTION;

     FILE#     BLOCK#     BLOCKS
---------- ---------- ----------
        18        131          1

また、RMANのデータ・リカバリ・アドバイザを使用すると、破損データブロックの特定からリカバリ・コマンドの生成および実行まで行うことができます。

■障害個所の把握
RMAN> list failure;

データベース・ロール: PRIMARY

データベース障害のリスト
=========================

障害ID 優先度ステータス    検出時間 サマリー
------ -------- --------- -------- -------
21862  HIGH     OPEN      19-03-11 データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'には 破損したブロックが1つ以上含まれています

RMAN> list failure 21862 detail;

データベース・ロール: PRIMARY

データベース障害のリスト
=========================

障害ID 優先度ステータス    検出時間 サマリー
------ -------- --------- -------- -------
21862  HIGH     OPEN      19-03-11 データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'には 破損したブロックが1つ以上含まれています
  影響: 表領域USERS2内の一部のオブジェクトが使用できない可能性があります
  親の障害ID 21862に対する子の障害リスト
  障害ID 優先度ステータス    検出時間 サマリー
  ------ -------- --------- -------- -------
  21865  HIGH     OPEN      19-03-11 ブロック131 (データファイル18): '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'はメディア破損しています
    影響: オブジェクトT1 (BKTEST所有)は使用できない可能性があります

■修復スクリプトの生成
RMAN> advise failure;

データベース・ロール: PRIMARY

データベース障害のリスト
=========================

障害ID 優先度ステータス    検出時間 サマリー
------ -------- --------- -------- -------
21862  HIGH     OPEN      19-03-11 データファイル18: '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'には 破損したブロックが1つ以上含まれています
  影響: 表領域USERS2内の一部のオブジェクトが使用できない可能性があります
  親の障害ID 21862に対する子の障害リスト
  障害ID 優先度ステータス    検出時間 サマリー
  ------ -------- --------- -------- -------
  21865  HIGH     OPEN      19-03-11 ブロック131 (データファイル18): '/u01/app/oracle/oradata/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/datafile/o1_mf_users2_g8cqt3yj_.dbf'はメディア破損しています
    影響: オブジェクトT1 (BKTEST所有)は使用できない可能性があります

自動修復オプションを分析中です。これには少し時間がかかる場合があります
チャネルORA_DISK_1の使用
チャネルORA_DISK_2の使用
チャネルORA_DISK_3の使用
チャネルORA_DISK_4の使用
チャネルORA_DISK_5の使用
チャネルORA_DISK_6の使用
チャネルORA_DISK_7の使用
チャネルORA_DISK_8の使用
チャネルORA_DISK_9の使用
チャネルORA_DISK_10の使用
チャネルORA_DISK_11の使用
チャネルORA_DISK_12の使用
チャネルORA_DISK_13の使用
チャネルORA_DISK_14の使用
チャネルORA_DISK_15の使用
チャネルORA_DISK_16の使用
自動修復オプションの分析が完了しました

必須の手動アクション
========================
使用可能な手動アクションがありません

オプションの手動アクション
=======================
使用可能な手動アクションがありません

自動修復オプション
========================
オプション 修復 説明
------ ------------------
1      ブロック131 (ファイル18)のブロック・メディア・リカバリを実行します
  計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます
  修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_3037615942.hm

RMAN> repair failure preview;

計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます
修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_3037615942.hm

修復スクリプトの内容:
   # block media recovery
   recover datafile 18 block 131;

■修復の実行
RMAN> repair failure;

計画: 修復には、データが損失しない完全なメディア・リカバリが含まれます
修復スクリプト: /u01/app/oracle/diag/rdbms/sidb18a/sidb18a/hm/reco_3037615942.hm

修復スクリプトの内容:
   # block media recovery
   recover datafile 18 block 131;

この修復を実行しますか(YESまたはNOを入力してください)。 YES
修復スクリプトを実行しています

recoverを19-03-11で開始しています
チャネルORA_DISK_1の使用
チャネルORA_DISK_2の使用
チャネルORA_DISK_3の使用
チャネルORA_DISK_4の使用
チャネルORA_DISK_5の使用
チャネルORA_DISK_6の使用
チャネルORA_DISK_7の使用
チャネルORA_DISK_8の使用
チャネルORA_DISK_9の使用
チャネルORA_DISK_10の使用
チャネルORA_DISK_11の使用
チャネルORA_DISK_12の使用
チャネルORA_DISK_13の使用
チャネルORA_DISK_14の使用
チャネルORA_DISK_15の使用
チャネルORA_DISK_16の使用

チャネルORA_DISK_1: ブロックをリストアしています
チャネルORA_DISK_1: バックアップ・セットからリストアするブロックを指定しています
データファイル00018のブロックをリストアしています
チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/fast_recovery_area/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/backupset/2019_03_11/o1_mf_nnndf_TAG20190311T132556_g8crtonw_.bkpから読取り中です
チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/fast_recovery_area/SIDB18A/7C1A44C292701775E0532E97B90ADBAD/backupset/2019_03_11/o1_mf_nnndf_TAG20190311T132556_g8crtonw_.bkp タグ=TAG20190311T132556
チャネルORA_DISK_1: バックアップ・ピース1からブロックをリストアしました
チャネルORA_DISK_1: ブロックのリストアが完了しました。経過時間: 00:00:01

メディア・リカバリを開始しています
メディア・リカバリが完了しました。経過時間: 00:00:03

recoverを19-03-11で終了しました
障害の修復が完了しました

ここまでは、破損データブロックの番号を特定し、その特定されたデータブロック番号をRECOVERコマンドに指定していました。しかし、V$DATABASE_BLOCK_CORRUPTIONビューに現れるすべての破損データブロックを一括でリカバリする方法もあります。RECOVERコマンドにCORRUPTION LISTを指定すると、破損を把握しているすべてのデータブロックをリカバリします。

RMAN> recover corruption list;

3 ブロック・メディア・リカバリのリストア元

ブロック・メディア・リカバリを実施する場合、リカバリの起点となるデータブロックはどこからリストアされるのでしょうか。

データファイル単位のリストアの場合、第8回で説明したように増分バックアップからのリストアはlevel 0をリストアしたのち順次level 1をリストアしていきます。増分更新バックアップではlevel 0にlevel 1を適用したファイルをリストアします。

ブロック・メディア・リカバリでは、RMANで取得したデータファイルの他にも、フラッシュバック・ログが設定されていた場合はそこからリストアしようとします。RMANでデータファイルのバックアップを取得する頻度は、高速増分バックアップでも1日1回で運用している場合が多く、バックアップを取得してから時間が経過している(更新が多い)場合があります。しかし、フラッシュバック・ログにはRMANのバックアップよりも新しい更新の状態が記録されていることが期待できます。リストアするデータブロックが最新の状態に近いほど、リカバリで適用するREDOログも少なくて済みます。そのため、ブロック・メディア・リカバリではフラッシュバック・ログからリストアしようとします。

img-1

フラッシュバック・ログからリストアできない場合、データファイルのバックアップからリストアしようとします。ブロック・メディア・リカバリではlevel 0のバックアップからリストアします。そのため、level 1の増分バックアップを取得していても、増分更新バックアップを適用していなければ、level 0までさかのぼってリストアします。REDOログの適用はlevel 0のバックアップの時点からとなるので、アーカイブREDOログがlevel 0バックアップの時点からの分が保存されていなければいけません。

4 ファイル破損の自動修復

RMANのリカバリを実行することになったということは、破損データブロックにアクセスしようとしたSQLに何らかのエラーが返っています。しかし、Oracle Databaseは破損を検出したデータブロックを自動的に修復し、SQLにエラーを返さずに処理を継続できる機能があります。

4.1 Oracle Automatic Storage Management(ASM)

ASMはOracle Database専用のボリューム・マネージャ兼ファイルシステムとしての役割を担っており、Oracle Grid Infrastructureの機能として提供されています。ASMでは格納するファイルの冗長度をEXTERNAL(冗長化なし)、NORMAL(2重化)およびHIGH(3重化)から選択することができます。

NORMALまたはHIGHのASMディスクグループに格納されたファイルにアクセスした際に破損が検出されると、ミラーされた領域にアクセスしOracleクライアントにエラーを返すことなく処理を継続します。そして、破損が検出された領域はミラー領域のデータを使って自動的に修復されます。

img-1

4.2 自動ブロック・メディア・リカバリ

Oracle Databaseのリモート・レプリケーション機能であるOracle Active Data Guardを構成すると、プライマリ・データベースで更新されたREDOログの情報がスタンバイ・データベースに転送され、スタンバイ・データベースではそのREDOログでリカバリが実施されます。そのため、Oracle Active Data Guardではプライマリ・データベースとスタンバイ・データベースのデータブロックの中身が同一になります。

プライマリ・データベースでデータブロックの破損が検出されると、Oracleクライアントにエラーを返さずに、スタンバイ・データベースから正常なデータブロックを取得してプライマリ・データベースを修復します。そして、Oracleクライアントにはエラーを返さずに処理を継続します。

img-1

今回は、データファイルよりも小さな粒度であるデータブロックを単位としてリストア/リカバリが可能であるブロック・メディア・リカバリについて説明しました。ブロック・メディア・リカバリでは、破損個所以外の正常なデータブロックにはアクセス可能なまま、破損データブロックだけをリストア/リカバリすることができます。また、ASMやActive Data Guardを構成すると、破損を検出してもOracleクライアントにはエラーを返さずに処理を継続することが可能です。