Oracle Database SQL言語リファレンス 11g リリース1(11.1) E05750-03 |
|
この章では、次のSQL文について説明します。
CREATE
LIBRARY
文を使用すると、オペレーティング・システム共有ライブラリに関連するスキーマ・オブジェクトを作成できます。このスキーマ・オブジェクトの名前は、CREATE
FUNCTION
またはCREATE
PROCEDURE
文のcall_spec
で使用できます。また、パッケージまたはタイプにおけるファンクションまたはプロシージャを宣言する際にも使用できます。これによって、SQLおよびPL/SQLは、3GLファンクションおよびプロシージャに対してコールできます。
自分のスキーマ内にライブラリを作成する場合は、CREATE
LIBRARY
システム権限が必要です。他のユーザーのスキーマ内にライブラリを作成する場合は、CREATE
ANY
LIBRARY
システム権限が必要です。ライブラリに格納されているプロシージャおよびファンクションを使用する場合は、そのライブラリに対するEXECUTE
オブジェクト権限が必要です。
CREATE
LIBRARY
文は、共有ライブラリおよび動的リンクをサポートするプラットフォーム上でのみ有効です。
OR
REPLACE
を指定すると、既存のライブラリを再作成できます。この句を指定した場合、既存のライブラリに付与されているスキーマ・オブジェクト権限を削除、再作成および再付与しなくても、ライブラリの定義を変更できます。
再定義したライブラリに対して権限を付与されていたユーザーは、権限を再付与されなくてもライブラリにアクセスできます。
作成するライブラリの名前を指定します。call_spec
でファンクションまたはプロシージャを宣言するときは、この名前を指定します。
一重引用符で囲まれた文字列リテラルを指定します。文字列には、オペレーティング・システムの共有ライブラリの名前となるパスまたはファイル名を指定します。
filename
は、CREATE
LIBRARY
文の実行中は解析されません。ライブラリ・ファイルの存在は、そのファイルからルーチンが実行されるまでチェックされません。
AGENT
句を指定すると、サーバーではなく、データベース・リンクから外部プロシージャを実行できます。外部プロシージャの実行には、agent_dblink
に指定したデータベース・リンクが使用されます。この句を指定しない場合、サーバーのデフォルト・エージェント(extproc
)が、外部プロシージャを実行します。
次の文は、ライブラリext_lib
を作成します。
CREATE LIBRARY ext_lib AS '/OR/lib/ext_lib.so'; /
次の文は、ライブラリext_lib
を再作成します。
CREATE OR REPLACE LIBRARY ext_lib IS '/OR/newlib/ext_lib.so'; /
次の例は、ライブラリapp_lib
を作成し、パブリック・データベースsales.hq.acme.com
から外部プロシージャを起動することを指定します。
CREATE LIBRARY app_lib as '${ORACLE_HOME}/lib/app_lib.so' AGENT 'sales.hq.acme.example.com'; /
CREATE
MATERIALIZED
VIEW
文を使用すると、マテリアライズド・ビューを作成できます。マテリアライズド・ビューは、問合せ結果を含むデータベース・オブジェクトです。問合せのFROM
句には、表、ビューおよびその他のマテリアライズド・ビューを指定できます。これらのオブジェクトをあわせて、マスター表(レプリケーション用語)またはディテール表(データ・ウェアハウス用語)といいます。このマニュアルでは、「マスター表」を使用します。マスター表が格納されているデータベースをマスター・データベースといいます。
レプリケーションでは、マテリアライズド・ビューを使用すると、ローカル・ノード上にあるリモート・データのコピーのメンテナンスができます。コピーは、アドバンスト・レプリケーション機能によって更新可能となりますが、この機能がない場合は読取り専用です。マテリアライズド・ビューのデータを、表またはビューと同じように選択することができます。レプリケーション環境では、通常作成されるマテリアライズド・ビューは、主キー、ROWID、オブジェクトおよび副問合せのマテリアライズド・ビューです。
データ・ウェアハウスでは、通常作成されるマテリアライズド・ビューは、マテリアライズド集計ビュー、単一表マテリアライズド集計ビューおよびマテリアライズド結合ビューです。3つのマテリアライズド・ビューは、クエリー・リライトで使用できます。クエリー・リライトとは、マスター表に関して記述したユーザー要求を、1つ以上のマテリアライズド・ビューを含む同等の要求に変換するための最適化手法です。
参照:
|
マテリアライズド・ビューの作成に必要な権限は、ロールを介してではなく、直接付与する必要があります。
自分のスキーマ内にマテリアライズド・ビューを作成する場合は、次の条件に従う必要があります。
CREATE
MATERIALIZED
VIEW
システム権限と、CREATE
TABLE
またはCREATE
ANY
TABLE
のいずれかのシステム権限が必要です。
SELECT
オブジェクト権限またはSELECT
ANY
TABLE
システム権限が必要です。
他のユーザーのスキーマ内にマテリアライズド・ビューを作成する場合、次の条件に従う必要があります。
CREATE
ANY
MATERIALIZED
VIEW
システム権限が必要です。
CREATE
TABLE
システム権限が必要です。スキーマ所有者が所有していないマテリアライズド・ビューの任意のマスター表(リモート・データベースに存在するマスター表など)、およびそのマスター表に定義された任意のマテリアライズド・ビュー・ログにアクセスするには、各表に対するSELECT
オブジェクト権限、またはSELECT
ANY
TABLE
システム権限が必要です。
REFRESH ON COMMITモードのマテリアライズド・ビューを作成する(ON
COMMIT
REFRESH
句を使用)場合は、前述の権限の他に、所有しないマスター表に対するON
COMMIT
REFRESH
オブジェクト権限、またはON
COMMIT
REFRESH
システム権限が必要です。
前述の権限の他にも、クエリー・リライトが使用可能なマテリアライズド・ビューを作成する場合は、次の条件に従う必要があります。
GLOBAL
QUERY
REWRITE
権限、または自分のスキーマ以外の各表に対するQUERY
REWRITE
オブジェクト権限が必要です。
ON
PREBUILT
TABLE
句を使用)場合は、コンテナ表に対するWITH
GRANT
OPTION
付きのSELECT
権限が必要です。
マテリアライズド・ビューを含むスキーマのユーザーには、マテリアライズド・ビューのマスター表および索引を格納するターゲット表領域への十分な割当て制限またはUNLIMITED
TABLESPACE
システム権限が必要です。
マテリアライズド・ビューを作成する場合、Oracle Databaseはマテリアライズド・ビューのスキーマ内に、1つの内部表および1つ以上の索引を作成します。また、1つのビューを作成することもあります。これらのオブジェクトは、マテリアライズド・ビューのデータをメンテナンスするために使用されます。ユーザーには、これらのオブジェクトを作成するための権限が必要です。
参照:
|
(physical_properties::=、scoped_table_ref_constraint::=、materialized_view_props::=、physical_attributes_clause::=、create_mv_refresh::=、subquery::=を参照)
(segment_attributes_clause::=、table_compression::=、index_org_table_clause::=を参照)
(column_properties::=、「CREATE
TABLE
」構文の項にあるtable_partitioning_clauses::=、parallel_clause::=、build_clause::=を参照)
(mapping_table_clause
は、マテリアライズド・ビューではサポートされていません。key_compression::=、index_org_overflow_clause::=を参照)
(segment_attributes_clause::=を参照)
(physical_attributes_clause::=、logging_clause::=を参照)
(logging_clause::=を参照)
(object_type_col_properties::=、nested_table_col_properties::=、varray_col_properties::=、LOB_partition_storage::=、LOB_storage_clause::=を参照。XMLType_column_properties
は、マテリアライズド・ビューではサポートされていません。)
(substitutable_column_clause::=を参照)
(substitutable_column_clause::=、object_properties::=、「CREATE
TABLE
」構文の項にあるphysical_properties::=、column_properties::=を参照)
(substitutable_column_clause::=、varray_storage_clause::=を参照)
(LOB_parameters::=を参照)
(LOB_storage_parameters::=を参照)
(LOB_parameters::=、storage_clause::=を参照)
(storage_clause::=、logging_clause::=を参照)
(LOB_storage_clause::=、varray_col_properties::=を参照)
マテリアライズド・ビューを含めるスキーマを指定します。schema
を指定しないと、自分のスキーマ内にマテリアライズド・ビューが作成されます。
作成するマテリアライズド・ビューの名前を指定します。Oracle Databaseは、マテリアライズド・ビュー名に接頭辞または接尾辞を追加して、マテリアライズド・ビューをメンテナンスするための表および索引の名前を生成します。
マテリアライズド・ビューの各列に対して別名を指定できます。列の別名のリストによって、競合する列名が明示的に解決されます。したがって、マテリアライズド・ビューのSELECT
句で別名を指定する必要がなくなります。この句で列の別名を指定する場合は、SELECT
句内で参照される各データ・ソースの別名を指定する必要があります。
OF
object_type
句を指定すると、object_type
型のオブジェクト・マテリアライズド・ビューを明示的に作成できます。
SCOPE
FOR
句を使用すると、参照の有効範囲を1つのオブジェクト表に制限できます。scope_table_name
を持つ表名または列の別名を参照できます。REF
列または属性の値はscope_table_name
またはc_alias
内のオブジェクトを指し、その場所にREF
列と同じ型のオブジェクト・インスタンスが格納されます。別名を指定する場合は、その別名が、マテリアライズド・ビューを定義する問合せのSELECT
構文のリストの列と1対1で対応する必要があります。
ON
PREBUILT
TABLE
句を指定すると、既存の表を再初期化したマテリアライズド・ビューとして登録できます。この句は、データ・ウェアハウス環境において、大きいマテリアライズド・ビューを登録する場合に有効です。その表は、結果マテリアライズド・ビューと同じ名前で、同じスキーマにある必要があります。
マテリアライズド・ビューが削除されると、その既存の表は、1つの表としての元の形に戻ります。
WITH
REDUCED
PRECISION
を指定すると、表またはマテリアライズド・ビュー列の精度が、副問合せで戻される精度と一致しない場合に、精度の低下を許可できます。
WITHOUT
REDUCED
PRECISION
を指定すると、表またはマテリアライズド・ビュー列の精度が副問合せによって戻された精度と一致することを要求できます。一致しない場合、作成操作は中断します。これはデフォルトです。
事前作成表には、次の制限事項があります。
subquery
の各列の別名は、事前作成表の列に対応し、対応する列のデータ型が一致している必要があります。
subquery
で参照されない列にデフォルト値も指定しないかぎり、その列にNOT
NULL
制約は指定できません。physical_properties_clause
の構成要素は、マテリアライズド・ビューと表に対して同一のセマンティクスを持ちます。ただし、次の項で説明する例外および追加事項があります。
マテリアライズド・ビューに対しては、ORGANIZATION
EXTERNAL
を指定できません。
segment_attributes_clause
を使用すると、PCTFREE
、PCTUSED
、INITRANS
パラメータの値、およびマテリアライズド・ビューの記憶特性の設定、表領域の割当て、ロギングが実行されるかどうかを指定できます。USING
INDEX
句では、PCTFREE
またはPCTUSED
は指定できません。
マテリアライズド・ビューを作成する表領域を指定します。この句を指定しないと、マテリアライズド・ビューを含むスキーマのデフォルト表領域内にマテリアライズド・ビューが作成されます。
LOGGING
またはNOLOGGING
を指定すると、マテリアライズド・ビュー・ログのロギング特性を設定できます。ロギング特性は、マテリアライズド・ビューの作成およびDBMS_REFRESH
パッケージによって開始される非アトミック・リフレッシュに影響します。デフォルトは、マテリアライズド・ビューが存在する表領域のロギング特性です。
参照:
この句の詳細は、「logging_clause」を参照してください。アトミック・リフレッシュおよび非アトミック・リフレッシュの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
table_compression
句を使用すると、ディスクおよびメモリーの使用量を削減するために、データ・セグメントを圧縮するかどうかを指定できます。
ORGANIZATION
INDEX
を指定すると、索引構成マテリアライズド・ビューを作成できます。このマテリアライズド・ビューでは、データ行は、マテリアライズド・ビューの主キーに定義した索引に格納されます。次のようなマテリアライズド・ビューの索引構成を指定できます。
index_org_table_clause
のキーワードおよびパラメータは、CREATE
TABLE
と同じです。また、次の制限事項があります。
索引構成マテリアライズド・ビューには、次の制限事項があります。
CREATE
MATERIALIZED
VIEW
のCACHE
、NOCACHE
、CLUSTER
またはON
PREBUILT
TABLE
句は指定できません。
index_org_table_clause
には次の制限事項があります。
CLUSTER
句を指定すると、指定したクラスタの一部としてマテリアライズド・ビューを作成できます。クラスタ化マテリアライズド・ビューは、クラスタの領域割当てを使用します。したがって、CLUSTER
句で物理属性またはTABLESPACE
句を指定しないでください。
CLUSTER
を指定する場合、materialized_view_props
内のtable_partitioning_clauses
は指定できません。
これらのプロパティ句を使用すると、既存の表に基づかないマテリアライズド・ビューを定義できます。既存の表に基づくマテリアライズド・ビューを作成するには、ON
PREBUILT
TABLE
句を使用します。
column_properties
句を使用すると、LOB、ネストした表、VARRAYまたはXMLType
の列の記憶特性を指定できます。object_type_col_properties
は、マテリアライズド・ビューには関連しません。
table_partitioning_clauses
を使用すると、マテリアライズド・ビューを、指定した範囲の値またはハッシュ・ファンクションでパーティション化できます。マテリアライズド・ビューのパーティション化は、表のパーティション化と同じです
アクセス頻度の高いデータについて、CACHE
は、全表スキャンの実行時にこの表に対して取り出された各ブロックを、バッファ・キャッシュの最低使用頻度(LRU)リストの最高使用頻度側に入れることを指定します。この属性は、小規模な参照表で有効です。NOCACHE
は、ブロックをLRUリストの最低使用頻度側に入れることを指定します。
parallel_clause
を使用すると、マテリアライズド・ビューへのパラレル操作をサポートするかどうかを指定できます。作成後にマテリアライズド・ビューに対する問合せおよびDMLのデフォルトの並列度を設定します。
この句の詳細は、「CREATE
TABLE
」の「parallel_clause」を参照してください。
build_clause
を指定すると、マテリアライズド・ビューをいつ移入するかを指定できます。
IMMEDIATE
を指定すると、マテリアライズド・ビューにすぐに移入できます。これはデフォルトです。
DEFERRED
を指定すると、次のREFRESH
操作でマテリアライズド・ビューに移入できます。最初の(遅延)リフレッシュは、常に、完全リフレッシュである必要があります。それ以前のマテリアライズド・ビューの値はUNUSABLE
であるため、クエリー・リライトには使用できません。
USING
INDEX
句を使用すると、マテリアライズド・ビューのデータをメンテナンスするために使用されるデフォルトの索引のINITRANS
パラメータおよびSTORAGE
パラメータの値を変更できます。USING
INDEX
が設定されていない場合、この索引にはデフォルト値が使用されます。デフォルトの索引は、マテリアライズド・ビューの増分リフレッシュ(高速リフレッシュ)を高速に処理するために使用されます。
この句では、PCTUSED
パラメータは指定できません。
USING
NO
INDEX
句を指定すると、デフォルトの索引の作成を抑制できます。CREATE
INDEX
文を使用することによって、代替する索引を明示的に作成できます。USING
NO
INDEX
を指定し、増分リフレッシュ(REFRESH
FAST
)でマテリアライズド・ビューを作成する場合は、このような索引を作成する必要があります。
create_mv_refresh
句を使用すると、マテリアライズド・ビューのデフォルトのリフレッシュ方法、リフレッシュ・モードおよびリフレッシュ時刻を指定できます。マテリアライズド・ビューのマスター表が変更された場合、マテリアライズド・ビューのデータを更新し、その時点でマスター表にあるデータを正確に反映させる必要があります。この句によって、自動的にマテリアライズド・ビューをリフレッシュする日時をスケジューリングし、リフレッシュの方法およびモードを指定できます。
参照:
|
FAST
を指定すると、増分リフレッシュ方法を指定できます。これはマスター表に対して行った変更に従ってリフレッシュを行います。従来型DML変更の場合、変更は、マスター表に関連付けられたマテリアライズド・ビュー・ログに格納されます。ダイレクト・パス・インサート操作の場合、ダイレクト・ローダー・ログに格納されます。
REFRESH
FAST
を指定すると、マテリアライズド・ビューのマスター表のマテリアライズド・ビュー・ログが存在していない場合に、CREATE
文は正常に実行されません。ダイレクト・パス・インサートが行われると、ダイレクト・ローダー・ログが自動的に作成されます。手動での操作は必要ありません。
従来型DMLの変更の場合も、ダイレクト・パス・インサート操作の場合も、他の条件によって、高速リフレッシュへのマテリアライズド・ビューの適応性が制限されることがあります。
定義する問合せに分析ファンクションが含まれている場合、マテリアライズド・ビューは高速リフレッシュに適応しません。
参照:
|
COMPLETE
を指定すると、完全リフレッシュ方法を指定できます。これは、マテリアライズド・ビューを定義する問合せを実行することによって実装されます。完全リフレッシュを要求すると、高速リフレッシュが実行可能であっても、完全リフレッシュが実行されます。
FORCE
を指定すると、リフレッシュ時に、高速リフレッシュが可能な場合は高速リフレッシュを実行し、可能でない場合は完全リフレッシュを実行するように指定できます。リフレッシュ方法(FAST
、COMPLETE
またはFORCE
)を指定しないと、デフォルトでFORCE
が指定されます。
ON
COMMIT
を指定すると、マテリアライズド・ビューのマスター表に対するトランザクションをコミットするときに、必ず高速リフレッシュが実行されるように指定できます。この句を指定すると、リフレッシュ操作がコミット処理の一部として行われるため、コミットの完了に時間がかかります。
ON
COMMIT
およびON
DEMAND
の両方を指定することはできません。ON
COMMIT
を指定した場合は、START
WITH
またはNEXT
を同時に指定できません。
ON
DEMAND
句の場合は、それ以降のマスター表での分散トランザクションに、このような制限はありません。
ON
DEMAND
を指定すると、3つのDBMS_MVIEW
リフレッシュ・プロシージャのうちのいずれかを使用してユーザーが手動でリフレッシュしないかぎりデータベースによってマテリアライズド・ビューがリフレッシュされないように指定できます。
ON
COMMIT
およびON
DEMAND
のどちらも指定しなかった場合、ON
DEMAND
がデフォルトになります。このデフォルト設定は、同じCREATE
MATERIALIZED
VIEW
文または後続のALTER
MATERIALIZED
VIEW
文のいずれかにSTART
WITH
句またはNEXT
句を指定することで上書きできます。
ON
COMMIT
およびON
DEMAND
の両方を指定することはできません。START
WITH
およびNEXT
は、ON
DEMAND
より優先されます。このため、START
WITH
またはNEXT
を指定したときは、ほとんどの場合、ON
DEMAND
を指定しても意味がありません。
最初の自動リフレッシュ時刻を表す日時式を指定します。
自動リフレッシュの間隔を計算するための日時式を指定します。
START
WITH
値およびNEXT
値は、将来の時刻に評価される値です。START
WITH
値を省略した場合、Oracle Databaseはマテリアライズド・ビューの作成時刻に対してNEXT
式を評価することによって、最初の自動リフレッシュ時刻を判断します。START
WITH
値を指定し、NEXT
値を指定しない場合、Oracle Databaseは1回のみマテリアライズド・ビューをリフレッシュします。START
WITH
値およびNEXT
値のどちらも指定しない場合、またはcreate_mv_refresh
を指定しない場合は、マテリアライズド・ビューは自動リフレッシュされません。
WITH PRIMARY
KEY
を指定すると、主キー・マテリアライズド・ビューを作成できます。これはデフォルトであり、WITH
ROWID
の項で説明する場合を除き、すべての場合に使用する必要があります。主キー・マテリアライズド・ビューを使用すると、高速リフレッシュに対するマテリアライズド・ビューの適応性に影響せずに、マテリアライズド・ビューのマスター表を再編成できます。マスター表には、使用可能な主キー制約が定義されている必要があり、マテリアライズド・ビューを定義する問合せでは、すべての主キー列が直接指定される必要があります。定義する問合せでは、UPPER
などのファンクションへの引数として主キー列を指定できません。
この句は、オブジェクト・マテリアライズド・ビューには指定できません。WITH
OBJECT
ID
を指定してマテリアライズドされたオブジェクトは暗黙的にリフレッシュされます。
WITH
ROWID
を指定すると、ROWIDマテリアライズド・ビューを作成できます。マテリアライズド・ビューがマスター表の主キー列をすべて含まない場合に、ROWIDマテリアライズド・ビューは有効です。ROWIDマテリアライズド・ビューは、単一表を基にしている必要があり、次のいずれも含むことができません。
完全リフレッシュが行われるまでは、マスター表の再編成後に、ROWIDマテリアライズド・ビューは高速リフレッシュされません。
この句は、オブジェクト・マテリアライズド・ビューには指定できません。WITH
OBJECT
ID
を指定してマテリアライズドされたオブジェクトは暗黙的にリフレッシュされます。
自動UNDOモードではロールバック・セグメントではなくUNDO表領域が使用されるため、データベースが自動UNDOモードの場合、この句は無効です。自動UNDOモードを使用することをお薦めします。この句は、ロールバック・セグメントが使用される以前のバージョンのOracle Databaseが含まれるレプリケーション環境との下位互換性のためにサポートされています。
rollback_segment
に、マテリアライズド・ビューのリフレッシュ中に使用するリモート・ロールバック・セグメントを指定します。
DEFAULT
を使用すると、使用するロールバック・セグメントを自動的に選択できます。DEFAULT
を指定した場合、rollback_segment
は指定できません。DEFAULT
は、マテリアライズド・ビューを(作成ではなく)変更する場合に有効です。
MASTER
を使用すると、個々のマテリアライズド・ビュー用のリモート・マスター・サイトで使用されるリモート・ロールバック・セグメントを指定できます。
LOCAL
を使用すると、マテリアライズド・ビューが含まれているローカル・リフレッシュ・グループで使用されるリモート・ロールバック・セグメントを指定できます。これはデフォルトです。
rollback_segment
を指定しない場合、使用するロールバック・セグメントが自動的に選択されます。各マテリアライズド・ビューに対して1つのマスター・ロールバック・セグメントが格納され、マテリアライズド・ビューの作成およびリフレッシュ時に検証されます。複合マテリアライズド・ビューの場合、マスター・ロールバック・セグメントの指定は無視されます。
USING
... CONSTRAINTS
句を使用すると、リフレッシュ操作中にOracle Databaseでより多くのリライト・オプションを選択でき、リフレッシュをより効果的に実行できます。リフレッシュ操作中に、適用される制約のみに依存するのではなく、適用されていない制約(RELY
状態のディメンションの関係や制約など)を使用できます。
この句を指定しない場合、USING
ENFORCED
CONSTRAINTS
がデフォルトになります。
NEVER
REFRESH
を指定すると、Oracle Databaseのリフレッシュ・メカニズムまたはパッケージ・プロシージャを使用したマテリアライズド・ビューのリフレッシュを回避できます。このようなプロシージャから発行された、マテリアライズド・ビューに対するREFRESH
文は、無視されます。この句を無効にするには、ALTER
MATERIALIZED
VIEW
... REFRESH
文を発行する必要があります。
FOR
UPDATE
を指定すると、副問合せ、主キー、オブジェクトまたはROWIDマテリアライズド・ビューを更新できます。アドバンスト・レプリケーションと組み合せて使用した場合、更新はマスターにも影響します。
QUERY
REWRITE
句を使用すると、マテリアライズド・ビューがクエリー・リライトで使用できるかどうかを指定できます。
ENABLE
を指定すると、クエリー・リライトでマテリアライズド・ビューを使用可能にできます。
クエリー・リライトを使用可能にする処理には、次の制限事項があります。
DETERMINISTIC
である場合のみ、クエリー・リライトを使用可能にできます。
CURRENT_TIME
、USER
、順序値(たとえば、CURRVAL
またはNEXTVAL
疑似列)、またはSAMPLE
句(マテリアライズド・ビューの変更内容と異なる行をサンプルとして抽出します)を含めることはできません。
参照:
DBMS_STATS
パッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
DBMS_MVIEW
パッケージのEXPLAIN_MVIEW
プロシージャを参照してください。クエリー・リライトの問題の修正については、DBMS_MVIEW
パッケージのTUNE_MVIEW
プロシージャを参照してください。
DISABLE
を指定すると、マテリアライズド・ビューをクエリー・リライトで使用禁止にできます。使用禁止にしたマテリアライズド・ビューはリフレッシュ可能です。
マテリアライズド・ビューを定義する問合せを指定します。マテリアライズド・ビューの作成時に、この副問合せが実行され、実行結果がマテリアライズド・ビューに格納されます。この副問合せは、有効なSQL副問合せである必要があります。ただし、すべての副問合せに高速リフレッシュを適用できるわけではなく、すべての副問合せがクエリー・リライトに使用できるわけでもありません。
マテリアライズド・ビューには、次の注意事項があります。
BUILD
DEFERRED
を指定する場合、定義する問合せはすぐには実行されません。
FROM
句に指定する各表およびビューを、それを含むスキーマで修飾することをお薦めします。
マテリアライズド・ビュー問合せには、次の制限事項があります。
SYS
が所有する表、ビューまたはマテリアライズド・ビューから選択できますが、このようなマテリアライズド・ビューに対してQUERY
REWRITE
は使用できません。
WHERE
句内など、定義する問合せの他の箇所には、副問合せを含めることができます。
GROUP
BY
句を含むマテリアライズド結合ビューおよびマテリアライズド集計ビューは、索引構成表からは選択できません。
LONG
データ型の列を含めることはできません。
QUERY
REWRITE
を指定することもできません。
FROM
句が他のマテリアライズド・ビューを参照する場合、この文で作成するマテリアライズド・ビューのリフレッシュの前に、定義する問合せで参照されているマテリアライズド・ビューを常にリフレッシュしておく必要があります。
XMLType
およびURIデータ型の列が含まれます。
クエリー・リライトが可能なマテリアライズド・ビューを作成する場合、次の制限があります。
ROWNUM
、USER
、SYSDATE
、リモート表、順序、または(データベースやパッケージ状態の書込みまたは読取りを行う)PL/SQLファンクションに対する直接またはビューを介した参照を含めることはできません。
マテリアライズド・ビュー・ログを使用した高速リフレッシュを実行する場合は、いくつかの制限事項があります。
参照:
|
次の例では、「CREATE MATERIALIZED VIEW LOG」の「例」で作成したマテリアライズド・ログが必要です。
次の文は、hr
スキーマ内のemployees
表に基づいた非常に単純なマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW mv1 AS SELECT * FROM hr.employees;
デフォルトでは、REFRESH ON DEMANDのみが指定されている主キー・マテリアライズド・ビューが作成されます。マテリアライズド・ビュー・ログがemployees
に存在する場合は、高速リフレッシュできるようにmv1
を変更できます。このようなログが存在しない場合は、mv1
の完全リフレッシュのみが可能です。Oracle Databaseでは、mv1
に対してデフォルトの記憶域プロパティが使用されます。この操作に必要な権限は、CREATE
MATERIALIZED
VIEW
システム権限およびhr.employeesに対するSELECT
オブジェクト権限のみです。
次の文は、リモート・データベースのsh
スキーマのcountries
およびcustomers
表を基にした副問合せマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW foreign_customers FOR UPDATE AS SELECT * FROM sh.customers@remote cu WHERE EXISTS (SELECT * FROM sh.countries@remote co WHERE co.country_id = cu.country_id);
次の文は、サンプル表sh.sales
にマテリアライズド集計ビューを作成して移入し、デフォルトのリフレッシュ方法、モードおよび時刻を指定します。この文は、ここに示されている2つのログおよび「マテリアライズド・ビュー・ログの作成例:」で作成されたマテリアライズド・ビュー・ログを使用します。
CREATE MATERIALIZED VIEW LOG ON times WITH ROWID, SEQUENCE (time_id, calendar_year) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW LOG ON products WITH ROWID, SEQUENCE (prod_id) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW sales_mv BUILD IMMEDIATE REFRESH FAST ON COMMIT AS SELECT t.calendar_year, p.prod_id, SUM(s.amount_sold) AS sum_sales FROM times t, products p, sales s WHERE t.time_id = s.time_id AND p.prod_id = s.prod_id GROUP BY t.calendar_year, p.prod_id;
次の文は、サンプル・スキーマsh
の表を使用して、マテリアライズド集計ビューsales_by_month_by_state
を作成して移入します。マテリアライズド・ビューは、この文が正しく実行されるとすぐに移入されます。デフォルトで、次のマテリアライズド・ビューを定義する問合せを再実行することによって、後続のリフレッシュが行われます。
CREATE MATERIALIZED VIEW sales_by_month_by_state TABLESPACE example PARALLEL 4 BUILD IMMEDIATE REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT t.calendar_month_desc, c.cust_state_province, SUM(s.amount_sold) AS sum_sales FROM times t, sales s, customers c WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id GROUP BY t.calendar_month_desc, c.cust_state_province;
次の文は、既存の集計表sales_sum_table
に対するマテリアライズド集計ビューを作成します。
CREATE TABLE sales_sum_table (month VARCHAR2(8), state VARCHAR2(40), sales NUMBER(10,2)); CREATE MATERIALIZED VIEW sales_sum_table ON PREBUILT TABLE WITH REDUCED PRECISION ENABLE QUERY REWRITE AS SELECT t.calendar_month_desc AS month, c.cust_state_province AS state, SUM(s.amount_sold) AS sales FROM times t, customers c, sales s WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id GROUP BY t.calendar_month_desc, c.cust_state_province;
前述の例では、マテリアライズド・ビューは事前作成表と同じ名前を持ち、かつ事前作成表と同じデータ型で同じ数の列を持ちます。WITH
REDUCED
PRECISION
句によって、マテリアライズド・ビュー列の精度と副問合せによって戻された値の精度の違いは許可されます。
次の文は、サンプル表oe.product_information
に主キー・マテリアライズド・ビューcatalog
を作成します。
CREATE MATERIALIZED VIEW catalog REFRESH FAST START WITH SYSDATE NEXT SYSDATE + 1/4096 WITH PRIMARY KEY AS SELECT * FROM product_information;
次の文は、サンプル表oe.orders
にROWIDマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW order_data REFRESH WITH ROWID AS SELECT * FROM orders;
次の文は、主キー・マテリアライズド・ビューemp_data
を作成し、サンプル表hr.employees
のデータを移入します。
CREATE MATERIALIZED VIEW LOG ON employees WITH PRIMARY KEY INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW emp_data PCTFREE 5 PCTUSED 60 TABLESPACE example STORAGE (INITIAL 50K NEXT 50K) REFRESH FAST NEXT sysdate + 7 AS SELECT * FROM employees;
前述の文にはSTART
WITH
パラメータが指定されていないため、Oracle Databaseでは、現行のSYSDATE
を使用してNEXT
値が評価され、最初の自動リフレッシュ時刻が判断されます。従業員表のマテリアライズド・ビュー・ログが作成されたため、マテリアライズド・ビュー作成の7日後から、7日ごとにマテリアライズド・ビューの高速リフレッシュが実行されます。
マテリアライズド・ビューが高速リフレッシュを行うための条件と一致するため、高速リフレッシュが行われます。また、前述の文では、マテリアライズド・ビューをメンテナンスするためにデータベースで使用される表の記憶特性も設定しています。
次の文は、remote
およびlocal
データベースの従業員表を問い合せる複合マテリアライズド・ビューall_customers
を作成します。
CREATE MATERIALIZED VIEW all_customers PCTFREE 5 PCTUSED 60 TABLESPACE example STORAGE (INITIAL 50K NEXT 50K) USING INDEX STORAGE (INITIAL 25K NEXT 25K) REFRESH START WITH ROUND(SYSDATE + 1) + 11/24 NEXT NEXT_DAY(TRUNC(SYSDATE), 'MONDAY') + 15/24 AS SELECT * FROM sh.customers@remote UNION SELECT * FROM sh.customers@local;
このマテリアライズド・ビューは、翌日の午前11:00に自動的にリフレッシュされ、その後は、毎週月曜日の午後3:00にリフレッシュされます。デフォルトのリフレッシュ方法は、FORCE
です。定義する問合せにはUNION
演算子が含まれますが、UNION演算子は高速リフレッシュでサポートされていないため、自動的に完全リフレッシュが実行されます。
前述の文では、マテリアライズド・ビューおよびこのマテリアライズド・ビューをメンテナンスするために使用される索引の記憶特性を次のように設定しています。
STORAGE
句で、マテリアライズド・ビューの1番目と2番目のエクステントのサイズをそれぞれ50KBに設定します。
USING
INDEX
句付きのSTORAGE
句では、索引の1番目と2番目のエクステントのサイズをそれぞれ25KBに変更します。
次の文は、product_information
およびinventories
表からWHERE
条件で戻される行を制限するUNION
集合演算子を使用して、サンプル・スキーマoe
の表order_items
から列を選択する高速リフレッシュが可能なマテリアライズド・ビューを作成します。order_items
およびproduct_information
のマテリアライズド・ビュー・ログは、CREATE
MATERIALIZED
VIEW
LOG
の「例」で作成されたものです。また、次の例では、oe.inventories
のマテリアライズド・ビュー・ログが必要です。
CREATE MATERIALIZED VIEW LOG ON inventories WITH (quantity_on_hand); CREATE MATERIALIZED VIEW warranty_orders REFRESH FAST AS SELECT order_id, line_item_id, product_id FROM order_items o WHERE EXISTS (SELECT * FROM inventories i WHERE o.product_id = i.product_id AND i.quantity_on_hand IS NOT NULL) UNION SELECT order_id, line_item_id, product_id FROM order_items WHERE quantity > 5;
マテリアライズド・ビューwarranty_orders
には、order_items
(product_id
を結合列とする)およびinventories(quantity_on_hand
をフィルタ列とする)で定義されたマテリアライズド・ビュー・ログが必要です。「マテリアライズド・ビュー・ログにフィルタ列を指定する例:」および「マテリアライズド・ビュー・ログに結合列を指定する例:」を参照してください。
次の例は、前述の例のマテリアライズド・ビューをマスター表として使用し、サンプル・スキーマoe
の特定の販売員で構成されるマテリアライズド・ビューを作成します。
CREATE MATERIALIZED VIEW my_warranty_orders AS SELECT w.order_id, w.line_item_id, o.order_date FROM warranty_orders w, orders o WHERE o.order_id = o.order_id AND o.sales_rep_id = 165;
CREATE
MATERIALIZED
VIEW
LOG
文を使用すると、マテリアライズド・ビューのマスター表に関連する表マテリアライズド・ビュー・ログを作成できます。
マスター表のデータがDMLによって変更された場合、Oracle Databaseは変更を記述する行をマテリアライズド・ビュー・ログに格納し、そのマテリアライズド・ビュー・ログを使用して、マスター表を基にしたマテリアライズド・ビューをリフレッシュします。このプロセスを、増分リフレッシュまたは高速リフレッシュといいます。マテリアライズド・ビュー・ログがない場合、マテリアライズド・ビュー問合せが再実行され、マテリアライズド・ビューがリフレッシュされます。このプロセスが完全リフレッシュです。通常、高速リフレッシュは、完全リフレッシュよりも高速に処理されます。
マテリアライズド・ビュー・ログは、マスター表と同一のスキーマ内のマスター・データベースにあります。マスター表に定義できるマテリアライズド・ビュー・ログは1つのみです。Oracle Databaseでは、このマテリアライズド・ビュー・ログを使用して、マスター表に基づく高速リフレッシュが可能なすべてのマテリアライズド・ビューに対して、高速リフレッシュを実行します。
マテリアライズド結合ビューを高速リフレッシュする場合、マテリアライズド・ビューが参照するそれぞれのマスター表に対するマテリアライズド・ビュー・ログを作成する必要があります。
参照:
|
マテリアライズド・ビュー・ログを作成するために必要な権限は、マテリアライズド・ビュー・ログに関連付けられた基礎となるオブジェクトの作成に必要な権限と直接関連しています。
CREATE
TABLE
権限がある場合、関連するマテリアライズド・ビュー・ログを作成できます。
CREATE
ANY
TABLE
システム権限、COMMENT
ANY
TABLE
システム権限、およびマスター表に対するSELECT
オブジェクト権限またはSELECT
ANY
TABLE
システム権限が必要です。
どちらの場合も、マテリアライズド・ビュー・ログの所有者には、マテリアライズド・ビュー・ログを格納するための表領域への十分な割当て制限またはUNLIMITED
TABLESPACE
システム権限が必要です。
(physical_attributes_clause::=、logging_clause::=、parallel_clause::=、「CREATE
TABLE
」のtable_partitioning_clauses::=、new_values_clause::=を参照)
(storage_clause::=を参照)
マテリアライズド・ビュー・ログのマスター表が含まれているスキーマを指定します。schema
を省略した場合、マスター表は自分のスキーマ内に含まれているとみなされます。マテリアライズド・ビュー・ログは、マスター表のスキーマ内に作成されます。なお、ユーザーSYS
のスキーマ内の表に対しては、マテリアライズド・ビュー・ログを作成できません。
マテリアライズド・ビュー・ログを作成するマスター表の名前を指定します。
一時表またはビューに対しては、マテリアライズド・ビュー・ログを作成できません。
physical_attributes_clause
を使用すると、マテリアライズド・ビュー・ログにおける物理特性および記憶特性を定義できます。
マテリアライズド・ビュー・ログを作成する表領域を指定します。この句を省略した場合、マテリアライズド・ビュー・ログのスキーマのデフォルト表領域内にマテリアライズド・ビュー・ログが作成されます。
LOGGING
またはNOLOGGING
を指定すると、マテリアライズド・ビュー・ログのロギング特性を設定できます。デフォルトは、マテリアライズド・ビュー・ログが存在する表領域のロギング特性です。
アクセス頻度の高いデータについて、CACHE
は、全表スキャンの実行時にこのログ用に取り出された各ブロックを、バッファ・キャッシュの最低使用頻度(LRU)リストの最高使用頻度側に入れることを指定します。この属性は、小規模な参照表で有効です。
NOCACHE
は、ブロックをLRUリストの最低使用頻度側に入れることを指定します。デフォルトはNOCACHE
です。
parallel_clause
を使用すると、パラレル操作でマテリアライズド・ビュー・ログをサポートするかどうかを指定できます。
この句の詳細は、「CREATE
TABLE
」の「parallel_clause」を参照してください。
table_partitioning_clauses
を使用すると、マテリアライズド・ビュー・ログが、指定された範囲の値またはハッシュ・ファンクションでパーティション化されることを指定できます。マテリアライズド・ビュー・ログのパーティション化は、表のパーティション化と同じです。
WITH
句を使用すると、マスター内の行の更新時に、マテリアライズド・ビュー・ログに主キー、ROWID、オブジェクトIDまたはこれらの行識別子の組合せを記録するかどうかを指定できます。また、マテリアライズド・ビュー・ログに順序を追加し、レコードに対する追加の順序情報を提供することもできます。
この句を指定すると、マテリアライズド・ビュー・ログがフィルタ列(副問合せマテリアライズド・ビューが参照する主キー以外の列)または結合列(副問合せのWHERE
句で結合を定義する主キー以外の列)として参照する追加の列を記録するかどうかを指定できます。
この句を指定しない場合、またはPRIMARY
KEY
、ROWID
またはOBJECT
ID
なしで句を指定する場合は、デフォルトで主キー値が格納されます。ただし、作成時にOBJECT
ID
またはROWID
のみを指定した場合は、主キー値は暗黙的に格納されません。明示的に、またはデフォルトで作成された主キー・ログによって、主キー制約の追加の検証が実行されます。
OBJECT
ID
を指定すると、更新されるすべての行に対するシステム生成またはユーザー定義のオブジェクト識別子をマテリアライズド・ビュー・ログに記録することを指定できます。
OBJECT
ID
は、オブジェクト表のログの作成時のみに指定でき、記憶表用には指定できません。
PRIMARY
KEY
を指定すると、更新されるすべての行の主キーをマテリアライズド・ビュー・ログに記録することを指定できます。
ROWID
を指定すると、更新されるすべての行のROWIDをマテリアライズド・ビュー・ログに記録することを指定できます。
SEQUENCE
を指定すると、追加の順序情報を提供する順序値をマテリアライズド・ビュー・ログに記録できます。更新操作後の高速リフレッシュには、順序番号が必要です。
更新されるすべての行に対して、マテリアライズド・ビュー・ログに値を記録する列を指定します。通常、フィルタ列および結合列を指定します。
この句には、次の制限事項があります。
PRIMARY
KEY
、ROWID
、OBJECT
ID
、SEQUENCE
、および列リストを1つずつです。
column
が主キー列の1つを含む場合は、次の結合はいずれも指定できません。
WITH ... PRIMARY KEY ... (column) WITH ... (column) ... PRIMARY KEY WITH (column)
参照:
|
NEW
VALUES
句を使用すると、更新DML操作で、古い値と新しい値の両方をマテリアライズド・ビュー・ログに保存するかどうかを指定できます。
INCLUDING
を指定すると、古い値と新しい値の両方を保存できます。このログが単一表マテリアライズド集計ビューの表用で、マテリアライズド・ビューに高速リフレッシュを実行する場合、INCLUDING
を指定してください。
EXCLUDING
を指定すると、ログに新しい値が記録されなくなります。これはデフォルトです。この句を使用すると、新しい値の記録によるオーバーヘッドを回避できます。マスター表に高速リフレッシュが可能な単一表マテリアライズド集計ビューが定義されている場合は、この句を使用しないでください。
次の文は、物理特性および記憶特性を指定するoe.customers
表にマテリアライズド・ビュー・ログを作成します。
CREATE MATERIALIZED VIEW LOG ON customers PCTFREE 5 TABLESPACE example STORAGE (INITIAL 10K NEXT 10K);
customers
のマテリアライズド・ビュー・ログは、主キー・マテリアライズド・ビューの高速リフレッシュのみサポートします。
次の文は、ROWID
句を指定してマテリアライズド・ビュー・ログの別のバージョンを作成します。これによって、高速リフレッシュが使用可能になるマテリアライズド・ビューのタイプが追加されます。
CREATE MATERIALIZED VIEW LOG ON customers WITH PRIMARY KEY, ROWID;
このcustomers
のマテリアライズド・ビュー・ログによって、ROWIDマテリアライズド・ビューおよびマテリアライズド結合ビューに対する高速リフレッシュが実行可能になります。マテリアライズド集計ビューの高速リフレッシュを指定するには、次の例に示すとおり、SEQUENCE
およびINCLUDING
NEW
VALUES
句も指定する必要があります。
次の文は、sh.sales
表にマテリアライズド・ビュー・ログを作成します。この文は、「マテリアライズド集計ビューの作成例:」で使用します。この文は、このマテリアライズド・ビューで参照される表のすべての列を、フィルタ列として指定します。
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(amount_sold, time_id, prod_id) INCLUDING NEW VALUES;
次の文は、サンプル・スキーマoe
のorder_items
表にマテリアライズド・ビュー・ログを作成します。ログは、主キーおよび「高速リフレッシュ可能なマテリアライズド・ビューの作成例:」で結合列として使用したproduct_id
を記録します。
CREATE MATERIALIZED VIEW LOG ON order_items WITH (product_id);
次の例は、INCLUDING
NEW
VALUES
を指定するoe.product_information
表にマテリアライズド・ビュー・ログを作成します。
CREATE MATERIALIZED VIEW LOG ON product_information WITH ROWID, SEQUENCE (list_price, min_price, category_id), PRIMARY KEY INCLUDING NEW VALUES;
次の文は、マテリアライズド集計ビューを作成し、product_information
ログを使用します。
CREATE MATERIALIZED VIEW products_mv REFRESH FAST ON COMMIT AS SELECT SUM(list_price - min_price), category_id FROM product_information GROUP BY category_id;
マスター表に定義されたログに古い値と新しい値の両方が含まれるため、このマテリアライズド・ビューでは、高速リフレッシュを実行できます。
CREATE
OPERATOR
文を使用すると、新しい演算子を作成し、バインディングを定義できます。
演算子は、索引タイプ、SQL問合せおよびDML文で参照できます。それに対して演算子は、ファンクション、パッケージ、型および他のユーザー定義オブジェクトを参照します。
自分のスキーマ内に演算子を作成する場合は、CREATE
OPERATOR
システム権限が必要です。他のユーザーのスキーマ内に演算子を作成する場合は、CREATE
ANY
OPERATOR
システム権限が必要です。どちらの場合も、参照するファンクションおよび演算子に対するEXECUTE
オブジェクト権限が必要です。
OR
REPLACE
を指定すると、演算子スキーマ・オブジェクトの定義を置換できます。
演算子をサポートする索引タイプなどの依存オブジェクトが演算子にない場合のみ、定義を置換できます。
演算子が含まれているスキーマを指定します。schema
を省略した場合、自分のスキーマ内に演算子が作成されます。
作成する演算子の名前を指定します。
binding_clause
を使用すると、演算子をファンクションにバインドするために、1つ以上のパラメータ・データ型(parameter_type
)を指定できます。各バインドの署名(対応するファンクションに対する引数のデータ型のシーケンス)は、オーバーロードの規則に従って一意である必要があります。
parameter_type
自体をオブジェクト型にできます。この場合、任意にスキーマで修飾することもできます。
REF
、LONG
またはLONG
RAW
はparameter_type
に指定できません。
バインドに戻りデータ型を指定します。
return_type
自体をオブジェクト型にできます。この場合、任意にスキーマで修飾することもできます。
REF
、LONG
またはLONG
RAW
はreturn_type
に対して指定できません。
この句を使用すると、バインドの実装を指定できます。
ANCILLARY
TO
句を使用すると、演算子バインドが、指定した主演算子バインド(primary_operator
)を補助することを指定できます。この句を指定する場合は、1つのみの数値パラメータで前のバインドを指定しないでください。
context_clause
を使用すると、主演算子バインドを補助しないバインドのファンクション実装を指定できます。
この句を使用すると、演算子のファンクション評価に、実装タイプで指定した索引およびスキャン・コンテキストが使用されるように指定できます。
COMPUTE
ANCILLARY
DATA
を指定すると、演算子バインディングが補助データを計算するように指定できます。
WITH
COLUMN
CONTEXT
を指定すると、列情報が演算子のファンクション実装に渡されるように指定できます。
この句を指定する場合は、実装するファンクションの署名に、余分なODCIFuncCallInfo
構造を1つ含める必要があります。
using_function_clause
を使用すると、バインディングを実装するファンクションを指定できます。function_name
には、スタンドアロン・ファンクション、パッケージ・ファンクション、型メソッドまたはこれらのシノニムを指定できます。
ファンクションが後で削除された場合は、演算子などのすべての依存オブジェクトに、INVALID
のマークが付けられます。ただし、その後ALTER
OPERATOR
... DROP
BINDING
文を発行してバインディングを削除した場合は、後続の問合せおよびDMLで依存オブジェクトが再検証されます。
次の文は、非常に単純な等価性のファンクション実装を作成した後、このファンクションを使用する演算子を作成します。より詳細な例については、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。
CREATE FUNCTION eq_f(a VARCHAR2, b VARCHAR2) RETURN NUMBER AS BEGIN IF a = b THEN RETURN 1; ELSE RETURN 0; END IF; END; / CREATE OPERATOR eq_op BINDING (VARCHAR2, VARCHAR2) RETURN NUMBER USING eq_f;
CREATE
OUTLINE
文を使用すると、ストアド・アウトラインを作成できます。ストアド・アウトラインは、実行計画を生成するためにオプティマイザが使用する属性集合です。最適化に影響する要因に変更があるかどうかにかかわらず、特定のSQL文が発行された場合に、実行計画の生成に影響するアウトラインの集合を使用するように、オプティマイザに指示します。これらの要因における変更を考慮するように、アウトラインを変更することもできます。
参照:
|
パブリック・アウトラインまたはプライベート・アウトラインの作成には、CREATE
ANY
OUTLINE
システム権限が必要です。
ソース・アウトラインからクローン・アウトラインを作成するには、SELECT_CATALOG_ROLE
ロールも必要です。
個々のセッションまたはシステムに対して、ストアド・アウトラインを動的に使用可能または使用禁止にできます。
USE_STORED_OUTLINES
パラメータを使用可能にすると、パブリック・アウトラインが使用可能になります。
USE_PRIVATE_OUTLINES
パラメータを使用可能にすると、プライベート・ストアド・アウトラインが使用可能になります。OR
REPLACE
を指定すると、既存のアウトラインを同じ名前の新しいアウトラインと置き換えることができます。
PUBLIC
を指定すると、PUBLIC
が使用するアウトラインを作成できます。これはデフォルトです。
PRIVATE
を指定すると、現行のセッションのみがプライベートに使用するアウトラインを作成できます。このアウトラインのデータは、現行のスキーマに格納されます。
ストアド・アウトラインに割り当てる一意の名前を指定します。outline
を指定しない場合、データベースがアウトライン名を生成します。
FROM
句を使用すると、既存のアウトラインのコピーによって新しいアウトラインを作成できます。デフォルトでは、パブリック領域のsource_category
が検索されます。PRIVATE
を指定すると、現行のスキーマのアウトラインが検索されます。
FROM
句を指定する場合、ON
句は指定できません。
ストアド・アウトラインをグループ化するために使用する任意の名前を指定します。たとえば、週末に使用するアウトラインの1つのカテゴリおよび四半期末に使用する別のカテゴリを指定できます。category
を指定しない場合、アウトラインはDEFAULT
カテゴリに格納されます。
文をコンパイルする際にアウトラインが作成されるSQL文を指定します。この句は、FROM
句を使用して既存のアウトラインのコピーを作成する場合のみに指定するオプションです。
指定できる文は、SELECT
、DELETE
、UPDATE
、INSERT
... SELECT
またはCREATE
TABLE
... AS
SELECT
のいずれかです。
この句には、次の制限事項があります。
次の文は、ON
文をコンパイルすることによってストアド・アウトラインを作成します。アウトラインはsalaries
という名前で、special
カテゴリに格納されます。
CREATE OUTLINE salaries FOR CATEGORY special ON SELECT last_name, salary FROM employees;
USE_STORED_OUTLINES
パラメータにspecial
が設定されている場合、同じSELECT
文が後でコンパイルされると、アウトラインsalaries
を作成する場合と同様に実行計画が生成されます。
次の文は、前述の例で作成したパブリック・カテゴリsalaries
に基づいて、ストアド・プライベート・アウトラインmy_salaries
を作成します。プライベート・アウトラインを作成する場合、プライベート・アウトラインを作成するユーザーには、DBMS_OUTLN_EDIT
パッケージに対するEXECUTE
オブジェクト権限が必要です。また、このパッケージのCREATE_EDIT_TABLES
プロシージャを実行する必要があります。
EXECUTE DBMS_OUTLN_EDIT.CREATE_EDIT_TABLES; CREATE OR REPLACE PRIVATE OUTLINE my_salaries FROM salaries;
次の文は、プライベート編集の後でプライベート・アウトラインをパブリック領域にコピー(公開)します。
CREATE OR REPLACE OUTLINE public_salaries FROM PRIVATE my_salaries;
パッケージはPL/SQLを使用して定義されます。このため、この項では一般的な情報について説明します。構文およびセマンティクスの詳細は『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE
PACKAGE
文を使用すると、ストアド・パッケージの仕様部を作成できます。パッケージとは、関連するプロシージャ、ファンクション、およびデータベース上にまとめて格納されるその他のプログラム・オブジェクトの集合のことです。パッケージ仕様部では、これらのオブジェクトを宣言します。後で指定するパッケージ本体では、これらのオブジェクトを定義します。
参照:
|
自分のスキーマ内にパッケージを作成または再作成する場合は、CREATE
PROCEDURE
システム権限が必要です。他のユーザーのスキーマ内にパッケージを作成または再作成する場合は、CREATE
ANY
PROCEDURE
システム権限が必要です。
Oracle Databaseのプリコンパイラ・プログラム内にCREATE
PACKAGE
文を埋め込む場合、キーワードEND-EXEC
に続けて、各言語の埋込みSQL文の終了記号を記述して文を終了する必要があります。
パッケージはPL/SQLを使用して定義されます。このため、このマニュアルの構文図ではSQLキーワードのみを示します。PL/SQLの構文、セマンティクスおよび例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
(plsql_source
については、『Oracle Database PL/SQL言語リファレンス』を参照してください。)
OR
REPLACE
を指定すると、既存のパッケージ仕様部を再作成できます。この句を指定した場合、パッケージに対して付与されていたオブジェクト権限を削除、再作成および再付与しなくても、既存のパッケージの仕様部を変更できます。パッケージ仕様部を変更した場合、その仕様部は自動的に再コンパイルされます。
再定義したパッケージに対して権限が付与されていたユーザーは、権限が再付与されなくてもそのパッケージにアクセスできます。
ファンクション索引がパッケージに依存している場合、索引にDISABLED
のマークが付きます。
plsql_source
の構文、セマンティクスおよび例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
パッケージ本体はPL/SQLを使用して定義されます。このため、この項では一般的な情報について説明します。構文およびセマンティクスの詳細は『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE
PACKAGE
BODY
文を使用すると、ストアド・パッケージの本体を作成できます。パッケージとは、関連するプロシージャ、ストアド・ファンクション、およびデータベース上にまとめて格納されるその他のプログラム・オブジェクトの集合のことです。パッケージ本体では、これらのオブジェクトを定義します。前述のCREATE
PACKAGE
文で定義するパッケージ仕様部では、これらのオブジェクトを宣言します。
一連のプロシージャやファンクションをスタンドアロンのスキーマ・オブジェクトとして作成するかわりの方法としてパッケージを使用する方法があります。
参照:
|
自分のスキーマ内にパッケージを作成または再作成する場合は、CREATE
PROCEDURE
システム権限が必要です。他のユーザーのスキーマ内にパッケージを作成または再作成する場合は、CREATE
ANY
PROCEDURE
システム権限が必要です。どちらの場合も、パッケージ本体はパッケージと同じスキーマ内に作成される必要があります。
Oracle Databaseのプリコンパイラ・プログラム内にCREATE
PACKAGE
BODY
文を埋め込む場合、キーワードEND-EXEC
に続けて、各言語の埋込みSQL文の終了記号を記述して文を終了する必要があります。
パッケージ本体はPL/SQLを使用して定義されます。このため、このマニュアルの構文図ではSQLキーワードのみを示します。PL/SQLの構文、セマンティクスおよび例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
(plsql_source
については、『Oracle Database PL/SQL言語リファレンス』を参照してください。)
OR
REPLACE
を指定すると、既存のパッケージ本体を再作成できます。この句を指定した場合、パッケージに対して付与されていたオブジェクト権限を削除、再作成および再付与しなくても、既存のパッケージの本体を変更できます。パッケージ本体を変更した場合、その本体は自動的に再コンパイルされます。
再定義したパッケージに対して権限が付与されていたユーザーは、権限が再付与されなくてもそのパッケージにアクセスできます。
plsql_source
の構文およびセマンティクスについては、『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE
PFILE
文を使用すると、バイナリのサーバー・パラメータ・ファイルまたは現行のメモリー内パラメータ設定をテキストの初期化パラメータ・ファイルにエクスポートできます。テキストのパラメータ・ファイルの作成は、データベースで使用している現行のパラメータ設定リストの取得に便利です。また、テキスト・エディタで簡単に編集でき、CREATE
SPFILE
文を使用してサーバー・パラメータ・ファイルに変換して戻すこともできます。
この文が正常に実行されると、サーバーにテキストのパラメータ・ファイルが作成されます。Oracle Real Application Clusters環境では、すべてのインスタンスのすべてのパラメータ設定が含まれます。サーバー・パラメータ・ファイルのパラメータ設定と同じ行のコメントも含まれます。
参照:
|
この文を実行するには、SYSDBA
ロールまたはSYSOPER
ロールが必要です。この文は、インスタンスの起動前と起動後のいずれかで実行できます。
作成するテキストのパラメータ・ファイル名を指定します。pfile_name
を指定しないと、プラットフォーム固有のデフォルトの初期化パラメータ・ファイル名が使用されます。pfile_name
には、パス接頭辞を含めることができます。パス接頭辞を指定しない場合は、データベースによってデフォルトの格納場所(プラットフォームによって異なる)のパス接頭辞が追加されます。
テキストのファイルを作成する元となるバイナリのサーバー・パラメータ・ファイル名を指定します。
spfile_name
を指定する場合、そのファイルがサーバーに存在する必要があります。ファイルがオペレーティング・システムのサーバー・パラメータ・ファイルのデフォルト・ディレクトリに存在しない場合、フルパス名を指定する必要があります。
spfile_name
を指定しない場合は、現在インスタンスに関連付けられているspfileがデータベースで使用されます。通常、これは起動時に使用されたspfileです。インスタンスにspfileが関連付けられていない場合は、プラットフォーム固有のデフォルトのサーバー・パラメータ・ファイル名が検索されます。このファイルが存在しない場合は、エラーが戻されます。MEMORY
を指定すると、現行のシステム全体のパラメータ設定を使用してpfileを作成できます。RAC環境では、作成されたファイルには各インスタンスからのパラメータ設定が含まれます。
次の例は、バイナリのサーバー・パラメータ・ファイルs_params.ora
からテキストのパラメータ・ファイルmy_init.ora
を作成します。
CREATE PFILE = 'my_init.ora' FROM SPFILE = 's_params.ora';
パッケージはPL/SQLを使用して定義されます。このため、この項では一般的な情報について説明します。構文およびセマンティクスの詳細は『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE
PROCEDURE
文を使用すると、スタンドアロンのストアド・プロシージャまたはコール仕様を作成できます。
プロシージャとは、名前によってコールできるPL/SQL文の集合です。コール仕様は、SQLおよびPL/SQLからコールできるように、Javaメソッドまたは第三世代言語(3GL)ルーチンを宣言します。コール仕様は、コールされたときに起動するJavaメソッドをOracle Databaseに指示します。また、引数および戻り値に対して実行する型変換もデータベースに指示します。
ストアド・プロシージャには、開発、整合性、セキュリティ、パフォーマンスおよびメモリー割当ての面でいくつかのメリットがあります。
参照:
|
自分のスキーマ内にプロシージャを作成または再作成する場合は、CREATE
PROCEDURE
システム権限が必要です。他のユーザーのスキーマ内にプロシージャを作成または再作成する場合は、CREATE
ANY
PROCEDURE
システム権限が必要です。
コール仕様を起動する場合、その他の権限が必要になることがあります。たとえば、Cコール仕様には、Cライブラリに対するEXECUTE
オブジェクト権限が必要です。
Oracleプリコンパイラ・プログラム内にCREATE
PROCEDURE
文を埋め込む場合、キーワードEND-EXEC
に続けて、各言語の埋込みSQL文の終了記号を記述して文を終了する必要があります。
パッケージ本体はPL/SQLを使用して定義されます。このため、このマニュアルの構文図ではSQLキーワードのみを示します。PL/SQLの構文、セマンティクスおよび例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
(plsql_source
については、『Oracle Database PL/SQL言語リファレンス』を参照してください。)
OR
REPLACE
を指定すると、既存のプロシージャを再作成できます。この句を指定した場合、プロシージャに付与されているオブジェクト権限を削除、再作成および再付与しなくても、既存のプロシージャの定義を変更できます。プロシージャを再定義した場合、そのプロシージャは自動的に再コンパイルされます。
再定義したプロシージャに対して権限が付与されていたユーザーは、権限が再付与されなくてもそのプロシージャにアクセスできます。
ファンクション索引がパッケージに依存している場合、索引にDISABLED
のマークが付きます。
plsql_source
の構文およびセマンティクスについては、『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE
PROFILE
文を使用すると、プロファイルを作成できます。プロファイルとは、データベース・リソースの制限の設定です。あるユーザーに対してプロファイルを割り当てた場合、そのユーザーは、その割当て制限を超えることはできません。
プロファイルを作成する場合、CREATE
PROFILE
システム権限が必要です。
次の方法でユーザーに対するリソース制限を指定します。
ALTER
SYSTEM
文または初期化パラメータRESOURCE_LIMIT
で動的にリソース制限を使用可能にします。このパラメータは、パスワード・リソースには適用されません。パスワード・リソースは、常に使用可能です。
CREATE
PROFILE
文を使用して、制限を定義するプロファイルを作成します。
CREATE
USER
またはALTER
USER
文を使用して、プロファイルを割り当てます。
参照:
RESOURCE_LIMIT
パラメータについては、『Oracle Databaseリファレンス』を参照してください。
(size_clause::=を参照)
作成するプロファイルの名前を指定します。プロファイルを使用した場合、ユーザーが使用可能なデータベース・リソースを1つのコールまたは1つのセッションごとに制限できます。
Oracle Databaseでは、次の方法でリソース制限を適用します。
CONNECT_TIME
またはIDLE_TIME
で指定したセッション・リソース制限を超えた場合、現行のトランザクションが自動的にロールバックされ、セッションが終了します。ユーザー・プロセスで次にコールを実行すると、エラーが戻ります。
リソース・パラメータでUNLIMITED
を指定すると、このプロファイルを割り当てられたユーザーは無制限にリソースを使用できます。パスワード・パラメータでUNLIMITED
を指定した場合は、パラメータに制限が設定されていないことを示します。
DEFAULT
を指定すると、このプロファイルでリソースの制限を省略できます。このプロファイルを割り当てられたユーザーは、DEFAULT
プロファイルで指定した対象リソースに対する制限を受けます。DEFAULT
プロファイルは、最初に無制限のリソースを定義します。ALTER
PROFILE
文でこの制限を変更できます。
明示的にプロファイルが割り当てられていないユーザーは、DEFAULT
プロファイルに定義されている制限を受けます。ユーザーに明示的に割り当てられているプロファイルでリソースに対する制限が省略されている場合、または制限に対してDEFAULT
が指定されている場合、ユーザーはDEFAULT
プロファイルで定義されているリソースに関する制限を受けます。
ユーザーを制限する同時セッションの数を指定します。
1セッション当たりのCPU時間制限を指定します。この値は100分の1秒単位で指定します。
1コール(解析、実行またはフェッチ)当たりのCPU時間制限を指定します。この値は100分の1秒単位で指定します。
1セッション当たりの合計経過時間制限を指定します。この値は分単位で指定します。
セッション中の連続的な非活動時間の長さを制限します。この値は分単位で指定します。長時間実行の問合せなどの処理は、この制限を受けません。
メモリーおよびディスクから読み込まれるブロックなど、1セッション中に読み込まれるデータ・ブロックの数の制限を指定します。
SQL文(解析、実行またはフェッチ)を処理する1つのコールで読み込まれるデータ・ブロックの数の制限を指定します。
1つのセッションでシステム・グローバル領域(SGA)の共有プール内に割り当てることができるプライベート領域の大きさを指定します。この句の詳細は、「size_clause」を参照してください。
1セッション当たりのリソースの総コストをサービス単位で指定します。サービス単位の合計は、CPU_PER_SESSION
、CONNECT_TIME
、LOGICAL_READS_PER_SESSION
およびPRIVATE_SGA
の重み付き合計として計算されます。
次の句を使用すると、パスワード・パラメータを設定できます。時間の長さを設定するパラメータは、日数で解析されます。テストのために、分(n/1440)または秒(n/86400)を指定できます。
ユーザー・アカウントがロックされる前に、そのアカウントへのログインに失敗できる回数を指定します。この句を指定しない場合、10日がデフォルトになります。
同じパスワードを認証に使用できる日数を制限します。PASSWORD_GRACE_TIME
の値とともに設定した場合、猶予期間内にパスワードを変更しないと、そのパスワードは使用できなくなり、それ以降の接続は拒否されます。この句を指定しない場合、180日がデフォルトになります。
これら2つのパラメータは、両方を組み合せて設定する必要があります。PASSWORD_REUSE_TIME
は、パスワードを再利用できない日数を指定します。PASSWORD_REUSE_MAX
は、現行のパスワードを再利用する前に必要な、パスワードの変更回数を指定します。これらのパラメータを有効にするには、両方のパラメータに整数を指定する必要があります。
PASSWORD_REUSE_TIME
に指定した日数の間は、PASSWORD_REUSE_MAX
に指定した回数パスワードが変更されるまで、パスワードを再利用できません。たとえば、PASSWORD_REUSE_TIME
に30を指定し、PASSWORD_REUSE_MAX
に10を指定した場合、パスワードが10回変更されていると、30日後にパスワードを再利用できます。
UNLIMITED
を指定すると、パスワードを再利用できません。
DEFAULT
を指定すると、DEFAULT
プロファイルに定義された値が使用されます。DEFAULT
プロファイルでは、すべてのパラメータはデフォルトでUNLIMITED
に設定されます。DEFAULT
プロファイルのデフォルト設定のUNLIMITED
を変更していない場合、パラメータの値はUNLIMITED
として扱われます。
UNLIMITED
に設定すると、これらのパラメータは無視されます。これは、両方のパラメータを指定しない場合のデフォルトです。
ログインが指定された回数連続して失敗した場合、アカウントがロックされる日数を指定します。この句を指定しない場合、1日がデフォルトになります。
警告が出され、ログインが許可される猶予期間の日数を指定します。この句を指定しない場合、7日がデフォルトになります。
PASSWORD_VERIFY_FUNCTION
句を使用すると、PL/SQLの複雑なパスワード検証スクリプトをCREATE
PROFILE
文の引数として渡すことができます。Oracle Databaseにはデフォルトのスクリプトがありますが、ユーザー固有のルーチンを作成することも、サード・パーティのソフトウェアを使用することもできます。
パスワード・パラメータにexpr
を指定する場合、スカラー副問合せ式を除くすべての形式の式を指定できます。
次の文は、プロファイルnew_profile
を作成します。
CREATE PROFILE new_profile LIMIT PASSWORD_REUSE_MAX 10 PASSWORD_REUSE_TIME 30;
次の文は、プロファイルapp_user
を作成します。
CREATE PROFILE app_user LIMIT SESSIONS_PER_USER UNLIMITED CPU_PER_SESSION UNLIMITED CPU_PER_CALL 3000 CONNECT_TIME 45 LOGICAL_READS_PER_SESSION DEFAULT LOGICAL_READS_PER_CALL 1000 PRIVATE_SGA 15K COMPOSITE_LIMIT 5000000;
ユーザーにapp_user
プロファイルを割り当てた場合、そのユーザーは、後続のセッションで次の制限を受けます。
DEFAULT
プロファイルで指定した制限を受けます。
ALTER
RESOURCE
COST
文で指定します。
app_user
プロファイルでは、IDLE_TIME
およびパスワードに対する制限が指定されていないため、ユーザーはDEFAULT
プロファイルに指定されているこれらのリソースの制限を受けます。
次の文は、app_user2
プロファイルに、パスワード制限値を設定して作成します。
CREATE PROFILE app_user2 LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LIFE_TIME 60 PASSWORD_REUSE_TIME 60 PASSWORD_REUSE_MAX 5 PASSWORD_VERIFY_FUNCTION verify_function PASSWORD_LOCK_TIME 1/24 PASSWORD_GRACE_TIME 10;
この例では、Oracle Databaseのデフォルトのパスワード検証ファンクションverify_function
を使用します。この検証ファンクションの使用方法または独自の検証ファンクションの設計方法については、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CREATE
RESTORE
POINT
文を使用すると、リストア・ポイント(タイムスタンプまたはデータベースのSCNに関連付けられた名前)を作成できます。リストア・ポイントを使用すると、表またはデータベースをリストア・ポイントによって指定された時点にフラッシュバックできます。その際、SCNやタイムスタンプを指定する必要はありません。リストア・ポイントは、バックアップやデータベースの複製など、様々なRecovery Manager操作でも有効です。Recovery Managerを使用して、アーカイブ・バックアップの実装プロセスにリストア・ポイントを作成できます。
参照:
|
通常のリストア・ポイントを作成するには、SELECT
ANY
DICTIONARY
権限またはFLASHBACK
ANY
TABLE
権限のいずれかが必要です。保証付きリストア・ポイントを作成するには、SYSDBA
システム権限が必要です。
リストア・ポイントを表示または使用するには、SELECT
ANY
DICTIONARY
またはFLASHBACK
ANY
TABLE
のいずれかのシステム権限か、SELECT_CATALOG_ROLE
ロールが必要です。
リストア・ポイントは、プライマリ・データベースまたはスタンバイ・データベースに作成できます。データベースは、オープンされている状態でも、マウントされているがオープンされていない状態でもかまいません。データベースがマウントされている場合、それが物理スタンバイ・データベースでなければ、整合性を保持して停止されてからマウントされている必要があります。
保証付きリストア・ポイントを作成する場合は、その前に、フラッシュ・リカバリ領域を作成しておく必要があります。フラッシュバック・データベースを使用可能にしておかなくても、リストア・ポイントは作成できます。ただし、フラッシュバック・データベースが使用可能になっていない場合、このデータベースに作成する最初の保証付きリストア・ポイントは、データベースのマウント時に作成する必要があります。保証付きリストア・ポイントを作成する場合、データベースはARCHIVELOG
モードになっていることが必要です。
リストア・ポイントの名前を指定します。名前は、最大128文字の文字値です。
データベースには、最大2048個のリストア・ポイントを保持できます。リストア・ポイントは、少なくとも初期化パラメータCONTROL_FILE_RECORD_KEEP_TIME
で指定された日数はデータベース内に保持されます。そのパラメータのデフォルト値は7日です。保証付きおよび保存済のリストア・ポイントは、ユーザーが明示的に削除するまでデータベース内に保持されます。
PRESERVE
もGUARANTEE FLASHBACK DATABASE
も指定しない場合、結果のリストア・ポイントによって、DB_FLASHBACK_RETENTION_TARGET
初期化パラメータで設定された期間内のリストア・ポイントにデータベースをフラッシュバックできます。そのようなリストア・ポイントは、データベースによって自動的に管理されます。リストア・ポイントの数が、前述のrestore_point
で定められた最大数に達すると、最も古いリストア・ポイントが自動的に削除されます。一定の状況では長期バックアップのリストアに使用するために、リストア・ポイントはRecovery Managerリカバリ・カタログに保持されます。DROP
RESTORE
POINT
文を使用して、リストア・ポイントを明示的に削除することもできます。
この句を使用すると、過去の指定した日時またはSCNでリストア・ポイントを作成できます。TIMESTAMP
を指定する場合、expr
は過去の日時となる有効な日時式である必要があります。SCNを指定する場合、expr
は過去のデータベースの有効なSCNである必要があります。どちらの場合にも、expr
はデータベースの現行のインカネーションの日時またはSCNを参照する必要があります。
PRESERVE
を指定すると、リストア・ポイントを明示的に削除する必要があることを指定できます。このようなリストア・ポイントは、フラッシュバック履歴機能で使用するために作成すると有効です。
保証付きリストア・ポイントの場合、初期化パラメータDB_FLASHBACK_RETENTION_TARGET
の設定とは無関係に、データベースをリストア・ポイントに確定的にフラッシュバックできます。フラッシュバック機能が保証されるかどうかは、フラッシュ・リカバリ領域に十分な使用可能スペースがあるかどうかによって決まります。
保証付きリストア・ポイントで保証されるのは、データベースを保証付きリストア・ポイントにフラッシュバックするのに十分なフラッシュバック・ログが、データベースに保持されるということのみです。すべての表を同じリストア・ポイントにフラッシュバックするためのUNDOがデータベースに保持されるかどうかは保証されません。
保証付きリストア・ポイントは、常に保存されます。DROP
RESTORE
POINT
文を使用してユーザーが明示的に削除する必要があります。このリストア・ポイントは、期限切れになることはありません。保証付きリストア・ポイントは、フラッシュ・リカバリ領域内の領域を大量に使用する場合があります。このため、保証付きリストア・ポイントは十分に検討したうえで作成することをお薦めします。
次の例では、通常のリストア・ポイントを作成し、表を更新してから、変更した表をリストア・ポイントにフラッシュバックします。この例は、ユーザーhr
がそれぞれの文を使用する適切なシステム権限を持っていることを前提としています。
CREATE RESTORE POINT good_data; SELECT salary FROM employees WHERE employee_id = 108; SALARY ---------- 12000 UPDATE employees SET salary = salary*10 WHERE employee_id = 108; SELECT salary FROM employees WHERE employee_id = 108; SALARY ---------- 120000 COMMIT; FLASHBACK TABLE employees TO RESTORE POINT good_data; SELECT salary FROM employees WHERE employee_id = 108; SALARY ---------- 12000
CREATE
ROLE
文を使用すると、ロールを作成できます。ロールは、ユーザーまたは他のロールに付与できる権限の集合です。ロールを使用してデータベース権限を管理できます。ロールに権限を追加したうえで、ユーザーにそのロールを付与できます。その後、ユーザーはロールを使用可能にし、そのロールによって付与された権限を使用できるようになります。
ロールには、そのロールに付与されたすべての権限、およびそのロールに付与された他のロールのすべての権限が含まれています。新しく作成されたロールには、ロールや権限は付与されていません。GRANT
文を使用して、ロールに様々な権限を追加します。
NOT
IDENTIFIED
、IDENTIFIED
EXTERNALLY
またはBY
password
ロールを作成した場合、そのロールはADMIN
OPTION
付きで付与されます。ただし、ロールIDENTIFIED
GLOBALLY
を作成した場合、ロールは付与されません。
参照:
|
CREATE
ROLE
システム権限が必要です。
作成するロールの名前を指定します。データベース・キャラクタ・セットにマルチバイト文字がサポートされている場合でも、ロールにはシングルバイト文字を1つ以上使用することをお薦めします。各ユーザーに対し、一度に使用可能にできるユーザー定義のロールの最大数は148です。
配布メディアで提供されているSQLスクリプトには、いくつかのロールが定義されています。
NOT
IDENTIFIED
を指定すると、指定するロールがデータベースによって認可され、パスワードを入力しなくてもこのロールを使用可能にできます。
IDENTIFIED
句を使用すると、SET
ROLE
文によってロールを使用可能にする前に、指定したメソッドによってユーザーが認可される必要があります。
BY
password
句を使用すると、ローカル・ロールを作成できます。また、ロールを使用可能にするときに、パスワードを指定する必要があることを指定できます。データベース・キャラクタ・セットにマルチバイト文字が含まれている場合でも、データベース・キャラクタ・セットのシングルバイト文字のみでパスワードを指定できます。
USING
package
句を使用すると、保護アプリケーション・ロールを作成できます。保護アプリケーション・ロールとは、認可済パッケージのみを使用するアプリケーションよって使用可能になるロールです。schema
を指定しない場合、パッケージが自分のスキーマ内にあるとみなされます。
EXTERNALLY
を指定すると、外部ロールを作成できます。外部ユーザーは、ロールを使用可能にする前に、オペレーティング・システムやサード・パーティ・サービスなどの外部サービスによって認可されている必要があります。
オペレーティング・システムによっては、ユーザーがオペレーティング・システムに対してパスワードを指定しないと、ロールが使用可能にできない場合もあります。
GLOBALLY
を指定すると、グローバル・ロールを作成できます。グローバル・ユーザーは、ログイン時にロールの使用が可能になる前に、エンタープライズ・ディレクトリ・サービスによってロールの使用を認可されている必要があります。
NOT
IDENTIFIED
句およびIDENTIFIED
句を両方とも省略した場合、ロールにはNOT
IDENTIFIED
がデフォルト値として使用されます。
次の文は、ロールdw_manager
を作成します。
CREATE ROLE dw_manager;
この後にdw_manager
ロールを付与されるユーザーは、このロールに付与されているすべての権限を継承します。
次の例のように、パスワードの指定によってロールにセキュリティのレイヤーを追加できます。
CREATE ROLE dw_manager IDENTIFIED BY warehouse;
この後、dw_manager
ロールを付与されたユーザーは、パスワードwarehouse
を指定して、SET
ROLE
文でロールを使用可能にする必要があります。
次の文は、グローバル・ロールwarehouse_user
を作成します。
CREATE ROLE warehouse_user IDENTIFIED GLOBALLY;
次の文は、同じロールを外部ロールとして作成します。
CREATE ROLE warehouse_user IDENTIFIED EXTERNALLY;
CREATE ROLLBACK SEGMENT
文を使用すると、ロールバック・セグメントを作成できます。ロールバック・セグメントとは、トランザクションによる変更を元に戻す(取り消す)ために必要なデータを格納する際にOracle Databaseが使用するオブジェクトです。
ここでは、データベースがロールバックUNDOモードで実行されている(初期化パラメータUNDO_MANAGEMENT
にMANUAL
を設定、またはすべて設定しない)ことを前提としています。データベースが自動UNDOモードで実行されている場合(初期化パラメータUNDO_MANAGEMENT
にデフォルト値のAUTO
を設定)、ユーザー作成のロールバック・セグメントには関連がなくなります。
また、データベースにローカル管理SYSTEM
表領域がある場合、ディクショナリ管理表領域にロールバック・セグメントは作成できません。かわりに、自動UNDO管理機能を使用するか、またはローカル管理表領域を作成して、ロールバック・セグメントを保持する必要があります。
SYSTEM
以外の表領域のオブジェクトを使用する場合は、次の注意事項があります。
SYSTEM
ロールバック・セグメント以外)がオンラインである必要があります。
UNDO
表領域がオンラインである必要があります。
参照:
UNDO_MANAGEMENT
パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
ロールバック・セグメントを作成するには、CREATE ROLLBACK SEGMENT
システム権限が必要です。
(storage_clauseを参照)
PUBLIC
を指定すると、ロールバック・セグメントがパブリックとなり、すべてのインスタンスに対して使用可能にできます。この句を省略した場合、ロールバック・セグメントはプライベートになり、インスタンスの初期化パラメータROLLBACK_SEGMENTS
で指定したインスタンスに対してのみ使用可能になります。
作成するロールバック・セグメントの名前を指定します。
TABLESPACE
句を使用すると、ロールバック・セグメントが作成される表領域を指定できます。この句を省略した場合、ロールバック・セグメントはSYSTEM
表領域に作成されます。
storage_clause
を使用すると、ロールバック・セグメントの記憶特性を指定できます。
storage_clause
のOPTIMAL
パラメータは、ロールバック・セグメントにのみ適用されるので、特に重要です。
storage_clause
のPCTINCREASE
パラメータは、CREATE ROLLBACK SEGMENT
では指定できません。次の文は、適切に構成された表領域にデフォルトの記憶域値でロールバック・セグメントを作成します。
CREATE TABLESPACE rbs_ts DATAFILE 'rbs01.dbf' SIZE 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 100K; /* This example and the next will fail if your database is in automatic undo mode. */ CREATE ROLLBACK SEGMENT rbs_one TABLESPACE rbs_ts;
前述の文は、次の文と同じ結果になります。
CREATE ROLLBACK SEGMENT rbs_one TABLESPACE rbs_ts STORAGE ( INITIAL 10K NEXT 10K MAXEXTENTS UNLIMITED );
CREATE
SCHEMA
文を使用すると、複数表およびビューを作成し、自分のスキーマ内に1つのトランザクションで複数の権限を付与できます。
CREATE
SCHEMA
文を実行すると、挿入されている個々の文が実行されます。すべての文が正常に実行された場合、そのトランザクションがコミットされます。文の結果が1つでもエラーになった場合は、すべての文がロールバックされます。
注意: この文では、実際にスキーマが作成されるわけではありません。ユーザーを作成すると、自動的にスキーマが作成されます(「CREATE USER」を参照)。この文を実行すると、複数のトランザクションで複数のSQL文を発行しなくても、スキーマに表およびビューが移入され、これらのオブジェクトに対する権限が付与されます。 |
CREATE
SCHEMA
文には、CREATE
TABLE
文、CREATE
VIEW
文およびGRANT
文を含めることができます。CREATE
SCHEMA
文を発行する場合は、挿入した文を発行するための権限が必要です。
スキーマの名前を指定します。スキーマ名は、Oracle Databaseユーザー名と一致している必要があります。
このCREATE SCHEMA
文の一部として発行するCREATE
TABLE
文を指定します。この文の終わりには、セミコロン(またはその他の終了文字)を付けないでください。
このCREATE
SCHEMA
文の一部として発行するCREATE
VIEW
文を指定します。この文の終わりには、セミコロン(またはその他の終了文字)を付けないでください。
このCREATE
SCHEMA
文の一部として発行するGRANT
文を指定します。この文の終わりには、セミコロン(またはその他の終了文字)を付けないでください。この句を使用すると、所有するオブジェクトに対するオブジェクト権限を、他のユーザーに付与できます。また、WITH
ADMIN
OPTION
付きでシステム権限を付与されている場合、それらの権限を他のユーザーに付与できます。
CREATE
SCHEMA
文は、Oracle Databaseでサポートされている完全な構文ではなく、標準SQLで定義されている構文のみをサポートします。
CREATE
TABLE
、CREATE
VIEW
およびGRANT
の各文を指定する順序は重要ではありません。CREATE
SCHEMA
文の中の文では、既存のオブジェクトまたは同じCREATE
SCHEMA
文の他の文で作成したオブジェクトを参照できます。
parallel_clause
構文は、CREATE
SCHEMA
のCREATE
TABLE
文で使用できますが、オブジェクトの作成時に並列度は使用されません。
次の文は、サンプルの注文入力ユーザーoe
用のoe
という名前のスキーマ、表new_product
、ビューnew_product_view
を作成し、サンプルの人事情報のユーザーhr
にnew_product_view
に対するSELECT
オブジェクト権限を付与します。
CREATE SCHEMA AUTHORIZATION oe CREATE TABLE new_product (color VARCHAR2(10) PRIMARY KEY, quantity NUMBER) CREATE VIEW new_product_view AS SELECT color, quantity FROM new_product WHERE color = 'RED' GRANT select ON new_product_view TO hr;
CREATE
SEQUENCE
文を使用すると、順序を作成できます。順序とは、データベース・オブジェクトの1つで、これを使用して複数のユーザーが一意の整数を生成することができます。順序を使用した場合、主キー値が自動的に生成されます。
順序番号が生成されると、順序はトランザクションのコミットやロールバックとは無関係に増加していきます。2人のユーザーが、同時に同一の順序を増加させると、ユーザーがそれぞれ順序番号を生成しているため、取得する順序番号間に違いが発生することもあります。他のユーザーが生成した順序番号は取得できません。あるユーザーが順序値を生成すると、他のユーザーがその順序を増加させたかどうかに関係なく、順序を生成したユーザーは引き続きその値にアクセスできます。
順序番号は表から独立して生成されるため、1つ以上の表に対して同一の順序を使用することができます。生成された順序番号が、最終的にロールバックされるトランザクションで使用されたため、個々の順序番号が連続していないように見える場合があります。また、他のユーザーが同一順序を使用していることを個々のユーザーが認識しない場合もあります。
順序が作成されると、SQL文の中でCURRVAL
疑似列を使用してその値にアクセスできます(この場合、その順序の現在の値が戻ります)。また、NEXTVAL
疑似列を使用してもアクセスできます(この場合は、順序が増加され、新しい値が戻ります)。
参照:
|
自分のスキーマ内に順序を作成する場合は、CREATE
SEQUENCE
システム権限が必要です。
他のユーザーのスキーマ内に順序を作成する場合は、CREATE
ANY
SEQUENCE
システム権限が必要です。
順序を含めるスキーマを指定します。schema
を省略した場合、自分のスキーマ内に順序が作成されます。
作成する順序の名前を指定します。
次の句のうちどれも指定しない場合は、1から始まる昇順の順序が作成され、上限なしで1ずつ増加していきます。INCREMENT
BY
に-1のみを指定した場合は、初期値を-1として、下限なしで1つずつ減少していきます。
MAXVALUE
パラメータを省略するか、またはNOMAXVALUE
を指定します。降順の場合は、MINVALUE
パラメータを省略するか、またはNOMINVALUE
を指定します。
MAXVALUE
パラメータに値を指定します。降順の場合は、MINVALUE
パラメータの値を指定します。NOCYCLE
も指定します。順序が制限に達したときに順序番号をさらに生成しようとした場合、エラーが発生します。
MAXVALUE
パラメータとMINVALUE
パラメータの両方に値を指定します。CYCLE
も指定します。MINVALUE
を指定しない場合、デフォルトでNOMINVALUE
(値1)が設定されます。
順序の番号間の増分間隔を指定します。この値は、0(ゼロ)以外の正の整数または負の整数になります。この値には、28桁以内の値を指定できます。この値の絶対値は、MAXVALUE
とMINVALUE
の差未満である必要があります。この値が負の場合、順序は降順になります。この値が正の場合、順序は昇順になります。この句を省略した場合、デフォルトで増分間隔は1に設定されます。
生成する順序番号の初期値を指定します。この句を指定した場合、順序の最小値より大きい値を初期値として昇順を開始することも、最大値よりも小さい値を初期値として降順を開始することもできます。昇順の場合、デフォルト値は順序の最小値になります。降順の場合、デフォルト値は順序の最大値になります。28桁以内の整数値を指定できます。
順序の最大値を指定します。28桁以内の整数値を指定できます。MAXVALUE
値は、START
WITH
以上で、かつMINVALUE
を超える値である必要があります。
NOMAXVALUE
を指定すると、順序の最大値を、昇順の場合は1027、降順の場合は-1に指定できます。これはデフォルトです。
順序の最小値を指定します。28桁以内の整数値を指定できます。MINVALUE
値は、START
WITH
以下で、かつMAXVALUE
未満である必要があります。
NOMINVALUE
を指定すると、順序の最小値を、昇順の場合は1、降順の場合は-1026に指定できます。これはデフォルトです。
CYCLE
を指定すると、順序が最大値または最小値に達しても、引き続き値を生成できます。つまり、昇順の場合は、最大値に達すると最小値が生成されます。降順の場合は、最小値に達すると最大値が生成されます。
NOCYCLE
を指定すると、順序が最大値または最小値に達した場合は、それ以上値を生成しないように指定できます。これはデフォルトです。
より高速に順序番号にアクセスできるように、メモリー上に事前に割り当て、保持しておく順序番号の数を指定します。28桁以内の整数値を指定できます。このパラメータの最小値は2です。循環する順序の場合、この値は、そのサイクル内で生成される値の数未満である必要があります。指定したサイクル内で生成される順序番号の数を超える値はキャッシュできません。したがって、CACHE
に指定できる値の最大値は、次の式で求められる値未満である必要があります。
(CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT)
システム障害が発生すると、キャッシュされた順序の値のうち、コミットされたDML文で使用されていなかったものはすべて失われます。したがって、失われる可能性がある値の数は、CACHE
パラメータの値と等しくなります。
NOCACHE
を指定すると、順序の値を事前に割り当てないように指定できます。CACHE
およびNOCACHE
の両方を省略した場合、デフォルトで20の順序番号がキャッシュされます。
ORDER
を指定すると、要求どおりの順序で順序番号を生成することを保証できます。順序番号をタイムスタンプとして使用する場合に、この句は有効です。通常、主キー生成用の順序については、順序どおりに生成するかどうかの保証は重要ではありません。
Oracle Real Application Clustersを使用する場合、ORDER
は順序どおりの生成を確保する場合にのみ必要です。排他モードの場合、順序番号は必ず順序どおりに生成されます。
NOORDER
を指定すると、要求どおりの順で順序番号を生成することは保証されません。これはデフォルトです。
次の文は、サンプル・スキーマoe
に順序customers_seq
を作成します。この順序は、customers
表に行が追加されるときに、顧客ID番号として使用できます。
CREATE SEQUENCE customers_seq START WITH 1000 INCREMENT BY 1 NOCACHE NOCYCLE;
最初にcustomers_seq.nextval
を参照したときは、1000が戻されます。次に参照したときは、1001が戻されます。同様に、この後の各参照で、前回参照された値より1大きい値が戻されます。
CREATE
SPFILE
を使用すると、従来のプレーンテキストの初期化パラメータ・ファイルまたは現行のシステム全体の設定から、サーバー・パラメータ・ファイルを作成できます。サーバー・パラメータ・ファイルは、サーバーのみに存在し、データベースを起動するためにクライアントからコールされるバイナリ・ファイルです。
サーバー・パラメータ・ファイルを指定すると、個々のパラメータを永続的に変更できます。サーバー・パラメータ・ファイルを使用する場合、新しいパラメータ値を永続化するALTER
SYSTEM
SET
parameter
文を指定できます。新しい値は、現行のインスタンスのみでなく、その後で起動するすべてのインスタンスにおいて適用されます。従来のプレーンテキストのパラメータ・ファイルでは、パラメータ値を永続的に変更できません。
サーバー・パラメータ・ファイルは、サーバー上に存在するため、Oracle Databaseによる自動データベースのチューニングおよびRecovery Managerによるバックアップが可能です。
データベースの起動時にサーバー・パラメータ・ファイルを使用するには、CREATE
SPFILE
文を使用してサーバー・パラメータ・ファイルを作成する必要があります。
Oracle Real Application Clusters環境のすべてのインスタンスは、同一のサーバー・パラメータ・ファイルを使用する必要があります。ただし、個々のインスタンスで1つのファイル内の同じパラメータで異なる設定が可能な場合もあります。インスタンス固有のパラメータ定義は、SID.parameter = value
で指定します。SID
にはインスタンス識別子を指定します。
サーバー・パラメータ・ファイルを使用したデータベースの起動方法は、作成したサーバー・パラメータ・ファイルをデフォルトで作成したか、または非デフォルトで作成したかによって異なります。サーバー・パラメータ・ファイルの使用方法については、「サーバー・パラメータ・ファイルの作成例:」を参照してください。
参照:
|
この文を実行するには、SYSDBA
システム権限またはSYSOPER
システム権限が必要です。この文は、インスタンスの起動前と起動後のいずれかで実行できます。ただし、spfile_name
を使用して、インスタンスがすでに起動済の場合は、この文で同じspfile_name
を指定できません。
この句を指定すると、作成するサーバー・パラメータ・ファイルの名前を指定できます。
spfile_name
を指定しない場合、プラットフォーム固有のデフォルトのサーバー・パラメータ・ファイル名が使用されます。spfile_name
がサーバーにすでに存在する場合、そのファイルは上書きされます。デフォルトのサーバー・パラメータ・ファイルを使用する場合、ファイル名を参照せずにデータベースが起動されます。
spfile_name
を指定する場合、デフォルト以外のサーバー・パラメータ・ファイルを作成します。この場合、データベースを起動するときに、サーバー・パラメータ・ファイルを指す単一行の以前のパラメータ・ファイルを作成し、STARTUP
コマンドで単一行のファイルを指定する必要があります。
spfile_name
には、パス接頭辞を含めることができます。パス接頭辞を指定しない場合は、データベースによってデフォルトの格納場所(プラットフォームによって異なる)のパス接頭辞が追加されます。
参照:
|
サーバー・パラメータ・ファイルを作成する元になる従来のプレーンテキストの初期化パラメータ・ファイル名を指定します。従来のパラメータ・ファイルは、サーバー上にある必要があります。
pfile_name
を指定して、従来のパラメータ・ファイルがオペレーティング・システムのパラメータ・ファイルのデフォルト・ディレクトリに存在しない場合は、フルパス名を指定する必要があります。
pfile_name
を指定しない場合、オペレーティング・システムのパラメータ・ファイルのデフォルト・ディレクトリからデフォルトのパラメータ・ファイル名が検索され、使用されます。そのディレクトリにファイルが存在しない場合、エラーが戻されます。MEMORY
を指定すると、現行のシステム全体のパラメータ設定を使用してspfileを作成できます。RAC環境では、作成されたファイルには各インスタンスからのパラメータ設定が含まれます。
次の例は、クライアントの初期化パラメータ・ファイルt_init1.ora
からデフォルトのサーバー・パラメータ・ファイルを作成します。
CREATE SPFILE FROM PFILE = '$ORACLE_HOME/work/t_init1.ora';
デフォルトのサーバー・パラメータ・ファイルを作成する場合、その後のデータベースの起動は、次のようにPFILE
パラメータなしでSQL*PlusのコマンドSTARTUP
を実行し、サーバー・パラメータ・ファイルを使用します。
STARTUP
次の例は、クライアントの初期化パラメータ・ファイルt_init1.ora
からデフォルト以外のサーバー・パラメータ・ファイルs_params.ora
を作成します。
CREATE SPFILE = 's_params.ora' FROM PFILE = '$ORACLE_HOME/work/t_init1.ora';
デフォルト以外のサーバー・パラメータ・ファイルを作成する場合、次の単一行を含む以前のパラメータ・ファイルを最初に作成し、その後でデータベースを起動します。
spfile = 's_params.ora'
このパラメータ・ファイル名は、ご使用のオペレーティング・システムのネーミング規則に従う必要があります。その後、STARTUP
コマンドで単一行のパラメータ・ファイルを使用します。次の例では、単一行のパラメータ・ファイルの名前がnew_param.ora
であるとした場合のデータベースの起動方法を示します。
STARTUP PFILE=new_param.ora
|
![]() Copyright © 1996, 2008, Oracle Corporation. All Rights Reserved. |
|