EXPLAIN PLAN
zal de syntaxis en semantiek van bijna alle typen SQL-instructies controleren. En in tegenstelling tot DBMS_SQL.PARSE het zal impliciet niets uitvoeren.
Het doel van het explain plan is om te laten zien hoe Oracle een statement zal uitvoeren. Als een neveneffect van het genereren van het plan moet het ook de syntaxis, privileges controleren en in het algemeen alles doen, behalve het daadwerkelijk uitvoeren van de instructie. Het uitlegplan zelf is zinloos en kan worden genegeerd, de instructie wordt alleen uitgevoerd om te controleren op eventuele fouten. Zolang er geen fouten zijn, is de verklaring geldig.
De onderstaande PL/SQL-blokken controleren bijvoorbeeld de geldigheid van een SELECT statement en een CREATE TABLE uitspraak. Ze werken foutloos, dus de syntaxis is in orde.
begin
execute immediate 'explain plan for select * from dual';
end;
/
begin
execute immediate 'explain plan for create table just_some_table(a number)';
end;
/
Het uitvoeren van een slechte verklaring zal een fout genereren. In ten minste dit ene testgeval genereert het dezelfde fout alsof het statement op zichzelf is uitgevoerd.
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
Het syntaxisdiagram in de handleiding geeft aan dat het voor alles moet werken verklaringen. Het lijkt er echter op dat er op zijn minst een paar typen instructies niet werken, zoals 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
Een beetje off-topic - probeer je een volledig generieke SQL-interface te bouwen, zoals een privé SQL Fiddle gebouwd in PL/SQL? Moet u zich zorgen maken over zaken als voorkomen dat gebruikers proberen bepaalde typen instructie uit te voeren en ervoor zorgen dat er geen puntkomma's achteraan staan? Als dat zo is, kan ik de vraag bewerken om te helpen met enkele van die moeilijke dynamische SQL-taken.