Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Även om statisk SQL fungerar bra i många situationer finns det en klass med program där dataåtkomsten inte kan fastställas i förväg. Anta till exempel att ett kalkylblad tillåter en användare att ange en fråga, som kalkylbladet sedan skickar till DBMS för att hämta data. Innehållet i den här frågan kan uppenbarligen inte vara känt för programmeraren när kalkylbladsprogrammet skrivs.
Dynamisk körning
För att lösa det här problemet använder kalkylbladet en form av inbäddad SQL som kallas dynamisk SQL. Till skillnad från statiska SQL-instruktioner, som är hårdkodade i programmet, kan dynamiska SQL-instruktioner skapas vid körning och placeras i en värdvariabel för sträng. De skickas sedan till DBMS för bearbetning. Eftersom DBMS måste generera en åtkomstplan vid körning för dynamiska SQL-instruktioner är dynamisk SQL vanligtvis långsammare än statisk SQL. När ett program som innehåller dynamiska SQL-instruktioner kompileras tas inte de dynamiska SQL-uttrycken bort från programmet, som i statisk SQL. I stället ersätts de av ett funktionsanrop som skickar -instruktionen till DBMS. statiska SQL-instruktioner i samma program behandlas normalt.
Det enklaste sättet att köra en dynamisk SQL-instruktion är med en EXECUTE IMMEDIATE-instruktion. Den här instruktionen skickar SQL-instruktionen till DBMS för kompilering och körning.
En nackdel med EXECUTE IMMEDIATE-instruktionen är att DBMS måste gå igenom vart och ett av de fem stegen för att bearbeta en SQL-instruktion varje gång -instruktionen körs. De omkostnader som ingår i den här processen kan vara betydande om många instruktioner körs dynamiskt, och det är slöseri om dessa instruktioner är liknande.
Förberedd exekvering
För att hantera ovanstående situation erbjuder dynamisk SQL en optimerad form av körning som kallas förberedd körning, som använder följande steg:
Programmet konstruerar en SQL-instruktion i en buffert, precis som för EXECUTE IMMEDIATE-instruktionen. I stället för värdvariabler kan ett frågetecken (?) ersättas med en konstant var som helst i instruktionstexten för att indikera att ett värde för konstanten kommer att anges senare. Frågetecknet anropas som en parametermarkör.
Programmet skickar SQL-instruktionen till DBMS med en PREPARE-instruktion som begär att DBMS parsar, validerar och optimerar -instruktionen och genererar en körningsplan för den. Programmet använder sedan en EXECUTE-instruktion (inte en EXECUTE IMMEDIATE-instruktion) för att köra PREPARE-instruktionen vid ett senare tillfälle. Den skickar parametervärden för -instruktionen via en särskild datastruktur som kallas SQL Data Area eller SQLDA.
Programmet kan använda EXECUTE-instruktionen upprepade gånger och ange olika parametervärden varje gång den dynamiska instruktionen körs.
Förberedd körning är fortfarande inte samma sak som statisk SQL. I statisk SQL sker de första fyra stegen för bearbetning av en SQL-instruktion vid kompileringstillfället. I den förberedda körningen utförs de här stegen fortfarande i samband med körning, men de görs bara en gång. Utförandet av planen sker endast när EXECUTE anropas. Det här beteendet hjälper till att eliminera några av prestandanackdelarna som är inneboende i arkitekturen för dynamisk SQL.