1. 管理者ガイド
  2. PDBおよびアプリケーション・コンテナの作成
  3. PDBのクローニング

8 PDBのクローニング

PDBは、ローカルPDBまたはリモートPDBをクローニングすることで作成できます。

親トピック: PDBおよびアプリケーション・コンテナの作成

PDBのクローニングについて

クローニングとは、ソースPDBから新しいPDBを作成することです。

一般的なユースケースは開発テストです。PDBの1つ以上のクローンを作成して、それらのクローンを分離して安全にテストできます。たとえば、新しいアプリケーションまたは変更されたアプリケーションを、本番PDBで使用する前に、クローニングPDBでテストできます。

関連項目:

暗号化データまたはキーストア・セットを持つソースのクローニングについて学習するには、『Oracle Database Advanced Securityガイド』を参照してください

親トピック: PDBのクローニング

クローニングの仕組み

この手法では、ソースPDBから新しいPDBを作成します。このプロセスでは、新しいPDBを自動的にCDBに接続します。

この手法を使用するには、CREATE PLUGGABLE DATABASE文でソースを指定する必要があります。ソースには、ローカルまたはリモートのPDBを使用できます。

ターゲットPDBはソースPDBのコピーです。このコピーのことをクローンPDBと呼びます。

CREATE PLUGGABLE DATABASE文では、ソースに関連付けられているファイルを新しい場所にコピーし、そのファイルをターゲットPDBに関連付けます。CDBがARCHIVELOGモードおよびローカルUNDOモードの場合、ソースPDBは読取り/書込みモードでオープンでき、クローニング・プロセス中に機能します。この手法は、ホット・クローニングと呼ばれます。

ノート:

PDBをクローニングするときに、そのPDBに暗号化データがある場合、またはTDEマスター暗号化キーが設定されている場合は、CREATE PLUGGABLE DATABASE ... FROM SQL文にKEYSTORE IDENTIFIED BY keystore_password句を含めて、ターゲット・キーストアのキーストア・パスワードを提供する必要があります。クローンを使用する前に追加のキーをインポートする必要があるかどうかを確認できるように、ターゲット・キーストアのパスワードを指定する必要があります。ソースPDBに暗号化データまたはキーストアで設定されているTDEマスター暗号化キーがあるかどうかを確認するには、V$ENCRYPTION_KEYS動的ビューを問い合せます。

すべてのクローニングのシナリオで、CREATE PLUGGABLE DATABASE文をアプリケーション・ルートで実行するときには、アプリケーション・コンテナ内にクローンPDBを作成します。ソースPDBのアプリケーション名およびバージョンは、アプリケーション・コンテナのアプリケーション名およびバージョンと一致する必要があります。

次の図に、この手法でローカル・ソース・アプリケーションPDBをクローニングすることで新しいアプリケーションPDBをアプリケーション・コンテナに作成する方法を示します。ソースPDBは、ローカルCDBルートに接続されたPDB、リモートCDBルートに接続されたPDBまたはリモート・アプリケーション・ルートに接続されたアプリケーションPDBにすることができます。

図8-1 アプリケーション・コンテナ内のPDBのクローニング

図8-1の説明が続きます
「図8-1 アプリケーション・コンテナ内のPDBのクローニング」の説明

関連項目:

「PDB記憶域」

親トピック: PDBのクローニングについて

PDBクローニングのユーザー・インタフェース

すべての形式のPDBクローニングに、CREATE PLUGGABLE DATABASE文を使用します。

クローニングの際には、FROM句でソースPDBを指定する必要があります。次の表に、最も重要な句のまとめを示します。

表8-1 PDBクローニングのためのCREATE PLUGGABLE DATABASEオプション

句 クローニング操作 関連項目

USING SNAPSHOT

PDBレベルのスナップショットからクローンを作成します(ALTER PLUGGABLE DATABASE SNAPSHOT)。PDBスナップショット名、SCNまたはタイムスタンプを指定します。

PDBスナップショットからのクローン

REFRESH MODE

リフレッシュ可能クローンPDBを作成します。

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

SNAPSHOT COPY

記憶域管理スナップショットからスナップショット・コピーPDBを作成します(ALTER PLUGGABLE DATABASE SNAPSHOTではない)。記憶域管理スナップショットは、特定のファイル・システムでのみサポートされています。

スナップショット・コピーPDBには、ソース・データ・ファイルの完全なコピーは含まれていません。かわりに、基礎となるファイル・システムの記憶域レベルのスナップショットが作成され、そのスナップショットからクローンPDBが作成されます。

標準のクローンPDBとは異なり、スナップショット・コピーPDBは記憶域スナップショットに依存しています。そのため、スナップショット・コピーPDBは、CDBルートから切断することも、アプリケーション・ルートに接続することもできません。また、そのPDBが基づいている記憶域スナップショットを削除することもできません。そのかわりに、スナップショット・コピーPDBをマテリアライズする必要があります。これにより、非スパース・ファイルによる完全PDBに変換します。

スナップショット・コピーPDB

USING MIRROR COPY

mirror_nameで指定されているASM記憶域ミラーを分割することで、新しいPDBを作成します。準備済ミラー・コピーからは1つのPDBのみを分割できます。追加の分割を作成する場合は、新しいミラー・コピーを準備する必要があります。

「分割ミラーによるクローンPDBの作成」

関連項目:

親トピック: PDBのクローニングについて

ローカルPDBのクローニング

ローカルPDBのクローンは、CREATE PLUGGABLE DATABASE文を実行して、FROM文でローカルPDBを指定することで作成できます。

親トピック: PDBのクローニング

ローカルPDBのクローニングについて

クローニングの最も簡単な形式では、PDBをCDBから同じCDBにコピーします。

ノート:

PDBをPDBシード(PDB$SEED)またはアプリケーション・シードから作成する場合に、CREATE PLUGGABLE DATABASE文にFROM句を含めることはできません。

次の図は、ローカルPDBをクローニングする方法を示しています。

図8-2 ローカルPDBのクローニング

図8-2の説明が続きます
「図8-2 ローカルPDBのクローニング」の説明

PDBをクローニングする前に、「表6-3」のPDBのクローニングに適用される質問に対処します。この表では、様々な要因に基づいて指定するCREATE PLUGGABLE DATABASEの句について説明しています。

Oracle Database 18c以降では、DBCAを使用してローカルPDBをクローニングできます。

関連項目:

親トピック: ローカルPDBのクローニング

ローカルPDBのクローニング: 基本的なステップ

ローカルPDBのクローンは、CREATE PLUGGABLE DATABASEを実行して、FROM句でソースPDBを指定することで作成できます。

前提条件

次の前提条件を満たしている必要があります。

  • 「PDB作成の一般的な前提条件」で説明している前提条件を満たします。

  • 現行ユーザーは、ルートおよびソースPDBの両方でCREATE PLUGGABLE DATABASEシステム権限を持っている必要があります。

  • ソースPDBはクローズできません。

  • CDBがローカルUNDOモードでない場合、ソースPDBは読取り専用オープン・モードである必要があります。この要件は、CDBがローカルUNDOモードの場合は適用されません。

  • CDBがARCHIVELOGモードでない場合、ソースPDBは読取り専用オープン・モードである必要があります。この要件は、CDBがARCHIVELOGモードの場合は適用されません。

  • アプリケーションPDBを作成している場合、アプリケーションPDBはアプリケーション・コンテナと同じ文字セットおよび各国語文字セットである必要があります。

    CDBのデータベース文字セットがAL32UTF8の場合、アプリケーション・コンテナの文字セットおよび各国語文字セットはCDBと異なっていても構いません。ただし、アプリケーション・コンテナ内のすべてのアプリケーションPDBには、アプリケーション・コンテナと同じ文字セットおよび各国語文字セットが必要です。

ノート:

REFRESH MODE句を使用してローカルPDBのリフレッシュ可能なクローンを作成できるのは、データベース・リンクが同じCDBにループ・バックしている場合のみです。

ローカルPDBをクローニングするには:

  1. SQL*Plusで、現在のコンテナがCDBルートまたはアプリケーション・ルートであることを確認します。

    現在のコンテナがCDBルートの場合、PDBはCDBに作成されます。現在のコンテナがアプリケーション・ルートの場合、アプリケーションPDBはアプリケーション・コンテナ内に作成されます。

  2. CREATE PLUGGABLE DATABASE文を実行し、ソースPDBをFROM句で指定します。必要に応じて、他の句を指定します。

    ローカルPDBのクローニング後、ソースPDBとターゲットPDBは同じCDBに存在します。新しいPDBはマウント・モードになっていて、そのステータスはNEWになります。PDBのオープン・モードは、V$PDBSビューのOPEN_MODE列を問い合せることで確認できます。CDB_PDBSまたはDBA_PDBSビューのSTATUS列を問い合せて、PDBのステータスを表示できます。

    PDBの新しいデフォルト・サービスが作成されます。サービスの名前はPDBと同じになり、このサービスを使用してPDBにアクセスできます。このサービスにアクセスするクライアントには、Oracle Net Serviceが正しく構成されている必要があります。

  3. 新しいPDBを読取り/書込みモードでオープンします。

    Oracle Databaseで新しいPDBをCDBに統合するには、PDBを読取り/書込みモードでオープンする必要があります。PDBを読取り専用モードでオープンしようとすると、エラーが返されます。PDBが読取り/書込みモードでオープンされると、そのステータスはNORMALになります。

  4. 新しいPDBのバックアップを作成します。

    PDBは、バックアップしないとリカバリできません。

ノート:

PDBの作成時にエラーが返された場合は、作成されたPDBがUNUSABLE状態である可能性があります。PDBの状態は、CDB_PDBSまたはDBA_PDBSビューを問い合せることで確認できます。PDB作成のエラーについてさらに学習するには、アラート・ログを確認してください。使用不可のPDBのみを削除できます。また、使用不可のPDBを削除してからでないと、同じ名前のPDBを作成できません。

関連項目:

親トピック: ローカルPDBのクローニング

ローカルPDBのクローニング後

ローカルPDBのクローニング後には、ユーザーと表領域に関する特定のルールが適用されます。

ソースPDBのデフォルト一時表領域を使用していた新しいPDBのユーザーは、新しいPDBのデフォルト一時表領域を使用します。PDB内のデフォルト以外の一時表領域を使用していたユーザーは、クローニングされたPDB内の同じローカル一時表領域を引き続き使用します。

関連項目:

「CDB内表領域の管理について」

親トピック: ローカルPDBのクローニング

ローカルPDBのクローニング: 例

次の例では、様々な要因に基づき、pdb1という名前のローカル・ソースPDBを、pdb2という名前のターゲットPDBにクローニングします。

各例で、新しいPDBが属するルートはCREATE PLUGGABLE DATABASE文の実行時の現在のコンテナによって決まります。

  • 現在のコンテナがCDBルートの場合、データベースではCDBルートにPDBが作成されます。

  • 現在のコンテナがアプリケーション・コンテナ内のアプリケーション・ルートの場合、データベースではアプリケーション・ルート内にアプリケーションPDBが作成されます。

親トピック: ローカルPDBのクローニング

句を使用しないローカルPDBのクローニング: 例

この例では、PDBをクローニングする最も簡単な方法を示しています。

この例では、次の要因を想定しています。

  • PATH_PREFIX句は必要ありません。

  • FILE_NAME_CONVERT句およびCREATE_FILE_DEST句は必要ありません。

    Oracle Managed Filesが有効であるか、またはPDB_FILE_NAME_CONVERT初期化パラメータが設定されています。したがって、FILE_NAME_CONVERT句は必要ありません。これらのファイルは、Oracle Managed Files構成または初期化パラメータ設定に基づいて新しい場所にコピーされます。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

次の文は、pdb1 PDBからpdb2 PDBをクローニングします。 

CREATE PLUGGABLE DATABASE pdb2 FROM pdb1;

関連項目:

親トピック: ローカルPDBのクローニング: 例

DBCAを使用したローカルPDBのクローニング: 例

この例では、DBCAのサイレント・モードを使用してPDBをクローニングします。ホット・クローニングがサポートされます。

この例では、次の要因を想定しています。

  • ソースCDBは、SIDがorclの単一インスタンス・データベースです。

  • ソースPDBはpdb1です。クローニング操作中、pdb1はオープンのままにします。これは、ローカルUNDOおよびARCHIVELOGモードがCDBで有効になっていることを意味します。それ以外の場合、DBCAはクローン操作中にPDBをクローズし、確認を受け取った後に、ソースPDBを読取り専用モードでオープンします。

  • 新しいPDBはpdb2です。

  • DBCAを非対話型モードで実行しています。

次のコマンドは、pdb1 PDBからpdb2 PDBをクローニングします。 

./dbca -silent 
  -createpluggabledatabase 
  -sourcedb orcl 
  -createpdbfrom PDB 
  -pdbName pdb2 
  -sourcepdb pdb1

関連項目:

DBCAのコマンド・リファレンスは、『Oracle Database管理者ガイド』を参照してください

親トピック: ローカルPDBのクローニング: 例

PATH_PREFIX句を使用したローカルPDBのクローニング: 例

この例では、PATH_PREFIX、FILE_NAME_CONVERTおよびSERVICE_NAME_CONVERT句を使用してローカルPDBをクローニングする方法を説明しています。

この例では、次の要因を想定しています。

  • パス接頭辞をPDBのディレクトリ・パスに追加する必要があります。したがって、PATH_PREFIX句が必要です。この例では、パス接頭辞/disk2/oracle/pdb2/をPDBのディレクトリ・オブジェクト・パスに追加しています。

  • コピーしたファイルのターゲットの場所を指定するには、FILE_NAME_CONVERT句が必要です。この例では、ファイルは/disk1/oracle/pdb1から/disk2/oracle/pdb2にコピーされます。

    CREATE_FILE_DEST句は使用されず、Oracle Managed FilesもPDB_FILE_NAME_CONVERT初期化パラメータも、コピーしたファイルのターゲットの場所の指定に使用されません。

    PDBのデータファイルの場所を表示するには、「例15-34」の問合せを実行します。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

  • クローニングされるPDB (pdb1)には、カリフォルニア州の営業担当者およびオーダー入力担当者のための2つのユーザー定義のサービス(salesrep_caおよびorders_ca)があります。新しいサービスはオレゴン州の営業担当者およびオーダー入力担当者のためのものであり、クローニングされたPDB (pdb2)でサービス名はsalesrep_orおよびorders_orにそれぞれ名前変更されます。

  • PDB内で今後作成される表領域は、デフォルトでNOLOGGING属性を使用して作成されます。この機能は、Oracle Database 12cリリース1 (12.1.0.2)以降で使用可能です。

次の文は、pdb1 PDBからpdb2 PDBをクローニングします。 

CREATE PLUGGABLE DATABASE pdb2 FROM pdb1 
  PATH_PREFIX = '/disk2/oracle/pdb2/'
  FILE_NAME_CONVERT = ('/disk1/oracle/pdb1/', '/disk2/oracle/pdb2/')
  SERVICE_NAME_CONVERT = ('salesrep_ca','salesrep_or','orders_ca','orders_or')
  NOLOGGING;
STORAGE句を使用したローカルPDBのクローニング: 例

この例では、FILE_NAME_CONVERT、STORAGEおよびSERVICE_NAME_CONVERT句を使用してローカルPDBをクローニングします。

この例では、次の要因を想定しています。

  • PATH_PREFIX句は必要ありません。

  • コピーしたファイルのターゲットの場所を指定するには、FILE_NAME_CONVERT句が必要です。この例では、ファイルは/disk1/oracle/pdb1から/disk2/oracle/pdb2にコピーされます。

    CREATE_FILE_DEST句は使用されず、Oracle Managed FilesもPDB_FILE_NAME_CONVERT初期化パラメータも、コピーしたファイルのターゲットの場所の指定に使用されません。

    PDBのデータファイルの場所を表示するには、例15-34の問合せを実行します。

  • PDBにストレージ制限を強制する必要があります。したがって、STORAGE句が必要です。特に、PDBに属する表領域はいずれも2GBを超えることはできません。

  • ソースPDB (pdb1)には、カリフォルニア州の営業担当者およびオーダー入力担当者のための2つのユーザー定義のサービス(salesrep_caおよびorders_ca)があります。新しいサービスはオレゴン州の営業担当者およびオーダー入力担当者のためのものであり、クローニングされたPDB (pdb2)でサービス名はsalesrep_orおよびorders_orにそれぞれ名前変更されます。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

次の文は、pdb1 PDBからpdb2 PDBをクローニングします。 

CREATE PLUGGABLE DATABASE pdb2 FROM pdb1 
  FILE_NAME_CONVERT = ('/disk1/oracle/pdb1/', '/disk2/oracle/pdb2/')
  STORAGE (MAXSIZE 2G)
  SERVICE_NAME_CONVERT = ('salesrep_ca','salesrep_or','orders_ca','orders_or');
NO DATA句を使用したローカルPDBのクローニング: 例

この例では、PDBのデータ・モデル定義をクローニングしますが、PDBのデータはクローニングしません。

この例では、次の要因を想定しています。

  • NO DATA句は、目的がデータをクローニングせずにソースPDBのデータ・モデル定義をクローニングすることであるため必要です。

  • PATH_PREFIX句は必要ありません。

  • FILE_NAME_CONVERT句およびCREATE_FILE_DEST句は必要ありません。

    Oracle Managed Filesが有効であるか、またはPDB_FILE_NAME_CONVERT初期化パラメータが設定されています。したがって、FILE_NAME_CONVERT句は必要ありません。プロセスでは、Oracle Managed Files構成または初期化パラメータ設定に基づいて、ファイルが新しい場所にコピーされます。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

ソースPDB pdb1にデータが大量にあるとします。次のステップでは、操作の完了時にソースPDBのデータがクローンに含まれない動作の内容を示します。

  1. ソースPDB pdb1を現在のコンテナとして使用し、データが大量にある表を問い合せます。 

    SELECT COUNT(*) FROM tpch.lineitem;

  COUNT(*)
----------
  60001215

    表には、6000万超の行があります。

  2. NO DATA句を指定して、ソースPDBをクローニングします。 

    CREATE PLUGGABLE DATABASE pdb2 FROM pdb1 NO DATA;

  3. クローニングしたPDBをオープンします。

    ALTER PLUGGABLE DATABASE pdb2 OPEN;

  4. クローニングしたPDB pdb2を現在のコンテナとして使用し、ソースPDB内のデータが大量にある表を問い合せます。 

    SELECT COUNT(*) FROM tpch.lineitem;

  COUNT(*)
----------
         0

    クローニングしたPDB内の表には行がありません。

リモートPDBのクローニング

ローカルPDBのクローンは、CREATE PLUGGABLE DATABASE文を実行し、FROM文でリモートPDBへのデータベースへのリンクを指定することで作成できます。

親トピック: PDBのクローニング

リモートPDBのクローニングについて

ソースがリモートCDB内のPDBである場合は、データベース・リンクを使用してPDBをローカルCDBにクローニングする必要があります。

データベース・リンクは、ローカルCDB (リモートCDBではない)に存在している必要があります。ローカルCDBのルートからCREATE PLUGGABLE DATABASE文を発行する場合は、クローニングされるPDBを含むリモートCDBへのデータベース・リンクをFROM句で指定する必要があります。データベース・リンクは、ローカルCDBから、リモートCDBのルートまたはリモート・ソースPDBのいずれかに接続します。

次の図は、ソースPDBがリモートである場合に、この手法で新規PDBがどのように作成されるかを示しています。

図8-3 リモートPDBのクローニングによるPDBの作成

図8-3の説明が続きます
「図8-3 リモートPDBのクローニングによるPDBの作成」の説明

Oracle Database 19c以降では、サイレント・モードでDBCAを使用してリモートPDBをクローニングできます。

親トピック: リモートPDBのクローニング

リモートPDBのクローニング: 基本的なステップ

PDBは、リモートPDBをクローニングすることで作成できます。クローニング操作後、ソースとターゲットPDBは異なる場所にあります。

一般的な前提条件

次の前提条件を満たしている必要があります。

  • 「PDB作成の一般的な前提条件」で説明している前提条件を満たします。

  • 現行ユーザーは、ターゲットPDBが含まれるCDBのルートでCREATE PLUGGABLE DATABASEシステム権限を持っている必要があります。

  • ソースとターゲットのプラットフォームは、次の要件を満たしている必要があります。

    • endiannessが同じである必要があります。

    • ソース・プラットフォームにインストールされているデータベース・オプションは、ターゲット・プラットフォームにインストールされているデータベース・オプションと同じか、サブセットである必要があります。

  • アプリケーションPDBを作成している場合、ソースPDBのアプリケーション名およびバージョンは、ターゲット・アプリケーション・コンテナのアプリケーション名およびバージョンと一致する必要があります。

文字セットの前提条件

  • PDBがクローニングされるCDBの文字セットがAL32UTF8でない場合、ソースとターゲットには互換性のある文字セットおよび各国語文字セットが必要です。PDBがクローニングされるCDBの文字セットがAL32UTF8である場合、この要件は適用されません。

  • アプリケーションPDBを作成している場合、アプリケーションPDBはアプリケーション・コンテナと同じ文字セットおよび各国語文字セットである必要があります。

    CDBのデータベース文字セットがAL32UTF8の場合、アプリケーション・コンテナの文字セットおよび各国語文字セットはCDBと異なっていても構いません。ただし、アプリケーション・コンテナ内のすべてのアプリケーションPDBには、アプリケーション・コンテナと同じ文字セットおよび各国語文字セットが必要です。

ノート:

Oracle Multitenantでは、あるコンテナのLOBに対する異なる文字セットのコンテナによるデータ・リンク、拡張データ・リンクまたはCONTAINERS()句を使用したアクセスはサポートされません。たとえば、CDBルートとsalespdbの文字セットが異なる場合、CDBルートで実行されるCONTAINERS()問合せはsalespdbのLOBにアクセスできません。

ソースPDBのオープン・モードの前提条件

  • ソースPDBはクローズできません。

  • リモートCDBがローカルUNDOモードでない場合、ソースPDBは読取り専用モードでオープンしている必要があります。

    「CDB UNDOモードについて」を参照してください。

  • リモートCDBがARCHIVELOGモードでない場合、ソースPDBは読取り専用モードでオープンしている必要があります。

  • リフレッシュ可能なPDBを作成している場合、ソースPDBはARCHIVELOGモードおよびローカルUNDOモードである必要があります。

データベース・リンクの前提条件

次の前提条件を満たしている必要があります。

  • データベース・リンクで、宛先CDB (PDBのクローニング先のCDB)からソースCDB内のPDBへの接続が有効である必要があります。

  • データベース・リンクでは、共通ユーザーとしてソースCDBのルートに、または共通ユーザーかローカル・ユーザーとしてソースPDBに接続できます。ソースPDBとしては、標準PDBまたはアプリケーションPDBのどちらかを使用できます。

  • データベース・リンクで指定されたユーザー・アカウントには、次のいずれかの権限が必要です。

    • ソースPDBに共通またはローカルで付与されているCREATE PLUGGABLE DATABASE権限

    • SYSOPER権限

  • Oracle Data Guard環境でプライマリCDBへのPDBのリモート・クローンを実行している場合は、スタンバイCDBでSTANDBY_PDB_SOURCE_FILE_DBLINK初期化パラメータを設定します。このパラメータは、CREATE PLUGGABLE DATABASE ... FROM dblinkで使用するデータベース・リンクの名前を指定します。スタンバイCDBでは、ソースPDBが読取り専用モードでオープンしている場合のみ、データベース・リンクで参照されるソースPDBからデータファイルのコピーを試みます。それ以外の場合は、スタンバイCDBでデータ・ファイルをOracle Managed Filesの場所にコピーする必要があります。

リモートPDBをクローニングするには:

  1. SQL*Plusで、現在のコンテナがターゲットCDBのルートまたはターゲット・アプリケーション・コンテナのアプリケーション・ルートであることを確認します。

  2. CREATE PLUGGABLE DATABASE文を実行し、ソースPDBをFROM句で指定します。必要に応じて、他の句を指定します。

    作成したPDBはマウント・モードになり、そのステータスはNEWです。PDBのオープン・モードは、V$PDBSビューのOPEN_MODE列を問い合せることで確認できます。CDB_PDBSまたはDBA_PDBSビューのSTATUS列を問い合せて、PDBのステータスを表示できます。

    PDBの新しいデフォルト・サービスが作成されます。サービスの名前はPDBと同じになり、このサービスを使用してPDBにアクセスできます。このサービスにアクセスするクライアントには、Oracle Net Serviceが正しく構成されている必要があります。

    ノート:

    PDBの作成時にエラーが返された場合は、作成されたPDBがUNUSABLE状態である可能性があります。CDB_PDBSまたはDBA_PDBSビューを問い合せてPDBの状態を確認したり、アラート・ログをチェックしてPDBの作成エラーについてさらに学習できます。使用不可のPDBは削除することのみができ、使用不可のPDBと同じ名前のPDBを作成できるようにするには、その前に削除する必要があります。

  3. 新しいPDBを読取り/書込みモードでオープンします。

    Oracle Databaseで新しいPDBをCDBに統合するには、PDBを読取り/書込みモードでオープンする必要があります。PDBを読取り専用モードでオープンしようとすると、エラーが返されます。PDBが読取り/書込みモードでオープンされると、そのステータスはNORMALになります。

    ノート:

    ソースPDBが読取り専用でオープンされ、スタンバイ・データベースに存在する場合: PDBがプライマリ・データベースでオープンされていて、リカバリがスタンバイ・データベースで実行されており、ソースPDBのデータファイルがリカバリされている場合、ソースPDBのリモート・クローニングはできません。ソースPDBのリモート・クローニングを実行するには、最初にソース・スタンバイ・データベースのメディア・リカバリを停止する必要があります。

  4. PDBをバックアップします。

    PDBは、バックアップしないとリカバリできません。

関連項目:

親トピック: リモートPDBのクローニング

リモートPDBのクローニング後

リモートPDBのクローニング後には、ユーザーと表領域に関する特定のルールが適用されます。

リモートPDBのクローニング後、次の内容が適用されます。

  • ソースPDBのデフォルト一時表領域を使用していた新しいPDBのユーザーは、新しいPDBのデフォルト一時表領域を使用します。PDB内のデフォルト以外の一時表領域を使用していたユーザーは、クローニングされたPDB内の同じローカル一時表領域を引き続き使用します。

  • ソースCDBに存在していてターゲットCDBには存在しないユーザー作成の共通ユーザー・アカウントには、一般に権限は付与されていません。ただし、ターゲットCDBに共通ユーザー・アカウントが存在していて、PDBの共通ユーザー・アカウントと同じ名前である場合、後者は前者にリンクされ、ターゲットCDBの共通ユーザー・アカウントに付与された権限を持ちます。

    クローニングまたは接続されたPDBにターゲットCDBに存在しない共通ユーザー・アカウントが存在し、このユーザーがPDB内のオブジェクトを所有していない場合、Oracle Databaseでは同期ステップ中にユーザーが削除されます。それ以外の場合、ユーザー・アカウントはターゲットPDBでロックされます。ロックされたアカウントに関して、次のオプションがあります。

    • PDBをクローニングし、ルートに接続し、同じ名前で共通ユーザー・アカウントを作成します。PDBを読取り/書込みモードでオープンすると、ユーザー・アカウントに共通して付与されているロールや権限の相違点が解決され、アカウントをロック解除できます。ユーザー・アカウントに対してローカルに付与されている権限やロールは、このプロセス中も変更されません。

    • PDBに新しいローカル・ユーザー・アカウントを作成し、データ・ポンプを使用して、ロックされたユーザーのデータを新しいローカル・ユーザーのスキーマにエクスポート/インポートします。

    • ユーザー・アカウントはロックされたままにします。

    • ユーザー・アカウントを削除します。

関連項目:

親トピック: リモートPDBのクローニング

リモートPDBのクローニング: 例

これらの例では、様々な要因に基づき、リモートPDBをクローニングします。

各例で、新しいPDBが属するルートはCREATE PLUGGABLE DATABASE文の実行時の現在のコンテナによって決まります。

  • 現在のコンテナがCDBルートの場合、新しいPDBはCDBルートに作成されます。

  • 現在のコンテナがアプリケーション・コンテナ内のアプリケーション・ルートの場合、新しいPDBはアプリケーション・ルート内にアプリケーションPDBとして作成されます。

親トピック: リモートPDBのクローニング

句を使用しないリモートPDBのクローニング: 例

次の例では、様々な要因に基づき、pdb1という名前のリモート・ソースPDBを、pdb2という名前のターゲットPDBにクローニングします。

この例では、次の要因を想定しています。

  • リモートPDBへのデータベース・リンク名はpdb1_linkです。

  • PATH_PREFIX句は必要ありません。

  • FILE_NAME_CONVERT句およびCREATE_FILE_DEST句は必要ありません。

    Oracle Managed Filesが有効であるか、またはPDB_FILE_NAME_CONVERT初期化パラメータが設定されています。これらのファイルは、Oracle Managed Files構成または初期化パラメータ設定に基づいて新しい場所にコピーされます。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

次の文は、pdb1リモートPDBからpdb2 PDBをクローニングします。 

CREATE PLUGGABLE DATABASE pdb2 FROM pdb1@pdb1_link;

関連項目:

親トピック: リモートPDBのクローニング: 例

DBCAを使用したリモートPDBのクローニング: 例

この例では、DBCAを使用して、リモートCDBからローカルCDBにpdb1という名前のPDBをクローニングし、クローニング先でclonepdb1という名前に変更します。

前提条件

この例では、次のことを前提としています。

  • ローカル・データベースのユーザーには、ルート・コンテナでのCREATE PLUGGABLE DATABASE権限が付与されている。

  • リモートCDBはローカルUNDOモードになっている。

  • リモートCDBとローカルCDBは、ARCHIVELOGモードになっている。

  • データベース・リンクの接続先リモートCDBの共通ユーザーには、CREATE PLUGGABLE DATABASE、SESSIONおよびSYSOPER権限が付与されている。

  • ローカルCDBとリモートCDBは、同じオプションでインストールされている。

想定

この例では、次のことを前提としています。

  • クローンPDBを格納するCDBのホスト上でDBCAを実行しています。ローカルCDBの名前は、loccdb1です。

  • リモート(ソース) CDBの名前はremcdb1で、ホストremcdb1hostに存在しています。リモートCDBのインスタンス名は、reminstです。

  • クローニングされるPDBであるリモートPDBの名前は、rempdb1です。

  • 共通ユーザーc##adminuser_remcdb1がremcdb1に存在しています。

  • 管理ユーザーlocSYSには、loccdb1 (PDBのクローニング先のCDB)に対するSYSDBA権限が付与されています。

  • 管理ユーザーremSYSにはremcdb1 (クローニングするPDBを格納しているCDB)に対するSYSDBA権限が付与されています。

  • loccdb1へのクローニング後、PDBの名前はclonepdb1に変更されます。

次のsilentコマンドでは、rempdb1をloccdb1にクローニングします。 

./dbca -silent 
  -createPluggableDatabase
  -createFromRemotePDB
  -sourceDB loccdb1  
  -remotePDBName rempdb1 
  -remoteDBConnString remcdb1host:1521/reminst 
  -remoteDBSYSDBAUserName remSYS 
      -remoteDBSYSDBAUserPassword remsyspwd 
  -dbLinkUsername c##adminuser_remcdb1 
      -dbLinkUserPassword pwd4dblinkusr 
  -sysDBAUserName locSYS 
      -sysDBAPassword locsyspwd
  -pdbName clonepdb1

関連項目:

DBCAコマンドの構文およびセマンティクスは、『Oracle Database管理者ガイド』を参照

親トピック: リモートPDBのクローニング: 例

リフレッシュ可能なクローンPDBについて

CREATE PLUGGABLE DATABASE ... REFRESH MODE文は、ソースPDBをクローニングし、クローンをリフレッシュ可能に構成します。クローンPDBをリフレッシュすると、最後のREDOログの適用以降に蓄積されたREDOでクローンPDBが更新されます。

親トピック: PDBのクローニング

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

本番PDBのクローニング操作には長い時間がかかる場合があります。

システム上でのドラッグを避けるためPDBをあまりクローニングしないと、クローニングしたデータが古くなります。リフレッシュ可能なクローンPDBによってこの問題が解決します。リフレッシュ可能クローンPDBが古くなっている場合は、それをクローズしてから、最新のREDOでリフレッシュできます。リフレッシュ可能クローンPDBは、リフレッシュされていない場合は、読取り専用でオープンできます。本番PDBの最終マスターのリフレッシュ可能クローンを保持し、PDBレベルのスナップショットを取得してから、開発およびテスト用にそれらのPDBスナップショットからクローンを作成するのが一般的な方法です。

ALTER PLUGGABLE DATABASE ... SWITCHOVER文を使用して、ソースとクローンPDBのロールを置き換えることができます。この機能は、次の場合に有効です。

  • 計画済スイッチオーバー

    ソースPDBをホストするCDBは、クローンPDBをホストするCDBよりもオーバーヘッドが非常に多くなる可能性があります。ロード・バランシングをアーカイブするには、ロールを置き換えて、クローンを新しいソースPDBにし、ソースPDBを新しいクローンにできます。

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

    ソースPDBで不測の失敗が発生することがあります。この場合、クローンPDBを新しいソースPDBにして、通常の操作を再開できます。

関連項目:

親トピック: リフレッシュ可能なクローンPDBについて

自動および手動リフレッシュ・モード

設定した間隔で自動的にリフレッシュするようにクローンPDBを構成するか、またはALTER PLUGGABLE DATABASE REFRESH文により手動でリフレッシュできます。

REFRESH MODE句は、CREATE PLUGGABLE DATABASE ... FROM文でのみサポートされています。この句を使用して、次のいずれかのオプションを指定できます。

  • デフォルトのREFRESH MODE NONEを指定して、リフレッシュ可能でないPDBを作成します。

    ALTER PLUGGABLE DATABASE文にREFRESH MODE NONE句を含め、PDBを読取り/書込みモードでオープンすることにより、リフレッシュ可能なクローンPDBを通常のPDBに変更できます。通常のPDBはリフレッシュ可能なクローンPDBに変更できません。リフレッシュ可能なクローンPDBが通常のPDBに変換された後は、リフレッシュ可能なクローンPDBに戻すことができません。

  • REFRESH MODE MANUALを指定して、手動でリフレッシュする必要のあるリフレッシュ可能PDBを作成します。

  • REFRESH MODE EVERY number_of_minutes MINUTESを指定して、指定した時間(分単位)の経過後に自動的にリフレッシュされるリフレッシュ可能PDBを作成します。自動リフレッシュを使用するリフレッシュ可能PDBを手動でリフレッシュすることもできます。

ノート:

  • リフレッシュ可能PDBを作成する場合、PDBにREMOTE_RECOVERY_FILE_DEST初期化パラメータを設定できます。この初期化パラメータは、ソースPDBがデータベース・リンク上で使用可能でない場合に、リフレッシュ操作中にアーカイブ・ログ・ファイルを読み取るディレクトリを指定します。

  • ソースPDBに新しいデータファイルが作成された場合は、CDBでPDB_FILE_NAME_CONVERT初期化パラメータを設定して、データファイルのパスをソースPDBからクローンPDBに変換する必要があります。

  • 表領域暗号化アルゴリズムへの変更(AES128からAES256への変更など)は、ソースPDBでアルゴリズムが変更された後はリフレッシュ可能PDBに適用されません。リフレッシュ可能PDBを作成した後、その表領域暗号化アルゴリズムを手動で更新する必要があります。

例8-1 自動リフレッシュを指定したREFRESH MODE句

このリフレッシュ・モード句では、リフレッシュ可能なPDBが2時間(120分)おきに自動的にリフレッシュされることを指定します。

REFRESH MODE EVERY 120 MINUTES

関連項目:

親トピック: リフレッシュ可能なクローンPDBについて

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

リフレッシュ可能なクローンPDBを作成するには、データベース・リンクが必要です。データベース・リンクは、同じCDBまたは別のCDBを指し示すことができます。

リフレッシュ可能なクローンPDBは、次のいずれかの状態である必要があります。

  • クローズ

    リフレッシュ可能PDBは、リフレッシュの実行時にクローズする必要があります。自動リフレッシュが試行されたときにクローズされていない場合、リフレッシュは次のスケジュール済リフレッシュまで延期されます。ユーザーが手動リフレッシュの実行を試行したときにクローズされていない場合は、エラーがレポートされます。

  • 読取り専用モードでオープン

    ソースPDBでは行われていない同期されていない変更がリフレッシュ可能なPDBで行われないように、リフレッシュ可能なPDBは読取り専用モードにしておく必要があります。リフレッシュ可能なPDBはクローン・マスターとして機能することが意図されているため、リフレッシュされた時点でソースPDBが正確に反映される必要があります。

親トピック: リフレッシュ可能なクローンPDBについて

リフレッシュ可能なクローンPDBの作成: シナリオ

このシナリオでは、pdb1という名前のリモートPDBからpdb1_ref_clnという名前のリフレッシュ可能なクローンを作成します。

クローンPDBはソースPDBのコピーです。クローンPDBを定期的にリフレッシュして、ソースPDBに対する変更内容で更新します。

想定

このシナリオでは、次の要因を想定しています。

  • リモートPDBへのデータベース・リンク名はpdb1_linkです。

  • PATH_PREFIX句は必要ありません。

  • FILE_NAME_CONVERT句およびCREATE_FILE_DEST句は必要ありません。

    Oracle Managed Filesが有効であるか、またはPDB_FILE_NAME_CONVERT初期化パラメータが設定されています。これらのファイルは、Oracle Managed Files構成または初期化パラメータ設定に基づいて新しい場所にコピーされます。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

  • リフレッシュ可能なクローンは、60分ごとに自動的にリフレッシュされます。

ノート:

リフレッシュ可能なPDBを作成するには、ソースPDBがARCHIVELOGモードおよびローカルUNDOモードである必要があります。

リフレッシュ可能なクローンPDBを作成するには:

  1. SQL*Plusで、現在のコンテナがCDBルートまたはアプリケーション・ルートであることを確認します。

    現在のコンテナがCDBルートの場合、PDBはCDBに作成されます。現在のコンテナがアプリケーション・ルートの場合、アプリケーションPDBはアプリケーション・コンテナ内に作成されます。

  2. CREATE PLUGGABLE DATABASE文を実行します。

    次の文では、pdb1からpdb1_ref_clnを作成します。 

    CREATE PLUGGABLE DATABASE pdb1_ref_cln FROM pdb1@pdb1_link REFRESH MODE EVERY 60 MINUTES;

関連項目:

「リフレッシュ可能なクローンPDBの管理」

親トピック: リフレッシュ可能なクローンPDBについて

DBCAを使用したリフレッシュ可能なクローンPDBの作成について

Oracle Database Configuration Assistant (DBCA)では、リモートPDBをリフレッシュ可能なPDBとしてクローニングできます。

PDBがリフレッシュ可能なPDBとして作成されると、ソースPDBの変更がリフレッシュ可能なPDBに定期的に伝播されます。リフレッシュ可能なPDBを作成するときに、手動または自動でリフレッシュするように構成できます。リフレッシュ可能なPDBの場合、リモート・データベースに接続するデータベース・リンクは最後に削除されません。このリンクはリフレッシュ操作の実行に必要なものです。作成後、リフレッシュ可能なPDBはMOUNTEDモードのままになります。これは、リフレッシュ操作はリフレッシュ可能なPDBがクローズ状態のときにのみ機能するためです。

表8-2 サイレント・モードのオプション

オプション 説明 
-createAsRefreshablePDB true/false
 trueを指定して、プラガブル・データベースをリフレッシュ可能なPDBとして作成します。 
-refreshMode AUTO|MANUAL
 プラガブル・データベースのリフレッシュ・モードを指定します。 
-refreshInterval time_interval
 PDBの自動リフレッシュを実行する間隔を分単位で指定します。リフレッシュ間隔が指定されていない場合は、手動リフレッシュが構成されます。

親トピック: リフレッシュ可能なクローンPDBについて

DBCAを使用したリフレッシュ可能なクローンPDBの作成: 例

この例では、DBCAを使用して、pdb1という名前のリモートPDBをリフレッシュ可能なPDBにクローニングし、refreshpdb1という名前に変更します。

前提条件

この例では、次のことを前提としています。

  • ローカル・データベースのユーザーには、ルート・コンテナでのCREATE PLUGGABLE DATABASE権限が付与されている。

  • リモートPDBはローカルUNDOモードになっている。

  • リモートPDBとローカルPDBは、ARCHIVELOGモードになっている。

  • データベース・リンクの接続先リモートPDBの共通ユーザーには、CREATE PLUGGABLE DATABASE、SESSIONおよびSYSOPER権限が付与されている。

  • ローカルPDBとリモートPDBは、同じオプションでインストールされている。

想定

この例では、次のことを前提としています。

  • クローンPDBを格納するCDBのホスト上でDBCAを実行しています。ローカルCDBの名前は、loccdb1です。

  • リモート(ソース) CDBの名前はremcdb1で、ホストremcdb1hostに存在しています。リモートCDBのインスタンス名は、reminstです。

  • クローニングされるPDBであるリモートPDBの名前は、rempdb1です。

  • 共通ユーザーc##adminuser_remcdb1がremcdb1に存在しています。

  • 管理ユーザーlocSYSには、loccdb1 (PDBのクローニング先のCDB)に対するSYSDBA権限が付与されています。

  • 管理ユーザーremSYSにはremcdb1 (クローニングするPDBを格納しているCDB)に対するSYSDBA権限が付与されています。

  • loccdb1へのクローニング後、PDBの名前はrefreshpdb1に変更されます。

次のsilentコマンドでは、rempdb1をloccdb1にクローニングします。 

./dbca -silent 
  -createPluggableDatabase
  -createFromRemotePDB
  -sourceDB loccdb1  
  -remotePDBName rempdb1 
  -remoteDBConnString remcdb1host:1521/reminst 
  -remoteDBSYSDBAUserName remSYS 
      -remoteDBSYSDBAUserPassword remsyspwd 
  -dbLinkUsername c##adminuser_remcdb1 
      -dbLinkUserPassword pwd4dblinkusr 
  -sysDBAUserName locSYS 
      -sysDBAPassword locsyspwd
  -pdbName refreshpdb1
  -createAsRefreshablePDB true
  -refreshMode AUTO
  -refreshInterval 60

関連項目:

DBCAコマンドの構文およびセマンティクスは、『Oracle Database管理者ガイド』を参照

親トピック: リフレッシュ可能なクローンPDBについて

PDBスナップショットからのPDBのクローニング

PDBスナップショットからPDBを作成するには、CREATE PLUGGABLE DATABASE … USING SNAPSHOT文を実行します。

親トピック: PDBのクローニング

PDBスナップショットからのPDBのクローニングについて

PDBスナップショットはPDBのPoint-in-Timeコピーです。スナップショットの作成中に、ソースPDBを読取り専用または読取り/書込みでオープンできます。PDBスナップショットからのクローンは、フルであり、スタンドアロンのPDBです。

親トピック: PDBスナップショットからのPDBのクローニング

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

PDBスナップショット・カルーセルは、最大8個のスナップショットのライブラリです。

カルーセルによって、特定のSCNまたは時点にPDBをクローニングできます。一般的なユースケースでは、カルーセルからPDBスナップショット(通常は最新のスナップショット)をリストアし、必要なSCNまたはタイムスタンプにリカバリします。

USING SNAPSHOT句の使用によるPDBの作成

CREATE PLUGGABLE DATABASE文のUSING SNAPSHOT句は、読取り専用のPDBスナップショットからアクティブなPDBを作成します。

使用可能なPDBスナップショットを確認するには、DBA_PDB_SNAPSHOTSデータ・ディクショナリ・ビューを問い合せます。スナップショットからPDBをクローニングするには、次のいずれかの値をUSING SNAPSHOT句で指定します。

  • PDBスナップショットの一意の名前

  • 次の形式のPDBスナップショットのSCN

    USING SNAPSHOT AT SCN scn

  • 次の形式のPDBスナップショットのタイムスタンプ

    USING SNAPSHOT AT TIME timestamp

PDBスナップショットからのクローンは、完全なスタンドアロンのPDBです。記憶域管理スナップショットに基づくスナップショット・コピーPDBとは異なり、スナップショット・クローンPDBをマテリアライズする必要はありません。

関連項目:

USING SNAPSHOT句の構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照してください

親トピック: PDBスナップショットからのPDBのクローニングについて

PDBスナップショットからのPDBのクローニング: シナリオ

このシナリオでは、CREATE PLUGGABLE DATABASE ... USING SNAPSHOTを実行して、PDBスナップショットから新しいPDBを作成します。

想定

この例では、次の要因を想定しています。

  • ソースPDB salespdbの8個の日次スナップショットを含むPDBスナップショット・カルーセルが存在しています。スナップショットには作成時の曜日、日付および時刻にちなんだ名前が付けられています(例: pdb1_mon_2_1201、pdb1_tue_3_1201、pdb1_wed_4_1201など)。

  • ソースのsalespdbが読取り/書込みモードであった場合は、すべてのスナップショットが作成されています。

  • 新しいPDBはpdb1_wed_4_1201という名前のスナップショットのクローンで、これは先週の水曜日、その月の4日の午前12時1分に取得されたpdb1のスナップショットです。

  • PATH_PREFIX句は必要ありません。

  • FILE_NAME_CONVERT句およびCREATE_FILE_DEST句は必要ありません。

    Oracle Managed Filesが有効であるか、またはPDB_FILE_NAME_CONVERT初期化パラメータが設定されています。したがって、FILE_NAME_CONVERT句は必要ありません。これらのファイルは、Oracle Managed Files構成または初期化パラメータ設定に基づいて新しい場所にコピーされます。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

PDBスナップショットからPDBをクローニングするには:

  1. SQL*Plusで、現在のコンテナがCDBルートまたはアプリケーション・ルートであることを確認します。

    現在のコンテナがCDBルートの場合、PDBはCDBに作成されます。現在のコンテナがアプリケーション・ルートの場合、アプリケーションPDBはアプリケーション・コンテナ内に作成されます。

  2. CREATE PLUGGABLE DATABASE ... USING SNAPSHOT文を実行します。

    次の文は、pdb1_wed_4_1201という名前のPDBのスナップショットからpdb1_copy PDBをクローニングします。 

    CREATE PLUGGABLE DATABASE pdb1_copy FROM pdb1 
  USING SNAPSHOT pdb1_wed_4_1201;

関連項目:

親トピック: PDBスナップショットからのPDBのクローニング

スナップショット・コピーPDBの作成およびマテリアライズ

PDBは、基礎となる記憶域のスナップショットからクローニングできます。PDBファイルはスパースですが、それらのファイルをマテリアライズしてスタンドアロンPDBを作成できます。

Oracle ACFSでは、PDBファイルはスパースにならないことに注意してください。そのかわりにストレージ・スナップショットが使用され、スナップショット・コピー・ファイルとソース・ファイルがストレージを共有します。

関連項目:

Oracle Advanced Cluster File SystemガイドのOracle ACFSおよびデータベース・データ・ファイルについて

親トピック: PDBのクローニング

スナップショット・コピーPDBについて

スナップショット・コピーPDBは、CREATE PLUGGABLE DATABASE ... FROM ... SNAPSHOT COPY文を実行することで作成できます。ソースPDBは、FROM句で指定します。

スナップショット・コピーにより、クローンの作成に必要な時間が短縮されます。これは、ソース・データ・ファイルの完全なコピーが含まれていないためです。さらに、スナップショット・コピーPDBは、ソースPDBの領域よりもわずかな領域しか占有しません。

記憶域クローンには、ターゲットPDBのGUIDを使用して名前およびタグが付けられます。記憶域クローンのクローン・タグを表示するには、DBA_PDB_HISTORY.CLONETAG列を問い合せます。

親トピック: スナップショット・コピーPDBの作成およびマテリアライズ

スナップショットのコピーPDBの記憶域要件

CREATE PLUGGABLE DATABASE ... FROM srcpdb ... SNAPSHOT COPYを使用する場合は、ソースPDBのデータ・ファイルが、同じ記憶域タイプで存在している必要があります。

CREATE PLUGGABLE DATABASE ... FROM ... SNAPSHOT COPYコマンドの動作は、次のルールに基づいて決まります。

  1. ファイル・システムで記憶域管理スナップショットがサポートされている場合、スナップショット・コピーPDBは、基礎となるファイル・システムの記憶域レベル・コピーに基づいています。スナップショット・コピーPDBファイルは、ソースとストレージを共有します。copy-on-writeテクノロジを使用すると、ディスク上の記憶域がさらに必要になるのは変更されたブロックのみとなります。

  2. ファイル・システムで記憶域スナップショットがサポートされていない場合、アルゴリズムは次のようになります。

    • ストレージ・システムでOracle Exadataスパース・ディスク・グループが使用されている場合は、Oracle Databaseによってスナップショット・コピーPDBが作成されます。ただし、そのスナップショット・コピーPDBの存続期間中は、ソースPDBが読取り専用のままである必要があります。

    • ストレージ・システムでOracle Exadataスパース・ディスク・グループが使用されない場合、動作は次のようになります。

      • CLONEDB=trueの場合、ソースPDBファイルの基礎になるファイル・システムは、任意のローカル・ファイル・システム、ネットワーク・ファイル・システム(NFS)またはOracle ACFSなどのクラスタ化ファイル・システムになります。ネットワーク・ファイル・システムを使用する場合は、CDBに対してDirect NFSを有効にする必要があります。ファイル・システムはスパース・ファイルをサポートする必要があります。ほとんどのUNIXシステムは、これらの要件を満たしています。

        CLONEDB=trueの場合、ソースPDBのオープン・モードには次のような影響があります。

        • ソースPDBが読取り専用モードでオープンされている場合、Oracle Databaseでは、copy-on-writeテクノロジを使用してスナップショット・コピーPDBが作成されます。スナップショット・コピーPDBには、完全コピーではなく、スパース・ファイルが含まれています。

        • ソースPDBが読取り/書込みモードでオープンされていない場合は、Oracle Databaseによってエラーが発行されます。

      • CLONEDB=falseの場合は、Oracle Databaseによってエラーが発行されます。

Direct NFSクライアントにより、Oracle Databaseは、オペレーティング・システム・カーネルのNFSクライアントを使用するかわりに、ネットワーク接続記憶域(NAS)デバイスに直接アクセスできます。ソースPDBのファイルがDirect NFSクライアント記憶域に格納されている場合は、次の追加の要件が満たされている必要があります。

  • ソースPDBファイルはNFSボリューム上に存在する必要があります。

  • 記憶域の資格証明は、透過的データ暗号化キーストアに格納されている必要があります。

  • 記憶域ユーザーは、ソースPDBのファイルをホストするボリューム上でスナップショットを作成および破棄するために必要な権限を持っている必要があります。

  • 資格証明は、ADMINISTER KEY MANAGEMENT ADD SECRET SQL文を使用してキーストアに格納されている必要があります。

    次の例では、ソフトウェア・キーストアのOracle Databaseシークレットを構成しています。

    ADMINISTER KEY MANAGEMENT  
  ADD SECRET 'secret' FOR CLIENT 'client_name' 
  USING TAG 'storage_user' 
  IDENTIFIED BY  keystore_password  WITH BACKUP;

    構成内の各記憶域サーバーに対して個別のエントリを追加するには、この文を実行します。前の例では、次の値を指定する必要があります。

    • secretは、記憶域パスワードです。

    • client_nameは、記憶域サーバーです。LinuxまたはUNIXのプラットフォームでは、/etc/hostsに入力した名前または記憶域サーバーのIPアドレスです。

    • tagは、記憶域サーバーに渡されるユーザー名です。

    • keystore_passwordは、キーストアのパスワードです。

ノート:

スナップショット・コピーの動作および効率性はベンダー固有であり、ベンダーによって異なる場合があります。

関連項目:

親トピック: スナップショット・コピーPDBについて

スナップショット・コピーPDBの制限

スナップショット・コピーPDBの基になっている記憶域スナップショットは削除できません。

スナップショット・コピーPDBをCDBルートまたはアプリケーション・コンテナから切断することはできません。スナップショット・コピーPDBを切断しようとすると、エラーが発生します。ただし、スナップショット・コピーPDBのマテリアライズは可能です。マテリアライズによってスタンドアロンPDBにすると、削除できるようになります。

ストレージ管理のスナップショットの場合、新しいスナップショットPDBが作成され、コマンドを実行するローカル・ノードにのみマウントされます。Oracle RACデータベースの場合、新しいスナップショット・ファイル・システムを手動でマウントし、他のノードでPDBをオープンする必要があります。

スナップショット・コピーPDBの作成: シナリオ

このシナリオでは、CREATE PLUGGABLE DATABASEでSNAPSHOT COPY句を指定することで、スナップショット・コピーPDBを作成します。

想定

このシナリオでは、次の要因を想定しています。

  • 新しいスナップショット・コピーPDBは、pdb1というPDBから作成されます。

  • 基礎となるファイル・システムでは、記憶域スナップショットがサポートされています。したがって、CLONEDB初期化パラメータを設定する必要はありません。

  • PATH_PREFIX句は必要ありません。

  • FILE_NAME_CONVERT句およびCREATE_FILE_DEST句は必要ありません。

    Oracle Managed Filesが有効であるか、またはPDB_FILE_NAME_CONVERT初期化パラメータが設定されています。したがって、FILE_NAME_CONVERT句は必要ありません。これらのファイルは、Oracle Managed Files構成または初期化パラメータ設定に基づいて新しい場所にコピーされます。

  • PDBにはストレージ制限は必要ありません。したがって、STORAGE句は必要ありません。

  • ターゲットの場所に、作成される新しい一時ファイルと同じ名前のファイルはありません。したがって、TEMPFILE REUSE句は必要ありません。

スナップショット・コピーPDBを作成するには:

  1. SQL*Plusで、現在のコンテナがCDBルートまたはアプリケーション・ルートであることを確認します。

    現在のコンテナがCDBルートの場合、PDBはCDBに作成されます。現在のコンテナがアプリケーション・ルートの場合、アプリケーションPDBはアプリケーション・コンテナ内に作成されます。

  2. CREATE PLUGABBLE DATABASE … SNAPSHOT COPY文を実行します。

    次の文は、pdb1からpdb1_snap_copy PDBをクローニングします。 

    CREATE PLUGGABLE DATABASE pdb1_snap_copy FROM pdb1 SNAPSHOT COPY;

    pdb1_snap_copyが存在するかぎり、pdb1_snap_copyの基になっている記憶域スナップショットは削除できません。

関連項目:

「スナップショット・コピーPDBのマテリアライズ」

親トピック: スナップショット・コピーPDBの作成およびマテリアライズ

スナップショット・コピーPDBのマテリアライズ

MATERIALIZE句を指定したALTER PLUGGABLE DATABASE文を実行して、スナップショット・コピーPDBをマテリアライズできます。スナップショット・コピーPDBをマテリアライズすると、すべてのデータ・ブロックがコピーされます。

スナップショット・コピーPDBをマテリアライズすると、スナップショット・コピーPDB(スパース・ファイルを使用する)は、完全PDB(スパース・ファイルを使用しない)に変換されます。マテリアライズされたPDBは、ソースPDBに依存しなくなり、削除や別のオープン・モードへの変更が可能です。

たとえば、pd1_snap_copyがスナップショット・コピーPDBである場合は、ALTER PLUGGABLE DATABASE MATERIALIZEコマンドを実行することで、それをマテリアライズしてスタンドアロンPDBにできます。マテリアライズ後は、pdb1_snap_copyは記憶域レベルのスナップショットに依存しなくなり、削除できるようになります。

PDBスナップショットをマテリアライズするには:

  1. SQL*Plusで、現在のコンテナがマテリアライズされるスナップショット・コピーPDBであることを確認します。

  2. MATERIALIZE句を指定してALTER PLUGGABLE DATABASE文を実行します。

例8-2 スナップショット・コピーPDBのマテリアライズ

次のSQL文は、スナップショット・コピーPDBをマテリアライズします。

ALTER PLUGGABLE DATABASE MATERIALIZE;

関連項目:

親トピック: スナップショット・コピーPDBの作成およびマテリアライズ

分割ミラーによるクローンPDBの作成

Oracle ASMでは、分割ミラーは親コピーからPoint-in-Timeメディア・コピーをデタッチするプロセスです。分割後、親コピーに対する更新は子コピーに影響しません。

Oracle Database 18c以降では、親コピーは、記憶域ボリュームではなく、PDBであることが可能です。分割ミラーによるクローンPDBは親と同じメディア上に存在します。主要なユースケースでは、Oracle ASM環境でテストおよび開発のPDBを迅速にプロビジョニングします。

ノート:

分割ミラーによるクローンPDBには、Oracle ASMの柔軟性および拡張ディスク・グループが必要です。

ミラー・リフレッシュによって、親PDBからの変更で分割ミラーによるクローンPDBをリフレッシュします。実際には、この操作は、ミラー分割を削除してから新しいミラー分割を取得するのと同じです。

分割ミラーによるクローンPDBを削除するには、ALTER PLUGGABLE DATABASE ... DROP MIRROR COPYを入力します。

分割ミラーによるクローンPDBを作成するには:

  1. SQL*Plusを起動し、CDBルートに接続します。

  2. ソースPDBは、ALTER PLUGGABLE DATABASE ... PREPARE MIRROR COPY文を発行することで準備します。

    別のCDBにPDBを作成する場合は、FOR DATABASE database_name句を指定したALTER PLUGGABLE DATABASE ... PREPARE MIRROR COPY文を発行します。database_nameはターゲットCDBの名前です。

  3. CREATE PLUGGABLE DATABASE ... FROM ... USING MIRROR COPY文を発行して、ソースPDBからクローンPDBを作成します。

    別のCDBにPDBを作成する場合は、ソースCDBへのデータベース・リンクをFROM句に含めます。CREATE PLUGGABLE DATABASEコマンドを発行する前に、ALTER PLUGGABLE DATABASE ... PREPARE MIRROR COPYコマンドの発行元のソースCDBに接続できるデータベース・リンクを作成する必要があります。

  4. 必要に応じて、V$ASM_DBCLONE_INFOビューを問い合せて、ソースPDB、クローニングされたPDB、およびそのファイル・グループ間の関係を確認します。

関連項目:

親トピック: PDBのクローニング