EXPLAIN PLAN
ほぼすべてのタイプのSQLステートメントの構文とセマンティクスをチェックします。また、DBMS_SQL.PARSE
とは異なります 暗黙的に何も実行されません。
Explain Planのポイントは、Oracleがステートメントを実行する方法を示すことです。プランを生成することの副作用として、構文、特権もチェックし、通常、ステートメントを実際に実行する以外のすべてを実行する必要があります。 Explainプラン自体は無意味であり、無視できます。ステートメントは、エラーをチェックするためにのみ実行されます。エラーがない限り、ステートメントは有効です。
たとえば、以下のPL / SQLブロックは、SELECT
の有効性をチェックします。 ステートメントとCREATE TABLE
声明。エラーなしで実行されるため、構文は問題ありません。
begin
execute immediate 'explain plan for select * from dual';
end;
/
begin
execute immediate 'explain plan for create table just_some_table(a number)';
end;
/
不正なステートメントを実行すると、エラーが発生します。少なくともこの1つのテストケースでは、ステートメントが単独で実行された場合と同じエラーが生成されます。
begin
execute immediate 'explain plan for select * from this_table_does_not_exist';
end;
/
ORA-00942: table or view does not exist
ORA-06512: at line 2
マニュアルのシンタックスダイアグラムは、すべてで実行する必要があることを示しています。 ステートメント。ただし、ALTER SESSION
など、機能しないステートメントタイプが少なくともいくつかあるようです。 。
begin
execute immediate 'explain plan for alter session set optimizer_features_enable = ''11.2.0.4''';
end;
/
ORA-00900: invalid SQL statement
ORA-06512: at line 2
少しトピックから外れています-PL/SQLに組み込まれているプライベートSQLフィドルのように、完全に汎用的なSQLインターフェイスを構築しようとしていますか?ユーザーが特定のステートメントタイプを実行しようとするのを防ぎ、末尾のセミコロンがないことを確認するなどのことを心配する必要がありますか?もしそうなら、私はそれらの難しい動的SQLタスクのいくつかを助けるために質問を編集することができます。