11g リリース1（11.1）
E05750-03
 目次 |
 索引 |
| 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_Cnという形式の名前が自動的に割り当てられます。この場合の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. |
|