Oracle Databaseのリフレッシュ可能なクローン機能を使いこなす ― パート1：基本概念と仕組みの解説

Oracle® Database 18c Enterprise Edition（クラウド版）は、Exadataなどのエンジニアード・システムと組み合わせることで、数多くの新機能と改良された機能を提供します。Release 18cでは、12c Release 2から搭載されていたリフレッシュ可能なクローン（Refreshable Clone）機能が強化され、迅速なスイッチオーバーやフェイルオーバーが可能になりました。さらに、マルチテナント環境において、スナップショット・カルーセル（Snapshot Carousel）を使用してプラガブル・データベース（PDB）のクローンや複製を作成することもできます。

本番環境では、スナップショット・カルーセルをリフレッシュ可能なクローンPDB機能と組み合わせることで、予期しない障害への備えや論理破損のトラブルシューティングなど、データベース管理者（DBA）の業務を大幅に効率化できます。本記事では、手動および自動スイッチオーバーのケースにおけるリフレッシュ可能なクローンの実践的な活用方法を解説します。スナップショット・カルーセル機能と併用することで、以下のようなデータベースの健全性に関する問題を特定し、対処できるようになります。

• 本番データベースが利用できない状態
• パフォーマンス問題
• Oracleデータベースにおける論理破損

本記事は全2回シリーズの第1回です。リフレッシュ可能なクローンPDBとは何か、どのように動作するのか、そしていつ使用すべきかについて学びましょう。

第2回では、リフレッシュ可能なクローンPDBの作成、構成、保守、削除といった具体的な操作手順を詳しく解説します。

クローンとスナップショットに関する基礎知識

まず、クローンとスナップショット・カルーセルに関する基本的な疑問に答えていきます。

クローニングとは？

インスタンスのクローンを作成するとは、そのバックアップを取得し、別の場所にリストアすることです。通常は、同じディレクトリ構造を持つ別のマシンにリストアします。また、OracleシステムID（SID）とデータベース名を変更すれば、同じマシン上にリストアすることも可能です。本番インスタンスのクローンをテストマシンで使用すれば、init.oraパラメータの変更やコード修正といった「もしも」のシナリオを、本番環境に影響を与えることなく安全に検証できます。

PDBクローニングの仕組み

PDBクローニングを使用すると、マルチテナント環境でPDBをクローンできます。ローカルまたはリモートのPDBに対しては、リフレッシュ可能なクローンやスナップショット・カルーセルを使って、ローカルのコンテナ・データベース（CDB）内にPDBクローンを作成します。

リモートPDBのクローニングについては、以下の点に注意してください。

• リフレッシュ可能なクローンを使用するには、対象PDBへのデータベース・リンクが必要であり、クローン側のデータベースは無効化された状態になります。
• スナップショット・カルーセルを使用する場合は、スナップショットを使って通常のPDBクローンを作成した後、データベース・リンク経由、またはアンプラグ＆プラグによって別のコンテナ・データベースへ移行します。クローンしたPDBからさらにリフレッシュ可能なクローンを作成することもできます。

PDBスナップショットとは？

PDBスナップショットは、ある時点におけるPDBのコピーです。CREATE PLUGGABLE DATABASE（またはALTER PLUGGABLE DATABASE）コマンドのSNAPSHOT句を使用して手動で作成するか、EVERY間隔句を使用して自動的に作成できます。

PDBスナップショット・カルーセルとは？

PDBスナップショット・カルーセルは、最新のPDBスナップショットのライブラリを保持する機能です。これにより、ポイント・イン・タイム・リカバリ（時点復元）やPDBのクローン作成に活用できます。

リフレッシュ可能なクローンPDB

リフレッシュ可能なクローン機能を使用すると、PDBをクローンできます。この機能は、リフレッシュ間隔とREDO生成率に応じて最小限のデータ損失で、データ破損や災害からデータベースを保護します。リフレッシュ可能なクローン・データベースはレプリカとして利用でき、負荷の低い重要度の低いアプリケーションをそこで稼働させることも可能です。リフレッシュ可能なクローン・データベースは、REDOログの適用により、一定間隔での自動更新または手動更新を設定できます。

図1は、リフレッシュ可能なクローン処理のアーキテクチャを示しています。主要なコンポーネントとプロセス、そして本番データベースとリフレッシュ可能なクローン・データベースの関係が描かれています。この図では、コンテナ・データベースCDB1のプラガブル・データベースPDB1を、別のコンテナ・データベースCDB2へクローンしており、その結果、PDB1_REF_CLONEという名前のホットクローン版PDB1が作成されます。

図1

リフレッシュ・モードのオプション

以下のモードを設定することで、リフレッシュ・モードを変更できます。

• MANUAL（手動）
• AUTOMATIC（自動：EVERY n MINUTESを使用）
• NONE（なし）

リフレッシュ可能なクローンの作成と運用

次のステートメントを使用すると、ソースPDBをクローンし、そのクローンをリフレッシュ可能な状態に構成できます。クローンPDBをリフレッシュすると、前回のREDOログ適用以降に蓄積されたREDOデータで更新されます。

CREATE PLUGGABLE DATABASE ... REFRESH MODE [ MANUAL / AUTOMATIC (using EVERY n MINUTES) / NONE ] ;

次のステートメントを使用すると、リフレッシュ済みまたは無効化されたリフレッシュ可能なクローンの現在のモードを変更し、完全に機能するPDBへ変換できます。

ALTER PLUGGABLE DATABASE ... REFRESH MODE [ MANUAL / AUTOMATIC (using EVERY n MINUTES) / NONE ] ;

PDBを頻繁にクローンしなければパフォーマンス低下を回避できますが、その一方でクローンのデータは古くなってしまいます。リフレッシュ可能なクローンPDBはこの問題を解決します。リフレッシュ可能なクローンが古くなった場合でも、最新のREDOですばやくリフレッシュできます。

一般的には、本番PDBの「マスター」となるリフレッシュ可能なクローンを1つ維持し、そのマスターから開発・テスト用のスナップショット・クローンを作成します。

次のステートメントを使用すると、ソースPDBとクローンPDBの役割を逆転できます。

ALTER PLUGGABLE DATABASE ... SWITCHOVER;

このスイッチオーバー処理は、図2および図3のように簡略化できます。

図2

図3

このスイッチオーバー機能は、以下のような状況で特に役立ちます。

計画的なスイッチオーバー

図3において、ソースPDBであるPDB1をホストするCDB1は、クローンPDBであるPDB1_REF_CLONEをホストするCDB2よりも、大幅に高い負荷がかかる可能性があります。より良い負荷分散を実現するために、クローンを新しいソースPDBに、ソースPDBを新しいクローンに変換することで、PDBの役割を入れ替えることができます。

この役割の切り替えは、現在のプライマリ・データベースで次のコマンドを実行して行います。

ALTER PLUGGABLE DATABASE PDB1 REFRESH MODE EVERY 2 MINUTES FROM PDB1_REF_CLONE@DBLINK2CDB2 SWITCHOVER;

このコマンドが完了すると、CDB2内のPDB1_REF_CLONEがプライマリの役割を引き継ぎます。CDB1は以後レプリカを維持します。本番へのすべての接続は、新しいプライマリであるCDB2に向けられます。リフレッシュがソースのREDO生成率に追いついていた場合、失われるトランザクションは最大2分間分です。

計画外のスイッチオーバー

ソースPDBに計画外の障害が発生した場合でも、クローンPDBを新しいソースPDBに切り替えて、通常の運用を再開できます。

必ず現実的なトランザクション量で環境をテストし、レプリカのリフレッシュ処理がREDO生成率に追いつけることを確認してください。

リフレッシュ可能なクローンとData Guardの違い

Oracleは、Data Guardとスタンバイ・データベースによる高可用性機能を提供しています。リフレッシュ可能なクローンとData Guardを区別する主な要素は以下の通りです。

• Data Guardは、スタンバイ・データベースへのスイッチオーバーおよびフェイルオーバーを提供することで、災害やデータ破損からリアルタイムにデータベースを保護する高可用性を実現します。また、リフレッシュ可能なクローンPDB機能を使えば、Data Guardスタンバイ・データベースを負荷分散にも利用できます。ただし、Data GuardはCDBレベルで動作するため、PDBレベルでのスイッチオーバーやフェイルオーバーは実行できません。
• スイッチオーバーの開始から完了までのラグ（遅延）があるため、単にリフレッシュ可能なクローンを維持するよりもData Guardの方が効果的です。このラグの間に、プライマリ・データベースへのトランザクションが、役割を切り替える前に読み取り専用データベースへ適用・同期されない場合があり、その結果、それらのトランザクションを失う可能性があります。
• Data Guardには最大30のスタンバイ・データベースという上限がありますが、リフレッシュ可能なクローンは必要な数だけ作成できます。

リフレッシュ可能なクローンPDB機能を高可用性目的で強化し、ほぼデータ損失ゼロを実現するには、REMOTE_RECOVERY_FILE_DESTパラメータを設定して、ソースPDBのログ格納場所をアーカイブ先として指定します。

まとめ

高可用性の観点から、リフレッシュ可能なクローンPDB機能をData Guardの代替とみなすべきではありません。しかし、リフレッシュ可能なクローンを使用すれば、別のサーバー上にレプリカ・データベースを維持することができます。

本記事では、スイッチオーバーが計画的なものであれ計画外のものであれ、リフレッシュ可能なPDBをレプリカとして活用し、負荷の低い重要度の低いアプリケーションの運用を再開する方法を解説しました。スイッチオーバーを検討する際は、目標復旧時間（RTO：運用再開までの時間）と目標復旧時点（RPO：最小限のデータ損失の達成）の観点から評価することを忘れないでください。

シリーズ第2回では、リフレッシュ可能なクローン機能の実際のデモを紹介します。

フィードバックタブからコメントやご質問をお寄せください。今すぐチャットを開始して会話を始めることもできます。

データベースに関する詳細情報はこちらをご覧ください。