1. データベース概要
  2. マルチテナント・アーキテクチャ
  3. CDBおよびPDB

2 CDBおよびPDB

マルチテナント・アーキテクチャを使用すると、Oracle Databaseをマルチテナント・コンテナ・データベース(CDB)として機能させることができます。

Oracle Database 20cから、マルチテナント・コンテナ・データベースがサポート対象の唯一のアーキテクチャになりました。前のリリースでは、Oracleは非コンテナ・データベース(非CDB)をサポートしていました。

この章のトピックは、次のとおりです:

CDBのコンテナについて

コンテナは、マルチテナント・コンテナ・データベース(CDB)内のスキーマ、オブジェクトおよび関連構造の集合です。CDB内では、各コンテナは一意のIDと名前を持ちます。

CDBには、顧客が作成した0個以上のプラガブル・データベース(PDB)およびアプリケーション・コンテナが含まれています。PDBは、Oracle Netクライアントに個別のデータベースとして表示されるスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトのポータブル・コレクションです。アプリケーション・コンテナはオプションのユーザー作成CDBコンポーネントで、1つ以上のアプリケーション・バックエンドのデータおよびメタデータが格納されます。CDBにはゼロ以上のアプリケーション・コンテナが含まれます。

注意:

アプリケーション・コンテナでは、アプリケーション・コンテナについて詳しく説明します。

次の図は、CDBで使用可能なコンテナを示しています。

図2-1 CDB内のコンテナ

図2-1の説明が続きます
「図2-1 CDB内のコンテナ」の説明

CDBごとに、次のコンテナがあります。

  • 1つのみのCDBルート・コンテナ(単純にルートとも呼ばれる)

    CDBルートは、すべてのPDBが属するスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合です(CDBおよびPDBを参照)。ルートには、Oracle提供のメタデータおよび共通ユーザーが格納されます。メタデータの例は、Oracle提供のPL/SQLパッケージのソース・コードです。共通ユーザーは、すべてのコンテナで認識されるデータベース・ユーザーです(共通ユーザー・アカウントを参照)。ルート・コンテナには、CDB$ROOTという名前が付いています。

  • 1つのみのシステム・コンテナ

    システム・コンテナにはルートCDBおよびCDB内のすべてのPDBが含まれます。このように、システム・コンテナはCDB自体の論理コンテナです。

  • 0以上のアプリケーション・コンテナ

    アプリケーション・コンテナは1つのアプリケーション・ルートと、このルートに接続しているPDBで構成されます。システム・コンテナにはCDBルートおよびCDB内のすべてのPDBが含まれますが、アプリケーション・コンテナにはアプリケーション・ルートに接続しているPDBのみが含まれます。アプリケーション・ルートはCDBルートに属しており、他のコンテナには属しません。

  • 0以上のユーザー作成PDB

    PDBには特定の機能セットに必要なデータおよびコードが格納されています(「PDB」を参照してください)。たとえば、PDBでは、人事管理または販売アプリケーションなど、特定のアプリケーションをサポートできます。CDBの作成時にはPDBは存在しません。ビジネスの要件に基づいてPDBを追加します。

    PDBはゼロまたは1つのアプリケーション・コンテナに属しています。PDBがアプリケーション・コンテナに属す場合、これはアプリケーションPDBになります。たとえば、cust1_pdbおよびcust2_pdbのアプリケーションPDBがsaas_sales_acアプリケーション・コンテナに属す場合、これらは他のアプリケーション・コンテナには属していません。アプリケーション・シードはユーザー作成のPDBテンプレートとして機能するオプションのアプリケーションPDBで、これによって新規のアプリケーションPDBを迅速に作成できます。

  • 1つのシードPDB

    シードPDBは、システム提供のテンプレートで、CDBではこれを使用して新しいPDBを作成できます。シードPDBには、PDB$SEEDの名前が付いています。PDB$SEEDでは、オブジェクトの追加や変更はできません。

例2-1 アプリケーション・コンテナを使用しないCDB

この例は、システム・コンテナ(CDB全体)、CDBルート、PDBシード(PDB$SEED)および2つのPDBという5つのコンテナがあるシンプルなCDBを示しています。各PDBには、独自の専用アプリケーションがあります。各PDB管理者はそれぞれのPDBを管理します。共有ユーザーは、1つのCDB全体に1つのIDで存在します。この例では、共有ユーザーSYSは、ルートおよびすべてのPDBを管理できます。物理レベルでは、このCDBは1つ以上のデータベース・インスタンスによって管理され、各PDBおよびCDB自体の一連のデータ・ファイルが含まれています。

図2-2 アプリケーション・コンテナを使用しないCDB

図2-2の説明が続きます
「図2-2 アプリケーション・コンテナを使用しないCDB」の説明

例2-2 アプリケーション・コンテナを使用するCDB

この例では、CDBにsaas_sales_acというアプリケーション・コンテナが含まれます。アプリケーション・コンテナ内で、アプリケーションPDBのcust1_pdbは1人の顧客のアプリケーションをサポートし、アプリケーションPDBのcust2_pdbは別の顧客のアプリケーションをサポートします。CDBにはhrpdbというPDBも含まれており、これはHRアプリケーションをサポートしますが、アプリケーション・コンテナには属していません。

図2-3 アプリケーション・コンテナを使用するCDB

図2-3の説明が続きます
「図2-3 アプリケーション・コンテナを使用するCDB」の説明

この例では、複数のDBAがCDB環境を管理します。

  • CDB管理者はCDB自体を管理します。

  • アプリケーション・コンテナ管理者は、アプリケーションのインストールおよびアップグレードも含めてsaas_sales_acコンテナを管理します。

  • アプリケーションPDB管理者は、cust1_pdbおよびcust2_pdbという、saas_sales_acコンテナ内の2つのPDBを管理します。

  • PDB管理者はhrpdbを管理します。

CDBルートとシステム・コンテナ

CDBルート(単純にルートとも呼ばれている)は、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合で、すべてのPDBはこれに属します。

どのCDBにも、CDB$ROOTという名前のルート・コンテナが1つだけあります。ルートにはPDBの管理に必要なシステム・メタデータが格納されます。すべてのPDBはこのルートに属します。システム・コンテナは、CDBルートとこのルートに属するすべてのPDBです。

CDBルートにはユーザー・データは格納されません。共通オブジェクトをルートに追加したり、ルート内のOracle提供スキーマを変更したりしないことをお薦めします。ただし、データベース管理用の共通ユーザーおよびロールを作成できます。必要な権限を持った共通ユーザーは、コンテナ間の切替えが可能です。

ルート・キャラクタ・セットとして、AL32UTF8をお薦めします。キャラクタ・セット変換をしなくても、異なるキャラクタ・セットを使用するPDBが同じCDB内に存在できます。

例2-3 CDBのすべてのコンテナ

CDBルートに接続された管理ユーザーによって発行される次の問合せによって、CDB内のすべてのコンテナ(シードおよびCDBルートを含む)がCON_IDの順序でリストされます。 

COL NAME FORMAT A15
SELECT NAME, CON_ID, DBID, CON_UID, GUID 
FROM   V$CONTAINERS ORDER BY CON_ID;

NAME          CON_ID       DBID    CON_UID GUID
------------- ------ ---------- ---------- --------------------------------
CDB$ROOT           1 1895287725          1 2003321EDD4F60D6E0534E40E40A41C5
PDB$SEED           2 2795386505 2795386505 200AC90679F07B55E05396C0E40A23FE
SAAS_SALES_AC      3 1239646423 1239646423 200B4CE0A8DC1D24E05396C0E40AF8EE
SALESPDB           4 3692549634 3692549634 200B4928319C1BCCE05396C0E40A2432
HRPDB              5 3784483090 3784483090 200B4928319D1BCCE05396C0E40A2432

関連項目:

共通ユーザー・アカウント

PDB

PDBは、ユーザーが作成したスキーマ、オブジェクトおよび関連構造体のセットで、論理的にクライアント・アプリケーションでは個別のデータベースとして表示されます。

あらゆるPDBは、PDBを作成したユーザーに関係なくSYSによって所有されます。SYSはCDB内の共通ユーザーで、rootおよびCDB内の既存と将来のすべてのPDBにおいて同じIDを持つこのユーザーです。

PDBのタイプ

すべてのPDBは、Oracle提供のPDB$SEEDを除いて、CREATE PLUGGABLE DATABASE文でユーザー作成されます。

次のタイプのPDBを作成できます。

標準PDB

このタイプのPDBは、シード、プロキシPDBまたはアプリケーション・ルートとしてPDBを指定せずに、CREATE PLUGGABLE DATABASEを実行することによって生成されます。その機能は作成する対象のコンテナによって異なります。

  • CDBルートに接続されているPDB

    このPDBはCDBルート・コンテナに属しており、アプリケーション・コンテナには属していません。このタイプのPDBは、アプリケーション共通オブジェクトを使用できません。「アプリケーション共通オブジェクト」を参照してください。

  • アプリケーションPDB

    アプリケーションPDBは1つのアプリケーション・コンテナのみに属しています。CDBルートに接続しているPDBとは異なり、アプリケーションPDBはアプリケーション・コンテナ内のマスター・アプリケーション定義を共有できます。たとえば、アプリケーション・ルート内のusa_zipcodes表はデータリンク共通オブジェクトになる場合があり、ここに含まれているデータはこのルートに接続しているすべてのアプリケーションPDBによってアクセスが可能です。アプリケーション・コンテナに存在しないPDBは、そのアプリケーション共通オブジェクトにアクセスできません。

アプリケーション・ルート

アプリケーション・ルートは、アプリケーション固有のルート・コンテナとみなされます。アプリケーション・バックエンドのマスター定義(共通データとメタデータを含む)用のリポジトリとして機能します。アプリケーション・コンテナを作成するには、CDBルートに接続し、CREATE PLUGGABLE DATABASE文にAS APPLICATION CONTAINER句を指定します。アプリケーション・ルートを参照してください。

シードPDB

標準PDBとは異なり、シードPDBはアプリケーションのサポートを目的としていません。むしろ、シードはアプリケーションをサポートするPDBを作成するためのテンプレートです。シードは次のいずれかです。

  • CDBルートに接続しているシードPDB(PDB$SEED)

    このシステム付属テンプレートを使用して、アプリケーション・コンテナまたはシステム・コンテナのいずれかで新規のPDBを作成できます。システム・コンテナに含まれるPDBシードは1つのみです。PDB$SEEDは、削除したり、シードPDBに対してオブジェクトを追加または変更することはできません。

  • アプリケーション・シードPDB

    アプリケーション・コンテナ内のアプリケーションPDBの作成を促すため、オプションのアプリケーション・シードを作成できます。アプリケーション・コンテナにはゼロまたは1つのアプリケーション・シードが含まれます。

    アプリケーション・シードは、アプリケーション・コンテナに接続してCREATE PLUGGABLE DATABASE ... AS SEED文を実行することで作成します。アプリケーション・シードを参照してください。

プロキシPDB

プロキシPDBは、データベース・リンクを使用してリモートCDB内のPDBを参照するPDBです。PDBが開いている間にプロキシPDBで文を発行すると、その文は参照先PDB内で実行されます。

プロキシPDBは、CDBルートまたはアプリケーション・ルートへの接続中に作成する必要があります。プロキシPDBは、標準PDBと同じように変更または削除ができます。

PDBの目的

アプリケーションの観点では、PDBは自己完結した完全に機能するOracleデータベースです。PDBを1つのCDBに統合することで、PDBの分離を維持しながら規模の経済性が得られます。

PDBを使用して、次の特定の目的を達成できます。

  • アプリケーション固有のデータの格納

    たとえば、販売アプリケーションは独自の専用PDBを持ち、人事管理アプリケーションも独自の専用PDBを持つことができます。もう1つの方法として、アプリケーション・コンテナ(PDBの名前付きコレクション)を作成して、共通のデータおよびメタデータが含まれるアプリケーション・バックエンドを格納できます。

  • 異なるCDBへのデータの移動

    データベースがプラガブルなのは、それを自己完結型のユニットとしてパッケージ化(切断されたPDBと呼ばれる)し、別のCDBに移動できるからです。

  • 迅速なアップグレードの実行

    旧リリースのOracle DatabaseのCDBからPDBを切断してから、新リリースのCDBにそのPDBを接続できます。

  • 可用性を維持しながらも迅速なデータのコピー

    テストおよび開発のために、PDBを開いている状態のままでクローニングして、そのクローンを同じまたは別のCDB内に格納できます。オプションで、リフレッシュ可能クローンPDBとしてPDBを指定できます。また、Oracle提供のシードPDBまたはユーザー作成アプリケーション・シードを使用して新しいPDBをコピーすることもできます。

  • 異なるCDB内の参照データ

    同じCDBまたは別のCDB内のいずれかで、異なるPDBを参照するプロキシPDBを作成できます。プロキシPDBで文を発行すると、その文は参照先PDB内で実行されます。

  • PDB内での付与の分離

    適切な権限を持つローカルまたは共通ユーザーは、スキーマ・オブジェクトのEXECUTE権限を個々のPDB内のPUBLICに付与できます。

関連項目:

プロキシPDB

プロキシPDBは、参照先PDBと呼ばれるリモートPDBを参照します。

プロキシ(参照元)PDBでSQL文を発行する場合でも、その文は参照先PDB内で実行されます。この点において、プロキシPDBはLinuxのシンボリック・リンク・ファイルと大まかに似ています。

プロキシPDBには、次の利点があります。

  • 複数のアプリケーション・モデルからデータを集計します

    プロキシPDBを使用すると、複数のソースからデータを集計できる位置透過的なアプリケーションを構築できます。これらのソースは、同じデータ・センター内にあっても、複数のデータ・センターに分散していてもかまいません。

  • 1つのCDB内のアプリケーション・ルートが、別のアプリケーション・ルートにアプリケーションの変更を伝播できるようになります

    CDBのcdb_prodおよびcdb_testのアプリケーション・モデルが同じであると仮定します。cdb_testのアプリケーション・ルートを参照するプロキシPDBをcdb_prodのアプリケーション・コンテナに作成します。cdb_prodのアプリケーション・ルートでインストールおよびアップグレードのスクリプトを実行すると、Oracle Databaseではこれらの文がプロキシPDBに伝播され、これは次にcdb_testのアプリケーション・ルートにリモートで送信されます。このように、cdb_testのアプリケーション・ルートがcdb_prodのアプリケーション・ルートのレプリカになります。

プロキシPDBを作成するには、AS PROXY FROM句を含むCREATE PLUGGABLE DATABASEを実行します(FROMは参照先PDB名およびデータベース・リンクを指定します)。作成文では、SYSTEMおよびSYSAUX表領域に属すデータ・ファイルのみがコピーされます。

例2-4 プロキシPDBの作成

この例ではローカル本番CDBのコンテナsaas_sales_acに接続します。sales_admin共通ユーザーは、sales_sync_pdbというプロキシPDBを作成します。このアプリケーションPDBは、cdb_dev_remデータベース・リンクを使用してアクセスするリモート開発CDBの、saas_sales_test_acというアプリケーション・ルートを参照します。本番CDBのsaas_sales_acでアプリケーションのアップグレードが発生すると、リモート開発CDBのアプリケーション・ルートsaas_sales_test_acにアップグレードが自動的に伝播されます。 

CONNECT sales_admin@saas_sales_ac
Password: ***********

CREATE PLUGGABLE DATABASE sales_sync_pdb AS PROXY FROM saas_sales_test_ac@cdb_dev_rem;

PDBの名前

CDB内のコンテナは同じネームスペースを共有します。つまり、このネームスペース内では一意の名前を保持する必要があります。

次のコンテナの名前は同じCDB内で競合しないことが必要です。

  • CDBルート

  • CDBルートに接続されているPDB

  • アプリケーション・ルート

  • アプリケーションPDB

たとえば、同じCDBにアプリケーション・コンテナsaas_sales_acとsaas_sales_test_acが含まれる場合、両方ともcust1と名付けられた2つのアプリケーションPDBが両方のコンテナに同時に存在することはできません。このネームスペース・ルールではCDBルートでのcust1pdbというPDBの作成と、アプリケーション・ルートでのcust1pdbというPDBの作成も妨げられます。

PDBおよびアプリケーション・ルート・コンテナの名前は、ネット・サービス名と同じルールに従う必要があります。さらに、PDBまたはアプリケーション・ルートは独自の名前のサービスを持つため、コンテナ名は、特定のリスナーを介して公開されるサービスを所有するすべてのCDBにわたって一意にする必要があります。ユーザー作成のコンテナ名は最初の文字を英数字にし、それ以降の文字を英数字またはアンダースコア(_)にする必要があります。サービス名には大文字小文字の区別がないため、コンテナ名にも大文字と小文字の区別はなく、区切り識別子を使用して指定しても、大文字になります。

関連項目:

サービス名のルールの詳細は、『Oracle Database Net Servicesリファレンス』を参照

PDB間のデータベース・リンク

デフォルトで、あるPDBに接続しているユーザーが、別のPDBのオブジェクトにアクセスするには、データベース・リンクを使用する必要があります。

図2-4 PDB間のデータベース・リンク

この図で、PDB管理者はhrpdb1というPDBに接続されています。デフォルトで、このユーザー・セッション中に、c##dbaがデータベース・リンクを指定せずにhrpdb2のemp2表に問合せすることはできません。

図2-4の説明が続きます
「図2-4 PDB間のデータベース・リンク」の説明

このルールには、次の例外があります。

  • データリンク共通オブジェクトは、このオブジェクトを示すデータ・リンクが含まれるすべてのアプリケーションPDBによってアクセス可能です。たとえば、アプリケーション・コンテナsaas_sales_acではそのアプリケーション内にデータリンク表usa_zipcodesが含まれる場合があります。この場合、共通CDBユーザーc##dbaはこのコンテナ内のアプリケーションPDBに接続して、実際の表がアプリケーション・ルートに存在する場合でもusa_zipcodesに問合せすることができます。この場合は、データベース・リンクは必要ありません。

  • CDBルートまたはアプリケーション・ルートから発行されるSQLのCONTAINERS()句。この句を使用すると、コンテナ・ルートに接続されたすべてのPDB間でデータを問い合せることができます。

プロキシPDBを作成するとき、CREATE PLUGGABLE DATABASE ... AS PROXY文のFROM句でデータベース・リンク名を指定する必要があります。プロキシPDBと参照先PDBが別々のCDBに存在する場合は、プロキシPDBが含まれるCDBのルート内でデータベース・リンクが定義されている必要があります。データベース・リンクは、リモート参照先PDB、またはリモートCDBのCDBルートのいずれかに接続する必要があります。

関連項目:

共通オブジェクトとローカル・オブジェクト