19 マルチテナント・アーキテクチャの概要
この章では、マルチテナント・アーキテクチャの最も重要なコンポーネントについて説明します。
この項では、次の項目について説明します。
CDBのコンテナの概要
コンテナは、マルチテナント・コンテナ・データベース(CDB)内のスキーマ、オブジェクトおよび関連構造の集合です。CDB内では、各コンテナは一意のIDと名前を持ちます。
この項では、次の項目について説明します。
CDBルートとシステム・コンテナ
CDBルート(単純にルートとも呼ばれている)は、スキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合で、すべてのPDBはこれに属します。
どのCDBにも、CDB$ROOT
という名前のルート・コンテナが1つだけあります。ルートにはPDBの管理に必要なシステム・メタデータが格納されます。すべてのPDBはこのルートに属します。システム・コンテナは、CDBルートとこのルートに属するすべてのPDBです。
CDBルートにはユーザー・データは格納されません。共通オブジェクトをルートに追加したり、ルート内のOracle提供スキーマを変更したりしないことをお薦めします。ただし、データベース管理用の共通ユーザーやロールを作成できます(「CDBの共通ユーザー」を参照)。必要な権限を持った共通ユーザーは、コンテナ間の切替えが可能です。
ルート・キャラクタ・セットとして、AL32UTF8をお薦めします。キャラクタ・セット変換をしなくても、異なるキャラクタ・セットを使用するPDBが同じCDB内に存在できます。
例19-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
関連項目:
PDB
PDBは、ユーザーが作成したスキーマ、オブジェクトおよび関連構造体のセットで、論理的にクライアント・アプリケーションでは個別のデータベースとして表示されます。
あらゆるPDBは、そのPDBをどのユーザーが作成したかにかかわらず、CDBの共通ユーザーであるSYS
によって所有されます。
この項では、次の項目について説明します。
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を作成できます。システム・コンテナに含まれるCDBシードは1つだけです。
PDB$SEED
ではシードの削除や、オブジェクトの追加または変更はできません。 -
アプリケーション・シードPDB
アプリケーション・コンテナ内のアプリケーションPDBの作成を促すため、オプションのアプリケーション・シードを作成できます。アプリケーション・コンテナにはゼロまたは1つのアプリケーション・シードが含まれます。
アプリケーション・シードは、アプリケーション・コンテナに接続して
CREATE PLUGGABLE DATABASE ... AS SEED
文を実行することで作成します。「アプリケーション・シード」を参照してください。
プロキシPDB
プロキシPDBは、データベース・リンクを使用してリモートCDB内のPDBを参照するPDBです。PDBが開いている間にプロキシPDBで文を発行すると、その文は参照先PDB内で実行されます。
プロキシPDBは、CDBルートまたはアプリケーション・ルートへの接続中に作成する必要があります。プロキシPDBは、標準PDBと同じように変更または削除ができます。
関連項目:
PDBの作成方法の詳細は、Oracle Database管理者ガイドを参照してください
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
に付与できます。
関連項目:
-
CDBでロールおよび権限を付与する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
プロキシ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
表領域に属すデータ・ファイルのみがコピーされます。
例19-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の作成方法の詳細は、『Oracle Database管理者ガイド』を参照
PDBの名前
CDB内のコンテナは同じネームスペースを共有します。つまり、このネームスペース内では一意の名前を保持する必要があります。
次のコンテナの名前は同じCDB内で競合しないことが必要です。
-
CDBルート
-
CDBルートに接続されているPDB
-
アプリケーション・ルート
-
アプリケーションPDB
たとえば、同じCDBにアプリケーション・コンテナsaas_sales_ac
とsaas_sales_test_ac
が含まれる場合、両方ともcust1
と名付けられた2つのアプリケーションPDBが両方のコンテナに同時に存在することはできません。このネームスペース・ルールではCDBルートでのcust1pdb
というPDBの作成と、アプリケーション・ルートでのcust1pdb
というPDBの作成も妨げられます。
PDBとアプリケーション・ルート・コンテナは、サービス名と同じネーミング・ルールに従う必要があります。さらに、PDBまたはアプリケーション・ルートは独自の名前のサービスを持つため、コンテナ名は、特定のリスナーを介して公開されるサービスを所有するすべてのCDBにわたって一意にする必要があります。ユーザー作成のコンテナ名は最初の文字を英数字にし、それ以降の文字を英数字またはアンダースコア(_
)にする必要があります。サービス名には大文字小文字の区別がないため、コンテナ名にも大文字と小文字の区別はなく、区切り識別子を使用して指定しても、大文字になります。
関連項目:
-
サービス名のルールの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
-
PDBの作成準備の詳細は、Oracle Database管理者ガイドを参照してください
PDB間のデータベース・リンク
デフォルトで、あるPDBに接続しているユーザーが、別のPDBのオブジェクトにアクセスするには、データベース・リンクを使用する必要があります。この動作は、まさに別の非CDBのオブジェクトにアクセスする非CDBのユーザーに似ています。
図19-1 PDB間のデータベース・リンク
この図で、PDB管理者はhrpdb1
というPDBに接続されています。デフォルトで、このユーザー・セッション中に、c##dba
がデータベース・リンクを指定せずにhrpdb2
のemp2
表に問合せすることはできません。
「図19-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のオブジェクトにアクセスする方法の詳細は、Oracle Database管理者ガイドを参照してください
CDBのデータ・ディクショナリ・アーキテクチャ
ユーザーおよびアプリケーションから見て、CDBの各コンテナのデータ・ディクショナリは、非CDBの場合と同様に分かれています。
たとえば、各PDBのDBA_OBJECTS
ビューでは、異なる行数を表示できます。このようにディクショナリを分けることで、Oracle DatabaseではPDBを、お互いから別々に、そしてルートから管理できます。
データ・ディクショナリ分割の目的
まだユーザー・データが含まれていない新規に作成された非CDBでは、データ・ディクショナリにはシステム・メタデータのみが含まれています。たとえば、TAB$
表には、Oracle提供の表(TRIGGER$
およびSERVICE$
など)のみを説明する行が含まれます。
次の図は、3つの基礎的なデータ・ディクショナリ表で、赤い棒はシステムを説明する行を示しています。
ユーザーがこの非CDBに自身のスキーマおよび表を作成する場合、データ・ディクショナリにはOracle提供のエンティティを説明する行と、ユーザー作成エンティティを説明するその他の行が含まれます。たとえば、TAB$
ディクショナリ表には、employees
を説明する行とdepartments
を説明する行があります。
CDBでは、データ・ディクショナリ・メタデータは、ルートとPDBの間で分割されています。次の図では、employees
表とdepartments
表がPDB内に存在します。このユーザー・データのデータ・ディクショナリも、PDBに常駐します。したがって、PDBのTAB$
表には、employees
表の行とdepartments
表の行があります。
前図は、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$
ディクショナリ表の列定義は、ルートにしか存在しません。図19-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全体に関連するデータを含む表またはビューです。
コンテナ・データの権限は、複数のPDBが1つのCDBに存在する一般的な要件をサポートしますが、異なるローカル管理の要件があります。たとえば、ローカル管理を行わないアプリケーションDBAは、適切なビューに対するコンテナ・データの権限を共有ユーザーに付与できます。この場合、CDB管理者はこれらのPDBのデータにアクセスできます。これに対して、CDB管理者がデータにアクセスしないようにする必要があるPDB管理者は、コンテナ・データの権限を付与しません。
名前がV$
およびCDB_
で始まるOracle提供ビューは、コンテナ・データベース・オブジェクトの例です。すべてのコンテナ・データベース・オブジェクトには、CON_ID
列があります。次の表に、この列の値の意味を示します。
表19-1 コンテナID値
コンテナID | 関連行 |
---|---|
|
CDB全体、または非CDB |
|
|
|
|
その他すべてのID |
ユーザー作成のPDB、アプリケーション・ルートまたはアプリケーション・シード |
CDBでは、各DBA_
ビューに、対応するCDB_
ビューが存在します。CDB_
ビューの所有者は、対応するDBA_
ビューの所有者です。次の図は、異なるカテゴリのディクショナリ・ビューの間の関係を示しています。
現在のコンテナがPDBである場合、ユーザーは現在のPDBのデータ・ディクショナリ情報のみを表示できます。PDBに接続されているアプリケーションには、データ・ディクショナリが非CDBの場合と同様に表示されます。ただし、現在のコンテナがルートである場合、共通ユーザーは、ルートとこのユーザーが権限を持つPDBのメタデータを確認するために、CDB_
ビューに問い合せることができます。
注意:
ルート・コンテナから問合せされる際、CDB_
ビューおよびV$
ビューはデータをAL32UTF8キャラクタ・セットに暗黙的に変換します。AL32UTF8に変換される際にキャラクタ・セットで文字を表すためにバイト数がさらに必要な場合、そしてビューの列幅が特定のPDBのデータを収容できない場合、データの切捨てが可能です。
次の表に、CDB_
ビューの問合せを含むシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。
表19-2 CDB_ビューの問合せ
操作 | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
関連項目:
コンテナ・データ・オブジェクトの詳細は、Oracle Database管理者ガイドを参照してください
現在のコンテナ
指定されたセッションで、現在のコンテナは、セッションが実行されているコンテナです。現在のコンテナはCDBルート、アプリケーション・ルートまたはPDBになります。
各セッションには、任意の時点で現在のコンテナがそれぞれ1つのみ含まれます。各コンテナのデータ・ディクショナリは個別のため、Oracle Databaseでは、名前の解決と権限の認証に、現在のコンテナのデータ・ディクショナリを使用します。
関連項目:
現在のコンテナの詳細は、Oracle Database管理者ガイドを参照してください
コンテナ間操作
コンテナ間操作は、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
プロパティが使用されます。
例19-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自体)内または特定のアプリケーション・コンテナ内のいずれにも共通します。
たとえば、CDB$ROOT
への接続中に共通ユーザー・アカウントを作成した場合、このユーザー・アカウントはCDB内のすべてのPDBおよびアプリケーション・ルートにも共通です。しかし、アプリケーション・ルートへの接続中にアプリケーション共通ユーザー・アカウントを作成した場合、このユーザー・アカウントはこのアプリケーション・コンテナ内のPDBのみに共通です。
CDB$ROOT
またはアプリケーション・ルートのコンテキストにおける共通性の原則は、次のとおりです。
-
共通現象は、既存および将来のすべてのコンテナで同じになります。
したがって、CDBルートで定義された共通ユーザーはCDBルートに接続しているすべてのPDBで同じIDを持ち、アプリケーション・ルートで定義された共通ユーザーはこのアプリケーション・ルートに接続しているすべてのアプリケーションPDBで同じIDを持ちます。一方、ローカル現象は、厳密に既存の1つのコンテナをスコープとしています。
-
共通ユーザーのみが共通現象の存在を変更できます。
もっと正確に言えば、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の共通ユーザーおよびローカル・ユーザーの概要
ユーザー・アカウントがデータベースを定義するオブジェクトを所有する場合、このユーザー・アカウントは共通です。Oracle提供ではないユーザー・アカウントはローカルまたは共通のいずれかです。
CDB共通ユーザーは、CDBルートで作成される共通ユーザーです。アプリケーション共通ユーザーはアプリケーション・ルートで作成されるユーザーで、このアプリケーション・コンテナ内のみで共通です。
次の図は、CDBで使用可能なユーザー・アカウント・タイプを示しています。
CDB共通ユーザーは、十分な権限を持つCDB内の任意のコンテナに接続できます。対照的に、アプリケーション共通ユーザーは(権限に応じて)そのユーザーが作成されたアプリケーション・ルートまたはこのアプリケーション・ルートに接続しているPDBのみに接続できます。
関連項目:
共通ユーザーおよびローカル・ユーザーの概要は、Oracle Databaseセキュリティ・ガイドを参照してください
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共通ユーザーまたはアプリケーション共通ユーザーのいずれかです。
図19-7に、2つのPDB(hrpdb
とsalespdb
)のユーザーとスキーマの例を示します。SYS
とc##dba
は、CDB$ROOT
、hrpdb
およびsalespdb
にスキーマを持つCDB共通ユーザーです。ローカル・ユーザーhr
とrep
は、hrpdb
に存在します。ローカル・ユーザーhr
とrep
は、salespdb
にも存在します。
共通ユーザーには、次の特徴があります。
-
共通ユーザーは、
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にも接続できます。
関連項目:
-
共通ユーザー・アカウントの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
-
COMMON_USER_PREFIX
の詳細は、Oracle Databaseリファレンスを参照してください
CDBのローカル・ユーザー
ローカル・ユーザーとは、共通ではなく、1つのPDBでのみ操作が可能なデータベース・ユーザーです。
ローカル・ユーザーには、次の特徴があります。
-
ローカル・ユーザーは、特定のPDBに固有であり、このPDB内でスキーマを所有できます。
図19-7では、
hrpdb
上のローカル・ユーザーhr
がhr
スキーマを所有しています。salespdb
では、ローカル・ユーザーrep
がrep
スキーマを、ローカル・ユーザーhr
がhr
スキーマを所有しています。 -
ローカル・ユーザーは、PDBのオープンとクローズも含めて、PDBを管理できます。
SYSDBA
権限を持つ共通ユーザーは、ローカル・ユーザーにSYSDBA
権限を付与できます。この場合、権限を付与されたユーザーはローカルのままです。 -
あるPDBのローカル・ユーザーは、別のPDBやCDBルートにログインできません。
たとえば、ローカル・ユーザー
hr
がhrpdb
に接続する場合、hr
は、データベース・リンクを使用せずに、salespdb
データベースに常駐するsh
スキーマのオブジェクトにアクセスすることはできません。同様に、ローカル・ユーザーsh
がsalespdb
PDBに接続する場合、sh
は、データベース・リンクを使用せずに、hrpdb
に存在するhr
スキーマのオブジェクトにアクセスすることはできません。 -
ローカル・ユーザーには、
c##
またはC##
の文字で始まる名前を付けることはできません。 -
ローカル・ユーザーの名前は、PDB内でのみ一意である必要があります。
ユーザー名とそのユーザーのスキーマが含まれているPDBにより、一意のローカル・ユーザーが決まります。図19-7では、
rep
というローカル・ユーザーおよびスキーマがhrpdb
に存在します。rep
という完全に独立したローカル・ユーザーとスキーマが、salespdb
PDBに存在します。
次の表で、図19-7のCDBに関連したシナリオを説明します。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEM
が、2つのPDBでローカル・ユーザーを作成します。
表19-3 CDBのローカル・ユーザー
操作 | 説明 |
---|---|
SQL> CONNECT SYSTEM@hrpdb Enter password: ******** Connected. |
|
SQL> CREATE USER rep IDENTIFIED BY password;
User created.
SQL> GRANT CREATE SESSION TO rep;
Grant succeeded. |
|
SQL> CONNECT rep@salespdb Enter password: ******* ERROR: ORA-01017: invalid username/password; logon denied |
|
SQL> CONNECT SYSTEM@salespdb Enter password: ******** Connected. |
|
SQL> CREATE USER rep IDENTIFIED BY password;
User created.
SQL> GRANT CREATE SESSION TO rep;
Grant succeeded. |
|
SQL> CONNECT rep@salespdb Enter password: ******* Connected. |
|
関連項目:
ローカル・ユーザー・アカウントの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CDBの共通ロールおよびローカル・ロールの概要
Oracle提供ロールは、例として事前定義DBA
ロールのように、すべて共通です。Oracle提供のスクリプトでは、Oracle提供のユーザーおよびロールに付与されるすべての権限またはロールは共通に付与されますが、例外は、システム権限が共通ロール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全体になります。アプリケーション・ルート内でロールを定義すると、そのスコープはアプリケーション・コンテナになります。
関連項目:
-
「コンテナ間操作」
-
共通ロールの管理方法の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
-
CREATE ROLE
文の詳細は、Oracle Database SQL言語リファレンスを参照してください
CDBのローカル・ロール
非CDBのロールが非CDBにのみ存在するのと同様に、ローカル・ロールは単一のPDBにのみ存在します。
ローカル・ロールには、そのロールが存在するコンテナで適用されるロールおよび権限のみを含めることができます。たとえば、hrpdb
でローカル・ロールpdbadmin
を作成した場合、このロールのスコープはこのPDBに制限されます。
同じCDB、または同じアプリケーション・コンテナのPDBには、同じ名前のローカル・ロールが含まれる場合があります。たとえば、ユーザー作成のロールpdbadmin
は、hrpdb
とsalespdb
のどちらにも存在する可能性があります。しかし、これらのロールは、別々の非CDBにあるかのように、互いにまったく関係ありません。
関連項目:
ローカル・ロールの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CDBでの権限およびロール付与の概要
非CDBと同様に、ロールと権限をCDB内のユーザーが付与することも、CDB内のユーザーに付与することもできます。ただし、CDB内のロールおよび権限は、ローカルに付与されたものか、共通に付与されたもののいずれかです。
ローカルに付与された権限またはロールは、それが付与されたPDBでのみ実行可能です。共通に付与された権限またはロールは、付与された対象のコンテナ(CDBまたはアプリケーション・コンテナ)の既存および将来のどのPDBにおいても実行可能です。
ユーザーおよびロールは、共通の場合もローカルの場合もあります。ただし、権限は、それ自体は共通でもローカルでもありません。ユーザーがCONTAINER=CURRENT
句を使用してローカルに権限を付与した場合、権限受領者は現行コンテナ内でのみ実行可能な権限を持ちます。ユーザーがCDBルートまたはアプリケーション・ルートのいずれかに接続している場合、そしてこのユーザーがCONTAINER=ALL
句を使用して共通に権限を付与した場合、権限受領者は現在のコンテナ内の既存または将来のPDBでこの権限を持ちます。
関連項目:
共通権限の管理方法の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
CDBにおける権限およびロールの付与の原則
CDBでは、付与の行為は、ローカルか共通かに関係なく、すべてコンテナの内部で起こります。コンテナはCDBルート、アプリケーション・ルートまたはPDBになります。
現在のコンテナがCDBルートの場合、共通に付与することはCDBのすべてのコンテナに付与することを意味します。しかし、現在のコンテナがアプリケーション・ルートの場合、共通に付与することは現在のアプリケーション・コンテナのすべてのPDBに付与することを意味します。
付与の基本原則は、次のとおりです。
-
共通およびローカルのどちらの現象も、ローカルに付与および受領できます。
-
共通に付与または受領できるのは、共通の現象のみです。
ローカルのユーザー、ロールおよび権限は、本質的に特定のPDBに限定されます。したがって、ローカル・ユーザーは、共通のロールおよび権限を付与することはできず、ローカルのロールおよび権限は共通に付与されることはありません。
次の各項では、前述の原則の意味を説明します。
CDBでローカルに付与される権限およびロール
ロールおよび権限は、受領者、付与者または付与されるロールがローカルか共通かに関係なく、ユーザーおよびロールにローカルに付与できます。
次の表では、ローカルに付与されたロールおよび権限の有効な可能性について説明します。
表19-4 ローカルな付与
現象 | ローカルな付与が可能 | ローカルな受領が可能 | ローカルに付与されたロールまたは権限の受領が可能 |
---|---|---|---|
共通ユーザー |
はい |
N/A |
はい |
ローカル・ユーザー |
はい |
N/A |
はい |
共通ロール |
N/A |
はい脚注 1 |
はい |
ローカル・ロール |
N/A |
はい脚注 2 |
はい |
権限 |
N/A |
はい |
N/A |
脚注1
このロールでの権限は、権限がロールにローカルに付与されたか共通に付与されたかに関係なく、被付与者にとってロールが付与されたコンテナでのみ使用可能です。
脚注2
このロールでの権限は、被付与者にとってロールが付与され作成されたコンテナでのみ使用可能です。
ロールまたは権限がローカルに付与される条件
ロールまたは権限をローカルに付与するには、CONTAINER=CURRENT
句(デフォルト)を含むGRANT
文を使用します。
具体的には、次の条件を満たした場合にのみ、ロールまたは権限がローカルに付与されます。
-
付与者に、指定したロールまたは権限を付与するために必要な権限がある。
システム・ロールまたは権限の場合、付与者には付与するロールまたは権限に対する
ADMIN OPTION
が必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTION
が必要です。 -
付与は1つのコンテナに対してのみ適用される。
GRANT
文には、権限またはロールがローカルに付与されることを示すCONTAINER=CURRENT
句がデフォルトで含まれています。
例19-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セキュリティ・ガイドを参照してください
ローカルに付与されるロールおよび権限
ユーザーまたはロールは、ローカルに付与された権限である可能性があります(CONTAINER=CURRENT
)。
たとえば、hrpdb
のローカルまたは共通ユーザーに対してローカルに付与されたREAD ANY TABLE
権限は、この PDB内のこのユーザーに対してのみ適用されます。同様に、非CDBのユーザーhr
に付与されたREAD ANY TABLE
権限は、別の非CDBに存在するhr
ユーザーの権限には何の関係もありません。
ユーザーまたはロールは、ローカルに付与されたロールである可能性があります(CONTAINER=CURRENT
)。表19-4に示すように、共通ロールは、ローカルに付与される権限を受領する可能性があります。たとえば、共通ロールc##dba
は、hrpdb
でREAD ANY TABLE
権限をローカルに付与される可能性があります。c##cdb
共通ロールがローカルに付与されると、そのロールの権限は、ロールの付与先のコンテナでのみ適用されます。この例では、c##cdba
ロールを持つ共通ユーザーは、権限がこのロールに対してhrpdb
でローカルに付与されたものであるため、この権限をhrpdb
以外のどのPDBでも実行する権利はありません。
関連項目:
CDBでロールおよび権限を付与する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CDBで共通に付与されるロールおよび権限
権限および共通ロールは、共通に付与される可能性があります。
ユーザー・アカウントまたはロールに対してロールおよび権限を共通に付与できるのは、権限受領者と権限付与者がどちらも共通である場合のみです。ロールを共通に付与する場合は、そのロール自体が共通である必要があります。次の表では、共通の付与の可能性について説明します。
表19-5 共通の付与
現象 | 共通の付与が可能 | 共通の受領が可能 | 共通に付与されたロールおよび権限の受領が可能 |
---|---|---|---|
共通ユーザー・アカウント |
はい |
N/A |
はい |
ローカル・ユーザー・アカウント |
いいえ |
N/A |
いいえ |
共通ロール |
N/A |
はい脚注 3 |
はい |
ローカル・ロール |
N/A |
いいえ |
いいえ |
権限 |
N/A |
はい |
N/A |
脚注3
共通ロールに共通に付与された権限は、すべてのコンテナで被付与者が使用できます。さらに、共通ロールに対してローカルに付与された権限はどれも、その権限が共通ロールに付与されたコンテナでのみ、被付与者が使用できます。
関連項目:
共通の付与の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
付与が共通になる条件
CONTAINER=ALL
句は、権限またはロールが共通に付与されることを指定します。
ロールまたは権限は、次の条件を満たしたとき、共通に付与されます。
-
付与者は、共通ユーザーである。
付与を実行するユーザーは、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。
-
被付与者は、共通ユーザーまたは共通ロールである。
付与の受領者は、CDB自体または特定のアプリケーション・コンテナのいずれかに共通します。
-
付与者に、指定したロールまたは権限を付与するために必要な権限がある。
システム・ロールまたは権限の場合、付与者には付与するロールまたは権限に対する
ADMIN OPTION
が必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTION
が必要です。 -
付与は、付与が発生したコンテナ(CDBまたはアプリケーション・コンテナのいずれか)内のすべてのPDBに適用されます。
GRANT
文には、権限またはロールが共通に付与されることを指定するCONTAINER=ALL
句が含まれます。 -
ロールが付与される場合、それは共通であり、オブジェクト権限が付与される場合は、権限が付与される対象のオブジェクトが共通であることが必要。
例19-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セキュリティ・ガイドを参照してください
共通に付与されるロールおよび権限
共通ユーザー・アカウントまたはロールには、権限を共通に付与できます(CONTAINER=ALL
)。
CDBルートまたはアプリケーション・ルートのいずれかのコンテキスト内で、現在のコンテナ内の既存および将来のすべてのPDBにおいて、権限がこの共通ユーザー・アカウントまたはロールに付与されます。たとえば、SYSTEM
がCDBルートに接続して、SELECT ANY TABLE
権限をCDB共通ユーザー・アカウントc##dba
に共通に付与した場合、ユーザーc##dba
はCDBのすべてのPDBでこの権限を保持します。共通に付与されたロールまたは権限をローカルに取り消すことはできません。
ユーザーまたはロールは、共通に付与された共通ロールを受領する可能性があります。表19-5の脚注で言及されているように、共通ロールは、ローカルに付与された権限を受領できます。したがって、共通ユーザーには共通ロールを付与でき、このロールにはローカルに付与された権限が含まれる可能性があります。
たとえば、共通ロールc##admin
は、hrpdb
に対してローカルなSELECT ANY TABLE
権限を付与される可能性があります。共通ロールでローカルに付与された権限は、その権限が付与されたコンテナでのみ適用されます。したがって、c##admin
ロールを持つ共通ユーザーには、salespdb
またはhrpdb
以外のどのPDBでも、hrpdb
に含まれる権限を実行する権利はありません。
関連項目:
CDBでロールおよび権限を付与する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
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セキュリティ・ガイド』を参照してください。
権限およびロールの付与: シナリオ
このシナリオでは、SYSTEM
は共通ユーザーc##dba
を作成し、hrpdb
のhr
スキーマで表を問い合せるためにこのユーザー権限を付与しようとします。
このシナリオは、CONTAINER
句がロールおよび権限の付与にどのような影響を与えるかを示しています。最初の列には、CDB$ROOT
での操作が示されています。2番目の列には、hrpdb
での操作が示されています。
表19-6 CDBのロールおよび権限の付与
t | CDB$ROOTでの操作 | hrpdbでの操作 | 説明 |
---|---|---|---|
t1 |
|
N/A |
共通ユーザー |
t2 |
|
N/A |
|
t3 |
|
N/A |
|
t4 |
|
N/A |
|
t5 |
|
N/A |
|
t6 |
|
N/A |
|
t7 |
N/A |
|
|
t8 |
N/A |
|
|
t9 |
N/A |
|
|
t10 |
N/A |
|
共通ユーザー |
t11 |
N/A |
|
|
t12 |
|
N/A |
共通ユーザー |
t13 |
|
N/A |
|
t14 |
N/A |
|
|
t15 |
|
N/A |
|
t17 |
N/A |
|
問合せに成功します。 |
関連項目:
共通ロールおよびローカル・ロールの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CDBの共通オブジェクトおよびローカル・オブジェクトの概要
共通オブジェクトは、CDBルートまたはアプリケーション・ルートのいずれかで定義されており、メタデータ・リンクまたはオブジェクト・リンクを使用して参照できます。ローカル・オブジェクトは、共通オブジェクトではないすべてのオブジェクトです。
データベースによって提供される共通オブジェクトは、CDB$ROOT
で定義されており、変更できません。Oracle Databaseでは、CDB$ROOT
での共通オブジェクトの作成はサポートされていません。
アプリケーション・ルートでは、表、ビュー、PL/SQLおよびJavaプログラム・ユニット、順序などのほとんどのスキーマ・オブジェクトを共通オブジェクトとして作成できます。オブジェクトがアプリケーション・ルートに存在する場合、それはアプリケーション共通オブジェクトと呼ばれます。
ローカル・ユーザーは共通オブジェクトを所有できます。また、共通ユーザーはローカル・オブジェクトを所有できますが、これはオブジェクトがデータリンクまたはメタデータリンクされてなく、なおかつメタデータ・リンクでもデータ・リンクでもない場合のみです。
関連項目:
-
アプリケーション共通オブジェクトの詳細は、Oracle Database管理者ガイドを参照してください
-
共通オブジェクトの権限管理の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
共通監査構成の概要
混合モードと統合監査のどちらの場合も、共通監査構成が表示され、すべてのPDBにわたって実行されます。
監査構成は、ローカルまたは共通のいずれかです。他のローカルまたは共通現象(ユーザーやロールなど)に適用されるすべてのスコープ指定ルールが、監査構成にも適用されます。
注意:
監査初期化パラメータは、CDBレベルに存在し、各PDBには存在しません。
PDBでは、次の監査オプションがサポートされます。
-
オブジェクト監査
オブジェクト監査とは、特定のオブジェクトに対する監査構成のことを指します。共通監査構成に含めることができるのは、共通オブジェクトのみです。ローカル監査構成には、共通オブジェクトを含めることはできません。
-
監査ポリシー
監査ポリシーは、ローカルまたは共通のいずれかです。
-
ローカル監査ポリシー
ローカル監査ポリシーは、1つのPDBに適用されます。ローカル監査ポリシーは、このPDBのみのローカルおよび共通ユーザーに対して実行できます。ローカル監査ポリシーをすべてのコンテナにわたって実行しようとすると、エラーが発生します。
いかなる場合でも、ローカル監査ポリシーの実行は、ローカル監査フレームワークの一部です。
-
共通監査ポリシー
共通監査ポリシーは、すべてのコンテナに対して適用されます。このポリシーには、アクション、システム権限、共通ロールおよび共通オブジェクトのみを含めることができます。共通監査ポリシーは、共通ユーザーに対してのみ適用できます。ローカル・ユーザーに対する共通監査ポリシーをすべてのコンテナにわたって実行しようとすると、エラーが発生します。
-
共通監査構成は、ルートのSYS
スキーマに格納されています。ローカル監査構成は、適用対象のPDBのSYS
スキーマに格納されています。
監査証跡は、関連PDBのSYS
またはAUDSYS
スキーマに格納されています。オペレーティング・システムおよびPDBのXML監査証跡は、AUDIT_FILE_DEST
初期化パラメータで指定されたディレクトリのサブディレクトリに格納されています。
関連項目:
-
「データベース監査」
-
共通監査構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
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への接続を制限できます。
PDB_LOCKDOWN
初期化パラメータによって、指定されたPDBに適用されるPDBロックダウン・プロファイルが決まります。ロックダウン・プロファイルを作成および変更するには、ルートへの接続時にSQL文を発行します。
ロックダウン・プロファイルは、PDB_LOCKDOWN
初期化パラメータを使用して指定します。このパラメータを設定できるのは、設定されたPDBのみにプロファイルが適用されるPDBレベルか、すべてのPDBにプロファイルが適用されるCDBレベルのいずれかです。共通のSYSDBA
権限または共通のALTER SYSTEM
権限を持つ共通ユーザーは、特定のPDBに対するCDB全体の設定をオーバーライドできます。
例19-6 PDBロックダウン・プロファイルの作成
この例では、SYSDBA
権限を持つ共通ユーザーとして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
には設定できません。
注意:
-
PDBロックダウン・プロファイルの詳細は、Oracle Database管理者ガイドを参照してください
-
PDBロックダウン・プロファイルの作成、有効化および削除方法の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
アプリケーション・コンテナ内のアプリケーションの概要
アプリケーション・コンテナ内で、アプリケーションはアプリケーション・ルートに格納される共通データおよびメタデータの名前付けおよびバージョニングされたセットです。
このアプリケーション・コンテナのコンテキストでは、「アプリケーション」という用語は「マスター・アプリケーション定義」を意味します。たとえば、表、ビュー、パッケージなどの定義をアプリケーションに含めることができます。
この項では、次の項目について説明します。
関連項目:
-
アプリケーション共通オブジェクトの詳細は、「CDBの共通オブジェクトおよびローカル・オブジェクトの概要」を参照してください
-
アプリケーション・コンテナの管理方法の詳細は、Oracle Database管理者ガイドを参照してください
アプリケーション・コンテナについて
アプリケーション・コンテナはオプションのユーザー作成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のスコープ内で一意にする必要があります。すべてのアプリケーション・コンテナに、アプリケーション・コンテナと同じ名前のデフォルト・サービスがあります。
関連項目:
-
アプリケーション・コンテナの作成および削除方法の詳細は、Oracle Database管理者ガイドを参照してください
アプリケーション・コンテナの目的
アプリケーション・コンテナはある意味で、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で使用できます。
純粋な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には表示されません。
関連項目:
アプリケーション・コンテナの作成方法の詳細は、『Oracle Database管理者ガイド』を参照
例19-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の作成方法の詳細は、『Oracle Database管理者ガイド』を参照
アプリケーション・シード
アプリケーション・シードはアプリケーション・コンテナ内のオプションのユーザー作成PDBです。アプリケーション・コンテナにはゼロまたは1つのアプリケーション・シードが含まれます。
アプリケーション・シードを使用すると、アプリケーションPDBを簡単に作成できます。これはアプリケーション・コンテナ内で、CDBシードがCDB内で果たす役割と同じ役割を果たします。
アプリケーション・シード名は常にapplication_container_name$SEED
となり、application_container_name
はアプリケーション・コンテナの名前を表します。たとえば、CREATE PDB ... AS SEED
文を使用して、saas_sales_ac
アプリケーション・コンテナにsaas_sales_ac$SEED
を作成します。
関連項目:
アプリケーション・シードの作成方法の詳細は、『Oracle Database管理者ガイド』を参照
アプリケーション共通オブジェクト
アプリケーション共通オブジェクトは、アプリケーション・ルートのアプリケーション内で作成される共通オブジェクトです。共通オブジェクトはデータリンクされているか、メタデータリンクされているかのいずれかです。
データリンク共通オブジェクトの場合、アプリケーションPDBは単一のデータのセットを共有します。たとえば、saas_sales_ac
アプリケーション・コンテナのアプリケーションがsaas_sales_app
という名前で、バージョンが1.0
であり、データリンクされたusa_zipcodes
表を含むとします。この場合、行はアプリケーション・ルート内の表に1回のみ格納されますが、すべてのアプリケーションPDBで表示されます。
メタデータリンク共通オブジェクトの場合、アプリケーションPDBはメタデータのみを共有しますが、異なるデータのセットが含まれます。たとえば、メタデータリンクされたproducts
表はあらゆるアプリケーションPDBで同じ定義を持ちますが、行自体はPDBに固有です。cust1pdb
というアプリケーションPDBには書籍を格納するproducts
表があり、cust2pdb
というアプリケーションPDBには自動車部品を格納するproducts
表がある場合があります。
関連項目:
-
共通オブジェクトの詳細は、「CDBの共通オブジェクトおよびローカル・オブジェクトの概要」を参照
-
アプリケーション共通オブジェクトの詳細は、Oracle Database管理者ガイドを参照してください
アプリケーション共通オブジェクトの作成
共通オブジェクトを作成するには、アプリケーション・ルートに接続してから、共有属性を指定するCREATE
文を実行します。
アプリケーション共通オブジェクトを作成または変更できるのは、アプリケーションのインストール、アップグレードまたはパッチ適用の一環である場合のみです。共有は次の方法で指定できます。
-
DEFAULT_SHARING
初期化パラメータ設定は、ルートで作成されたサポート対象タイプのすべてのデータベース・オブジェクトに対するデフォルト共有属性です。
-
SHARING
句この句は、
CREATE
文自体で指定します。SHARING
句がSQL文に含まれる場合、これはDEFAULT_SHARING
初期化パラメータで指定された値よりも優先されます。指定できる値は、METADATA
、DATA
、EXTENDED DATA
およびNONE
です。
次の表は、アプリケーション共通オブジェクトのタイプと、データおよびメタデータの格納場所を示しています。
表19-7 アプリケーション共通オブジェクト
オブジェクト・タイプ | SHARING値 | メタデータ記憶域 | データ記憶域 |
---|---|---|---|
データリンク | DATA |
アプリケーション・ルート | アプリケーション・ルート |
拡張データリンク | EXTENDED DATA |
アプリケーション・ルート | アプリケーション・ルートおよびアプリケーションPDB |
メタデータリンク | METADATA |
アプリケーション・ルート | アプリケーションPDB |
関連項目:
-
アプリケーション共通オブジェクトの作成方法の詳細は、『Oracle Database管理者ガイド』を参照
-
共通オブジェクトの権限を管理する方法の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
メタデータリンク・アプリケーション共通オブジェクト
メタデータ・リンクは、アプリケーション・コンテナ内のすべてのPDBによって共有される共通メタデータの参照および権限付与をサポートするディクショナリ・オブジェクトです。
METADATA
値をSHARING
句またはDEFAULT_SHARING
初期化パラメータのいずれかで指定すると、メタデータリンク共通オブジェクトと呼ばれるオブジェクトのメタデータへのリンクが指定されます。オブジェクトのメタデータは、アプリケーション・ルートに1回のみ格納されます。
表、ビュー、およびコード・オブジェクト(PL/SQLプロシージャなど)はメタデータを共有できます。このコンテキストでの「メタデータ」には、列定義、制約、トリガーおよびコードが含まれています。たとえば、sales_mlt
がメタデータリンクされた共通表の場合、すべてのアプリケーションPDBがメタデータ・リンクによってこの表の同じ定義(これはアプリケーション・ルートに格納されています)にアクセスします。sales_mlt
の行はすべてのアプリケーションPDBで異なりますが、列定義は同じです。
一般に、アプリケーションのほとんどのオブジェクトはメタデータリンクされます。したがって、1つのマスター・アプリケーション定義を保持するのみで済みます。この方法により、複数のアプリケーションPDB内のアプリケーションの管理が集中化されます。
例19-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
でこの表のコピーに行を追加します。アプリケーション・ルートに格納される表メタデータのみが共有されます。
注意:
-
メタデータリンク共通オブジェクトの詳細は、『Oracle Database管理者ガイド』を参照
-
共通に付与されるオブジェクト権限の使用方法の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください
メタデータ・リンク
メタデータリンク・アプリケーション共通オブジェクトの場合、オブジェクトのメタデータはアプリケーション・ルートに1回格納されます。メタデータ・リンクは、共有しているメタデータと同じオブジェクト・タイプのディクショナリ・オブジェクトです。
メタデータ・リンクの説明は、それが作成されたPDBのデータ・ディクショナリに格納されます。メタデータ・リンクは、アプリケーション共通ユーザーによって所有されている必要があります。CDBルートまたはアプリケーション・ルートで、その作成者によって所有される共通オブジェクトのメタデータを共有するには、メタデータ・リンクのみを使用できます。
データ・リンクと異なり、メタデータ・リンクは共通データのみに依存します。たとえば、アプリケーションでローカル表dow_close_lt
およびnasdaq_close_lt
がアプリケーション・ルートに含まれる場合、共通ユーザーはこれらのオブジェクトへのメタデータ・リンクを作成できません。しかし、sales_mlt
というアプリケーション共通表はメタデータリンクできます。
権限を持つ共通ユーザーが表に列を追加するなどしてsales_mlt
のメタデータを変更した場合、この変更はメタデータ・リンクに伝播されます。アプリケーションPDBユーザーはメタデータ・リンクのメタデータを変更しない場合があります。たとえば、cust1_pdb
というアプリケーションPDBを管理するDBAは、このPDBのみのsales_mlt
に列を追加できません。このようなメタデータの変更はアプリケーション・ルートのみで行われるためです。
関連項目:
メタデータリンク共通オブジェクトの詳細は、『Oracle Database管理者ガイド』を参照
データリンク・アプリケーション共通オブジェクト
データリンク・オブジェクトは、そのメタデータおよびデータがアプリケーション・ルートに存在し、このアプリケーション・コンテナのすべてのアプリケーションPDBからアクセスできるオブジェクトです。
DATA
値をSHARING
句またはDEFAULT_SHARING
初期化パラメータのいずれかで指定すると、データリンク共通オブジェクトと呼ばれる共通オブジェクトへのリンクが指定されます。データ・ウェアハウスのディメンション表はほとんどの場合、データリンク共通表の適切な候補です。
データ・リンクは、ほとんどシノニムのように機能するディクショナリ・オブジェクトです。たとえば、countries
がアプリケーション共通表の場合、すべてのアプリケーションPDBがデータ・リンクによってこの表の同じコピーにアクセスします。ある行がこの表に追加されると、この行はすべてのアプリケーションPDBで表示可能です。
データ・リンクは、アプリケーション共通ユーザーによって所有されている必要があります。リンクはそれが示しているオブジェクトからオブジェクト・タイプを継承します。データ・リンクの説明は、それが作成されたPDBのデータ・ディクショナリに格納されます。たとえば、アプリケーション・コンテナに10個のアプリケーションPDBが含まれ、すべてのPDBにcountries
アプリケーション共通表へのリンクが含まれる場合、10個のPDBすべてにこのリンクのディクショナリ定義が含まれます。
例19-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
データリンク表へのデータ・リンクが作成されます。
注意:
データリンク共通オブジェクトの詳細は、Oracle Database管理者ガイドを参照してください
拡張データリンク・アプリケーション・オブジェクト
拡張データリンク・アプリケーション・オブジェクトは、データリンク・オブジェクトとメタデータリンク・オブジェクトを合成したものです。
拡張データリンク・オブジェクトでは、アプリケーション・ルートに格納されたデータはすべてのアプリケーションPDBに共通で、すべてのPDBがこのデータにアクセスできます。ただし、アプリケーション・ルートの共通データを共有すると同時に、各アプリケーションPDBは独自のPDB固有データを作成できます。このように、PDBはその固有データで共通データを補完します。
たとえば、販売アプリケーションでいくつかのアプリケーションPDBをサポートする場合があります。すべてのアプリケーションPDBで米国の郵便番号が必要です。この場合、アプリケーション・ルートでzipcodes_edt
拡張データリンク表を作成できます。アプリケーション・ルートが米国の郵便番号を格納するため、すべてのアプリケーションPDBがこのデータにアクセスできます。ただし、1つのアプリケーションPDBでは米国およびカナダの郵便番号が必要です。このアプリケーションPDBは、カナダの郵便番号をアプリケーション・ルートではなくアプリケーションPDB内の拡張データリンク・オブジェクトに格納できます。
拡張データリンク・オブジェクトを作成するには、アプリケーション・ルートに接続して、CREATE
文にSHARING=EXTENDED DATA
キーワードを指定します。
例19-10 拡張データ・オブジェクトの作成
この例では、SYSTEM
がsaas_sales_ac
アプリケーション・コンテナに接続し、(「例19-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
に挿入された郵便番号を参照できますが、独自の郵便番号をこの表に挿入することもできます。
注意:
拡張データリンク・オブジェクトの詳細は、Oracle Database管理者ガイドを参照してください
アプリケーション・メンテナンス
このコンテキストにおけるアプリケーション・メンテナンスは、アプリケーションのインストール、アンインストール、アップグレードまたはパッチ適用を指します。
アプリケーションには名前およびバージョン番号が必要です。このプロパティの組合せによって、実行可能なメンテナンス作業が決まります。すべてのメンテナンス作業で、次の手順を実行します。
-
ALTER PLUGGABLE DATABASE ... APPLICATION
文をBEGIN INSTALL
句、BEGIN UPGRADE
句またはBEGIN PATCH
句とともに実行することで開始します。 -
文を実行してアプリケーションを変更します。
-
ALTER PLUGGABLE DATABASE ... APPLICATION
文をEND INSTALL
句、END UPGRADE
句またはEND PATCH
句とともに実行することで終了します。
アプリケーションの発展に伴って、アプリケーション・コンテナではバージョンおよびパッチの変更がすべて保守されます。
注意:
アプリケーションの管理方法の詳細は、Oracle Database管理者ガイドを参照してください
アプリケーション・メンテナンスについて
ALTER PLUGGABLE DATABASE APPLICATION
文を使用して、アプリケーションのインストール、アップグレードおよびパッチ適用操作を実行します。
アプリケーション・メンテナンスの基本的な手順は、次のとおりです。
-
アプリケーション・ルートにログインします。
-
アプリケーション・ルートで
ALTER PLUGGABLE DATABASE APPLICATION ... BEGIN
文を使用して操作を開始します。 -
アプリケーション・メンテナンスの文を実行します。
-
ALTER PLUGGABLE DATABASE APPLICATION ... END
文を使用して操作を終了します。
スクリプト、SQL文またはGUIツールを使用してメンテナンスを実行します。
関連項目:
アプリケーション・コンテナ内のアプリケーションのメンテナンスの詳細は、Oracle Database管理者ガイドを参照してください
アプリケーションのインストール
アプリケーションのインストールは、マスター・アプリケーション定義の初期作成操作です。通常のインストールではユーザー・アカウント、表およびPL/SQLパッケージが作成されます。
アプリケーションをインストールするには、ALTER PLUGGABLE DATABASE APPLICATION
文に次の項目を指定します。
-
アプリケーション名
-
アプリケーションのバージョン番号
例19-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固有の行を挿入できます。
関連項目:
-
アプリケーション・コンテナにアプリケーションをインストールする方法の詳細は、Oracle Database管理者ガイドを参照してください
アプリケーションのアップグレード
アプリケーションのアップグレードはインストールされたアプリケーションへの大規模な変更です。
通常、アップグレードではアプリケーションの物理アーキテクチャが変更されます。たとえば、アップグレードによって新規のユーザー・アカウント、表およびパッケージが追加されたり、既存のオブジェクトの定義が変更されます。
アプリケーションをアップグレードするには、ALTER PLUGGABLE DATABASE APPLICATION
文で次の項目を指定する必要があります。
-
アプリケーション名
-
古いアプリケーションのバージョン番号
-
新規のアプリケーションのバージョン番号
例19-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管理者ガイドを参照してください
アプリケーションのアップグレードの動作
アプリケーションのアップグレード中に、アプリケーションは引き続き使用可能です。この可用性を可能にするため、Oracle Databaseではアプリケーション・ルートがクローニングされます。
次の図で、アプリケーションのアップグレード・プロセスの概要を示します。
アップグレードは次のように実行されます。
-
初期の状態で、アプリケーション・ルートには特定のバージョンのアプリケーションがあります。
-
ユーザーは
ALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE
文を実行してから、アプリケーションのアップグレード文を発行します。アップグレード中にデータベースでは自動的に次の処理が実行されます。
-
アプリケーション・ルートをクローニングします
たとえば、
saas_sales_app
アプリケーションがアプリケーション・ルートでバージョン1.0である場合、クローンもバージョン1.0になります。 -
アプリケーションPDBをアプリケーション・ルート・クローンに示します
クローンは読取り専用モードです。アプリケーションはアプリケーションPDBに対して引き続き使用可能です。
-
-
ユーザーは
ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE
文を実行します。この段階で、アプリケーションPDBは依然としてアプリケーション・ルート・クローンを示しており、元のアプリケーション・ルートが新規バージョンになります。たとえば、
saas_sales_app
アプリケーションがアプリケーション・ルートでバージョン1.0である場合、アップグレードによってこれがバージョン2.0になります。ただし、アプリケーション・ルート・クローンはバージョン1.0のままです。 -
オプションで、
SYNC
句とともにALTER PLUGGABLE DATABASE APPLICATION
文を発行することで、ユーザーはアプリケーションPDBをアップグレード済のアプリケーション・ルートと同期化します。たとえば、同期後に、一部のアプリケーションPDBはバージョン2.0のアプリケーション・ルートに接続されます。ただし、アプリケーション・ルート・クローンでは、バージョン1.0のままでいることが必要なアプリケーションPDBや、バージョン1.0のアプリケーション・ルートに接続される新規のアプリケーションPDBが引き続きサポートされます。
関連項目:
-
アップグレードの動作の詳細は、Oracle Database管理者ガイドを参照してください
異なるバージョンのアプリケーション
異なるアプリケーションPDBが、異なるバージョンのアプリケーションを使用する場合があります。
たとえば、あるアプリケーションPDBにsaas_sales_app
のバージョン1.0があるとします。同じアプリケーション・コンテナの別のアプリケーションPDBには、このアプリケーションのバージョン2.0があります。
ユースケースとしては、異なる顧客に提供されたSaaSアプリケーションがあります。個々の顧客に各自のアプリケーションPDBがある場合、中にはアプリケーションをアップグレードするまでより長期間待機する顧客がいます。この場合、あるアプリケーションPDBでは最新バージョンのアプリケーションが使用されますが、他のアプリケーションPDBでは古いバージョンが使用される可能性があります。
関連項目:
異なるバージョンのアプリケーションの詳細は、Oracle Database管理者ガイドを参照してください
アプリケーション・パッチ
アプリケーション・パッチは、アプリケーションの小規模な変更です。
アプリケーションのパッチ適用の一般的な例として、バグ修正やセキュリティ・パッチがあります。パッチの内部では、新しいファンクションおよびパッケージが許可されます。
一般に、破壊的な操作は許可されません。たとえば、DROP
文や、列の削除またはデータ型の変更を行うALTER TABLE
文をパッチに含めることはできません。
Oracle Databaseのパッチ適用プロセスでOracle Databaseパッチで許可される操作の種類が制限されるのと同様、アプリケーションのパッチ適用プロセスではアプリケーション・パッチで許可される操作が制限されます。ある修正に「アプリケーション・パッチで操作がサポートされていません」というエラーを引き起こす操作が含まれる場合は、かわりにアプリケーションのアップグレードを実行してください。
注意:
他のアプリケーションのパッチ適用またはアップグレードが進行中の間は、アプリケーションのパッチ適用ができません。
アプリケーションにパッチを適用するには、ALTER PLUGGABLE DATABASE APPLICATION
文にアプリケーション名とパッチ番号を指定します。オプションで、アプリケーション最小バージョンを指定できます。
例19-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;
関連項目:
アプリケーションのパッチ適用方法の詳細は、Oracle Database管理者ガイドを参照してください
既存のアプリケーションの移行
PDBにインストールされているアプリケーションを、アプリケーション・ルートまたはアプリケーションPDBのいずれかに移行できます。
既存のアプリケーションを移行する一般的な理由として、次のものがあります。
-
インストール・プログラムを使用するアプリケーション
一部のアプリケーションは、スクリプトではなくインストール・プログラムを使用します。この場合は、新しいアプリケーション・ルートでインストール・プログラムを実行し、
DBMS_PDB_ALTER_SHARING
パッケージを使用してオブジェクトを適切な共有モード(METADATA
、DATA
またはEXTENDED DATA
)に設定します。この変更はルートからアプリケーションPDBに自動的に伝播します。Oracle Databaseによってインストールの文ログが作成されるため、前のアプリケーション・バージョンのPDBはアプリケーション・ルートに接続できます。 -
各PDBで別個に定義されたアプリケーション
一部のアプリケーションは各PDBで定義されますが、アプリケーション・コンテナが存在しません。この場合は、インストール・スクリプトを更新して適切な共有モードを設定できます。アプリケーション・ルートを作成し、このルートでマスター・アプリケーション定義を作成します。既存のPDBをアプリケーションPDBとして採用するには、そのPDBをアプリケーション・ルートに接続し、共通定義への参照を使用して定義全体を置き換えるSQLスクリプトを実行します。
たとえば、Oracle Database 12cリリース1 (12.1) CDBに接続中のPDBにインストールされているアプリケーションを、Oracle Database 12cリリース2 (12.2) CDBのアプリケーション・コンテナに移行できます。
関連項目:
既存アプリケーションの移行方法の詳細は、Oracle Database管理者ガイドを参照してください
暗黙的に作成されるアプリケーション
ユーザー作成アプリケーション以外に、アプリケーション・コンテナには暗黙的に作成されるアプリケーションも含まれます。
ALTER PLUGGABLE DATABASE BEGIN
文を最初に使用せずに、アプリケーション共通ユーザー操作がCONTAINER=ALL
句によって発行されると、アプリケーション・ルートでアプリケーションが暗黙的に作成されます。
アプリケーション共通ユーザー操作には、CREATE USER
文による共通ユーザーの作成や、ALTER USER
文による共通ユーザーの変更などの操作が含まれます。データベースによって暗黙的アプリケーションにAPP$guid
(guid
はアプリケーション・ルートのグローバル一意ID)という名前が自動的に付けられます。暗黙的アプリケーションは、アプリケーション・ルートが初めて開かれたときに作成されます。
関連項目:
暗黙的に作成されるアプリケーションの詳細は、Oracle Database管理者ガイドを参照してください
アプリケーションの同期化
アプリケーションPDB内で、同期化は、アプリケーション・ルートでの最新のバージョンおよびパッチへのユーザー始動のアプリケーションの更新です。
アプリケーションPDBに接続されているとき、SYNC
キーワードとともにALTER PLUGGABLE DATABASE APPLICATION
文を発行することでアプリケーションを同期化します。SYNC
の前にアプリケーション名を指定すると、指定されたアプリケーションのみがデータベースによって同期化されます。アプリケーション名を指定しないか、ALL SYNC
を指定した場合は、暗黙的に作成されたアプリケーションを含むすべてのアプリケーションがデータベースによって同期化されます。
注意:
アプリケーション・ルートへの接続中に、アプリケーションのインストール、アップグレードおよびパッチ適用の操作によって、変更がアプリケーションPDBに自動的には伝播されません。
例19-14 アプリケーションPDB内の特定のアプリケーションの同期化
次の文ではsaas_sales_app
というアプリケーションが、アプリケーション・ルートでの最新のアプリケーションの変更と同期化されます。
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
例19-15 アプリケーションPDB内の特定のアプリケーションとパッチの同期化
次の文では、saas_sales_app
というアプリケーションがアプリケーション・ルートのパッチ100と同期化されます。
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC TO PATCH 100;
関連項目:
アプリケーションの同期化の詳細は、Oracle Database管理者ガイドを参照してください
コンテナ・マップ
コンテナ・マップを使用することにより、アプリケーション・ルートに接続したセッションで発行した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')
のように、国の名前です。 -
-
コンテナ・マップ
コンテナ・マップは、マップ表を指定するデータベース・プロパティです。プロパティを設定するには、アプリケーション・ルートに接続して
ALTER PLUGGABLE DATABASE SET CONTAINER_MAP=map_table
文を実行します。map_table
はマップ表の名前を表します。
例19-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()
句を使用する必要があることを指定します。
例19-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;
例19-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別にパーティション化する方法の詳細は、Oracle Database管理者ガイドを参照してください
CDBのサービスの概要
クライアントは、サービスを使用してPDBまたはアプリケーション・ルートに接続する必要があります。
サービス名を使用した接続により、PDBまたはアプリケーション・ルートでは新規のセッションが開始されます。フォアグラウンド・プロセス、およびその結果のセッションは、ライフタイムの各時点で、一意に定義された現在のコンテナがあります。
次の図に、2つの異なるリスナーを使用してPDBに接続する2つのクライアントを示します。
関連項目:
PDBに関連付けられているサービスの管理方法の詳細は、Oracle Database管理者ガイドを参照してください
CDBのサービス作成
CREATE PLUGGABLE DATABASE
文を実行してPDBを作成すると、データベースではCDB内のサービスが自動的に作成されて起動されます。
このデフォルト・サービスには、PDBをサービスの最初の現行コンテナとして識別するプロパティがあります。このプロパティは、DBA_SERVICES.PDB
列に表示されます。
関連項目:
PDBに関連付けられているサービスの詳細は、Oracle Database管理者ガイドを参照してください
CDBのデフォルト・サービス
デフォルト・サービスの名前はPDBと同じになります。PDB名は、CDB内で一意となる有効なサービス名である必要があります。
アプリケーション・コンテナを作成する際、AS APPLICATION CONTAINER
句の指定が必要になると、Oracle Databaseではアプリケーション・ルートの新規のデフォルト・サービスが自動的に作成されます。サービスはアプリケーション・コンテナと同じ名前を持ちます。このサービスにアクセスするクライアントには、Oracle Net Serviceが正しく構成されている必要があります。同様に、すべてのアプリケーションPDBには固有のデフォルト・サービス名があり、アプリケーション・シードPDBには固有のデフォルト・サービス名があります。
例19-19 デフォルト・サービスを使用したPDBへの切替え
この例では、PDBと同じ名前を持つデフォルト・サービスを使用して、PDB名salespdb
に切り替えます。
ALTER SESSION SET CONTAINER = salespdb;
関連項目:
-
「サービス名」
-
PDBに関連付けられているサービスの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
CDBの非デフォルト・サービス
各PDBについて、CDBごとに上限10,000までの追加サービスを作成できます。各追加サービスでは、そのPDBが最初の現行コンテナとして表示されます。
図19-10では、erppdb
とhrpdb
にデフォルト以外のサービスが存在します。非CDBで使用するのと同じ方法で、サービスを作成、維持および削除します。
たとえば、図19-10では、hrpdb
というPDBには、hrpdb
というデフォルトのサービスがあります。デフォルト・サービスは削除できません。
ALTER SESSION SET CONTAINER
を使用してコンテナに切り替えると、コンテナのデフォルト・サービスがセッションで使用されます。オプションで、SERVICE = service_name
を指定することでコンテナに別のサービスを使用できます。service_name
はサービスの名前を表します。特定のサービスを使用することで、セッションがそのサービス属性および機能(サービス・メトリック、ロード・バランシング、Resource Manager設定など)を利用できるようにする場合があります。
例19-20 非デフォルト・サービスを使用したPDBへの切替え
この例では、hrpdb
のデフォルト・サービスによってすべてのサービス属性および機能(サービス・メトリック、FAN、ロード・バランシング、Oracle Database Resource Manager、トランザクション・ガード、アプリケーション・コンティニュイティなど)がサポートされるとはかぎりません。非デフォルト・サービスには次のように切り替えます。
ALTER SESSION SET CONTAINER = hrpdb SERVICE = hrpdb_full;
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
システム権限が必要です。
次の表で、図19-10のCDBに関連したシナリオを説明します。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEM
は、現行コンテナの名前と、CDB内のPDBの名前を問い合せます。
表19-8 CDBのサービス
操作 | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
問合せにより、現行コンテナが |
関連項目:
-
PDBへの接続方法の詳細は、『Oracle Database管理者ガイド』を参照
-
ALTER SESSION SET CONTAINER
の構文およびセマンティクスについては、『Oracle Database SQL言語リファレンス』を参照
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の場合、インスタンスごとに1つのUNDO表領域が存在します。すべての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つ存在します。
例19-21 ローカルUNDOモードのCDB
この例は、2つのPDB(hrpdb
とsalespdb
)を持つCDBの物理記憶域アーキテクチャの様子を示します。この例では、データベースはローカルUNDOモードを使用するため、CDBルート、hrpdb
およびsalespdb
内にUNDOデータ・ファイルがあります。
関連項目:
-
CDBの作成後の状態の詳細は、『Oracle Database管理者ガイド』を参照
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でのフラッシュバック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での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を管理します。
関連項目:
-
CDBでのResource Managerの使用方法の概要は、Oracle Database管理者ガイドを参照してください
-
DB_CACHE_SIZE
およびその他の初期化パラメータの詳細は、Oracle Databaseリファレンスを参照してください -
DBMS_RESOURCE_MANAGER
パッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください -
I/Oリソース管理の詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください