Oracle Databaseで本番環境に近いテスト用・開発用データベースを維持しようとすると、定期的なコピーや再作成に時間と運用負荷がかかることがあります。特にデータ量が大きい環境では、毎回Pluggable Database（PDB）を最初から複製する運用は効率的とはいえません。
このような用途で利用できるのが、Oracle DatabaseのRefreshable Clone PDBです。一般に「PDB Refresh」と呼ばれることもある仕組みで、ソースPDBから作成したクローンを、前回以降に蓄積されたREDOを利用して更新できます。開発・テスト環境向けのコピーを継続的に新しい状態へ近づけたい場合に有効な機能です。
Oracle DatabaseのPDB Refreshとは
Oracle Databaseでは、CREATE PLUGGABLE DATABASE ... REFRESH MODEを使用して、ソースPDBからRefreshable Clone PDBを作成できます。Oracleの公式ドキュメントによれば、Refreshable Clone PDBをリフレッシュすると、前回のREDO適用以降に蓄積されたREDOを利用してクローン側を更新します。
通常のPDBクローンでは、最新状態が必要になるたびに新しいクローンを作成すると、データ量によっては時間やI/O負荷が大きくなります。一方、Refreshable Clone PDBでは既存クローンに差分となる変更を反映できるため、同じ環境を継続的に更新する運用を構築しやすくなります。
OracleもRefreshable Clone PDBの代表的な用途として、本番PDBの「golden master」となる更新可能なクローンを維持し、そこから開発・テスト用のクローンを作成する方法を説明しています。
[参照] Oracle Databaseドキュメント：Cloning a PDB
PDB Refreshでテスト環境の更新を簡略化できる理由
テスト環境を本番環境に近い状態へ更新する場合、毎回フルコピーを作成する方式では、コピー対象となるPDBが大きくなるほど作業時間やシステム負荷が増加します。更新頻度を下げれば負荷は軽減できますが、その代わりテスト環境のデータが古くなってしまいます。
Refreshable Clone PDBでは、最初にソースPDBからクローンを作成した後、以降の変更をREDOによって反映できるため、毎回PDB全体を作り直す必要を減らせます。これにより、比較的新しい本番データを反映した検証用の基準環境を維持しやすくなります。
例えば、毎週月曜日に本番PDBからテスト環境をフルコピーしていた運用を考えてみます。データ量が増えるにつれてコピー処理に数時間かかるようになると、更新作業そのものが負担になります。Refreshable Clone PDBを利用すれば、ソースとの差分を定期的に適用する構成に変更できるため、テスト用環境を更新する手順を簡素化できます。
手動リフレッシュと自動リフレッシュの2つの方法がある
Refreshable Clone PDBには、手動更新と自動更新の2種類のリフレッシュモードがあります。用途やテストスケジュールに合わせて選択できます。
| モード | 指定例 | 用途 |
|---|---|---|
| 手動リフレッシュ | REFRESH MODE MANUAL |
必要なタイミングだけ管理者が更新したい場合 |
| 自動リフレッシュ | REFRESH MODE EVERY 60 MINUTES |
一定間隔で自動的に最新状態へ近づけたい場合 |
| リフレッシュなし | REFRESH MODE NONE |
通常の更新不可なクローンとして利用する場合 |
手動モードでは、必要なタイミングでALTER PLUGGABLE DATABASE REFRESHを実行して更新します。テスト開始前だけ最新状態にしたい場合や、更新タイミングを厳密に管理したい場合に向いています。
自動モードでは、REFRESH MODE EVERY 60 MINUTESのように更新間隔を分単位で指定できます。Oracleの公式ドキュメントでも、自動リフレッシュと手動リフレッシュの双方がサポートされています。
[参照] Oracle Database 21c：Automatic and Manual Refresh Modes
Refreshable Clone PDBを作成する基本例
例えば、リモートにあるPRODPDBというPDBから、60分ごとに更新されるTESTPDB_REFRESHを作成する場合は、概念的には次のようなSQLになります。
CREATE PLUGGABLE DATABASE TESTPDB_REFRESH FROM PRODPDB@prod_link REFRESH MODE EVERY 60 MINUTES;
この例では、prod_linkというデータベースリンク経由でソースPDBに接続し、Refreshable Clone PDBを作成しています。Oracleのドキュメントでは、Refreshable Clone PDBの作成にはデータベースリンクが必要であり、リンク先は同じCDBでも別のCDBでも構成可能とされています。
手動更新にしたい場合は、作成時にREFRESH MODE MANUALを指定します。その後、更新したいタイミングでクローンPDBを閉じ、ALTER PLUGGABLE DATABASE REFRESHを実行する流れになります。
リフレッシュ時はPDBを閉じる必要がある
PDB Refreshを利用するうえで重要なのが、リフレッシュ処理中のPDB状態です。Oracleの仕様では、Refreshable Clone PDBをリフレッシュするときはPDBが閉じている必要があります。
自動リフレッシュの予定時刻にPDBが開いている場合、リフレッシュ処理はその時点では実行されず、次回へ延期されます。手動リフレッシュ時にPDBが開いている場合にはエラーになります。
また、Refreshable Clone PDBは通常、更新していない間はREAD ONLYで開くことができます。これは、クローン側だけに独自の変更が発生し、ソースPDBとの整合性が崩れるのを防ぐためです。
そのため、アプリケーションから自由にINSERT・UPDATE・DELETEを行う通常のテストDBとして、そのままRefreshable Clone PDBを使う構成には注意が必要です。
書き込み可能なテスト環境が必要なら「ゴールデンマスター」として使う
Refreshable Clone PDBはREAD ONLYでの利用が基本となるため、更新系テストを行いたい場合は少し構成を工夫します。Oracleが紹介している代表的な方法が、Refreshable Clone PDBをゴールデンマスターとして維持する方式です。
まず、本番PDBから定期的に更新されるRefreshable Clone PDBを作ります。そして実際にテストを行う際には、その最新状態のゴールデンマスターから別のPDBクローンやスナップショットクローンを作成します。
例えば、PRODPDB → GOLDEN_PDB → TEST_PDB_01、TEST_PDB_02という構成です。GOLDEN_PDBだけを本番に追随させておき、開発者ごとのテスト環境はそこから作成します。こうすれば、本番から毎回大規模なコピーを作成する必要を減らしつつ、テスト環境側では自由にデータを書き換えられる構成を作りやすくなります。
Oracleの公式ドキュメントでも、本番PDBからRefreshable Clone PDBをゴールデンマスターとして維持し、PDBレベルのスナップショットを取得して開発・テスト用クローンを作成する運用例が示されています。
PDB Refreshを使う前に確認しておきたい要件
Refreshable Clone PDBは便利ですが、どのOracle Database環境でも何も準備せず利用できるわけではありません。ソースPDB、CDB、データベースリンク、アーカイブログなどの条件を事前に確認する必要があります。
Oracleの現行ドキュメントでは、Refreshable Clone PDBを作成する際、ソースPDBがARCHIVELOGモードおよびローカルUNDOモードであることなどが要件として示されています。また、リモートPDBから作成する場合には適切なデータベースリンクが必要です。
さらに、ソースPDB側で新しいデータファイルが追加される構成では、PDB_FILE_NAME_CONVERTなどファイル配置に関する設定が必要になる場合があります。実運用へ導入する際は、使用しているOracle Databaseのバージョンに対応した公式マニュアルで要件を確認することが重要です。
PDB Refreshだけでテストデータ管理の問題がすべて解決するわけではない
PDB Refreshはテスト環境を更新するための強力な仕組みですが、データコピーに伴う運用上の課題すべてを解決するものではありません。特に本番データを開発・テスト環境へ持ち込む場合は、個人情報や機密情報の扱いに注意が必要です。
例えば顧客氏名、メールアドレス、電話番号、決済関連情報などが本番PDBに保存されている場合、そのままテスト環境へ複製することが社内ルールや法令上問題になる可能性があります。その場合は、データマスキングや匿名化などを組み合わせる必要があります。
また、Refreshable Clone PDBはソースPDBの更新内容を追随する仕組みであるため、「昨日の状態」「リリース前の特定時点」といった複数の状態を自由に保持する用途とは別に考える必要があります。テスト目的に応じて、PDB Snapshot、バックアップ、Data Pump、スナップショットクローンなど他のOracle機能との使い分けを検討するとよいでしょう。
PDB Refreshが向いているケース
PDB Refreshは、特に本番に近いデータを継続的に利用する開発・検証環境でメリットがあります。毎回大きなPDBをコピーするのではなく、更新可能な基準PDBを維持したい場合に適しています。
- 本番に近い最新データを利用してテストしたい
- 大規模なPDBを毎回フルクローンする時間を減らしたい
- 定期的にテスト用データを更新したい
- 複数の開発・テスト環境を作るためのゴールデンマスターを用意したい
- 更新タイミングを自動化または定型化したい
一方で、Refreshable Clone PDBそのものへ頻繁に書き込みを行いたい場合には、そのまま利用するより、Refreshable Cloneをマスターとして別のテスト用クローンを作成する構成のほうが適していることがあります。
まとめ：PDB Refreshはテスト環境更新の効率化に有効
Oracle DatabaseのRefreshable Clone PDBを利用すると、ソースPDBから作成したクローンに対し、前回以降のREDOを適用して継続的に更新できます。毎回PDB全体を最初から複製する運用と比べて、開発・テスト環境の基準データを最新状態へ近づける作業を簡略化しやすいことが大きなメリットです。
リフレッシュには手動モードと自動モードがあり、テスト開始前だけ更新する運用から一定間隔で自動更新する運用まで構築できます。ただし、Refreshable Clone PDBはリフレッシュ時に閉じる必要があり、通常はREAD ONLYで利用するため、自由に書き込み可能なテスト環境が必要な場合はゴールデンマスターとして利用し、そこから別のクローンを作る構成が有効です。
実際に採用する際は、ARCHIVELOGやローカルUNDO、データベースリンクなどの前提条件に加え、本番データのマスキングやテスト環境のライフサイクルも含めて設計することが重要です。Oracle Databaseのバージョンによって仕様や要件が異なる可能性があるため、導入時には使用バージョンのOracle公式ドキュメントを確認してください。
コメント