każde zapytanie SQL wysyłane na serwer musi przejść trzy (cztery – w przypadku SELECT) etapy. Po pierwsze, Oracle będzie szukać pasującego skrótu SQL w pamięci podręcznej Biblioteki. Jeśli hash zostanie znaleziony, po prostu pobierze powiązany Plan explain i uruchomi go. Jeśli nie, wywoływany jest twardy parse – >, co oznacza, że następujące kroki mają zostać wykonane.
- PARSE
- sprawdzanie składni
- sprawdzanie semantyki
- sprawdzanie uprawnień
- BIND
- zamień zmienne bind / host na rzeczywiste wartości
- EXEC
- rzeczywista realizacja na podstawie planu
- FETCH (tylko polecenia SELECT)
- zwraca wynik ustawiony użytkownikowi
pozwólcie, że wyjaśnię każdą fazę w poniższym przykładzie.
wykonałeś to zapytanie:
SELECT *FROM employee;
proces serwera wygeneruje hash dla zapytania issues SQL. Hash jest wartością szesnastkową generowaną na podstawie tekstu zapytania SQL. Nadchodzi bardzo ważna część!! Nawet najmniejsze zmiany (duże i małe litery i odwrotnie; dodanie / usunięcie spacji;…) zmieni hash i dlatego może wygenerować twardy parse (więcej na twardym parse vs miękki parse poniżej). Trzeba być bardzo ostrożnym i starać się trzymać tylko jednego kodu – dlatego procedury działają najlepiej (na dodatek – najczęściej używają zmiennych bind, które generują identyczne zapytania w oczach Oracle).
możesz go łatwo zweryfikować samodzielnie, wykonując poniższe zapytania:
-- 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.
po wygenerowaniu skrótu Oracle sprawdza, czy to zapytanie zostało już wykonane w tej instancji. Jak? Sprawdzając, czy hash już istnieje w obszarze SQL.
zakładając, że to zapytanie nie jest jeszcze dostępne, zostanie utworzony obszar SQL z wartością skrótu dla tego zapytania, A Oracle rozpocznie pierwszy etap przetwarzania zapytania, czyli PARSE.
- podczas sprawdzania składni Oracle sprawdzi zapytanie, czy jest poprawne składniowo (SELECT zamiast SELECT; prawidłowa kolejność poleceń – > SELECT * Z kolejności tabeli wg col1 gdzie col2 = 'John’; itd.).
- następnym krokiem jest sprawdzenie semantyki, w której Oracle sprawdza, czy nazwy kolumn i nazw obiektów są poprawne. Jak? Sprawdzając je za pomocą pamięci podręcznej słownika danych
- w ostatnim etapie analizy, Oracle sprawdza, czy użytkownik/aplikacja ma odpowiednie uprawnienia dostępu do zapytanych obiektów.
gdy to się skończy, obszar SQL jest ważny i inne narzędzie w Oracle o nazwie OPTIMIZER wygeneruje plan wykonania – oznacza to, że optymalizator zdecyduje, jak zapytanie zostanie wykonane. Po wybraniu najlepszego planu wykonania Oracle wiąże wszystkie zmienne i przechodzi do trzeciego kroku – wykonania.
co tu się stanie? Oracle odczyta bloki danych związane z zapytanymi obiektami i przeniesie je do bufora cache (jeśli nie są tam jeszcze prezentowane. Jeśli tam są, Wyrocznia nie przeczyta ich ponownie!). Proces ten wygeneruje I / O(co, jak wspomniałem w artykule architektura obliczeniowa, jest bardzo powolne w porównaniu do odczytu z pamięci). Zatrzymam się tutaj na chwilę i podkreślę generację I / O. W przypadku analiz miękkich wszystkie dane są odczytywane z pamięci (bufora cache), co jest znacznie szybsze niż odczyt ich z dysku. Dlatego musisz dążyć do recyklingu / ponownego wykorzystania zapytań w jak największym stopniu. Każda zmiana zapytania wygeneruje nowy hash, a zatem najprawdopodobniej wygeneruje I / O. wszystko to jest nadal obsługiwane przez proces serwera.
teraz, gdy dane są już w pamięci (bufor cache), instrukcja SELECT jest przetwarzana i Uruchamiany jest ostatni etap (FETCH), a wynik jest zwracany z powrotem do użytkownika.
jeśli to samo zapytanie zostanie wykonane ponownie, hash jest generowany, a ponieważ obszar SQL dla tego hasha już istnieje, etap PARSE jest pomijany i wykonywane są tylko EXEC i FETCH.
