Oracle Outlines

Outlines

Outlines zostały wprowadzone aby zagwarantować stały plan wykonania, bez względu na zmiany w środowisku uruchomieniowym, czy zmiany statystyk. Stają się bardzo użyteczne gdy zechcemy wykonać zapytanie na innym serwerze w dokładnie taki sam sposób jak na pierwotnym, w przypadku upgrade wersji Oracle czy migracji z optymalizatora regułowego do kosztowego.

Outlines są obiektami powiązanymi z zapytaniami, zbiorami hintów optymalizatora kosztowego które są w stanie zmusić go do wykonania zapytania w określony sposób, definiując w sposób jednoznaczny plan zapytania. W pewnym sensie „zamrażają” plan wykonania zapytania.

Dzięki Outlines jesteśmy w stanie wpływać na pracę optymalizatora kosztowego i wybór planu, bez konieczności modyfikacji kodu zapytania. Hinty przechowywane są w słownikach systemowych, są powiązane z konkretnym zapytaniem i optymalizator kosztowy wybiera je automatycznie. Jest to bardzo przydatne w przypadku konieczności optymalizacji aplikacji której kodu źródłowego nie jesteśmy w stanie zmienić. W czasie działania optymalizator kosztowy poddaje treść zapytania normalizacji (tj. np. powiększa wszystkie znaki w wyrażeniach składniowych) i poszukuje w słownikach outlines dla takiego właśnie zapytania. Jeśli znajduje, stosuje je do wygenerowania planu zapytania. Outlines są dostępne od wersji 10g wzwyż, we wszystkich licencjach włącznie z Express Edition.

Tworzenie Outlines

Tworzyć outlines można na dwa sposoby: manualnie, bądź zlecić systemowi automatyczne

generowanie outlines dla wszystkich zapytań z sesji, bądź całej bazy.

Automatyczne generowanie outlines

Automatyczne generowanie outlines możemy uruchomić ustawiając parametr create_stored_outlines na True. Parametr ten można ustawić dla sesji, lub całego systemu. Outlines będą wtedy tworzone odpowiednio dla wszystkich zapytań z sesji, lub dla wszystkich zapytań uruchamianych w ramach instancji.

Uruchamianie automatycznego generowania Outlines w ramach sesji:

ALTER SESSION SET CREATE_STORED_OUTLINES=TRUE;

Wyłączanie automatycznego generowania Outlines w ramach sesji:

ALTER SESSION SET CREATE_STORED_OUTLINES=FALSE;

Uruchamianie automatycznego generowania Outlines w ramach całej instancji (oczywiście potrzebne są do tego uprawnienia):

ALTER SYSTEM SET CREATE_STORED_OUTLINES=TRUE;

Wyłączanie automatycznego generowania Outlines w ramach instancji:

ALTER SYSTEM SET CREATE_STORED_OUTLINES=FALSE;

Manualne generowanie Outlines

Outlines możemy tworzyć również manualnie, dla wybranego zapytania. Jeśli zechcemy robić to jako jakiś inny niż SYS bądź SYSTEM użytkownik, będziemy potrzebowali stosownych uprawnień:



GRANT CREATE ANY OUTLINE TO NAZWA_UZYTKOWNIKA;



Outline dla zapytania tworzymy w taki sposób:



CREATE OUTLINE JOIN_EMP_DEP_ORDER ON
SELECT * FROM EMPLOYEES JOIN DEPARTMENTS
USING(DEPARTMENT_ID) ORDER BY DEPARTMENT_NAME,LAST_NAME;

Przeglądać nasze stworzone outlines możemy w słowniku USER_OUTLINES :

Same hinty powiązane za danym Outline znajdziemy w słowniku USER_OUTLINES_HINTS:

Administrator ma do dyspozycji dwa słowniki DBA_OUTLINES i DBA_OUTLINE_HINTS, w których może przeglądać Outlines i związane z nimi hinty wszystkich użytkowników:

Używanie Outlines

Same outlines mamy już stworzone, jednak nie zostały do tej pory użyte i do czasu aż nie ustawimy parametru QUERY_REWRITE_ENABLED nie będą używane. To czy dany Outline został użyty czy też nie, możemy stwierdzić sprawdzając wartość w kolumnie USED słownika USER_OUTLINES :

Wydaję więc polecenie :



ALTER SESSION SET QUERY_REWRITE_ENABLED=TRUE;

Możemy też uruchomić tą opcję dla całego systemu:



ALTER SYSTEM SET QUERY_REWRITE_ENABLED=TRUE;



Musimy jednak dysponować uprawnieniami do zmiany parametrów systemowych.






Outlines są zbierane w grupy, które możemy zdefiniować podczas tworzenia danego zarysu. Jeśli nie zdefiniujemy grupy (kategorii) do której nasz outline ma należeć, zostanie on przypisany do grupy DEFAULT. Niemniej musimy podać systemowi informację, z której grupy ma korzystać:




ALTER SESSION SET USE_STORED_OUTLINES=DEFAULT;

Jeśli tego nie zrobimy, system nie będzie wykorzystywał naszych outlines!

Testy

W dalszej kolejności uruchamiam zapytanie dla którego został stworzony Outline :

Po tej czynności sprawdzam jeszcze wpis w słowniku USER_OUTLINES. Wartość w kolumnie USED dla naszego Outline, powinna zmienić się z UNUSED na USED.

Jeśli tak się nie stało, to mogą być tego trzy przyczyny:

• nie włączyliśmy parametru QUERY_REWRITE_ENABLED
  
• nie ustawiliśmy kategorii używanych Outlines poprzez parametr USE_STORED_OUTLINES
  
• Nasze zapytanie czymś się jednak różni od tego, dla którego Outline został stworzony.
  

Odbudowywanie Outlines

Jeśli zmienią się struktury dostępu, np. zostaną dodane nowe indeksy, warto odtworzyć Outline'y i w ten sposób odświeżyć związane z nimi hinty. W tym celu stosujemy polecenie:



ALTER OUTLINE NAZWA_OUTLINE REBUILD;

Włączanie i wyłączanie wybranych Outlines

Jeśli zechcemy jakiś Outline tymczasowo wyłączyć, nie kasując go trwale wydajemy poniższe polecenie:



ALTER OUTLINE NAZWA_OUTLINE DISABLE;



Później zawsze możemy go włączyć do użycia:



ALTER OUTLINE NAZWA_OUTLINE ENABLE;

Eksport i import Outlines

Niestety Oracle nie dostarcza żadnego narzędzia do przenoszenia między serwerami ani eksportu i importu outlines. Musimy więc sobie poradzić jakoś inaczej. Posłużymy się programami imp oraz exp, dostępnymi we wszystkich licencjach Oracle. Wszystkie outlines znajdują się w słownikach schematu OUTLN. Eksportuje więc ten schemat do pliku:

Muszę teraz zaimportować ten schemat na serwerze na który chcę wdrożyć stworzone wcześniej Outlines.
 

Po operacji importu, musimy po stronie serwera na którym wdrażamy nasze outlines uruchomić ich używanie – tak jak robiliśmy to na serwerze źródłowym:



ALTER SYSTEM SET QUERY_REWRITE_ENABLED=TRUE;
ALTER SYSTEM SET USE_STORED_OUTLINES=DEFAULT;



lub tylko w ramach sesji:



ALTER SESSION SET QUERY_REWRITE_ENABLED=TRUE;
ALTER SESSION SET USE_STORED_OUTLINES=DEFAULT;




Od tej pory outlines będą wykorzystywane tak jak na serwerze źródłowym. Warto sprawdzić jako administrator zawartość słowników DBA_OUTLINES , DBA_OUTLINE_HINTS czy na pewno wszystko się przeniosło właściwie.

Obliczanie odległości na podstawie współrzędnych w PL/SQL

Akurat było mi potrzebne i musiałem zrobić, może komuś też się nada. Nie jest to wyliczenie grzeszące precyzją, ale np. do wyznaczenia miast znajdujących się mniej więcej w promieniu X od punktu się nada :)

declare
dl_a number:=18.3594444;
dl_b number:=21.0508155;
szer_a number:=54.4019444;
szer_b number:=52.3317039;
roznica_szerokosci number;
roznica_dlugosci number;
begin
roznica_szerokosci:=szer_b-szer_a;
roznica_dlugosci:=dl_b-dl_a;
dbms_output.put_line(sqrt(power(roznica_szerokosci,2)+power(roznica_dlugosci,2))*111.1);
end;

Hurtownie danych w Oracle: Star Transforation

Star Transformation

Star Transformation jest metodą łączenia tabel używaną w środowiskach hurtowni danych w celu podniesienia wydajności wykonywania zapytań. Ta metoda zastępuje tradycyjne sposoby łączenia tabel : nested loops, sort merge join i hash join. Metoda Star Transformation jest dostępna od wersji 8i Oracle.
Schemat „Star”

Schemat gwiazdy jest najprostszym schematem hurtowni danych. Nazwa pochodzi od konstrukcji samego schematu, przypomina ona nieco kształt gwiazdy. W tym schemacie mamy jedną tabelę faktu , stanowiącą centralny element schematu, oraz przynajmniej dwie tabele wymiarów będące rozszerzeniami tabeli faktu.

W przypadku wykonania zapytania korzystającego z takich tabel, przeprowadzone zostanie łączenie każdej z tabel rozszerzeń z tabelą faktu. Tabele nie łączą się między sobą. Na powyższej ilustracji tabelę faktu stanowi tabela „zamówienia” , natomiast tabele rozszerzeń (wymiarów) stanowią wszystkie pozostałe.

Schemat „Snowflake”

W bazach danych możemy się spotkać również ze schematami typu „Snowflake”, które są rozwinięciem schematu „Star”. 

Star Query

Ideą Star Transformation jest zmniejszenie ilości full table skanów dużych tabelach – w tym przypadku na tabeli faktu – sales. W typowych zapytaniach na strukturze gwiazdy duża tabela faktu jest łączona z wielokrotnie mniejszymi tabelami rozszerzeń. Tabela faktu ma zazwyczaj po jednym kluczu obcym dla każdej tabeli rozszerzenia.

select ch.channel_class,cu.cust_city,t.calendar_year,sum(s.amount_sold) suma_sprzedazy

from

sales s,channels ch,customers cu, times t where

s.time_id=t.time_id and ch.channel_id=s.channel_id

and s.cust_id=cu.cust_id

and channel_class in ('Direct','Internet')

and cust_state_province='CA' and t.calendar_year ='1998'

group by ch.channel_class,cu.cust_city,t.calendar_year;

Bez stosowania Star Transformation, łączenie przebiega w taki sposób, że tabela faktu (w tym przypadku tabela Sales) jest łączona osobno z każdą z tabel. Mimo, że w efekcie końcowym zapytania zostanie wyświetlona bardzo nieznaczna część tabeli sales, przeprowadzany jest na niej full scan. Im większa jest tabela faktu, tym większa utrata wydajności. Przyjrzyjmy się sposobowi wykonania tego zapytania w „tradycyjny” sposób:

 

Tabela zawiera prawie milion wierszy:

Sam wynik zapytania dotyczy jednak jedynie 11 wierszy. Oczywiście wymagane było połączenie tabeli sales z tabelami channels,times i customers, jednak wykonywanie w tym celu full scana jest bardzo nieefektywne.

Star Transformation

Optymalizator kosztowy rozpoznaje takie struktury i stosuje dla zapytań na nich specjalnie zoptymalizowane plany wykonania przy użyciu metody Star Transformation. Aby jednak było to możliwe, musi zostać spełnione kilka warunków:

• na kluczach obcych tabeli faktu powinny zostać założone indeksy bitmapowe. W tym przypadku osobne indeksy bitmapowe powinny zostaćzałożone na kolumnach: channel_id,time_id,cust_id tabeli sales.
• Parametr STAR_TRANSFORMATION_ENABLED musi być włączony dla sesji lub bazy danych.
• Muszą być przynajmniej dwie tabele wymiarów i jedna tabela faktu.
• Statystyki wszystkich obiektów biorących udział w zapytaniu muszą być świeże.

Kiedy te warunki będą spełnione, optymalizator kosztowy będzie automatycznie wybierał metodę Star Transformation która jest bardzo efektywna dla zapytań typu star query (tj. takich jak omawiane wcześniej). Dla użytkownika fakt zmiany metody wykonywania zapytania jest niezauważalny (poza przyspieszeniem :) ). Zastosowanie Star Transformation nigdy nie doprowadzi do odmiennych niż pierwotne wyników zapytania.

Sposób działania Star Transformation

W jaki sposób działa metoda Star Transformation? Przebiega zasadniczo w dwóch fazach.

W pierwszej fazie, system stosuje filtry na tabeli rozszerzeń i określa wartości klucza głownego dla wybranych wierszy. W drugiej fazie mając już ograniczone dane z tabeli rozszerzenia, system przeszukuje indeksy bitmapowe założone na kluczach obcych tabeli faktu w celu wybrania tylko niezbędnych wierszy z tabeli faktu.

Przeprowadzimy teraz testy. Włączam parametr star_transformation_enabled dla sesji i ponawiam generowanie planu wykonania dla tego samego zapytania:

alter session set star_transformation_enabled=true;

select ch.channel_class,cu.cust_city,t.calendar_year,sum(s.amount_sold) suma_sprzedazy

from sales s,channels ch,customers cu, times t where

s.time_id=t.time_id and ch.channel_id=s.channel_id

and s.cust_id=cu.cust_id and channel_class in ('Direct','Internet')

and cust_state_province='CA' and t.calendar_year ='1998'

group by ch.channel_class,cu.cust_city,t.calendar_year;

 

Róznica polega przede wszystkim na sposobie dostępu do danych z tabeli faktu:

Porównajmy z wcześniejszym sposobem dostępu:

 

Należy pamiętać, że im większa jest tabela faktu , tym większy koszt generuje full table scan. Wynika to z większej ilości danych które trzeba odczytać. Im więc tabela faktu jest większa, tym bardziej opłacalna z punktu widzenia optymalizacji jest implementacja metody Star Transformation.

Podczas wykorzystania metody Star Transformation, następuje dwukrotny dostęp do tabel rozszerzeń. Po jednym razie dla każdej z dwóch faz wykonywania tej metody. Jeśli optymalizator kosztowy uzna to za opłacalne z punktu opłacalności, system utworzy tabelę tymczasową zawierającą odfiltrowane dane i będzie z niej korzystał zamiast wielokrotnego dostępu do tabeli rozszerzenia.

Testy były przeprowadzane na schemacie SH , który jest dostarczany jako schemat przykładowy razem z samą bazą. Wystarczy jedynie odblokować konto SH i ustawić mu hasło.

Wyrażenie CASE w SQL (IF THEN ELSE tylko w SQL)

Wyrażenie CASE zapewnia funkcjonalność konstrukcji typu IF-THEN-ELSE w SQL.

Wynik wyrażenia CASE może być m.in. uzależniony od wartości w jednej kolumnie :

select last_name, department_id,

case department_id

when 90 then 'Zarząd'

when 60 then 'Geeki informatyczne'

else 'Inni'

end case

from employees;

W powyższym przykładzie jeśli w kolumnie department_id pojawi się wartość 90, case zwróci nam ciąg tekstowy „Zarząd”, jeśli pojawi się wartość 60 dostaniemy tekst „Geeki informatyczne”. W przypadku pojawienia się dowolnej innej wartości otrzymamy tekst „Inni”. Po wszystkich warunkach musi być zakończenie konstrukcji klauzulą „END CASE” lub samo „END”. 

Klauzula „else” nie jest konieczna. W przypadku pojawienia się innej niż 60 lub 90 wartości, dostaniemy NULL.

Na powyższym obrazku widzimy też użycie aliasu dla wyrażenia CASE. Aby można było użyć aliasu, warunki musimy zakończyć klauzulą „END”. W przypadku zastosowania klauzuli „END CASE” dostajemy błąd.

CASE nie musi opierać się na wartościach z jednej kolumny. Na poniższym przykładzie pokazuję dodanie kolumny z opisem stanowiska uzależnionym od wartości w różnych kolumnach.

select last_name, salary,department_id,manager_id, case

when manager_id is null then 'Prezes'

when department_id=90 then 'Czlonek zarządu'

when department_id=60 and salary>5000 then 'Programista Oracle :)'

when department_id=100 then 'Ci co nie chcą dać podwyżek'

else 'jacyś inni' end stanowisko

from employees;

Case działa w taki sposób, że jeśli warunek okaże się prawdziwy, nie sprawdza następnych. Widać to na przykładzie pracownika „King”. Pracuje w departamencie 90 i jednocześnie ma null w manager_id. Wyświetla się przy nim „Prezes” a nie „Członek zarządu”, ponieważ warunek pierwszy został spełniony (null w manager_id) i system nie sprawdzał kolejnego.

Oracle SQL Tuning Advisor

SQL Tuning Advisor

W miejsce ręcznej optymalizacji zapytań SQL, można zastosować rozwiązania automatycznej optymalizacji dostarczane przez Oracle. Jednym z takich narzędzi jest SQL Tuning Advisor wprowadzony w Oracle 10g. Optymalizator kosztowy może działać w dwóch trybach:

• Normal mode
  
• Tuning mode
  

Normal Mode

Podczas zwykłego funkcjonowania, optymalizator kosztowy generuje dla zapytań plany wykonania. W tym trybie optymalizator ma narzucone ścisłe ograniczenia czasowe na działanie, zazwyczaj są to ułamki sekund. W tym czasie musi stworzyć jak najlepszy plan wykonania zapytania.

Tuning Mode

W trybie strojenia optymalizator wykonuje dodatkową analizę mającą na celu sprawdzenie czy plan wykonania zapytania wygenerowany w zwykłym trybie funkcjonowania można jeszcze ulepszyć. Wynikiem działania takiej dodatkowej analizy nie jest plan wykonania zapytania, a szereg proponowanych działań wraz z ich uzasadnieniem i szacowanymi korzyściami. Wywołany w trybie strojenia optymalizator nazywamy ATO (Automatic Tuning Optimizer). W trybie strojenia optymalizator może poświęcić nawet kilka minut na optymalizację zapytania. Ponieważ taka analiza również pochłania zasoby systemowe, ATO jest przeznaczony do wykorzystania dla złożonych i bardzo obciążających zapytań mających duże znaczenie dla całego systemu. Tryb strojenia jest włączany przez użytkownika dla wybranych przez niego zapytań.

Automatic Database Diagnostic Monitor (ADDM)

Poczynając od Oracle 10g, identyfikacją najbardziej obciążających system zapytań zajmuje się ADDM. Najbardziej obciążające zapytania to te zużywające najwięcej zasobów CPU, I/O i przestrzeni tymczasowej. Takie obciążające zapytania są dobrymi kandydatami do optymalizacji przez SQL Tuning Advisor. Otrzymuje on na wejściu zapytania wskazane przez ADDM i tworzy dla nich wskazówki optymalizacyjne wraz z uzasadnieniem, szacunkowymi korzyściami płynącymi z ich zastosowania i jeśli jest dostępna – komendą która wdroży daną wskazówkę (np. komendę tworzącą odpowiedni indeks). Użytkownik może akceptować wskazówki Advisor'a i w ten sposób optymalizować zapytania.

Sposób działania SQL Tuning Advisor'a

SQL Tuning Advisor jest jedynie kontrolerem procesu optymalizacji. Wywołuje on ATO (Optymalizator kosztowy działający w trybie strojenia) aby ten przeprowadził poniższe analizy:

• Analiza statystyk. ATO sprawdza obiekty biorące udział w zapytaniu pod kątem aktualności statystyk. Jeśli statystyki nie są aktualne, tworzy wskazówkę dotyczącą ich odświeżenia. Wykorzystując próbkowanie zbiera również dodatkowe informacje w celu dostarczenia brakujących lub niepoprawnych statystyk na wypadek gdyby wskazówki Advisor'a nie zostały zaimplementowane.
  
• Profilowanie SQL. Profil dla zapytania SQL jest tym , czym statystyki dla tabel. Bazując na kolejnych wykonaniach danego zapytania, ATO zbiera informacje na temat sposobu wykonania, i dzięki temu może lepiej dobrać podpowiedzi dla niego. Weryfikuje czy jego własne szacunki dotyczące wykonania zapytania pokrywają się z rzeczywistością. Profile SQL są formą indywidualnych dla zapytania informacji, statystyk i ustawień optymalizatora. ATO buduje profil zapytania SQL i sugeruje utworzenie go dla danego zapytania. Kiedy profil zostanie stworzony, będzie stosowany przez optymalizator kosztowy do tworzenia efektywniejszych planów wykonania danego zapytania w normalnym trybie działania optymalizatora. Dla użytkownika fakt korzystania z profilu SQL jest niezauważalny. Podczas budowania profilu, ATO testuje swoje własne wskazówki poprzez szacowanie obciążenia z nowymi ustawieniami, ale też częściowe realne wykonanie zapytania z użyciem nowych konfiguracji.
  
• Analiza ścieżek dostępu. ATO analizuje ścieżki dostępu w zapytaniu, i jeśli stworzenie indeksu poprawiłoby wydajność zapytania, rekomenduje jego utworzenie.
  
• Analiza struktury zapytania. Niekiedy sama struktura zapytania powoduje niską wydajność. W takich przypadkach ATO sugeruje zmianę zapytania. Wykrywa np. łączenia kartezjańskie, czy stosowanie UNION tam gdzie powinno się użyć UNION ALL.
  

Źródła zapytań podlegających optymalizacji przez ATO

Zapytania które będą analizowane i optymalizowane przez ATO mogą pochodzić z trzech źródeł:

• najbardziej obciążające zapytania zidentyfikowane przez ADDM
• zapytania SQL które znajdują się w cache'u
• wybrane zapytania podane przez użytkownika

W przypadku zapytać pochodzących z cache, lub zakwalifikowanych przez ADDM, użytkownik ma możliwość wybrania niektórych zapytań. Nie ma konieczności optymalizacji wszystkich.

Sposób użycia SQL Tuning Advisor'a

Aby przejść do STA, logujemy się do Enterprise Manager'a. Następnie klikamy link „Advisor Central” dostępny na dole strony:

Następnie wybieramy „SQL Advisors” w górnej lewej części strony:

Dalej wybieramy SQL Tuning Advisor:

Mamy tutaj możliwość wyboru źródła pochodzenia zapytań które mają podlegać optymalizacji:

Zapytania najbardziej obciążające

Po wyborze „Top Activity” na poprzednim ekranie, zobaczymy wykres obciążenia bazy na przestrzeni czasu, pod kątem zużycia różnego rodzaju zasobów.

W lewej dolnej części strony możemy wybrać spośród tych najbardziej obciążających, zapytania które chcemy optymalizować. Niekiedy tabela pozostaje pusta. Wystarczy wtedy odświeżyć stronę. Możemy podejrzeć treść zapytań klikając na link w kolumnie SQL ID:

Zaznaczamy je, upewniamy się że w selektorze „Actions” wybrane jest „Schedule SQL Tuning Advisor” i naciskamy „Go”:

Pojawi nam się ekran który służy do uruchomienia analizy i optymalizacji wybranego zapytania.

Mamy możliwość wybrania typu analizy spośród dwóch opcji:

• Limited. Jeśli wybierzemy tę opcję, nie zostanie utworzony profil SQL, ale za to analiza przebiega bardzo szybko.
  
• Comprehensive. Wykonywana jest pełna analiza, tworzony jest też profil SQL dla zapytania. Taki rodzaj analizy trwa jednak znacznie dłużej niż w przypadku opcji „Limited”.
  

Możemy też określić limit czasowy na analizę wszystkich wybranych do optymalizacji zapytań ( w oknie „Total Time Limit”), oraz limit jednostkowy dla pojedynczego zapytania. Niżej, w sekcji Schedule możemy wybrać czy analiza ma się rozpocząć teraz, czy też chcemy ją odłożyć na nieco później (np. wtedy kiedy baza będzie mniej eksploatowana). Po zatwierdzeniu przyciskiem „Submit” (znajdującym się w prawym górnym rogu), zobaczymy taki oto ekran:

Przez parę chwil, ATO będzie analizował nasze zapytania. Gdy skończy, zobaczymy listę proponowanych działań:

Dla niektórych podpowiedzi optymalizacyjnych będzie dodana opcja implementacji. O ile np. do podpowiedzi dotyczącej stworzenia indeksów czy odświeżenia statystyk ATO jest w stanie wygenerować komendę która od razu to wykona, o tyle do podpowiedzi np. dotyczących zmiany kształtu zapytania nie będzie to możliwe.

W prawym górnym rogu mamy przycisk „Show SQL”, który pozwoli nam podejrzeć treść komendy którą ATO nam sugeruje:

 

 

Wybrałem jedną z podpowiedzi i kliknąłem „Implement”. System przeszedł do okna umożliwiającego zastosowanie wskazówki – w tym przypadku odświeżenia statystyk tabel. Mamy tutaj też możliwość zastosowania wskazówki teraz, lub w innym terminie.

Przeprowadziłem jeszcze jeden test, tym razem wybierając nieco więcej zapytań. Proces analizy też trwał już dłużej.

Po zakończeniu pojawił się ekran z podsumowaniem statystyk analizy. Wybieram przycisk „Show all results”:

Przejdziemy wtedy do ekranu z propozycjami ATO:

Analiza zapytań historycznych

Przy użyciu ATO mamy też możliwość analizowania historycznych zapytań. Tym razem po przejściu do SQL Tuning Advisora link „Historical SQL”:

 

Zobaczymy listę zapytań które nadal rezydują w cache kursorowym. Mamy tam informacje o zapytaniach jako takich, ale też dane na temat czasu wykonywania zapytania, ilość wykonań danego zapytania etc.

 

Podobnie jak wcześniej, zaznaczam zapytania które chcę poddać analizie, po czym wybieram przycisk „schedule SQL Tuning Advisor”:

Tak jak i wcześniej przechodzę przez widok w którym określam rodzaj analizy i moment jej przeprowadzenia:

Na kolejnym ekranie wybieram „Show all results”:

i przechodzę do ekranu podpowiedzi, gdzie zaznaczam wybrane zapytanie i klikam „View Recomendations” aby zobaczyć podpowiedzi dla danego zapytania:

Należy traktować podpowiedzi ATO troszkę z dystansem, ponieważ jest to tylko program , a program nie myśli w taki sposób jak człowiek. Nigdy też człowieka nie zastąpi. Nie traktujmy więc wszystkich podpowiedzi bezkrytycznie i weryfikujmy czy jego sugestie są racjonalne. Pamiętajmy też, że ATO nie wymyśli też wszystkiego co wymyślić może człowiek. Nie raz więc będzie się zdarzać że po ATO trzeba będzie poprawiać :)