EXPLAIN PLAN
vil kontrollere syntaksen og semantikken for næsten alle typer SQL-sætninger. Og i modsætning til DBMS_SQL.PARSE det vil ikke implicit udføre noget.
Pointen med forklaringsplanen er at vise, hvordan Oracle vil udføre en erklæring. Som en bivirkning ved at generere planen skal den også kontrollere syntaks, privilegier og generelt gøre alt undtagen faktisk at køre sætningen. Selve forklaringsplanen er meningsløs og kan ignoreres, sætningen køres kun for at kontrollere for eventuelle fejl. Så længe der ikke er fejl, er erklæringen gyldig.
For eksempel kontrollerer PL/SQL-blokkene nedenfor gyldigheden af en SELECT sætning og en CREATE TABLE udmelding. De kører uden fejl, så syntaksen er fin.
begin
execute immediate 'explain plan for select * from dual';
end;
/
begin
execute immediate 'explain plan for create table just_some_table(a number)';
end;
/
At køre en dårlig erklæring vil generere en fejl. I mindst dette ene testtilfælde genererer den den samme fejl, som hvis sætningen blev kørt af sig selv.
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
Syntaksdiagrammet i manualen antyder, at det skal køre for alle udsagn. Der ser dog ud til at være mindst et par sætningstyper, der ikke virker, såsom 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
Lidt off-topic - forsøger du at bygge en fuldstændig generisk SQL-grænseflade, som en privat SQL Fiddle indbygget i PL/SQL? Har du brug for at bekymre dig om ting som at forhindre brugere i at forsøge at køre bestemte sætningstyper og sikre, at der ikke er efterstillede semikoloner? Hvis ja, kan jeg redigere spørgsmålet for at hjælpe med nogle af de svære dynamiske SQL-opgaver.