elke SQL-query die u naar een server verzendt, moet drie (vier – in het geval van SELECT) fasen doorlopen. Allereerst, Oracle zal zoeken naar een overeenkomende SQL hash in de bibliotheek Cache. Als de hash wordt gevonden zal het gewoon het bijbehorende explain plan ophalen en uitvoeren. Zo niet, dan wordt een harde parse aangeroepen – > dat betekent dat de volgende stappen moeten worden uitgevoerd.

1. PARSE
   • syntaxis controleren
   • semantiek controleren
   • machtigingen controleren
2. BIND
   • vervangen bind/host-variabelen met de werkelijke waarden
3. EXEC
   • daadwerkelijke uitvoering op basis van een explain plan
4. FETCH (SELECT-instructies alleen)
   • geeft als resultaat het resultaat van een gebruiker

Laat het me uitleggen van elke fase in het volgende voorbeeld.

u hebt deze query uitgevoerd:

SELECT *FROM employee;

het serverproces zal een hash genereren voor de problemen SQL query. De hash is een hexadecimale waarde die wordt gegenereerd op basis van de tekst van de SQL-query. Hier komt het zeer belangrijke deel!! Zelfs de geringste verandering (bovenste naar kleine letters en vice versa; toevoegen/verwijderen van een spatie; …) zal de hash te veranderen en daarom kan het een harde parse genereren (meer op de harde parse vs zachte parse hieronder). Je moet heel voorzichtig zijn en proberen je aan één code te houden – dat is de reden waarom procedures het beste werken (bovenop dat – ze gebruiken meestal bind variabelen die identieke query ‘ s genereren in de ogen van Oracle).

u kunt het eenvoudig zelf verifiëren door de onderstaande query ‘ s uit te voeren:

-- first run this querySELECT * FROM dual;-- then run this one again with all uppercase lettersSELECT * FROM DUAL;-- check the sql hashes SELECT sql_id, sql_text, hash_valueFROM v$sqlWHERE 1=1AND lower(sql_text) LIKE '%select%from dual%'; sql_id | sql_text | hash_value--------------------------------------------------0x735fvggtnu6 | SELECT * FROM DUAL | 37411111103vyt9wdmca69b | SELECT * FROM dual | 1724193067-- As you can see Oracle evaluated it as two different queries.

zodra de hash is gegenereerd, controleert Oracle of deze query in dit geval al is uitgevoerd. Hoe? Door te controleren of de hash al bestaat in het sql gebied.

ervan uitgaande dat deze query nog niet beschikbaar is, zal er een SQL-gebied worden aangemaakt met de hash-waarde voor deze query en zal het Oracle de eerste fase van query-verwerking starten en dat is ontleden.

• tijdens de syntaxiscontrole zal Oracle de query controleren of het syntactisch correct is (selecteer in plaats van selecteer; de juiste volgorde van opdrachten -> selecteer * uit tabel volgorde door col1 waarbij col2 = ‘John’; etc).
• de volgende stap is semantiekcontroles waarbij Oracle controleert of de kolomnamen en objectnamen correct zijn. Hoe? Door ze te kruisen met Data Dictionary Cache
• in de laatste stap van PARSE stage, controleert Oracle of de gebruiker/toepassing de juiste rechten heeft om toegang te krijgen tot opgevraagde objecten.

zodra dit voorbij is, is het sql – gebied geldig en een ander hulpmiddel in Oracle genaamd OPTIMIZER zal een uitvoeringsplan genereren-dat betekent dat de OPTIMIZER zal beslissen hoe de query zal worden uitgevoerd. Nadat het beste uitvoeringsplan is geselecteerd, bindt Oracle alle variabelen en gaat over tot de derde stap – uitvoering.

wat gaat er hier gebeuren? Oracle zal Data blokken met betrekking tot queried objecten te lezen en breng ze naar buffer cache(als ze er nog niet worden gepresenteerd. Als ze er zijn, zal Oracle ze niet meer lezen!). Dit proces zal I/O genereren (wat, zoals ik al zei in het artikel Computing Architecture, erg traag is in vergelijking met het lezen van het geheugen). Ik zal hier een tijdje stoppen en de nadruk leggen op de I/O generatie. In het geval van zachte parse, worden alle gegevens gelezen van het geheugen (buffer cache) die veel sneller is dan het lezen van hen van een schijf. Daarom moet je ernaar streven om je query ‘ s zoveel mogelijk te recyclen/hergebruiken. Elke wijziging van een query zal een nieuwe hash genereren en zal daarom hoogstwaarschijnlijk I/O genereren. dit alles wordt nog steeds afgehandeld door het serverproces.

nu, dat de gegevens al in het geheugen (buffer cache) de SELECT instructie wordt verwerkt en de laatste fase (FETCH) wordt geactiveerd en de result set wordt teruggestuurd naar de gebruiker.

als dezelfde query opnieuw wordt uitgevoerd, wordt de hash gegenereerd en aangezien het sql-gebied voor die hash al bestaat, wordt PARSE stage overgeslagen en worden alleen EXEC en FETCH uitgevoerd.