Oracle Databaseのリフレッシュ可能なクローン機能を使用する—パート1：はじめに

インスタンスのクローンを作成するときは、インスタンスのバックアップを取り、他の場所にバックアップを復元します。通常、同じディレクトリ構造を持つ別のマシンに復元します。 OracleSystem ID（SID）とデータベース名を変更して、同じマシンに復元することもできます。テストマシンでproductioninstanceのクローンを使用して、init.oraの変更などのwhat-ifシナリオを試すことができます。 パラメータやコードの変更など。

PDBのクローン作成はどのように機能しますか？

PDBクローンを使用して、マルチテナント環境でPDBのクローンを作成できます。ローカルまたはリモートのPDBの場合は、更新可能なクローンまたはスナップショットカルーセルを使用して、ローカルコンテナデータベースにPDBクローンを作成します。

リモートPDBのクローン作成については、次のことを考慮してください。

• 更新可能なクローンを使用するには、PDBのデータベースリンクが必要であり、クローンデータベースを無効にする必要があります。

• スナップショットカルーセルを使用するには、スナップショットを使用して一般的なPDBクローンを作成する必要があります。次に、データベースリンクを使用するか、別のコンテナデータベースのプラグを抜いてプラグインします。複製されたPDBから更新可能なクローンを作成することもできます。

PDBスナップショットとは何ですか？

PDBスナップショットは、PDBのポイントインタイムコピーです。 SNAPSHOTを使用して、スナップショットを手動で作成します CREATE PLUGGABLE DATABASEの句 （またはALTER PLUGGABLE DATABASE ）コマンド、またはEVERYを使用して自動的に 間隔句。

PDBスナップショットカルーセルとは何ですか？

PDBスナップショットカルーセルは、ポイントインタイムリカバリを実行してPDBのクローンを作成するために使用できる最近のPDBスナップショットのライブラリを維持します。

更新可能なクローンPDB

更新可能クローン機能を使用してPDBのクローンを作成できます。この機能は、更新間隔とREDO生成率に応じて、データの破損や災害からデータベースを最小限のデータ損失で保護します。 refreshablecloneデータベースをレプリカとして使用して、特定の低負荷で重要ではないアプリケーションを再開できます。更新可能なクローンデータベースを設定して、設定した間隔で自動的に更新するか、REDOログアプリケーションを使用して手動で更新することができます。

図1は、更新可能なクローン処理のアーキテクチャーを示しています。主なコンポーネントとプロセスを示し、本番データベースと更新可能なクローンデータベースの関係を示します。この図は、プラガブルデータベース PDB1のクローン作成を示しています。 コンテナデータベースのCDB1 別のコンテナデータベースへCDB2 。このアクションにより、 PDB1のホットクローンバージョンが作成されます。 PDB1_REF_CLONEという名前 。

図1

図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のクローンを頻繁に作成しないと、clonedataが古くなります。更新可能なクローンPDBは、この問題を解決します。更新可能なクローンが古くなった場合は、最近のやり直しですばやく更新できます。

通常、マスターを維持します 本番PDBの更新可能なクローンを作成し、開発とテストのためにマスターのスナップショットクローンを作成します。

次のステートメントを使用して、ソースPDBとクローンPDBの役割を逆にします。

ALTER PLUGGABLE DATABASE ... SWITCHOVER;

次の図に示すように、この切り替えプロセスを簡略化できます。

図2

図2

図3

図3

この切り替え機能は、次の状況で役立ちます。

更新可能なクローンの計画された切り替え

図3では、 CDB1 、ソースPDB、 PDB1をホストします 、 CDB2よりも大幅に多くのオーバーヘッドが発生する可能性があります 、クローンPDBをホストします。 PDB1_REF_CLONE 。より良い負荷分散を実現するために、クローンを新しいソースPDBに変換し、ソースPDBを新しいクローンに変換することで、PDBの役割を逆にすることができます。

currentprimaryデータベースで次のコマンドを使用して、この役割の移行を実行します。

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

このコマンドが完了したら、 PDB1_REF_CLONE CDB2 主な役割を引き受けます。 CDB1 レプリカを維持するようになりました。プロダクションへのすべての接続は、新しいプライマリ（現在は CDB2 ）に接続します 。更新がソースからの再生成率に追いついていると仮定すると、2分以内のトランザクションが失われます。

更新可能なクローンの計画外の切り替え

ソースPDBに予期しない障害が発生した場合は、クローンPDBを新しいソースPDBに切り替えて、通常の操作を再開できます。

現実的なトランザクションボリュームを使用して環境をテストし、レプリカを更新するプロセスがREDOの生成速度に対応できることを確認してください。

更新可能なクローンはDataGuardとどのように異なりますか？

Oracleは、DataGuardとスタンバイデータベースで高可用性機能を導入しました。次の要素は、更新可能なクローンとDataGuardを区別します。

• Data Guardは、スタンバイデータベースへのリアルタイムのスイッチオーバーとフェイルオーバーでデータベースを災害やデータ破損から保護するための高可用性を提供します。リフレッシュ可能なクローンPDB機能を使用して、負荷分散にDataGuardスタンバイ・データベースを使用することもできます。 Data GuardはCDBレベルで機能し、PDBレベルでスイッチオーバーやフェイルオーバーを行うことはできません。

• スイッチオーバーの開始と完了の間には遅延があるため、DataGuardは単に更新可能なクローンを維持するよりも効果的です。このラグの間、ロールを切り替える前に、プライマリデータベースへのトランザクションが読み取り専用データベースに適用または同期されない場合があります。その結果、これらの取引が失われる可能性があります。

• Data Guardには最大30のスタンバイ・データベースの制限がありますが、必要に応じて多くの更新可能なクローンを作成できます。

更新可能なクローンPDB機能を強化して高可用性を実現し、データの損失をほとんど発生させないようにするには、REMOTE_RECOVERY_FILE_DESTを設定します。 ソースPDBのログの場所をアーカイブするためのパラメータ。

結論

高可用性の観点から、更新可能なクローンPDB機能をDataGuardの代わりと見なすべきではありません。ただし、更新可能なクローンを使用して、別のサーバーにレプリカデータベースを維持することができます。

この投稿では、更新可能なPDBをレプリカとして使用して、スイッチオーバーが計画的または計画外のイベントであるかどうかに関係なく、特定の低負荷で重要ではないアプリケーション操作を再開できるようにする方法について説明しました。目標復旧時間（RTO、運用再開までの時間）および目標復旧時点（データ損失の最小化などのRPO）の観点から、切り替えを検討する必要があることに注意してください。

シリーズのパート2では、更新可能なクローン機能について説明します。

コメントや質問をするには、[フィードバック]タブを使用します。今すぐチャットして会話を開始することもできます。

データベースの詳細をご覧ください。