Jarosław Gramacki - Uniwersytet Zielonogórski

,POGFSFODKBOBVLPXB,/84
v*OGPSNBUZLBT[UVLBD[ZS[FNJPT’P
D[FSXDB$[PDIB
KONCEPCJA ZASTOSOWANIA SZTUCZNYCH SIECI NEURONOWYCH
W DIAGNOSTYCE BAZ DANYCH ORACLE
Jarosław Gramacki
Instytut Informatyki i Elektroniki, Uniwersytet Zielonogórski
65-246 Zielona Góra, ul. Podgórna 50
e-mail: [email protected]
STRESZCZENIE
W artykule przedstawiono koncepcjĊ zastosowania sztucznych sieci neuronowych w
diagnostyce kluczowych parametrów wydajnoĞciowych bazy danych ORACLE. Pokazano, Īe
jest uzasadnione i moĪliwe zbudowanie układu neuronowego przewidującego ewentualne
pogorszenie siĊ wybranych parametrów bazy.
1. WPROWADZENIE
Wymieniü moĪna co najmniej parĊ czynników i związanych z nimi zadaĔ wpływających na
wydajnoĞü bazy danych w obszarze związanym z zarządzaniem pamiĊcią [2]. Wymienione
poniĪej oraz zilustrowane na rysunku 1 elementy tworzą tzw. globalny obszar systemowy
SGA (ang. System Global Area), który jest niczym innym jak odpowiednio zarządzanym na
potrzeby bazy danych Oracle obszarem pamiĊci operacyjnej komputera. PamiĊü ta jest
zawsze alokowana w momencie uruchamiania instancji bazy poleceniem startup (wydanym
z poziomu programu Server Manager – do wersji 8i, lub SQL*Plus – w wersjach 9i oraz 10g).
Jest ona jednoczeĞnie współdzielona przez wszystkich uĪytkowników podłączonych w danym
momencie do bazy.
Do głównych zadaĔ administratora bazy naleĪy [3, 4, 6]:
ƒ strojenie obszaru współdzielonego (ang. Shared Pool),
ƒ
strojenie dziennika powtórzeĔ (ang. Redo Log Buffer),
ƒ
strojenie bufora danych (ang. Buffer Cache).
W pracy skupiono siĊ nad zagadnieniem obsługi bufora danych. Zaproponowana metodologia
nie bĊdzie merytorycznie róĪniü siĊ w pozostałych przypadkach a róĪnice bĊdą jedynie
iloĞciowe.
105
Globalny Obszar Systemowy SGA
(ang. System Global Area)
bufor danych
(DB_Block_Size,
DB_Block_Buffers)
obszar współdzielony
(Shared_Pool_Size)
współdzielony obszar
poleceĔ SQL
bufora dziennika
powtórzeĔ
(Log_Buffer)
bufor słownika
danych
Rys. 1. Globalny obszar systemowy SGA. Czcionką nieproporcjonalną podano odpowiednie
parametry pliku konfiguracyjnego instancji init<SID>.ora
WielkoĞü obszaru SGA okreĞliü moĪna wydają na przykład poniĪsze polecenie
-- Parametry instancji
SELECT * FROM v$sga;
-- przykładowy wynik
NAME
VALUE
---------------- --------Fixed Size
75804
Variable Size
106840064
Database Buffers 49594368
Redo Buffers
=
8192
* 6054
DB_Block_Size * DB_Block_Buffers
77824
WielkoĞü bufora danych oblicza siĊ jako iloczyn dwóch parametrów konfiguracyjnych
instancji Oracle: DB_Block_Size oraz DB_Block_Buffers. Pierwszego z nich nie
moĪna zmieniaü bez przebudowania bazy danych, gdyĪ jego wielkoĞü ustawiana jest w
momencie tworzenia nowej bazy danych. Podaje on w bajtach rozmiar najmniejszego
elementu obszaru bufora danych – jednego bloku danych. Doborowi podlega parametr
DB_Block_Buffers, który okreĞla liczbĊ bloków, które tworzą cały bufor danych.
W obszarze pamiĊci jakim jest bufor danych przechowuje siĊ dane uĪytkowe (tabele,
indeksy), do których dostĊp mają wszyscy uĪytkownicy systemu (oczywiĞcie w zakresie
posiadanych do nich uprawnieĔ). Po wystartowaniu bazy danych bufor danych jest pusty i
zapełnia siĊ stopniowo wraz z pobieraniem przez uĪytkowników kolejnych danych z plików
dyskowych. Gdy w jakimkolwiek momencie pracy któryĞ z uĪytkowników zaĪąda
106
jakichkolwiek danych, system w pierwszej kolejnoĞci stara siĊ odnaleĨü je w pamiĊci
operacyjnej czyli w buforze danych. PoniewaĪ czas dostĊpu do pamiĊci jest
nieporównywalnie krótszy niĪ czas dostĊpu do pliku (plików) dyskowego, wiĊc optymalny
dobór parametrów bufora danych ma bezpoĞredni wpływ na Ğredni czas dostĊpu do danych.
W pracy pominiĊto oczywisty, choü nie zawsze uĞwiadamiany sobie przez administratorów,
aspekt pierwszeĔstwa strojenia modelu danych, na których działa aplikacja, strojenia
(optymalizacji) samej aplikacji oraz ĞciĞle związane z tym ostatnim strojenie zapytaĔ SQL.
Wydaje siĊ, Īe w wielu przypadkach problem (pozornie słabej) wydajnoĞci systemu leĪy nie
w niewłaĞciwych parametrach instancji bazy, ale w aplikacjach, które w niej działają.
Innym problemem jest czĊsto duĪe przeszacowanie zaalokowanych zasobów systemowych
(głównie pamiĊci) na potrzeby instancji. Pomijając oczywiste w takim przypadku
marnotrawienie zasobów sprzĊtowych komputera, problemem w takim przypadku moĪe byü
duĪy narzut obliczeniowy związany z koniecznoĞcią obsługi np. nieracjonalnie duĪego bufora
danych.
NaleĪy równieĪ wspomnieü, Īe w buforze danych mogą równieĪ znajdowaü siĊ kopie tych
samych danych, jeĞli na przykład wiĊcej niĪ jedna transakcja operuje na tych samych danych
i zmiany nie zostały jeszcze zatwierdzone (ang. committed). Fakt ten nie zmienia jednak istoty
buforowania w pamiĊci zawartoĞci bazy danych.
Parametrem charakteryzującym "jakoĞü" bufora danych jest tzw. współczynnik trafieĔ w
bufor (ang. Cache Hit Ratio). Wyliczany on jest na podstawie analizy całkowitej liczby
fizycznych operacji odczytu z dysku (ang. physial reads) oraz całkowitej liczby operacji
odczytu danych, które odnaleziono w buforze. Dane do jego wyliczenia (tzw. statystyki)
znajdują siĊ odpowiednich tzw. tabelach (widokach) słownikowych systemu Oracle i
uaktualniane są na bieĪąco w trakcie pracy systemu. Zwykle uĪyteczną ich wartoĞü moĪna
obliczyü dopiero po kilku / kilkunastu godzinach pracy systemu, licząc od momentu
uruchomienia instancji.
-- Wyliczenie współczynnika trafieĔ w bufor
SELECT (1 FROM
v$sysstat
WHERE
PR.name
DBG.name
CG.name
(PR.value / (DBG.value + CG.value)))*100 "Cache Hit Ratio"
PR, v$sysstat DBG, v$sysstat CG
= 'physical reads' AND
= 'db block gets' AND
= 'consistent gets';
-- przykładowy wynik
Cache Hit Ratio
--------------95,5167612
107
ZaleĪnoĞü miĊdzy wielkoĞcią bufora a współczynnikiem trafieĔ nie jest liniowa. Oznacza to,
Īe po osiągniĊciu pewnej granicznej wielkoĞci bufora danych, dalsze zwiĊkszanie jego
rozmiaru daje znikome efekty, a dodatkowy narzut obliczeniowy związany z zarządzaniem
wiĊkszą iloĞcią pamiĊci moĪe skutkowaü nawet spowolnieniem pracy całego systemu.
Wspomnianą nieliniowoĞü łatwo pokazaü eksperymentalnie, wykonując wykres zaleĪnoĞci
współczynnika trafieĔ od wielkoĞci bufora danych dla zadanego scenariusza dostĊpu do
miara fizycznych
dostĊpów do dysku
danych. NieliniowoĞü ta szczególnie uzasadnia zastosowanie sieci neuronowych do analizy
(aproksymacji) tej zaleĪnoĞci [7, 8]. Na rysunku 2 pokazano hipotetyczną zaleĪnoĞü pomiĊdzy
wielkoĞcią fizycznych dostĊpów do danych dyskowych a wielkoĞcią bufora. W
rzeczywistoĞci liczba analizowanych parametrów bĊdzie duĪo wiĊksza.
kształt intuicyjny
kształt rzeczywisty
~0.5
~0.1
wielkoĞü bufora danych
Rys. 2. Ilustracja rzeczywistego i intuicyjnego przebiegu zaleĪnoĞci iloĞci dostĊpów do fizycznych
plików z danymi od wielkoĞci bufora danych
Uwaga. Przy analizie współczynnika trafieĔ pamiĊtaü naleĪy, Īe wyniki tzw. pełnego odczytu
tabeli (ang. full table scan) nie są domyĞlnie kierowane w "normalny" sposób do bufora, ale w
sposób zapewniający moĪliwie szybkie "pozbycie" siĊ wyników takich odczytów z bufora. W
czasie testów wygodnie jest jednak zapełniaü bufor takimi właĞnie odczytami (wtedy łatwo o
duĪe porcje danych). DomyĞlne działanie procesu obsługującego bufor łatwo jednak zmieniü
poprzez uĪywanie w zapytaniach SQL wskazówki CACHE (ang. hint). Opcja ta jest równieĪ
czĊsto wykorzystywana do zapewnienia sobie szybkiego dostĊpu do tzw. małych słowników
(ang. small lookup tables), które w normalnym trybie (NOCHACHE) byłyby szybko usuniĊte z
bufora danych.
WielkoĞü parametru DB_Block_Buffers dobiera siĊ eksperymentalnie, korzystając z
wiedzy i doĞwiadczenia administratora systemu. Jest to jednak zawsze proces długotrwały a
czĊsto i uciąĪliwy, gdyĪ wymaga restartu instancji i nastĊpnie odpowiednio długiej pracy w
normalnych warunkach w celu wypełnienia siĊ bufora danych i zaistnienia odpowiednio duĪej
iloĞci dostĊpów do zgromadzonych w nim danych.
108
Odpowiednie procedury, opisane w [4, 6], pozwalają na symulacjĊ wpływu zwiĊkszenia i /
lub zmniejszenia bufora danych na wynikowy współczynnik trafieĔ. Stosowane tam podejĞcie
jest jednak uciąĪliwe – podobnie jak dla przypadku opisanego wyĪej.
2. SIECI NEURONOWE
Najogólniej stwierdziü moĪna [7, 8], Īe dobrze skonstruowana sieü neuronowa (SN) jest w
stanie "nauczyü siĊ" aproksymowaü dowolną funkcjĊ wielu zmiennych f(x1, x2,. x3,...,xN).
Zmiennymi mogą byü dowolne wartoĞci reprezentujące wybrany obiekt sterowania (w
naszym przypadku: bazy danych).
Cechą podstawową SN jest wiĊc moĪliwoĞü uczenia siĊ odwzorowywania dowolnej funkcji,
najczĊĞciej zaleĪnej od wielu zmiennych i silnie nieliniowej. PoniewaĪ jest to aproksymacja, a
nie interpolacja, to sieü jest w stanie uogólniaü wiedzĊ, wykrywaü istniejące pomiĊdzy
zmiennymi zaleĪnoĞci. W procesie uczenia sieü tworzy wiĊc rodzaj statystycznego modelu
uczonej zaleĪnoĞci (funkcji).
SN jest zbudowana z tzw. neuronów, ułoĪonych warstwami. Szczegóły budowy
pojedynczego neuronu [7, 8] nie są w tych dosyü ogólnych rozwaĪaniach istotne. Neurony tej
samej warstwy nie są połączone miĊdzy sobą, ale neurony dwóch sąsiednich warstw są
połączone "kaĪdy z kaĪdym". WyróĪnia siĊ warstwĊ wejĞciową (We), warstwy ukryte (U)
(zazwyczaj 1 lub 2) i warstwĊ wyjĞciową (Wy). Sygnał przechodzi od warstwy We poprzez U
aĪ do Wy, skąd jest odbierany i interpretowany. Sygnał przechodząc przez dane połączenie
wewnątrz SN zostaje pomnoĪony przez liczbĊ przypisaną temu połączeniu, zwaną wagą
połączenia. Wagi mogą mieü dowolne wartoĞci rzeczywiste. Siec taka zwana jest równieĪ
perceptronem wielowarstwowym.
We
U
wagi
połączeĔ
x1
wagi
połączeĔ
Wy
•••
x2
•
•••
x3
•
•
•
•
•
•
•
y1
yM
•••
•
xN
Rys. 3. Sieü jednokierunkowa jako perceptron wielowarstwowy. Tworzą go neurony ułoĪone w
warstwach o jednym kierunku przepływy sygnałów, o połączeniach miĊdzywarstwowych jedynie
pomiĊdzy sąsiednimi warstwami
109
W pierwszej kolejnoĞci naleĪy ustaliü, jak sieü bĊdzie zbudowana. IloĞü neuronów
wejĞciowych i wyjĞciowych jest okreĞlona z góry dla danego problemu, natomiast iloĞü
neuronów w warstwach ukrytych (oraz iloĞü samych warstw, choü zazwyczaj stosuje siĊ
jedną, góra dwie) moĪna regulowaü.
Po wyborze struktury sieci (wstĊpnej, gdyĪ w kolejnych krokach moĪe zajĞü potrzeba jej
modyfikacji) przechodzi siĊ do zasadniczej czynnoĞci – tzn. di jej uczenia. Uczenie to po
prostu dobieranie wag połączeĔ miĊdzy neuronami w taki sposób, aby po podaniu na wejĞcie
sieci jakichĞ wartoĞci, na jej wyjĞciu uzyskaü odpowiedni wynik. Uczenie odbywa siĊ w
nastĊpujący sposób:
Przygotowuje siĊ zestaw danych wejĞciowych wraz z odpowiadającymi im wynikami, jakie
powinna uzyskaü sieü. Wagi sieci inicjalizuje siĊ w sposób przypadkowy. NastĊpnie podaje
siĊ kolejno, wiele razy, wszystkie zestawy danych wejĞciowych i patrzy, na ile odpowiedĨ
sieci róĪni siĊ od poprawnego wyniku. Oblicza siĊ róĪnicĊ i nastĊpnie w odpowiedni sposób
koryguje siĊ wagi połączeĔ wewnątrz sieci (poczynając od ostatniej warstwy, aĪ do warstwy
wejĞciowej). W wyniku otrzymujemy sieü nauczoną, tj. mającą odpowiednie wartoĞci wag,
aby efektywnie rozwiązaü postawione jej zadanie.
Po nauczeniu sieci trzeba ją nastĊpnie przetestowaü – do tego wykorzystuje siĊ kolejny
zestaw danych wejĞciowych i wyjĞciowych, ale takich, które nie były wykorzystane podczas
uczenia. JeĞli na tym zestawie odpowiedzi sieci na zadane wymuszenia bĊdą poprawne, to
moĪna siĊ spodziewaü, Īe w sytuacjach przyszłych (dla jakichĞ nieznanych danych) teĪ tak
bĊdzie. JeĞli nie – trzeba powtórzyü uczenie, ewentualnie zmieniając budowĊ sieci albo
zestaw danych uczących.
Generalnie rzecz biorąc, tylko jeden układ przestrzenny sieci jest optymalny. JeĞli warstwy
ukryte mają zbyt wiele neuronów, sieü nadmiernie dopasowuje siĊ do nauczanych danych (jej
wynik staje siĊ bliĪszy interpolacji) i przez to traci zdolnoĞü uogólniania. O takiej sieci mówi
siĊ, Īe jest "przeuczona". JeĞli natomiast neuronów w warstwach ukrytych jest za mało, sieü
nie jest w stanie poprawnie odtworzyü uczonej funkcji, jest "niedouczona".
3. PRZEWIDYWANIE PARAMETRÓW BUFORA DANYCH
W naszym przypadku aproksymowaü bĊdziemy opisany w rozdziale 1 współczynnik trafieĔ
(wyjĞcie SN) w funkcji takich zmiennych jak: wielkoĞü bufora danych, wielkoĞü obiektów
(tabel) w bazie danych, sposób i czĊstotliwoĞü dostĊpu do danych, wykorzystanie indeksów,
itp. (wejĞcia SN) [1]. W rzeczywistoĞci analiza tych parametrów (zmiennych) w kontekĞcie
strojenia wydajnoĞci bufora danych jest klasycznym zagadnieniem diagnostycznym, w
którym wykorzystywana jest wiedza eksperta (tu: administratora systemu Oracle).
OczywiĞcie model matematyczny (funkcja wielu zmiennych) nie jest znana. W rzeczywistoĞci
nawet trudno wyobraziü sobie zbudowanie takiego, nawet przybliĪonego, modelu. W
110
praktyce funkcja ta podana bĊdzie w postaci tabelarycznych danych bĊdących wynikiem np.
wielu przeprowadzonych eksperymentów na bazie. Zebrane dane zostaną zinterpretowane
przez sieü neuronową, a zbudowany w ten sposób neuronowy model wybranego aspektu
działania bazy danych zostanie uĪyty do predykcji wartoĞci współczynnika trafieĔ dla innych
wartoĞci zmiennych wejĞciowych.
4. ZADANIE TESTOWE
Korzystano z klasycznego w systemie Oracle schematu SUMMIT2, (skrypt o nazwie
summit2.sql instaluje siĊ automatycznie w systemie) do którego wprowadzono bardzo duĪą
iloĞü danych do tabel biorących udział w złączeniach N:N. Przykładowo zarejestrowano ok.
200 tysiĊcy faktur sprzedaĪy, ok. 100 tysiĊcy zamówieĔ, podobną liczbĊ stanów
magazynowych produktów oraz kilkanaĞcie tysiĊcy danych o klientach firmy. Dane
udostĊpniono trzem uĪytkownikom.
W losowy sposób, losowy uĪytkownik wybiera po kilkanaĞcie tysiĊcy wierszy z losowo
wybranego układu odpowiednich (moĪliwych do sensownego złączenia) tabel. Wymuszono
przy tym, aby wszystkie dane zostały normalnie przesłane do bufora (hint CACHE). IloĞü i
czĊstotliwoĞü pobrania okreĞlonego zbioru danych tworzą tzw. miarĊ charakteru
wykorzystania zgromadzonych danych [1]. WielkoĞci te (odpowiednio przeskalowane)
podawane są na wejĞcia sieci neuronowej. Kolejną daną wejĞciową jest wielkoĞü bufora
danych. WyjĞciem jest wyliczony dla takiego układu danych współczynnik trafieĔ w bufor.
Dla powyĪszych danych przeprowadzono proces uczenia wielowarstwowej sieci neuronowej
z jedną i dwoma warstwami ukrytymi metodą wstecznej propagacji błĊdów.
Praktyczne wykorzystanie nauczonej sieci bĊdzie polegało np. na otrzymaniu informacji o
charakterze wykorzystania zgromadzonych danych na podstawie aktualnej wielkoĞci bufora
czy teĪ o (przewidywanej) wielkoĞci współczynnika trafieĔ w bufor na podstawie zmiany
charakteru wykorzystania danych przez uĪytkowników bazy. Podobnie dla oczekiwanego
współczynnika trafieĔ moĪna by okreĞlaü konieczne zmiany w wielkoĞci bufora danych.
5. PODSUMOWANIE
W pracy zaprezentowano koncepcjĊ zastosowania sieci neuronowych w analizie danych
istotnych dla optymalnego zarządzania pamiĊcią w systemie Oracle. Uzasadniono powód ich
zastosowania oraz przedstawiono szkic rzeczywistych testów w Ğrodowisku Oracle
dostarczających bazĊ wiedzy wykorzystywaną w uczeniu wybranej struktury sieci
neuronowej.
Aby przekonaü siĊ o praktycznej celowoĞci zaprezentowanego w pracy podejĞcia naleĪałoby
wykonaü wiĊkszą liczbĊ testów na rzeczywistej bazie, zawierającej duĪą liczbĊ danych i
111
dodatkowo bardzo intensywnie eksploatowanej. Autor pracy prowadzi obecnie takie
eksperymenty, wyniki tych prac bĊdą sukcesywnie publikowane.
LITERATURA
[1] U. Harder, T. MacLeod: Predicting buffer hit ratios with neural networks, UK
Performance Engineering Workshop 1999, Bristol University (ISBN 0952402785)
[2] Oracle Concepts: Dokumentacja systemu Oracle
[3] Oracle Administrator's Guide: Dokumentacja systemu Oracle
[4] Oracle Designing and Tuning for Performance: Dokumentacja systemu Oracle
[5] Schemat SUMMIT2 (skrypt summit2.sql): dostĊpny na kaĪdej płycie instalacyjnej
systemu Oracle
[6] J. Wrembel, M. Jezierski, M. Zakrzewicz: System zarządzania bazą danych Oracle 7 i
Oracle 8, Wydawnictwo Nakom, PoznaĔ, 2000, ISBN 83-86969-34-2
[7] J. Korbicz, A. Obuchowicz, D. UciĔski: Sztuczne sieci neuronowe, Podstawy i
zastosowania, Akademicka Oficyna Wydawnicza PLJ, Warszawa 1994
[8] R. Tadeusiewicz: Sieci neuronowe, Warszawska Akademicka Oficyna Wydawnicza RM,
Warszawa 1993
112