| Oracle® Database概要 12c リリース1 (12.1) B71299-09 |
|
 前 |
 次 |
この項には次のトピックが含まれます:
コンテナは、マルチテナント・コンテナ・データベース(CDB)内のスキーマ、オブジェクトおよび関連構造体の集合で、論理的には別々のデータベースとしてアプリケーションに表示されます。CDB内では、各コンテナは一意のIDと名前を持ちます。
ルートと各プラガブル・データベース(PDB)は、コンテナとみなされます。PDBではデータと操作が分離され、ユーザーまたはアプリケーションから見れば、各PDBは従来の非CDBであるかのように表示されます。
この項には次のトピックが含まれます:
ルート・コンテナ(ルートともいう)は、すべてのPDBが属するスキーマ、スキーマ・オブジェクトおよび非スキーマ・オブジェクトの集合です。どのCDBにも、CDB$ROOTという名前のルート・コンテナが1つのみあり、これにはPDBの管理に必要なシステム・メタデータが格納されています。すべてのPDBはこのルートに属します。
ルートにはユーザー・データは格納されません。したがって、ルートにユーザー・データを追加することや、ルート内のシステム提供のスキーマを変更することはできません。ただし、データベース管理用の共通ユーザーやロールを作成できます(「CDBの共通ユーザー」を参照)。必要な権限を持った共通ユーザーは、PDB間の切替えが可能です。
関連項目:
『Oracle Database管理者ガイド』
PDBは、ユーザーが作成したスキーマ、オブジェクトおよび関連構造体のセットで、論理的にアプリケーションでは個別のデータベースとして表示されます。すべてのPDBは、そのPDBをどのユーザーが作成したかに関係なく、CDBの共通ユーザー(「CDBの共通ユーザー」を参照)であるSYSが所有者です。
この項には次のトピックが含まれます:
PDBには1つのCDB内で一意の名前を付け、サービス名と同じネーミング・ルールに従う必要があります。さらに、PDBは独自の名前のサービスを持つため、PDB名は、特定のリスナーを介して公開されるサービスを所有するすべてのCDBにわたって一意にする必要があります。
ユーザー作成のPDB名は最初の文字を英数字にし、それ以降の文字を英数字またはアンダースコア(_)にする必要があります。サービス名には大文字小文字の区別がないため、PDB名にも大文字と小文字の区別はなく、区切り識別子を使用して指定しても、大文字になります。
関連項目:
サービス名のルールの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
各PDBには個別のネームスペースがあり、次の各構造と次のような関連があります。
スキーマ
あるPDBに含まれたスキーマは、別のPDB内のスキーマと同じ名前である可能性があります。これらの2つのスキーマは、ユーザー名が接続時に解決されるPDBによってお互いに区別される個別のローカル・ユーザー、または共通ユーザーを表すことができます(「CDBの共通およびローカル・ユーザーの概要」を参照)。
オブジェクト
オブジェクトは、1つのPDBでは一意の名前を付ける必要がありますが、CDBのコンテナ全体ではその必要はありません。これは、スキーマ・オブジェクトと非スキーマ・オブジェクトの両方に該当します。異なるPDBに含まれる同じ名前のデータベース・オブジェクトと他のディクショナリ・オブジェクトは、互いにはっきり区別できます。
Oracle Databaseディレクトリは、非スキーマ・オブジェクトの一例です。CDBでは、共通ユーザーSYSがディレクトリを所有します。各PDBには独自のSYSスキーマがあるため、ディレクトリはPDBのSYSスキーマ内に作成されてPDBに属します。
名前の解決中、データベースでは、ユーザーの接続先であるコンテナのデータ・ディクショナリのみを参照します。この動作は、オブジェクト名、PUBLICスキーマおよびスキーマ名に対しても当てはまります。
CDBでは、すべてのデータベース・オブジェクトは1つのスキーマに常駐し、そのスキーマは1つのコンテナに常駐します。PDBはユーザーには非CDBとして表示されるため、1つのコンテナではスキーマに一意の名前を付ける必要がありますが、コンテナ全体ではその必要はありません。たとえば、repスキーマは、salespdbとhrpdbのどちらにも存在できます。2つのスキーマは独立しています(例については、図18-7を参照)。
あるPDBに接続しているユーザーが、別のPDBのオブジェクトにアクセスするには、データベース・リンクを使用する必要があります。この動作は、まさに別の非CDBのオブジェクトにアクセスする非CDBのユーザーに似ています。
関連項目:
データベース・リンクを使用して別のPDBのオブジェクトにアクセスする方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
ユーザーおよびアプリケーションから見て、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では、ディクショナリ・オブジェクトのメタデータは、ルート内にしか格納されません。たとえば、DBA_OBJECTSデータ・ディクショナリ・ビューの基礎であるOBJ$ディクショナリ表の列定義は、ルートにしか存在しません。図18-3に示すように、各PDB内のOBJ$表はメタデータ・リンクと呼ばれる内部メカニズムを使用して、ルートに格納されているOBJ$の定義を指し示します。
メタデータ・リンクに対応するデータは、ルートではなく、そのPDBに常駐します。たとえば、hrpdbに表mytableを作成し、これに行を追加する場合、その行はPDBファイルに格納されます。PDBおよびルートのデータ・ディクショナリ・ビューには、異なる行が含まれます。たとえば、mytableを説明する新しい行は、hrpdbのOBJ$表に存在し、ルートのOBJ$表には存在しません。したがって、ルートのDBA_OBJECTSの問合せと、hrdpbのDBA_OBJECTSでは、異なる結果セットが表示されます。
オブジェクト・リンク
場合によっては、Oracle Databaseでは、オブジェクトのデータ(メタデータではない)がルートに1回しか格納されません。たとえば、AWRデータはルートに常駐します。各PDBがオブジェクト・リンクと呼ばれる内部メカニズムを使用してルート内のAWRデータを指し示すことにより、DBA_HIST_ACTIVE_SESS_HISTORYやDBA_HIST_BASELINEなどのビューが個別のコンテナそれぞれでアクセス可能になります。
Oracle Databaseでは、オブジェクトとメタデータ・リンクを自動的に作成および管理します。ユーザーは、これらのリンクを追加、変更または削除できません。
コンテナ・データ・オブジェクトは、複数のコンテナと場合によってはCDB全体に関連するデータを、そのようなオブジェクトで特定の共通ユーザーに表示されるデータを1つ以上のコンテナに制限するメカニズムとともに格納する表またはビューです。
名前がV$およびCDB_で始まるOracle提供ビューは、コンテナ・データベース・オブジェクトの例です。すべてのコンテナ・データベース・オブジェクトには、CON_ID列があります。次の表に、この列の値の意味を示します。
表18-1 コンテナID値
| コンテナID | 関連行 |
|---|---|
|
CDB全体、または非CDB |
|
|
|
|
その他すべてのID |
ユーザー作成PDB |
CDBでは、各DBA_ビューに、対応するCDB_ビューが存在します。CDB_ビューの所有者は、対応するDBA_ビューの所有者です。次の図は、異なるカテゴリのディクショナリ・ビューの間の関係を示しています。
現在のコンテナがPDBである場合、ユーザーは現在のPDBのデータ・ディクショナリ情報のみを表示できます。PDBに接続されているアプリケーションには、データ・ディクショナリが非CDBの場合と同様に表示されます。ただし、現在のコンテナがルートである場合、共通ユーザーは、ルートとこのユーザーが権限を持つPDBのメタデータを確認するために、CDB_ビューに問い合せることができます。
次の表に、CDB_ビューの問合せを含むシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。
表18-2 CDB_ビューの問合せ
| 操作 | 説明 |
|---|---|
SQL> CONNECT SYSTEM Enter password: ******** Connected. |
|
SQL> SELECT COUNT(*) FROM CDB_USERS
WHERE CON_ID=1;
COUNT(*)
--------
41
|
|
SQL> SELECT COUNT(DISTINCT(CON_ID))
FROM CDB_USERS;
COUNT(DISTINCT(CON_ID))
-----------------------
4
|
|
SQL> CONNECT SYSTEM@hrdb Enter password: ******** Connected. |
|
SQL> SELECT COUNT(*) FROM CDB_USERS;
COUNT(*)
----------
45
|
|
関連項目:
Oracle Database管理者ガイド
指定されたセッションで、現在のコンテナは、セッションが実行されているコンテナです。現在のコンテナはルート(共通ユーザーのみ)またはPDBになります。
各セッションには、任意の時点で現在のコンテナがそれぞれ1つのみ含まれます。各コンテナのデータ・ディクショナリは個別のため、Oracle Databasesでは、名前の解決と権限の認証に、現在のコンテナのデータ・ディクショナリを使用します。
関連項目:
現在のコンテナの詳細は、『Oracle Database管理者ガイド』を参照してください。
コンテナ間操作とは、次のいずれかに影響を与えるDDL文です。
CDB自体
複数のコンテナ
複数のコンテナで表される共通ユーザーや共通ロールなどの複数のエンティティ
DDL文を発行しているユーザーが現在接続されているコンテナとは異なるコンテナ
ルートに接続されている共通ユーザーのみがコンテナ間操作を実行できます(「CDBの共通ユーザー」を参照)。たとえば、ユーザーSYSTEMが別の共通ユーザーに共通に権限を付与したり(「CDBで共通に付与されるロールおよび権限」を参照)、ALTER DATABASE . . . RECOVER文をCDB全体に適用します。
関連項目:
『Oracle Database管理者ガイド』
クライアントは、サービスを使用してPDBに接続する必要があります。サービス名を使用した接続により、PDBでは新規のセッションが開始されます。フォアグラウンド・プロセス、およびその結果のセッションは、ライフタイムの各時点で、一意に定義された現在のコンテナがあります。
次の図に、2つの異なるリスナーを使用してPDBに接続する2つのクライアントを示します。
PDBを作成すると、データベースではCDB内でサービスが自動的に作成され、開始されます。サービスには、DBA_SERVICES.PDB列に示されたプロパティがあり、これがそのPDBをサービスの最初の現行コンテナとして識別します。サービスには、PDBと同じ名前が付いています。PDB名は、有効なサービス名およびCDB内で一意である必要があります。たとえば、図18-5では、hrpdbというPDBには、hrpdbというデフォルトのサービスがあります。デフォルトのサービスは、削除できません。
PDBごとに追加のサービスを作成できます。各追加サービスでは、そのPDBが最初の現行コンテナとして表示されます。図18-5では、erppdbとhrpdbにデフォルト以外のサービスが存在します。非CDBで使用するのと同じ方法で、サービスを作成、維持および削除します。
注意:
同じコンピュータ・システム上の2つ以上のCDBが同じリスナーを使用し、2つ以上のPDBが、これらのCDBに同じサービス名を持つ場合、このサービス名を指定する接続は、このサービス名でPDBのいずれかにランダムに接続されます。不適切な接続を回避するには、PDBのすべてのサービス名をコンピュータ・システム上で一意にするか、コンピュータ・システム上のCDBごとに個別のリスナーを構成します。
関連項目:
PDBに関連付けられているサービスの管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
適切な権限を持つCDB管理者は、CDBのどのコンテナにも接続できます。管理者は、次のいずれかの方法を使用できます。
接続プーリングおよび高度なCDB管理の両方に役立つALTER SESSION SET CONTAINER文を使用して、コンテナの切替えを行います。
たとえば、CDB管理者は、あるセッションのルートに接続してから、同じセッションのPDBに切り替えることができます。この場合、ユーザーにはそのコンテナでのSET CONTAINERシステム権限が必要です。
PDBに直接接続します。
この場合、ユーザーにはそのコンテナでのCREATE SESSION権限が必要です。
表18-3では、図18-5のCDBに関連したシナリオを説明しています。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEMは、現行コンテナの名前と、CDB内のPDBの名前を問い合せます。
表18-3 CDBのサービス
| 操作 | 説明 |
|---|---|
SQL> CONNECT SYSTEM@prod Enter password: ******** Connected. |
|
SQL> SHOW CON_NAME CON_NAME -------- CDB$ROOT |
|
SQL> SELECT NAME, PDB FROM V$SERVICES 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. |
|
SQL> ALTER SESSION SET CONTAINER = hrpdb; Session altered. |
|
SQL> SELECT
SYS_CONTEXT('USERENV', 'CON_NAME')
AS CUR_CONTAINER FROM DUAL;
CUR_CONTAINER
-------------
HRPDB
|
問合せにより、現行コンテナが |
関連項目:
PDBへの接続方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
CDBでは、共通性の基本原則は、既存および将来のどのコンテナにおいても共通の現象が同じであるということです。CDBにおいて「共通」とは「すべてのコンテナに共通」という意味です。一方、ローカルな現象は、厳密に既存の1つのコンテナに限定されます。
この共通性の原則の当然の結果として、共通ユーザーのみが、共通現象の存在を変更できることになります。もっと正確に言えば、ルートに接続した共通ユーザーのみが、共通ユーザーまたは共通ロールのCDB全体にわたる属性を作成、無効化または変更できます。
この項には次のトピックが含まれます:
データベースを定義するオブジェクトを所有するすべてのユーザーは共通です。ユーザー作成のユーザーは、ローカルまたは共通のいずれかです。
図18-6に、CDBで考えられるユーザーのタイプを示します。
共通ユーザーとは、ルートとすべての既存および将来のPDBにおいて同じIDを持つデータベース・ユーザーです。どの共通ユーザーも、ルートに接続し、ルートと権限を持つすべてのPDBで操作を実行できます。
すべての共通ユーザーは、Oracle提供またはユーザー作成のいずれかです。Oracle提供の共通ユーザーの例は、SYSやSYSTEMです。
図18-7に、2つのPDB(hrpdbとsalespdb)のユーザーとスキーマの例を示します。SYSとc##dbaは、CDB$ROOT、hrpdbおよびsalespdbにスキーマを持つ共通ユーザーです。ローカル・ユーザーhrとrepは、hrpdbに存在します。ローカル・ユーザーhrとrepは、salespdbにも存在します。
共通ユーザーには、次の特徴があります。
共通ユーザーは、CREATE SESSION権限を持つどのコンテナ(CDB$ROOTも含む)にもログインできます。
共通ユーザーは、すべてのコンテナで同じ権限を持つ必要はありません。たとえば、c##dbaユーザーは、hrpdbおよびルートでセッション作成の権限を持っていて、salespdbではセッション作成の権限を持っていないという場合があります。適切な権限を持つ共通ユーザーはコンテナの切替えができるため、ルートの共通ユーザーはPDBを管理できます。
ユーザー作成のすべての共通ユーザーの名前は、必ずc##またはC##の文字で始まります。(Oracle提供の共通ユーザー名にはこの制限がありません。)
ローカル・ユーザー名でc##またはC##の文字で始まる名前はありません。
共通ユーザー名で使用できるのは、ASCIIまたはEBCDIC文字のみです。
すべての共通ユーザーには、すべてのコンテナにわたって一意の名前が付けられます。
共通ユーザーはルートに常駐しますが、同じIDを持つどのPDBにも接続できる必要があります。
共通ユーザーのスキーマは、各コンテナで異なる可能性があります。
たとえば、c##dbaは複数のコンテナに対して権限を持つ共通ユーザーで、これらの各コンテナのc##dbaスキーマには、異なるオブジェクトが含まれる場合があります。
関連項目:
共通アカウントとローカル・アカウントの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください
ローカル・ユーザーとは、共通ではなく、1つのPDBでのみ操作が可能なデータベース・ユーザーです。
ローカル・ユーザーには、次の特徴があります。
ローカル・ユーザーは、特定のPDBに固有であり、このPDB内でスキーマを所有できます。
図18-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により、一意のローカル・ユーザーが決まります。図18-7では、repというローカル・ユーザーおよびスキーマがhrpdbに存在します。repという完全に独立したローカル・ユーザーとスキーマが、salespdb PDBに存在します。
次の表に、図18-7のCDBに関連したシナリオを示します。各行は、前の行のアクションの後に発生するアクションについて説明します。共通ユーザーSYSTEMが、2つのPDBでローカル・ユーザーを作成します。
表18-4 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セキュリティ・ガイド』を参照してください。
Oracle提供のロールはいずれも共通です。Oracle提供のスクリプトでは、Oracle提供のユーザーおよびロールに付与されるすべての権限またはロールは共通に付与されますが、例外は、システム権限が共通ロールPUBLICに対してローカルに付与される場合です(「CDBのPUBLICへの付与」を参照)。ユーザー作成のロールは、ローカルまたは共通のいずれかです。
共通ロールは、ルートと既存および将来のすべてのPDBに存在するデータベース・ロールです。共通ロールは、コンテナ間の操作に便利で(「コンテナ間操作」を参照)、共通ユーザーがすべてのコンテナでロールを持つことを保証します。
すべての共通ロールは、ユーザー作成かOracle提供のいずれかです。Oracleから提供されるすべての事前定義ロールは共通ロールです(DBAやPUBLICなど)。ユーザー作成の共通ロールの名前は、C##またはc##の文字で始まり、ASCIIまたはEBCDIC文字しか使用できません。たとえば、CDB管理者が共通ユーザーc##dbaを作成し、このユーザーにDBAロールを共通に付与すると、c##dbaが既存および将来のすべてのPDBでDBAロールを持つようになります。
ユーザーは、次の基準を満たした場合にのみ、共通ロールで、そのロールに共通の権限を付与するなどの共通の操作を実行できます。
ユーザーは、その現在のコンテナがルートである共通ユーザーです。
ユーザーには、共通に付与されたSET CONTAINER権限があり、これはその権限がすべてのコンテナで適用されることを意味します。
ユーザーには、指定した操作を実行する能力を制御する権限があり、この権限は共通に付与されています(「CDBで共通に付与されるロールおよび権限」を参照)。
たとえば、共通ロールを作成するには、共通ユーザーに共通に付与されたCREATE ROLE権限とSET CONTAINER権限が必要です。CREATE ROLE文で、CONTAINER=ALL句はそのロールが共通であることを指定します。
関連項目:
共通ロールの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CREATE ROLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
非CDBのロールが非CDBにのみ存在するのと同様に、ローカル・ロールは単一のPDBにのみ存在します。ローカル・ロールには、そのロールが存在するコンテナで適用されるロールおよび権限のみを含めることができます。
同じCDBのPDBには、同じ名前のローカル・ロールが含まれる場合があります。たとえば、ユーザー作成のロールpdbadminは、hrpdbとsalespdbのどちらにも存在する可能性があります。これらのロールは、別々の非CDBにあるかのように、互いにまったく関係ありません。
関連項目:
ローカル・ロールの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
非CDBと同様に、CDBのユーザーは、ロールおよび権限を付与できます。CDBにおける主な違いは、ローカルに付与されるロールおよび権限と、共通に付与されるロールおよび権限とが区別されることです。ローカルに付与された権限またはロールは、それが付与されたコンテナでのみ実行可能です。共通に付与された権限またはロールは、既存および将来のどのコンテナにおいても実行可能です。
ユーザーおよびロールは、共通の場合もローカルの場合もあります。ただし、権限は、それ自体は共通でもローカルでもありません。ユーザーがCONTAINER=CURRENT句を使用してローカルに権限を付与した場合、権限受領者は現行コンテナ内でのみ実行可能な権限を持ちます。ユーザーがCONTAINER=ALL句を使用して共通に権限を付与した場合、権限受領者は既存および将来のコンテナ内で実行可能な権限を持ちます。
CDBでは、付与の行為は、ローカルであろうと共通であろうと、どれも特定のコンテナ内で起こります。
付与の基本原則は、次のとおりです。
共通およびローカルのどちらの現象も、ローカルに付与および受領できます。
共通に付与または受領できるのは、共通の現象のみです。
ローカルのユーザー、ロールおよび権限は、本質的に特定のコンテナに限定されます。したがって、ローカル・ユーザーは、共通のロールおよび権限を付与することはできず、ローカルのロールおよび権限は共通に付与されることはありません。
次の各項では、前述の原則の意味を説明します。
ロールおよび権限は、受領者、付与者または付与されるロールがローカルか共通かに関係なく、ユーザーおよびロールにローカルに付与できます。
次の表に、ローカルに付与されたロールおよび権限の有効な可能性を示します。
表18-5 ローカルな付与
| 現象 | ローカルな付与が可能 | ローカルな受領が可能 | ローカルに付与されたロールまたは権限の受領が可能 |
|---|---|---|---|
共通ユーザー |
はい |
該当なし |
はい |
ローカル・ユーザー |
はい |
該当なし |
はい |
共通ロール |
該当なし |
はい脚注 1 |
はい |
ローカル・ロール |
該当なし |
はい脚注 2 |
はい |
権限 |
該当なし |
はい |
該当なし |
脚注1
このロールでの権限は、権限がロールにローカルに付与されたか共通に付与されたかに関係なく、被付与者にとってロールが付与されたコンテナでのみ使用可能です。
脚注2
このロールでの権限は、被付与者にとってロールが付与され作成されたコンテナでのみ使用可能です。
ロールまたは権限は、次の条件を満たしたとき、ローカルに付与されます。
付与者に、指定したロールまたは権限を付与するために必要な権限がある。
システム・ロールまたは権限の場合、付与者には付与するロールまたは権限に対するADMIN OPTIONが必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTIONが必要です。
付与は1つのコンテナに対してのみ適用される。
デフォルトでは、GRANT文には、権限またはロールをローカルに付与することを指定するCONTAINER=CURRENT句が含まれます。
ユーザーまたはロールは、ローカルに付与された権限である可能性があります(CONTAINER=CURRENT)。
たとえば、hrpdbのローカルまたは共通ユーザーに対してローカルに付与されたREAD ANY TABLE権限は、この PDB内のこのユーザーに対してのみ適用されます。同様に、非CDBのユーザーhrに付与されたREAD ANY TABLE権限は、別の非CDBに存在するhrユーザーの権限には何の関係もありません。
ユーザーまたはロールは、ローカルに付与されたロールである可能性があります(CONTAINER=CURRENT)。表18-5に示すように、共通ロールは、ローカルに付与される権限を受領する可能性があります。たとえば、共通ロールc##dbaは、hrpdbでREAD ANY TABLE権限をローカルに付与される可能性があります。c##cdb共通ロールがローカルに付与されると、そのロールの権限は、ロールの付与先のコンテナでのみ適用されます。この例では、c##cdbaロールを持つ共通ユーザーは、権限がこのロールに対してhrpdbでローカルに付与されたものであるため、この権限をhrpdb以外のどのPDBでも実行する権利はありません。
関連項目:
CDBでロールおよび権限を付与する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
権限および共通ロールは、共通に付与される可能性があります。
ユーザー・アカウントまたはロールには、被付与者と付与者がどちらも共通である場合にのみ、ロールおよび権限を共通に付与できます。ロールを共通に付与する場合、そのロール自体が共通である必要があります。次の表に、共通の付与の可能性を示します。
表18-6 共通の付与
| 現象 | 共通の付与が可能 | 共通の受領が可能 | 共通に付与されたロールおよび権限の受領が可能 |
|---|---|---|---|
共通ユーザー・アカウント |
はい |
該当なし |
はい |
ローカル・ユーザー・アカウント |
いいえ |
該当なし |
いいえ |
共通ロール |
該当なし |
Yes脚注3 |
はい |
ローカル・ロール |
該当なし |
いいえ |
いいえ |
権限 |
該当なし |
はい |
該当なし |
脚注3
共通ロールに共通に付与された権限は、すべてのコンテナで被付与者が使用できます。さらに、共通ロールに対してローカルに付与された権限はどれも、その権限が共通ロールに付与されたコンテナでのみ、被付与者が使用できます。
関連項目:
共通の付与の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
ロールまたは権限は、次の条件を満たしたとき、共通に付与されます。
付与者は、共通ユーザーである。
被付与者は、共通ユーザーまたは共通ロールである。
付与者に、指定したロールまたは権限を付与するために必要な権限がある。
システム・ロールまたは権限の場合、付与者には付与するロールまたは権限に対するADMIN OPTIONが必要です。オブジェクト権限の場合、付与者には付与する権限に対するGRANT OPTIONが必要です。
付与はすべてのコンテナに適用される。
GRANT文には、権限またはロールが共通に付与されることを指定するCONTAINER=ALL句が含まれます。
ロールが付与される場合、それは共通であり、オブジェクト権限が付与される場合は、権限が付与される対象のオブジェクトが共通であることが必要。
共通ユーザーまたはロールは、共通に付与された権限である可能性があります(CONTAINER=ALL)。権限は、すべての既存および将来のコンテナで、この共通ユーザーまたはロールに付与されます。たとえば、共通ユーザーc##dbaに共通に付与されたSELECT ANY TABLE権限は、すべてのコンテナでこのユーザーに適用されます。
ユーザーまたはロールは、共通に付与された共通ロールを受領する可能性があります。表18-6の脚注で言及されているように、共通ロールは、ローカルに付与された権限を受領できます。したがって、共通ユーザーには共通ロールを付与でき、このロールにはローカルに付与された権限が含まれる可能性があります。たとえば、共通ロールc##adminは、hrpdbに対してローカルなSELECT ANY TABLE権限を付与される可能性があります。共通ロールでローカルに付与された権限は、その権限が付与されたコンテナでのみ適用されます。したがって、c##adminロールを持つ共通ユーザーには、salespdbまたはhrpdb以外のどのPDBでも、hrpdbに含まれる権限を実行する権利はありません。
関連項目:
CDBでロールおよび権限を付与する方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
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での操作が示されています。
表18-7 CDBのロールおよび権限の付与
| t | CDB$ROOTでの操作 | hrpdbでの操作 | 説明 |
|---|---|---|---|
t1 |
SQL> CONNECT SYSTEM@root Enter password: ******* Connected. |
N/A |
共通ユーザー |
t2 |
SQL> CREATE USER c##dba
IDENTIFIED BY password
CONTAINER=ALL;
|
N/A |
|
t3 |
SQL> GRANT CREATE SESSION TO c##dba; |
N/A |
|
t4 |
SQL> CREATE ROLE c##admin CONTAINER=ALL; |
N/A |
|
t5 |
SQL> GRANT SELECT ANY TABLE TO c##admin; Grant succeeded. |
N/A |
|
t6 |
SQL> GRANT c##admin TO c##dba; SQL> EXIT; |
N/A |
|
t7 |
N/A |
SQL> CONNECT c##dba@hrpdb Enter password: ******* ERROR: ORA-01045: user c##dba lacks CREATE SESSION privilege; logon denied |
|
t8 |
N/A |
SQL> CONNECT SYSTEM@hrpdb Enter password: ******* Connected. |
|
t9 |
N/A |
SQL> GRANT CONNECT, RESOURCE TO c##dba; Grant succeeded. SQL> EXIT |
|
t10 |
N/A |
SQL> CONNECT c##dba@hrpdb Enter password: ******* Connected. |
共通ユーザー |
t11 |
N/A |
SQL> SELECT COUNT(*)
FROM hr.employees;
select * from hr.employees
*
ERROR at line 1:
ORA-00942: table or view does
not exist
|
|
t12 |
SQL> CONNECT SYSTEM@root Enter password: ******* Connected. |
N/A |
共通ユーザー |
t13 |
SQL> GRANT SELECT ANY TABLE TO c##admin CONTAINER=ALL; Grant succeeded. |
N/A |
|
t14 |
N/A |
SQL> SELECT COUNT(*) FROM
hr.employees;
select * from hr.employees
*
ERROR at line 1:
ORA-00942: table or view does
not exist
|
|
t15 |
SQL> GRANT c##admin TO c##dba CONTAINER=ALL; Grant succeeded. |
N/A |
|
t17 |
N/A |
SQL> SELECT COUNT(*)
FROM hr.employees;
COUNT(*)
----------
107
|
問合せに成功します。 |
関連項目:
共通ロールおよびローカル・ロールの管理方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
混合モードと統合監査のどちらの場合も、共通監査構成が表示され、すべてのPDBにわたって実行されます。
監査構成は、ローカルまたは共通のいずれかです。ユーザーやロールなど、その他のローカルまたは共通の現象に適用されるスコーピング・ルールは、すべて監査構成に適用されます。
注意:
監査初期化パラメータは、CDBレベルに存在し、各PDBには存在しません。
PDBでは、次の監査オプションがサポートされます。
オブジェクト監査
オブジェクト監査とは、特定のオブジェクトに対する監査構成のことを指します。共通監査構成に含めることができるのは、共通オブジェクトのみです。ローカル監査構成には、共通オブジェクトを含めることはできません。
監査ポリシー
監査ポリシーは、ローカルまたは共通のいずれかです。
ローカル監査方針
ローカル監査ポリシーは、1つのPDBに適用されます。ローカル監査ポリシーは、このPDBのみのローカルおよび共通ユーザーに対して実行できます。ローカル監査ポリシーをすべてのコンテナにわたって実行しようとすると、エラーが発生します。
いかなる場合でも、ローカル監査ポリシーの実行は、ローカル監査フレームワークの一部です。
共通監査ポリシー
共通監査ポリシーは、すべてのコンテナに対して適用されます。このポリシーには、アクション、システム権限、共通ロールおよび共通オブジェクトのみを含めることができます。共通監査ポリシーは、共通ユーザーに対してのみ適用できます。ローカル・ユーザーに対する共通監査ポリシーをすべてのコンテナにわたって実行しようとすると、エラーが発生します。
共通監査構成は、ルートのSYSスキーマに格納されています。ローカル監査構成は、適用対象のPDBのSYSスキーマに格納されています。
監査証跡は、関連PDBのSYSまたはAUDSYSスキーマに格納されています。オペレーティング・システムおよびPDBのXML監査証跡は、AUDIT_FILE_DEST初期化パラメータで指定されたディレクトリのサブディレクトリに格納されています。
関連項目:
共通監査構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CDBの構造は非CDBと同じですが、各PDBおよびアプリケーション・ルートに独自の表領域のセット(独自のSYSTEM、SYSAUXおよびUNDO表領域を含む)が存在する点が異なります。
CDBには次のファイルが含まれています。
1つの制御ファイル
1つのオンラインREDOログ
1セットのUNDOデータ・ファイル
単一インスタンスCDBでは、アクティブなUNDO表領域が1つのみ存在します。Oracle RAC CDBの場合、それぞれのインスタンスについてアクティブなUNDO表領域が1つ存在します。適切な権限を持ち、現行コンテナがルートとなっている共通ユーザーのみが、UNDO表領域を作成できます。すべてのUNDO表領域は、すべてのコンテナのデータ・ディクショナリおよび関連ビューで表示されます。
コンテナごとのSYSTEM表領域およびSYSAUX表領域
CDBと非CDBの第一の物理的違いは、SYSTEMとSYSAUXのデータファイルです。非CDBには、SYSTEM表領域とSYSAUX表領域がそれぞれ1つのみ含まれます。対照的に、CDBルートおよび各PDBには、独自のSYSTEM表領域とSYSAUX表領域が含まれます。各コンテナには、コンテナに常駐するオブジェクトを記述した独自のディクショナリ表のセットも含まれます。
0以上のユーザー作成表領域
一般的なユースケースでは、各PDBに独自の非システム表領域のセットがあります。これらの表領域には、PDB内のユーザー定義のスキーマおよびオブジェクトのデータが含まれています。
PDB内では、永続表領域と一時表領域を非CDBで管理する場合と同じ方法で管理します。CREATE PLUGGABLE DATABASEまたはALTER PLUGGABLE DATABASE文でSTORAGE句を使用して、PDBのデータファイルが使用する記憶域の量を制限することもできます。
PDB内のデータ・ディクショナリの記憶域は、移植可能です。PDBはCDBから切断し、異なるCDBに接続できます。
コンテナごとの一連の一時ファイル
CDBルートおよび各PDBに対して、1つのデフォルトの一時表領域が存在します。
次の図に、2つのPDB (hrpdbとsalespdb)を持つCDBの物理記憶域アーキテクチャの様子を示します。
関連項目:
CDBの作成後の状態の詳細は、『Oracle Database管理者ガイド』を参照してください。
