Oracle Databaseのリフレッシュ可能クローン活用ガイド ― パート2：実践デモンストレーション

シリーズ第1部では、Oracle®のリフレッシュ可能クローン（Refreshable Clone）の概要と、その使用場面・採用理由について紹介しました。本記事では、Oracle 18cにおいてリフレッシュ可能クローンのプラッガブル・データベース（PDB）をセットアップ、構成、保守、そして削除する方法を、実際のデモンストレーションを通じて解説します。

リフレッシュ可能クローンPDBの前提条件

このデモンストレーションに沿って進めるには、以下の前提条件を満たしておく必要があります。

1. 新規作成するリフレッシュ可能クローンが、ローカルまたはリモートのコンテナを指すデータベースリンクを持っていること。
2. archive_log_modeをenabledに設定していること。
3. エンジニアード・システムまたはEnterprise Edition（EE）のOracle Cloudを使用すること。同一プラットフォームやバージョンで利用できない場合は、このデモンストレーション用に非公開パラメータ_exadata_feature_onをTrueに設定します。
4. local_undo_modeをenabledに設定していること。

リフレッシュ可能PDBはCLOSEDまたはOPEN READ ONLYモードで設定でき、リフレッシュ後はOPEN READ ONLYモードでクエリに利用できます。

環境

このデモンストレーションでは、環境が以下の仕様に合致していることを確認してください。

• Oracle 18cをインストールし、マシンとデータベースに対して前提条件の設定を済ませておく。
• 本番データベースの役割：
  ・コンテナ・データベース（CDB）名：YCDB1
  ・PDB名：PURCH_PDB
• リフレッシュ可能クローンPDBの役割：
  ・CDB名：XCDB1
  ・PDB名：PDB2_REFRO
  ・PDBを30分ごとに自動リフレッシュするよう設定
• XCDB上でcreate_pdbを使用してパブリック・データベースリンクを作成する。リンクはYCDB上のPURCH_PDBを指す必要があります。

まず、以下のTransparent Network Substrate（TNS）コマンドを実行します。

purch_pdb=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = tejashost2.localdomain)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = purch_pdb)))

XCDB1=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = tejashost2.localdomain)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XCDB1)))

YCDB1=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = tejashost2.localdomain)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = YCDB1)))

デモンストレーション

このデモンストレーションでは、以下の作業を行います。

• 環境をセットアップする。
• 本番データベースのリフレッシュモードを確認する。
• リフレッシュ可能クローンのリフレッシュモードの確認方法と、クローン側でのリフレッシュ無効化の手順を示す。
• 本番データベースとリフレッシュ可能クローン間の切り替え（スイッチオーバー）を行う。

リフレッシュ可能クローン環境のセットアップ

リフレッシュ可能クローン環境では、以下の操作を実施します。

YCDB1での操作

1. 本番データベースを作成し、オープンします。

2. impdpユーティリティを使用してEXPDPダンプからデータをインポートするか、HRスキーマをPURCH_PDBにインポートします。この例では、データベース上で次のスクリプトを実行してHRスキーマをインポートします。

@?/demo/schema/human_resources/hr_main.sql

処理が完了したら、次の図のようにHRスキーマの詳細を検証します。

XCDB1での操作

1. 本番データベースPURCH_PDBを指すデータベースリンクを作成します。
2. リフレッシュ可能PDBを作成し、リフレッシュ間隔を30分に設定した後、データが正しくリフレッシュされていることを検証します。

別の場所にデータベースを作成する目的でPDBを作成する場合も、通常のPDB作成時に使えるすべての属性を利用できます。たとえば、PDBのデータファイル配置先を変更したい場合は、CREATE_FILE_DESTやFILE_NAME_CONVERTを使用します。

唯一の追加要素がREFRESH MODE属性です。このデモンストレーションをシンプルに保つため、オプション属性は追加していません。

リフレッシュモードと本番データベースの詳細を確認する

DBA_PDBS表をクエリすることで、リフレッシュ可能PDBのモード、ステータス、最終リフレッシュSCN、および親となる本番データベースの詳細を確認できます。PDB2_REFRO PDBの場合の出力例は次のとおりです。

作業完了後は、スケジュールに従って継続的にリフレッシュできるよう、リフレッシュ可能PDBをMOUNTEDモードに戻す必要があります。この操作には以下のコマンドを使用します。ここで使用しているopen_mode.sqlは、データベースの現在のopen_modeを確認するためのクエリです。

リフレッシュのためにデータベースインスタンスをクローズしていなかった場合、次のエラーが表示されることがあります。

ORA-65025: Pluggable database is not closed on all instances

リフレッシュ可能クローンのリフレッシュモードを変更する

リフレッシュ可能クローンのモードは、以下のように変更できます。

• 手動リフレッシュから自動リフレッシュへの変更
• 自動リフレッシュから手動リフレッシュへの変更
• 自動または手動リフレッシュモードからのリフレッシュ無効化

手動リフレッシュから自動リフレッシュへの変換（およびその逆）

注意：別のPDBにログインした状態では、PDBのリフレッシュモードを変更できません。たとえば、YPDBにログイン中にXPDBのモードを変更することはできません。試みると、次のエラーが発生します。

ORA-65118: operation affecting a pluggable database cannot be performed from
another pluggable database.

手動リフレッシュモードでは、次のコマンドを使って必要なタイミングでクローンPDBをリフレッシュできます。

PDBリフレッシュの無効化と、読み取り専用クローンの読み書き可能データベースへの変換

PDBのリフレッシュモードを無効にすると、リフレッシュ可能クローンを読み書き可能モードに変換できます。

注意：プラッガブル・データベースのリフレッシュを無効にした後は、再度有効にすることができません。リフレッシュ可能PDBとして運用したい場合は、PDBを再作成する必要があります。NONEリフレッシュモードからリフレッシュモードへ変換しようとすると、次のエラーが表示されます。

ORA-65261: pluggable database PDB2_REFRO3 not enabled for refresh.

リフレッシュを無効にすると、PDBは読み書きアクセス可能になります。

本番からリフレッシュ可能クローンへの切り替え（およびその逆）

Oracle 18cより前のバージョンでは、プライマリをシャットダウンして読み取り専用でオープンするなど、ロール切り替えに必要なすべての手順を手動で実行する必要がありました。

このデモンストレーションでは、以下の手順を実行します。

1. grant connectおよびsysoper権限を付与して、コンテナ・データベースXCDB1とYCDB1にユーザーC##SWITCHUSERを作成します。
2. 相手側のコンテナ・データベースを指すデータベースリンク（dblink）を作成します。YCDB1では、XCDB1に接続するdblink XCDB1SYSOPERを作成します。リンク作成後は、データベースビューDBA_DB_LINKSとV$DATABASEを使用してデータベースの詳細情報を収集します。
3. リフレッシュ可能クローン・データベースを読み取り専用でオープンします。
4. スイッチオーバー・コマンドを実行します。
5. 本番とリフレッシュ可能クローンの切り替え後、データベースのステータスとオープンモードを検証します。

YCDB1での操作

スイッチオーバー・コマンドを実行する前に、前提条件の1〜3を完了させておいてください。

データベースリンクの詳細：

XCDB1での操作

DBA_DB_LINKSとV$DATABASEを使用してデータベースリンクの詳細を確認し、データベースのオープンモードを把握します。

スイッチオーバー完了後、元のソースPDBであったPURCH_PDBがリフレッシュ可能クローンPDBに変わります。このPDBは現在MOUNTステータスにあり、今後はREAD ONLYモードでのみオープンできます。一方、元のリフレッシュ可能クローンであったPDB PDB2_REFROはREAD/WRITEモードでオープンされ、ソースPDBとして機能するようになります。

まとめ

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

本記事では、スイッチオーバーが計画的なものであれ計画外のものであれ、低負荷かつクリティカル度の低いアプリケーション操作を迅速に再開できるよう、リフレッシュ可能PDBをレプリカとして活用する方法を解説しました。切り替えを検討する際は、目標復旧時間（RTO：操作再開までの時間）と目標復旧時点（RPO：最小限のデータ損失の達成など）の観点から評価することが重要です。

コメントやご質問がある場合は、フィードバックタブからお気軽にお寄せください。チャットで会話を始めることもできます。

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