Fazy przetwarzania polecenia SQL Faza parsingu (1)

Transkrypt

Fazy przetwarzania polecenia SQL
Optymalizacja poleceń SQL
Część 1.
Fazy przetwarzania polecenia SQL, pojęcie i cel
optymalizacji, schemat optymalizacji, plan
wykonania polecenia SQL, polecenie EXPLAIN
PLAN, dyrektywa AUTOTRACE, wybór celu
optymalizacji
(c) Instytut Informatyki Politechniki Poznańskiej
1
Faza parsingu (1)
2
Faza parsingu (2)
Krok 1. Test składniowy – weryfikacja
poprawności składniowej polecenia SQL.
Krok 3. Otwarcie kursora
• Kursor – obszar pamięci dla struktur danych, związanych z
przetwarzaniem polecenia SQL, umieszczony w obszarze
współdzielonym serwera.
• Następuje wyliczenie wartości identyfikatora polecenia SQL przy
zastosowaniu funkcji haszującej.
SQL> SELECT * FROM pracownicy;
...
Krok 2. Test semantyczny – m.in. weryfikacja obecności obiektów adresowanych
w poleceniu SQL.
SQL> SELECT sql_id FROM v$sql
WHERE sql_text = 'SELECT * FROM pracownicy';
SQL_ID
------------01439xwqw8pjw
3
4
Faza parsingu (3)
Faza parsingu (4)
Krok 4. Wyszukanie w obszarze współdzielonym serwera obecności
identycznego, wcześniej wykonanego polecenia SQL
• Wyszukanie na podstawie identyfikatora wyliczonego w kroku 3.
Krok 5. Optymalizacja polecenia SQL
• Wynik – plan wykonania polecenia SQL.
Krok 6. Generacja binarnego programu wykonania polecenia SQL
• Konwersja planu wykonania do binarnego programu wykonania
polecenia SQL.
• Jeśli znaleziono identyczne polecenie, odczytywany jest
zbudowany dla niego plan wykonania, faza parsingu ulega
zakończeniu (tzw. miękki parsing).
• Plan wykonania polecenia zostaje zapisany w obszarze
współdzielonym.
• Jeśli wyszukanie zakończy się porażką (wcześniej nie zostało
wykonane identyczne polecenie), następuje przejście do kroku
optymalizacji polecenia (tzw. twardy parsing).
• Uwaga! Kolejne kroki są kosztowne!
5
Faza wykonania
6
Faza pobrania
• Następuje realizacja programu wygenerowanego dla polecenia SQL.
• Występuje tylko dla poleceń SELECT lub poleceń DML z klauzulą
RETURNING.
• Jeśli polecenie używało zmiennych wiązania, zostają one
zamienione na konkretne wartości.
• Realizuje cykliczne pobieranie danych z bufora bazy danych i
przesłanie ich do oprogramowania klienckiego.
• System szuka danych dla polecenia w buforze bazy danych, jeśli ich
tam nie ma, sprowadza je do bufora z nośników.
• Jeśli polecenie modyfikuje dane, następuje założenie odpowiednich
blokad na danych.
7
8
Optymalizacja
Plan wykonania polecenia SQL (1)
• Proces doboru odpowiednich struktur danych, metod dostępu i
operacji, w celu zminimalizowania kosztu realizacji polecenia SQL.
• Wykonywana przez wyspecjalizowany moduł SZBD – optymalizator
poleceń.
• Rodzaje:
• regułowa:
• oparta na rankingu metod dostępu do struktur danych,
• niestosowana, preferowana dla aplikacji spadkowych,
• kosztowa:
• oparta na szacowaniu kosztu (czas zajętości procesora,
liczby operacji we/wy, zajętość pamięci operacyjnej itp.),
wykonania wszystkich potencjalnych sposobów wykonania
polecenia SQL,
• zalecana dla wszystkich nowopowstających aplikacji,
• zakłada duże obciążenie systemu: dużą współbieżność
operacji, niski współczynnik trafień w bufor danych.
• Sekwencja operacji, które SZBD używa do wykonania polecenia
SQL.
• Podstawowe informacje zawarte w planie wykonania:
• ścieżki dostępu (ang. access path) do każdej z relacji, użytych w
poleceniu SQL,
• algorytmy łączenia relacji,
• kolejność łączenia relacji,
• operacje na danych, takie jak filtrowanie, sortowanie, agregacja.
• Dodatkowe informacje w planie:
• koszt operacji (% wykorzystania czasu procesora),
• czas wykonania operacji,
• liczba rekordów i rozmiar danych, przetwarzanych przez
operację.
• Operacje w planie tworzą drzewo.
9
Plan wykonania polecenia SQL (2)
10
Proces optymalizacji polecenia SQL
1.
2.
3.
4.
SELECT * FROM pracownicy NATURAL JOIN zespoly;
0
select statement
Przetransformowanie polecenia do optymalnej postaci.
Wygenerowanie zbioru potencjalnych planów dla polecenia SQL.
Oszacowanie kosztu wykonania każdego planu na podstawie tzw. statystyk.
Wybór do realizacji planu z najniższym kosztem wykonania.
1
merge join
2
4
table access by index rowid on ZESPOLY
sort join
3
5
index full scan on PK_ZESP
table access full on PRACOWNICY
transformator
poleceń
polecenie
i estymacje
polecenie
po transformacji
---------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes| Cost (%CPU)| Time
|
---------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
| 14
| 1036 |
6 (17)| 00:00:01 |
| 1 | MERGE JOIN
|
| 14
| 1036 |
6 (17)| 00:00:01 |
| 2 |
TABLE ACCESS BY INDEX ROWID| ZESPOLY
| 6
| 174 |
2 (0)| 00:00:01 |
| 3 |
INDEX FULL SCAN
| PK_ZESP
| 6
|
|
1 (0)| 00:00:01 |
| 4 |
SORT JOIN
|
| 14
| 630 |
4 (25)| 00:00:01 |
| 5 |
TABLE ACCESS FULL
| PRACOWNICY | 14
| 630 |
3 (0)| 00:00:01 |
----------------------------------------------------------------------------------------
estymator
generator
planów
statystyki
poprawne
polecenie SQL
11
słownik
plan wykonania
polecenia
12
Transformator polecenia
Generator planów wykonania polecenia
• Przekształca polecenie do optymalnej postaci.
• Przykładowe operacje:
• Scalanie perspektyw (ang. view merging).
• Zastąpienie podzapytania połączeniem (ang. subquery
unnesting).
• Eliminacja połączeń.
• Zastąpienie warunków z operatorami OR w kilka zapytań,
połączonych operatorem UNION ALL (ang. or-expansion).
• Zastąpienie zapytań z operatorami MINUS i INTERSECT przez
połączenie.
• Tworzy zbiór różnych planów wykonania tego samego polecenia.
• Plany wykonania różnią przez:
• zastosowanie różnych kombinacji ścieżek dostępu,
• zastosowanie różnych algorytmów połączenia relacji,
• inną kolejność łączenia relacji.
• Dla każdego planu następuje oszacowanie kosztu wykonania.
• Moment zakończenia generacji zbioru planów:
• Jeśli koszt aktualnego planu jest wysoki, generator szuka
lepszego planu bardziej intensywnie (rozpatruje więcej
alternatywnych planów).
• Jeśli koszt aktualnego planu jest niski, wówczas generator
szybko kończy poszukiwania z uwagi na małe
prawdopodobieństwo poprawy.
13
Estymator kosztu planu wykonania
14
Wybór celu optymalizacji (1)
• Zajmuje się szacowaniem kosztu plany wykonania polecenia,
wyliczając tzw. miary.
• Zbiór rekordów – wynik wykonania operacji w planie: relacja,
perspektywa, wynik operacji połączenia, wynik działania operatora
GROUP BY.
• Miary, pozwalające na oszacowanie całkowitego kosztu planu:
• Selektywność – ułamek reprezentujący liczbę rekordów
odczytanych ze zbioru przez operację w stosunku do liczby
rekordów w zbiorze. Ściśle związana z warunkami,
zdefiniowanymi w poleceniu SQL. Zakres: <0, 1>, selektywność
0 – nie zostały odczytane żadne rekordy, selektywność 1 –
zostały odczytane wszystkie rekordy ze zbioru.
• Liczność – liczba rekordów, odczytanych ze zbioru.
• Koszt – reprezentuje jednostki pracy lub zasoby użyte do
realizacji operacji w planie wykonania, np. liczba operacji we/wy,
użycie procesora, użycie pamięci.
• Najlepsza przepustowość – wykorzystanie jak najmniejszych
zasobów systemowych do uzyskania wszystkich rekordów
polecenia SQL.
• Dla aplikacji wykonywanych wsadowo, np. drukowanych
raportów.
• Najważniejszy krótki czas zakończenia całego zadania, mniej
ważny czas odpowiedzi.
• Najkrótszy czas odpowiedzi – wykorzystanie jak najmniejszych
zasobów do uzyskania pierwszego rekordu polecenia SQL.
• Dla aplikacji interaktywnych, np. formularzy ekranowych,
zapytań w SQL*Plus.
• Najważniejszy krótki czas odpowiedzi – użytkownik chce jak
najszybciej zobaczyć pierwszy rekord (lub kilka pierwszych
rekordów) polecenia.
15
16
Wybór celu optymalizacji (2)
Polecenie EXPLAIN PLAN (1)
• Dla bieżącej sesji – parametr OPTIMIZER_MODE:
• ALL_ROWS – optymalizacja maksymalizująca przepustowość
•
•
•
• FIRST_ROWS – optymalizacja minimalizująca czas odpowiedzi (od
Oracle10g cel wycofywany, stosować FIRST_ROWS_n)
Polecenie SZBD (będzie działać w różnych narzędziach).
Polecenie nie jest wykonywane.
Przebieg:
1. Utworzenie relacji PLAN_TABLE (raz w schemacie):
SQL> @$ORACLE_HOME\RDBMS\ADMIN\UTLXPLAN.SQL
• FIRST_ROWS_n – optymalizacja minimalizująca łączny czas
Krok zbędny od wersji Oracle10g – PLAN_TABLE istnieje w
schemacie użytkownika SYS
odczytania pierwszych n krotek (n może być równe (1,10,100 lub
1000)
2. Wygenerowanie planu wykonania polecenia:
EXPLAIN PLAN
[ SET STATEMENT_ID = 'identyfikator' ]
FOR SELECT ... FROM ... WHERE ... ;
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1;
17
•
•
Przebieg (cd):
3. Obejrzenie wygenerowanego planu – użycie funkcji tablicowej
DBMS_XPLAN.DISPLAY, parametry:
•
•
•
UWAGA! Jeśli w iSQL*Plus plan jest nieczytelny, ustawić zmienną
markup html preformat na wartość on
set markup html preformat on
nazwa relacji przechowującej plan, domyślnie PLAN_TABLE,
identyfikator polecenia, domyślnie ostatnio wyjaśniane polecenie,
poziom szczegółowości prezentowanych informacji o planie:
– BASIC – wyświetlenie tylko podstawowe informacje w planie (id operacji,
nazwa obiektu i typ operacji)
– TYPICAL (domyślnie) – wyświetlenie najbardziej odpowiednich informacji
dla danego planu (np. predykaty zapytania, równoległe wykonanie
zapytania)
– ALL – wyświetlenie wszystkich informacji dla planu
– SERIAL – jak TYPICAL ale bez informacji o równoległym wykonaniu
zapytania
18
•
dostępny skrypt, zawierający wywołanie funkcji:
SQL> @$ORACLE_HOME\RDBMS\ADMIN\UTLXPLS.SQL
•
przykłady:
SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, 'zap_1', 'BASIC'));
SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY());
19
20
Dyrektywa AUTOTRACE (1)
• Działa tylko w SQL*Plus/iSQL*Plus i SQL Developer.
• Po wykonaniu polecenia wyświetlany jest raport zawierający plan
wykonania polecenia i dodatkowe informacje.
• Administrator musi użytkownikowi nadać rolę PLUSTRACE:
SQL> EXPLAIN PLAN set statement_id = 'plan01' FOR
SELECT * FROM pracownicy;
Wyjaśniono
SQL> set markup html preformat on -- opcjonalnie!
SQL> @$ORACLE_HOME\SQLPLUS\ADMIN\PLUSTRCE.SQL
SQL> GRANT PLUSTRACE TO SCOTT;
SQL> SELECT PLAN_TABLE_OUTPUT
FROM TABLE(DBMS_XPLAN.DISPLAY(NULL,'plan01','BASIC'));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------Plan hash value: 363874572
-------------------------------------| Id | Operation
| Name
|
-------------------------------------| 0 | SELECT STATEMENT |
|
| 1 | TABLE ACCESS FULL | PRACOWNICY |
--------------------------------------
• Dyrektywa:
SET AUTOTRACE [ON | OFF] [TRACEONLY]
[ EXPLAIN ] [ STATISTICS ]
SQL> set markup html preformat off
21
SET AUTOTRACE OFF
wyłączenie generowania raportu
SET AUTOTRACE ON EXPLAIN
wynik polecenia + plan wykonania
SET AUTOTRACE ON STATISTICS
wynik polecenia + statystyki wykonania
SET AUTOTRACE ON
wynik polecenia + plan wykonania +
statystyki wykonania
SET AUTOTRACE TRACEONLY
plan wykonania + statystyki
Statystyki wykonania polecenia:
•
•
SQL> SET AUTOTRACE ON EXPLAIN
SQL> SELECT nazwisko FROM pracownicy WHERE id_prac=100;
NAZWISKO
----------KOWALSKI
Plan wykonania
---------------------------------------------------------0
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=22)
1
0
TABLE ACCESS (BY ROWID) OF 'PRACOWNICY' (Cost=1 Card=1 Bytes=22)
2
1
INDEX (UNIQUE SCAN) OF 'PK_PRAC' (UNIQUE)
SQL>
SETInformatyki
AUTOTRACE
OFF
(c)
Instytut
Politechniki
Poznańskiej
22
•
•
•
•
•
23
db block gets – liczba bloków danych, które zostały odczytane z bufora
bazy danych przez polecenia, najczęściej DML (odczyty aktualnych wersji
bloków), odczytane bloki nie mogą być równocześnie odczytane przez inne
polecenia (w innych transakcjach),
consistent gets – liczba bloków danych, które zostały odczytane z bufora
bazy danych przez polecenia, najczęściej zapytania (odczyty wersji bloków,
które są aktualne z punktu widzenia transakcji wykonującej zapytanie,
wersje mogą być rekonstruowane z danych z segmentów wycofania, jeśli
np. odczytywany blok został zmodyfikowany przez inną transakcję),
physical reads – liczba bloków, które zostały odczytane z dysków dla
poleceń,
sorts (memory) – liczba operacji sortowania, wykonanych całkowicie w
pamięci,
sorts (disk) – liczba operacji sortowania, zapisu na dysku,
rows processed – liczba przetworzonych rekordów,
logical reads = db block gets + consistent gets – całkowita liczba bloków
odczytanych z bufora bazy danych.
24

Fazy przetwarzania polecenia SQL Faza parsingu (1)

Transkrypt

Podobne dokumenty

Programista SQL, PL/SQL, PHP - Polisa

Centrum Komputerowe Politechniki Łódzkiej

Inżynier Systemowy IT

02-scenariusz-projek..

Mini test z SQL Rozwiąż poniższy test i sprawdź, która

Junior developer SQL / .NET C

Projekty z Baz Danych (wytyczne)

Hosting ZSI Papirus SQL

Oferta: praca / customer support / helpdesk