EXPLAIN PLAN
kommer att kontrollera syntaxen och semantiken för nästan alla typer av SQL-satser. Och till skillnad från DBMS_SQL.PARSE det kommer inte implicit att köra någonting.
Poängen med förklaringsplanen är att visa hur Oracle kommer att utföra ett uttalande. Som en bieffekt av att generera planen måste den också kontrollera syntax, privilegier och i allmänhet göra allt utom att faktiskt köra uttalandet. Förklaringsplanen i sig är meningslös och kan ignoreras, uttalandet körs endast för att kontrollera eventuella fel. Så länge det inte finns några fel är påståendet giltigt.
Till exempel kontrollerar PL/SQL-blocken nedan giltigheten av en SELECT och en CREATE TABLE påstående. De körs utan fel så syntaxen är bra.
begin
execute immediate 'explain plan for select * from dual';
end;
/
begin
execute immediate 'explain plan for create table just_some_table(a number)';
end;
/
Att köra ett dåligt uttalande kommer att generera ett fel. I åtminstone detta testfall genererar den samma fel som om satsen kördes av sig själv.
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
Syntaxdiagrammet i manualen antyder att det ska köras för alla uttalanden. Det verkar dock finnas åtminstone ett fåtal påståendetyper som inte fungerar, till exempel 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
Lite off-topic - försöker du bygga ett helt generiskt SQL-gränssnitt, som en privat SQL Fiddle inbyggd i PL/SQL? Behöver du oroa dig för saker som att förhindra användare från att försöka köra vissa typer av uttalanden och se till att det inte finns några efterföljande semikolon? I så fall kan jag redigera frågan för att hjälpa till med några av dessa svåra dynamiska SQL-uppgifter.