EXPLAIN PLAN
sprawdzi składnię i semantykę prawie wszystkich typów instrukcji SQL. I w przeciwieństwie do DBMS_SQL.PARSE nie wykona niczego domyślnie.
Celem planu wyjaśniania jest pokazanie, w jaki sposób Oracle wykona instrukcję. Jako efekt uboczny generowania planu musi również sprawdzić składnię, uprawnienia i ogólnie zrobić wszystko oprócz faktycznego uruchomienia instrukcji. Sam plan wyjaśniania jest bezcelowy i można go zignorować, instrukcja jest uruchamiana tylko w celu sprawdzenia ewentualnych błędów. Dopóki nie ma błędów, oświadczenie jest ważne.
Na przykład poniższe bloki PL/SQL sprawdzają poprawność SELECT oświadczenie i CREATE TABLE oświadczenie. Działają bezbłędnie, więc składnia jest w porządku.
begin
execute immediate 'explain plan for select * from dual';
end;
/
begin
execute immediate 'explain plan for create table just_some_table(a number)';
end;
/
Uruchomienie złej instrukcji wygeneruje błąd. Przynajmniej w tym jednym przypadku testowym generuje ten sam błąd, jakby instrukcja została uruchomiona sama.
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
Diagram składni w podręczniku sugeruje, że powinien działać dla wszystkich sprawozdania. Wydaje się jednak, że istnieje co najmniej kilka typów instrukcji, które nie działają, takie jak 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
Trochę nie na temat - czy próbujesz zbudować całkowicie ogólny interfejs SQL, jak prywatny SQL Fiddle zbudowany w PL/SQL? Czy musisz się martwić o takie rzeczy, jak uniemożliwienie użytkownikom prób uruchomienia niektórych typów instrukcji i upewnienie się, że nie ma końcowych średników? Jeśli tak, mogę edytować pytanie, aby pomóc w niektórych trudnych zadaniach dynamicznego SQL.
