hver forespørgsel, du sender til en server, skal gennemgå tre (fire – i tilfælde af SELECT) faser. Først og fremmest vil Oracle søge efter en matchende hash i bibliotekets Cache. Hvis hash er fundet det vil bare hente den tilhørende forklare planen og udfører det. Hvis ikke, påberåbes en hård parse – > det betyder, at følgende trin skal udføres.
- PARSE
- syntakskontrol
- semantikcheck
- privilegier check
- BIND
- erstat bind / host variabler med faktiske værdier
- udførelse
- faktisk udførelse baseret på en forklaringsplan
- Hent (vælg kun udsagn)
- returnerer et resultatsæt til en bruger
lad mig forklare hver fase i det følgende eksempel.
du udførte denne forespørgsel:
SELECT *FROM employee;
serveren proces vil generere en hash for spørgsmål spørgsmål. Hash er en værdi, der genereres baseret på teksten i forespørgslen. Her kommer den meget vigtige del!! Selv den mindste ændring (store til små bogstaver og omvendt; tilføjelse/fjernelse af et mellemrum; …) vil ændre hash og derfor kan det generere en hård parse (mere på den hårde parse vs blød parse nedenfor). Du skal være meget forsigtig og forsøge at holde sig til en kode kun – det er derfor, procedurer fungerer bedst (på toppen af det – de bruger for det meste bindevariabler, der genererer identiske forespørgsler i Oracle ‘ s øjne).
du kan nemt bekræfte det på egen hånd ved at udføre nedenstående forespørgsler:
-- 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 hash er genereret, kontrollerer Oracle, om denne forespørgsel allerede blev udført i dette tilfælde. Hvordan? Ved at kontrollere, om hash allerede findes i området.
hvis vi antager, at denne forespørgsel ikke er tilgængelig endnu, vil der blive oprettet et KVL-område med hashværdien for denne forespørgsel, og oraklet vil starte den første fase af forespørgselsbehandling, og det er PARSE.
- under syntakskontrollen kontrollerer Oracle forespørgslen, om den er syntaktisk korrekt (vælg i stedet for Vælg; den korrekte rækkefølge af kommandoer- > vælg * fra tabelrækkefølge efter col1 hvor col2 = ‘John’; etc).
- det næste trin er semantik kontrol, hvor Oracle kontrollerer, om kolonnenavne og objektnavne er korrekte. Hvordan? Ved at krydschecke dem med Data Dictionary Cache
- i det sidste trin i PARSE-fasen kontrollerer Oracle, om brugeren/applikationen har korrekte tilladelser til at få adgang til forespurgte objekter.
når dette er overstået, er området gyldigt, og et andet værktøj i Oracle, der hedder optimering, genererer en eksekveringsplan – det betyder, at optimatoren bestemmer, hvordan forespørgslen skal udføres. Når den bedste eksekveringsplan er valgt, binder Oracle alle variabler og fortsætter til det tredje trin – udførelse.
Hvad skal der ske her? Oracle vil læse datablokke relateret til forespurgte objekter og bringe dem til buffer cache (hvis de ikke er præsenteret der endnu. Hvis de er der, vil Oracle ikke læse dem igen!). Denne proces genererer I / O (som, som jeg nævnte i artiklen Computing Architecture, er meget langsom sammenlignet med læsning fra hukommelsen). Jeg vil stoppe her et stykke tid og understrege I/O-generationen. I tilfælde af soft parse læses alle data fra hukommelsen (buffercache), hvilket er meget hurtigere end at læse dem fra en disk. Derfor er du nødt til at stræbe efter at genbruge/genbruge dine forespørgsler så meget som muligt. Hver ændring af en forespørgsel vil generere en ny hash og vil derfor sandsynligvis generere I/O. alt dette håndteres stadig af serverprocessen.
når dataene allerede er i hukommelsen (buffercache), behandles SELECT-sætningen, og den sidste fase (Hent) udløses, og resultatsættet returneres tilbage til brugeren.
hvis den samme forespørgsel udføres igen, genereres hash, og da området for den pågældende hash allerede eksisterer, springes PARSE-scenen over, og kun eksekvering og hentning udføres.
