3 アプリケーション・コンテナ

CDB内に、PDBで共有できるアプリケーション・データおよびメタデータ用のコンテナを作成できます。

関連項目:

アプリケーション共通オブジェクトについて学習するには、共通オブジェクトおよびローカル・オブジェクトを参照してください。

アプリケーション・コンテナについて

アプリケーション・コンテナはオプションのユーザー作成CDBコンポーネントで、1つ以上のアプリケーション・バックエンドのデータおよびメタデータが格納されます。CDBにはゼロ以上のアプリケーション・コンテナが含まれます。

アプリケーション・コンテナ内で、アプリケーションはアプリケーション・ルートに格納される共通データおよびメタデータの名前付けおよびバージョニングされたセットです。このアプリケーション・コンテナのコンテキストでは、「アプリケーション」という用語は「マスター・アプリケーション定義」を意味します。たとえば、表、ビュー、パッケージなどの定義をアプリケーションに含めることができます。

たとえば、1つのアプリケーション・コンテナ内で複数の販売関連PDBを作成し、これらのPDBが一連の共通表および表定義で構成されるアプリケーション・バックエンドを共有するようにできます。複数のHR関連PDBを、その独自の共通表および表定義とともに別のアプリケーション・コンテナ内で格納できます。

AS APPLICATION CONTAINER句を使用したCREATE PLUGGABLE DATABASE文によってアプリケーション・コンテナのアプリケーション・ルートが作成され、これによって暗黙的にアプリケーション・コンテナ自体が作成されます。アプリケーション・コンテナを最初に作成した時点では、PDBは含まれていません。アプリケーションPDBを作成するには、アプリケーション・ルートに接続してCREATE PLUGGABLE DATABASE文を実行する必要があります。

CREATE PLUGGABLE DATABASE文で、たとえば、saas_sales_acなどのコンテナ名(アプリケーション・ルート名と同じ)を指定する必要があります。アプリケーション・コンテナ名は、CDB内と、そのインスタンスが特定のリスナーを介してアクセスされるすべてのCDBのスコープ内で一意にする必要があります。すべてのアプリケーション・コンテナに、アプリケーション・コンテナと同じ名前のデフォルト・サービスがあります。

アプリケーション・コンテナの目的

アプリケーション・コンテナはある意味で、CDB内のアプリケーション固有CDBとして機能します。アプリケーション・コンテナにはCDB自身のように複数のPDBが含まれ、これらのPDBはメタデータおよびデータを共有できます。

アプリケーション・ルートによってアプリケーションPDBが、アプリケーション(このコンテキストでは共通メタデータおよびデータの名前付けおよびバージョニングされたセット)を共有できます。一般的なアプリケーションではアプリケーション共通ユーザー、メタデータリンク共通オブジェクト、およびデータリンク共通オブジェクトがインストールされます。

アプリケーション・コンテナの主な利点

アプリケーション・コンテナにより、個々のアプリケーションを別々のPDBに格納することの利点が提供されます。

  • アプリケーション・ルートは、すべてのアプリケーションPDBが共有できるメタデータおよびデータを格納します。

    たとえば、すべてのアプリケーションPDBは中央にある1つの表(デフォルトのアプリケーション・ロールをリストする表など)のデータを共有できます。また、すべてのPDBはPDB固有行の追加先である表定義を共有できます。

  • マスター・アプリケーション定義は、各PDBで個別のコピーを保持するのではなく、アプリケーション・ルートで保持されます。

    アプリケーション・ルートでアプリケーションをアップグレードすると、その変更はすべてのアプリケーションPDBに自動的に伝播されます。アプリケーション・バックエンドには、データリンク共通オブジェクトapp_rolesが含まれている場合があります。これは、adminmanagersales_repなどのデフォルト・ロールをリストする表です。アプリケーションPDBに接続したユーザーは、この表を問い合せることができます。

  • アプリケーション・コンテナには、アプリケーション・シード、アプリケーションPDBおよびプロキシPDB (他のCDB内のPDBを参照する)を含めることができます。

  • 新規のアプリケーションPDBをアプリケーション・シードから迅速に作成できます。

  • アプリケーション・コンテナですべてのPDBについてレポートするビューを問合せできます。

  • アプリケーション・ルートへの接続中に、CONTAINERS関数を使用して、複数のPDB内のオブジェクトに対してDMLを実行できます。

    たとえば、あらゆるアプリケーションPDBにproducts表が存在する場合、アプリケーション・ルートに接続して、単一のSELECT文を使用してすべてのアプリケーションPDB内の製品を問合せできます。

  • PDBをアプリケーション・ルートから切断してから、新しいOracle Databaseリリースのアプリケーション・ルートにそのPDBを接続できます。したがって、PDBはOracle Databaseのアップグレードに役立ちます。

アプリケーション・コンテナのユースケース: SaaS

SaaSデプロイメントでは、個々が別の顧客用で、メタデータおよびデータを共有する複数のアプリケーションPDBを使用できます。

純粋なSaaS環境では、マスター・アプリケーション定義はアプリケーション・ルート内に存在しますが、顧客固有のデータはその固有のアプリケーションPDB内に存在します。たとえば、sales_appはアプリケーション・ルート内のアプリケーション・モデルです。cust1_pdbというアプリケーションPDBには顧客1用の販売データのみが含まれる一方、cust2_pdbというアプリケーションPDBには顧客2用の販売データのみが含まれます。接続、切断、クローニングおよびその他のPDBレベルの操作を、個々の顧客PDBで使用できます。

図3-1 SaaSのユースケース

図3-1の説明が続きます
「図3-1 SaaSのユースケース」の説明

純粋なSaas構成には次のメリットがあります。

  • パフォーマンス

  • セキュリティ

  • 複数の顧客のサポート

    各顧客のデータは、その固有のコンテナ内に存在しますが、多くの顧客をまとめて管理できるように統合されます。このモデルにより、多くの要素を1つにまとめて管理する規模の経済性が、DBAのみでなくアプリケーション管理者にも適用されます。

アプリケーション・コンテナのユースケース: 論理データ・ウェアハウス

顧客は複数のアプリケーションPDBを使用してデータの主権の問題に対応できます。

サンプル・ユースケースでは、ある会社が各会計四半期に固有のデータを別個のPDBに配置しています。たとえば、sales_acというアプリケーション・コンテナにq1_2016_pdbq2_2016_pdbq3_2016_pdbおよびq4_2016_pdbが含まれています。個々のトランザクションは、関連する四半期に対応するPDB内で定義します。1年間の業績を集計するレポートを生成するには、CONTAINERS()句を使用して4つのPDB間で集計します。

この論理ウェアハウス設計の利点は次のとおりです。

  • 1つのPDBに固有のデータに対するETLが他のPDBに影響しません。

  • 実行計画が、実際のデータ分布に基づいているため、より効率的です。

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

アプリケーション・コンテナには、コンテナ内のアプリケーションPDBの親であるアプリケーション・ルートが1つだけあります。

アプリケーション・ルートになるためのプロパティは作成時に確立され、変更することはできません。アプリケーション・ルートが属すコンテナはCDBルートのみです。アプリケーション・ルートはある面ではCDBルートに類似し、別の面ではPDBに類似しています。

  • CDBルートと同様に、アプリケーション・ルートは接続されているPDBの親コンテナとして機能します。アプリケーション・ルートへの接続中に、共通ユーザーおよび権限の管理、アプリケーションPDBの作成、コンテナの切替え、およびアプリケーション・コンテナのすべてのPDBに適用されるDDLの発行などができます。

  • PDBと同様に、CREATE PLUGGABLE DATABASE文でアプリケーション・ルートを作成し、それをALTER PLUGGABLE DATABASEで変更し、その可用性をSTARTUPおよびSHUTDOWNで変更することができます。アプリケーション・ルートの接続、切断および削除にはDDLを使用できます。アプリケーション・ルートには固有のサービス名があり、ユーザーはPDBに接続するのと同じ方法でアプリケーション・ルートに接続できます。

アプリケーション・ルートは、CDBルートおよび標準PDBのどちらとも異なります。これは、アプリケーション共通オブジェクトと呼ばれるユーザー作成共通オブジェクトを格納できるためです。アプリケーション共通オブジェクトはアプリケーション・ルートに接続されたアプリケーションPDBにとってアクセス可能です。アプリケーション共通オブジェクトはCDBルート、他のアプリケーション・ルート、またはアプリケーション・ルートに属さないPDBには表示されません。

例3-1 アプリケーション・ルートの作成

この例では、管理共通ユーザーc##systemとしてCDBルートにログインします。saas_sales_acというアプリケーション・コンテナを作成し、コンテナと同じ名前を持つアプリケーション・ルートをオープンします。

-- Create the application container called saas_sales_ac
CREATE PLUGGABLE DATABASE saas_sales_ac AS APPLICATION CONTAINER
  ADMIN USER saas_sales_ac_adm IDENTIFIED BY manager; 

-- Open the application root
ALTER PLUGGABLE DATABASE saas_sales_ac OPEN;

現在のコンテナをsaas_sales_acに設定し、このコンテナがアプリケーション・ルートであることを確認します。

-- Set the current container to saas_sales_ac
ALTER SESSION SET CONTAINER = saas_sales_ac;

COL NAME FORMAT a15
COL ROOT FORMAT a4
SELECT CON_ID, NAME, APPLICATION_ROOT AS ROOT, 
       APPLICATION_PDB AS PDB,
FROM   V$CONTAINERS;

    CON_ID NAME            ROOT PDB
---------- --------------- ---- ---
         3 SAAS_SALES_AC   YES	NO

アプリケーションPDB

アプリケーションPDBはアプリケーション・コンテナ内に存在するPDBです。CDB内のPDBはすべて、ゼロまたは1つのアプリケーション・コンテナに存在します。

たとえば、saas_sales_acアプリケーション・コンテナで複数の顧客がサポートされ、個々の顧客アプリケーションがそのデータを別々のPDBに格納する場合があります。cust1_sales_pdbおよびcust2_sales_pdbのアプリケーションPDBがsaas_sales_acに存在する場合、これらは他のアプリケーション・コンテナには属していません(ただし、PDBは必然的にCDBルートにも属します)。

アプリケーション・ルートへの接続中にCREATE PLUGGABLE DATABASEを実行して、アプリケーションPDBを作成します。シードからアプリケーションPDBを作成するか、PDBをクローニングするか、または切断されたPDBを接続することができます。CDBルートに接続しているPDBと同様に、アプリケーションPDBをクローニング、切断または削除できます。ただし、アプリケーションPDBは常にアプリケーション・ルートに属す必要があります。

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

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

アプリケーション・シードを使用すると、アプリケーションPDBを簡単に作成できます。これはアプリケーション・コンテナ内で、PDB$SEEDがCDB内で果たす役割と同じ役割を果たします。

アプリケーション・シード名は常にapplication_container_name$SEEDとなり、application_container_nameはアプリケーション・コンテナの名前を表します。たとえば、CREATE PDB ... AS SEED文を使用して、saas_sales_acアプリケーション・コンテナにsaas_sales_ac$SEEDを作成します。

アプリケーション共通オブジェクト

アプリケーション共通オブジェクトは、アプリケーション・ルートのアプリケーション内で作成される共通オブジェクトです。共通オブジェクトはデータリンクされているか、メタデータリンクされているかのいずれかです。

データリンク共通オブジェクトの場合、アプリケーションPDBは単一のデータのセットを共有します。たとえば、saas_sales_acアプリケーション・コンテナのアプリケーションがsaas_sales_appという名前で、バージョンが1.0であり、データリンクされたusa_zipcodes表を含むとします。この場合、行はアプリケーション・ルート内の表に1回のみ格納されますが、すべてのアプリケーションPDBで表示されます。

メタデータリンク共通オブジェクトの場合、アプリケーションPDBはメタデータのみを共有しますが、異なるデータのセットが含まれます。たとえば、メタデータリンクされたproducts表はあらゆるアプリケーションPDBで同じ定義を持ちますが、行自体はPDBに固有です。cust1pdbというアプリケーションPDBには書籍を格納するproducts表があり、cust2pdbというアプリケーションPDBには自動車部品を格納するproducts表がある場合があります。

関連項目:

共通オブジェクトについて学習するには、共通オブジェクトおよびローカル・オブジェクトを参照してください

CDBの共通性について

CDBまたはアプリケーション・ルートで定義された共通現象は、このルートに接続されたすべてのコンテナで同じになります。

共通性の原則

CDBでは、ある現象はシステム・コンテナ(CDB自体)内または特定のアプリケーション・コンテナ内のいずれにも共通します。

たとえば、CDB$ROOTへの接続中に共通ユーザー・アカウントを作成した場合、このユーザー・アカウントはCDB内のすべてのPDBおよびアプリケーション・ルートにも共通です。しかし、アプリケーション・ルートへの接続中にアプリケーション共通ユーザー・アカウントを作成した場合、このユーザー・アカウントはこのアプリケーション・コンテナ内のPDBのみに共通です。

CDB$ROOTまたはアプリケーション・ルートのコンテキストにおける共通性の原則は、次のとおりです。

  • 共通現象は、既存および将来のすべてのコンテナで同じになります。

    したがって、CDBルートで定義された共通ユーザーはCDBルートに接続しているすべてのPDBで同じIDを持ち、アプリケーション・ルートで定義された共通ユーザーはこのアプリケーション・ルートに接続しているすべてのアプリケーションPDBで同じIDを持ちます。一方、ローカル現象は、厳密に既存の1つのコンテナをスコープとしています。

  • 共通ユーザーのみが共通現象の存在を変更できます。

    もっと正確に言えば、CDBルートまたはアプリケーション・ルートのいずれかにログインした共通ユーザーのみが、現在のコンテナに共通のユーザー、ロールまたはオブジェクトの属性を作成、無効化または変更できます。

CDBのネームスペース

CDBでは、すべてのオブジェクトのネームスペースはそのオブジェクトのコンテナをスコープとしています。

次の原則は、スコープ指定のルールをまとめたものです。

  • アプリケーションの観点では、PDBは他のPDBとは異なる個別のデータベースです。

  • ローカル現象は、1つのコンテナの内部で作成され、1つのコンテナに制限されます。

    ノート:

    このトピックでは、「現象」という用語は「ユーザー・アカウント、ロールまたはデータベース・オブジェクト」を意味します。

  • 共通現象は、CDBルートまたはアプリケーション・ルートで定義され、このルートに接続されている(または今後接続される)すべてのPDBに存在します。

前述の原則は、ローカル現象および共通現象に影響します。

ローカル現象

ローカル現象は、コンテナの内部で一意の名前を付ける必要がありますが、CDBのコンテナ全体ではその必要はありません。異なるコンテナに含まれる同じ名前を持つローカル現象は、別個のものです。たとえば、あるPDBのローカル・ユーザーshは、別のPDBのローカル・ユーザーshと競合しません。

CDB$ROOTの共通現象

CDB$ROOTで定義された共通現象は、複数のコンテナに存在し、それらのネームスペースのそれぞれで一意である必要があります。たとえば、CDBルートにはSYSTEMSYSなどの事前定義された共通ユーザーが含まれています。Oracle Databaseでは、ネームスペースを確実に分離するため、別のコンテナ内でSYSTEMユーザーを作成できません。

ネームスペースを確実に分離するため、CDBルートでユーザーが作成する共通現象の名前は、COMMON_USER_PREFIX初期化パラメータによって指定された値で始まる必要があります。デフォルトの接頭辞はc##またはC##です。ユーザーが作成する他の現象にc##およびC##で始まる名前を付けることはできません。たとえば、hrpdbc##hrという名前のローカル・ユーザーを作成したり、CDBルートでhrという名前の共通ユーザーを作成することはできません。

アプリケーション共通現象

アプリケーション・コンテナ内で、ローカルおよびアプリケーション共通の現象の名前が競合することはできません。

  • アプリケーション共通ユーザーおよびロール

    CDB共通ユーザーに対する同じ原則がアプリケーション共通ユーザーにも適用されます。違いは、CDB共通ユーザーの場合、共通ユーザー接頭辞のデフォルト値はc##またはC##であるのに対し、アプリケーション・ルートでは、共通ユーザー接頭辞のデフォルト値は空の文字列であることです。

    マルチテナント・アーキテクチャでは、アプリケーション・ルートからアプリケーションPDBを作成するか、シングルテナント・アプリケーションをマルチテナント・アプリケーションに変換することが想定されています。

  • アプリケーション共通オブジェクト

    マルチテナント・アーキテクチャでは、アプリケーション・ルートでアプリケーション共通オブジェクトを作成することが想定されています。その後、アプリケーションPDBの内部でローカルにデータを追加します。ただし、Oracle DatabaseではアプリケーションPDB内でのローカル・テーブルの作成がサポートされています。この場合、ローカル表はアプリケーションPDB内のアプリケーション共通オブジェクトと同じネームスペースに存在します。

関連項目:

共通ユーザーおよびロールについてさらに学習するには、Oracle Databaseセキュリティ・ガイドを参照してください

アプリケーション共通オブジェクトの作成

共通オブジェクトを作成するには、アプリケーション・ルートに接続してから、共有属性を指定するCREATE文を実行します。

アプリケーション共通オブジェクトを作成または変更できるのは、アプリケーションのインストール、アップグレードまたはパッチ適用の一環である場合のみです。共有は次の方法で指定できます。

  • DEFAULT_SHARING初期化パラメータ

    設定は、ルートで作成されたサポート対象タイプのすべてのデータベース・オブジェクトに対するデフォルト共有属性です。

  • SHARING

    この句は、CREATE文自体で指定します。SHARING句がSQL文に含まれる場合、これはDEFAULT_SHARING初期化パラメータで指定された値よりも優先されます。指定できる値は、METADATADATAEXTENDED DATAおよびNONEです。

次の表は、アプリケーション共通オブジェクトのタイプと、データおよびメタデータの格納場所を示しています。

表3-1 アプリケーション共通オブジェクト

オブジェクト・タイプ SHARING値 メタデータ記憶域 データ記憶域
データリンク DATA アプリケーション・ルート アプリケーション・ルート
拡張データリンク EXTENDED DATA アプリケーション・ルート アプリケーション・ルートおよびアプリケーションPDB
メタデータリンク METADATA アプリケーション・ルート アプリケーションPDB

関連項目:

共通オブジェクトの権限を管理する方法を学習するには、Oracle Databaseセキュリティ・ガイドを参照してください

メタデータリンク・アプリケーション共通オブジェクト

メタデータ・リンクは、アプリケーション・コンテナ内のすべてのPDBによって共有される共通メタデータの参照および権限付与をサポートするディクショナリ・オブジェクトです。

METADATA値をSHARING句またはDEFAULT_SHARING初期化パラメータのいずれかで指定すると、メタデータリンク共通オブジェクトと呼ばれるオブジェクトのメタデータへのリンクが指定されます。オブジェクトのメタデータは、アプリケーション・ルートに1回のみ格納されます。

表、ビュー、およびコード・オブジェクト(PL/SQLプロシージャなど)はメタデータを共有できます。このコンテキストでの「メタデータ」には、列定義、制約、トリガーおよびコードが含まれています。たとえば、sales_mltがメタデータリンクされた共通表の場合、すべてのアプリケーションPDBがメタデータ・リンクによってこの表の同じ定義(これはアプリケーション・ルートに格納されています)にアクセスします。sales_mltの行はすべてのアプリケーションPDBで異なりますが、列定義は同じです。

一般に、アプリケーションのほとんどのオブジェクトはメタデータリンクされます。したがって、1つのマスター・アプリケーション定義を保持するのみで済みます。この方法により、複数のアプリケーションPDB内のアプリケーションの管理が集中化されます。

例3-2 メタデータリンク共通オブジェクトの作成

この例では、SYSTEMユーザーがsaas_sales_acアプリケーション・コンテナにログインします。SYSTEMは、バージョン1.0.のsaas_sales_appという名前のアプリケーションをインストールします。このアプリケーションは、saas_sales_admという共通ユーザー・アカウントを作成します。スキーマには、sales_mltというメタデータリンクされた共通表が含まれています。

-- Begin the install of saas_sales_app
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN INSTALL '1.0';

-- Create the tablespace for the app
CREATE TABLESPACE saas_sales_tbs DATAFILE SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 200M;

-- Create the user account saas_sales_adm, which will own the app
CREATE USER saas_sales_adm IDENTIFIED BY ****** CONTAINER=ALL;

-- Grant necessary privileges to this user account
GRANT CREATE SESSION, DBA TO saas_sales_adm;

-- Makes the tablespace that you just created the default for saas_sales_adm
ALTER USER saas_sales_adm DEFAULT TABLESPACE saas_sales_tbs;

-- Now connect as the application owner
CONNECT saas_sales_adm/******@saas_sales_ac

-- Create a metadata-linked table
CREATE TABLE saas_sales_adm.sales_mlt SHARING=METADATA
(YEAR       NUMBER(4),
 REGION     VARCHAR2(10),
 QUARTER    VARCHAR2(4),
 REVENUE    NUMBER);

-- End the application installation
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END INSTALL '1.0';

ALTER PLUGGABLE DATABASE APPLICATION ... SYNC文を使用して、同じマスター・アプリケーション定義を使用するようにアプリケーションPDBを同期化できます。このように、あらゆるアプリケーションPDBがsaas_sales_adm.sales_mlt共通表へのメタデータ・リンクを持ちます。cust1_pdbというPDB内でsales_mltを更新する中間層コードはcust1_pdbでこの表に行を追加し、cust2_pdbsales_mltを更新する中間層コードはcust2_pdbでこの表のコピーに行を追加します。アプリケーション・ルートに格納される表メタデータのみが共有されます。

ノート:

共通に付与されるオブジェクト権限の使用方法についてさらに学習するには、Oracle Databaseセキュリティ・ガイドを参照してください

メタデータ・リンク

メタデータリンク・アプリケーション共通オブジェクトの場合、オブジェクトのメタデータはアプリケーション・ルートに1回格納されます。メタデータ・リンクは、共有しているメタデータと同じオブジェクト・タイプのディクショナリ・オブジェクトです。

メタデータ・リンクの説明は、それが作成されたPDBのデータ・ディクショナリに格納されます。メタデータ・リンクは、アプリケーション共通ユーザーによって所有されている必要があります。CDBルートまたはアプリケーション・ルートで、その作成者によって所有される共通オブジェクトのメタデータを共有するには、メタデータ・リンクのみを使用できます。

データ・リンクと異なり、メタデータ・リンクは共通データのみに依存します。たとえば、アプリケーションでローカル表dow_close_ltおよびnasdaq_close_ltがアプリケーション・ルートに含まれる場合、共通ユーザーはこれらのオブジェクトへのメタデータ・リンクを作成できません。しかし、sales_mltというアプリケーション共通表はメタデータリンクできます。

権限を持つ共通ユーザーが表に列を追加するなどしてsales_mltのメタデータを変更した場合、この変更はメタデータ・リンクに伝播されます。アプリケーションPDBユーザーはメタデータ・リンクのメタデータを変更しない場合があります。たとえば、cust1_pdbというアプリケーションPDBを管理するDBAは、このPDBのみのsales_mltに列を追加できません。このようなメタデータの変更はアプリケーション・ルートのみで行われるためです。

データリンク・アプリケーション共通オブジェクト

データリンク・オブジェクトは、そのメタデータおよびデータがアプリケーション・ルートに存在し、このアプリケーション・コンテナのすべてのアプリケーションPDBからアクセスできるオブジェクトです。

DATA値をSHARING句またはDEFAULT_SHARING初期化パラメータのいずれかで指定すると、データリンク共通オブジェクトと呼ばれる共通オブジェクトへのリンクが指定されます。データ・ウェアハウスのディメンション表はほとんどの場合、データリンク共通表の適切な候補です。

データ・リンクは、ほとんどシノニムのように機能するディクショナリ・オブジェクトです。たとえば、countriesがアプリケーション共通表の場合、すべてのアプリケーションPDBがデータ・リンクによってこの表の同じコピーにアクセスします。ある行がこの表に追加されると、この行はすべてのアプリケーションPDBで表示可能です。

データ・リンクは、アプリケーション共通ユーザーによって所有されている必要があります。リンクはそれが示しているオブジェクトからオブジェクト・タイプを継承します。データ・リンクの説明は、それが作成されたPDBのデータ・ディクショナリに格納されます。たとえば、アプリケーション・コンテナに10個のアプリケーションPDBが含まれ、すべてのPDBにcountriesアプリケーション共通表へのリンクが含まれる場合、10個のPDBすべてにこのリンクのディクショナリ定義が含まれます。

例3-3 データリンク・オブジェクトの作成

この例では、SYSTEMsaas_sales_acアプリケーション・コンテナに接続します。SYSTEMは、saas_sales_appという名前のアプリケーションをバージョン1.0から2.0にアップグレードします。このアプリケーション・アップグレードは、共通ユーザーsaas_sales_admとしてコンテナにログインし、countries_dltという名前のデータリンク表を作成して、その表に行を挿入します。

-- Begin an upgrade of the application
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN UPGRADE '1.0' to '2.0';

-- Connect as application owner to application root
CONNECT saas_sales_adm/manager@saas_sales_ac

-- Create data-linked table named countries_dlt
CREATE TABLE countries_dlt SHARING=DATA
(country_id   NUMBER,
 country_name VARCHAR2(20));

-- Insert records into countries_dlt
INSERT INTO countries_dlt VALUES(1, 'USA');
INSERT INTO countries_dlt VALUES(44, 'UK');
INSERT INTO countries_dlt VALUES(86, 'China');
INSERT INTO countries_dlt VALUES(91, 'India');

-- End application upgrade
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END UPGRADE TO '2.0';

ALTER PLUGGABLE DATABASE APPLICATION ... SYNC文を使用して、アプリケーションPDBをアプリケーション・ルートと同期化します。このようにして、同期化されたあらゆるアプリケーションPDBにsaas_sales_adm.countries_dltデータリンク表へのデータ・リンクが作成されます。

拡張データリンク・アプリケーション・オブジェクト

拡張データリンク・アプリケーション・オブジェクトは、データリンク・オブジェクトとメタデータリンク・オブジェクトを合成したものです。

拡張データリンク・オブジェクトでは、アプリケーション・ルートに格納されたデータはすべてのアプリケーションPDBに共通で、すべてのPDBがこのデータにアクセスできます。ただし、アプリケーション・ルートの共通データを共有すると同時に、各アプリケーションPDBは独自のPDB固有データを作成できます。このように、PDBはその固有データで共通データを補完します。

たとえば、販売アプリケーションでいくつかのアプリケーションPDBをサポートする場合があります。すべてのアプリケーションPDBで米国の郵便番号が必要です。この場合、アプリケーション・ルートでzipcodes_edt拡張データリンク表を作成できます。アプリケーション・ルートが米国の郵便番号を格納するため、すべてのアプリケーションPDBがこのデータにアクセスできます。ただし、1つのアプリケーションPDBでは米国およびカナダの郵便番号が必要です。このアプリケーションPDBは、カナダの郵便番号をアプリケーション・ルートではなくアプリケーションPDB内の拡張データリンク・オブジェクトに格納できます。

拡張データリンク・オブジェクトを作成するには、アプリケーション・ルートに接続して、CREATE文にSHARING=EXTENDED DATAキーワードを指定します。

例3-4 拡張データ・オブジェクトの作成

この例では、SYSTEMsaas_sales_acアプリケーション・コンテナに接続し、(例3-2で作成した) saas_sales_appという名前のアプリケーションをバージョン2.0から3.0にアップグレードします。このアプリケーションは、共通ユーザーsaas_sales_admとしてコンテナにログインし、zipcodes_edtという名前の拡張データリンク表を作成して、その表に行を挿入します。

-- Begin an upgrade of the app
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN UPGRADE '2.0' to '3.0';

-- Connect as app owner to app root
CONNECT saas_sales_adm/manager@saas_sales_ac

-- Create a common-data table named zipcodes_edt
CREATE TABLE zipcodes_edt SHARING=EXTENDED DATA
(code       VARCHAR2(5),
 country_id NUMBER,
 region     VARCHAR2(10));

-- Load rows into zipcodes_edt
INSERT INTO zipcodes_edt VALUES ('08820','1','East');
INSERT INTO zipcodes_edt VALUES ('10005','1','East');
INSERT INTO zipcodes_edt VALUES ('44332','1','North');
INSERT INTO zipcodes_edt VALUES ('94065','1','West');
INSERT INTO zipcodes_edt VALUES ('73301','1','South');
COMMIT;

-- End app upgrade
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END UPGRADE TO '3.0';

ALTER PLUGGABLE DATABASE APPLICATION ... SYNC文を使用して、アプリケーションPDBをアプリケーションと同期化します。このようにして、同期化されたあらゆるアプリケーションPDBにsaas_sales_adm.zipcodes_edtデータリンク表へのデータ・リンクが作成されます。これらのPDBに接続するアプリケーションは、アプリケーションのアップグレード中にzipcodes_edtに挿入された郵便番号を参照できますが、この表に独自の郵便番号を挿入することもできます。

コンテナ・マップ

コンテナ・マップを使用することにより、アプリケーション・ルートに接続したセッションで発行したSQL文が、SQL文に使用された条件の値に応じて適切なPDBにルーティングされるようになります。

マップ表はメタデータリンクされた共通表内の列を指定し、パーティションを使用して異なるアプリケーションPDBを異なる列値と関連付けます。このように、データが表レベルで物理的にパーティション化されていないときに、コンテナ・マップはPDBレベルでのデータのパーティション化を有効にします。

コンテナ・マップを使用するための主なコンポーネントは次のとおりです。

  • メタデータリンク表

    この表はコンテナ・マップを使用して問合せするためのものです。たとえば、各アプリケーションPDBに異なるデータを格納する、countries_mltというメタデータリンク表を作成する場合があります。amer_pdb内のcountries_mlt.cname列には北アメリカの国名が格納され、euro_pdb内のcountries_mlt.cname列にはヨーロッパの国名が格納され、asia_pdb内のcountries_mlt.cname列にはアジアの国名が格納されます。

  • マップ表

    アプリケーション・ルートで、リスト、ハッシュまたはレンジ別にパーティション化された単一列のマップ表を作成します。マップ表によって、コンテナ・マップで有効化されているパーティション化計画を使用して、メタデータリンク表が問合せできるようになります。マップ・オブジェクト表内のパーティションの名前は、アプリケーション・コンテナ内のアプリケーションPDBの名前と一致する必要があります。

    たとえば、pdb_map_tblというマップ表がcname列でリスト別にパーティション化します。amer_pdbeuro_pdbおよびasia_pdbというパーティションがアプリケーションPDBの名前に対応します。各パーティションの値は、たとえばPARTITION amer_pdb VALUES ('US','MEXICO','CANADA')のように、国の名前です。

    Oracle Database 18c以降は、CONTAINERS()問合せでマップを使用するために、マップ表のパーティション化列がメタデータリンク表の列と一致している必要はありません。表sh.salesがコンテナ・マップpdb_map_tblに対して有効で、cnameがマップ表のパーティション化列であるとします。sh.salescname列が含まれていない場合でも、マップ表は次の問合せを適切なPDBにルーティングします: SELECT * FROM CONTAINERS(sh.sales) WHERE cname = 'US' ORDER BY time_id

  • コンテナ・マップ

    コンテナ・マップは、マップ表を指定するデータベース・プロパティです。プロパティを設定するには、アプリケーション・ルートに接続してALTER PLUGGABLE DATABASE SET CONTAINER_MAP=map_table文を実行します。map_tableはマップ表の名前を表します。

例3-5 メタデータリンク表、マップ表およびコンテナ・マップの作成: パート1

この例では、アプリケーション管理者としてアプリケーション・ルートにログインします。アプリケーション・コンテナに、amer_pdbeuro_pdbおよびasia_pdbという3つのアプリケーションPDBがあると想定します。各アプリケーションPDBは異なる地域の国名を格納します。oe.countries_mltというメタデータリンク表に、国名が格納されるcname列があります。このパーティション化計画のため、リスト別のパーティションを使用して、各地域のパーティションを作成するsalesadm.pdb_map_tblと言う名前のマップ・オブジェクトを作成します。国名によって地域が決まります。

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN INSTALL '1.0';

-- Create the metadata-linked table.
CREATE TABLE oe.countries_mlt SHARING=METADATA (
  region    VARCHAR2(30),
  cname     VARCHAR2(30));

-- Create the partitioned map table, which is list partitioned on the
-- cname column. The names of the partitions are the names of the 
-- application PDBs.
CREATE TABLE salesadm.pdb_map_tbl (cname VARCHAR2(30) NOT NULL)
  PARTITION BY LIST (cname) (
    PARTITION amer_pdb VALUES ('US','MEXICO','CANADA'),
    PARTITION euro_pdb VALUES ('UK','FRANCE','GERMANY'),
    PARTITION asia_pdb VALUES ('INDIA','CHINA','JAPAN'));

-- Set the CONTAINER_MAP database property to the map object.
ALTER PLUGGABLE DATABASE SET CONTAINER_MAP='salesadm.pdb_map_tbl';

-- Enable the container map for the metadata-linked table to be queried.
ALTER TABLE oe.countries_mlt ENABLE CONTAINER_MAP;

-- Ensure that the table to be queried is enabled for the 
-- CONTAINERS clause.
ALTER TABLE oe.countries_mlt ENABLE CONTAINERS_DEFAULT;

-- End the application installation.
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END INSTALL '1.0';

ノート:

パーティション化構文を使用してコンテナ・マップを作成しても、データベースではパーティション化機能を使用しません。コンテナ・マップの定義にOracleパーティション化は必要ありません。

前述のスクリプトでは、ALTER TABLE oe.countries_mlt ENABLE CONTAINERS_DEFAULT文によって、アプリケーション・ルートで発行される問合せおよびDML文がデータベース・オブジェクトに対してデフォルトでCONTAINERS()句を使用する必要があることを指定します。

例3-6 アプリケーションの同期化と、データの追加: パート2

この例は前の例からの続きです。アプリケーション・ルートへの接続中に、現在のコンテナを各PDBに順番に切り替えて、saas_sales_appアプリケーションを同期化し、PDB固有データをoe.countries_mlt表に追加します。

ALTER SESSION SET CONTAINER=amer_pdb;
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
INSERT INTO oe.countries_mlt VALUES ('AMER','US');
INSERT INTO oe.countries_mlt VALUES ('AMER','MEXICO');
INSERT INTO oe.countries_mlt VALUES ('AMER','CANADA');
COMMIT;

ALTER SESSION SET CONTAINER=euro_pdb;
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
INSERT INTO oe.countries_mlt VALUES ('EURO','UK');
INSERT INTO oe.countries_mlt VALUES ('EURO','FRANCE');
INSERT INTO oe.countries_mlt VALUES ('EURO','GERMANY');
COMMIT;

ALTER SESSION SET CONTAINER=asia_pdb;
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
INSERT INTO oe.countries_mlt VALUES ('ASIA','INDIA');
INSERT INTO oe.countries_mlt VALUES ('ASIA','CHINA');
INSERT INTO oe.countries_mlt VALUES ('ASIA','JAPAN');
COMMIT;

例3-7 メタデータリンク表の問合せ: パート3

この例は前の例からの続きです。アプリケーション・ルートへ接続して、WHERE句で別の国を指定しながらoe.countries_mltを複数回、問合せします。問合せではoe.countries_mlt.region列から正しい値が返されます。

ALTER SESSION SET CONTAINER=saas_sales_ac;

SELECT region FROM oe.countries_mlt WHERE cname='MEXICO';

REGION
------
AMER

SELECT region FROM oe.countries_mlt WHERE cname='GERMANY';

REGION
------
EURO

SELECT region FROM oe.countries_mlt WHERE cname='JAPAN';

REGION
------
ASIA

コンテナ間操作

コンテナ間操作は、1回で複数のコンテナに影響を及ぼすDDL文またはDML文です。

CDBルートまたはアプリケーション・ルートのいずれかに接続されている共通ユーザーのみが、コンテナ間操作を実行できます。コンテナ間操作は次の対象に影響を及ぼします。

  • CDB自体

  • CDB内の複数のコンテナ

  • 複数のコンテナで表される共通ユーザーや共通ロールなどの複数の現象

  • DDL文またはDML文を発行しているユーザーが現在接続されていないコンテナ

コンテナ間DDL操作の例として、ユーザーSYSTEMが別の共通ユーザーに共通に権限を付与したり、ALTER DATABASE . . . RECOVER文をCDB全体に適用します。

CDBルートまたはアプリケーション・ルートのいずれかに接続しているユーザーは、1つのDML文を実行することでコンテナ内の複数のPDBで表またはビューを変更できます。データベースでは、DML文で指定されたCON_ID列の値からターゲットPDBが推測されます。CON_IDが指定されていない場合、データベースではALTER PLUGGABLE DATABASE CONTAINERS DEFAULT TARGET文で指定されたCONTAINERS_DEFAULT_TARGETプロパティが使用されます。

例3-8 1つのDML文における複数のPDBの更新

この例での目的は、sh.sales表でcountry_name列を値USAに設定することです。この表はコンテナID 7および8の2つの別個のPDBに存在します。両方のPDBがsaas_sales_acというアプリケーション・コンテナにあります。管理者としてアプリケーション・ルートに接続し、次のように更新できます。

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

UPDATE CONTAINERS(sh.sales) sal 
  SET sal.country_name = 'USA' 
  WHERE sal.CON_ID IN (7,8);

前述のUPDATE文で、salCONTAINERS(sh.sales)の別名です。