Oracle Database SQL言語リファレンス 11g リリース1(11.1) E05750-03 |
|
この章では、次のSQL文について説明します。
DROP
SEQUENCE
文を使用すると、データベースから順序を削除できます。
この文を使用すると、順序の削除および再作成を行って、順序を再開することもできます。たとえば、現在、値が150の順序を初期値27で再開する場合、順序を削除して同じ名前で再作成し、START
WITH
値を27にします。
削除する順序が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
SEQUENCE
システム権限が必要です。
順序が含まれているスキーマを指定します。schema
を指定しない場合、順序は自分のスキーマ内にあるとみなされます。
削除する順序の名前を指定します。
次の文は、ユーザーoe
が所有する順序customers_seq
(「順序の作成例:」で作成)を削除します。この文を発行する場合は、ユーザーoe
として接続するか、またはDROP
ANY
SEQUENCE
システム権限が必要です。
DROP SEQUENCE oe.customers_seq;
DROP
SYNONYM
文を使用すると、データベースからシノニムを削除できます。また、シノニムの削除および再作成を行って、シノニムの定義を変更することもできます。
プライベート・シノニムを削除する場合は、シノニムが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
SYNONYM
システム権限が必要です。
パブリック・シノニムを削除する場合は、DROP
PUBLIC
SYNONYM
システム権限が必要です。
PUBLIC
を指定すると、パブリック・シノニムを削除できます。PUBLIC
を指定した場合、schema
は指定できません。
シノニムが含まれているスキーマを指定します。schema
を指定しない場合、シノニムは自分のスキーマ内にあるとみなされます。
削除するシノニムの名前を指定します。
マテリアライズド・ビューを定義する問合せに実際の表名ではなくシノニムが指定されていた場合に、このマテリアライズド・ビューのマスター表のシノニムを削除すると、このマテリアライズド・ビューには使用禁止のマークが付けられます。
依存表またはユーザー定義型を持つオブジェクト型のシノニムを削除するには、FORCE
も指定する必要があります。
FORCE
を指定すると、依存表またはユーザー定義型を持つシノニムでも強制的に削除できます。
次の文は、パブリック・シノニムcustomers
(「Oracle Databaseによるシノニムの変換例:」で作成)を削除します。
DROP PUBLIC SYNONYM customers;
DROP
TABLE
文を使用すると、表またはオブジェクト表をごみ箱に移動したり、表およびそれに含まれるすべてのデータをデータベースから完全に削除することができます。
外部表の場合、この文はデータベースにある表のメタデータのみを削除します。データベースの外部に存在する実際のデータには影響しません。
クラスタの一部である表を削除すると、その表はごみ箱に移動します。ただし、その後にそのクラスタを削除すると、その表はごみ箱から消去され、FLASHBACK TABLE
操作でもリカバリできなくなります。
表を削除すると、依存オブジェクトが無効になり、表のオブジェクト権限が取り消されます。表を再作成する際、表のオブジェクト権限を再度付与し、表の索引、整合性制約およびトリガーを再作成し、記憶域パラメータを再指定する必要があります。このような影響は、切捨ておよび置換ではありません。そのため、TRUNCATE
文による行の削除、またはCREATE
OR
REPLACE
TABLE
文による表の置換えは、表を削除して再作成するよりも効率的です。
参照:
|
削除する表が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
TABLE
システム権限が必要です。
セッションがバインドされていない場合にのみ、一時表でDDL操作(ALTER
TABLE
、DROP
TABLE
、CREATE
INDEX
など)を実行できます。セッションを一時表にバインドするには、一時表でINSERT
操作を実行します。セッションを一時表からアンバインドするには、TRUNCATE
文を発行するか、セッションを終了します。また、トランザクション固有の一時表からアンバインドするには、COMMIT
またはROLLBACK
文を発行します。
表が含まれているスキーマを指定します。schema
を指定しない場合、表は自分のスキーマ内にあるとみなされます。
削除する表の名前を指定します。Oracle Databaseによって次の操作が自動的に実行されます。
table
がパーティション化されている場合、対応するローカル索引パーティションも同様に削除されます。
table
のネストした表およびLOBのすべての記憶表が削除されます。
PURGE
キーワードでパーティション表を削除する場合、その文は一連のサブトランザクションとして実行され、それぞれのサブトランザクションで、パーティションまたはサブパーティションのサブセットおよびそのメタデータが削除されます。削除操作がこのように複数のサブトランザクションに分割されていることで、特に大きなパーティション表を削除する場合に、内部システム・リソース(ライブラリ・キャッシュなど)の消費処理が最適化されます。最初のサブトランザクションがコミットされるとすぐにUNUSABLE
のマークが表に付けられます。いずれかのサブトランザクションが失敗した場合、その表に対して可能な操作は、もう一度DROP
TABLE
... PURGE
文を実行することのみです。この場合、前回のDROP
TABLE
文が失敗したところから、処理が継続されます。ただし、この処理は、前回の操作で発生したエラーが修正されていることを前提としています。このような削除操作でUNUSABLE
のマークが付けられた表のリストは、該当する*_TABLES
、*_PART_TABLES
、*_ALL_TABLES
または*_OBJECT_TABLES
データ・ディクショナリ・ビューのstatus
列を問い合せて表示できます。
FORCE
句を使用して統計タイプの関連付けが解除され、統計タイプを使用して収集されたユーザー定義のすべての統計情報が削除されます。DROP
CLUSTER
文にINCLUDING
TABLES
句を指定した場合、クラスタおよびそのすべての表を削除できます。これによって、表を1つずつ削除する必要がなくなります。「DROP CLUSTER」を参照してください。
表を再作成する場合、ストアド・プロシージャ、ファンクションまたはパッケージで参照する列、およびマテリアライズド・ビューの定義で使用されていた副問合せで選択されるすべての列が、その表に含まれている必要があります。ビュー、ストアド・プロシージャ、ファンクション、パッケージに対するオブジェクト権限が付与されていたユーザーに、これらの権限を再付与する必要はありません。
表がマテリアライズド・ビューのマスター表の場合、マテリアライズド・ビューの問合せはできます。ただし、そのマテリアライズド・ビューを定義する問合せによって選択されるすべての列を含む表を再作成しないかぎり、リフレッシュはできません。
表がマテリアライズド・ビュー・ログを含む場合、このログおよびその表に関連付けられているダイレクト・パス・インサートのその他のリフレッシュ情報は削除されます。
ALTER
TABLE
... DROP
COLUMN
句を使用して、ネストした表の列を削除する必要があります。
CASCADE
CONSTRAINTS
を指定すると、削除される表の主キーまたは一意キーを参照するすべての参照整合性制約を削除できます。このような参照整合性制約があるときにこの句を省略した場合、エラーが戻され、表は削除されません。
PURGE
を指定すると、1つの手順で、表を削除してその表に関連付けられた領域を解放できます。PURGE
を指定すると、表およびその依存オブジェクトはごみ箱に移動しません。
この句を使用することは、表を削除してからその表をごみ箱から消去することと同じです。この句を使用すると、それらの操作を1つの手順で実行できます。また、機密情報をごみ箱に表示しないようにできるため、セキュリティを強化できます。
次の文は、oe.list_customers
表(「リスト・パーティション化の例:」で作成)を削除します。
DROP TABLE list_customers PURGE;
DROP
TABLESPACE
文を使用すると、データベースから表領域を削除できます。
削除した表領域は、ごみ箱内には移動しません。このため、削除した表領域を消去またはリカバリすることはできません。
DROP
TABLESPACE
システム権限が必要です。アクティブ・トランザクションを保持するロールバック・セグメントを含む場合は、表領域を削除できません。
削除する表領域の名前を指定します。
表領域の状態がオンラインまたはオフラインのどちらであっても、その表領域を削除できます。実行中のトランザクション内のSQL文で、表領域内のいずれかのオブジェクトにアクセスすることがないように、表領域はオフラインにしてから削除することをお薦めします。
SYSTEM
表領域は削除できません。SYSAUX
表領域は、SYSDBA
システム権限を持ち、MIGRATE
モードでデータベースを起動した場合にのみ削除できます。
削除する表領域がデフォルト表領域または一時表領域として割り当てられていたユーザーにアラートを出す必要がある場合があります。表領域が削除された後では、このようなユーザーはオブジェクトに領域を割り当てたり、表領域内で領域をソートすることはできません。ALTER
USER
文を使用すると、ユーザーに新しいデフォルト表領域および一時表領域を割り当てることができます。
以前に表領域から削除し、ごみ箱に移動したオブジェクトがごみ箱から消去されます。表領域に関連するすべてのメタデータ、および表領域に含まれるすべてのデータ・ファイルと一時ファイルが、データ・ディクショナリから削除されます。また、表領域にあるOracle Managed Filesのデータ・ファイルおよび一時ファイルが、オペレーティング・システムから自動的に削除されます。その他のデータ・ファイルおよび一時ファイルは、INCLUDING
CONTENTS
AND
DATAFILES
を指定しないかぎり、オペレーティング・システムから削除されません。
この文を使用して表領域グループを削除することはできません。ただし、tablespace
が表領域グループ内で唯一の表領域である場合、その表領域グループもデータ・ディクショナリから削除されます。
表領域の削除には、次の制限事項があります。
INCLUDING
CONTENTS
およびCASCADE
CONSTRAINTS
句を指定してもその表領域を削除できません。たとえば、削除する表領域に主キー列索引が含まれており、主キー列自体が別の表領域に存在する場合、その別の表領域内の主キー制約を手動で無効にしないかぎり、表領域を削除できません。INCLUDING
CONTENTS
を指定すると、表領域の中のすべてのデータベース・オブジェクトを削除できます。データベース・オブジェクトを格納している表領域を削除する場合は、必ずこの句を指定します。表領域が空でない場合にこの句を省略した場合、エラーが戻され、表領域は削除されません。
1つの表のパーティションまたはサブパーティションが表領域に(すべてではなく)一部含まれていると、INCLUDING
CONTENTS
を指定してもDROP
TABLESPACE
コマンドが正常に実行されません。パーティション表のすべてのパーティションまたはサブパーティションがtablespace
に存在する場合、DROP
TABLESPACE
... INCLUDING
CONTENTS
は、tablespace
を削除し、関連付けられた索引セグメント、LOBデータ・セグメントおよび他の表領域にある表のLOB索引セグメントも削除します。
パーティション化された索引構成表の場合、すべての主キー索引セグメントがこの表領域に存在する場合、この句は、他の表領域にあるオーバーフロー・セグメントも、他の表領域にある関連するマッピング表と同様に削除します。主キー索引セグメントのいくつかが存在しない場合、その文は実行されません。その場合、その表領域を削除する前に、ALTER
TABLE
... MOVE
PARTITION
を使用して、それらの主キー索引セグメントをこの表領域に移動し、この表領域にオーバーフロー・データ・セグメントの存在しないパーティションを削除します。また、パーティション化された索引構成表も削除します。
表領域がマテリアライズド・ビューのマスター表を含む場合、マテリアライズド・ビューは無効になります。
表領域がマテリアライズド・ビュー・ログを含む場合、このログおよびその表に関連付けられているダイレクト・パス・インサートのその他のリフレッシュ情報は削除されます。
INCLUDING
CONTENTS
を指定するときにAND
DATAFILES
句を指定すると、関連するオペレーティング・システム・ファイルも削除できます。Oracle Databaseによって、アラート・ログに、削除された各オペレーティング・システム・ファイルに関するメッセージが書き込まれます。この句は、Oracle Managed Filesについては不要です。Oracle Managed Filesは、AND
DATAFILES
を指定しなくてもシステムから削除されます。
INCLUDING
CONTENTS
を指定するときにKEEP
DATAFILES
句も指定すると、関連するオペレーティング・システム・ファイル(Oracle Managed Filesも含む)を処理せずにそのままにしておくことができます。この句を指定する必要があるのは、Oracle Managed Filesを使用しているときに、関連するオペレーティング・システム・ファイルをINCLUDING
CONTENTS
句で削除しない場合です。
CASCADE
CONSTRAINTS
を指定すると、tablespace
に含まれる表の主キーまたは一意キーを参照する、tablespace
の外の表からすべての参照整合性制約を削除できます。このような参照整合性制約があるときにこの句を省略した場合、エラーが戻され、表領域は削除されません。
次の文は、tbs_01
表領域を削除し、tbs_01
に含まれる主キーおよび一意キーを参照するすべての参照整合性制約を削除します。
DROP TABLESPACE tbs_01 INCLUDING CONTENTS CASCADE CONSTRAINTS;
次の例は、tbs_02
表領域およびそれに関連するすべてのオペレーティング・システムのデータ・ファイルを削除します。
DROP TABLESPACE tbs_02 INCLUDING CONTENTS AND DATAFILES;
トリガーはPL/SQLを使用して定義されます。トリガーの作成、変更および削除の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP
TRIGGER
文を使用すると、データベースからデータベース・トリガーを削除できます。
削除するトリガーが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
TRIGGER
システム権限が必要です。他のユーザーのスキーマ内のデータベースにあるトリガーを削除する場合は、ADMINISTER
DATABASE
TRIGGER
システム権限が必要です。
トリガーが含まれているスキーマを指定します。schema
を指定しない場合、トリガーは自分のスキーマ内にあるとみなされます。
削除するトリガーの名前を指定します。データベースからトリガーが削除され、再度、起動されることはありません。
次の文は、hr
スキーマ内のsalary_check
トリガーを削除します。
DROP TRIGGER hr.salary_check;
オブジェクト型はPL/SQLを使用して定義されます。オブジェクト型の作成、変更および削除の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP
TYPE
文を使用すると、オブジェクト型、VARRAY型またはネストした表型の仕様部および本体を削除できます。
削除するオブジェクト型、VARRAY型またはネストした表型が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
TYPE
システム権限が必要です。
型が含まれているスキーマを指定します。schema
を指定しない場合、型は自分のスキーマ内にあるとみなされます。
削除するオブジェクト型、VARRAY型またはネストした表型の名前を指定します。型依存性または表依存性のない型のみ削除できます。
type_name
がスーパータイプの場合、FORCE
も指定しないと、この文は正常に実行されません。FORCE
を指定すると、そのスーパータイプに依存するすべてのサブタイプが無効になります。
type_name
が統計タイプの場合、FORCE
も指定しないと、この文は正常に実行されません。FORCE
を指定した場合、最初にtype_name
に関連付けられたすべてのオブジェクトの関連付けが解除され、type_name
が削除されます。
type_name
が統計タイプに関連付けられたオブジェクト型の場合、最初にこの統計タイプからtype_name
の関連付けが解除され、type_name
が削除されます。ただし、統計タイプを使用して統計情報が収集された場合、この統計タイプからtype_name
の関連付けを解除することはできません。このため、この文は正常に実行されません。
type_name
が索引タイプの実装タイプの場合、索引タイプにINVALID
のマークが付けられます。
type_name
にパブリック・シノニムが定義されている場合、このシノニムも削除されます。
FORCE
オプションを指定していない場合に削除できるのは、依存性のないスタンドアロンのスキーマ・オブジェクトとして定義されているオブジェクト型またはネストした表型またはVARRAY型のみです。これはデフォルトの動作です。
FORCE
を指定すると、依存するデータベース・オブジェクトを持つ型でも強制的に削除できます。削除する型に依存するすべての列にUNUSED
のマークが付けられ、それらの列にアクセスできなくなります。
型を削除するときにVALIDATE
を指定すると、格納されているこの型のインスタンスがスーパータイプのいずれかの置換可能な列の範囲であることが検証されます。このようなインスタンスがない場合、削除操作が完了します。
この句はサブタイプのみに意味があります。明示的な型または表依存性のないサブタイプを安全に削除するために、このオプションの使用をお薦めします。
次の文は、オブジェクト型person_t
を削除します。このオブジェクト型を作成する例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。person_tに依存するすべての列は、UNUSED
のマークが付けられ、アクセスできなくなります。
DROP TYPE person_t FORCE;
オブジェクト型はPL/SQLを使用して定義されます。オブジェクト型の作成、変更および削除の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP
TYPE
BODY
文を使用すると、オブジェクト型、VARRAY型またはネストした表型の本体を削除できます。型本体を削除しても、オブジェクト型の仕様部は残ります。また、削除した型本体は再作成できます。その本体を再作成する場合、型本体を削除したオブジェクト型は引き続き使用できますが、メンバー・ファンクションはコールできません。
オブジェクト型の本体が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
TYPE
システム権限が必要です。
オブジェクト型が含まれているスキーマを指定します。schema
を指定しない場合、オブジェクト型は自分のスキーマ内にあるとみなされます。
削除するオブジェクト型の本体の名前を指定します。
型依存性および表依存性がない場合にのみ型の本体を削除できます。
次の文は、オブジェクト型本体data_typ1
を削除します。このオブジェクト型を作成する例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP TYPE BODY data_typ1;
DROP
USER
文を使用すると、データベース・ユーザーを削除できます。また、オプションでユーザーのオブジェクトを削除することもできます。
自動ストレージ管理クラスタでは、AS
SYSASM
と認証されたユーザーは、この句を使用して、現行のノードの自動ストレージ管理インスタンスに対してローカルなパスワード・ファイルでユーザーを削除できます。
ユーザーを削除すると、そのユーザーのすべてのスキーマ・オブジェクトもごみ箱から消去されます。
DROP
USER
システム権限が必要です。自動ストレージ管理クラスタでは、AS
SYSASM
と認証される必要があります。
削除するユーザーを指定します。CASCADE
を指定しない場合、またはユーザーのオブジェクトを最初に明示的に削除しない場合、所有するスキーマにオブジェクトが含まれているユーザーは削除されません。
CASCADE
を指定すると、ユーザーを削除する前に、そのユーザーのスキーマ内にあるすべてのオブジェクトを削除できます。所有するスキーマにオブジェクトが含まれているユーザーを削除する場合は、必ずこの句を指定します。
次の文は、ユーザーsidneyのスキーマ内にオブジェクトがない場合に、sidney
を削除します。
DROP USER sidney;
sidneyのスキーマ内にオブジェクトがある場合は、次の文のようにCASCADE
句を指定して、sidney
とそのオブジェクトを削除する必要があります。
DROP USER sidney CASCADE;
DROP
VIEW
文を使用すると、データベースからビューまたはオブジェクト・ビューを削除できます。ビューを削除して再作成すると、ビューの定義を変更できます。
削除するビューが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP
ANY
VIEW
システム権限が必要です。
ビューが含まれているスキーマを指定します。schema
を指定しない場合、ビューは自分のスキーマ内にあるとみなされます。
削除するビューの名前を指定します。
Oracle Databaseでは、ビューに依存するビュー、マテリアライズド・ビューおよびシノニムは削除されませんが、INVALID
のマークが付けられます。このようなビューおよびシノニムは削除または再定義するか、無効なビューやシノニムをもう一度有効にするビューを別に定義します。
指定するビューにサブビューが定義されている場合、サブビューも同様に無効になります。ビューがサブビューを持つかどうかを確認するには、USER_VIEWS
、ALL_VIEWS
またはDBA_VIEWS
データ・ディクショナリ・ビューのSUPERVIEW_NAME
列を問い合せます。
参照:
|
CASCADE
CONSTRAINTS
を指定すると、削除するビューの主キーまたは一意キーを参照するすべての参照整合性制約を削除できます。このような制約が存在する状態でこの句を省略すると、DROP
文は正常に実行されません。
次の文は、emp_view
ビュー(「ビューの作成例:」で作成)を削除します。
DROP VIEW emp_view;
EXPLAIN
PLAN
文を使用すると、指定したSQL文を実行するためにOracle Databaseが使用する実行計画を決定できます。この文によって、実行計画の各手順を記述している行が、指定した表に挿入されます。SQLトレース機能の一部としてEXPLAIN
PLAN
文を発行することもできます。
この文によって、文を実行するコストも決まります。表にドメイン索引が定義されている場合、ユーザー定義のCPUおよびI/Oコストが挿入されます。
配布メディアのSQLスクリプトの中に、サンプル出力表PLAN_TABLE
の定義があります。使用する出力表は、列の名前およびデータ型がこのサンプル表と同じである必要があります。このスクリプトの一般的な名前は、UTLXPLAN.SQL
です。正確な名前および位置は、使用するオペレーティング・システムによって異なります。
Oracle Database キャッシュされたカーソルに関する情報は、次の動的パフォーマンス・ビューから得られます。
V$SQL_WORKAREA
を問い合せます。
V$SQL_PLAN
を問い合せます。
V$SQL_PLAN_STATISTICS
を問い合せます。
V$SQL_PLAN_STATISTICS_ALL
を問い合せます。
V$SQL_PLAN_MONITOR
に表示されます。MONITOR
ヒントを使用すると、監視を強制的に適用できます。EXPLAIN
PLAN
文を実行する場合、実行計画を格納する既存の出力表に行を挿入するための権限が必要です。
出力する実行計画の適用対象であるSQL文を実行するための権限も必要です。このSQL文でビューにアクセスする場合は、このビューの基礎になっているすべての表およびビューへのアクセス権限が必要です。このビューが別のビューに基づき、さらにこの別のビューが、ある表に基づいている場合、別のビューとそのビューの基礎になっている表へのアクセス権限が必要です。
EXPLAIN
PLAN
で作成された実行計画を検証する場合は、出力表へ問い合せる権限が必要です。
EXPLAIN
PLAN
文はデータ操作言語(DML)文であり、データ定義言語(DDL)文ではありません。そのため、EXPLAIN
PLAN
文で加えられた変更内容は暗黙的にコミットされません。出力表のEXPLAIN
PLAN
文で生成された行を保存する場合は、この文を指定したトランザクションをコミットする必要があります。
実行計画が出力される表の中で、この実行計画に該当する行にあるSTATEMENT_ID
列の値を指定します。この値によって、実行計画の行を出力表の中の他の行と区別できます。ユーザーの出力表に多数の実行計画の行が含まれている場合は、必ず、STATEMENT_ID
の値を指定します。この句を省略した場合、デフォルトでSTATEMENT_ID
値がNULLに設定されます。
出力表の名前を指定し、オプションとしてそのスキーマおよびデータベースの名前も指定します。この表は、EXPLAIN
PLAN
文を使用する前に作成しておく必要があります。
schema
を指定しない場合、表は自分のスキーマ内にあるとみなされます。
dblink
には、出力表が格納されているリモートのOracle Databaseに対するデータベース・リンクの完全な名前または名前の一部を指定します。Oracle Databaseの分散機能を使用している場合にのみ、リモート出力表を指定できます。dblink
を省略した場合、表がローカル・データベース上にあるとみなされます。データベース・リンクの参照方法の詳細は、「リモート・データベース内のオブジェクトの参照」を参照してください。
INTO
句を省略した場合、出力表は、ローカル・データベース上の自分のスキーマ内にあるPLAN_TABLE
であるとみなされます。
実行計画生成の対象となるSELECT
、INSERT
、UPDATE
、DELETE
、CREATE
TABLE
、CREATE
INDEX
またはALTER
INDEX
... REBUILD
文を指定します。
EXPLAIN
PLAN
には、次の注意事項があります。
statement
にparallel_clause
を指定した場合、結果として生成される実行計画はパラレルで実行されます。ただし、EXPLAIN
PLAN
コマンドによって計画表に実際に文が挿入されるため、ユーザーが発行したパラレルDML文は、トランザクションの最初のDML文ではなくなります。これは、トランザクション1つにつきパラレルDML文は1つというOracle Databaseの制限に違反するため、この文はシリアルで実行されます。文をパラレルで実行するには、EXPLAIN
PLAN
文をコミットまたはロールバックしてから、パラレルDML文を発行する必要があります。
EXPLAIN
PLAN
は、同一セッションから実行する必要があります。これは、一時表内のデータがセッション固有であるためです。
次の文は、UPDATE
文の実行計画およびコストを決定し、実行計画を記述した行をSTATEMENT_ID
値'Raise in Tokyo'とともに、指定したplan_table
表に挿入します。
EXPLAIN PLAN SET STATEMENT_ID = 'Raise in Tokyo' INTO plan_table FOR UPDATE employees SET salary = salary * 1.10 WHERE department_id = (SELECT department_id FROM departments WHERE location_id = 1200);
次のSELECT
文は、plan_table
表への問合せを実行し、実行計画およびコストを戻します。
SELECT LPAD(' ',2*(LEVEL-1))||operation operation, options, object_name, position FROM plan_table START WITH id = 0 AND statement_id = 'Raise in Tokyo' CONNECT BY PRIOR id = parent_id AND statement_id = 'Raise in Tokyo' ORDER BY operation, options, object_name, position;
問合せによって、次の実行計画が戻されます。
OPERATION OPTIONS OBJECT_NAME POSITION -------------------- --------------- --------------- ---------- UPDATE STATEMENT 2 UPDATE EMPLOYEES 1 TABLE ACCESS FULL EMPLOYEES 1 VIEW index$_join$_00 1 2 HASH JOIN 1 INDEX RANGE SCAN DEPT_LOCATION_I 1 X INDEX FAST FULL SCAN DEPT_ID_PK 2
POSITION
列の1行目の値は、文のコストが2であることを示しています。
サンプル表sh.sales
は、time_id
列でパーティション化されています。パーティションsales_q3_2000
には、2000年10月1日より小さい時刻の値があり、time_id
列にローカル索引sales_time_bix
があります。
次の問合せを考えてみます。
EXPLAIN PLAN FOR SELECT * FROM sales WHERE time_id BETWEEN :h AND '01-OCT-2000';
ここで、:h
はすでに宣言されているバインド変数を指します。EXPLAIN
PLAN
文は、PLAN_TABLE
を出力表とする次の問合せを実行します。次の問合せによって、パーティション情報などの基本的な実行計画が得られます。
SELECT operation, options, partition_start, partition_stop, partition_id FROM plan_table;
FLASHBACK
DATABASE
文を使用すると、データベースを過去の時点またはシステム変更番号(SCN)まで戻すことができます。この文を使用すると、データベースの不完全リカバリと同じ操作をより高速に実行できます。
FLASHBACK
DATABASE
操作の後、フラッシュバックされたデータベースに書込みアクセスするためには、ALTER
DATABASE
OPEN
RESETLOGS
文によってそのデータベースを再オープンする必要があります。
SYSDBA
システム権限が必要です。フラッシュ・リカバリ領域をデータベースに設定しておく必要があります。また、データベースを保証付きリストア・ポイントにフラッシュバックするのでなければ、ALTER
DATABASE
FLASHBACK
ON
文を使用して、データベースをFLASHBACK
モードにしておく必要があります。データベースは、マウントされているがオープンされていない状態であることが必要です。また、次のことも必要です。
ARCHIVELOG
モードで実行されている必要があります。
ALTER
TABLESPACE
... FLASHBACK
OFF
を使用して、フラッシュバック機能が使用禁止にされたオンライン表領域は含めないでください。
参照:
FLASHBACK
モードにする方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』および「ALTER
DATABASE
」の「flashback_mode_clause」を参照してください。
FLASHBACK
DATABASE
文を発行すると、最初に、必要なすべてのアーカイブREDOログおよびオンラインREDOログが使用可能であるかどうかが確認されます。これらのログが使用可能な場合、データベース内で現在オンラインになっているすべてのデータ・ファイルが、この文に指定したSCNまたは時刻まで戻されます。
DB_FLASHBACK_RETENTION_TARGET
初期化パラメータおよびフラッシュ・リカバリ領域のサイズによって制御されます。V$FLASHBACK_DATABASE_LOG
ビューを問い合せることによって、どの時点までデータベースをフラッシュバックできるかを判断できます。
STANDBY
を指定すると、スタンバイ・データベースを以前のSCNまたは時点まで戻すことができます。スタンバイ・データベースではない場合、エラーが戻されます。この句を省略すると、database
には、プライマリ・データベースまたはスタンバイ・データベースのどちらでも指定できます。
システム変更番号(SCN)を指定します。
現行のSCNを判断するには、V$DATABASE
ビューのCURRENT_SCN
列を問い合せます。これによって、高リスクのバッチ・ジョブを実行する前などに、SCNをスプール・ファイルに保存することもできます。
有効な日時式を指定します。
TO TIMESTAMP
では、指定したタイムスタンプ時点の状態にデータベースが戻されます。
TO BEFORE TIMESTAMP
では、指定したタイムスタンプの1秒前の状態にデータベースが戻されます。
タイムスタンプには、基準の値(SYSDATE
など)からのオフセットか、またはシステム・タイムスタンプの絶対値を指定できます。
この句を使用すると、指定したリストア・ポイントにデータベースをフラッシュバックできます。フラッシュバック・データベースが使用可能になっていない場合、このFLASHBACK
DATABASE
文では、この句のみを指定できます。データベースのモードがFLASHBACK
でない場合、前述の「前提条件」で示したように、これは、この文で指定可能な唯一の句です。
TO
BEFORE
RESETLOGS
を指定すると、データベースを最後のリセットログ操作(ALTER
DATABASE
OPEN
RESETLOGS
)の直前の状態にフラッシュバックできます。
データベースにフラッシュ・リカバリ領域が設定してあり、メディア・リカバリが使用可能になっていると想定します。次の文は、データベースのFLASHBACK
モードを有効にして、データベースをオープンします。
STARTUP MOUNT ALTER DATABASE FLASHBACK ON; ALTER DATABASE OPEN;
次の文は、データベースを1日以上オープンしていた場合、データベースを1日フラッシュバックします。
SHUTDOWN DATABASE STARTUP MOUNT FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1;
FLASHBACK
TABLE
文を使用すると、人為的エラーまたはアプリケーション・エラーが発生した場合に、表を以前の状態にリストアできます。表をフラッシュバックできる過去の時点は、システム内のUNDOデータの量によって異なります。また、Oracle Databaseでは、表の構造を変更するDDL操作が行われた場合は、表を以前の状態にリストアできません。
FLASHBACK
TABLE
文はロールバックできません。ただし、もう1つFLASHBACK
TABLE
文を発行し、現在の時間の直前の時間を指定することはできます。このため、FLASHBACK
TABLE
句を発行する前に、現在のSCNを記録しておくことをお薦めします。
参照:
|
表を以前のSCNまたはタイムスタンプまでフラッシュバックするには、その表に対するFLASHBACK
オブジェクト権限か、FLASHBACK
ANY
TABLE
システム権限が必要です。また、その表に対するSELECT
、INSERT
、DELETE
およびALTER
オブジェクト権限が必要です。
TO
BEFORE
DROP
を使用せずに表をフラッシュバックする場合、フラッシュバック・リスト内のすべての表で、行の移動を有効にする必要があります。この操作はフラッシュバック削除といい、UNDOデータではなく、ごみ箱に削除されたデータを使用します。行の移動の有効化の詳細は、「row_movement_clause」を参照してください。
表をリストア・ポイントにフラッシュバックするには、SELECT
ANY
DICTIONARY
またはFLASHBACK
ANY
TABLE
のいずれかのシステム権限か、SELECT_CATALOG_ROLE
ロールが必要です。
DROP
TABLE
操作の前まで表をフラッシュバックするために必要な権限は、その表の削除に必要な権限のみです。
Oracle Flashback Tableの操作中は、フラッシュバック・リストに指定されたすべての表が、排他DMLロックによってロックされます。これらのロックによって、表を以前の状態に戻す操作の間に、それらの表に他の操作が行われなくなります。
表のフラッシュバック操作は、フラッシュバック・リストに指定された表の数に関係なく、1回のトランザクションで実行されます。すべての表が以前の状態に戻されるか、何も戻されないかのいずれかです。いずれかの表のフラッシュバック操作が正常に実行されなかった場合、この文全体が正常に実行されません。
表のフラッシュバック操作が完了すると、表内のデータは、指定した過去の状態のものになっています。ただし、FLASHBACK TABLE TO SCN
またはFLASHBACK TABLE TO TIMESTAMP
では行IDが保持されず、FLASHBACK TABLE TO BEFORE DROP
では参照制約がリカバリされません。
表に関連付けられた統計情報は、以前の形式には戻されません。表の現行の索引は戻され、フラッシュバック時点での表の状態が反映されます。現行の索引がフラッシュバック時点で存在していなかった場合、その索引は、フラッシュバック時点の表の状態を反映するように更新されます。ただし、フラッシュバック時点から現時点の間に削除された索引は、リストアされません。
表が含まれているスキーマを指定します。schema
を指定しない場合、表は自分のスキーマ内にあるとみなされます。
以前の状態に戻すデータを含む1つ以上の表の名前を指定します。
この文には、次の制限事項があります。
TO
SCN
またはTO
TIMESTAMP
句を使用して表をその操作以前の時点にフラッシュバックすることはできません。
表を戻す時点に対応するシステム変更番号(SCN)を指定します。expr
は、有効なSCNに評価される数値である必要があります。
表を戻す時点に対応するタイムスタンプ値を指定します。expr
は、過去の有効なタイムスタンプに評価される必要があります。表は、指定したタイムスタンプの約3秒以内の時点にフラッシュバックされます。
表をフラッシュバックするリストア・ポイントを指定します。リストア・ポイントは作成済である必要があります。
デフォルトでは、表のフラッシュバック操作中は、table
に定義したすべての有効なトリガーが無効にされ、表のフラッシュバック操作の完了後に再度有効にされます。このデフォルト動作を上書きして、フラッシュバック処理中もトリガーを有効にする必要がある場合、ENABLE
TRIGGERS
を指定します。
この句は、table
に定義され、すでに有効にされているデータベース・トリガーのみに影響します。現在無効になっているトリガーを選択して有効にするには、ALTER
TABLE
... enable_disable_clause
を使用してから、FLASHBACK
TABLE
文にENABLE
TRIGGERS
句を指定して発行します。
この句を使用すると、削除された表およびすべての依存するオブジェクトをごみ箱から取り出すことができます。表は、SYSTEM
表領域以外のローカル管理表領域内に置いておく必要があります。
参照:
|
ユーザーが指定した元の表名か、オブジェクトの削除時にそのオブジェクトに割り当てられたシステム生成名を指定できます。
ごみ箱の内容を参照するには、USER_RECYCLEBIN
データ・ディクショナリ・ビューを問い合せます。かわりにRECYCLEBIN
シノニムを使用することもできます。次の2つの文は、同じ行を戻します。
SELECT * FROM RECYCLEBIN; SELECT * FROM USER_RECYCLEBIN;
Oracle Databaseは、元の表名を保持します。元の表が削除された後、同じスキーマ内に削除された表と同じ名前を持つ新しい表が作成されていた場合、RENAME
TO
句も指定しないかぎりエラーが戻されます。
この句を使用すると、ごみ箱から取り出される表に新しい名前を指定できます。
削除された表のフラッシュバックには、次の注意事項があります。
DROP
TABLE
操作中にごみ箱に移動しないため、取り出すことができません。)
取り出された索引、トリガーおよび制約には、ごみ箱での名前が付けられています。そのため、FLASHBACK
TABLE
... TO
BEFORE
DROP
文を発行する前に、USER_RECYCLEBIN
ビューを問い合せて、取り出されたトリガーおよび制約の名前を使用しやすい名前に変更することをお薦めします。
次の例では、新しい表employees_test
を行の移動を有効にして作成し、新しい表内の値を更新し、FLASHBACK
TABLE
文を発行します。
hr
サンプル・スキーマのemployees
表から、employees_test
表を、行の移動を有効にして作成します。
CREATE TABLE employees_test AS SELECT * FROM employees;
指標として、2500未満の給与をリストします。
SELECT salary FROM employees_test WHERE salary < 2500; SALARY ---------- 2400 2200 2100 2400 2200
表の行の移動を可能にします。
ALTER TABLE employees_test ENABLE ROW MOVEMENT;
給与が2500未満の従業員の給与を10%上げます。
UPDATE employees_test SET salary = salary * 1.1 WHERE salary < 2500; 5 rows updated. COMMIT;
2つ目の指標として、10%の昇給後にも2500未満である給与をリストします。
SELECT salary FROM employees_test WHERE salary < 2500; SALARY ---------- 2420 2310 2420
employees_test
表を、現在のシステム時間より前の状態にリストアします。この例では、一連の例を迅速にテストできるように、1分間(実際にはこのような短い期間は設定しない)を使用しています。通常の環境では、より長い期間が経過します。
FLASHBACK TABLE employees_test TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' minute);
2500未満の給与をリストします。前述のFLASHBACK
TABLE
文を発行したため、このリストは1つ目の指標リストと一致しています。
SELECT salary FROM employees_test WHERE salary < 2500; SALARY ---------- 2400 2200 2100 2400 2200
次の文は、誤って削除したpm.print_media
表を取り出します。
FLASHBACK TABLE print_media TO BEFORE DROP;
pm
スキーマ内に別のprint_media
表が作成されていた場合、RENAME
TO
句を使用して、取り出された表の名前を変更します。
FLASHBACK TABLE print_media TO BEFORE DROP RENAME TO print_media_old;
複数回削除された従業員表を最も古い状態で取り出す必要がある場合、USER_RECYLEBIN
表を問い合せてシステム生成名を判断し、その名前をFLASHBACK
TABLE
文で使用します。(ご使用のデータベースでのシステム生成名は、ここに示すものとは異なります。)
SELECT object_name, droptime FROM user_recyclebin WHERE original_name = 'PRINT_MEDIA'; OBJECT_NAME DROPTIME ------------------------------ ------------------- RB$$45703$TABLE$0 2003-06-03:15:26:39 RB$$45704$TABLE$0 2003-06-12:12:27:27 RB$$45705$TABLE$0 2003-07-08:09:28:01
GRANT
文を使用すると、次の権限またはロールを付与できます。
PUBLIC
に対する、特定のオブジェクトに対するオブジェクト権限。表18-2に、オブジェクト権限とその権限によって許可される操作を示します。
データベース・ユーザーを認可する方法は、データベースやGRANT
文を介して行う以外にもあります。
OS_ROLES
でロールを付与できます。オペレーティング・システム機能を使用してユーザーにロールを付与する場合、GRANT
文を使用してユーザーにシステム権限を付与したり、その他のロールにシステム権限およびロールを付与することはできますが、そのユーザーにロールを付与することはできません。
AS
SYSASM
と認証されたユーザーは、この文を使用すると、システム権限SYSASM
、SYSOPER
およびSYSDBA
を現行ノードの自動ストレージ管理パスワード・ファイルのユーザーに付与できます。
参照:
|
システム権限を付与にするには、次のいずれかの条件が満たされている必要があります。
GRANT
ANY
PRIVILEGE
システム権限が付与されている必要があります。この場合、ロールがユーザーのセッションで有効になっていないかぎり、システム権限をロールに付与しても、ロールが付与されているユーザーに権限は付与されません。
ADMIN
OPTION
付きのシステム権限が付与されている必要があります。この場合、ロールがユーザーのセッションで有効になっているかどうかに関係なく、システム権限をロールに付与すると、ロールが付与されているユーザーに権限が付与されます。
ロールを付与する場合は、Admin
Option
付きのロールが付与されているか、GRANT
ANY
ROLE
システム権限が付与されているか、または付与するロールが自分で作成したロールである必要があります。
オブジェクト権限を付与する場合は、オブジェクトの所有者であるか、オブジェクトの所有者からGrant
Option
付きのオブジェクト権限が付与されている必要があります。または、GRANT
ANY
OBJECT
PRIVILEGE
システム権限が付与されている必要があります。GRANT
ANY
OBJECT
PRIVILEGE
システム権限を持っている場合は、オブジェクトの所有者が付与可能なオブジェクト権限と同じオブジェクト権限のみを付与できます。その場合、DBA_TAB_PRIVS
ビューのGRANTOR
列には、GRANT
文を発行したユーザーではなく、オブジェクトの所有者が表示されます。
(grant_system_privileges::=、grant_object_privileges::=を参照)
(grantee_clause::=を参照)
(on_object_clause::=、grantee_clause::=を参照)
システム権限を付与するには、次の句を使用します。
付与するシステム権限を指定します。表18-1に、システム権限のリストを、操作対象のデータベース・オブジェクト別に示します。
PUBLIC
に権限を付与する場合、各ユーザーの権限ドメインに権限が登録されます。すべてのユーザーは、その権限によって許可される操作をすぐに実行できます。
Oracle Databaseには、ALL
PRIVILEGES
というショートカットも用意されており、このショートカットを使用すると、SELECT
ANY
DICTIONARY
権限を除き、表18-1に示すすべてのシステム権限を付与できます。
付与するロールを指定します。Oracle Databaseの事前定義ロールまたはユーザー定義ロールを付与できます。
ユーザーにロールを付与する場合、ロールはユーザーのデフォルトのロールとして付与されるため、ログインするとすぐに使用可能になります。保護アプリケーション・ロールのセキュリティを確保するには、ロールをデフォルトのロールにしないようにする必要があります。ユーザーにアプリケーション・ロールを付与した直後に、
また、ユーザーに保護アプリケーション・ロールを直接付与する必要はありません。ユーザーが適切なセキュリティ・ポリシーを渡すことを前提として、関連付けられたPL/SQLパッケージでこの処理を行うことができます。詳細は、「USING package」の「
注意:
DEFAULT
ROLE
ALL
EXCEPT
role
句を指定したALTER
USER
文を発行し、アプリケーション・ロールを指定します。これによって、このユーザーによる以降のログイン時に、認可済パッケージを使用するアプリケーションのみがこのロールを使用可能にできるというルールが適用されます。
CREATE
ROLE
セマンティクス」および『Oracle Databaseセキュリティ・ガイド』を参照してください。
PUBLIC
にロールを付与する場合、すべてのユーザーがロールを使用できます。すべてのユーザーはそのロールをすぐに使用可能にし、ロールの権限ドメインに登録されている権限を使用できます。
ユーザーに付与する各ロールはALTER
USER
... DEFAULT
ROLE
文を発行するまでは、デフォルトのロールになります。この文によって、デフォルトのロールが指定されます。これ以外のすべてのロール(これまでに付与されたもの、今後付与するもの)は、もう一度ALTER
USER
... DEFAULT
ROLE
文を使用してデフォルトに指定しないかぎり、デフォルトのロールにはなりません。
参照:
|
この句は、オブジェクト権限ではなくシステム権限を割り当てる場合にのみ有効です。IDENTIFIED
BY
句を使用すると、パスワードによって既存ユーザーが明確に識別できるか、または存在しないユーザーを作成できます。この句は、権限受領者がロールまたはPUBLIC
の場合は無効です。grantee_clause
に指定したユーザーが存在しない場合、この句で指定したパスワードおよび権限とロール付きでユーザーが作成されます。
With
Admin
Option
を指定すると、権限受領者は次のことができます。
GLOBAL
ロールでない場合、権限またはロールを他のユーザーまたはロールに付与できます。
たとえば、With
Admin
Option
を指定せずにユーザーにロールまたはシステム権限を付与し、後でWith
Admin
Option
を指定してその権限およびロールを付与した場合、そのユーザーはその権限またはロールに関してAdmin
Option
を持つことになります。
システム権限またはロールのAdmin
Option
をユーザーから取り消す場合、そのユーザーの権限またはロールを完全に取り消し、その次にAdmin
Option
を指定せずに権限またはロールをユーザーに付与します。
TO
grantee_clause
を使用すると、システム権限、ロールまたはオブジェクト権限が付与されているユーザーまたはロールを識別できます。
TO grantee_clause
にユーザー、ロールおよびPUBLIC
を指定できるのは1回のみです。
PUBLIC
を指定すると、すべてのユーザーに権限を付与できます。
権限およびロールには、次の制限事項があります。
IDENTIFIED
GLOBALLY
は、どのようなユーザーまたはロールに対しても付与できません。
IDENTIFIED
EXTERNALLY
は、グローバル・ユーザーまたはグローバル・ロールに対して付与できません。
banker
をロールteller
に付与した場合、逆にteller
をbanker
に付与することはできません。
オブジェクト権限を付与するには、次の句を使用します。
付与するオブジェクト権限を指定します。表18-2に示すいずれかの値を指定します。
付与する権限のリストに権限を指定できるのは1回のみです。
ALL
を指定すると、Grant
Option
付きで付与されているオブジェクト権限に対するすべての権限を付与できます。オブジェクトが定義されているスキーマを所有しているユーザーは、自動的にGrant
Option
付きのオブジェクトに対するすべての権限を持っています。キーワードPRIVILEGES
はセマンティクスを明確にするためのものであり、指定は任意です。
権限を付与する表またはビューの列を指定します。INSERT
、REFERENCES
またはUPDATE
の各権限を付与する場合にのみ、列を指定できます。列を指定しない場合、権限受領者には表またはビューのすべての列に対して指定した権限が付与されます。
既存の列オブジェクトに対して付与された権限については、データ・ディクショナリ・ビューUSER_COL_PRIVS
、ALL_COL_PRIVS
またはDBA_COL_PRIVS
を問い合せます。
on_object_clause
を指定すると、権限が付与されているオブジェクトを識別できます。ディレクトリ・スキーマ・オブジェクト、Javaソースおよびリソース・スキーマ・オブジェクトは、異なるネームスペースに格納されるため、別々に識別されます。
object
の所有者でもなく、object
WITH
GRANT
OPTION
でobject_privilege
が付与されてもいないが、GRANT
ANY
OBJECT
PRIVILEGE
システム権限が付与されているためこの権限付与を行える場合、この権限付与を行うと、オブジェクト所有者の役割を果たすことになります。*_TAB_PRIVS
データ・ディクショナリ・ビューには、この権限付与がobject
の所有者によって行われたことが反映されます。
参照:
|
With
Grant
Option
を指定すると、権限受領者による、他のユーザーまたはロールに対するオブジェクト権限の付与を許可できます。
With
Grant
Option
は、ユーザーまたはPUBLIC
に権限を付与する場合にのみ指定できます。ロールに付与する場合は指定できません。
With
Hierarchy
Option
を指定すると、この文の後に作成されるサブオブジェクトも含め、object
のすべてのサブオブジェクト(ビューを基に作成したサブビューなど)に対する指定したオブジェクト権限を付与できます。
この句は、SELECT
オブジェクト権限とあわせて指定する場合のみ意味があります。
権限を付与するスキーマ・オブジェクトを指定します。object
をschema
で修飾しなかった場合、そのオブジェクトは自分のスキーマ内にあるとみなされます。オブジェクトには次のタイプがあります。
パーティション表の単一パーティションに直接権限を付与することはできません。
権限を付与するディレクトリ・スキーマ・オブジェクトを指定します。directory_name
はスキーマ名で修飾できません。
JAVA
句を使用すると、権限を付与するJavaソースまたはリソース・スキーマ・オブジェクトを指定できます。
オブジェクト権限 | 許可される操作 |
---|---|
ディレクトリ権限 |
次のディレクトリ権限では、ディレクトリ・オブジェクトをポインタとして使用することにより、オペレーティング・システムのディレクトリに格納されている各ファイルにデータベースから安全にアクセスできるようになります。このディレクトリ・オブジェクトには、ファイルが格納されているオペレーティング・システムのディレクトリへのフルパス名が定義されています。これらのファイルは実際にはデータベース外に格納されているため、Oracle Databaseサーバーの各プロセスは、ファイル・システム・サーバーに対して適切なファイル・アクセス権も持っている必要があります。オペレーティング・システムに対するオブジェクト権限ではなく、ディレクトリ・データベース・オブジェクトに対するオブジェクト権限を個々のデータベース・ユーザーに付与することによって、データベースでファイル運用時のセキュリティが確保されます。 |
|
ディレクトリ内のファイルの読取り。 |
|
ディレクトリ内へのファイルの書込み。外部表に接続する場合のみに役立ちます。これによって、権限受領者は、外部表のエージェントがディレクトリに書き込めるのがログ・ファイルなのか不良ファイルなのかを判断できます。
制限事項: この権限を持っていても、 |
索引タイプ権限 |
次の索引タイプ権限は、索引タイプの操作を許可します。 |
|
索引タイプの参照。 |
フラッシュバック・データ・アーカイブ権限 |
次のフラッシュバック・データ・アーカイブ権限では、フラッシュバック・データ・アーカイブに対する操作を許可します。 |
|
表の履歴追跡を使用可能または使用禁止にします。 |
ライブラリ権限 |
次のライブラリ権限は、ライブラリの操作を許可します。 |
|
特定のオブジェクトの使用と参照、およびそのメソッドの起動。 |
マテリアライズド・ビュー権限 |
次のマテリアライズド・ビュー権限は、マテリアライズド・ビューについての操作を許可します。 |
|
指定した表に対するREFRESH ON COMMITモードのマテリアライズド・ビューの作成。 |
|
指定した表で使用するクエリー・リライトに対するマテリアライズド・ビューの作成。 |
|
|
マイニング・モデル権限 |
次のマイニング・モデル権限では、マイニング・モデルに対する操作を許可します。これらの権限は、ユーザー自身のスキーマ内にあるモデルに対しては必要ありません。 |
|
該当する |
|
マイニング・モデルのスコアリングまたは表示。スコアリングの実行には、SQLファンクションの |
オブジェクト型権限 |
次のオブジェクト型権限は、データベース・オブジェクト型の操作を許可します。 |
|
オブジェクト型に定義されたすべてのパブリック変数、非パブリック変数、メソッドおよび型へのデバッガを介したアクセス。 型本体内の行または指示境界へのブレークポイントの設定、またはこれらの場所のいずれかでの停止。 |
|
オブジェクト型に定義されたパブリック変数、型およびメソッドへのデバッガを介したアクセス。 |
|
型のサブタイプの作成。この型の直属のスーパータイプに |
OLAP権限 |
Oracle DatabaseをOLAPオプションで使用している場合は、次のオブジェクト権限が有効になります。 |
|
メンバーをOLAPキューブ・ディメンションに挿入するか、またはメジャーをメジャー・フォルダに挿入します。 |
|
OLAPキューブ・ディメンションまたはキューブの定義を変更します。 |
|
メンバーをOLAPキューブ・ディメンションから削除するか、またはメジャーをメジャー・フォルダから削除します。 |
|
OLAPキューブまたはキューブ・ディメンションを表示または問い合せます。 |
|
OLAPキューブのメジャー値またはキューブ・ディメンションの属性値を更新します。 |
演算子権限 |
次の演算子権限は、ユーザー定義演算子の操作を許可します。 |
|
演算子の参照。 |
プロシージャ、ファンクション、パッケージ権限 |
次のプロシージャ、ファンクションおよびパッケージ権限は、プロシージャ、ファンクションおよびパッケージの操作を許可します。これらの権限は、Javaソース、クラスおよびリソースにも適用されます。Oracle Databaseでは、これらはオブジェクト権限の付与のために生成されたプロシージャとして扱われます。 |
|
オブジェクトに定義されたすべてのパブリック変数、非パブリック変数、メソッドおよび型へのデバッガを介したアクセス。 プロシージャ、ファンクションまたはパッケージ内の行または指示境界へのブレークポイントの設定、またはこれらの場所のいずれかでの停止。この権限は、メソッドまたはパッケージの仕様部および本体の宣言にアクセスする権限を付与します。 |
|
プロシージャかファンクションの直接実行、パッケージの仕様部に宣言された任意のプログラム・オブジェクトへのアクセス、または現在無効であるかコンパイルされていないファンクションかプロシージャへのコール中の暗黙的なオブジェクトのコンパイル。この権限を持っていても、 プロシージャ、ファンクションまたはパッケージに定義されたパブリック変数、型およびメソッドへのデバッガを介したアクセス。この権限は、メソッドまたはパッケージの仕様部のみの宣言にアクセスする権限を付与します。
ジョブ・スケジューラ・オブジェクトは、 注意: プロシージャ、ファンクションまたはパッケージを間接的に実行する場合、ユーザーはこの権限を持つ必要はありません。 |
SCHEDULER PRIVILEGES |
ジョブ・スケジューラ・オブジェクトは、 |
|
ジョブ・クラス、プログラム、チェーンおよび資格証明に対する操作。 |
|
ジョブ、プログラム、チェーン、資格証明およびスケジュールに対する変更。 |
順序権限 |
次の順序権限は、順序の操作を許可します。 |
|
|
|
|
シノニム権限 |
シノニム権限は、対象となるオブジェクトに対して付与される権限と同じです。シノニムに権限を付与することは、基本オブジェクトに権限を付与することと同じです。同様に、基本オブジェクトに対して権限を付与することは、オブジェクトのすべてのシノニムに権限を付与することと同じです。あるユーザーにシノニムの権限を付与した場合、そのユーザーは、シノニム名または基本オブジェクト名をSQL文に指定して、その権限を使用できます。 |
表権限 |
次の表権限は、表の操作を許可します。次のいずれかのオブジェクト権限を持っている場合は、
注意: 外部表に有効な権限は、 |
|
|
|
注意: 表がリモート・データベースにある場合は、 |
|
デバッガを介した次のものへのアクセス。 |
|
|
|
|
|
表参照制約の作成。この権限はロールには付与できません。 |
|
|
|
注意: 表がリモート・データベースにある場合は、 |
ビュー権限 |
次のビュー権限は、ビューの操作を許可します。次のいずれかのオブジェクト権限を持っている場合は、
ビューの権限を付与する場合、そのビューのすべての実表に関して |
|
デバッガを介した次のものへのアクセス。 |
|
|
|
|
|
このオブジェクト権限の動作は、権限が |
|
ビューへの外部キー制約の定義。 |
|
参照: ビューに対するこのオブジェクト権限の付与の詳細は、「object_privilege」を参照してください。 |
|
ビューのサブビューの作成。このビューの直属のスーパービューに |
|
|
次の文は、サンプル・ユーザーhr
にCREATE
SESSION
システム権限を付与し、hr
がOracle Databaseにログインできるようにします。
GRANT CREATE SESSION TO hr;
次の文は、データ・ウェアハウス管理者ロール(「ロールの作成例:」で作成)に、適切なシステム権限を付与します。
GRANT CREATE ANY MATERIALIZED VIEW , ALTER ANY MATERIALIZED VIEW , DROP ANY MATERIALIZED VIEW , QUERY REWRITE , GLOBAL QUERY REWRITE TO dw_manager WITH ADMIN OPTION;
dw_manager
の権限ドメインには、マテリアライズド・ビューに関連するシステム権限が含まれます。
次の文は、サンプル・ユーザーsh
にAdmin
Option
付きのdw_manager
ロールを付与します。
GRANT dw_manager TO sh WITH ADMIN OPTION;
dw_manager
ロールによって、sh
は次の操作を実行できます。
CREATE
MATERIALIZED
VIEW
システム権限を含むそのロールの権限ドメインに登録されている権限の使用
次の文は、データ・ウェアハウス・ユーザー・ロール(「ロールの作成例:」で作成)に、SELECT
オブジェクト権限を付与します。
GRANT SELECT ON sh.sales TO warehouse_user;
次の文は、dw_manager
ロールに、warehouse_user
ロールを付与します (いずれのロールも、「ロールの作成例:」で作成)。
GRANT warehouse_user TO dw_manager;
dw_manager
ロールには、warehouse_user
ロールのドメインにあるすべての権限が含まれます。
次の文は、ユーザーhr
にディレクトリbfile_dir
に対するREAD
権限をGrant
Option
付きで付与します。
GRANT READ ON DIRECTORY bfile_dir TO hr WITH GRANT OPTION;
次の文は、ユーザーhr
に対して、oe.bonuses
表(「表へのマージ例:」で作成)についてのすべての権限をGrant
Option
付きで付与します。
GRANT ALL ON bonuses TO hr WITH GRANT OPTION;
この結果、hr
ユーザーは次の操作を実行できます。
次の文は、ビューemp_view
(「ビューの作成例:」で作成)についてのSELECT
権限およびUPDATE
権限をすべてのユーザーに付与します。
GRANT SELECT, UPDATE ON emp_view TO PUBLIC;
この結果、すべてのユーザーが、従業員の詳細についてのビューを問合せおよび更新できるようになります。
次の文は、ユーザーhr
に対して、スキーマoe
内のcustomers_seq
順序のSELECT
権限を付与します。
GRANT SELECT ON oe.customers_seq TO hr;
ユーザーhr
は、次の文を指定して、順序の次の値を作成できるようになります。
SELECT oe.customers_seq.NEXTVAL FROM DUAL;
次の文は、ユーザーoe
に、スキーマhr
にあるemployees
表のemployee_id
列に対するREFERENCES
権限、およびemployee_id
、salary
、commission_pct
列に対するUPDATE
権限を付与します。
GRANT REFERENCES (employee_id), UPDATE (employee_id, salary, commission_pct) ON hr.employees TO oe;
この結果、ユーザーoe
は、employee_id
列、salary
列およびcommission_pct
列の値を更新できるようになります。ユーザーoe
は、employee_id
列を参照する参照整合性制約を定義することもできます。ただし、GRANT
文にはこれらの列のみが指定されているため、ユーザーoe
はemployees
表の他の列を操作できません。
たとえば、oe
は制約付きの表を作成できます。
CREATE TABLE dependent (dependno NUMBER, dependname VARCHAR2(10), employee NUMBER CONSTRAINT in_emp REFERENCES hr.employees(employee_id) );
スキーマhr
内のemployees
表の従業員に対応するdependent
表の依存性が、制約in_emp
によって保証されます。
INSERT
文を使用すると、表、ビューの実表、パーティション表のパーティション、コンポジット・パーティション表のサブパーティション、オブジェクト表またはオブジェクト・ビューの実表に、行を追加できます。
表に行を挿入する場合は、その表が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、その表に対するINSERT
権限が必要です。
ビューの実表に行を挿入する場合、ビューが定義されているスキーマの所有者には、その実表に対するINSERT
権限が必要です。また、他のユーザーのスキーマ内のビューに行を挿入する場合は、そのビューに対するINSERT
権限が必要です。
INSERT
ANY
TABLE
システム権限があれば、任意の表または任意のビューの実表に行を挿入できます。
表、パーティションまたはビューにデータを挿入するために使用するINSERT
文には、従来型INSERT
およびダイレクト・パス・インサートの2種類があります。従来型INSERT
文を発行すると、表の空き領域を再利用して挿入され、参照整合性制約が維持されます。ダイレクト・パス・インサートの場合、表の既存データの後に、挿入したデータが追加されます。データは、バッファ・キャッシュを回避してデータ・ファイルに直接書き込まれます。既存データの空き領域は再利用されません。これによって挿入操作中のパフォーマンスが向上します。また、これはOracleのダイレクト・パスのローダー・ユーティリティ、SQL*Loaderの機能に似ています。パラレル・モードで作成された表に挿入する場合は、ダイレクト・パス・インサートがデフォルトです。
データベースでのREDOデータおよびUNDOデータの生成方法は、従来型INSERT
とダイレクト・パス・インサートのいずれを使用しているかに一部関係しています。
INSERT
では、表とアーカイブ・ログのロギング設定に関係なく、データとメタデータの両方に対する変更に対して常に最大のREDOおよびUNDOが生成され、データベースのロギング設定が強制的に使用されます。
ARCHIVELOG
またはFORCE
LOGGING
モードでない場合は、表のロギング設定に関係なく、データの変更に対するREDOは生成されません。
ARCHIVELOG
モード(ただしFORCE
LOGGING
モードではない)の場合、ダイレクト・パス・インサートでは、LOGGING
表のデータのREDOは生成されますが、NOLOGGING
表のデータのREDOは生成されません。
ARCHIVELOG
モードかつFORCE
LOGGING
モードの場合、ダイレクト・パスSQLでは、LOGGING
表とNOLOGGING
表の両方のデータのREDOが生成されます。
ダイレクト・パス・インサートには、次の制限があります。これらの制限に違反する場合、他にエラーがないかぎりメッセージが戻されず、従来型INSERT
がシリアルで実行されます。
APPEND
ヒントを指定した場合でも、シリアルで実行されます。ただし、パーティション化されたIOTへのダイレクト・パス・インサート操作は、拡張パーティション名が使用されず、IOTに複数のパーティションが含まれているかぎり、パラレル・モードで実行されません。
(single_table_insert::=、multi_table_insert::=を参照)
(insert_into_clause::=、values_clause::=、returning_clause::=、subquery::=、error_logging_clause::=を参照)
(DML_table_expression_clause::=を参照)
(insert_into_clause::=、values_clause::=、conditional_insert_clause::=、subquery::=、error_logging_clause::=を参照)
(insert_into_clause::=、values_clause::=を参照)
(partition_extension_clause::=、SELECT
構文の項にあるsubquery::=、subquery_restriction_clause::=、table_collection_expression::=を参照)
文の実行計画を選択する場合に、オプティマイザに指示を与えるためのコメントを指定します。
マルチテーブル・インサートの場合、対象となる表に対してPARALLEL
ヒントを指定すると、表がPARALLEL
の指定付きで作成または変更されていなくても、マルチテーブル・インサート文全体がパラレル化されます。PARALLEL
ヒントを指定しない場合、対象となるすべての表がPARALLEL
の指定付きで作成または変更されていないかぎり、挿入操作はパラレル化されません。
シングルテーブル・インサートの場合、明示的に値を指定する、または副問合せで値を検索することによって、表、ビューまたはマテリアライズド・ビューの1行に値を挿入します。
副問合せでflashback_query_clause
を使用すると、過去のデータをtable
に挿入できます。この句の詳細は、「SELECT
」の「flashback_query_clause」を参照してください。
副問合せで値を検索する場合、副問合せのSELECT構文のリストにはINSERT
文の列リストと同じ数の列が含まれている必要があります。列リストを指定しない場合は、副問合せで表の各列の値を指定する必要があります。
INSERT
INTO
句を使用すると、データを挿入する対象となる表またはオブジェクトを指定できます。
INTO
DML_table_expression_clause
を使用すると、データを挿入するオブジェクトを指定できます。
表、ビューまたはマテリアライズド・ビューが含まれているスキーマを指定します。schema
を指定しない場合、オブジェクトは自分のスキーマ内にあるとみなされます。
行を挿入する表またはオブジェクト表の名前、ビューまたはオブジェクト・ビューの名前、マテリアライズド・ビューの名前、あるいは副問合せから戻された列の名前を指定します。ビューまたはオブジェクト・ビューを指定した場合、そのビューの実表に行が挿入されます。
読取り専用マテリアライズド・ビューには行を挿入できません。書込み可能なマテリアライズド・ビューに行を挿入した場合、基礎となるコンテナ表にその行が挿入されます。ただし、その挿入操作は次のリフレッシュ操作によって上書きされます。マテリアライズド・ビュー・グループ内の更新可能なマテリアライズド・ビューに行を挿入した場合、対応する行もマスター表に挿入されます。
挿入される値がオブジェクト表に対するREF
の場合、およびそのオブジェクト表に主キー・オブジェクト識別子がある場合、REF
を挿入する列は、オブジェクト表に対する参照整合性制約または有効範囲制約を持つREF
列である必要があります。
table
またはview
の実表に、1列以上のドメイン索引がある場合は、この文が適切な索引タイプの挿入ルーチンを実行します。
表に対してINSERT
文を発行した場合、その表に対して定義されているINSERT
トリガーが起動します。
この句には、次の制限事項があります。
table
またはview
の実表に、IN_PROGRESS
またはFAILED
とマークされたドメイン索引がある場合は、この文は実行できません。
UNUSABLE
とマークされている場合は、パーティションに挿入できません。
DML_table_expression_clause
のsubquery
のORDER
BY
句に関して、順序付けは、挿入された行または表の各エクステント内のみに保証されています。既存の行に関連する新しい行の順序付けは保証されていません。
WITH
CHECK
OPTION
を指定してビューを作成した場合、ビューを定義する問合せを満たす行のみビューに挿入されます。
returning_clause
を使用してその行の値を取り出せます。
INSTEAD
OF
トリガーを使用する場合を除いて、そのビューに行を挿入できません。
DISTINCT
演算子
GROUP
BY
、ORDER
BY
、MODEL
、CONNECT
BY
またはSTART
WITH
句
SELECT
構文のリストにあるコレクション式
SELECT
構文のリストにある副問合せ
WITH READ ONLY
が指定された副問合せ
UNUSABLE
のマークが付いている索引、索引パーティションまたは索引サブパーティションを指定する場合、SKIP_UNUSABLE_INDEXES
セッション・パラメータがTRUE
に設定されていないかぎり、INSERT
文は正常に実行されません。SKIP_UNUSABLE_INDEXES
セッション・パラメータの詳細は、「ALTER SESSION」を参照してください。
挿入先のtable
またはview
の実表内にあるパーティションまたはサブパーティションの名前またはパーティション・キー値を指定します。
挿入する行が特定のパーティションまたはサブパーティションにマップされない場合、エラーが戻されます。
この句は、オブジェクト表またはオブジェクト・ビューでは無効です。
表またはビューが格納されているリモート・データベースへのデータベース・リンクの完全名または部分名を指定します。Oracle Databaseの分散機能を使用している場合にのみ、リモート表またはリモート・ビューに行を挿入できます。
dblink
を指定しない場合、その表またはビューはローカル・データベース内にあるとみなされます。
参照:
|
subquery_restriction_clause
を使用すると、次のいずれかの方法で副問合せを制限できます。
WITH READ ONLY
を指定すると、表またはビューを更新禁止にできます。
WITH CHECK OPTION
を指定すると、副問合せに含まれない行を生成する表またはビューの変更を禁止できます。この句をDML文の副問合せ内で使用する場合、FROM
句内の副問合せには指定できますが、WHERE
句内の副問合せには指定できません。
CHECK OPTION
制約の名前を指定します。この識別子を省略した場合、その制約にSYS_C
n
という形式の名前が自動的に割り当てられます。この場合のnは、その制約名をデータベース内で一意の名前にする整数です。
table_collection_expression
を使用すると、問合せおよびDML操作で、collection_expression
値を表として扱うことができます。collection_expression
には、副問合せ、列、ファンクションまたはコレクション・コンストラクタのいずれかを指定できます。その形式にかかわらず、集合値(ネストした表型またはVARRAY型の値)を戻す必要があります。このようなコレクションの要素抽出プロセスをコレクション・ネスト解除といいます。
TABLE
式を親表と結合する場合は、オプションのプラス(+)には大きな意味があります。+を指定すると、その2つの外部結合が作成され、コレクション式がNULLの場合でも、外部表の行が問合せで戻されるようになります。
相関名を指定します。これは、文中で参照する表、ビュー、マテリアライズド・ビューまたは副問合せの別名です。
t_alias
は、マルチテーブル・インサートに指定できません。
表、ビューまたはマテリアライズド・ビューの列を指定します。挿入された行では、このリストにある各列にvalues_clause
または副問合せの値が代入されます。
このリストに1つ以上の列を指定しない場合、挿入された行の、指定しなかった列の値には、表の作成時または最終更新時に指定した列のデフォルト値が使用されます。指定しなかった列のいずれかにNOT
NULL
制約があり、デフォルト値がない場合、制約違反のエラーが発生してINSERT
文がロールバックされます。列のデフォルト値の詳細は、「CREATE TABLE」を参照してください。
列リストを指定しない場合は、values_clause
または問合せに、表の列をすべて指定する必要があります。
シングルテーブル・インサート操作の場合、表またはビューに挿入する値の行を指定します。なお、値は、列リスト内の各列についてvalues_clause
に指定する必要があります。列リストを指定しない場合、values_clause
または副問合せで、表の各列の値を指定する必要があります。
マルチテーブル・インサート操作の場合、values_clause
の各式は、副問合せのSELECT構文のリストによって戻される列を参照する必要があります。values_clause
を省略すると、副問合せのSELECT構文のリストによって挿入する値が決定されるため、insert_into_clause
に対応する列リストと同じ列数を含んでいる必要があります。insert_into_clause
で列リストを指定しない場合、対象となる表のすべての列に対する値を計算した行を指定する必要があります。
どちらの挿入操作の場合も、insert_into_clause
で列リストを指定すると、リストの各列に値の句または副問合せからの対応する値が割り当てられます。values_clause
の任意の値に対してDEFAULT
を指定できます。表またはビューの対応する列に対してデフォルト値を指定すると、その値が挿入されます。対応する列に対してデフォルト値を指定しない場合、NULLが挿入されます。有効な式の構文の詳細は、「SQL式」および「SELECT」を参照してください。
この値には、次の制限事項があります。
BFILE
ロケータをNULLに、またはディレクトリ名およびファイル名に初期化するまで、BFILE
値を挿入できません。
参照:
BFILE
値の初期化の詳細およびBFILE
への挿入例については、「BFILENAME」を参照してください。
BFILE
ロケータの初期化の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
partition_value
リストに存在していないパーティション化キー列に値を挿入できません。
DEFAULT
を指定できません。
RAW
列に文字列リテラルを挿入する場合、後続の問合せ中にRAW
列にある索引は使用されずに、全表スキャンが行われます。
参照:
この句を使用すると、DML文に影響される行を取り出すことができます。この句は、表、マテリアライズド・ビュー、および単一の実表を持つビューに指定できます。
returning_clause
を指定したDML文を単一行に実行すると、影響された行、ROWID、および処理された行へのREF
を使用している列式が取り出され、ホスト変数またはPL/SQL変数に格納されます。
returning_clause
を指定したDML文を複数行に実行すると、式の値、ROWIDおよび処理された行に関連するREF
がバインド配列に格納されます。
expr
リストの各項目は、適切な構文で表す必要があります。
INTO
句を指定すると、変更された行の値を、data_item
リストに指定する変数に格納できます。
取り出されたexpr
値を格納するホスト変数またはPL/SQL変数を指定します。
RETURNING
リストの各式については、INTO
リストに、対応する型に互換性があるPL/SQL変数またはホスト変数を指定する必要があります。
RETURNING
句には、次の制限事項があります。
expr
に次の制限事項があります。
expr
リストに主キー列またはその他のNOT
NULL
列が含まれている場合、表にBEFORE
UPDATE
トリガーが定義されていると、UPDATE文は正常に実行されません。
returning_clause
を指定できません。
LONG
型を取り出すことはできません。
INSTEAD
OF
トリガーが定義されたビューに対して指定することはできません。マルチテーブル・インサートでは、副問合せの評価によって戻された行から導出され、計算された行が1つ以上の表に挿入されます。
副問合せのSELECT構文のリストでは、表の別名は定義されていません。そのため、SELECT構文のリストに依存する句では、表の別名は参照できません。たとえば、式内のオブジェクト列を参照しようとしても、表の別名は参照できません。表の別名とともに式を使用する場合は、列の別名を使用して式をSELECT構文のリストに挿入してから、マルチテーブル・インサートのVALUES
句またはWHEN
条件で列の別名を参照する必要があります。
ALL
の後に複数のinsert_into_clauses
を指定すると、無条件のマルチテーブル・インサートを実行できます。副問合せによって戻される各行に対して、各insert_into_clause
が1回実行されます。
conditional_insert_clause
を指定すると、条件付きのマルチテーブル・インサートを実行できます。各insert_into_clause
は、それに対応するWHEN
条件で実行されるかどうかが判断されます。WHEN
条件の各式は、副問合せのSELECT構文のリストによって戻される列を参照する必要があります。1つのマルチテーブル・インサートには、最大127個のWHEN
句を指定できます。
ALL
(デフォルト値)を指定すると、他のWHEN
句の評価結果にかかわらず、各WHEN
句が評価されます。条件が真と評価された各WHEN
句に対して、対応するINTO
句リストが実行されます。
FIRST
を指定すると、文で指定されている順序で各WHEN
句が評価されます。真と評価された最初のWHEN
句に対して、対応するINTO
句が実行され、指定された行に対する後続のWHEN
句はスキップされます。
指定された行に対して、WHEN
句が真と評価されない場合、次のようになります。
マルチテーブル・インサートには、次の制限事項があります。
insert_into_clause
で組み合せて指定できる列が最大999です。
NEXTVAL
を初めて参照するときに、その次の番号が生成された後、この番号と同じ番号が、この文の後続のすべての参照で戻されます。
表に挿入される行を戻す副問合せを指定します。副問合せによって、INSERT
文の対象となる表を含む任意の表、ビューおよびマテリアライズド・ビューを参照できます。副問合せで選択された行が1行もない場合、表に行は挿入されません。
subquery
をTO_LOB
ファンクションと組み合せて、LONG
列にある値を、同じ表の異なる列または別の表にあるLOB値に変換できます。ビュー内でLONG
値を別の列のLOB値に移行する場合、実表内で移行を実行してからビューにLOB列を追加する必要があります。
副問合せを使用した挿入には、次の注意事項があります。
subquery
が、既存のマテリアライズド・ビューと部分的または完全に同じビューを戻す場合、subquery
に指定された1つ以上の表のかわりにマテリアライズド・ビューがクエリー・リライトに使用されることがあります。subquery
がリモート・オブジェクトを参照する場合、参照がローカル・データベース上でオブジェクトにループバックしないかぎり、INSERT
はパラレルで実行されます。ただし、DML_table_expression_clause
のsubquery
がリモート・オブジェクトを参照する場合は、INSERT
操作はシリアルで実行されます。詳細は、「parallel_clause」を参照してください。
参照:
BFILE
への挿入例については、「BFILENAME」を参照してください。
BFILE
の初期化の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
error_logging_clause
を使用すると、DMLエラーと、その影響を受ける行のログ列値を取得して、エラー・ロギング表に保存できます。
エラー・ロギング表の名前を指定します。この句を省略すると、DBMS_ERRLOG
パッケージで生成されたデフォルトの名前が割り当てられます。エラー・ログ表のデフォルトの名前は、DML操作の対象となっている表の名前の最初の25文字を、ERR$_
の後に加えたものです。
文のタグとして使用する値を指定します。エラー・ロギング表内のエラーは、この文で識別することになります。この式には、テキスト・リテラル、数値リテラル、一般のSQL式(バインド変数など)のいずれかを指定できます。テキスト・リテラルに変換する場合は、たとえばTO_CHAR(SYSDATE)
のようなファンクション式も使用できます。
この句を使用すると、記録するエラーの数の上限値を整数で指定できます。エラーの数がこの値を超えると、文が終了し、その文によって変更された内容がロールバックされます。この拒否の制限のデフォルトは0(ゼロ)です。パラレルDML操作の場合、拒否の制限はパラレル・サーバーごとに適用されます。
LONG
、LOBまたはオブジェクト型の列のエラーは追跡できません。ただし、DML操作を行う表に、これらの型の列を含めることができます。
参照:
DBMS_ERRLOG
パッケージのcreate_error_log
プロシージャの使用方法は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。DMLエラー・ロギングに関する一般情報は、『Oracle Database管理者ガイド』を参照してください。
次の文は、サンプル表departments
に行を挿入します。
INSERT INTO departments VALUES (280, 'Recreation', 121, 1700);
manager_id
列のデフォルト値が121としてdepartments
表が作成された場合、次の文を発行できます。
INSERT INTO departments VALUES (280, 'Recreation', DEFAULT, 1700);
次の文は、employees
表に6つの列で構成される行を挿入します。NULL
または科学表記の数値を設定されている列がそれぞれ1つ含まれています。
INSERT INTO employees (employee_id, last_name, email, hire_date, job_id, salary, commission_pct) VALUES (207, 'Gregory', 'pgregory@example.com', sysdate, 'PU_CLERK', 1.2E3, NULL);
次の文は、前述の例と同じ結果を表しますが、DML_table_expression_clause
にある副問合せを使用します。
INSERT INTO (SELECT employee_id, last_name, email, hire_date, job_id, salary, commission_pct FROM employees) VALUES (207, 'Gregory', 'pgregory@example.com', sysdate, 'PU_CLERK', 1.2E3, NULL);
次の文は、歩合給が給与の25%を超える従業員をbonuses
表(「表へのマージ例:」で作成)にコピーします。
INSERT INTO bonuses SELECT employee_id, salary*1.1 FROM employees WHERE commission_pct > 0.25;
次の文は、サンプル・スキーマhr
内にraises
表を作成し、DBMS_ERRLOG
パッケージを使用してエラー・ロギング表を作成して、employees
表のデータをraises
表に移入します。raises
のチェック制約に違反する挿入操作があると、その行をerrlog
で参照できます。発生したエラーが10を超えると、その文は異常終了し、挿入された内容はロールバックされます。
CREATE TABLE raises (emp_id NUMBER, sal NUMBER CONSTRAINT check_sal CHECK(sal > 8000)); EXECUTE DBMS_ERRLOG.CREATE_ERROR_LOG('raises', 'errlog'); INSERT INTO raises SELECT employee_id, salary*1.1 FROM employees WHERE commission_pct > .2 LOG ERRORS INTO errlog ('my_bad') REJECT LIMIT 10; SELECT ORA_ERR_MESG$, ORA_ERR_TAG$, emp_id, sal FROM errlog; ORA_ERR_MESG$ ORA_ERR_TAG$ EMP_ID SAL --------------------------- -------------------- ------ ------- ORA-02290: check constraint my_bad 161 7700 (HR.SYS_C004266) violated
次の文は、データベース・リンクremote
がアクセスできるデータベース上の、ユーザーhr
が所有するemployees
表に行を挿入します。
INSERT INTO employees@remote VALUES (8002, 'Juan', 'Fernandez', 'juanf@hr.example.com', NULL, TO_DATE('04-OCT-1992', 'DD-MON-YYYY'), 'SH_CLERK', 3000, NULL, 121, 20);
次の文は、departments_seq
順序の次の値を持つ行を、departments
表に挿入します。
INSERT INTO departments VALUES (departments_seq.nextval, 'Entertainment', 162, 1400);
次の文は、出力バインド変数bnd1
およびbnd2
に挿入された行の値を戻します。バインド変数は最初に宣言しておく必要があります。
INSERT INTO employees (employee_id, last_name, email, hire_date, job_id, salary) VALUES (employees_seq.nextval, 'Doe', 'john.doe@example.com', SYSDATE, 'SH_CLERK', 2400) RETURNING salary*12, job_id INTO :bnd1, :bnd2;
次の例は、persons
表(「置換可能な表および列のサンプル:」で作成)に挿入します。最初の文は、ルート型person_t
を使用します。2番目の挿入は、person_t
のサブタイプemployee_t
を使用し、3番目の挿入はemployee_t
のサブタイプpart_time_emp_t
を使用します。
INSERT INTO persons VALUES (person_t('Bob', 1234)); INSERT INTO persons VALUES (employee_t('Joe', 32456, 12, 100000)); INSERT INTO persons VALUES ( part_time_emp_t('Tim', 5678, 13, 1000, 20));
次の例は、books
表(「置換可能な表および列のサンプル:」で作成)に挿入します。属性値の指定が、置換可能な表の例と同一であることに注意してください。
INSERT INTO books VALUES ( 'An Autobiography', person_t('Bob', 1234)); INSERT INTO books VALUES ( 'Business Rules', employee_t('Joe', 3456, 12, 10000)); INSERT INTO books VALUES ( 'Mixing School and Work', part_time_emp_t('Tim', 5678, 13, 1000, 20));
組込みファンクションおよび条件を使用して、置換可能な表および列からデータを抽出することができます。その例は、「TREAT」、「SYS_TYPEID」および「IS OF type条件」を参照してください。
次の例は、LONG
データを次のlong_tab
表にあるLOB列にコピーします。
CREATE TABLE long_tab (pic_id NUMBER, long_pics LONG RAW);
まず、LOBを持つ表を作成します。
CREATE TABLE lob_tab (pic_id NUMBER, lob_pics BLOB);
次に、INSERT
... SELECT
を使用して、LONG
列のすべての行にあるデータを、新しく作成したLOB列にコピーします。
INSERT INTO lob_tab SELECT pic_id, TO_LOB(long_pics) FROM long_tab;
移行が問題なく終了したことを確認したら、long_pics
表を削除できます。別の方法として、表が他の列を含む場合、次のように入力して表からLONG
列を削除できます。
ALTER TABLE long_tab DROP COLUMN long_pics;
次の例はマルチテーブル・インサートの構文を使用して、サンプル表sh.sales
に、異なる構造の入力表からデータを挿入します。
入力表は次のように構成されています。
SELECT * FROM sales_input_table;
PRODUCT_ID CUSTOMER_ID WEEKLY_ST SALES_SUN SALES_MON SALES_TUE SALES_WED SALES_THU SALES_FRI SALES_SAT ---------- ----------- --------- ---------- ---------- ---------- -------------------- ---------- ---------- 111 222 01-OCT-00 100 200 300 400 500 600 700 222 333 08-OCT-00 200 300 400 500 600 700 800 333 444 15-OCT-00 300 400 500 600 700 800 900
マルチテーブル・インサートの文を次に示します。
INSERT ALL INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date, sales_sun) INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date+1, sales_mon) INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date+2, sales_tue) INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date+3, sales_wed) INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date+4, sales_thu) INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date+5, sales_fri) INTO sales (prod_id, cust_id, time_id, amount) VALUES (product_id, customer_id, weekly_start_date+6, sales_sat) SELECT product_id, customer_id, weekly_start_date, sales_sun, sales_mon, sales_tue, sales_wed, sales_thu, sales_fri, sales_sat FROM sales_input_table;
sales
表には次の行のみが存在するものとします。内容は次のとおりです。
SELECT * FROM sales ORDER BY prod_id, cust_id, time_id; PROD_ID CUST_ID TIME_ID C PROMO_ID QUANTITY_SOLD AMOUNT COST ---------- ---------- --------- - ---------- ------------- ---------- ---------- 111 222 01-OCT-00 100 111 222 02-OCT-00 200 111 222 03-OCT-00 300 111 222 04-OCT-00 400 111 222 05-OCT-00 500 111 222 06-OCT-00 600 111 222 07-OCT-00 700 222 333 08-OCT-00 200 222 333 09-OCT-00 300 222 333 10-OCT-00 400 222 333 11-OCT-00 500 222 333 12-OCT-00 600 222 333 13-OCT-00 700 222 333 14-OCT-00 800 333 444 15-OCT-00 300 333 444 16-OCT-00 400 333 444 17-OCT-00 500 333 444 18-OCT-00 600 333 444 19-OCT-00 700 333 444 20-OCT-00 800 333 444 21-OCT-00 900
次の例は、複数の表に挿入します。販売員に様々なサイズの注文に関する情報を提供するとします。小口、中口、大口および特別注文についての表を作成し、これらの表にサンプル表oe.orders
のデータを移入します。
CREATE TABLE small_orders (order_id NUMBER(12) NOT NULL, customer_id NUMBER(6) NOT NULL, order_total NUMBER(8,2), sales_rep_id NUMBER(6) ); CREATE TABLE medium_orders AS SELECT * FROM small_orders; CREATE TABLE large_orders AS SELECT * FROM small_orders; CREATE TABLE special_orders (order_id NUMBER(12) NOT NULL, customer_id NUMBER(6) NOT NULL, order_total NUMBER(8,2), sales_rep_id NUMBER(6), credit_limit NUMBER(9,2), cust_email VARCHAR2(30) );
最初のマルチテーブル・インサートでは、小口、中口および大口注文の表に対してのみ移入を行います。
INSERT ALL WHEN order_total < 1000000 THEN INTO small_orders WHEN order_total > 1000000 AND order_total < 2000000 THEN INTO medium_orders WHEN order_total > 2000000 THEN INTO large_orders SELECT order_id, order_total, sales_rep_id, customer_id FROM orders;
large_orders
表への挿入のかわりに、ELSE
句を使用しても、同じ結果が得られます。
INSERT ALL WHEN order_total < 100000 THEN INTO small_orders WHEN order_total > 100000 AND order_total < 200000 THEN INTO medium_orders ELSE INTO large_orders SELECT order_id, order_total, sales_rep_id, customer_id FROM orders;
次の例は、前述の例と同様、小口、中口および大口注文の表に挿入し、件数が2,900,000を超える注文をspecial_orders
表に挿入します。この表は、文を単純にするために列の別名を使用する方法も示しています。
INSERT ALL WHEN ottl < 100000 THEN INTO small_orders VALUES(oid, ottl, sid, cid) WHEN ottl > 100000 and ottl < 200000 THEN INTO medium_orders VALUES(oid, ottl, sid, cid) WHEN ottl > 200000 THEN into large_orders VALUES(oid, ottl, sid, cid) WHEN ottl > 290000 THEN INTO special_orders SELECT o.order_id oid, o.customer_id cid, o.order_total ottl, o.sales_rep_id sid, c.credit_limit cl, c.cust_email cem FROM orders o, customers c WHERE o.customer_id = c.customer_id;
最後の例は、FIRST
句を使用して、件数が2,900,000を超える注文をspecial_orders
表に挿入し、これらの注文をlarge_orders
表から削除します。
INSERT FIRST WHEN ottl < 100000 THEN INTO small_orders VALUES(oid, ottl, sid, cid) WHEN ottl > 100000 and ottl < 200000 THEN INTO medium_orders VALUES(oid, ottl, sid, cid) WHEN ottl > 290000 THEN INTO special_orders WHEN ottl > 200000 THEN INTO large_orders VALUES(oid, ottl, sid, cid) SELECT o.order_id oid, o.customer_id cid, o.order_total ottl, o.sales_rep_id sid, c.credit_limit cl, c.cust_email cem FROM orders o, customers c WHERE o.customer_id = c.customer_id;
LOCK
TABLE
文を使用すると、1つ以上の表、表パーティションまたは表サブパーティションを特定のモードでロックできます。操作中の表またはビューに対する他のユーザーによるアクセスを許可または制限するため、自動ロックを手動で無効にします。
ロックによっては、同じ表に同時に設定できる場合、または表ごとに1つのみ設定できる場合があります。
ロックされた表は、トランザクションをコミットするか、全体をロールバックするか、または表をロックする前のセーブポイントにロールバックするまでロックされています。
ロックした場合でも他のユーザーが表を問い合せることができます。問合せによって表がロックされることはありません。読取りプログラムは書込みプログラムをブロックすることはなく、書込みプログラムが読取りプログラムをブロックすることもありません。
表またはビューが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、LOCK
ANY
TABLE
システム権限、または表やビューに対するオブジェクト権限が必要です。
表またはビューが含まれているスキーマを指定します。schema
を指定しない場合、表またはビューは自分のスキーマにあるとみなされます。
ロックする表の名前を指定します。
view
を指定した場合、ビューの実表がロックされます。
partition_extension_clause
を指定した場合、Oracle Databaseでは最初にその表が暗黙的にロックされます。表ロックは、partitionまたはsubpartitionに指定したロックと同じです。ただし、次の2つの例外があります。
SHARE
ロックをサブパーティションに指定した場合、表が暗黙的にROW
SHARE
ロックされます。
EXCLUSIVE
ロックをサブパーティションに指定した場合、表が暗黙的にROW
EXCLUSIVE
ロックされます。
PARTITION
を指定し、table
がコンポジット・パーティション化されている場合、パーティションのすべてのサブパーティションがロックされます。
view
が階層の一部である場合、階層のルートである必要があります。
表またはビューが格納されている、Oracle Databaseのリモート・データベースに対するデータベース・リンクを指定します。Oracle分散機能を使用している場合のみ、リモート・データベースで表およびビューをロックできます。LOCK
TABLE
文を使用してロックする表は、すべて同じデータベース上にある必要があります。
dblink
を指定しない場合、その表またはビューはローカル・データベース内にあるとみなされます。
次のいずれかのモードを指定します。
ROW
SHARE
を指定すると、ロックされた表への同時アクセスは可能になりますが、排他アクセスのために表全体をロックできなくなります。ROW
SHARE
は、SHARE
UPDATE
と同じ意味で、以前のリリースのOracle Databaseとの互換性を保つために用意されています。
ROW
EXCLUSIVE
は、ROW
SHARE
と同じですが、SHARE
モードでロックはできません。ROW
EXCLUSIVE
ロックは、更新、挿入、削除の実行時に自動的に適用されます。
「ROW SHARE」を参照してください。
SHARE
を指定すると、同時問合せは実行可能ですが、ロックされた表は更新できなくなります。
SHARE
ROW
EXCLUSIVE
は、表全体を見る場合に使用します。これを使用すると他のユーザーがその表内の行を見ることはできますが、SHARE
モードで表のロックまたは行の更新を行うことはできません。
EXCLUSIVE
を指定すると、ロックされた表上での問合せは実行可能ですが、他のアクティビティは実行できなくなります。
NOWAIT
を指定すると、指定した表、パーティションまたは表のサブパーティションが他のユーザーによってすでにロックされている場合に、制御をすぐに戻すことができます。この場合、表、パーティションまたはサブパーティションが他のユーザーによってロックされていることを示すエラー・メッセージが戻ります。
WAIT
句を使用すると、LOCK
TABLE
文では、DMLロックを取得するまでに指定した時間(秒数)待機するように指定できます。integer
の値に制限はありません。
NOWAIT
もWAIT
も指定しない場合には、表が利用可能になり、ロックされ、制御が戻されるまで、データベースは無限に待機します。データベースでDML文と同時にDDL文が実行されている場合、タイムアウトまたはデッドロックが発生することがあります。このようなタイムアウトまたはデッドロックが検出されると、エラーが戻されます。
次の文は、employees
表を排他モードでロックします。他のユーザーがすでに表をロックしている場合でも、待ち状態にはなりません。
LOCK TABLE employees IN EXCLUSIVE MODE NOWAIT;
次の文は、データベース・リンクremote
を介してアクセスできるリモート表employees
をロックします。
LOCK TABLE employees@remote IN SHARE MODE;
MERGE
文を使用すると、1つ以上のソースから行を選択し、表またはビューに対して更新および挿入できます。対象となる表またはビューに対して更新と挿入のどちらを実行するかを決定する条件を指定できます。
この文は、複数の操作を組み合せるときに便利です。DML文INSERT
、UPDATE
およびDELETE
を複数指定する必要がなくなります。
MERGE
は、決定的な文です。対象となる表の同じ行を、同一のMERGE
文で何度も更新することはできません。
対象となる表に対するINSERT
オブジェクト権限とUPDATE
オブジェクト権限、およびソース表に対するSELECT
オブジェクト権限が必要です。merge_update_clause
のDELETE
句を指定するには、対象となる表に対するDELETE
オブジェクト権限も必要です。
(merge_update_clause::=、merge_insert_clause::=、error_logging_clause::=を参照)
INTO
句を使用すると、更新または挿入の対象となる表またはビューを指定できます。データをビューにマージする場合、そのビューは更新可能であることが必要です。詳細は、「更新可能なビューの注意事項:」を参照してください。
USING
句を使用すると、更新または挿入の対象となるデータのソースを指定できます。ソースには、表、ビューまたは副問合せの結果を指定できます。
ON
句を使用すると、MERGE
の更新操作または挿入操作の条件を指定できます。対象となる表の中で検索条件が真となる各行は、ソース表の対応するデータに基づいて行が更新されます。どの行も条件が真とならない場合、ソース表の対応する行に基づいて対象となる表に行が挿入されます。
MERGE
文では、ファイングレイン・アクセス・コントロールが実行されません。操作対象の1つまたは複数の表でファイングレイン・アクセス・コントロール機能を使用する場合は、MERGE
文ではなく、それと等価なINSERT
およびUPDATE
文を使用して、エラー・メッセージを避け、適正なアクセス制御を行ってください。
merge_update_clause
を指定すると、対象となる表の新しい列値を指定できます。ON
句の条件が真となる場合、更新が実行されます。更新が実行されると、対象となる表に定義されているすべての更新トリガーがアクティブになります。
where_clause
を指定すると、指定した条件が真の場合のみに更新操作が実行されるようにできます。条件には、データ・ソースまたは対象となる表を参照できます。条件が真ではない場合、行を表に挿入する際に更新操作がスキップされます。
DELETE
where_clause
を指定すると、表の移入中または更新中にその表内のデータをクリーンアップできます。この句によって処理される行は、マージ操作によって更新される対象の表内の行のみです。DELETE
WHERE
条件は、更新後の値を評価し、UPDATE
SET
... WHERE
条件によって評価された元の値は評価しません。更新先の表の行がDELETE
条件を満たし、ON
句によって定義された結合に含まれていない場合、その行は削除されます。更新先の表に定義されている削除トリガーが起動し、各行が削除されます。
この句は、単独で、またはmerge_insert_clause
とともに指定できます。merge_insert_clause
とともに指定する場合は、どちらを先に指定してもかまいません。
この句には、次の制限事項があります。
merge_insert_clause
を指定すると、ON
句の条件が偽となる場合に対象となる表の列に挿入する値を指定できます。挿入が実行されると、対象となる表に定義されているすべての挿入トリガーがアクティブになります。INSERT
キーワードの後に列リストを指定しない場合、対象となる表内の列数は、VALUES
句内の値の数と一致している必要があります。
すべてのソース行を表に挿入するには、ON
句の条件に定数フィルタ条件を使用します。定数フィルタ条件の一例はON
(0=1
)です。Oracle Databaseはこのような条件を認識すると、すべてのソース行を無条件に表に挿入します。この方法は、merge_update_clause
を省略することとは異なります。merge_update_clauseを省略しても、結合は実行されます。定数フィルタ条件を設定すると、結合は実行されません。
where_clause
を指定すると、指定した条件が真の場合のみに更新操作が実行されるようにできます。条件には、データ・ソース表のみを参照できます。条件が真ではないすべての行に対する挿入操作はスキップされます。
この句は、単独で、またはmerge_update_clause
とともに指定できます。merge_insert_clauseとともに指定する場合は、どちらを先に指定してもかまいません。
ビューを更新する場合は、DEFAULT
を指定できません。
error_logging_clauseのMERGE
文での動作は、INSERT
文の場合と同じです。詳細は、INSERT
文の「error_logging_clause」を参照してください。
次の例は、oe
サンプル・スキーマ内のbonuses
表(ボーナスのデフォルトは100)を使用します。次に、oe.orders
表のsales_rep_id
列に基づいて販売実績があったすべての従業員を、bonuses
表に挿入します。最終的に、人事部門マネージャが、給与が8000ドル以下の従業員にボーナスを支給することを決定します。販売実績がなかった従業員には、給与の1%がボーナスとして支給されます。販売実績があった従業員には、給与の1%がボーナスに加算されて支給されます。MERGE
文は、これらの変更を1行で実装します。
CREATE TABLE bonuses (employee_id NUMBER, bonus NUMBER DEFAULT 100); INSERT INTO bonuses(employee_id) (SELECT e.employee_id FROM employees e, orders o WHERE e.employee_id = o.sales_rep_id GROUP BY e.employee_id); SELECT * FROM bonuses ORDER BY employee_id; EMPLOYEE_ID BONUS ----------- ---------- 153 100 154 100 155 100 156 100 158 100 159 100 160 100 161 100 163 100 MERGE INTO bonuses D USING (SELECT employee_id, salary, department_id FROM employees WHERE department_id = 80) S ON (D.employee_id = S.employee_id) WHEN MATCHED THEN UPDATE SET D.bonus = D.bonus + S.salary*.01 DELETE WHERE (S.salary > 8000) WHEN NOT MATCHED THEN INSERT (D.employee_id, D.bonus) VALUES (S.employee_id, S.salary*.01) WHERE (S.salary <= 8000); SELECT * FROM bonuses ORDER BY employee_id; EMPLOYEE_ID BONUS ----------- ---------- 153 180 154 175 155 170 159 180 160 175 161 170 179 620 173 610 165 680 166 640 164 720 172 730 167 620 171 740
NOAUDIT
文を使用すると、AUDIT
文によって有効になった監査操作を停止できます。
NOAUDIT
文は先に発行したAUDIT
文と同じ構文である必要があります。また、NOAUDIT文は、その特定のAUDIT文のみを無効にします。たとえば、1番目のAUDIT
文Aは特定のユーザーに対する監査を有効にするものとします。2番目の文Bが、すべてのユーザーに対して監査を有効にします。すべてのユーザーに対して監査を無効にするNOAUDIT
文Cは、文Bを無効にします。ただし、文Aは無効にされず、文Aが指定したユーザーの監査は継続されます。
SQL文の監査を停止するには、AUDIT
SYSTEM
システム権限が必要です。
スキーマ・オブジェクトの監査を停止するには、監査を停止するオブジェクトが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、AUDIT
ANY
システム権限が必要です。監査の対象として選択するオブジェクトがディレクトリの場合、自分が作成したディレクトリであっても、AUDIT
ANY
システム権限が必要です。
(audit_operation_clause::=、audit_schema_object_clause::=を参照)
audit_operation_clause
を使用すると、特定のSQL文の監査を停止できます。
sql_statement_shortcut
では、監査を停止するSQL文のショートカットを指定します。SQL文のショートカットおよびショートカットによって監査されるSQL文の詳細は、表13-1および表13-2を参照してください。
ALL
を指定すると、現在監査されているすべての文オプションの監査を停止できます。
監査を停止するシステム権限を指定します。システム権限および各システム権限によって許可される文については、表18-1を参照してください。
ALL
PRIVILEGES
を指定すると、現在監査されているすべてのシステム権限の監査を停止できます。
auditing_by_clause
を使用すると、特定のユーザーが発行するSQL文の監査のみを停止できます。この句を指定しない場合、すべてのユーザー文の監査が停止されます。
BY
user
を指定します。この句を指定しない場合、すべてのユーザー文の監査が停止されます。ただし、「WHENEVER
SUCCESSFUL
」で説明する状況は除きます。
BY
proxy
を指定します。
audit_schema_object_clause
を使用すると、特定のデータベース・オブジェクトの監査を停止できます。
sql_operation
の場合、ON
句で指定したオブジェクトへの監査を停止する操作の種類を指定します。これらのオプションのリストは、表13-3を参照してください。
ALL
をショートカットに指定することは、オブジェクト・タイプに適用できるSQL操作をすべて指定することと同じです。
auditing_on_clause
を使用すると、監査を停止する特定のスキーマ・オブジェクトを指定できます。
object
をschema
で修飾しなかった場合、そのオブジェクトは自分のスキーマ内にあるとみなされます。特定のスキーマ・オブジェクトの監査については、「AUDIT」を参照してください。
DIRECTORY
では、監査を停止するディレクトリ名を指定できます。
DEFAULT
を指定して、オブジェクトを作成した後に、特定のオブジェクト・オプションをデフォルト・オブジェクト・オプションとして削除します。
この句を使用すると、データベース・リンクの使用とログインの監査を停止できます。
WHENEVER
SUCCESSFUL
を指定すると、正常に実行されたスキーマ・オブジェクトに対するSQL文および操作の監査のみを停止できます。
WHENEVER
NOT
SUCCESSFUL
を指定すると、Oracle Databaseエラーとなった文および操作の監査のみが停止されます。
この句を指定しない場合、正常に実行されたかどうかにかかわらず、すべての文および操作の監査が停止されます。
次の文は、ロールを作成または削除するすべてのSQL文の監査を停止します。
NOAUDIT ROLE;
次の文は、ユーザーhr
およびoe
によって発行された、表の問合せまたは更新を実行する文を監査している場合、hr
の問合せの監査のみを停止します。
NOAUDIT SELECT TABLE BY hr;
この結果、ユーザーhr
の問合せの監査のみが停止されます。oe
の問合せと更新、およびhr
の更新の監査は継続されます。
次の文は、DELETE
ANY
TABLE
システム権限に許可されたすべての文の監査を停止します。
NOAUDIT DELETE ANY TABLE;
次の文は、スキーマhr
内のemployees
表に問い合せるすべてのSQL文の監査を選択していた場合に、この監査を停止します。
NOAUDIT SELECT ON hr.employees;
次の文は、正常に終了した問合せの監査を停止します。
NOAUDIT SELECT ON hr.employees WHENEVER SUCCESSFUL;
この文は、正常に終了した問合せの監査のみ停止します。Oracle Databaseエラーが発生した問合せの監査は継続されます。
PURGE
文を使用すると、ごみ箱内の表または索引を削除してそのオブジェクトに関連付けられていたすべての領域を解放するか、ごみ箱全体を空にするか、または削除された表領域の一部または全体をごみ箱から削除できます。
ごみ箱の内容を参照するには、USER_RECYCLEBIN
データ・ディクショナリ・ビューを問い合せます。かわりにRECYCLEBIN
シノニムを使用することもできます。次の2つの文は、同じ行を戻します。
SELECT * FROM RECYCLEBIN; SELECT * FROM USER_RECYCLEBIN;
参照:
|
データベース・オブジェクトが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、消去するオブジェクトのタイプに対するDROP
ANY
...システム権限、またはSYSDBA
システム権限が必要です。
ごみ箱内の消去する表または索引の名前を指定します。ユーザーが指定した元の名前か、オブジェクトの削除時にそのオブジェクトに割り当てられたシステム生成名を指定できます。
表が消去されると、その表のすべての表パーティション、LOBとLOBパーティション、索引、およびその他の依存オブジェクトも消去されます。
この句を使用すると、現行のユーザーのごみ箱を空にできます。そのユーザーのごみ箱からすべてのオブジェクトが消去され、そのオブジェクトに関連付けられていたすべての領域が解放されます。
この句は、SYSDBA
システム権限を持っている場合にのみ有効です。この句を使用すると、システム全体のごみ箱からすべてのオブジェクトを削除できます。これは、各ユーザーのごみ箱を空にすることと同じです。この操作は、以前のリリースへの移行などの場合に役立ちます。
この句を使用すると、ごみ箱から、指定した領域内に存在するすべてのオブジェクトを消去できます。
この句を使用すると、指定したユーザーが、表領域内の領域を再利用できます。この操作は、特定のユーザーの、特定の表領域に対するディスク領域が割当て制限間近である場合に特に役立ちます。
次の文は、ごみ箱からtest
表を削除します。複数のバージョンのtest表がごみ箱内に存在する場合、Oracle Databaseでは、ごみ箱内に最も長く存在しているものが削除されます。
PURGE TABLE test;
ごみ箱から削除する表のシステム生成名を判断するには、ごみ箱に対するSELECT
文を発行します。そのオブジェクト名を使用して、次の文に類似した文を発行して表を削除できます。(システム生成名は、次の例に示すものとは異なります。)
PURGE TABLE RB$$33750$TABLE$0;
次の文は、ごみ箱のすべての内容を削除します。
PURGE RECYCLEBIN;
RENAME
文を使用すると、表、ビュー、順序またはプライベート・シノニムの名前を変更できます。
オブジェクトが自分のスキーマ内にある必要があります。
既存の表、ビュー、順序またはプライベート・シノニムの名前を指定します。
既存のオブジェクトに指定する新しい名前を指定します。新しい名前は、同じネームスペース内の他のスキーマ・オブジェクトに使用されている名前以外を指定する必要があります。また、スキーマ・オブジェクトのネーミング規則に従って指定する必要があります。
オブジェクト名の変更には、次の制限事項があります。
次の例では、サンプル表hr.departments
のコピーを使用します。次の文は、表の名前をdepartments_new
からemp_departments
に変更します。
RENAME departments_new TO emp_departments;
この文では列名を直接変更できません。ただし、ALTER
TABLE
... rename_column_clause
を使用すると、列の名前を変更できます。
列名を変更するもう1つの方法は、AS
副問合せを指定したCREATE
TABLE
文とともに、RENAME
文を使用する方法です。この方法は、単に列の名前を変更するのではなく、表の構造を変更する場合に有効です。次の文は、サンプル表hr.job_history
を再作成し、列の名前をdepartment_id
からdept_id
に変更します。
CREATE TABLE temporary (employee_id, start_date, end_date, job_id, dept_id) AS SELECT employee_id, start_date, end_date, job_id, department_id FROM job_history; DROP TABLE job_history; RENAME temporary TO job_history;
前述の例の場合、job_history
表に定義されている整合性制約は失われます。これらの整合性制約は、ALTER
TABLE
文を使用して、新しいjob_history
表に再定義する必要があります。
REVOKE
文を使用すると、次の操作を実行できます。
AS
SYSASM
と認証されたユーザーは、この文を使用すると、システム権限SYSASM
、SYSOPER
およびSYSDBA
を、現行ノードの自動ストレージ管理パスワード・ファイルのユーザーから取り消すことができます。
システム権限を取り消すには、Admin
Option
付きの権限が必要です。
ロールを取り消すには、Admin
Option
付きのロールが必要です。なお、GRANT
ANY
ROLE
システム権限を持っている場合は、ロールを自由に取り消すことができます。
オブジェクト権限を取り消すには、以前にユーザーとロールにオブジェクト権限を付与している、またはGRANT
ANY
OBJECT
PRIVILEGE
システム権限を持っている必要があります。後者の場合は、オブジェクト所有者によって付与されたかまたは所有者の役割を持つユーザー(GRANT
ANY
OBJECT
PRIVILEGE
を持つユーザー)によって付与されたオブジェクト権限を取り消すことができます。ただし、With
Grant
Option
によって付与されたオブジェクト権限を取り消すことはできません。
REVOKE
文によって取り消すことができる権限およびロールは、GRANT
文によって直接付与されているものにかぎられます。この句では、次の権限を取り消すことはできません。
(revoke_system_privileges::=、revoke_object_privileges::=を参照)
(grantee_clause::=を参照)
(on_object_clause::=、grantee_clause::=を参照)
システム権限を取り消すには、次の句を使用します。
取り消すシステム権限を指定します。システム権限のリストは、表18-1を参照してください。
ユーザーのシステム権限を取り消す場合、ユーザーの権限ドメインからその権限が取り消されます。この取消しはすぐに有効になるため、このユーザーはその権限を使用できなくなります。
ロールのシステム権限を取り消す場合、ロールの権限ドメインからその権限が取り消されます。この取消しはすぐに有効になるため、そのロールが使用可能となっている場合でも、この権限は使用できません。また、そのロールが付与されている他のユーザーは、ロールを使用可能にしても、その権限を使用できなくなります。
PUBLICのシステム権限
を取り消す場合、PUBLIC
を介して権限を付与されている各ユーザーの権限ドメインからその権限が取り消されます。この取消しはすぐに有効になるため、ユーザーは権限を使用できなくなります。ただし、直接またはロールを介して権限が付与されているユーザーからは、権限を取り消すことはできません。
Oracle Databaseには、すべてのシステム権限を一度に指定できるショートカットがあります。ALL
PRIVILEGES
を指定すると、表18-1に示すすべてのシステム権限を取り消すことができます。
取り消す権限のリストに権限を指定できるのは1回のみです。
取り消すロールを指定します。
ユーザーからロールを取り消すと、ユーザーによるロールの使用が禁止されます。そのロールが使用可能となっている場合に、ロールの権限ドメインの権限が使用可能な場合はその権限を使用できます。ただし、ユーザーが後からロールを使用可能にできません。
他のロールからロールを取り消すと、取消し側ロールの権限ドメインから、取り消されたロールの権限ドメインが削除されます。取り消されたロールの権限を付与され、そのロールの権限が使用可能になっているユーザーは、そのロールの権限が使用可能な間は、取り消されたロールの権限ドメインの権限を引き続き使用できます。ただし、取り消された権限を付与されていても、ロールの取消し操作の後でそれを使用可能にしたユーザーは、取り消されたロールの権限ドメインの権限を使用できません。
PUBLIC
のロールを取り消すと、PUBLIC
を介してロールが付与されているすべてのユーザーに対して、そのロールが使用禁止にされます。そのロールを使用可能としているユーザーは、権限ドメインの権限が使用可能であるかぎり、権限ドメインでその権限を引き続き使用できます。ただし、ユーザーが後からロールを使用可能にすることはできません。直接またはロールを介して権限が付与されているユーザーからは、ロールを取り消すことはできません。
取り消すロールのリストにシステム・ロールを指定できるのは1回のみです。事前定義されているロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
FROM
grantee_clause
を指定すると、システム権限、ロールまたはオブジェクト権限が取り消されるユーザーまたはロールを識別できます。
PUBLIC
を指定すると、すべてのユーザーから権限を取り消すことができます。
オブジェクト権限を取り消すには、次の句を使用します。
取り消すオブジェクト権限を指定します。表18-2に示すどのオブジェクト権限でも指定できます。
ユーザーのオブジェクト権限を取り消すと、ユーザーの権限ドメインからその権限が取り消されます。この取消しはすぐに有効になるため、このユーザーはその権限を使用できなくなります。
REFERENCES
オブジェクト権限を取り消す場合、CASCADE
CONSTRAINTS
句も指定する必要があります。
ロールのオブジェクト権限を取り消すと、ロールの権限ドメインからその権限が取り消されます。この取消しはすぐに有効になるため、そのロールが使用可能となっている場合でも、この権限は使用できません。ロールが付与されている他のユーザーは、ロールを使用可能にした場合でも、権限を使用できなくなります。
PUBLICのオブジェクト権限
を取り消すと、PUBLIC
を介して権限を付与されている各ユーザーの権限ドメインからその権限が取り消されます。この取消しはすぐに有効になるため、それらのすべてのユーザーは、その権限を使用できなくなります。ただし、直接またはロールを介して権限が付与されているユーザーからは、権限を取り消すことはできません。
ALL
を指定すると、ユーザーまたはロールに付与されているすべてのオブジェクト権限を取り消すことができます(キーワードPRIVILEGES
はセマンティクスを明確にするためのものであり、指定は任意です。)
オブジェクトに権限が付与されていない場合、処理は行われず、エラーも戻りません。
取り消す権限のリストに権限を指定できるのは1回のみです。FROM
句にユーザー、ロールまたはPUBLIC
を指定できるのは1回のみです。
この句は、REFERENCES
権限またはALL
[PRIVILEGES
]を取り消すときにのみ適用されます。取消し側でREFERENCES
権限(ALL
[PRIVILEGES
]を付与して明示的または暗黙的に付与された権限)を使用して定義した参照整合性制約を削除します。
FORCE
を指定すると、表または型に依存するユーザー定義型オブジェクトで、EXECUTE
オブジェクト権限を取り消すことができます。表に依存するユーザー定義型オブジェクトでは、FORCE
を使用してEXECUTE
オブジェクト権限を取り消します。
FORCE
を指定した場合、すべての権限が取り消されますが、すべての依存するオブジェクトにはINVALID
のマークが付けられ、依存表のデータにはアクセスできなくなります。また、すべての依存するファンクション索引には、UNUSABLE
のマークが付けられます。必要な型の権限を再付与した場合、表に対して再度妥当性チェックが行われます。
on_object_clause
を指定すると、権限を取り消すオブジェクトを識別できます。
オブジェクト権限を取り消すオブジェクトを指定します。取り消すことができるオブジェクトは次のとおりです。
オブジェクトをschema
で修飾しなかった場合、そのオブジェクトは自分のスキーマ内にあるとみなされます。
システム権限のGrant
Option
の有無にかかわらず、SELECT
オブジェクト権限をマテリアライズド・ビューまたは表を含むマテリアライズド・ビューから取り消すと、そのマテリアライズド・ビューは無効になります。
システム権限のGRANT
OPTION
の有無にかかわらず、マテリアライズド・ビューのマスター表のいずれかにおけるSELECT
オブジェクト権限を取り消すと、そのマテリアライズド・ビューとそれに含まれる表の両方またはマテリアライズド・ビューが無効になります。
権限を取り消すディレクトリ・オブジェクトを指定します。directory_name
はschema
で修飾できません。このオブジェクトはディレクトリである必要があります。
JAVA
句を使用すると、権限を取り消すJavaソースまたはリソース・スキーマ・オブジェクトを指定できます。
次の文は、ユーザーhr
およびoe
のDROP
ANY
TABLE
システム権限を取り消します。
REVOKE DROP ANY TABLE FROM hr, oe;
この結果、hr
およびoe
は他のユーザーのスキーマに定義されている表を削除できなくなります。
次の文は、ユーザーsh
のロールdw_manager
を取り消します。
REVOKE dw_manager FROM sh;
この結果、sh
ユーザーはdw_manager
ロールを使用可能にできなくなります。
次の文は、ロールdw_manager
のCREATE
TABLESPACE
システム権限を取り消します。
REVOKE CREATE TABLESPACE FROM dw_manager;
ロールdw_manager
を使用可能にしても、ユーザーは表領域を作成できません。
次の文は、ロールdw_manager
からロールdw_user
を取り消します。
REVOKE dw_user FROM dw_manager;
この結果、dw_user
ロールの権限はdw_manager
に付与されなくなります。
次の文は、orders
表に対するDELETE
、INSERT
、SELECT
およびUPDATE
権限をユーザーhr
に付与します。
GRANT ALL ON orders TO hr;
次の文は、ユーザーhr
から表orders
に対するDELETE
権限を取り消します。
REVOKE DELETE ON orders FROM hr;
次の文は、ユーザーhr
の表orders
に対する残りのすべての権限を取り消します。
REVOKE ALL ON orders FROM hr;
次の文は、ロールpublic
に権限を付与することによって、すべてのユーザーにビューemp_details_view
に対するSELECT
権限およびUPDATE
権限を付与します。
GRANT SELECT, UPDATE ON emp_details_view TO public;
次の文は、すべてのユーザーからemp_details_view
に対するUPDATE
権限を取り消します。
REVOKE UPDATE ON emp_details_view FROM public;
ユーザーは、emp_details_view
ビューへの問合せはできますが、更新はできなくなります。ただし、emp_details_view
に対するUPDATE
権限も任意のユーザーに直接またはロールを介して付与している場合は、これらのユーザーはその権限を保持します。
次の文は、ユーザーoe
にスキーマhr
内のdepartments_seq
順序に対するSELECT
権限を付与します。
GRANT SELECT ON hr.departments_seq TO oe;
次の文は、oe
からdepartments_seq
に対するSELECT
権限を取り消します。
REVOKE SELECT ON hr.departments_seq FROM oe;
ただし、ユーザーhr
がdepartments
に対するSELECT
権限をsh
に付与している場合、sh
は、hr
からの権限付与によってdepartments
を使用できます。
次の文は、oe
に、スキーマhr
内のemployees
表に対するREFERENCES
権限およびUPDATE
権限を付与します。
GRANT REFERENCES, UPDATE ON hr.employees TO oe;
ユーザーoe
は、REFERENCES
権限を使用して、hr
スキーマ内のemployees
表を参照するdependent
表の制約を定義できます。
CREATE TABLE dependent (dependno NUMBER, dependname VARCHAR2(10), employee NUMBER CONSTRAINT in_emp REFERENCES hr.employees(employee_id) );
CASCADE
CONSTRAINTS
句を指定した次の文を発行することによって、oe
のhr.employees
に対するREFERENCES
権限を取り消すことができます。
REVOKE REFERENCES ON hr.employees FROM oe CASCADE CONSTRAINTS;
oe
のhr.employees
に対するREFERENCES
権限を取り消した場合、oe
は制約を定義する権限が必要になるため、in_emp
制約が自動的に削除されます。
ただし、oe
が他のユーザーからhr.employees
に対するREFERENCES
権限を付与されている場合は、その制約は削除されません。他のユーザーから権限付与されたため、oe
は制約に対して必要な権限を保持しています。
次の文は、hr
のbfile_dir
ディレクトリに対するREAD
オブジェクト権限を取り消します。
REVOKE READ ON DIRECTORY bfile_dir FROM hr;
データベース管理者によってユーザーsh
にGRANT
ANY
OBJECT
PRIVILEGE
が付与されているとします。ユーザーhr
が、employees
表に対するUPDATE権限をユーザーoe
に付与します。
CONNECT hr GRANT UPDATE ON employees TO oe WITH GRANT OPTION;
これによって、オブジェクト権限を別のユーザーに付与する権限がユーザーoe
に付与されます。
CONNECT oe GRANT UPDATE ON hr.employees TO pm;
oe
にはhr
によって権限が与えられたため、GRANT
ANY
OBJECT
PRIVILEGE
が付与されているユーザーsh
は、ユーザーhr
にかわってユーザーoe
のUPDATE権限を取り消すことができます。
CONNECT sh REVOKE UPDATE ON hr.employees FROM oe;
pm
に権限を付与したのがオブジェクトの所有者(hr
)、ユーザーsh
またはGRANT
ANY
OBJECT
PRIVILEGE
を持つ他のユーザーではなく、ユーザーoe
であったため、ユーザーsh
は、ユーザーpm
のUPDATE権限を明示的に取り消すことはできません。ただし、前述の文は、連鎖的な取消しを行い、取り消された権限に依存するすべての権限を取り消します。そのため、pm
のオブジェクト権限も暗黙的に取り消されます。
ROLLBACK
文を使用すると、現行のトランザクションで実行された処理を取り消すことができます。また、インダウト分散トランザクションで実行された処理を手動で取り消すこともできます。
参照:
|
現行のトランザクションをロールバックする場合、権限は不要です。
コミットしたインダウト分散トランザクションを手動でロールバックする場合は、FORCE
TRANSACTION
システム権限が必要です。他のユーザーがコミットしたインダウト分散トランザクションを手動でロールバックする場合は、FORCE
ANY
TRANSACTION
システム権限が必要です。
WORK
キーワードの指定は任意です。このキーワードは、SQL規格との互換性のために提供されています。
現行のトランザクションをロールバックするセーブポイントを指定します。この句を指定しない場合、ROLLBACK
文によってトランザクション全体がロールバックされます。
TO
SAVEPOINT
句を指定しないでROLLBACK
コマンドを実行すると、次の処理が行われます。
TO
SAVEPOINT
句を指定してROLLBACK
コマンドを実行すると、次の処理が行われます。
インダウト・トランザクションは、セーブポイントまで手動でロールバックできません。
FORCE
を指定すると、インダウト分散トランザクションを手動でロールバックできます。このトランザクションは、ローカル・トランザクションIDまたはグローバル・トランザクションIDを含むstring
で識別されます。このトランザクションのIDを確認する場合は、データ・ディクショナリ・ビューDBA_2PC_PENDING
を問い合せます。
FORCE
句を指定したROLLBACK
文では、指定したトランザクションのみがロールバックされます。この文は、現行のトランザクションには影響しません。
次の文は、現行のトランザクション全体をロールバックします。
ROLLBACK;
次の文は、現行のトランザクションをセーブポイントbanda_sal
にロールバックします。
ROLLBACK TO SAVEPOINT banda_sal;
前述の例の詳細は、「セーブポイントの作成例:」を参照してください。
次の文は、インダウト分散トランザクションを手動でロールバックします。
ROLLBACK WORK FORCE '25.32.87';
|
![]() Copyright © 1996, 2008, Oracle Corporation. All Rights Reserved. |
|