| Oracle® Databaseオブジェクト・リレーショナル開発者ガイド 11gリリース2 (11.2) E94920-01 |
|
 前 |
 次 |
この章では、Oracleオブジェクトがデータベースの他の部分と関連してどのように機能するか、またDML操作およびDDL操作をどのように実行するかについて説明します。内容は次のとおりです。
オブジェクト型に対する権限は、システム・レベルおよびスキーマ・オブジェクト・レベルで存在します。
この項の内容は次のとおりです。
Oracleデータベースでは、オブジェクト型に次のシステム権限を定義します。
CREATE TYPE: 自分のスキーマにオブジェクト型を作成できます。
CREATE ANY TYPE: 任意のスキーマにオブジェクト型を作成できます。
ALTER ANY TYPE: 任意のスキーマ内のオブジェクト型を変更できます。
DROP ANY TYPE: 任意のスキーマ内のオブジェクト型を削除できます。
EXECUTE ANY TYPE: 任意のスキーマ内のオブジェクト型を使用および参照できます。
UNDER ANY TYPE: 任意のNOT FINALオブジェクト型の下にサブタイプを作成できます。
UNDER ANY VIEW: 任意のオブジェクト・ビューの下にサブビューを作成できます。
次のロールが有用です。
RESOURCEロールには、CREATE TYPEシステム権限が含まれます。
DBAロールには、前述のすべての権限が含まれます。
オブジェクト型には、2つのスキーマ・オブジェクト権限が適用されます。
EXECUTE権限があると、その型を次のように使用できます。
表の定義
リレーショナル表の列の定義
オブジェクト型の変数またはパラメータの宣言
EXECUTEは、コンストラクタなどの型のメソッドを起動します。
メソッド実行および対応する権限は、ストアドPL/SQLプロシージャのものと同じです。
UNDERは、権限が与えられた型またはビューの下にサブタイプまたはサブビューを作成します。
直系のスーパータイプまたはスーパービューについてUNDER権限をWITH GRANT OPTION付きで持っている権限付与者のみ、サブタイプまたはサブビューに対するUNDER権限が付与されます。
WITH HIERARCHY OPTION句は、オブジェクトのすべてのサブタイプについて指定されたオブジェクト権限を付与します。このオプションが意味を持つのは、オブジェクト・ビュー階層内のオブジェクト・ビューにSELECTオブジェクト権限が付与されている場合のみです。この場合、権限が付与されているビューのサブビューすべてに、権限が適用されます。
次の場合は、前述の項で説明した権限の他に、特定の権限が必要です。
別のユーザーが作成した型を使用する型または表を作成する場合
新しく作成した型または表の使用権限を別のユーザーに付与する場合
EXECUTE ANY TYPEシステム権限、または新しい型または表を定義するために使用される型に対するEXECUTEオブジェクト権限が必要です。ロールを介してではなく、これらの権限を明示的に付与しておく必要があります。
新しい型または表へのアクセス権限を他のユーザーに付与するには、Grantオプションを含む適切なEXECUTEオブジェクト権限、またはオプションWITH ADMIN OPTIONを含むEXECUTE ANY TYPEシステム権限が必要です。ロールを介してではなく、これらの権限を明示的に付与しておく必要があります。
例7-1では、3つのユーザーまたはスキーマUSER1、USER2およびUSER3を作成し、CREATE SESSIONおよび RESOURCEロールを付与します。この章の後続の例でこれらのスキーマを使用する場合があります。
この例では、複数のパスワードを作成および使用する必要があります。例を実行する場合、最初にSQLコードに対してこれらの変更を行います。
|
注意: 簡略化のため、この例では、デプロイされたシステムで通常使用するパスワード管理技法を実行しません。本番環境では、Oracle Databaseパスワード管理ガイドラインに従って、サンプル・アカウントを無効にしてください。パスワード管理ガイドラインおよび他のセキュリティ推奨事項は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
例7-1 ユーザー・スキーマの作成
-- Requires passwords
CONNECT SYSTEM
-- Enter password
CREATE USER user1 PROFILE default
IDENTIFIED BY password DEFAULT TABLESPACE example ACCOUNT UNLOCK;
GRANT CREATE SESSION TO user1;
GRANT RESOURCE TO user1;
GRANT CREATE SYNONYM TO user1;
GRANT CREATE PUBLIC SYNONYM TO user1;
GRANT DROP PUBLIC SYNONYM TO user1;
CREATE USER user2 PROFILE default
IDENTIFIED BY password DEFAULT TABLESPACE example ACCOUNT UNLOCK;
GRANT CREATE SESSION TO user2;
GRANT RESOURCE TO user2;
CREATE USER user3 PROFILE default
IDENTIFIED BY password DEFAULT TABLESPACE example ACCOUNT UNLOCK;
GRANT CREATE SESSION TO user3;
GRANT RESOURCE TO user3;
例7-2ではパスワードの入力が必要で、USER1は、USER1スキーマのCREATEおよびGRANTデータ定義言語(DDL)文を実行します。
CREATE TYPE type1 AS OBJECT ( attr1 NUMBER );
/
CREATE TYPE type2 AS OBJECT ( attr2 NUMBER );
/
GRANT EXECUTE ON type1 TO user2;
GRANT EXECUTE ON type2 TO user2 WITH GRANT OPTION;
例7-3で、USER2は、USER2スキーマのCREATE DDL文を実行します。
例7-3 USER2スキーマのDDL文の実行
-- Requires Ex. 7-1, 7-2 and password input CONNECT user2 -- Enter password CREATE TABLE tab1 OF user1.type1; CREATE TYPE type3 AS OBJECT ( attr3 user1.type2 ); / CREATE TABLE tab2 (col1 user1.type2 );
例7-4では、例7-2の最後の行でUSER2に対してUSER1のTYPE2にGRANTオプションを使用したEXECUTE権限が付与され、例7-3でattr3 user1.type2を使用してオブジェクトとしてtype3が作成されたため、最初の2つの文が正常に実行されます。
ただし、USER2にUSER1.TYPE1のGRANTオプションを使用したEXECUTE権限が付与されていないため、例7-4の最後の付与は失敗します。
例7-4 USER3への付与の実行
-- Requires Ex. 7-1, 7-2, and 7-3 GRANT EXECUTE ON type3 TO user3; GRANT SELECT ON tab2 TO user3; -- Privileges on Object Types GRANT SELECT ON tab1 TO user3 -- incorrect statement;
例7-5で、USER3には、次の処理を実行するために必要な権限があります。
オブジェクト型はEXECUTE権限のみを使用しますが、オブジェクト表はリレーショナル表と同じ次のすべての権限を使用します。
SELECT: 表から1つのオブジェクトおよびその属性にアクセスできます。
UPDATE: 表内のオブジェクトの属性を変更できます。
INSERT: 表に新しいオブジェクトを追加できます。
DELETE: 表からオブジェクトを削除できます。
同様の表権限および列権限が、オブジェクト型の表列の使用を規制します。
オブジェクト表の列を選択するには、オブジェクト表の型に対する権限は必要ありません。ただし、行全体を選択するには必要です。
例7-6に示すスキーマと問合せを考えてみます。
例7-6 型へのアクセスのSELECT権限
-- Requires Ex. 7-1, 7-2, 7-3, 7-4, and 7-5 CREATE TYPE emp_type AS OBJECT ( eno NUMBER, ename VARCHAR2(36)); / CREATE TABLE emp OF emp_type; // an object table GRANT SELECT on emp TO user1; SELECT VALUE(e) FROM emp e; SELECT eno, ename FROM emp;
どちらの問合せの場合も、Oracleデータベースはオブジェクト表empに対するユーザーのSELECT権限をチェックします。最初の問合せの場合、データを解析するには、ユーザーはemp_type型情報を取得する必要があります。問合せがemp_type型にアクセスすると、ユーザーのEXECUTE権限をチェックします。
2番目の問合せは、指定された型を必要としません。そのため、型権限をチェックしません。
また、USER3は次のような問合せを実行できます。
SELECT t.col1.attr2 from user2.tab2 t; SELECT t.attr4.attr3.attr2 FROM tab3 t;
両方の問合せで、USER3は基礎となる型の明示的な権限を持っていないことに注意してください。ただし、型および表所有者はGRANTオプションを含む必要な権限を持っているため、この文は正常に実行されます。
次の要求についての権限をチェックし、ユーザーに各処理に対する権限がない場合はエラーを戻します。
REF値を使用してオブジェクト・キャッシュ内に1つのオブジェクトを確保すると、そのオブジェクトを含むオブジェクト表に対するSELECT権限、およびそのオブジェクト型に対するEXECUTE権限をチェックします。
|
関連項目: OCIプログラムをオブジェクトとともに効果的に使用するためのヒントおよび技法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 |
既存オブジェクトの変更、またはオブジェクト・キャッシュからのオブジェクトのフラッシュを行うと、接続先オブジェクト表に対するUPDATE権限をチェックします。新しいオブジェクトをフラッシュすると、接続先オブジェクト表に対するINSERT権限をチェックします。
メソッドを起動すると、対応するオブジェクト型に対するEXECUTE権限をチェックします。
この項では、2つの概要カテゴリで型依存性について説明します。
型が定義に対して相互に依存し、一方の型が他方の型の定義の一部である可能性がある状況。
型の作成または削除が表や型などの型が持つ依存性によって複雑になる状況。
この項の内容は次のとおりです。
直接的または中間の型を介して定義に対して互いに依存する型を、相互依存といいます。たとえば、employeeの1つの属性を従業員が属する部門にし、departmentの1つの属性を部門を管理する従業員にするように、オブジェクト型employeeおよびdepartmentを定義できます。
矢印を使用して一連の相互依存型の関係を示す図を視覚化する場合、つながりがループを形成します。そのような循環依存を定義するには、サークルの最小限1つのセグメントにREFを使用する必要があります。
たとえば、例7-7に示す型を定義できます。
例7-7 依存オブジェクト型の作成
-- Requires Ex. 7-1 and password CONNECT user1 -- Enter password ALTER SESSION SET PLSQL_WARNINGS = 'enable:all'; CREATE TYPE department; // a placeholder / CREATE TYPE employee AS OBJECT ( name VARCHAR2(30), dept REF department, supv REF employee ); / CREATE TYPE emp_list AS TABLE OF employee; / CREATE TYPE department AS OBJECT ( name VARCHAR2(30), mgr REF employee, staff emp_list ); /
これは、適切な相互依存型におけるSQL DDL文の適切な順序です。これをエラーなしでコンパイルします。
例7-7のコードはdepartment型を2回作成することに注意してください。最初の文は、employeeのREF属性が指すプレースホルダとして機能するdepartmentの不完全な宣言です。AS OBJECT句が省略され、属性またはメソッドがリストされていない点で、この宣言は不完全です。これらは、後述の型を完成させる完全な宣言で指定します。ここでは、departmentを不完全なオブジェクト型として作成しておきます。これにより、employeeがエラーなしでコンパイルできます。
不完全な型をプレースホルダとして作成しない場合、その型を参照する型はコンパイルされますが、コンパイル・エラーが発生します。たとえば、departmentが存在しない場合、それを不完全な型として作成し、employeeはコンパイル・エラーになります。この場合、次回なんらかの操作がこの型にアクセスする際に、employeeが再コンパイルされます。この型が依存するすべての型が作成され、その依存性が完全な場合、エラーなしでコンパイルされます。
不完全な型を使用することにより、まだ作成されていないサブタイプに対するREF属性を格納する型も作成できます。こうしたスーパータイプを作成するには、参照するサブタイプの不完全な型を最初に作成します。完全なサブタイプは、スーパータイプ作成後に作成します。
不完全な型が参照するすべての型を作成したら、不完全な型が不完全な状態を維持する必要がなくなるため、不完全な型の宣言を再定義してください。型を再定義すると、型が再コンパイルされ、システムが様々なロックを解放できるようになります。
不完全な型を再定義するには、例7-7の最後に示すとおり、型の属性およびメソッドを指定するCREATE TYPE文を実行します。
データベースによって作成される不完全な型も再定義する必要があります。前述の項で説明したように、不完全な型としてdepartmentを明示的に作成しなかった場合、データベースによって作成されました。この場合、引き続き再定義する必要があります。
不完全なオブジェクト型は、オブジェクト型として再定義する必要があります。オブジェクト型をコレクション型(ネストした表型または配列型)として再定義することはできません。その型を削除することはできます。
型の作成でコンパイル・エラーが発生し、その型に対してなんらかの操作(表の作成、行の挿入など)を実行しようとした場合、エラーが発生することがあります。この操作を行う前に、タイプを再コンパイルする必要があります。手動で型を再コンパイルする場合は、ALTER TYPE typename COMPILE文を実行します。型のコンパイルが正常に実行された後、操作を再試行してください。
CREATE OR REPLACE TYPE文は、置換される型に表または型の依存性がある場合にエラーをスローします。これは、オブジェクト、VARRAYおよびネストした表の型に適用されます。また、継承または型の合成(一方の型をもう一方の型に埋め込む)に関連する型の依存性にも適用されます。継承または型の合成では、一方の型がもう一方の属性である場合があります。
CREATE OR REPLACE TYPE文でFORCEオプションを使用すると、型の依存性がある場合に型を置換できますが、表の依存性がある場合には置換できません。表の依存性はエラーの原因になります。
例7-8に、型の依存性が原因で失敗するCREATE OR REPLACE文を示します。
例7-8 CREATE OR REPLACEの型と表のエラー
SQL> CREATE type t1 AS OBJECT (a number) not final;
2 /
Type created.
SQL> CREATE TYPE t2 UNDER t1 (b varchar(10));
2 /
Type created.
SQL> CREATE OR REPLACE TYPE t1 AS OBJECT (c varchar(20));
2 /
CREATE OR REPLACE TYPE t1 AS OBJECT (c varchar(20));
*
ERROR at line 1:
ORA-02303: cannot drop or replace a type with type or table dependents
例7-9に示したコードでは、CREATE OR REPLACE FORCE文は、型の依存性を持つ型を置換した後で、親の型を使用した表の作成に成功します。ただし、最後のCREATE OR REPLACE FORCE文は、型が表の依存性を持つようになったため、失敗します(FORCEオプションを使用しても、表の依存性を持つ型は置換できません)。
例7-9 FORCEを指定したCREATE OR REPLACE
SQL> CREATE OR REPLACE TYPE t1 FORCE AS OBJECT (c varchar(20));
2 /
Type created.
SQL> CREATE TABLE tb1 (c1 t1);
Table created.
SQL> CREATE OR REPLACE TYPE t1 FORCE AS OBJECT (d number);
2 /
CREATE OR REPLACE TYPE t1 FORCE AS OBJECT (d number);
*
ERROR at line 1:
ORA-22866: cannot replace a type with table dependents
|
関連項目: SQL文CREATE OR REPLACE TYPEの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。 |
特定の型の代入可能な表または列は、その型のみでなく型のすべてのサブタイプも依存します。それは、型のサブタイプで追加されたそれぞれの属性について、非表示列が表に追加されることからもわかります。代入可能な表または列に、このサブタイプのデータが何も入っていない場合も、非表示列は追加されます。
例7-10で、型person_typのpersons表は、person_typのみでなく、person_typのサブタイプであるstudent_typおよびpart_time_student_typにも依存します。
依存型、表または列を持つサブタイプを削除しようとすると、DROP TYPE文はエラーを戻し、異常終了します。したがって、part_time_student_typは、persons表に依存しているので、削除しようとすると、エラーとなります。
依存表または依存列が存在しても、削除する型のデータが何も入っていない場合は、VALIDATEキーワードを使用して、型を削除できます。VALIDATEキーワードが使用されていると、指定された型のインスタンスが実際に格納されているかどうかを調べ、何も見つからなければ、型を削除します。型に固有の属性と関連付けられた非表示列も削除されます。
例7-10で、part_time_student_typに依存表(persons)があるため、最初のDROP TYPE文に失敗します。ただし、personsにpart_time_student_typのインスタンスが何も入っていなければ(および他の依存表または依存列のいずれも入っていなければ)、VALIDATEキーワードにより2番目のDROP TYPE文は正常に実行されます。
例7-10 VALIDATEを使用するおよび使用しないDROP TYPE
CREATE TYPE person_typ AS OBJECT (
idno NUMBER,
name VARCHAR2(30),
phone VARCHAR2(20))
NOT FINAL;
/
CREATE TYPE student_typ UNDER person_typ (
dept_id NUMBER,
major VARCHAR2(30))
NOT FINAL;
/
CREATE TYPE part_time_student_typ UNDER student_typ (number_hours NUMBER);
/
CREATE TABLE persons OF person_typ;
-- Following generates an error due to presence of Persons table
DROP TYPE part_time_student_typ -- incorrect statement;
-- Following succeeds if there are no stored instances of part_time_student_typ
DROP TYPE part_time_student_typ VALIDATE;
|
注意: サブタイプの削除中に、VALIDATEオプションを使用することをお薦めします。 |
DROP TYPE文にはFORCEオプションもあり、このオプションを使用すると、型に依存型または依存表がある場合でも、型が削除されます。存在するすべての依存型または依存表に無効のマークが付けられ、型が削除されたときにアクセス不能になるので、FORCEオプションは慎重に使用します。この理由で無効になった表のデータに、再びアクセスすることはできません。こうした表に対して実行できる操作は、削除のみです。
型の変更方法の詳細は、「型進化」を参照してください。
表、ビューおよびその他の様々なスキーマ・オブジェクトについてシノニムが作成できるように、オブジェクト型についてもシノニムを定義できます。
型のシノニムは、基礎となるスキーマ・オブジェクトを場所に依存せずに参照する手段となるため、他の種類のスキーマ・オブジェクトのシノニムと同じ利点があります。パブリック・タイプのシノニムを使用するアプリケーションは、データベースのスキーマを変更せずにデプロイでき、スキーマの名前で型の名前を修飾する必要はありません。
|
関連項目: シノニムの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
この項の内容は次のとおりです。
型のシノニムは、CREATE SYNONYM文で作成します。ユーザーには、CREATE SYNONYMおよび CREATE PUBLIC SYNONYM権限を付与しておく必要があります。
たとえば、これらの文はtyp1型を作成し、次にこの型のシノニムを作成します。
例7-11 user1のCREATE TYPE / SYNONYM
-- Example requires Ex.7-1 which created user1 and granted it the CREATE SYNONYM
-- and CREATE PUBLIC SYNONYM privileges
-- connect as user1 if not already connected.
CREATE TYPE typ1 AS OBJECT (x number);
/
CREATE SYNONYM syn1 FOR typ1;
シノニムは、コレクション型についても作成できます。次の例は、ネストした表型のシノニムを作成します。
CREATE TYPE typ2 AS TABLE OF NUMBER;
/
CREATE SYNONYM syn2 FOR typ2;
パブリック・シノニムは、PUBLICキーワードを使用して作成します。
CREATE TYPE shape AS OBJECT ( name VARCHAR2(10) );
/
CREATE PUBLIC SYNONYM pub_shape FOR shape;
REPLACEオプションを使用すると、シノニムが指す基礎となる型を別の型に変更できます。たとえば、次の文は、syn1が指す型をtyp2型に変更します。
CREATE OR REPLACE SYNONYM syn1 FOR typ2;
型のシノニムは、型を参照できるすべての場所で使用できます。たとえば、DDL文の中で型のシノニムを使用して、表列の型または型属性を指定できます。
例7-12では、シノニムsyn1を使用して、属性の型をtyp3型に指定します。
例7-12 CREATE文での型のシノニムの使用
-- Requires Ex 7-1 and connection as user1 -- drop syn1 and typ1 if created for Ex. 7-12 CREATE TYPE typ1 AS OBJECT (x number); / CREATE SYNONYM syn1 FOR typ1; CREATE TYPE typ3 AS OBJECT ( a syn1 ); /
次の文で、型のシノニムsyn1は、syn1をシノニムとするオブジェクト型typ1のコンストラクタをコールします。この文は、typ1のオブジェクト・インスタンスを戻します。
SELECT syn1(0) FROM dual;
次の例は、syn2がネストした表型のシノニムです。シノニムは、CAST式の実際の型の名前と置き換わります。
SELECT CAST(MULTISET(SELECT eno FROM USER3.EMP) AS syn2) FROM dual;
このコードは、次の出力を戻します。
SQL> -- Type synonym used to call a constructor / nested tableSELECT syn1(0) FROM dual;SELECT CAST(MULTISET(SELECT eno FROM USER3.EMP) AS syn2) FROMdual;SQL> SYN1(0)(X)----------------------------------------------------------------TYP1(0)SQL>CAST(MULTISET(SELECTENOFROMUSER3.EMP)ASSYN2)----------------------------------------------------------------TYP2()型のシノニムは、次のような文で使用できます。
DML文: SELECT、INSERT、UPDATE、DELETE、FLASHBACK TABLE、EXPLAIN PLANおよびLOCK TABLE
DDL文: AUDIT、NOAUDIT、GRANT、REVOKEおよびCOMMENT
型のシノニムを使用して型または表が作成されると、DESCRIBEコマンドにより、これらのシノニムが表す型のかわりにシノニムが表示されます。同様に、型の名前を示すカタログ・ビュー(USER_TYPE_ATTRSなど)には、型のシノニムの名前が表示されます。
カタログ・ビューUSER_SYNONYMSを問い合せると、型のシノニムの基礎となる型を確認できます。
|
関連項目: データ・ディクショナリ・カタログ・ビューの完全リストは、『Oracle Databaseリファレンス』の第2章を参照してください。 |
型の宣言でシノニムを直接的または間接的に参照する型は、そのシノニムに依存します。したがって、例7-12の次の行に示す型typ3は、シノニムsyn1に依存する型です。
CREATE TYPE typ3 AS OBJECT ( a syn1 ); /
DDL文でシノニムを参照する他の種類のスキーマ・オブジェクトも、これらのシノニムに依存します。型のシノニムに依存するオブジェクトは、シノニムとシノニムの基礎になる型のどちらにも依存します。
シノニムの依存関係によって、シノニムが削除できるかどうか、または名前が変更できるかどうかが決まります。また、依存スキーマ・オブジェクトも、シノニムに対する操作の影響を受けます。次の項では、これらの様々な影響について説明します。
シノニムに依存表または有効なユーザー定義型が存在しない場合にのみ、シノニムは置換できます。シノニムを置換することは、シノニムを削除してから、同じ名前で新しいシノニムを再作成することと同等です。
例7-13のように、シノニムはDROP SYNONYM文で削除します。
型のシノニムに依存表または有効なオブジェクト型がある場合、型のシノニムを削除するには、FORCEオプションが必要です。FORCEオプションは、列の実際の型が削除された場合と同様に、直接的または間接的にシノニムに依存する列を、未使用とマークします。(たとえば、シノニムを使用して、列の宣言された型の属性の型を指定すると、列は間接的にそのシノニムに依存します。)
削除されたシノニムに依存するすべてのスキーマ・オブジェクトは無効になります。これらのスキーマ・オブジェクトは、削除されたシノニムと同じ名前のローカル・オブジェクトまたは新しいパブリック・シノニムを作成することで、再検証できます。
型のシノニムの基礎となるベース型の削除は、シノニムの削除と同じ結果を依存オブジェクトにもたらします。
型のシノニムの名前は、RENAME文で変更します。シノニムの名前を変更することは、シノニムを削除してから、新しい名前でシノニムを再作成することと同等です。型のシノニムに依存表または有効なオブジェクト型が存在する場合、型のシノニムの名前は変更できません。syn1には依存するオブジェクト型が存在するため、次の例は失敗します。
RENAME syn1 TO syn3 -- invalid statement;
パブリック・シノニムが、新しいスキーマ・オブジェクトを保持するローカル・スキーマに依存表または有効なオブジェクト型を持っている場合、そのパブリック・シノニムと同じ名前のローカル・スキーマ・オブジェクトは作成できません。また、同じスキーマ内のプライベート・スキーマと同じ名前のローカル・スキーマ・オブジェクトも作成できません。
たとえば、次の例では、表shape_tabはパブリック・シノニムpub_shapeの依存表ですが、それは、この表に型の定義でこのシノニムを使用する列があるためです。したがって、依存表と同じスキーマにパブリック・シノニムpub_shapeと同じ名前の表を作成しようとすると、正常に実行されません。
-- Following uses public synonym pub_shape CREATE TABLE shape_tab ( c1 pub_shape ); -- Following is not allowed CREATE TABLE pub_shape ( c1 NUMBER ) -- invalid statement;
オブジェクトのチューニング時には、次の点に対処する必要があります。
オブジェクトおよびオブジェクト・ビューによる実行時のCPUおよびメモリー・リソースの消費状況
実行時のメモリーおよびCPUリソースの監視方法
多数のオブジェクトの管理方法
重要なパフォーマンス要因には、次のようなものがあります。
統計を収集するDBMS_STATSパッケージ
SQLコマンドの実行をプロファイルするtkprof
問合せ計画を生成するEXPLAIN PLAN
|
関連項目: アプリケーションのパフォーマンスの測定およびチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください |
