| Oracle® TimesTen In-Memory Databaseセキュリティ・ガイド リリース18.1 E98622-04 |
|
 前 |
 次 |
TimesTenのアクセス制御の1つの側面は、表やビューなどのデータベース・オブジェクトへのアクセスを認可または制限する権限の使用です。データベース・オブジェクトにアクセスする可能性があるユーザーが複数存在する場合、権限の付与に従ってこれらのオブジェクトへのアクセスが認可されます。オブジェクトには必ず所有者が存在します。権限によって、ユーザーは、他のユーザーが所有しているオブジェクトに対するアクセスまたは変更を認可されます。権限の付与または取消しを実行できるのはインスタンス管理者、ADMIN権限を持つユーザー、または特定のオブジェクトに対する権限の場合は、そのオブジェクトの所有者です。
また、データベースへの接続などのアクションを認可するシステム・レベル権限もあります。
この章では、TimesTenの認可機能について説明します。内容は次のとおりです。
|
ノート:
|
TimesTenでは、権限の付与による認可に応じて、データベース内のオブジェクトへのアクセスが許可されます。これらの権限によって、ユーザーが実行できる操作が決定されます。この項の内容は次のとおりです。
|
ノート: ユーザーは、所有するすべてのオブジェクトに対するすべての権限を持ち、これらの権限は取り消せません。 |
ユーザーが特定のオブジェクトまたはオブジェクトのタイプにアクセスできるようにするには、SQLのGRANT文を使用して権限を付与します。権限を取り消すには、SQLのREVOKE文を使用します。
システム権限の付与または取消し、あるいは所有していないオブジェクトに対するオブジェクト権限の付与または取消しを行うには、管理権限が必要です。
例:
GRANT admin TO terry; GRANT SELECT ON pat.customers TO terry; GRANT SELECT ON emp_details_view TO terry; REVOKE admin, ddl FROM terry; REVOKE update ON pat.customers FROM terry;
構文および使用方法の詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのGRANTおよびREVOKEを参照してください。
TimesTenでは、SQL文の実行時に各ユーザーの権限が評価されます。次に例を示します。
Command> SELECT * from pat.table1;
この文をpatが実行する場合、patはこのオブジェクトの所有者であるため、他に必要な権限はありません。ただし、terryなどの他のユーザーがこの文を実行する前に、pat.table1に対するSELECT権限を付与されている必要があります。
Command> GRANT SELECT ON pat.table1 TO terry;
権限では、次のことが実行されます。
ユーザー、アプリケーションまたはファンクションがアクセスできるデータまたはそれらが実行できる操作を定義します。
ユーザーがシステム・パフォーマンスを低下させたり、システム・リソースを大量に消費することを防ぎます。たとえば、認可上の懸念からではなく、DMLパフォーマンスを低下させたり、ディスク領域を占有する可能性があるという理由から、索引作成を制限する権限を指定できます。
権限の一部の例には、次の処理を実行する認可が含まれます。
データベースへの接続およびセッションの作成
表の作成
表からの行の選択
キャッシュ・グループ処理の実行
システム権限があると、すべてのオブジェクトへのアクセスなど、システム全体の機能を有効にできます。システム権限を付与されたユーザーは、管理者タスクを実行したり、他のユーザーのスキーマ内のオブジェクトにアクセスできます。信頼できるユーザーのみにこれらを付与してください。システム権限の概要を参照してください。
オブジェクト権限によって、特定の表やビューなど、特定のデータベース・オブジェクトへのアクセスが可能になります。オブジェクト権限の概要を参照してください
このような権限のサブセットは、作成時に、PUBLICロールを介して各ユーザーに自動的に付与されます。PUBLICロールの概要を参照してください。
SQL文が準備されたとき、およびSQL文が最初に実行されたときに、権限が確認されます。それ以降に文を実行するときにさらに権限のチェックが必要になるのは、データベースでREVOKE文が実行された場合のみです。
システム権限は、ユーザーがデータベース全体でシステム・レベルのアクティビティを実行することや、指定したタイプのすべてのデータベース・オブジェクトに指定したタイプの操作(CREATE ANY TABLEなど)を実行することを認可します。
システム権限の例として、ADMIN、SELECT ANY TABLE、CREATE SESSIONおよびCREATE ANY SEQUENCEがあります。システム権限の付与と取消しの詳細は、システム権限を参照してください。
ユーザーにシステム権限を付与できるのは、インスタンス管理者またはADMIN (管理)権限を持つユーザーのみです。
|
ノート: ADMIN権限を持つユーザーは、管理権限で説明されているように、特別なシステム権限のセットを持ちます。インスタンス管理者は、インスタンス管理者権限で説明しているように、システム権限のセットをすべて包含しています。 |
オブジェクト権限を持つユーザーは、特定の処理を特定のオブジェクトに対して実行できます。オブジェクト・タイプごとに、CREATE TABLEなどの個別のオブジェクト権限を使用できます。
他のユーザーが所有するオブジェクトには、そのオブジェクトの所有者またはADMIN権限を持つユーザーから明示的にアクセス権を付与されないかぎり、アクセスできません。
PUBLICロールに特定のオブジェクトへのアクセス権が付与されている場合、すべてのデータベース・ユーザーがそのオブジェクトにアクセスできます。
オブジェクト権限の付与または取消しを実行できるのは、インスタンス管理者、ADMIN権限を持つユーザー、または該当するオブジェクトを所有するユーザーです。
オブジェクト権限の付与または取消しの詳細は、SQLオブジェクトに対する権限を参照してください。
TimesTenユーティリティの実行に必要な特別な権限は、『Oracle TimesTen In-Memory Databaseリファレンス』のユーティリティに関する項またはTimesTen Scaleoutユーティリティに関する項の「必要な権限」に記載された説明を参照してください。
|
ノート: データベースがメモリーにロードされていないときに、インスタンス管理者以外のユーザーが特別な権限を必要とするユーティリティを実行しようとすると、TimesTenはユーザーの権限を判断できないためにエラーが発生します。 |
PUBLICというロールがTimesTenの各データベースに自動的に作成され、特定の権限が付与されて、TimesTenデータベースに作成される各ユーザーは、これらの権限を継承します。PUBLICロールに後で付与された各権限も、同時にすべてのユーザーに自動的に付与されます。
たとえば、このコマンドを実行すると、すべてのユーザーに対するCREATE SESSION権限が発生します。
Command> GRANT CREATE SESSION TO PUBLIC;
このドキュメントの「PUBLICロールを介した権限」および『Oracle TimesTen In-Memory Database SQLリファレンス』のPUBLICロールに関する項も参照してください。
|
ノート: TimesTenでは他のロールはサポートされません。 |
インスタンス管理者の他に、最も強力なシステム権限はADMINであり、これによってユーザーは任意のデータベース・オブジェクトに対するシステム操作または操作を実行できます。他のユーザーに対してシステム権限の付与または取消しを行うことができるのは、インスタンス管理者またはADMIN権限を持つユーザーのみです。
各ユーザーは自分のシステム権限をSYS.USER_SYS_PRIVSシステム・ビューで確認できます。ADMIN権限を持つユーザーは、すべてのユーザーのすべてのシステム権限をSYS.DBA_SYS_PRIVSシステム表で確認できます。システム・ビューの詳細は、ユーザー権限ビューを参照してください。
次の項では、TimesTenで使用できるシステム権限について説明します。
インスタンス管理者(TimesTenユーザー・グループのメンバー)は、TimesTenインストールとすべてのTimesTenインスタンスを作成するユーザーです。このユーザーには、他の管理ユーザーの権限以外にも多数の特別な権限および機能があります。
インスタンス管理者のみが次のことを実行できます。
TimesTenインストールを削除します。
TimesTenインスタンスを作成、変更(アップグレードを含む)または破棄します。
データベースを作成または破棄します。
データベースを手動でロードまたはアンロードします(ttAdmin -ramLoadを使用してramPolicy manual)。
最初の接続属性設定への変更が適用されるときにデータベースをロードします。
データベースのオープンまたはクローズ
データベースをリストアします。
TimesTenデーモンを起動および停止します。
TimesTenサーバーを再起動します。
また、TimesTen Scaleoutの場合は、インスタンス管理者のみがttGridAdminユーティリティの任意のコマンドを実行できます。前述の機能を含め、他の多くの機能のうち、TimesTen Scaleoutインスタンス管理者のみがグリッドの作成、データベース定義と接続可能オブジェクトの作成、既存データベースの分散マップの変更、リポジトリの作成、バックアップ、リストア、エクスポートおよびインポートの実行を行うことができます。
関連情報については、次を参照してください。
Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのインスタンス管理者、TimesTenユーザー・グループの理解およびTimesTenインスタンス
Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイドのTimesTen Scaleoutのアーキテクチャおよびオペレーティング・システム・ユーザー
|
ノート:
|
ADMIN権限は、すべてのデータベース・オブジェクトに対するシステム権限および権限を付与し、これにより、これらのユーザーは、管理タスクおよび任意の有効なデータベース操作を実行できます。ADMIN権限を付与できるのは、インスタンス管理者またはADMIN権限を持つ別のユーザーのみです。
ADMIN権限を持つユーザーは、次のことができます。
すべてのデータベース・オブジェクトに対する作成、変更、破棄、選択、更新、挿入または削除操作の実行。
すべての権限の付与または取消し。
チェックポイント操作の実行。
ユーザーの作成および削除。
システム表、ビューおよびパッケージの表示。
レプリケーション・スキーマまたはアクティブ・スタンバイ・ペアの作成、変更または破棄。
ADMIN権限をユーザーterryに付与するには、インスタンス管理者またはADMIN権限を持つ他のユーザーが次の文を実行します。
Command> GRANT ADMIN TO terry;
patが所有するdepartments表でterryにSELECT権限を付与するには、次のようにします。
Command> GRANT SELECT ON pat.departments TO terry;
|
ノート: patはdepartmentsの所有者であるため、patもterryにSELECTオブジェクト権限を付与できます。 |
ユーザーがデータベースに接続するには、インスタンス管理者またはADMIN権限を持つユーザーによってCREATE SESSIONシステム権限が付与されている必要があります。次の例では、CREATE SESSION権限をpatに付与します。
Command> GRANT CREATE SESSION TO pat;
|
ノート: TimesTenデータベースへのアクセスには、データソース名(DSN)を使用します。ユーザーが、権限のない接続属性(初期接続属性など)を持つDSNを使用しようとすると、エラーが表示されます。必要な権限を含む初期接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。 |
ANYキーワードとともに使用する権限により、ユーザーは、データベースの指定されたタイプのオブジェクトに対して操作を実行できます。これらのシステム権限には、CREATE ANY object_type、DROP ANY object_type、ALTER ANY object_type、SELECT ANY object_type、UPDATE ANY TABLE、INSERT ANY TABLE、DELETE ANY TABLEおよびEXECUTE ANY PROCEDUREがあります。
ANY TABLEには、ビューおよびマテリアライズド・ビューも含まれます。
ALL PRIVILEGESは、インスタンス管理者またはADMIN権限を持つユーザーが付与でき、システム権限をユーザーに付与します。付与する権限を制限する場合は、ALL PRIVILEGESを付与してから、ユーザーに付与しないシステム権限を取り消すことができます。
付与後、ALL PRIVILEGESを取り消すことができます。
権限の階層があります。上位レベルの権限では、関連する下位レベルの権限が付与されます。たとえば、ADMIN権限ではシステム権限が付与されます。SELECT ANY TABLE権限では、任意の表に対するSELECT権限が付与されます。
ユーザーに操作の権限が必要な場合、最初にユーザーがすでに上位レベルの権限によって権限を持っているかどうかを確認します。たとえば、ユーザーpatがterry.table2に対するSELECT権限を必要としている場合、次の事項を確認します。
patにSELECT ANY TABLE権限が付与されているかどうか。この権限がある場合、patは任意の表、ビューおよびマテリアライズド・ビューに対してSELECTを実行できます。
patにADMIN権限が付与されているかどうか。これがある場合、patは有効なSQL操作を実行できます。
上位レベルに含まれる権限を付与しても、エラーは発生しません。ただし、権限を取り消す場合は、付与した単位(ANYレベルまたはオブジェクト・レベル)で取り消す必要があります。
次の一連の文は有効ですが、patはUPDATE ANY TABLE権限のためにhr.employees表を更新できます。(2番目の文は不要ですが、それがないと3番目の文が無効になります。)
Command> GRANT UPDATE ANY TABLE TO pat; Commanc> GRANT UPDATE ON hr.employees TO pat; Command> REVOKE UPDATE ON hr.employees FROM pat;
次の例でも、明示的に付与されたため、patは引き続きhr.employeesを更新できます。
Command> GRANT UPDATE ANY TABLE TO pat; Commanc> GRANT UPDATE ON hr.employees TO pat; Command> REVOKE UPDATE ANY TABLE FROM pat;
次の例では、ユーザーがhr.employees表を更新する機能を取り消そうとしていますが、その特定のオブジェクトに対するGRANT文がなかったため、無効です。
Command> GRANT UPDATE ANY TABLE TO pat; Command> REVOKE UPDATE ON hr.employees FROM pat; 15143: REVOKE failed: User PAT does not have object privilege UPDATE on HR.EMPLOYEES The command failed.
詳細は、Oracle TimesTen In-Memory Database SQLリファレンスの権限階層を参照してください。
ADMIN権限に加えて、次のシステム権限では、データベース機能の特定の領域にまたがる範囲の操作が認可されます。
XLA: システムにグローバルに影響を及ぼす可能性のあるXLAリーダーとして接続するには、XLAシステム権限が必要です。XLAリーダーは、追加のログ・ボリュームを作成できますが、そのブックマークを先に進めることができない場合にログが長期間保留される可能性があります。
CACHE_MANAGER: CACHE_MANAGER権限は、キャッシュ・グループ管理者処理に必要です。詳細は、キャッシュ・グループの権限を参照してください。
インスタンス管理者またはADMIN権限を持つユーザーは、PUBLICロールに対する権限の付与または取消しによって、すべてのユーザーのデフォルト権限の付与または取消しを実行できます。
|
ノート:
|
次の例では、ユーザーpatにSELECT ANY TABLE権限が、PUBLICにSELECT ANY TABLE権限がそれぞれ付与されます。次に、SYS.DBA_SYS_PRIVSビューのすべてのシステム権限が表示されます。(このビューの詳細は、ユーザー権限ビューを参照してください。)示されているように、PUBLICからSELECT ANY TABLEを取り消しても、patからSELECT ANY TABLEは取り消されません。(2番目の列はユーザーが保持している権限を示します。この例の3番目の列NOは、ユーザーがその権限を他のユーザーに付与できるかどうかを示します。)
Command> GRANT SELECT ANY TABLE TO PAT; Command> GRANT SELECT ANY TABLE TO PUBLIC; Command> SELECT * FROM SYS.DBA_SYS_PRIVS; < SYS, ADMIN, NO > < PUBLIC, SELECT ANY TABLE, NO > < SYSTEM, ADMIN, NO > < PAT, ADMIN, NO > < PAT, SELECT ANY TABLE, NO > 5 rows found. Command> REVOKE SELECT ANY TABLE FROM PUBLIC; Command> select * from sys.dba_sys_privs; < SYS, ADMIN, NO > < SYSTEM, ADMIN, NO > < PAT, ADMIN, NO > < PAT, SELECT ANY TABLE, NO > 4 rows found.
デフォルトでは、新しく作成されたTimesTenデータベースでは、PUBLICに、各種システム表およびビューと、PL/SQLファンクション、プロシージャおよびパッケージに対するSELECT権限とEXECUTE権限があります。PUBLICに付与された権限のリストは、SYS.DBA_TAB_PRIVSビューに問い合せることで表示できます。次に示す問合せでは、PUBLICに付与されている権限は、問合せの前にあるDESCRIBE文で示されているように5番目の列に表示されます。
Command> DESC SYS.DBA_TAB_PRIVS;
View SYS.DBA_TAB_PRIVS:
Columns:
GRANTEE VARCHAR2 (30) INLINE
OWNER VARCHAR2 (30) INLINE
TABLE_NAME VARCHAR2 (30) INLINE
GRANTOR VARCHAR2 (30) INLINE
PRIVILEGE VARCHAR2 (40) INLINE NOT NULL
GRANTABLE VARCHAR2 (3) INLINE NOT NULL
HIERARCHY VARCHAR2 (3) INLINE NOT NULL
1 view found.
Command> SELECT * FROM SYS.DBA_TAB_PRIVS WHERE GRANTEE='PUBLIC';
< PUBLIC, SYS, TABLES, SYS, SELECT, NO, NO >
< PUBLIC, SYS, COLUMNS, SYS, SELECT, NO, NO >
< PUBLIC, SYS, INDEXES, SYS, SELECT, NO, NO >
< PUBLIC, SYS, USER_COL_PRIVS, SYS, SELECT, NO, NO >
< PUBLIC, SYS, PUBLIC_DEPENDENCY, SYS, SELECT, NO, NO >
< PUBLIC, SYS, USER_OBJECT_SIZE, SYS, SELECT, NO, NO >
< PUBLIC, SYS, STANDARD, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, UTL_IDENT, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, TT_DB_VERSION, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, PLITBLM, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_OUTPUT, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_SQL, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_STANDARD, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_PREPROCESSOR, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, UTL_RAW, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_UTILITY, SYS, EXECUTE, NO, NO >
< PUBLIC, SYS, DBMS_RANDOM, SYS, EXECUTE, NO, NO >
...
57 rows found.
この項では、データベース・オブジェクトの作成、変更または破棄に必要な権限の概要を示します。
表、ビュー、マテリアライズド・ビュー、順序、PL/SQLプロシージャ、PL/SQLファンクション、PL/SQLパッケージ、シノニムなどのデータベース・オブジェクトを作成するには、適切なCREATE object_typeまたはCREATE ANY object_type権限が必要です。
次に、CREATE権限およびCREATE ANY権限について説明します。
CREATE object_type権限は、ユーザー自身のスキーマ内でのみ、指定したタイプ(TABLEなど)のオブジェクトを作成する機能を付与します。作成後、ユーザーはオブジェクトを所有し、そのオブジェクトに対するすべての権限を持ちます。
CREATE ANY object_type権限は、データベースの任意のスキーマでそのタイプのオブジェクトを作成する機能をユーザーに付与します。CREATE ANY object_type権限には、CREATE ANY TABLE、CREATE ANY INDEX、CREATE ANY VIEW、CREATE ANY MATERIALIZED VIEW、CREATE ANY SEQUENCE、CREATE ANY SYNONYMおよびCREATE ANY PROCEDUREがあります。
次の例のように、ユーザーが自分のスキーマに表を作成するにはCREATE TABLE権限を付与されている必要があります。
Command> GRANT CREATE TABLE TO terry;
次の例では、ユーザーterryに任意のスキーマで任意の表を作成する権限を付与します。
Command> GRANT CREATE ANY TABLE TO terry;
|
ノート:
|
ALTER ANY object_type権限は、自分が所有していないオブジェクトのプロパティを変更する場合に必要です。たとえば、プロシージャproc1がhrスキーマに作成され、patにALTER ANY PROCEDURE権限が付与されている場合、patはプロシージャhr.proc1を変更できます。
ALTER権限は、個々のオブジェクトに対しては付与できません。かわりに、必要なオブジェクト・タイプに対するALTER ANY権限を付与する必要があります。
データベース・オブジェクトへのユーザー・アクセスは、単一オブジェクトまたはデータベース内の任意の場所にあるそのタイプのオブジェクトについてGRANT文を使用して権限を付与することで認可されます。アクセスは、REVOKE文によって削除されます。
この項の内容は次のとおりです。
ユーザーが表を作成するには、そのユーザーにCREATE TABLEまたはCREATE ANY TABLE権限が付与されている必要があります。
自分が所有していない表に対して処理を実行する場合、そのユーザーには、その表に関する適切なオブジェクト権限が付与されている必要があります。このような権限には、キャッシュ・グループに含まれる表に関する権限などがあります。表に関するオブジェクト権限には、SELECT、UPDATE、DELETE、INSERT、INDEXおよびREFERENCESがあります。
次に例を示します。
Command> GRANT SELECT ON hr.employees TO pat; Command> GRANT UPDATE ON hr.employees TO pat;
INDEX権限を持つユーザーは、表の索引を作成できます。
REFERENCES権限により、CREATE TABLE文またはALTER TABLE文でREFERENCES句を使用できます。この句は、子表の列(次の例ではtable1.col1)から親表の列(例ではtable2.pk)への外部キー依存性を作成します。
Command> ALTER TABLE pat.table1 ADD CONSTRAINT fk1 FOREIGN KEY (col1) REFERENCES pat.table2 (pk);
pat (表の所有者)が文が実行する場合、追加の権限は必要ありません。文を実行する他のユーザーには、ALTER ANY TABLE権限が必要です。
また、ALTER TABLE ... REFERENCES文を実行するユーザーが、REFERENCES句で参照される表を所有していない場合、適用可能な表の列に対するREFERENCESオブジェクト権限が必要です。たとえば、patが次の文を実行するとします。
Command> ALTER TABLE pat.table1 ADD CONSTRAINT fk1 FOREIGN KEY (col1) REFERENCES terry.table2 (pk);
次の権限付与が必要になります。
Command> GRANT REFERENCES (pk) ON terry.table2 TO pat;
REFERENCES権限は、親表から外部キーを作成しているユーザーにSELECT権限を暗黙的に付与することに注意してください。ただし、この暗黙的な付与によって親表のSELECT権限がユーザーに付与されるわけではないため、親表に対する権限がREFERENCESのみの場合は、SELECT文が失敗します。
ユーザーに所有しないビューのSELECTオブジェクト権限を付与すると、そのユーザーはそのビューから選択できるようになります。さらに、ビューの所有者には、そのビューが参照するすべてのオブジェクトに対するSELECTオブジェクト権限が必要です。
ユーザーpatがpatが所有するオブジェクトのみを参照するビューを作成する場合、次の文のように、patにはCREATE VIEW権限のみが必要です。
Command> CREATE VIEW pat.view1 AS SELECT * FROM pat.table1;
patがterryが所有する表を参照するビューを作成する場合、次の文のように、patにはその表に対するSELECTオブジェクト権限も必要です。ビューの所有者には、ビューによって参照される各オブジェクトに対するSELECTオブジェクト権限が付与されている必要があります。
Command> CREATE VIEW pat.view2 AS SELECT * FROM terry.table2;
3人目のユーザーjoeが前述の文を実行するには、CREATE ANY VIEW権限が必要です。また、ビューの所有者としてpatには、terryが所有している表で選択を実行するためにSELECTオブジェクト権限が付与されている必要があります。
ビューから選択すると、実行時にTimesTenでは、必要な基本権限についてそのビューとそのビューによって参照されるビューが検証されます。
次の例を考えてみます。
Command> CREATE VIEW pat.view2 AS SELECT * from terry.table2; Command> CREATE VIEW joe.view4 AS SELECT * from pat.view2, terry.table4;
patがこの文を実行するには、次の権限が付与されている必要があります。
ユーザーpatがjoeに所有されるスキーマにビューを作成できるように、patにCREATE ANY VIEW権限が付与されている必要があります。
ユーザーjoeに、terry.table4に対するSELECTオブジェクト権限が付与されている必要があります。
ユーザーjoeに、pat.view2に対するSELECTオブジェクト権限が付与されている必要があります。
ユーザーpatに、terry.table2に対するSELECTオブジェクト権限が付与されている必要があります。
自分が所有していない順序に対して処理を実行する場合、ユーザーには、SELECTオブジェクト権限が付与されている必要があります。順序に対するSELECT権限を持つユーザーは、最終的にその順序を更新するNEXTVALのような処理も含めて、順序に対するすべての処理を実行できます。
たとえば、hrスキーマのemployees_seq順序に対するSELECT権限をユーザーpatに付与するには、次のようにします。
Command> GRANT SELECT ON hr.employees_seq TO pat;
ユーザーpatは、この後、次の文を使用してこの順序の次の値を生成できます。
Command> SELECT hr.employees_seq.NEXTVAL FROM DUAL; < 207 > 1 row found.
マテリアライズド・ビューを作成するには、ユーザーに少なくともCREATE MATERIALIZED VIEW権限が必要です。別のユーザーのスキーマ内にマテリアライズド・ビューを作成する場合は、CREATE ANY MATERIALIZED VIEW権限が必要です。
さらに、マテリアライズド・ビューの所有者には、そのマテリアライズド・ビュー内のすべてのディテール表に対するCREATE TABLE権限およびSELECT権限が必要です。既存のマテリアライズド・ビューの所有者がそのマテリアライズド・ビューに基づく任意のディテール表に対するSELECT権限を失うと、そのマテリアライズド・ビューは無効になります。
自分が所有していないマテリアライズド・ビューから選択する場合、ユーザーには、そのマテリアライズド・ビューに対するSELECT、INDEXやREFERENCESなどのオブジェクト権限が付与されている必要があります。
|
ノート: マテリアライズド・ビューのステータスは、SYS.DBA_OBJECTS、SYS.ALL_OBJECTSおよびSYS.USER_OBJECTSビューのSTATUS列に示されます。マテリアライズド・ビューの所有者は、USER_OBJECTSビューでそのステータスを確認できます。
また、マテリアライズド・ビューが無効な場合、 さらに、マテリアライズド・ビューについては次のとおりです。
|
シノニムは、データベース・オブジェクトの別名です。シノニムは、オブジェクトの名前や所有者を隠すために使用できるため、セキュリティや利便性を目的として頻繁に使用されます。また、シノニムでSQL文を簡略化できます。シノニムは、シノニムが参照するオブジェクトに関係なく、変更なしでアプリケーションを機能させることができ、独立性を提供します。シノニムはDML文の他、一部のDDLやTimesTen Cache文で使用できます。
ユーザーが、プライベート・シノニムまたはパブリック・シノニムを作成または破棄するには、次の権限が必要です。
表2-1 シノニムの権限
| アクション | 必要な権限 |
|---|---|
|
ユーザー自身のスキーマでプライベート・シノニムを作成します。 |
|
|
他のユーザーのスキーマでプライベート・シノニムを作成します。 |
|
|
パブリック・シノニムを作成します。 |
|
|
ユーザー自身のスキーマでプライベート・シノニムを破棄します。 |
権限は不要です。 |
|
他のユーザーのスキーマでプライベート・シノニムを破棄します。 |
|
|
パブリック・シノニムを破棄します。 |
|
さらに、シノニムを使用するには、ユーザーには、シノニムが参照するオブジェクトに対する適切はアクセス権限が必要です。たとえば、ビューに対するシノニムを作成し、作成したシノニムを使用してビューから選択を行うには、そのビューに対するSELECT権限が必要です。
ALLキーワードを使用すると、オブジェクトに対するすべての権限をユーザーに付与できます。オブジェクトに対する任意の処理を実行する権限がユーザーに付与されます。オブジェクト所有者およびADMIN権限を持つユーザーは、GRANT ALL文およびREVOKE ALL文を実行できます。
たとえば、GRANT ALL ON hr.employees TO patでは、employees表のすべての権限がユーザーpatに付与されます。すべてのオブジェクトに対する権限を付与した後、権限を個別に取り消すことができます。
Command> GRANT ALL ON hr.employees TO pat; Command> REVOKE DELETE ON hr.employees FROM pat;
ここでユーザーpatに対して行われているように、ユーザーに付与されたオブジェクト権限についてREVOKE ALLを実行することもできます。
Command> REVOKE ALL ON hr.employees FROM pat;
この項では、PL/SQLでの認可に関する次のトピックについて説明します。
PL/SQLユーザーの場合、権限の付与による認可は、ユーザーがパッケージおよびそのメンバー・プロシージャやファンクションを含むPL/SQLプロシージャおよびファンクションを作成、変更、破棄または実行できるようにするために必要です。
プロシージャ、ファンクション、パッケージ定義またはパッケージ本体をユーザー自身のスキーマに作成する場合は、CREATE PROCEDURE権限が必要であり、他のスキーマに作成する場合はCREATE ANY PROCEDUREが必要です。プロシージャ、ファンクション、パッケージ定義、またはパッケージ本体を変更または削除するには、その所有者であるか、ALTER ANY PROCEDURE権限またはDROP ANY PROCEDURE権限をそれぞれ持っている必要があります。
ユーザーが所有していないPL/SQLファンクション、PL/SQLプロシージャまたはPL/SQLパッケージを実行するには、プロシージャまたはファンクション、あるいはそれが属するパッケージに対するEXECUTEオブジェクト権限、またはEXECUTE ANY PROCEDUREが付与されている必要があります。ユーザーにパッケージに対するEXECUTE権限を付与すると、そのコンポーネント・プロシージャおよび関数に対するEXECUTE権限が自動的に付与されます。
EXECUTE権限によって、次のことが認可されます。
プロシージャまたは関数を実行します。
パッケージの仕様で宣言されている任意のプログラム・オブジェクトにアクセスします。
現時点で無効または未コンパイルの関数またはプロシージャのコール時にオブジェクトを暗黙的にコンパイルします。
ALTER PROCEDUREまたはALTER FUNCTIONを使用して明示的にコンパイルするには、ユーザーにALTER ANY PROCEDUREシステム権限が付与されている必要があります。
これらを表2-2にまとめます。
表2-2 PL/SQLのプロシージャおよびファンクションを使用するための権限
| アクション | SQL文または操作 | 必要な権限 |
|---|---|---|
|
プロシージャ、ファンクション、パッケージ定義またはパッケージ本体を作成します。 |
|
ユーザーのスキーマでの または 他のスキーマでの |
|
プロシージャ、ファンクションまたはパッケージを変更します。 |
|
プロシージャ、ファンクションまたはパッケージの所有権 または
|
|
プロシージャ、ファンクション、パッケージ定義またはパッケージ本体を削除します。 |
|
プロシージャ、ファンクションまたはパッケージの所有権 または
|
|
プロシージャまたはファンクションを実行します。 |
プロシージャまたはファンクションを起動します。 |
プロシージャまたはファンクション、あるいはこれらが所属するパッケージ(該当する場合)の所有権 または プロシージャまたはファンクション、あるいはこれらが属するパッケージ(該当する場合)に対する または
|
次の文は、user1が所有するプロシージャおよびパッケージに対するEXECUTE権限をuser2に付与してから取り消します。
Command> grant execute on user1.myproc to user2; Command> grant execute on user1.mypkg to user2; ... Command> revoke execute on user1.myproc from user2; Command> revoke execute on user1.mypkg from user2;
|
ノート:
|
例2-1 必要な権限の付与
この例は、ユーザーuser1によって試行される次の一連の操作を示しています。
ユーザーが、必要な権限を付与されていないときに各操作を試行します。その結果、エラーが表示されます。
インスタンス管理者が必要な権限を付与します。
ユーザーは操作の実行に成功します。
user1はttIsqlユーティリティを使用して操作を実行(または試行)し、インスタンス管理者はこのユーティリティを使用して権限を付与します。
user1:
ユーザーは、最初はプロシージャを作成する権限を持っていません。ユーザー自身のスキーマであっても、付与される必要があります。
Command> create procedure testproc is
begin
dbms_output.put_line('user1.testproc called');
end;
/
15100: User USER1 lacks privilege CREATE PROCEDURE
The command failed.
インスタンス管理者:
Command> grant create procedure to user1;
user1:
user1がuser1スキーマでプロシージャを作成できるようになると、そのユーザーがプロシージャを所有し、実行できるようになります。
Command> create procedure testproc is
begin
dbms_output.put_line('user1.testproc called');
end;
/
Procedure created.
Command> begin
testproc();
end;
/
user1.testproc called
PL/SQL procedure successfully completed.
ただし、ユーザーは別のスキーマではまだプロシージャを作成できません。
Command> create procedure user2.testproc is
begin
dbms_output.put_line('user2.testproc called');
end;
/
15100: User USER1 lacks privilege CREATE ANY PROCEDURE
The command failed.
インスタンス管理者:
Command> grant create any procedure to user1;
user1:
user1は別のスキーマでプロシージャを作成できるようになりましたが、所有しない場合や必要な権限がない場合は実行できません。
Command> create procedure user2.testproc is
begin
dbms_output.put_line('user2.testproc called');
end;
/
Procedure created.
Command> begin
user2.testproc();
end;
/
8503: ORA-06550: line 2, column 7:
PLS-00904: insufficient privilege to access object USER2.TESTPROC
8503: ORA-06550: line 2, column 1:
PL/SQL: Statement ignored
The command failed.
インスタンス管理者:
Command> grant execute any procedure to user1;
user1:
user1は、別のスキーマでプロシージャを実行できるようになりました。
Command> begin
user2.testproc();
end;
/
user2.testproc called
PL/SQL procedure successfully completed.
オブジェクトに対するユーザーの権限が取り消されると、そのオブジェクトを参照する、そのユーザーのすべてのPL/SQLオブジェクトが一時的に無効化されます。権限が元に戻されると、ユーザーはオブジェクトに対して適宜ALTER PROCEDURE、ALTER FUNCTIONまたはALTER PACKAGEを実行し、オブジェクトを明示的に再コンパイルおよび再検証できます。また、各オブジェクトは、次に実行されるときに自動的に再コンパイルおよび再検証されます。
たとえば、user1が、user2.proc1をコールするプロシージャuser1.proc0を所有している場合、user1のproc1に対するEXECUTE権限が取り消されると、proc0は無効になります。
次を使用して、無効になっているオブジェクトがないかを確認します。
select * from user_objects where status='INVALID';
例2-2 無効化されたオブジェクト
この例では、無効化されたPL/SQLプロシージャを生成する一連のアクションを示します。
ユーザーがCREATE ANY PROCEDURE権限を付与され、別のユーザーのスキーマにプロシージャを作成してから、その別のユーザーのスキーマにあるプロシージャをコールするプロシージャをユーザー自身のスキーマに作成します。
ユーザーが別のユーザーのスキーマでプロシージャを実行するEXECUTE権限を付与されます。
ユーザーが別のユーザーのスキーマでプロシージャをコールするプロシージャを自身のスキーマで実行します。
ユーザーから、別のユーザーのスキーマのプロシージャに対するEXECUTE権限が取り消され、そのユーザー自身のプロシージャが無効化されます。
ユーザーに、別のユーザーのスキーマのプロシージャに対するEXECUTE権限が再度付与されます。ユーザーが自身のプロシージャを実行すると、プロシージャは暗黙的に再コンパイルおよび再検証されます。
管理ユーザー:
Command> grant create any procedure to user1;
user1:
Command> create procedure user2.proc1 is
begin
dbms_output.put_line('user2.proc1 is called');
end;
/
Procedure created.
Command> create procedure user1.proc0 is
begin
dbms_output.put_line('user1.proc0 is called');
user2.proc1;
end;
/
Procedure created.
管理ユーザー:
Command> grant execute on user2.proc1 to user1;
user1:
Command> begin
user1.proc0;
end;
/
user1.proc0 is called
user2.proc1 is called
PL/SQL procedure successfully completed.
user1が無効なオブジェクトを持っていないことを確認するには、次のように実行します。
Command> select * from user_objects where status='INVALID'; 0 rows found.
管理ユーザー:
ここで、user1のEXECUTE権限を取り消します。
Command> revoke execute on user2.proc1 from user1;
user1:
user1にはuser2.proc1を実行する権限がなくなったため、即座にuser1.proc0は無効になります。
Command> select * from user_objects where status='INVALID'; < PROC0, <NULL>, 273, <NULL>, PROCEDURE, 2019-06-04 14:51:34, 2019-06-04 14:58:23, 2019-06-04:14:58:23, INVALID, N, N, N, 1, <NULL> > 1 row found.
このため、user1はプロシージャを実行できなくなりました。
Command> begin
user1.proc0;
end;
/
8503: ORA-06550: line 2, column 7:
PLS-00905: object USER1.PROC0 is invalid
8503: ORA-06550: line 2, column 1:
PL/SQL: Statement ignored
The command failed.
管理ユーザー:
再度user2.proc1へのEXECUTE権限をuser1に付与します。
Command> grant execute on user2.proc1 to user1;
user1:
プロシージャuser1.proc0は、明示的または暗黙的に再コンパイルされるまで無効のままです。次に示すとおり、実行時に暗黙的に再コンパイルされます。または、ALTER PROCEDUREを使用して明示的に再コンパイルすることができます。
Command> select * from user_objects where status='INVALID'; < PROC0, <NULL>, 273, <NULL>, PROCEDURE, 2019-06-04 14:51:34, 2019-06-04 16:13:00, 2019-06-04:16:13:00, INVALID, N, N, N, 1, <NULL> > 1 row found. Command> begin user1.proc0; end; / user1.proc0 is called user2.proc1 is called PL/SQL procedure successfully completed. Command> select * from user_objects where status='INVALID'; 0 rows found.
PL/SQLのプロシージャまたはファンクションを定義するときに、CREATE FUNCTION文またはCREATE PROCEDURE文のオプションのAUTHID句で、プロシージャまたはファンクションを定義者権限(AUTHID DEFINER、デフォルト)で実行するか、実行者権限(AUTHID CURRENT_USER)で実行するかを指定します。
AUTHIDの設定は、実行時にプロシージャまたはファンクションによって発行されるSQL文の名前解決および権限チェックに影響を与えます。定義者権限の場合、SQLの名前解決および権限チェックは、プロシージャまたはファンクションの所有者(定義者、つまりプロシージャまたはファンクションがあるスキーマの所有者)が実行しているものとして実行されます。実行者権限の場合、SQLの名前解決および権限チェックは、現在のユーザー(実行者)が実行しているものとして実行されます。
パッケージ内のプロシージャまたはファンクションでは、CREATE PACKAGE文のAUTHID句で、パッケージのメンバーのファンクションまたはプロシージャそれぞれを定義者権限で実行するか、実行者権限で実行するかを指定します。AUTHID句の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のSQL文に関する説明で、これらの文の構文に関する記述を参照してください。
実行者権限は、コード本体に対しては広範囲な権限を付与する一方で、そのコードの影響範囲を各ユーザーのスキーマ内の自分のオブジェクトに限定する場合に役立ちます。
定義者権限は、すべてのユーザーが1つの集中管理された表またはその他のSQLオブジェクトにアクセスできるようにするものの、プロシージャによって実行される操作を特定の操作に制限する場合に役立ちます。それ以外の場合、ユーザーはSQLオブジェクトにはアクセスできません。
詳細は、『Oracle Database PL/SQL言語リファレンス』の実行者権限および定義者権限(AUTHIDプロパティ)に関する説明を参照してください。
例2-3 定義者権限または実行者権限のAUTHID句
この例では、変更を1つだけ加えてスクリプトをttIsqlで2回実行します(最初は実行者権限のAUTHID CURRENT_USERでPL/SQLプロシージャを定義し、次に定義者権限のAUTHID DEFINERで定義します)。
AUTHIDのスクリプトの例:
スクリプトでは、1人のツール・ベンダーと2人のツール・ユーザー(brandXおよびbrandY)の、3人のユーザーが作成されていることを想定しています。各ユーザーには、必要に応じて、CREATE SESSION権限、CREATE PROCEDURE権限およびCREATE TABLE権限が付与されています。また、use username;構文を使用してusernameとしてデータベースに接続できるよう、次の設定が想定されています。
connect adding "uid=toolVendor;pwd=pw" as toolVendor; connect adding "uid=brandX;pwd=pw" as brandX; connect adding "uid=brandY;pwd=pw" as brandY;
スクリプトでは、次の操作を実行します。
ツール・ベンダーとして、プロシージャprintInventoryStatisticsを作成します。
3つのユーザー・スキーマのそれぞれに同じmyInventoryという名前の表を作成し、それぞれの表に一意のデータを移入します。
それぞれのツール・ユーザーとして、プロシージャを実行します。
2回のスクリプト実行の結果の違いは、実行者権限と定義者権限の違いを示しています。
次に、実行者権限で実行する場合のスクリプトを示します。
use toolVendor;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('butter', 1);
create or replace procedure printInventoryStatistics authid current_user is
inventoryCount pls_integer;
begin
select count(*) into inventoryCount from myInventory;
dbms_output.put_line('Total items in inventory: ' || inventoryCount);
for currentItem in (select * from myInventory) loop
dbms_output.put_line(currentItem.name || ' ' || currentItem.inventoryCount);
end loop;
end;
/
grant execute on printInventoryStatistics to brandX;
grant execute on printInventoryStatistics to brandY;
use brandX;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('toothpaste', 100);
set serveroutput on
execute toolVendor.printInventoryStatistics;
use brandY;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('shampoo', 10);
set serveroutput on
execute toolVendor.printInventoryStatistics;
定義者権限スクリプトの違いは、プロシージャ定義のAUTHID句を変更することのみです。
...
create or replace procedure printInventoryStatistics authid definer is
inventoryCount pls_integer;
begin
select count(*) into inventoryCount from myInventory;
dbms_output.put_line('Total items in inventory: ' || inventoryCount);
for currentItem in (select * from myInventory) loop
dbms_output.put_line(currentItem.name || ' ' || currentItem.inventoryCount);
end loop;
end;
/
...
AUTHID CURRENT_USERの使用
ここでは、実行者権限を使用してプロシージャを定義した場合の結果について説明しています。ツール・ユーザーbrandXおよびbrandYがprintInventoryStatisticsプロシージャを実行すると、それぞれのユーザー専用の(実行者の)myInventory表のデータが表示されることに注意してください。
Command> run invoker.sql
use toolVendor;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('butter', 1);
1 row inserted.
create or replace procedure printInventoryStatistics authid current_user is
inventoryCount pls_integer;
begin
select count(*) into inventoryCount from myInventory;
dbms_output.put_line('Total items in inventory: ' || inventoryCount);
for currentItem in (select * from myInventory) loop
dbms_output.put_line(currentItem.name || ' ' || currentItem.inventoryCount);
end loop;
end;
/
Procedure created.
grant execute on printInventoryStatistics to brandX;
grant execute on printInventoryStatistics to brandY;
use brandX;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('toothpaste', 100);
1 row inserted.
set serveroutput on;
execute toolVendor.printInventoryStatistics;
Total items in inventory: 1
toothpaste 100
PL/SQL procedure successfully completed.
use brandY;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('shampoo', 10);
1 row inserted.
set serveroutput on;
execute toolVendor.printInventoryStatistics;
Total items in inventory: 1
shampoo 10
PL/SQL procedure successfully completed.
次のコマンドを使用して、すべての接続を終了します。
Command> disconnect all;
AUTHID DEFINERの使用
ここでは、定義者権限を使用してプロシージャを定義した場合の結果について説明しています。ツール・ユーザーbrandXおよびbrandYがprintInventoryStatisticsを実行すると、ツール・ベンダー(定義者)に属するmyInventoryのデータが表示されることに注意してください。
Command> run definer.sql
use toolVendor;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('butter', 1);
1 row inserted.
create or replace procedure printInventoryStatistics authid definer is
inventoryCount pls_integer;
begin
select count(*) into inventoryCount from myInventory;
dbms_output.put_line('Total items in inventory: ' || inventoryCount);
for currentItem in (select * from myInventory) loop
dbms_output.put_line(currentItem.name || ' ' || currentItem.inventoryCount);
end loop;
end;
/
Procedure created.
grant execute on printInventoryStatistics to brandX;
grant execute on printInventoryStatistics to brandY;
use brandX;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('toothpaste', 100);
1 row inserted.
set serveroutput on;
execute toolVendor.printInventoryStatistics;
Total items in inventory: 1
butter 1
PL/SQL procedure successfully completed.
use brandY;
create table myInventory (name varchar2(100), inventoryCount tt_integer);
insert into myInventory values('shampoo', 10);
1 row inserted.
set serveroutput on;
execute toolVendor.printInventoryStatistics;
Total items in inventory: 1
butter 1
PL/SQL procedure successfully completed.
この場合、brandXおよびbrandYはそれぞれプロシージャを介してtoolVendor.myInventory表にアクセスできますが、直接にはアクセスできないことを理解しておくことも有用です。定義者権限を主にこのように使用することによって、プロシージャのアクションを介して表または他のSQLオブジェクトに明確に制限付きでアクセスできるようになります。
Command> use brandX; brandx: Command> select * from toolVendor.myInventory; 15100: User BRANDX lacks privilege SELECT on TOOLVENDOR.MYINVENTORY The command failed. brandx: Command> use brandY; brandy: Command> select * from toolVendor.myInventory; 15100: User BRANDY lacks privilege SELECT on TOOLVENDOR.MYINVENTORY The command failed.
終了したら、すべての接続を終了します。
Command> disconnect all;
キャッシュ・グループに対するシステム権限およびオブジェクト権限があります。ユーザーがキャッシュ・グループに関係する操作を実行するためには、適切なキャッシュ・グループ権限を持っている必要があります。
さらに、特別な権限が必要な管理ユーザー、つまり、キャッシュ管理ユーザー(Oracle Databaseユーザー)およびキャッシュ・マネージャ・ユーザー(TimesTenユーザー)があります。
これらの項では、キャッシュ・グループのユーザーおよび権限について説明します。
これらのユーザーの概要は、キャッシュ・グループ・ユーザーを参照してください。
キャッシュ・グループ処理のためのシステム権限とオブジェクト権限の完全なリストは、Oracle TimesTen In-Memory Database SQLリファレンスの権限を参照してください。
|
ノート: パススルーの場合、権限はOracleデータベースによってユーザー資格証明を使用してチェックされるため、キャッシュ・グループ権限は必要ありません。 |
Oracle Databaseで、SYSユーザーとしてtimesten_home/install/oraclescriptsディレクトリでSQL*PlusスクリプトgrantCacheAdminPrivileges.sqlを実行し、キャッシュ管理ユーザーに、キャッシュ操作の実行に必要な最小限の権限セットを付与します。
詳細は、Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドのOracle Databaseユーザーへの権限の付与を参照してください。
TimesTenのキャッシュ・マネージャ・ユーザーに必要な権限はCACHE_MANAGERシステム権限です。これにより、ユーザーは必要なキャッシュ・グループ処理を実行できます。ユーザーが読取り専用キャッシュ・グループの初期ロードを実行したり、読取り専用キャッシュ・グループの自動リフレッシュ状態を変更するには、CACHE_MANAGER権限が必要です。(初期ロードを実行すると、キャッシュ・グループの自動リフレッシュの状態が一時停止からオンに暗黙的に変更されます。)
個々のキャッシュ・グループ処理権限の完全なリストは、Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドのキャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限を参照してください。
これは、CACHE_MANAGER権限をpatに付与します。
Command> GRANT CACHE_MANAGER TO pat;
キャッシュ・グループまたはキャッシュ表に対する処理(キャッシュ・グループのロードやキャッシュ表の更新など)は、十分な権限を持ついずれのTimesTenユーザーでも実行できます。これらのユーザーには、キャッシュされたOracle Database表から選択して更新する権限を持つ、同じ名前の対応するOracle Databaseユーザーが必要です。
関連情報は、Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドのTimesTenユーザーの作成およびTimesTenユーザーへの権限の付与を参照してください。
それぞれのキャッシュ・グループ権限については、次の項で説明します。
キャッシュ・グループのシステム権限を持つユーザーは、データベース全体でキャッシュ・グループ・オブジェクトを操作できます。
キャッシュ・グループを作成するには、CREATE CACHE GROUPシステム権限またはCREATE ANY CACHE GROUPシステム権限が必要です。さらに、基礎となるキャッシュ表を作成するには、その表を自分が所有するかどうかに応じて、CREATE ANY TABLE権限またはCREATE TABLE権限のいずれかが付与される必要があります。
自分が所有していないキャッシュ・グループを破棄または変更する場合、ユーザーには、適宜DROP ANY CACHE GROUP権限またはALTER ANY CACHE GROUP権限が付与されている必要があります。さらに、ユーザーが、自分が所有していない基礎となるキャッシュ表を破棄するには、DROP ANY TABLE権限を付与される必要があります。
たとえば、次の例では、データベースに含まれる任意のキャッシュ・グループを変更する権限をユーザーに付与します。
Command> GRANT ALTER ANY CACHE GROUP TO pat;
これらのキャッシュ・グループのシステム権限は、ユーザーが所有していないオブジェクトに対する操作用です。
キャッシュ・グループ処理のオブジェクト権限により、ユーザーは、自分が所有していない特定のキャッシュ・グループに対して特定の処理を実行できます。使用可能なキャッシュ・グループのオブジェクト権限は次のとおりです。
この例では、terryが所有するキャッシュ・グループcachegrpに対してFLUSHを実行するために、patにキャッシュ・グループ・オブジェクト権限を付与します。
Command> GRANT FLUSH ON terry.cachegrp TO pat;
キャッシュ・グループ処理の詳細は、Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドのキャッシュ・グループの処理を参照してください。
各ユーザーに付与された権限を表示するには、次のビューを使用します。
表2-3 システム権限ビュー
| ビュー名 | 説明 |
|---|---|
|
現在のユーザーに付与されているすべてのシステム権限を戻します。 |
|
|
すべてのユーザーに付与される、 |
|
|
現在のユーザーに付与されているすべてのオブジェクト権限を戻します。 |
|
|
ユーザーに対して |
|
|
すべてのユーザーに付与される、 |
この例では、すべてのユーザーに付与されているシステム権限を表示します。
Command> SELECT * FROM SYS.DBA_SYS_PRIVS; < SYS, ADMIN, YES > < SYSTEM, ADMIN, YES > < TERRY, ADMIN, YES > < TERRY, CREATE ANY TABLE, NO > < PAT, CACHE_MANAGER, NO > 5 rows found.
|
注意: これらのビューの詳細は、Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンスのシステム表およびビューを参照してください。 |
