Fiecare interogare SQL pe care o trimiteți unui server trebuie să parcurgă trei etape (patru – în cazul SELECT). În primul rând, Oracle va căuta un hash SQL potrivit în memoria cache a Bibliotecii. Dacă hash-ul este găsit, acesta va prelua doar planul de explicații asociat și îl va executa. Dacă nu, este invocată o analiză hard ->, ceea ce înseamnă că următorii pași trebuie executați.
- analiza
- verificarea sintaxei
- verificarea semanticii
- verificarea privilegiilor
- BIND
- înlocuiți variabilele bind / host cu valori reale
- EXEC
- execuție efectivă bazată pe un plan de explicații
- FETCH (selectați numai declarații)
- returnează un set de rezultate unui utilizator
permiteți-mi să explic fiecare fază în exemplul următor.
ați executat această interogare:
SELECT *FROM employee;
procesul de Server va genera un hash pentru interogarea SQL probleme. Hash – ul este o valoare hexazecimală generată pe baza textului interogării SQL. Aici vine partea foarte importantă!! Chiar și cea mai mică schimbare (de la majuscule la minuscule și invers; adăugarea/eliminarea unui spațiu; …) va schimba hash-ul și, prin urmare, ar putea genera o analiză hard (mai multe despre analiza hard vs analiza soft de mai jos). Trebuie să fii foarte atent și să încerci să rămâi la un singur cod – de aceea procedurile funcționează cel mai bine (pe deasupra – folosesc mai ales variabile de legare care generează interogări identice în ochii Oracle).
puteți verifica cu ușurință pe cont propriu prin executarea interogările de mai jos:
-- 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.
odată ce hash-ul este generat, Oracle verifică dacă această interogare a fost deja executată în această instanță. Cum? Verificând dacă hash-ul există deja în zona SQL.
presupunând că această interogare nu este încă disponibilă, va exista o zonă SQL creată cu valoarea hash pentru această interogare și Oracle va iniția prima etapă a procesării interogării și aceasta este analiza.
- în timpul verificării sintaxei, Oracle va verifica interogarea dacă este corect din punct de vedere sintactic (selectați în loc de selectare; ordinea corectă a comenzilor- > selectați * din ordinea tabelului prin col1 unde col2 = ‘John’; etc).
- următorul pas este verificările semantice în care Oracle verifică dacă numele coloanelor și numele obiectelor sunt corecte. Cum? Prin verificarea încrucișată a acestora cu memoria cache a dicționarului de date
- în ultima etapă a etapei de analiză, Oracle verifică dacă utilizatorul/aplicația are permisiuni corecte pentru a accesa obiectele interogate.
odată ce acest lucru se termină, zona SQL este validă și un alt instrument din Oracle numit OPTIMIZER va genera un plan de execuție – asta înseamnă că Optimizatorul va decide cum va fi executată interogarea. După ce este selectat cel mai bun plan de execuție, Oracle leagă toate variabilele și trece la al treilea pas – execuție.
ce se va întâmpla aici? Oracle va citi blocurile de date legate de obiectele interogate și le va aduce în memoria cache tampon (dacă nu sunt prezentate încă acolo. Dacă sunt acolo, Oracle nu le va citi din nou!). Acest proces va genera I / O (care, așa cum am menționat în articolul Computing Architecture, este foarte lent în comparație cu citirea din memorie). Mă voi opri aici pentru o vreme și voi sublinia generația I/O. În cazul analizei soft, toate datele sunt citite din memorie (cache tampon), care este mult mai rapid decât citirea lor de pe un disc. De aceea, trebuie să vă străduiți să vă reciclați/reutilizați întrebările cât mai mult posibil. Fiecare modificare a unei interogări va genera un nou hash și, prin urmare, va genera cel mai probabil I/O. toate acestea sunt încă gestionate de procesul serverului.
acum, că datele sunt deja în memorie (cache tampon) instrucțiunea SELECT este procesată și etapa finală (FETCH) este declanșată și setul de rezultate este returnat utilizatorului.
dacă aceeași interogare este executată din nou, hash-ul este generat și din moment ce zona SQL pentru acel hash există deja, etapa de analiză este omisă și numai EXEC și FETCH sunt executate.
