varje SQL – fråga som du skickar till en server måste gå igenom tre (fyra-vid SELECT) steg. Först och främst kommer Oracle att söka efter en matchande SQL-hash i bibliotekets Cache. Om hashen hittas kommer den bara att hämta den tillhörande förklaringsplanen och exekvera den. Om inte, åberopas en hård Tolkning – > det betyder att följande steg ska utföras.
- tolka
- syntaxkontroll
- semantikkontroll
- behörighetskontroll
- BIND
- ersätt bind / värdvariabler med faktiska värden
- EXEC
- faktiskt utförande baserat på en förklaringsplan
- hämta (endast SELECT-satser)
- returnerar en resultatuppsättning till en användare
låt mig förklara varje fas i följande exempel.
du körde den här frågan:
SELECT *FROM employee;
servern processen kommer att generera en hash för frågor SQL-fråga. Hash är ett hexadecimalt värde som genereras baserat på texten i SQL-frågan. Här kommer den mycket viktiga delen!! Även den minsta förändringen (Stora till små bokstäver och vice versa; lägga till/ta bort ett mellanslag; …) kommer att ändra hash och därför kan det generera en hård parse (mer om hård parse vs soft parse nedan). Du måste vara mycket försiktig och försöka hålla dig till en enda kod – det är därför procedurer fungerar bäst (på toppen av det – de använder oftast bindningsvariabler som genererar identiska frågor i Oracles ögon).
du kan enkelt verifiera det på egen hand genom att utföra frågorna nedan:
-- 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.
när hashen har genererats kontrollerar Oracle om den här frågan redan utfördes i det här fallet. Hur? Genom att kontrollera om hash redan finns i SQL-området.
förutsatt att den här frågan inte är tillgänglig ännu, kommer det att finnas ett SQL-område Skapat med hashvärdet för den här frågan och Oracle kommer att initiera det första steget i frågebehandling och det är PARSE.
- under syntaxkontrollen kommer Oracle att kontrollera frågan om den är syntaktiskt korrekt (välj istället för Välj; rätt ordning på kommandon -> välj * från tabellordning efter col1 där col2 = ’John’; etc).
- nästa steg är semantik kontrollerar där Oracle verifierar om kolumnnamnen och objektnamnen är korrekta. Hur? Genom att korsa dem med Data Dictionary Cache
- i det sista steget i PARSE stage kontrollerar Oracle om användaren/applikationen har rätt behörighet att komma åt frågade objekt.
när detta är över är SQL – området giltigt och ett annat verktyg i Oracle som heter OPTIMIZER kommer att generera en exekveringsplan-det betyder att OPTIMERAREN bestämmer hur frågan ska utföras. När den bästa exekveringsplanen har valts binder Oracle alla variabler och fortsätter till det tredje steget – exekvering.
vad kommer att hända här? Oracle kommer att läsa datablock relaterade till frågade objekt och föra dem till buffertcache (om de inte presenteras där ännu. Om de är där kommer Oracle inte att läsa dem igen!). Denna process kommer att generera I / O (som, som jag nämnde i artikeln Computing Architecture, är mycket långsam jämfört med att läsa från minnet). Jag kommer att stanna här ett tag och betona I/O-generationen. När det gäller mjuk parse läses Alla data från minnet (buffertcache) vilket är mycket snabbare än att läsa dem från en disk. Det är därför du måste sträva efter att återvinna/återanvända dina frågor så mycket som möjligt. Varje ändring av en fråga kommer att generera en ny hash och kommer därför troligen att generera I/O. Allt detta hanteras fortfarande av serverprocessen.
nu, att data redan finns i minnet (buffertcache) SELECT-satsen bearbetas och det sista steget (FETCH) utlöses och resultatuppsättningen returneras tillbaka till användaren.
om samma fråga körs igen genereras hash och eftersom SQL-området för den hash redan finns, hoppas PARSE stage över och endast EXEC och FETCH körs.
