VELG Setningsbehandling

Hver SQL-spørring du sender til en server, må gå gjennom tre (fire – I TILFELLE VELG) stadier. Først Av Alt, Vil Oracle søke etter en matchende SQL hash I Library Cache. Hvis hash er funnet, vil den bare hente den tilknyttede forklaringsplanen og utføre den. Hvis ikke, startes en hard analyse – > det betyr at følgende trinn skal utføres.

  1. PARSE
    • syntakssjekk
    • semantisk sjekk
    • privilegier sjekk
  2. BIND
    • erstatt bind/vertsvariabler med faktiske verdier
  3. EXEC
    • faktisk utførelse basert på en forklaringsplan
  4. HENT (BARE VELG setninger)
    • returnerer et resultatsett til en bruker

la meg forklare hver fase i følgende eksempel.

du utførte denne spørringen:

VELG *
fra ansatt;
VELG * fra ansatt;

SELECT *FROM employee;

Serverprosessen vil generere en hash for problemene SQL-spørring. Hash er en heksadesimal verdi generert basert på teksten I SQL-spørringen. Her kommer den svært viktige delen!! Selv den minste endring (store til små bokstaver og vice versa, legge til/fjerne en plass,…) vil endre hash og derfor kan det generere en hard parse (mer på hard parse vs myk parse nedenfor). Du må være veldig forsiktig og prøve å holde fast i en kode bare – det er derfor prosedyrer fungerer best (på toppen av det – de bruker for det meste bind-variabler som genererer identiske spørringer i Oracles øyne).

du kan enkelt bekrefte det på egen hånd ved å utføre spørringene nedenfor:

— kjør først denne spørringen
VELG * fra dual;
— kjør deretter denne igjen med alle store bokstaver
VELG * FRA DUAL;
— sjekk sql hashes
VELG sql_id
, sql_text
, hash_value
FRA v $ sql
HVOR 1=1
og lavere (sql_text) SOM ‘ %velg%fra dual%’;
sql_id | sql_text / hash_value
————————————————–
0x735fvggtnu6 / VELG * FRA DUAL| 3741111110
3vyt9wdmca69b / VELG * fra dual| 1724193067
— Som Du kan se oracle evaluert det som to forskjellige spørringer.
— kjør først dette spørretvelg * fra dual; – kjør deretter denne igjen med alle store bokstavervelg * FRA DUAL;– sjekk sql hashes VELG sql_id, sql_text, hash_valueFROM v$sqlWHERE 1=1og lavere (sql_text) SOM ‘ %velg%fra dual%’; sql_id | sql_text / hash_value————————————————–0x735fvggtnu6 / VELG * FRA DUAL / 37411111103VYT9WDMCA69B / VELG * fra dual | 1724193067-som Du kan se Oracle evaluert det som to forskjellige spørringer.

-- 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 generert, Kontrollerer Oracle om denne spørringen allerede ble utført i dette tilfellet. Hvordan? Ved å sjekke om hash allerede finnes i SQL-Området.

Forutsatt at denne spørringen ikke er tilgjengelig ennå, vil DET være ET SQL-område opprettet med hash-verdien for denne spørringen, Og Oracle vil starte den første fasen av spørringsbehandling, og DET ER ANALYSE.

  • Under syntakskontroll Oracle vil sjekke spørringen om det er syntaktisk korrekt (VELG i stedet FOR Å VELGE; riktig rekkefølge av kommandoer – > VELG * fra tabell REKKEFØLGE av col1 HVOR col2 = ‘John’; etc).
  • det neste trinnet er semantikk sjekker Der Oracle bekrefter om kolonnenavn og objektnavn er riktige. Hvordan? Ved å krysse dem Med Data Dictionary Cache
  • i det siste trinnet I PARSE stage, kontrollerer Oracle om brukeren / programmet har riktige tillatelser for å få tilgang til spørrede objekter.

NÅR DETTE er over, ER SQL-Området gyldig, og et annet verktøy i Oracle KALT OPTIMIZER vil generere en utførelsesplan – det betyr AT OPTIMIZER bestemmer hvordan spørringen skal utføres. Etter at den beste utførelsesplanen er valgt, binder Oracle alle variabler og fortsetter til tredje trinn-Utførelse.

Hva kommer til å skje her? Oracle vil lese datablokker relatert til spørrede objekter og bringe dem til buffer cache (hvis de ikke presenteres der ennå. Hvis De er der, Vil Oracle ikke lese dem igjen!). Denne prosessen vil generere i / O (som, som jeg nevnte i Artikkelen Computing Architecture, er veldig treg i forhold til å lese fra minnet). Jeg vil stoppe her en stund og understreke I / o-generasjonen. Ved myk parse leses alle data fra minnet (buffer cache) som er mye raskere enn å lese dem fra en disk. Det er derfor du må streve for å resirkulere / gjenbruke dine spørsmål så mye som mulig. Hver endring av en spørring vil generere en ny hash og vil derfor mest sannsynlig generere I / O. Alt dette håndteres fortsatt av serverprosessen.

nå, at dataene allerede er i minnet (buffer cache) SELECT-setningen behandles og sluttfasen (HENTE) utløses og resultatsettet returneres tilbake til brukeren.

Hvis den samme spørringen utføres på nytt, genereres hash-en, og SIDEN SQL-Området for den hash-en allerede eksisterer, hoppes ANALYSETRINNET over og BARE EXEC og FETCH utføres.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.