Active Data Guardの革新的アップデート！PDBリカバリ分離を検証してみた

2021年8月、待望のOracle Database 21cがオンプレミスでリリースされ、200以上の新機能が実装されてコンバージド・データベースとしての第一歩を踏み出しました。
今回は21cから実装されたActive Data Guard（※）におけるリカバリの新機能をご紹介します。

Active Data Guard構成におけるプラガブル・データベース（以下、PDB）ごとのリカバリ動作が、従来（19c以下）と21cでは大きく異なり、よりシステム継続性を高めて参照系としてのActive Data Guardのリソースを最大限に活用できるようになりました。

※Active Data Guard...「Oracle Active Data Guard」オプションのご契約が必要です。

Active Data Guardの『PDBリカバリ分離』とは

Oracle Database 21c以降、Oracle Databaseはマルチテナント・コンテナ・データベース（以下、CDB）とPDBから構成される、いわゆるマルチテナント構成が標準となりました。

マルチテナント構成のデータベースではPDBごとにリカバリが行え、特定時間への不完全リカバリ（Point-in-Timeリカバリ）が可能です。
21cではActive Data Guardの構成において、このPDBごとのPoint-in-Timeリカバリの動作に新たな動作が加わりました。

PDBリカバリ分離

19cまでData GuardにおけるPDBのPoint-in-Timeリカバリを行う場合、プライマリサイトだけでなくスタンバイサイトのPDBについても、別途バックアップファイルのリストアやフラッシュバック・データベースが有効である必要がありました。

Oracle® Data Guard
概要および管理 19c
15.10 プライマリでのPDB PITRまたはPDBフラッシュバック後にスタンバイで必要なアクション

スタンバイサイトのPDBがリストアされていない場合、プライマリサイトのPoint-in-Timeリカバリ後のREDOをスタンバイサイトで検知するとMRPプロセスはORA-39874を伴い停止してしまいます。

PDB リカバリ

■プライマリサイトのPDBがPoint-in-Timeリカバリされた後の、スタンバイサイトのアラートログ

　
　2021-11-09T19:02:51.021026+09:00
　(3):Recovery of pluggable database PDB1 aborted due to pluggable database open resetlog marker.
　(3):To continue recovery, restore all data files for this PDB to checkpoint SCN lower than 2147890, or timestamp before 11/09/2021 18:53:00, and restart recovery
　PR00 (PID:1860): MRP0: Detected orphaned datafiles!
　PR00 (PID:1860): Recovery will possibly be retried after pluggable database flashback...
　2021-11-09T19:02:51.022776+09:00
　Errors in file /u01/app/oracle/diag/rdbms/orcls/orcls/trace/orcls_pr00_1860.trc:
　ORA-39874: プラガブル・データベースPDB1のリカバリが停止しました
　ORA-39873: すべてのデータ・ファイルを2147890より下位のチェックポイントSCNにリストアしてください。
　PR00 (PID:1860): Managed Standby Recovery not using Real Time Apply
　Recovery interrupted!
　Recovered data files to a consistent state at change 2150805
　stopping change tracking
　2021-11-09T19:02:51.126833+09:00
　Errors in file /u01/app/oracle/diag/rdbms/orcls/orcls/trace/orcls_pr00_1860.trc:
　ORA-39874: プラガブル・データベースPDB1のリカバリが停止しました
　ORA-39873: すべてのデータ・ファイルを2147890より下位のチェックポイントSCNにリストアしてください。
　2021-11-09T19:03:11.252427+09:00
　MRP0 (PID:1850): Recovery coordinator encountered one or more errors during automatic flashback on standby
　2021-11-09T19:03:11.252503+09:00
　Background Media Recovery process shutdown (orcls)

21cのActive Data Guardでは、スタンバイサイトのPDBのメディアリカバリを、PDBごとに独立して行うことができます。
この動作をPDBリカバリ分離と呼びます。

Oracle® Data Guard
概要および管理 21c
15.11 Active Data Guard環境でのPDB PITRまたはPDBのフラッシュバック後のリカバリ

プライマリサイトのPDBにてホット・クローニング、Point-in-Timeリカバリ、またはフラッシュバック・データベースが行われた場合、スタンバイサイトでその操作が検出されると次のようなステップでメディアリカバリが行われます。

プライマリサイトでのホット・クローニング、Point-in-Timeリカバリ、またはフラッシュバック・データベースを検知したスタンバイサイトのPDBは一時的に無効としてマークされ、その間もCDBのメディアリカバリが続行されます。
別個のバックグラウンドセッションで上記のPDBが自動的にリカバリされます。これがPDBリカバリ分離の動作です。
PDBリカバリ分離の完了後に上記のPDBが有効化されます。
CDBのメディアリカバリとPDBリカバリ分離のセッションがマージされます。

PDBリカバリ分離

なお、PDBリカバリ分離を動作させるにはスタンバイサイトのCDBがOPENしている必要があるため、前述のとおりActive Data Guardに限定された機能となります。

『PDBリカバリ分離』を検証

それでは、実際にプライマリサイトのPDBをメディアリカバリし、スタンバイサイトで行われるPDBリカバリ分離の動作を確認してみましょう。

1. 事前にバックアップを準備

検証前にプライマリサイトでPDBのバックアップ、およびバックアップ以降のアーカイブREDOログファイルとリカバリポイントまでのアーカイブREDOログファイルに不足がないことを確認しておきます。

■プライマリサイトのデータベースへRMANで接続の上、バックアップファイルが存在することを確認

　
　RMAN> list backup of pluggable database PDB1;
　 
　 
　バックアップ・セットのリスト
　===================
　 
　 
　BS Key  Type LV Size      Device Type Elapsed Time 終了時間
　------- ---- -- ---------- ----------- ------------ -----------------
　10      Full    96.52M     DISK            00:00:14 21-10-24 12:10:32
　        BPキー: 10   ステータス: AVAILABLE  圧縮: YES  タグ: TAG20211024T120913
　        ピース名: /u01/app/oracle/fast_recovery_area/ORCL/CDE731F60ADA2702E0536E38A8C0801D/backupset/2021_10_24/o1_mf_nnndf_TAG20211024T120913_jq9mntsj_.bkp
　  バックアップ・セット10のデータファイルのリスト
　  コンテナID: 3、PDB名: PDB1
　  File LV Type Ckp SCN   Ckp時間        Abs Fuz SCN Sparse Name
　  ---- -- ---- ---------- ----------------- ----------- ------ ----
　  9       Full    4007726   21-10-24 12:10:18             NO   /u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_system_jp2j3rhn_.dbf
　  10      Full    4007726   21-10-24 12:10:18             NO   /u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_sysaux_jp2j3rhx_.dbf
　  11      Full    4007726   21-10-24 12:10:18             NO   /u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_undotbs1_jp2j3rhz_.dbf
　  12      Full    4007726   21-10-24 12:10:18             NO   /u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_users_jp2j4qhd_.dbf

■バックアップ以降、およびリカバリポイントまでのアーカイブREDOログファイルが存在することを確認

　
　RMAN> list archivelog all;
　 
　リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
　データベースdb_unique_name ORCLのアーカイブ・ログ・コピーのリスト
　=====================================================================
　 
　Key     Thrd Seq     S Low時間
　------- ---- ------- - -----------------
　66      1    36      A 21-10-18 16:39:18
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_36_jq9l9r6q_.arc
　 
　69      1    37      A 21-10-24 11:47:19
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_37_jq9lg79o_.arc
　 
　70      1    38      A 21-10-24 11:49:43
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_38_jq9lnl4f_.arc
　 
　73      1    39      A 21-10-24 11:53:06
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_39_jq9mqvdz_.arc
　 
　74      1    40      A 21-10-24 12:11:55
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_40_jq9mr0xp_.arc
　 
　76      1    41      A 21-10-24 12:12:00
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_41_jq9mr52s_.arc
　 
　78      1    42      A 21-10-24 12:12:05
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_42_jq9mr5xw_.arc
　 
　80      1    43      A 21-10-24 12:12:05
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_43_jq9mr834_.arc
　 
　82      1    44      A 21-10-24 12:12:08
　        名前: /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_44_jq9mrc7r_.arc

2. リカバリ対象のPDBを停止

プライマリサイトでリカバリ対象のPDBを停止させます。
この時、CDBや他のPDBは稼働させたままであることに注意してください。
また、スタンバイサイトの該当PDBもOPENさせたままで問題ありません。

■プライマリサイトでリカバリ対象のPDBを停止させる

　
　SQL> alter session set container=PDB1;
　
　セッションが変更されました。
　
　SQL> shutdown abort
　プラガブル・データベースがクローズされました。

■プライマリサイトのPDBが停止した時のアラートログファイルの出力

　　
　2021-10-24T12:15:26.999403+09:00
　PDB1(3):ALTER PLUGGABLE DATABASE CLOSE ABORT
　2021-10-24T12:15:27.015448+09:00
　PDB1(3):Pluggable database PDB1 abort closing
　PDB1(3):JIT: pid 2728 requesting stop
　2021-10-24T12:15:27.021353+09:00
　PDB1(3):PDB Close Abort marking the Control File to indicate pdb 3 as aborted for tno 1
　PDB1(3):Buffer Cache invalidation for PDB 3 started
　PDB1(3):Buffer Cache invalidation for PDB 3 completed
　2021-10-24T12:15:27.538175+09:00
　PDB1(3):While transitioning the pdb 3 to clean state, clearing all its abort bits in the control file.
　Pluggable database PDB1 closed
　PDB1(3):Completed: ALTER PLUGGABLE DATABASE CLOSE ABORT

3. PDBをPoint-in-Timeリカバリする

プライマリサイトのPDBをPoint-in-Timeリカバリします。
今回はUNTIL TIME句を使用した時間指定のコマンドでリカバリを実行しました。

■プライマリサイトのPDBを「2021年 10月24日 12時12分」時点までリカバリする

　
　RMAN> run {
　2> set until time '21-10-24 12:12:00';
　3> restore pluggable database pdb1;
　4> recover pluggable database pdb1;
　5> }
　 
　実行コマンド: SET until clause
　 
　restoreを21-10-24 14:28:02で開始しています
　チャネルORA_DISK_1の使用
　 
　チャネルORA_DISK_1: データファイル・バックアップ・セットのリストアを開始しています
　チャネルORA_DISK_1: バックアップ・セットからリストアするデータファイルを指定しています
　チャネルORA_DISK_1: データファイル00009を/u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_system_jp2j3rhn_.dbfにリストア しています
　チャネルORA_DISK_1: データファイル00010を/u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_sysaux_jp2j3rhx_.dbfにリストア しています
　チャネルORA_DISK_1: データファイル00011を/u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_undotbs1_jp2j3rhz_.dbfにリスト アしています
　チャネルORA_DISK_1: データファイル00012を/u01/app/oracle/oradata/ORCL/CDE731F60ADA2702E0536E38A8C0801D/datafile/o1_mf_users_jp2j4qhd_.dbfにリストアしています
　チャネルORA_DISK_1: バックアップ・ピース/u01/app/oracle/fast_recovery_area/ORCL/CDE731F60ADA2702E0536E38A8C0801D/backupset/2021_10_24/o1_mf_nnndf_TAG20211024T120913_jq9mntsj_.bkpから読取り中です
　チャネルORA_DISK_1: ピース・ハンドル=/u01/app/oracle/fast_recovery_area/ORCL/CDE731F60ADA2702E0536E38A8C0801D/backupset/2021_10_24/o1_mf_nnndf_TAG20211024T120913_jq9mntsj_.bkp タグ=TAG20211024T120913
　チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
　チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:25
　restoreを21-10-24 14:28:28で終了しました
　 
　recoverを21-10-24 14:28:28で開始しています
　チャネルORA_DISK_1の使用
　 
　 
　メディア・リカバリを開始しています
　 
　スレッド1 (順序39)のアーカイブ・ログは、ファイル/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_39_jq9mqvdz_.arcとしてディスク にすでに存在します
　スレッド1 (順序40)のアーカイブ・ログは、ファイル/u01/app/oracle/fast_recovery_area/ORCL/archivelog/2021_10_24/o1_mf_1_40_jq9mr0xp_.arcとしてディスク にすでに存在します
　メディア・リカバリが完了しました。経過時間: 00:00:00
　recoverを21-10-24 14:28:29で終了しました

4. PDBをOPEN RESETLOGSでOPENする

Point-in-Timeリカバリ後は、適用されなかったREDOの情報を破棄するためにOPEN RESETLOGS句でプライマリサイトのPDBをOPENします。

■プライマリサイトでリカバリが完了したPDBをOPENする

　
　RMAN> alter pluggable database PDB1 open resetlogs;
　文が処理されました

プライマリサイトでリカバリ対象のPDBをOPENすると、スタンバイサイトではPoint-in-Timeリカバリを検知し、PDBリカバリ分離のセッションを開始します。

■プライマリサイトのPDB1がOPENした後の、スタンバイサイトのアラートログファイルの出力

　
　2021-10-24T14:29:46.456754+09:00
　PR00 (PID:1919): PDB unplug/drop/rename marker encountered. Retry recovery... [krd.c:27120]
　2021-10-24T14:29:46.456925+09:00
　Errors in file /u01/app/oracle/diag/rdbms/orcls/orcls/trace/orcls_pr00_1919.trc:
　ORA-65112: プラガブル・データベースPDB1はスタンバイ・データベースのすべてのインスタンスでクローズしていません
　PR00 (PID:1919): Managed Recovery not using Real Time Apply [krsm.c:15876]
　Recovery interrupted!
　Recovered data files to a consistent state at change 4035682
　Stopping change tracking
　2021-10-24T14:29:46.580674+09:00
　Errors in file /u01/app/oracle/diag/rdbms/orcls/orcls/trace/orcls_pr00_1919.trc:
　ORA-65112: プラガブル・データベースPDB1はスタンバイ・データベースのすべてのインスタンスでクローズしていません
　2021-10-24T14:29:46.723676+09:00
　alter pluggable database "PDB1" close immediate
　2021-10-24T14:29:46.724903+09:00
　PDB1(3):Pluggable database PDB1 closing
　PDB1(3):JIT: pid 1917 requesting stop
　PDB1(3):Buffer Cache flush started: 3
　PDB1(3):Buffer Cache flush finished: 3
　Pluggable database PDB1 closed
　Completed: alter pluggable database "PDB1" close immediate
　・・・中略・・・
　2021-10-24T14:30:08.699525+09:00
　PDB1(3):PDB Side Media Recovery started for pdbid(3)
　PDB1(3):.... (PID:4053): Managed Recovery starting Real Time Apply [krsm.c:15865]
　・・・中略・・・
　2021-10-24T14:30:18.946619+09:00
　PDB1(3):.... (PID:4053): Side Recovery Complete [krds.c:1584]
　2021-10-24T14:30:39.219431+09:00
　all data files of pdbid 3 are brought online.
　 Started logmerger process
　2021-10-24T14:30:39.241602+09:00
　 
　IM on ADG: Start of Empty Journal
　 
　IM on ADG: End of Empty Journal
　PR00 (PID:4055): Managed Recovery starting Real Time Apply [krsm.c:15865]
　max_pdb is 5
　2021-10-24T14:30:39.306948+09:00
　Parallel Media Recovery started with 2 slaves

「PDB名(CON_ID)」の出力（上述であれば「PDB1(3)」）に、「PDB Side Media Recover started」という出力があり、PDBリカバリ分離によるリカバリセッションが開始されたことが確認できます。
その後、「Side Recovery Complete」とリカバリが無事完了した旨が記録されておりました。

まとめ

今回紹介させていただいたPDBリカバリ分離の実装により、Active Data GuardであればスタンバイサイトのCDBおよび他PDBに影響なくPDBごとのリカバリが可能となりました。
これにより、統合基盤として利用されるデータベースにおいても可用性を高めることができると考えられます。

また、PDBのリカバリにおいてスタンバイサイトでは他PDBの停止が不要である点から、Active Data Guardという参照系のリソースを最大限活用できる、大きな機能改善であるとも理解しています。

Active Data Guardは19cからはスタンバイサイトでも更新処理が行えるようになるなど（参考：【Oracle Database】DMLリダイレクションで一歩進んだ Active Data Guard の使い方（19c新機能））、年々その機能が改善、拡張されていることから、使いこなすことで活用の幅が大きく広がることが期待できます。

現在災害対策サイトとしてのData Guardをご利用いただいているお客様も、障害時までそのリソースを眠らせておくだけでなくActive Data Guardという新たな活用方法をご検討いただく上でのご参考となれば幸いです。

　　Oracle Databaseに関する問い合わせはこちら　

執筆者情報

中垣佳祐

アシスト北海道

2016年アシスト北海道へ入社後、Oracle Databaseのサポート業務に従事。入社2年目より夜間休日帯など営業時間外の緊急対応を主に担当。現在は通常時間帯のサポート業務を担当しており、第一線で日々奮闘中。...show more

■本記事の内容について
　本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。

【Oracle AI Database 26ai】同時リフレッシュでON COMMITマテリアライズド・ビューのenqueue待ちにサヨナラ！OLTP／DWHスループットを実測検証

本記事では、従来のON COMMIT MViewが抱えてきたこのようなスループット低下や待機イベントのボトルネックを振り返りつつ、Oracle AI Database 26aiが提供する「同時リフレッシュ（Concurrent Refresh）」によって、OLTP／DWHそれぞれのユースケースでどのような改善が見込めるのかを検証していきます。