1. 管理者ガイド
  2. マルチテナント・アーキテクチャ
  3. マルチテナント・アーキテクチャの概要

2 マルチテナント・アーキテクチャの概要

この章では、マルチテナント・アーキテクチャの最も重要なコンポーネントについて説明します。

この部の内容は次のとおりです。

  • CDBのコンテナの概要
    コンテナは、マルチテナント・コンテナ・データベース(CDB)内のスキーマ、オブジェクトおよび関連構造の集合です。CDB内では、各コンテナは一意のIDと名前を持ちます。
  • CDBの共通性の概要
    CDBでは、すべてのユーザー、ロールまたはオブジェクトが共通またはローカルのいずれかになります。同様に、特権は共通に付与されるか、ローカルに付与されるかのいずれかです。
  • アプリケーション・コンテナ内のアプリケーションの概要
    アプリケーション・コンテナ内で、アプリケーションはアプリケーション・ルートに格納される共通データおよびメタデータの名前付けおよびバージョニングされたセットです。
  • CDBのサービスの概要
    クライアントは、サービスを使用してPDBまたはアプリケーション・ルートに接続する必要があります。
  • CDBの表領域およびデータベース・ファイルの概要
    CDBの構造は非CDBと同じですが、各PDBおよびアプリケーション・ルートに独自の表領域のセット(独自のSYSTEM、SYSAUXおよびUNDO表領域を含む)がある点が異なります。
  • CDBの可用性の概要
    非CDBについて存在する可用性機能の多くは、CDB内の個々のPDBについても存在します。
  • CDBでのOracle Resource Managerの概要
    Oracle Resource Manager (Resource Manager)を使用して、CDBリソース・プランを作成し、PDBにリソースを割り当てるための初期化パラメータを設定できます。

親トピック: マルチテナント・アーキテクチャ

CDBのコンテナの概要

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

この項では、次の項目について説明します。

  • CDBルートとシステム・コンテナ
    CDBルート(単純にルートとも呼ばれている)は、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合で、すべてのPDBはこれに属します。
  • PDB
    PDBは、ユーザーが作成したスキーマ、オブジェクトおよび関連構造体のセットで、論理的にクライアント・アプリケーションでは個別のデータベースとして表示されます。
  • CDBのデータ・ディクショナリ・アーキテクチャ
    ユーザーおよびアプリケーションから見て、CDBの各コンテナのデータ・ディクショナリは、非CDBの場合と同様に分かれています。
  • 現在のコンテナ
    指定されたセッションで、現在のコンテナは、セッションが実行されているコンテナです。現在のコンテナはCDBルート、アプリケーション・ルートまたはPDBになります。
  • コンテナ間操作
    コンテナ間操作は、1回で複数のコンテナに影響を及ぼすDDL文またはDML文です。

親トピック: マルチテナント・アーキテクチャの概要

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

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

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

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

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

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

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

SQL> COL NAME FORMAT A15
SQL> 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

関連項目:

親トピック: CDBのコンテナの概要

PDB

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

あらゆるPDBは、PDBを作成したユーザーに関係なくSYSによって所有されます。CDBでは、SYSは共通ユーザーです。

この項では、次の項目について説明します。

  • PDBのタイプ
    すべてのPDBは、Oracle提供のPDB$SEEDを除いて、CREATE PLUGGABLE DATABASE文でユーザー作成されます。
  • PDBの目的
    アプリケーションの観点からすると、PDBは全機能を備えた自己完結型のOracle Databaseです。PDBを1つのCDBに統合することで、PDBの分離を維持しながら規模の経済性が得られます。
  • プロキシPDB
    プロキシPDBは、参照先PDBと呼ばれるリモートPDBを参照します。
  • PDBの名前
    CDB内のコンテナは同じネームスペースを共有します。つまり、このネームスペース内では一意の名前を保持する必要があります。
  • PDB間のデータベース・リンク
    デフォルトで、あるPDBに接続しているユーザーが、別のPDBのオブジェクトにアクセスするには、データベース・リンクを使用する必要があります。この動作は、まさに別の非CDBのオブジェクトにアクセスする非CDBのユーザーに似ています。

親トピック: CDBのコンテナの概要

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は、そのアプリケーション共通オブジェクトにアクセスできません。

リフレッシュ可能クローンPDBは、ソースPDBから増分変更を取得できる、ソースPDBの読取り専用クローンです。自動的に、または手動でのみ変更を取得するようにクローンPDBを構成できます。

スナップショット・コピーPDBは記憶域レベルのスナップショットを使用して作成されます。標準の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

PDBの目的

アプリケーションの観点からすると、PDBは全機能を備えた自己完結型のOracle Databaseです。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を参照します。

プロキシ(参照元)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-2 プロキシ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の作成」

親トピック: PDB

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にわたって一意にする必要があります。ユーザー作成のコンテナ名は最初の文字を英数字にし、それ以降の文字を英数字またはアンダースコア(_)にする必要があります。サービス名には大文字小文字の区別がないため、コンテナ名にも大文字と小文字の区別はなく、区切り識別子を使用して指定しても、大文字になります。

関連項目:

親トピック: PDB

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

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

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

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

図2-1の説明が続きます
「図2-1 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ルートのいずれかに接続する必要があります。

関連項目:

親トピック: PDB

CDBのデータ・ディクショナリ・アーキテクチャ

ユーザーおよびアプリケーションから見て、CDBの各コンテナのデータ・ディクショナリは、非CDBの場合と同様に分かれています。

たとえば、各PDBのDBA_OBJECTSビューでは、異なる行数を表示できます。このようにディクショナリを分けることで、Oracle DatabaseではPDBを、お互いから別々に、そしてルートから管理できます。

この項では、次の項目について説明します。

親トピック: CDBのコンテナの概要

データ・ディクショナリ分割の目的

まだユーザー・データが含まれていない新規に作成された非CDBでは、データ・ディクショナリにはシステム・メタデータのみが含まれています。たとえば、TAB$表には、Oracle提供の表(TRIGGER$およびSERVICE$など)のみを説明する行が含まれます。

次の図は、3つの基礎的なデータ・ディクショナリ表で、赤い棒はシステムを説明する行を示しています。

図2-2 非CDBの非混合データ・ディクショナリ・メタデータ

図2-2の説明が続きます
「図2-2 非CDBの非混合データ・ディクショナリ・メタデータ」の説明

ユーザーがこの非CDBに自身のスキーマおよび表を作成する場合、データ・ディクショナリにはOracle提供のエンティティを説明する行と、ユーザー作成エンティティを説明するその他の行が含まれます。たとえば、TAB$ディクショナリ表には、employeesを説明する行とdepartmentsを説明する行があります。

図2-3 非CDBの混合データ・ディクショナリ・メタデータ

図2-3の説明が続きます
「図2-3 非CDBの混合データ・ディクショナリ・メタデータ」の説明

CDBでは、データ・ディクショナリ・メタデータは、ルートとPDBの間で分割されています。次の図では、employees表とdepartments表がPDB内に存在します。このユーザー・データのデータ・ディクショナリも、PDBに常駐します。したがって、PDBのTAB$表には、employees表の行とdepartments表の行があります。

図2-4 CDBのデータ・ディクショナリ・アーキテクチャ

図2-4の説明が続きます
「図2-4 CDBのデータ・ディクショナリ・アーキテクチャ」の説明

前図は、PDBのデータ・ディクショナリには、ルートにあるデータ・ディクショナリに対するポインタが含まれていることを示しています。内部では、データ・ディクショナリ表の定義やPL/SQLパッケージなど、Oracle提要オブジェクトは、ルートでのみ表されます。このアーキテクチャは、CDBで2つの主な目的を達成します。

  • 重複の減少

    たとえば、すべてのPDBにDBMS_ADVISOR PL/SQLパッケージのソース・コードを格納するかわりに、CDBではそれがCDB$ROOTにのみ格納され、ディスク領域が節約されます。

  • データベースのアップグレードの容易さ

    データ・ディクショナリ表の定義がすべてのPDBに存在し、その定義が新リリースで変わる場合、その変更を反映するには、各PDBを別々にアップグレードする必要があります。表定義をルートに1回格納すれば、この問題はなくなります。

メタデータ・リンクとデータ・リンク

CDBは、内部リンク・メカニズムを使用して、データ・ディクショナリ情報を分けます。

具体的には、Oracle Databaseでは、自動的に管理される次のポインタを使用します。

  • メタデータ・リンク

    Oracle Databaseでは、ディクショナリ・オブジェクトのメタデータは、CDBルート内にしか格納されません。たとえば、DBA_OBJECTSデータ・ディクショナリ・ビューの基礎であるOBJ$ディクショナリ表の列定義は、ルートにしか存在しません。図2-4に示すように、各PDB内のOBJ$表はメタデータ・リンクと呼ばれる内部メカニズムを使用して、ルートに格納されているOBJ$の定義を指し示します。

    メタデータ・リンクに対応するデータは、ルートではなく、そのPDBに常駐します。たとえば、hrpdbに表mytableを作成し、これに行を追加する場合、その行はPDBデータ・ファイルに格納されます。PDBおよびルートのデータ・ディクショナリ・ビューには、異なる行が含まれます。たとえば、mytableを説明する新しい行は、hrpdbのOBJ$表に存在し、CDBルートのOBJ$表には存在しません。したがって、CDBルートのDBA_OBJECTSの問合せと、hrdpbのDBA_OBJECTSでは、異なる結果が表示されます。

  • データ・リンク

    ノート:

    データ・リンクはOracle Database 12cリリース1 (12.1.0.2)でオブジェクト・リンクと呼ばれていました。

    場合によっては、Oracle Databaseで(メタデータのみではなく)オブジェクトのデータがアプリケーション・ルートに1回しか格納されません。アプリケーションPDBでは、データ・リンクと呼ばれる内部メカニズムを使用してアプリケーション・ルートのオブジェクトが参照されます。データ・リンクが作成されたアプリケーションPDBには、データ・リンクの説明も格納されます。データ・リンクは、参照先のオブジェクトのデータ型を継承します。

  • 拡張データ・リンク

    拡張データ・リンクは、データ・リンクとメタデータ・リンクを合成したものです。データ・リンクと同じように、拡張データ・リンクはアプリケーション・ルートのオブジェクトを参照します。しかし、拡張データ・リンクはアプリケーションPDBの対応するオブジェクトも参照します。メタデータ・リンクと同じように、アプリケーションPDBのオブジェクトはアプリケーション・ルートの対応するオブジェクトからメタデータを継承します。

    アプリケーション・ルートで問合せを実行すると、拡張データリンク・オブジェクトはアプリケーション・ルートからのみ行をフェッチします。しかし、アプリケーションPDBで問合せを実行すると、拡張データリンク・オブジェクトはアプリケーション・ルートとアプリケーションPDBの両方から行をフェッチします。

Oracle Databaseでは、CDB$ROOTに対するメタデータ・リンクとデータ・リンクが自動的に作成および管理されます。ユーザーは、これらのリンクを追加、変更または削除できません。

関連項目:

親トピック: CDBのデータ・ディクショナリ・アーキテクチャ

CDBのコンテナ・データ・オブジェクト

コンテナ・データ・オブジェクトは、複数のコンテナまたはCDB全体に関連するデータを含む表またはビューです。

コンテナ・データの権限は、複数のPDBが1つのCDBに存在する一般的な要件をサポートしますが、異なるローカル管理の要件があります。たとえば、ローカル管理を行わないアプリケーションDBAは、適切なビューに対するコンテナ・データの権限を共有ユーザーに付与できます。この場合、CDB管理者はこれらのPDBのデータにアクセスできます。これに対して、CDB管理者がデータにアクセスしないようにする必要があるPDB管理者は、コンテナ・データの権限を付与しません。

名前がV$およびCDB_で始まるOracle提供ビューは、コンテナ・データベース・オブジェクトの例です。すべてのコンテナ・データベース・オブジェクトには、CON_ID列があります。次の表に、この列の値の意味を示します。

表2-1 コンテナID値

コンテナID 関連行

0

CDB全体、または非CDB

1

CDB$ROOT

2

PDB$SEED

その他すべてのID

ユーザー作成のPDB、アプリケーション・ルートまたはアプリケーション・シード

CDBでは、各DBA_ビューに、対応するCDB_ビューが存在します。CDB_ビューの所有者は、対応するDBA_ビューの所有者です。次の図は、異なるカテゴリのディクショナリ・ビューの間の関係を示しています。

図2-5 CDBのディクショナリ・ビュー

図2-5の説明が続きます
「図2-5 CDBのディクショナリ・ビュー」の説明

現在のコンテナがPDBである場合、ユーザーは現在のPDBのデータ・ディクショナリ情報のみを表示できます。PDBに接続されているアプリケーションには、データ・ディクショナリが非CDBの場合と同様に表示されます。ただし、現在のコンテナがルートである場合、共通ユーザーは、ルートとこのユーザーが権限を持つPDBのメタデータを確認するために、CDB_ビューに問い合せることができます。

ノート:

ルート・コンテナから問合せされる際、CDB_ビューおよびV$ビューはデータをAL32UTF8文字セットに暗黙的に変換します。AL32UTF8に変換される際に文字セットで文字を表すためにバイト数がさらに必要な場合、そしてビューの列幅が特定のPDBのデータを収容できない場合、データの切捨てが可能です。

次の表に、CDB_ビューの問合せを含むシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。

表2-2 CDB_ビューの問合せ

操作 説明 
SQL> CONNECT SYSTEM
Enter password: ********
Connected.

SYSTEMユーザーは、CDBのすべてのコンテナに対して共通で、ルートに接続します(「CDBの共通ユーザー」を参照)。 

SQL> SELECT COUNT(*) FROM CDB_USERS 
WHERE CON_ID=1;

COUNT(*)
--------
      41

SYSTEMはCDB_USERSに対して、CDBの共通ユーザー数を取得するように問い合せます。出力は、41の共通ユーザーが存在することを示しています。 

SQL> SELECT COUNT(DISTINCT(CON_ID)) 
FROM CDB_USERS;
 
COUNT(DISTINCT(CON_ID))
-----------------------
                      4

SYSTEMはCDB_USERSに対して、CDBの個別のコンテナ数を確認するように問い合せます。 

SQL> CONNECT SYSTEM@hrdb
Enter password: ********
Connected.

SYSTEMユーザーは、今度はhrpdbというPDBに接続します。 

SQL> SELECT COUNT(*) FROM CDB_USERS;
 
  COUNT(*)
----------
        45

SYSTEMはCDB_USERSに対して問い合せます。出力は、45の共通ユーザーが存在することを示しています。SYSTEMはルートに接続していないため、CDB_USERSビューにはDBA_USERSと同じ出力が表示されます。DBA_USERSには現行コンテナ内のユーザーのみが表示されるため、45と表示されます。

関連項目:

コンテナ・データ・オブジェクトについてさらに学習するには、「ビュー内のCDBおよびコンテナの情報について」を参照してください

親トピック: CDBのデータ・ディクショナリ・アーキテクチャ

CDBのデータ・ディクショナリ・ストレージ

CDB全体のメタデータを格納するデータ・ディクショナリは、システム表領域にのみ格納されます。

特定のPDBのメタデータを格納するデータ・ディクショナリは、このPDB専用の自己完結型表領域に格納されます。PDB表領域には、アプリケーション・バックエンドのデータとメタデータの両方が格納されます。このため、データ・ディクショナリ表の各セットは、それぞれの専用の表領域のセットに格納されます。

関連項目:

親トピック: CDBのデータ・ディクショナリ・アーキテクチャ

現在のコンテナ

指定されたセッションで、現在のコンテナは、セッションが実行されているコンテナです。現在のコンテナはCDBルート、アプリケーション・ルートまたはPDBになります。

各セッションには、任意の時点で現在のコンテナがそれぞれ1つのみ含まれます。各コンテナのデータ・ディクショナリは個別のため、Oracle Databaseでは、名前の解決と権限の認証に、現在のコンテナのデータ・ディクショナリを使用します。

関連項目:

「現在のコンテナについて」

親トピック: CDBのコンテナの概要

コンテナ間操作

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

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

  • CDB自体

  • CDB内の複数のコンテナ

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

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

コンテナ間DDL操作の例として、ユーザーSYSTEMが別の共通ユーザーに共通に権限を付与したり(「CDBで共通に付与されるロールおよび権限」を参照)、ALTER DATABASE . . . RECOVER文をCDB全体に適用します。

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

例2-3 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文で、salはCONTAINERS(sh.sales)の別名です。

関連項目:

親トピック: CDBのコンテナの概要

CDBの共通性の概要

CDBでは、すべてのユーザー、ロールまたはオブジェクトが共通またはローカルのいずれかになります。同様に、特権は共通に付与されるか、ローカルに付与されるかのいずれかです。

この項では、次の項目について説明します。

  • CDBの共通性について
    ルートで定義された共通現象は、このルートに接続されたすべてのコンテナで同じになります。
  • CDBの共通ユーザーおよびローカル・ユーザーの概要
    ユーザー・アカウントがデータベースを定義するオブジェクトを所有する場合、このユーザー・アカウントは共通です。Oracle提供ではないユーザー・アカウントはローカルまたは共通のいずれかです。
  • CDBの共通ロールおよびローカル・ロールの概要
    ユーザー作成のロールは、ローカルまたは共通のいずれかです。共通ロールは、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。
  • CDBでの権限およびロール付与の概要
    非CDBと同様に、ロールと権限をCDB内のユーザーが付与することも、CDB内のユーザーに付与することもできます。ただし、CDB内のロールおよび権限は、ローカルに付与されたものか、共通に付与されたもののいずれかです。
  • CDBの共通オブジェクトおよびローカル・オブジェクトの概要
    共通オブジェクトは、CDBルートまたはアプリケーション・ルートのいずれかで定義されており、メタデータ・リンクまたはオブジェクト・リンクを使用して参照できます。ローカル・オブジェクトは、共通オブジェクトではないすべてのオブジェクトです。
  • 共通監査構成の概要
    混合モードと統合監査のどちらの場合も、共通監査構成が表示され、すべてのPDBにわたって適用されます。
  • PDBロックダウン・プロファイルの概要
    PDBロックダウン・プロファイルは、PDBに接続されたユーザーが使用できる操作を制限する一連の機能に名前を付けたものです。たとえば、PDBロックダウン・プロファイルによって、ALTER SYSTEM文に伴う権限を無効化できます。

親トピック: マルチテナント・アーキテクチャの概要

CDBの共通性について

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

この項では、次の項目について説明します。

  • 共通性の原則
    CDBでは、ある現象はシステム・コンテナ(CDB自体)内または特定のアプリケーション・コンテナ内のいずれにも共通します。
  • CDBのネームスペース
    CDBでは、すべてのオブジェクトのネームスペースはそのオブジェクトのコンテナをスコープとしています。

親トピック: CDBの共通性の概要

共通性の原則

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

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

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

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

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

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

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

親トピック: CDBの共通性について

CDBのネームスペース

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

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

  • アプリケーションの観点からすると、PDBは非CDBと区別できません。

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

    ノート:

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

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

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

ローカル現象

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

CDB$ROOTの共通現象

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

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

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

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

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

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

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

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

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

関連項目:

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

親トピック: CDBの共通性について

CDBの共通ユーザーおよびローカル・ユーザーの概要

ユーザー・アカウントがデータベースを定義するオブジェクトを所有する場合、このユーザー・アカウントは共通です。Oracle提供ではないユーザー・アカウントはローカルまたは共通のいずれかです。

CDB共通ユーザーは、CDBルートで作成される共通ユーザーです。アプリケーション共通ユーザーはアプリケーション・ルートで作成されるユーザーで、このアプリケーション・コンテナ内のみで共通です。

次の図は、CDBで使用可能なユーザー・アカウント・タイプを示しています。

図2-6 CDBのユーザー・アカウント

図2-6の説明が続きます
「図2-6 CDBのユーザー・アカウント」の説明

CDB共通ユーザーは、十分な権限を持つCDB内の任意のコンテナに接続できます。対照的に、アプリケーション共通ユーザーは(権限に応じて)そのユーザーが作成されたアプリケーション・ルートまたはこのアプリケーション・ルートに接続しているPDBのみに接続できます。

この項では、次の項目について説明します。

  • CDBの共通ユーザー
    システム・コンテナ(CDB)またはアプリケーション・コンテナのいずれかのコンテキスト内で、共通ユーザーは、ルートとこのコンテナ内の既存と将来のすべてのPDBにおいて同じIDを持つデータベース・ユーザーです。
  • CDBのローカル・ユーザー
    ローカル・ユーザーとは、共通ではなく、1つのPDBでのみ操作が可能なデータベース・ユーザーです。

関連項目:

共通ユーザーおよびローカル・ユーザーの概要は、Oracle Databaseセキュリティ・ガイドを参照してください

親トピック: CDBの共通性の概要

CDBの共通ユーザー

システム・コンテナ(CDB)またはアプリケーション・コンテナのいずれかのコンテキスト内で、共通ユーザーは、ルートとこのコンテナ内の既存と将来のすべてのPDBにおいて同じIDを持つデータベース・ユーザーです。

どの共通ユーザーも、そのコンテナのルートに接続し、ルート内および十分な権限を持つすべてのPDB内で操作を実行できます。一部の管理タスクは、共通ユーザーによって実行される必要があります。例として、PDBの作成やPDBの切断などがあります。

たとえば、SYSTEMはDBA権限を持つCDB共通ユーザーです。したがって、SYSTEMはCDBルートおよびデータベース内の任意のPDBに接続できます。saas_salesアプリケーション・コンテナでsaas_sales_admin共通ユーザーを作成する場合があります。この場合、saas_sales_adminユーザーが接続できるのはsaas_salesアプリケーション・ルートか、saas_salesアプリケーション・コンテナ内のアプリケーションPDBのみです。

すべての共通ユーザーは、Oracle提供またはユーザー作成のいずれかです。Oracle提供の共通ユーザーの例は、SYSやSYSTEMです。すべてのユーザー作成共通ユーザーは、CDB共通ユーザーまたはアプリケーション共通ユーザーのいずれかです。

図2-7に、2つのPDB(hrpdbとsalespdb)のユーザーとスキーマの例を示します。SYSとc##dbaは、CDB$ROOT、hrpdbおよびsalespdbにスキーマを持つCDB共通ユーザーです。ローカル・ユーザーhrとrepは、hrpdbに存在します。ローカル・ユーザーhrとrepは、salespdbにも存在します。

図2-7 CDBのユーザーとスキーマ

図2-7の説明が続きます
「図2-7 CDBのユーザーとスキーマ」の説明

共通ユーザーには、次の特徴があります。

  • 共通ユーザーは、CREATE SESSION権限を持つどのコンテナ(CDB$ROOTも含む)にもログインできます。

    共通ユーザーは、すべてのコンテナで同じ権限を持つ必要はありません。たとえば、c##dbaユーザーは、hrpdbおよびルートでセッション作成の権限を持っていて、salespdbではセッション作成の権限を持っていないという場合があります。適切な権限を持つ共通ユーザーはコンテナの切替えができるため、ルートの共通ユーザーはPDBを管理できます。

  • アプリケーション共通ユーザーには、その固有アプリケーション・コンテナ外のコンテナでのCREATE SESSION権限がありません。

    したがって、アプリケーション共通ユーザーはその固有のアプリケーション・コンテナに制限されます。たとえば、saas_salesアプリケーションで作成されたアプリケーション共通ユーザーは、saas_salesアプリケーション・コンテナ内のアプリケーション・ルートおよびPDBにのみ接続できます。

  • ユーザーが作成するCDB共通ユーザーの名前は、他のデータベース・ユーザーに対する命名規則に従う必要があります。また、COMMON_USER_PREFIX初期化パラメータによって指定された文字(デフォルトではc##またはC##)で始まる名前を付ける必要があります。Oracle提供の共通ユーザー名とユーザー作成のアプリケーション共通ユーザー名にはこの制限がありません。

    ローカル・ユーザー名でc##またはC##の文字で始まる名前はありません。

  • すべての共通ユーザーには、そのユーザーが作成されたコンテナ(システム・コンテナまたは特定のアプリケーション・コンテナのいずれか)内のすべてのPDBにおいて、一意の名前が付けられます。

    CDB共通ユーザーはCDBルートで定義されますが、同じIDを持つどのPDBにも接続できる必要があります。アプリケーション共通ユーザーはアプリケーション・ルートに常駐しますが、同じIDを持つそのコンテナのどのアプリケーションPDBにも接続できます。

関連項目:

親トピック: CDBの共通ユーザーおよびローカル・ユーザーの概要

CDBのローカル・ユーザー

ローカル・ユーザーとは、共通ではなく、1つのPDBでのみ操作が可能なデータベース・ユーザーです。

ローカル・ユーザーには、次の特徴があります。

  • ローカル・ユーザーは、PDBに固有であり、このPDB内でスキーマを所有できます。

    図2-7では、hrpdb上のローカル・ユーザーhrがhrスキーマを所有しています。salespdbでは、ローカル・ユーザーrepがrepスキーマを、ローカル・ユーザーhrがhrスキーマを所有しています。

  • ローカル・ユーザーは、オープンやクローズなどを含め、PDBを管理できます。

    SYSDBA権限を持つ共通ユーザーは、ローカル・ユーザーにSYSDBA権限を付与できます。この場合、権限を付与されたユーザーはローカルのままとなります。

  • あるPDBのローカル・ユーザーは、別のPDBまたはCDBルートにはログインできません。

    たとえば、ローカル・ユーザーhrがhrpdbに接続する場合、hrは、データベース・リンクを使用せずに、salespdbデータベースに常駐するshスキーマのオブジェクトにアクセスすることはできません。同様に、ローカル・ユーザーshがsalespdb PDBに接続する場合、shは、データベース・リンクを使用せずに、hrpdbに存在するhrスキーマのオブジェクトにアクセスすることはできません。

  • ローカル・ユーザーには、c##またはC##の文字で始まる名前を付けることはできません。

  • ローカル・ユーザーの名前は、PDB内でのみ一意である必要があります。

    ユーザー名とそのユーザーのスキーマが含まれているPDBにより、一意のローカル・ユーザーが決まります。図2-7では、repというローカル・ユーザーおよびスキーマがhrpdbに存在します。repという完全に独立したローカル・ユーザーとスキーマが、salespdb PDBに存在します。

次の表に、図2-7のCDBに関連したシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEMが、2つのPDBでローカル・ユーザーを作成します。

表2-3 CDBのローカル・ユーザー

操作 説明 
SQL> CONNECT SYSTEM@hrpdb
Enter password: ********
Connected.

SYSTEMが、サービス名hrpdbを使用してhrpdbコンテナに接続します。 

SQL> CREATE USER rep IDENTIFIED BY password; 

User created.

SQL> GRANT CREATE SESSION TO rep;

Grant succeeded.

SYSTEMは、ここでローカル・ユーザーrepを作成し、このユーザーにこのPDBでのCREATE SESSION権限を付与します。共通ユーザーを作成できるのはルートに接続された共通ユーザーのみであるため、このユーザーはローカルです。 

SQL> CONNECT rep@salespdb
Enter password: *******
ERROR:
ORA-01017: invalid username/password; logon denied

repユーザーは、hrpdbに対するローカル・ユーザーで、salespdbへの接続を試みます。repはPDB salespdbに存在しないため、この試みは失敗します。この動作は、非CDBの動作に似ています。ある非CDBのユーザー・アカウントは、別の非CDBのユーザー・アカウントとは無関係です。 

SQL> CONNECT SYSTEM@salespdb
Enter password: ********
Connected.

SYSTEMは、サービス名salespdbを使用してsalespdbコンテナに接続します。 

SQL> CREATE USER rep IDENTIFIED BY password; 

User created.

SQL> GRANT CREATE SESSION TO rep;

Grant succeeded.

SYSTEMは、salespdbでローカル・ユーザーrepを作成し、このユーザーにこのPDBでのCREATE SESSION権限を付与します。ローカル・ユーザー名はそのPDBでのみ一意である必要があるため、repというユーザーはsalespdbとhrpdbの両方に存在できます。 

SQL> CONNECT rep@salespdb
Enter password: *******
Connected.

repユーザーは、正常にsalespdbにログインします。

関連項目:

ローカル・ユーザー・アカウントについて学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBの共通ユーザーおよびローカル・ユーザーの概要

CDBの共通ロールおよびローカル・ロールの概要

ユーザー作成のロールは、ローカルまたは共通のいずれかです。共通ロールは、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。

Oracle提供ロールは、例として事前定義DBAロールのように、すべて共通です。Oracle提供のスクリプトでは、Oracle提供のユーザーおよびロールに付与されるすべての権限またはロールは共通に付与されますが、例外は、システム権限が共通ロールPUBLICに対してローカルに付与される場合です。

この項では、次の項目について説明します。

  • CDBの共通ロール
    共通ロールは、CDBルートまたはアプリケーション・ルートのいずれかに存在し、ルート・コンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のあらゆるPDBに適用されます。
  • CDBのローカル・ロール
    ローカル・ロールは、非CDBのロールが非CDBにのみ存在するのと同様に、単一のPDBにのみ存在します。

関連項目:

「CDBでのPUBLICへの付与」

親トピック: CDBの共通性の概要

CDBの共通ロール

共通ロールは、CDBルートまたはアプリケーション・ルートのいずれかに存在し、ルート・コンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のあらゆるPDBに適用されます。

共通ロールは、コンテナ間の操作に便利で、共通ユーザーがすべてのPDBでロールを持つことを保証します。すべての共通ユーザーは、次のいずれかのタイプになります。

  • Oracle提供

    DBAやPUBLICなどのOracle提供ロールはすべて、CDBに共通です。

  • ユーザー作成

    共通ロールを作成するには、CDBルートまたはアプリケーション・ルートのいずれか(これによって、ロールが共通となるコンテナが決まります)でCREATE ROLE ... CONTAINER=ALLを実行します。標準の命名規則が適用されます。また、CDB共通ロールには、COMMON_USER_PREFIX初期化パラメータによって指定された文字(デフォルトではc##またはC##)で始まる名前を付ける必要があります。

ロールのスコープは、そのロールが定義されているルートのスコープです。CDB$ROOTでロールを定義すると、そのスコープはCDB全体になります。アプリケーション・ルート内でロールを定義すると、そのスコープはアプリケーション・コンテナになります。

関連項目:

親トピック: CDBの共通ロールおよびローカル・ロールの概要

CDBのローカル・ロール

非CDBのロールが非CDBにのみ存在するのと同様に、ローカル・ロールは単一のPDBにのみ存在します。

ローカル・ロールには、そのロールが存在するコンテナで適用されるロールおよび権限のみを含めることができます。たとえば、hrpdbでローカル・ロールpdbadminを作成した場合、このロールのスコープはこのPDBに制限されます。

同じCDB、または同じアプリケーション・コンテナのPDBには、同じ名前のローカル・ロールが含まれる場合があります。たとえば、ユーザー作成のロールpdbadminは、hrpdbとsalespdbのどちらにも存在する可能性があります。しかし、これらのロールは、別々の非CDBにあるかのように、互いにまったく関係ありません。

関連項目:

ローカル・ロールの管理方法を学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBの共通ロールおよびローカル・ロールの概要

CDBでの権限およびロール付与の概要

非CDBと同様に、ロールと権限をCDB内のユーザーが付与することも、CDB内のユーザーに付与することもできます。ただし、CDB内のロールおよび権限は、ローカルに付与されたものか、共通に付与されたもののいずれかです。

ローカルに付与された権限またはロールは、それが付与されたPDBでのみ実行可能です。共通に付与された権限またはロールは、付与された対象のコンテナ(CDBまたはアプリケーション・コンテナ)の既存および将来のどのPDBにおいても実行可能です。

ユーザーおよびロールは、共通の場合もローカルの場合もあります。ただし、権限は、それ自体は共通でもローカルでもありません。ユーザーがCONTAINER=CURRENT句を使用してローカルに権限を付与した場合、権限受領者は現行コンテナ内でのみ実行可能な権限を持ちます。ユーザーがCDBルートまたはアプリケーション・ルートのいずれかに接続している場合、そしてこのユーザーがCONTAINER=ALL句を使用して共通に権限を付与した場合、権限受領者は現在のコンテナ内の既存または将来のPDBでこの権限を持ちます。

この項では、次の項目について説明します。

関連項目:

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

親トピック: CDBの共通性の概要

CDBにおける権限およびロールの付与の原則

CDBでは、付与の行為は、ローカルか共通かに関係なく、すべてコンテナの内部で起こります。コンテナはCDBルート、アプリケーション・ルートまたはPDBになります。

現在のコンテナがCDBルートの場合、共通に付与することはCDBのすべてのコンテナに付与することを意味します。しかし、現在のコンテナがアプリケーション・ルートの場合、共通に付与することは現在のアプリケーション・コンテナのすべてのPDBに付与することを意味します。

付与の基本原則は、次のとおりです。

  • 共通およびローカルのどちらの現象も、ローカルに付与および受領できます。

  • 共通に付与または受領できるのは、共通の現象のみです。

ローカルのユーザー、ロールおよび権限は、特定のPDBに制限されます。したがって、ローカル・ユーザーは、共通のロールおよび権限を付与することはできず、ローカルのロールおよび権限は共通に付与されることはありません。

次の各項では、前述の原則の意味を説明します。

CDBでローカルに付与される権限およびロール

ロールおよび権限は、受領者、付与者または付与されるロールがローカルか共通かに関係なく、ユーザーおよびロールにローカルに付与できます。

次の表に、ローカルに付与されたロールおよび権限の有効な可能性を示します。

表2-4 ローカルな付与

現象 ローカルな付与が可能 ローカルな受領が可能 ローカルに付与されたロールまたは権限の受領が可能

共通ユーザー

はい

該当なし

はい

ローカル・ユーザー

はい

該当なし

はい

共通ロール

該当なし

はい脚注1

はい

ローカル・ロール

該当なし

はい脚注2

はい

権限

該当なし

はい

該当なし

脚注1

このロールでの権限は、権限がロールにローカルに付与されたか共通に付与されたかに関係なく、被付与者にとってロールが付与されたコンテナでのみ使用可能です。

脚注2

このロールでの権限は、被付与者にとってロールが付与され作成されたコンテナでのみ使用可能です。

この項では、次の項目について説明します。

親トピック: CDBでの権限およびロール付与の概要

ロールまたは権限がローカルに付与される条件

ロールまたは権限をローカルに付与するには、CONTAINER=CURRENT句(デフォルト)を含むGRANT文を使用します。

具体的には、次の条件を満たした場合にのみ、ロールまたは権限がローカルに付与されます。

  • 付与者に、指定したロールまたは権限を付与するために必要な権限がある。

    システム・ロールまたは権限の場合、付与者には付与するロールまたは権限に対するADMIN OPTIONが必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTIONが必要です。

  • 付与は1つのコンテナに対してのみ適用される。

    GRANT文には、権限またはロールがローカルに付与されることを示すCONTAINER=CURRENT句がデフォルトで含まれています。

例2-4 ローカルでの権限の付与

この例で、SYSTEMおよびc##hr_adminは両方とも共通ユーザーです。この例ではSYSTEM(管理者権限を持つ)としてhrpdbに接続し、employees表での読取り権限をローカルにc##hr_adminに付与します。この付与は、他のPDB内ではなくhrpdb内のc##hr_adminのみに適用されます。 

CONNECT SYSTEM@hrpdb
Enter password: password
Connected.

GRANT READ ON employees TO c##hr_admin CONTAINER=CURRENT;

関連項目:

ローカルなロールおよび権限の付与についてさらに学習するには、Oracle Databaseセキュリティ・ガイドを参照してください

親トピック: CDBでローカルに付与される権限およびロール

ローカルに付与されるロールおよび権限

ユーザーまたはロールは、ローカルに付与された権限である可能性があります(CONTAINER=CURRENT)。

たとえば、hrpdbのローカルまたは共通ユーザーに対してローカルに付与されたREAD ANY TABLE権限は、この PDB内のこのユーザーに対してのみ適用されます。同様に、非CDBのユーザーhrに付与されたREAD ANY TABLE権限は、別の非CDBに存在するhrユーザーの権限には何の関係もありません。

ユーザーまたはロールは、ローカルに付与されたロールである可能性があります(CONTAINER=CURRENT)。表2-4に示すように、共通ロールは、ローカルに付与される権限を受領する可能性があります。たとえば、共通ロールc##dbaは、hrpdbでREAD ANY TABLE権限をローカルに付与される可能性があります。c##cdb共通ロールがローカルに付与されると、そのロールの権限は、ロールの付与先のコンテナでのみ適用されます。この例では、c##cdbaロールを持つ共通ユーザーは、権限がこのロールに対してhrpdbでローカルに付与されたものであるため、この権限をhrpdb以外のどのPDBでも実行する権利はありません。

関連項目:

CDBでロールおよび権限を付与する方法を学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBでローカルに付与される権限およびロール

CDBで共通に付与されるロールおよび権限

権限および共通ロールは、共通に付与される可能性があります。

ユーザー・アカウントまたはロールには、被付与者と付与者がどちらも共通である場合にのみ、ロールおよび権限を共通に付与できます。ロールを共通に付与する場合、そのロール自体が共通である必要があります。次の表に、共通の付与の可能性を示します。

表2-5 共通の付与

現象 共通の付与が可能 共通の受領が可能 共通に付与されたロールおよび権限の受領が可能

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

はい

該当なし

はい

ローカル・ユーザー・アカウント

いいえ

該当なし

いいえ

共通ロール

該当なし

はい脚注3

はい

ローカル・ロール

該当なし

いいえ

いいえ

権限

該当なし

はい

該当なし

脚注3

共通ロールに共通に付与された権限は、すべてのコンテナで被付与者が使用できます。さらに、共通ロールに対してローカルに付与された権限はどれも、その権限が共通ロールに付与されたコンテナでのみ、被付与者が使用できます。

この項では、次の項目について説明します。

関連項目:

共通の付与についてさらに学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBでの権限およびロール付与の概要

付与が共通になる条件

CONTAINER=ALL句は、権限またはロールが共通に付与されることを指定します。

ロールまたは権限は、次の条件を満たしたとき、共通に付与されます。

  • 付与者は、共通ユーザーである。

    付与を実行するユーザーは、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。

  • 被付与者は、共通ユーザーまたは共通ロールである。

    付与の受領者は、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。

  • 付与者に、指定したロールまたは権限を付与するために必要な権限がある。

    システム・ロールまたは権限の場合、付与者には付与するロールまたは権限に対するADMIN OPTIONが必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTIONが必要です。

  • 付与は、付与が発生したコンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のすべてのPDBに適用されます。

    GRANT文には、権限またはロールが共通に付与されることを指定するCONTAINER=ALL句が含まれます。

  • ロールが付与される場合、それは共通であり、オブジェクト権限が付与される場合は、権限が付与される対象のオブジェクトが共通であることが必要。

例2-5 共通での権限の付与

この例で、SYSTEMおよびc##hr_adminは両方とも共通ユーザーです。SYSTEMはCDBルートに接続して、CREATE ANY TABLE権限をc##hr_adminに共通に付与します。この場合、c##hr_adminはCDBのどのPDBにも表を作成できるようになります。 

CONNECT SYSTEM@root 
Enter password: password
Connected.

GRANT CREATE ANY TABLE TO c##hr_admin CONTAINER=ALL;

関連項目:

共通権限の付与方法を学習するには、Oracle Databaseセキュリティ・ガイドを参照

親トピック: CDBで共通に付与されるロールおよび権限

共通に付与されるロールおよび権限

共通ユーザー・アカウントまたはロールには、権限を共通に付与できます(CONTAINER=ALL)。

CDBルートまたはアプリケーション・ルートのいずれかのコンテキスト内で、現在のコンテナ内の既存および将来のすべてのPDBにおいて、権限がこの共通ユーザー・アカウントまたはロールに付与されます。たとえば、SYSTEMがCDBルートに接続して、SELECT ANY TABLE権限をCDB共通ユーザー・アカウントc##dbaに共通に付与した場合、ユーザーc##dbaはCDBのすべてのPDBでこの権限を保持します。共通に付与されたロールまたは権限をローカルに取り消すことはできません。

ユーザーまたはロールは、共通に付与された共通ロールを受領する可能性があります。表2-5の脚注で言及されているように、共通ロールは、ローカルに付与された権限を受領できます。したがって、共通ユーザーには共通ロールを付与でき、このロールにはローカルに付与された権限が含まれる可能性があります。

たとえば、共通ロールc##adminは、hrpdbに対してローカルなSELECT ANY TABLE権限を付与される可能性があります。共通ロールでローカルに付与された権限は、その権限が付与されたコンテナでのみ適用されます。したがって、c##adminロールを持つ共通ユーザーには、salespdbまたはhrpdb以外のどのPDBでも、hrpdbに含まれる権限を実行する権利はありません。

関連項目:

CDBでロールおよび権限を付与する方法を学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBで共通に付与されるロールおよび権限

CDBでのPUBLICへの付与

CDBでは、PUBLICは共通ロールです。PDBでは、PUBLICにローカルに付与された権限により、すべてのローカルおよび共通ユーザー・アカウントはこのPDBでのみこれらの権限を実行できるようになります。

Oracle提供のユーザーおよびロールに付与される権限およびロールはいずれも共通に付与されますが、PUBLICに付与されるシステム権限のみはローカルに付与されます。この例外は、Oracle Databaseにデフォルトで含まれている一部の付与(SYS.UTL_FILEに対するEXECUTEなど)を取り消すことができるように設けられています。

ローカル・ユーザー・アカウントhrがhrpdbに存在するとします。このユーザーは、hr.employeesでのSELECT権限を、PUBLICに対してローカルに付与します。hrpdbの共通およびローカル・ユーザーは、PUBLICに付与された権限を実行できます。salespdbまたはその他のPDBのユーザー・アカウントには、hrpdbでhr.employeesに問い合せる権限はありません。

PUBLICに対して共通に付与され権限により、すべてのローカル・ユーザーは、それぞれのPDBで付与された権限を実行でき、すべての共通ユーザーは、アクセス権限を持つPDBでこの権限を実行できます。ユーザーは、PUBLICに対しては、権限およびロールを共通に付与しないことをお薦めします。

関連項目:

マルチテナント環境でPUBLICロールロールが機能する仕組みを学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBでの権限およびロール付与の概要

権限およびロールの付与: シナリオ

このシナリオでは、SYSTEMは共通ユーザーc##dbaを作成し、hrpdbのhrスキーマで表を問い合せるためにこのユーザー権限を付与しようとします。

このシナリオは、CONTAINER句がロールおよび権限の付与にどのような影響を与えるかを示しています。最初の列には、CDB$ROOTでの操作が示されています。2番目の列には、hrpdbでの操作が示されています。

表2-6 CDBのロールおよび権限の付与

t CDB$ROOTでの操作 hrpdbでの操作 説明

t1

 
SQL> CONNECT SYSTEM@root
Enter password: *******
Connected.

該当なし

共通ユーザーSYSTEMは、ルート・コンテナに接続します。

t2

 
SQL> CREATE USER c##dba 
IDENTIFIED BY password 
CONTAINER=ALL;

該当なし

SYSTEMは、共通ユーザーc##dbaを作成します。CONTAINER=ALL句により、ユーザーが共通ユーザーになります。

t3

 
SQL> GRANT CREATE SESSION 
  TO c##dba;

該当なし

SYSTEMは、CREATE SESSIONシステム権限をc##dbaに付与します。CONTAINER=ALL句がないため、この権限はローカルに付与され、したがって現行のコンテナであるルートに対してのみ適用されます。

t4

 
SQL> CREATE ROLE c##admin 
  CONTAINER=ALL;

該当なし

SYSTEMは、c##adminという共通ロールを作成します。CONTAINER=ALL句により、ロールは共通ロールになります。

t5

 
SQL> GRANT SELECT ANY TABLE 
  TO c##admin;
Grant succeeded.

該当なし

SYSTEMは、SELECT ANY TABLE権限をc##adminロールに付与します。CONTAINER=ALL句がないため、権限はルートに対してローカルになります。したがって、この共通ロールには、ルートでのみ実行可能な権限が含まれます。

t6

 
SQL> GRANT c##admin TO c##dba;
SQL> EXIT;

該当なし

SYSTEMは、c##adminロールをc##dbaに付与します。CONTAINER=ALL句がないため、ロールは、共通ロールであっても、現行のコンテナに対してのみ適用されます。c##dbaがPDBに接続すると、c##dbaにこのロールはありません。

t7

該当なし

 
SQL> CONNECT c##dba@hrpdb
Enter password: *******
ERROR: ORA-01045: user c##dba
lacks CREATE SESSION privilege;
logon denied

c##dbaは、t3での付与がルートに対してローカルであったため、hrpdbへの接続に失敗します。

t8

該当なし

 
SQL> CONNECT SYSTEM@hrpdb
Enter password: *******
Connected.

SYSTEMは、hrpdbに接続します。

t9

該当なし

 
SQL> GRANT CONNECT, RESOURCE TO c##dba;
Grant succeeded.
SQL> EXIT

SYSTEMは、CONNECTロールおよびRESOURCEロールを共通ユーザーc##dbaに付与します。CONTAINER=ALL句がないため、付与はhrpdbに対してローカルです。

t10

該当なし

 
SQL> CONNECT c##dba@hrpdb
Enter password: *******
Connected.

共通ユーザーc##dbaは、hrpdbに接続します。

t11

該当なし

 
SQL> SELECT COUNT(*)
FROM hr.employees;
select * from hr.employees
                 *
ERROR at line 1:
ORA-00942: table or view does
not exist

c##dbaはhrpdb内の表に対してSELECT権限がないため、hr.employeesの問合せからは、まだエラーが戻されます。t5でローカルに付与されたSELECT ANY TABLE権限は、ルートに限定されるため、hrpdbには適用されません。

t12

 
SQL> CONNECT SYSTEM@root
Enter password: *******
Connected.

該当なし

共通ユーザーSYSTEMは、ルート・コンテナに接続します。

t13

 
SQL> GRANT SELECT ANY TABLE
 TO c##admin CONTAINER=ALL;
Grant succeeded.

該当なし

SYSTEMは、SELECT ANY TABLE権限をc##adminロールに付与します。CONTAINER=ALLが存在するため、この権限は共通に付与されます。

t14

該当なし

 
SQL> SELECT COUNT(*) FROM 
  hr.employees;
select * from hr.employees
                 *
ERROR at line 1:
ORA-00942: table or view does
not exist

hr.employeesの問合せでは、まだエラーが戻されます。これは、t6でc##admin共通ロールが、ルートでのみc##dbaに付与されたためです。

t15

 
SQL> GRANT c##admin TO c##dba
  CONTAINER=ALL;
Grant succeeded.

該当なし

SYSTEMは、CONTAINER=ALLを指定して、c##adminという共通ロールをc##dbaに付与します。これでユーザーc##dbaは、ルートのみでなく、すべてのコンテナでこのロールを持つことになります。

t17

該当なし

 
SQL> SELECT COUNT(*)
  FROM hr.employees;

  COUNT(*)
----------
       107

問合せに成功します。

関連項目:

共通ロールおよびローカル・ロールの管理方法を学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

親トピック: CDBでの権限およびロール付与の概要

CDBの共通オブジェクトおよびローカル・オブジェクトの概要

共通オブジェクトは、CDBルートまたはアプリケーション・ルートのいずれかで定義されており、メタデータ・リンクまたはオブジェクト・リンクを使用して参照できます。ローカル・オブジェクトは、共通オブジェクトではないすべてのオブジェクトです。

データベースによって提供される共通オブジェクトは、CDB$ROOTで定義されており、変更できません。Oracle Databaseでは、CDB$ROOTでの共通オブジェクトの作成はサポートされていません。

アプリケーション・ルートでは、表、ビュー、PL/SQLおよびJavaプログラム・ユニット、順序などのほとんどのスキーマ・オブジェクトを共通オブジェクトとして作成できます。オブジェクトがアプリケーション・ルートに存在する場合、それはアプリケーション共通オブジェクトと呼ばれます。

ローカル・ユーザーは共通オブジェクトを所有できます。また、共通ユーザーはローカル・オブジェクトを所有できますが、これはオブジェクトがデータリンクまたはメタデータリンクされてなく、なおかつメタデータ・リンクでもデータ・リンクでもない場合のみです。

関連項目:

親トピック: CDBの共通性の概要

共通監査構成の概要

混合モードと統合監査のどちらの場合も、共通監査構成が表示され、すべてのPDBにわたって実行されます。

監査構成は、ローカルまたは共通のいずれかです。ユーザーやロールなど、その他のローカルまたは共通の現象に適用されるスコーピング・ルールは、すべて監査構成に適用されます。

ノート:

監査初期化パラメータは、CDBレベルに存在し、各PDBには存在しません。

PDBでは、次の監査オプションがサポートされます。

  • オブジェクト監査

    オブジェクト監査とは、特定のオブジェクトに対する監査構成のことを指します。共通監査構成に含めることができるのは、共通オブジェクトのみです。ローカル監査構成には、共通オブジェクトを含めることはできません。

  • 監査ポリシー

    監査ポリシーは、ローカルまたは共通のいずれかです。

    • ローカル監査ポリシー

      ローカル監査ポリシーは、1つのPDBに適用されます。ローカル監査ポリシーは、このPDBのみのローカルおよび共通ユーザーに対して実行できます。ローカル監査ポリシーをすべてのコンテナにわたって実行しようとすると、エラーが発生します。

      いかなる場合でも、ローカル監査ポリシーの実行は、ローカル監査フレームワークの一部です。

    • 共通監査ポリシー

      共通監査ポリシーは、すべてのコンテナに対して適用されます。このポリシーには、アクション、システム権限、共通ロールおよび共通オブジェクトのみを含めることができます。共通監査ポリシーは、共通ユーザーに対してのみ適用できます。ローカル・ユーザーに対する共通監査ポリシーをすべてのコンテナにわたって実行しようとすると、エラーが発生します。

共通監査構成は、ルートのSYSスキーマに格納されています。ローカル監査構成は、適用対象のPDBのSYSスキーマに格納されています。

監査証跡は、関連PDBのSYSまたはAUDSYSスキーマに格納されています。オペレーティング・システムおよびPDBのXML監査証跡は、AUDIT_FILE_DEST初期化パラメータで指定されたディレクトリのサブディレクトリに格納されています。

関連項目:

親トピック: CDBの共通性の概要

PDBロックダウン・プロファイルの概要

PDBロックダウン・プロファイルは、PDBに接続されたユーザーが使用できる操作を制限する一連の機能に名前を付けたものです。たとえば、PDBロックダウン・プロファイルによって、ALTER SYSTEM文に伴う権限を無効化できます。

PDBがIDを共有する際、権限が上昇する可能性があります。たとえば、ネットワーク・レベルや、PDBが共通オブジェクトにアクセスする、またはデータベース・リンク経由で接続する際にIDを共有できます。セキュリティを向上するため、CDB管理者はアクセスを区画化することで、ユーザーがPDBで実行可能な操作を制限する場合があります。

ユースケースとしては、高、中および低レベルのロックダウン・プロファイルの作成があります。高いレベルではアクセスが大幅に制限されますが、低いレベルではアクセスが有効になります。

次のタイプのアクセスを制限できます。

  • ネットワーク・アクセス

    たとえば、UTL_HTTPやUTL_MAILへのアクセスを制限します。

  • 共通ユーザーおよび共通オブジェクトのアクセス

    たとえば、PDBのローカル・ユーザーが共通ユーザーを介してプロキシを使用する操作や、共通スキーマのオブジェクトにアクセスする操作を制限します。

  • オペレーティング・システム・アクセス

    たとえば、PL/SQLパッケージUTL_FILEやDBMS_FILE_TRANSFERへのアクセスを制限します。

  • 接続

    たとえば、共通ユーザーによるPDBへの接続を制限したり、SYSOPER管理権限を持つローカル・ユーザーによる制限モードでオープンしたPDBへの接続を制限できます。

  • 管理機能

    たとえば、ALTER SYSTEM、ALTER SESSIONおよびALTER DATABASEの使用を制限できます。

  • データベース・オプション

    たとえば、ロックダウン・プロファイルを使用して、Oracleのパーティション化やOracle Databaseアドバンスト・キューイングなどのデータベース・オプションへのアクセスを無効にできます。

CDBルートまたはアプリケーション・ルートにログインするときに、次のオプション句をサポートしているCREATE LOCKDOWN PROFILE文を発行して、ロックダウン・プロファイルを作成します。

  • FROM static_base_profileは、既存のプロファイルの値を使用して、新しいロックダウン・プロファイルを作成します。既存のプロファイルへの以降の変更は、新しいプロファイルには影響しません。

  • INCLUDING dynamic_base_profileは、既存のプロファイルの値を使用して新しいロックダウン・プロファイルを作成しますが、この新しいロックダウン・プロファイルは、基本プロファイルを構成するDISABLE STATEMENTルール、および基本プロファイルへの以降の変更を継承するという点が異なります。

文を発行するユーザーは、現在のコンテナでCREATE LOCKDOWN PROFILEシステム権限を持っている必要があります。制約を追加および削除するには、ALTER LOCKDOWN PROFILE文を使用します。ユーザーはCDBルートまたはアプリケーション・ルートでALTER文を発行する必要があり、現在のコンテナでALTER LOCKDOWN PROFILEシステム権限を持っている必要があります。

ロックダウン・プロファイルは、PDB_LOCKDOWN初期化パラメータを使用して指定します。このパラメータによって、PDBロックダウン・プロファイルが指定のPDBに適用されるかどうかが決定します。このパラメータは、次のレベルで設定できます。

  • PDB

    プロファイルは、設定されるPDBにのみ適用されます。

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

    プロファイルは、アプリケーション・コンテナ内のすべてのアプリケーションPDBに適用されます。値を変更できるのは、アプリケーション共通のSYSDBA権限または共通のALTER SYSTEM権限を持つアプリケーション共通ユーザー、あるいは共通のSYSDBA権限または共通のALTER SYSTEM権限を持つCDB共通ユーザーのみです。

  • CDB

    プロファイルはすべてのPDBに適用されます。共通のSYSDBA権限または共通のALTER SYSTEM権限を持つ共通ユーザーは、特定のPDBに対するCDB全体の設定をオーバーライドできます。

PDBのPDB_LOCKDOWNパラメータが、このPDBのコンテナ(CDBまたはアプリケーション・コンテナ)とは異なるロックダウン・プロファイルの名前に設定されている場合は、一連のルールによって制限の間の相互作用が制御されます。

例2-6 PDBロックダウン・プロファイルの作成

この例では、CREATE LOCKDOWN PROFILE権限を持つ共通ユーザーとしてCDBルートに接続します。ALTER SYSTEM FLUSH SHARED POOL以外のすべてのALTER SYSTEM文を無効にする、mediumというプロファイルを作成します。 

CREATE LOCKDOWN PROFILE medium;
ALTER LOCKDOWN PROFILE medium DISABLE STATEMENT=('ALTER SYSTEM');
ALTER LOCKDOWN PROFILE medium ENABLE STATEMENT=('ALTER SYSTEM') CLAUSE=('FLUSH SHARED POOL');

同じ共通ユーザーとして、このプロファイルを必要とする各PDBに接続し、ALTER SYSTEMを使用してPDB_LOCKDOWN初期化パラメータをmediumに設定します。たとえば、hrpdbについてPDB_LOCKDOWNをmediumに設定できますが、salespdbには設定できません。

次の例では、mediumからmedium2プロファイルを作成します。 

CREATE LOCKDOWN PROFILE medium2 FROM medium;

ノート:

親トピック: CDBの共通性の概要

アプリケーション・コンテナ内のアプリケーションの概要

アプリケーション・コンテナ内で、アプリケーションはアプリケーション・ルートに格納される共通データおよびメタデータの名前付けおよびバージョニングされたセットです。

このアプリケーション・コンテナのコンテキストでは、「アプリケーション」という用語は「マスター・アプリケーション定義」を意味します。たとえば、表、ビュー、パッケージなどの定義をアプリケーションに含めることができます。

この項では、次の項目について説明します。

  • アプリケーション・コンテナについて
    アプリケーション・コンテナはオプションのユーザー作成CDBコンポーネントで、1つ以上のアプリケーション・バックエンドのデータおよびメタデータが格納されます。CDBにはゼロ以上のアプリケーション・コンテナが含まれます。
  • アプリケーション共通オブジェクト
    アプリケーション共通オブジェクトは、アプリケーション・ルートのアプリケーション内で作成される共通オブジェクトです。共通オブジェクトはデータリンクされているか、メタデータリンクされているかのいずれかです。
  • アプリケーション・メンテナンス
    このコンテキストにおけるアプリケーション・メンテナンスは、アプリケーションのインストール、アンインストール、アップグレードまたはパッチ適用を指します。
  • 既存のアプリケーションの移行
    PDBにインストールされているアプリケーションを、アプリケーション・ルートまたはアプリケーションPDBのいずれかに移行できます。
  • 暗黙的に作成されるアプリケーション
    ユーザー作成アプリケーション以外に、アプリケーション・コンテナには暗黙的に作成されるアプリケーションも含まれます。
  • アプリケーションの同期化
    アプリケーションPDB内で、同期化は、アプリケーション・ルートでの最新のバージョンおよびパッチへのユーザー始動のアプリケーションの更新です。
  • コンテナ・マップ
    コンテナ・マップを使用することにより、アプリケーション・ルートに接続したセッションで発行したSQL文が、SQL文に使用された条件の値に応じて適切な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の親であるアプリケーション・ルートが1つあります。
  • アプリケーションPDB
    アプリケーションPDBはアプリケーション・コンテナ内に存在するPDBです。CDB内のPDBはすべて、ゼロまたは1つのアプリケーション・コンテナに存在します。
  • アプリケーション・シード
    アプリケーション・シードはアプリケーション・コンテナ内のオプションのユーザー作成PDBです。アプリケーション・コンテナにはゼロまたは1つのアプリケーション・シードが含まれます。

関連項目:

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

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

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

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

この項では、次の項目について説明します。

親トピック: アプリケーション・コンテナについて

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

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

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

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

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

    アプリケーション・ルートでアプリケーションをアップグレードすると、その変更はすべてのアプリケーションPDBに自動的に伝播されます。アプリケーション・バックエンドには、データリンク共通オブジェクトapp_rolesが含まれている可能性があります。これは、admin、manager、sales_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で使用できます。

図2-8 SaaSのユースケース

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

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

  • パフォーマンス

  • セキュリティ

  • 複数の顧客のサポート

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

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

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

サンプル・ユースケースでは、ある会社が各会計四半期に固有のデータを別個のPDBに配置しています。たとえば、sales_acというアプリケーション・コンテナにq1_2016_pdb、q2_2016_pdb、q3_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には表示されません。

関連項目:

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

この例では、管理共通ユーザー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表がある場合があります。

この項では、次の項目について説明します。

関連項目:

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

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

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

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

  • DEFAULT_SHARING初期化パラメータ

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

  • SHARING句

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

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

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

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

関連項目:

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

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

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

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

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

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

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

この例では、SYSTEMユーザーがsaas_sales_acアプリケーション・コンテナにログインします。SYSTEMは、saas_sales_appという名前のアプリケーションのバージョン1.0をインストールします(「アプリケーション・メンテナンス」を参照)。このアプリケーションは、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_pdbでsales_mltを更新する中間層コードはcust2_pdbでこの表のコピーに行を追加します。アプリケーション・ルートに格納される表メタデータのみが共有されます。

ノート:

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

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

メタデータ・リンク

メタデータリンク・アプリケーション共通オブジェクトの場合、オブジェクトのメタデータはアプリケーション・ルートに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すべてにこのリンクのディクショナリ定義が含まれます。

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

この例では、SYSTEMがsaas_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キーワードを指定します。

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

この例では、SYSTEMがsaas_sales_acアプリケーション・コンテナに接続し、(「例2-8」で作成した) 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に挿入された郵便番号を参照できますが、この表に独自の郵便番号を挿入することもできます。

ノート:

「アプリケーション共通オブジェクトについて」

アプリケーション・メンテナンス

このコンテキストにおけるアプリケーション・メンテナンスは、アプリケーションのインストール、アンインストール、アップグレードまたはパッチ適用を指します。

アプリケーションには名前およびバージョン番号が必要です。このプロパティの組合せによって、実行可能なメンテナンス作業が決まります。すべてのメンテナンス作業で、次のステップを実行します。

  1. ALTER PLUGGABLE DATABASE ... APPLICATION文をBEGIN INSTALL句、BEGIN UPGRADE句またはBEGIN PATCH句とともに実行することで開始します。

  2. 文を実行してアプリケーションを変更します。

  3. ALTER PLUGGABLE DATABASE ... APPLICATION文をEND INSTALL句、END UPGRADE句またはEND PATCH句とともに実行することで終了します。

アプリケーションの発展に伴って、アプリケーション・コンテナではバージョンおよびパッチの変更がすべて保守されます。

この項では、次の項目について説明します。

ノート:

「アプリケーションの管理について」

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

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

ALTER PLUGGABLE DATABASE APPLICATION文を使用して、アプリケーションのインストール、アップグレードおよびパッチ適用操作を実行します。

アプリケーション・メンテナンスの基本的なステップは、次のとおりです。

  1. アプリケーション・ルートにログインします。

  2. アプリケーション・ルートでALTER PLUGGABLE DATABASE APPLICATION ... BEGIN文を使用して操作を開始します。

  3. アプリケーション・メンテナンスの文を実行します。

  4. ALTER PLUGGABLE DATABASE APPLICATION ... END文を使用して操作を終了します。

スクリプト、SQL文またはGUIツールを使用してメンテナンスを実行します。

アプリケーションのインストール

アプリケーションのインストールは、マスター・アプリケーション定義の初期作成操作です。通常のインストールではユーザー・アカウント、表およびPL/SQLパッケージが作成されます。

アプリケーションをインストールするには、ALTER PLUGGABLE DATABASE APPLICATION文に次の項目を指定します。

  • アプリケーション名

  • アプリケーションのバージョン番号

例2-11 アプリケーションのインストール

この例では、saas_sales_acという名前のアプリケーション・コンテナにログインしていると仮定します。例ではバージョン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 application
CREATE USER saas_sales_adm IDENTIFIED BY manager CONTAINER=ALL;

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

-- Make 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/manager@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';

PDBの同期化は、ユーザーがアプリケーション・ルートのアプリケーションを使用して開始するアプリケーションPDBの更新です。saas_sales_appアプリケーションを使用してアプリケーションPDBを同期化した後、各アプリケーションPDBにproducts_mltと呼ばれる空の表が格納されます。アプリケーションは、アプリケーションPDBに接続してから、この表にPDB固有の行を挿入できます。

アプリケーションのアップグレード

アプリケーションのアップグレードはインストールされたアプリケーションへの大規模な変更です。

通常、アップグレードではアプリケーションの物理アーキテクチャが変更されます。たとえば、アップグレードによって新規のユーザー・アカウント、表およびパッケージが追加されたり、既存のオブジェクトの定義が変更されます。

アプリケーションをアップグレードするには、ALTER PLUGGABLE DATABASE APPLICATION文で次の項目を指定する必要があります。

  • アプリケーション名

  • 古いアプリケーションのバージョン番号

  • 新規のアプリケーションのバージョン番号

例2-12 自動による手法を使用したアプリケーションのアップグレード

この例では、管理者としてアプリケーション・ルートに接続し、アプリケーションsaas_sales_appをバージョン1.0からバージョン2.0にアップグレードします。アップグレードにより、countries_dltという名前のデータリンク表が作成され、その表に行が追加されます。また、zipcodes_edtという名前の拡張データリンク表が作成され、その表に行が追加されます。 

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

-- Connect as app owner to app 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');

-- Create an extended data-linked 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 '2.0';

この項では、次の項目について説明します。

関連項目:

「アプリケーション・コンテナ内のアプリケーションのアップグレード」

親トピック: アプリケーション・メンテナンス

アプリケーションのアップグレードの動作

アプリケーションのアップグレード中に、アプリケーションは引き続き使用可能です。この可用性を可能にするため、Oracle Databaseではアプリケーション・ルートがクローニングされます。

次の図で、アプリケーションのアップグレード・プロセスの概要を示します。

図2-9 アプリケーションのアップグレード

図2-9の説明が続きます
「図2-9 アプリケーションのアップグレード」の説明

アップグレードは次のように実行されます。

  1. 初期の状態で、アプリケーション・ルートには特定のバージョンのアプリケーションがあります。

  2. ユーザーはALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE文を実行してから、アプリケーションのアップグレード文を発行します。

    アップグレード中にデータベースでは自動的に次の処理が実行されます。

    • アプリケーション・ルートをクローニングします

      たとえば、saas_sales_appアプリケーションがアプリケーション・ルートでバージョン1.0である場合、クローンもバージョン1.0になります。

    • アプリケーションPDBをアプリケーション・ルート・クローンに示します

      クローンは読取り専用モードです。アプリケーションはアプリケーションPDBに対して引き続き使用可能です。

  3. ユーザーはALTER PLUGGABLE DATABASE APPLICATION END UPGRADE文を実行します。

    この段階で、アプリケーションPDBは依然としてアプリケーション・ルート・クローンを示しており、元のアプリケーション・ルートが新規バージョンになります。たとえば、saas_sales_appアプリケーションがアプリケーション・ルートでバージョン1.0である場合、アップグレードによってこれがバージョン2.0になります。ただし、アプリケーション・ルート・クローンはバージョン1.0のままです。

  4. オプションで、SYNC句とともにALTER PLUGGABLE DATABASE APPLICATION文を発行することで、ユーザーはアプリケーションPDBをアップグレード済のアプリケーション・ルートと同期化します。

    たとえば、同期後に、一部のアプリケーションPDBはバージョン2.0のアプリケーション・ルートに接続されます。ただし、アプリケーション・ルート・クローンでは、バージョン1.0のままでいることが必要なアプリケーションPDBや、バージョン1.0のアプリケーション・ルートに接続される新規のアプリケーションPDBが引き続きサポートされます。

異なるバージョンのアプリケーション

異なるアプリケーションPDBが、異なるバージョンのアプリケーションを使用する場合があります。

たとえば、あるアプリケーションPDBにsaas_sales_appのバージョン1.0があるとします。同じアプリケーション・コンテナの別のアプリケーションPDBには、このアプリケーションのバージョン2.0があります。

ユースケースとしては、異なる顧客に提供されたSaaSアプリケーションがあります。個々の顧客に各自のアプリケーションPDBがある場合、中にはアプリケーションをアップグレードするまでより長期間待機する顧客がいます。この場合、あるアプリケーションPDBでは最新バージョンのアプリケーションが使用されますが、他のアプリケーションPDBでは古いバージョンが使用される可能性があります。

関連項目:

異なるバージョンのアプリケーションについてさらに学習するには、「アプリケーション・コンテナ内のアプリケーションのアップグレード」を参照してください

親トピック: アプリケーションのアップグレード

アプリケーション・パッチ

アプリケーション・パッチは、アプリケーションの小規模な変更です。

アプリケーションのパッチ適用の一般的な例として、バグ修正やセキュリティ・パッチがあります。パッチの内部では、新しいファンクションおよびパッケージが許可されます。

一般に、破壊的な操作は許可されません。たとえば、DROP文や、列の削除またはデータ型の変更を行うALTER TABLE文をパッチに含めることはできません。

Oracle Databaseのパッチ適用プロセスでOracle Databaseパッチで許可される操作の種類が制限されるのと同様、アプリケーションのパッチ適用プロセスではアプリケーション・パッチで許可される操作が制限されます。ある修正に「アプリケーション・パッチで操作がサポートされていません」というエラーを引き起こす操作が含まれる場合は、かわりにアプリケーションのアップグレードを実行してください。

ノート:

他のアプリケーションのパッチ適用またはアップグレードが進行中の間は、アプリケーションのパッチ適用ができません。

アプリケーションにパッチを適用するには、ALTER PLUGGABLE DATABASE APPLICATION文にアプリケーション名とパッチ番号を指定します。オプションで、アプリケーション最小バージョンを指定できます。

例2-13 自動による手法を使用したアプリケーションのパッチ適用

この例では、SYSTEMがアプリケーション・ルートにログインし、アプリケーションsaas_sales_appにバージョン1.0以上のパッチを適用します。パッチ101は、saas_sales_admとしてアプリケーション・コンテナにログインし、get_total_revenueという名前のメタデータリンクされたPL/SQLファンクションを作成します。 

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN PATCH 101 MINIMUM VERSION '1.0';

-- Connect to the saas_sales_ac container as saas_sales_adm, who owns the application
CONNECT saas_sales_adm/*******@saas_sales_ac

-- Now install the get_total_revenue() function
CREATE FUNCTION get_total_revenue SHARING=METADATA (p_year IN NUMBER)
RETURN SYS_REFCURSOR
AS
c1_cursor SYS_REFCURSOR;
BEGIN
OPEN c1_cursor FOR
   SELECT a.year,sum(a.revenue)
   FROM containers(sales_data) a
   WHERE a.year = p_year
   GROUP BY a.year;
RETURN c1_cursor;
END;
/

-- End the patch
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END PATCH 101;

既存のアプリケーションの移行

PDBにインストールされているアプリケーションを、アプリケーション・ルートまたはアプリケーションPDBのいずれかに移行できます。

既存のアプリケーションを移行する一般的な理由として、次のものがあります。

  • インストール・プログラムを使用するアプリケーション

    一部のアプリケーションは、スクリプトではなくインストール・プログラムを使用します。この場合は、新しいアプリケーション・ルートでインストール・プログラムを実行し、DBMS_PDB_ALTER_SHARINGパッケージを使用してオブジェクトを適切な共有モード(METADATA、DATAまたはEXTENDED DATA)に設定します。この変更はルートからアプリケーションPDBに自動的に伝播します。Oracle Databaseによってインストールの文ログが作成されるため、前のアプリケーション・バージョンのPDBはアプリケーション・ルートに接続できます。

  • 各PDBで別個に定義されたアプリケーション

    一部のアプリケーションは各PDBで定義されますが、アプリケーション・コンテナが存在しません。この場合は、インストール・スクリプトを更新して適切な共有モードを設定できます。アプリケーション・ルートを作成し、このルートでマスター・アプリケーション定義を作成します。既存のPDBをアプリケーションPDBとして採用するには、そのPDBをアプリケーション・ルートに接続し、共通定義への参照を使用して定義全体を置き換えるSQLスクリプトを実行します。

たとえば、Oracle Database 12c CDBに接続中のPDBにインストールされているアプリケーションを、Oracle Database 18c CDBのアプリケーション・コンテナに移行できます。

関連項目:

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

暗黙的に作成されるアプリケーション

ユーザー作成アプリケーション以外に、アプリケーション・コンテナには暗黙的に作成されるアプリケーションも含まれます。

ALTER PLUGGABLE DATABASE BEGIN文を最初に使用せずに、アプリケーション共通ユーザー操作がCONTAINER=ALL句によって発行されると、アプリケーション・ルートでアプリケーションが暗黙的に作成されます。

アプリケーション共通ユーザー操作には、CREATE USER文による共通ユーザーの作成や、ALTER USER文による共通ユーザーの変更などの操作が含まれます。データベースによって暗黙的アプリケーションにAPP$guid (guidはアプリケーション・ルートのグローバル一意ID)という名前が自動的に付けられます。暗黙的アプリケーションは、アプリケーション・ルートが初めて開かれたときに作成されます。

関連項目:

暗黙的に作成されるアプリケーションについてさらに学習するには、「アプリケーションPDB内のアプリケーションの同期」を参照してください

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

アプリケーションの同期化

アプリケーションPDB内で、同期化は、アプリケーション・ルートでの最新のバージョンおよびパッチへのユーザー始動のアプリケーションの更新です。

アプリケーションPDBに接続されているとき、SYNCキーワードとともにALTER PLUGGABLE DATABASE APPLICATION文を発行することでアプリケーションを同期化します。SYNCの前にアプリケーション名を指定すると、指定されたアプリケーションのみがデータベースによって同期化されます。アプリケーション名を指定しないか、ALL SYNCを指定した場合は、暗黙的に作成されたアプリケーションを含むすべてのアプリケーションがデータベースによって同期化されます。

ノート:

アプリケーション・ルートへの接続中に、アプリケーションのインストール、アップグレードおよびパッチ適用の操作によって、変更がアプリケーションPDBに自動的には伝播されません。

例2-14 アプリケーションPDB内の特定のアプリケーションの同期化

次の文ではsaas_sales_appというアプリケーションが、アプリケーション・ルートでの最新のアプリケーションの変更と同期化されます。 

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;

例2-15 アプリケーションPDB内の特定のアプリケーションとパッチの同期化

次の文では、saas_sales_appというアプリケーションがアプリケーション・ルートのパッチ100と同期化されます。 

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC TO PATCH 100;

関連項目:

「アプリケーションPDB内のアプリケーションの同期」

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

コンテナ・マップ

コンテナ・マップを使用することにより、アプリケーション・ルートに接続したセッションで発行した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_pdb、euro_pdbおよびasia_pdbというパーティションがアプリケーションPDBの名前に対応します。各パーティションの値は、たとえばPARTITION amer_pdb VALUES ('US','MEXICO','CANADA')のように、国の名前です。

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

  • コンテナ・マップ

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

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

この例では、アプリケーション管理者としてアプリケーション・ルートにログインします。アプリケーション・コンテナに、amer_pdb、euro_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()句を使用する必要があることを指定します。

例2-17 アプリケーションの同期化と、データの追加: パート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;

例2-18 メタデータリンク表の問合せ: パート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

関連項目:

「コンテナ・マップを使用したPDBでのパーティション化」

親トピック: アプリケーション・コンテナ内のアプリケーションの概要

CDBのサービスの概要

クライアントは、サービスを使用してPDBまたはアプリケーション・ルートに接続する必要があります。

サービス名を使用した接続により、PDBまたはアプリケーション・ルートでは新規のセッションが開始されます。フォアグラウンド・プロセス、およびその結果のセッションは、ライフタイムの各時点で、一意に定義された現在のコンテナがあります。

次の図に、2つの異なるリスナーを使用してPDBに接続する2つのクライアントを示します。

図2-10 CDBのサービス

図2-10の説明が続きます
「図2-10 CDBのサービス」の説明

この項では、次の項目について説明します。

  • CDBのサービス作成
    CREATE PLUGGABLE DATABASE文を実行してPDBを作成すると、データベースではCDB内のサービスが自動的に作成されて起動されます。
  • CDBのコンテナへの接続
    一般に、CDB管理者はPDBをプロビジョニングして様々なコンテナに接続するための適切な権限が必要です。CDB管理者は共通ユーザーです。

関連項目:

「PDBのサービスの管理」

親トピック: マルチテナント・アーキテクチャの概要

CDBのサービス作成

CREATE PLUGGABLE DATABASE文を実行してPDBを作成すると、データベースではCDB内のサービスが自動的に作成されて起動されます。

このデフォルト・サービスには、PDBをサービスの最初の現行コンテナとして識別するプロパティがあります。このプロパティは、DBA_SERVICES.PDB列に表示されます。

この項では、次の項目について説明します。

  • CDBのデフォルト・サービス
    デフォルト・サービスの名前はPDBと同じになります。PDB名は、CDB内で一意となる有効なサービス名である必要があります。
  • CDBの非デフォルト・サービス
    各PDBについて、CDBごとに上限10,000までの追加サービスを作成できます。各追加サービスでは、そのPDBが最初の現行コンテナとして表示されます。

関連項目:

「PDBのサービスの管理」

親トピック: CDBのサービスの概要

CDBのデフォルト・サービス

デフォルト・サービスの名前はPDBと同じになります。PDB名は、CDB内で一意となる有効なサービス名である必要があります。

アプリケーション・コンテナを作成する際、AS APPLICATION CONTAINER句の指定が必要になると、Oracle Databaseではアプリケーション・ルートの新規のデフォルト・サービスが自動的に作成されます。サービスはアプリケーション・コンテナと同じ名前を持ちます。このサービスにアクセスするクライアントには、Oracle Net Serviceが正しく構成されている必要があります。同様に、すべてのアプリケーションPDBには固有のデフォルト・サービス名があり、アプリケーション・シードPDBには固有のデフォルト・サービス名があります。

例2-19 デフォルト・サービスを使用したPDBへの切替え

この例では、PDBと同じ名前を持つデフォルト・サービスを使用して、PDB名salespdbに切り替えます。 

ALTER SESSION SET CONTAINER = salespdb;

関連項目:

親トピック: CDBのサービスの作成

CDBの非デフォルト・サービス

各PDBについて、CDBごとに上限10,000までの追加サービスを作成できます。各追加サービスでは、そのPDBが最初の現行コンテナとして表示されます。

図2-10では、erppdbとhrpdbにデフォルト以外のサービスが存在します。非CDBで使用するのと同じ方法で、サービスを作成、維持および削除します。

たとえば、図2-10では、hrpdbというPDBには、hrpdbというデフォルトのサービスがあります。デフォルト・サービスは削除できません。

ALTER SESSION SET CONTAINERを使用してコンテナに切り替えると、コンテナのデフォルト・サービスがセッションで使用されます。オプションで、SERVICE = service_nameを指定することでコンテナに別のサービスを使用できます。service_nameはサービスの名前を表します。特定のサービスを使用することで、セッションがそのサービス属性および機能(サービス・メトリック、ロード・バランシング、Resource Manager設定など)を利用できるようにする場合があります。

例2-20 非デフォルト・サービスを使用したPDBへの切替え

この例では、hrpdbのデフォルト・サービスによってすべてのサービス属性および機能(サービス・メトリック、FAN、ロード・バランシング、Oracle Database Resource Manager、トランザクション・ガード、アプリケーション・コンティニュイティなど)がサポートされるとはかぎりません。非デフォルト・サービスには次のように切り替えます。 

ALTER SESSION SET CONTAINER = hrpdb SERVICE = hrpdb_full;

親トピック: CDBのサービスの作成

CDBのコンテナへの接続

一般に、CDB管理者はPDBをプロビジョニングして様々なコンテナに接続するための適切な特権を持つ必要があります。CDB管理者は共通ユーザーです。

CDB管理者は、次のいずれかの方法を使用できます。

  • PDBまたはアプリケーション・ルートに直接接続します。

    ユーザーにはそのコンテナでのCREATE SESSION権限が必要です。

  • 接続プーリングおよび高度なCDB管理の両方に役立つALTER SESSION SET CONTAINER文を使用して、コンテナの切替えを行います。構文はALTER SESSION SET CONTAINER = container_name [SERVICE = service_name]です。

    たとえば、CDB管理者は、あるセッションのルートに接続してから、同じセッションのPDBに切り替えることができます。この場合、ユーザーにはそのコンテナでのSET CONTAINERシステム権限が必要です。

次の表に、図2-10のCDBに関連したシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEMは、現行コンテナの名前と、CDB内のPDBの名前を問い合せます。

表2-8 CDBのサービス

操作 説明 
SQL> CONNECT SYSTEM@prod
Enter password: ********
Connected.

SYSTEMユーザーは、CDBのすべてのコンテナに対して共通で、prodというサービスを使用してルートに接続します。 

SQL> SHOW CON_NAME
 
CON_NAME
--------
CDB$ROOT

SYSTEMは、ユーザーが現在接続されているコンテナの名前をリストするために、SQL*PlusコマンドSHOW CON_NAMEを使用します。CDB$ROOTは、ルート・コンテナの名前です。 

SQL> SELECT NAME, PDB FROM V$SERVICES 
  2  ORDER BY PDB, NAME;

NAME                    PDB
----------------------  --------
SYS$BACKGROUND          CDB$ROOT
SYS$USERS               CDB$ROOT
prod.example.com        CDB$ROOT
erppdb.example.com      ERPPDB
erp.example.com         ERPPDB
hr.example.com          HRPDB
hrpdb.example.com       HRPDB
salespdb.example.com    SALESPDB

8 rows selected.

V$SERVICESの問合せは、PDB名と一致するサービス名を持つ3つのPDBが存在することを示します。hrpdbとerppdbの両方に追加サービスが1つあります。 

SQL> ALTER SESSION SET CONTAINER = hrpdb;

Session altered.

SYSTEMは、ALTER SESSIONを使用してhrpdbに接続します。 

SQL> SELECT SYS_CONTEXT  
  2  ('USERENV', 'CON_NAME')
  3  AS CUR_CONTAINER FROM DUAL;
 
CUR_CONTAINER
-------------
HRPDB

問合せにより、現行コンテナがhrpdbであることを確認します。

関連項目:

親トピック: CDBのサービスの概要

CDBの表領域およびデータベース・ファイルの概要

CDBの構造は非CDBと同じですが、各PDBおよびアプリケーション・ルートに独自の表領域のセット(独自のSYSTEM、SYSAUXおよびUNDO表領域を含む)が存在する点が異なります。

CDBには次のファイルが含まれています。

  • 1つの制御ファイル

  • 1つのオンラインREDOログ

  • 1つ以上のUNDO表領域

    適切な権限を持ち、現行コンテナがルートとなっている共通ユーザーのみが、UNDO表領域を作成できます。どの時点でも、CDBは次のいずれかのUNDOモードにあります。

    • ローカルUNDOモード

      この場合は、各PDBに固有のUNDO表領域があります。CDBがローカルUNDOモードを使用している場合は、データベースによってすべてのPDBにUNDO表領域が自動的に作成されます。ローカルUNDOはPDBのホット・クローンを実行する機能などの利点を備えており、PDBの再配置を高速化します。また、ローカルUNDOでは分離レベルが提供され、迅速な切断およびポイント・イン・タイム・リカバリ操作が可能です。

      ローカルUNDO表領域は、Oracle Real Application Clusters (RAC)クラスタ内のPDBが開いているノードごとに必要です。たとえば、PDBを2ノードのクラスタから4ノードのクラスタに移動した場合や、すべてのノードでPDBが開いている場合は、必要な追加のUNDO表領域がデータベースによって自動的に作成されます。PDBを元に戻した場合は、冗長なUNDO表領域を削除できます。

      ノート:

      デフォルトでは、Database Configuration Assistant (DBCA)によってローカルUNDOが有効になった状態で新しいCDBが作成されます。

    • 共有UNDOモード

      単一インスタンスCDBでは、アクティブなUNDO表領域が1つのみ存在します。Oracle RAC CDBの場合、それぞれのインスタンスについてアクティブなUNDO表領域が1つ存在します。すべてのUNDO表領域は、すべてのコンテナのデータ・ディクショナリおよび関連ビューで表示されます。

    UNDOモードはCDB全体に適用されます。つまり、すべてのコンテナが共有UNDOを使用するか、すべてのコンテナがローカルUNDOを使用するかのどちらかです。CDBでUNDOモードを切り替えることは可能で、これにはデータベースの再起動が伴います。

  • コンテナごとのSYSTEM表領域およびSYSAUX表領域

    CDBと非CDBの第一の物理的違いは、SYSTEMとSYSAUXのデータファイルです。非CDBには、SYSTEM表領域とSYSAUX表領域がそれぞれ1つのみ含まれます。これに対して、CDB内のCDBルート、各アプリケーション・ルートおよび各PDBには、それぞれ固有のSYSTEMおよびSYSAUX表領域があります。各コンテナには、コンテナに常駐するオブジェクトを記述した独自のディクショナリ表のセットも含まれます。

  • 0以上のユーザー作成表領域

    一般的なユースケースでは、各PDBに独自の非システム表領域のセットがあります。これらの表領域には、PDB内のユーザー定義のスキーマおよびオブジェクトのデータが含まれています。

    PDB内では、永続表領域と一時表領域を非CDBで管理する場合と同じ方法で管理します。CREATE PLUGGABLE DATABASEまたはALTER PLUGGABLE DATABASE文でSTORAGE句を使用して、PDBのデータファイルが使用する記憶域の量を制限することもできます。

    PDB内のデータ・ディクショナリの記憶域は、移植可能です。PDBはCDBから切断し、異なるCDBに接続できます。

  • コンテナごとの一連の一時ファイル

    デフォルトの一時表領域は、CDBルートに1つ存在し、アプリケーション・ルート、アプリケーションPDBおよびPDBごとに1つ存在します。

例2-21 ローカルUNDOモードのCDB

この例は、2つのPDB(hrpdbとsalespdb)を持つCDBの物理記憶域アーキテクチャの様子を示します。この例では、データベースはローカルUNDOモードを使用するため、CDBルート、hrpdbおよびsalespdb内にUNDOデータ・ファイルがあります。

図2-11 ローカルUNDOモードのCDBの物理アーキテクチャ

図2-11の説明が続きます
「図2-11 ローカルUNDOモードのCDBの物理アーキテクチャ」の説明

関連項目:

親トピック: マルチテナント・アーキテクチャの概要

CDBの可用性の概要

非CDBについて存在する多くの可用性機能は、CDB内の個々のPDBについても存在します。

この項では、次の項目について説明します。

親トピック: マルチテナント・アーキテクチャの概要

CDBのバックアップおよびリカバリの概要

RMANおよびOracle Enterprise Manager Cloud Controlによって、マルチテナント環境でのバックアップとリカバリが完全にサポートされます。

CDB全体、rootのみまたは1つ以上のPDBをバックアップおよびリカバリできます。また、PDB内の個々の表領域とデータファイルをバックアップおよびリカバリすることができます。

リカバリの観点では、ルートとすべてのPDBを別個にバックアップすることは、CDB全体をバックアップするのと同等です。主な違いは、入力する必要があるRMANコマンドの数とリカバリの時間です。CDB全体のリカバリにかかる時間は、CDBルートとすべてのPDBをリカバリする場合より短くなります。

他の開いているPDBの操作に影響を与えずに、1つ以上のPDBの完全リカバリを実行できます。RMANは、PDBレベルのPoint-in-Timeリカバリもサポートします。手順は、非CDBのPoint-in-Timeリカバリの手順と類似しています。

関連項目:

CDBの作成後の状態について学習するには、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください

親トピック: CDBの可用性の概要

CDBでのフラッシュバックPDBの概要

SQLまたはRecovery ManagerでFLASHBACK PLUGGABLE DATABASEコマンドを使用してPDBを巻き戻しできます。このコマンドは、非CDBのFLASHBACK DATABASEに似ています。

フラッシュバックPDBはデータ破損、広範囲のユーザー・エラー、およびREDO破損から個々のPDBを保護します。操作ではCDB内の他のPDBのデータは巻き戻しされません。

Oracle Database 12cリリース2 (12.2)よりも前のリリースでは、ルートへの接続時のみ、リストア・ポイント(SCNの別名)を作成できました。現在は、CREATE RESTORE POINT ... FOR PLUGGABLE DATABASEを使用してPDBリストア・ポイント(指定されたPDB内のみで使用可能)を作成できます。CDBリストア・ポイントと同様に、PDBリストア・ポイントも通常または保証付きのいずれかです。保証付きリストア・ポイントは、制御ファイルからエージ・アウトされず、明示的に削除する必要があります。ルートに接続しており、FOR PLUGGABLE DATABASE句を指定しない場合は、すべてのPDBで使用可能なCDBリストア・ポイントを作成します。

特殊なPDBリストア・ポイントのタイプはクリーン・リストア・ポイントで、これはPDBが閉じている場合のみ作成できます。共有UNDOがあるPDBでは、PDBをクリーン・リストア・ポイントまで巻き戻すことによって、データベースの整合性が維持され、パフォーマンスが向上します。パフォーマンスを低下させる可能性がある自動インフラストラクチャがデータベースによって使用されなくなります。

関連項目:

FLASHBACK PLUGGABLE DATABASEの使用について学習するには、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照

親トピック: CDBの可用性の概要

CDBでのOracle Resource Managerの概要

Oracle Resource Manager (Resource Manager)を使用して、CDBリソース・プランを作成し、PDBにリソースを割り当てるための初期化パラメータを設定できます。

非CDBでは、リソース・マネージャを使用して、システム・リソースおよびデータベース・リソースについて競合する複数のワークロードを管理できます。したがって、CDBでは複数のPDB内の複数のワークロードがシステム・リソースおよびCDBリソースについて競合する場合があります。

CDBでは、リソース・マネージャにより、CDBとPDBの2つのレベルでリソースを管理できます。

CDBリソース・プラン

CDBリソース・プランにより、そのリソース・プラン・ディレクティブ(ディレクティブ)のセットに従って、リソースがそのPDBに割り当てられます。CDBリソース・プランとそのディレクティブは親子関係にあります。各リソース・プラン・ディレクティブは、PDBのセットまたは個々のPDBのいずれかを参照します。

パフォーマンス・プロファイルは、PDBのセットに対するシステム・リソースの共有を指定します。PDBパフォーマンス・プロファイルにより、個々のPDBではなくプロファイルのリソース・マネージャ・ディレクティブを指定することで、大量のPDBのリソースを管理できます。

ディレクティブにより、CPUとパラレル実行サーバーの割当てが制御されます。ディレクティブにより、PDBまたはPDBパフォーマンス・プロファイルごとに指定する共有値に基づいてPDBへのリソースの割当てを制御できます。共有値が高いほど、保証されるリソースは増加します。PDBおよびPDBパフォーマンス・プロファイルでは、CPUおよびパラレル・サーバーの使用率制限を設定することもできます。

CDBリソース・プランを作成するには、DBMS_RESOURCE_MANAGER PL/SQLパッケージのCREATE_CDB_PLANプロシージャを使用し、RESOURCE_MANAGER_PLANパラメータを使用してCDBリソース・プランを設定します。CDBリソース・プランのディレクティブを作成するには、CREATE_CDB_PLAN_DIRECTIVEプロシージャを使用します。

PDBリソース・プラン

CDBリソース・プランにより、システム・リソースの一部がPDBに割り当てられます。PDBリソース・プランにより、PDB内でのこの部分の割当て方法が決定します。

PDBリソース・プランは、非CDBのリソース・プランを作成する場合と同じ方法で作成します。プランを作成するには、DBMS_RESOURCE_MANAGERパッケージ内のプロシージャを使用します。

PDBリソース・プランを作成するには、DBMS_RESOURCE_MANAGER PL/SQLパッケージのCREATE_PLANプロシージャを使用し、RESOURCE_MANAGER_PLANパラメータを使用してPDBリソース・プランを設定します。PDBリソース・プランのディレクティブを作成するには、CREATE_PLAN_DIRECTIVEプロシージャを使用します。

PDBレベルのメモリー制御

CDBでは、PDBがSGAまたはPGAメモリーについて競合する可能性があります。複数の初期化パラメータでPDBのメモリー使用(メモリーの保証またはメモリーの制限)を制御できます。PDBを現在のコンテナとして次の初期化パラメータを設定する場合、パラメータは現在のPDBのメモリー使用を制御します。

重要なパラメータの例として、次のものがあります。

  • SGA_MIN_SIZEは、PDBの保証される最小のSGAサイズを設定します。

  • SGA_TARGETは、PDBでいつでも使用できる最大のSGAを指定します。

  • PGA_AGGREGATE_LIMITは、PDBでいつでも使用できる最大のPGAを設定します。

PDBレベルのI/O制御

集中的なディスクI/Oはパフォーマンス低下の原因となることがあります。不適切に設計されたSQL、大量トランザクションでの索引や表のスキャンなど、複数の要因によりディスクI/Oが過剰になることがあります。1つのPDBが過剰なディスクI/Oを生成している場合は、同じCDB内の他のPDBのパフォーマンスが低下することがあります。

非エンジニアド・システムでは、特定のPDBによって生成されるI/Oを制御するために、次の初期化パラメータのどちらかまたは両方を使用します。

  • MAX_IOPSは、毎秒のI/O操作の数を制限します。

  • MAX_MBPSは、毎秒のI/O操作のMB数を制限します。

エンジニアド・システムでは、I/Oリソース管理を使用してPDBのI/Oを管理します。

関連項目:

親トピック: マルチテナント・アーキテクチャの概要