administracja bazami danych

Transkrypt

ADMINISTRACJA
BAZAMI DANYCH
Rozdziaáy 27-29
Rok akademicki – 2007/2008
Notatki do przedmiotu „Administracja bazami danych”
SPIS TREĝCI
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD (ODG) ................................................................................................... 278
§ 27.1. NiezawodnoĞü wedáug Oracle a Data Guard ............................................................................................................................................ 278
§ 27.2. Funkcjonowanie i ogólny zarys mechanizmu. ......................................................................................................................................... 280
§ 27.3. Logiczna i fizyczna zastĊpcza baza danych ............................................................................................................................................. 283
27.3.1. Fizyczna zapasowa baza danych ..................................................................................................................................................... 283
27.3.2. Logiczna zapasowa baza danych ..................................................................................................................................................... 286
§ 27.4. Podsumowanie .......................................................................................................................................................................................... 288
28. STROJENIE INSTANCJI ................................................................................................................................................................................... 290
§ 28.1. Strojenie pamiĊci....................................................................................................................................................................................... 292
28.1.1. Strojenie bufora dziennika powtórzeĔ (REDO BUFFERS) ............................................................................................................ 293
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
SPIS TREĝCI
28.1.2. Strojenie przydziaáu prywatnego obszaru poleceĔ SQL ................................................................................................................. 295
28.1.3. Strojenie pamiĊci wspóádzielonej (Shared pool)...................................................................................................................... 296
28.1.4. Strojenie bufora danych ................................................................................................................................................................... 304
28.1.5. Zmniejszenie zajĊtoĞci pamiĊci operacyjnej ................................................................................................................................... 306
§ 28.2. Strojenie wykorzystania urządzeĔ dyskowych ......................................................................................................................................... 307
28.2.1. Diagnostyka obciąĪenia urządzeĔ dyskowych ................................................................................................................................ 307
28.2.2. RównowaĪenie obciąĪenia............................................................................................................................................................... 309
28.2.3. Migracja i áaĔcuchowanie bloków................................................................................................................................................... 311
28.2.4. Unikanie dynamicznego zarządzania rozszerzeniami ..................................................................................................................... 316
28.2.5. Strojenie procesu DBWR ................................................................................................................................................................ 318
28.2.6. Strojenie segmentów wycofywania ................................................................................................................................................. 318
28.2.7. Strojenie serwera w trybie SMU- System Management Undo ....................................................................................................... 319
28.2.8. Strojenie serwera w trybie RBU ...................................................................................................................................................... 321
§ 28.3. Strojenie punktów kontrolnych................................................................................................................................................................. 321
§ 28.4. Strojenie sortowaĔ .................................................................................................................................................................................... 323
§ 28.5. Zmniejszenie rywalizacji o semafory bufora dziennika powtórzeĔ ......................................................................................................... 325
§ 28.6. Minimalizacja rywalizacji o listĊ wolnych bloków .................................................................................................................................. 328
29. WYZWALACZE INSTEAD OF I SYSTEMOWE ............................................................................................................................................ 330
§ 29.1. Wyzwalacze INSTEAD OF ...................................................................................................................................................................... 330
§ 29.2. Wyzwalacze systemowe ........................................................................................................................................................................... 330
§ 29.3. Wyzwalacze a transakcje autonomiczne .................................................................................................................................................. 333
- 277 -
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
- 278 -
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD (ODG)
Oprócz podstawowych narzĊdzi backupu zabezpieczających przed utratą danych Oracle wprowadziáo do
swojego produktu narzĊdzie pod nazwa Oracle Data Guard (ODG).
System oparty o takie rozwiązanie, skáada siĊ z bazy produkcyjnej1 oraz z baz zapasowych2, gotowych
w kaĪdej chwili przejąü kontrolĊ w przypadku awarii bazy gáównej.
W Oracle Database 10g rozbudowano mechanizm Data Guard, wprowadzając opcjonalną moĪliwoĞü
kompresji i szyfrowania zapisów w dzienniku powtórzeĔ.
§ 27.1. NiezawodnoĞü wedáug Oracle a Data Guard
x
OdtwarzalnoĞü – jest to cecha pozwalająca na przywrócenie stanu systemu sprzed awarii tj.
poczynając od drobnych pomyáek typu usuniĊcie wiersza z tabeli lub caáej tabeli, a skoĔczywszy na
awarii platformy sprzĊtowej, gdzie utracie ulega wiĊkszoĞü danych.
x CiągáoĞü pracy – jest to dobrze zdefiniowany poziom dostĊpnoĞci, który najczĊĞciej wyraĪany jest
jako procentowa wartoĞü nieprzerwanego jego dziaáania w ciągu caáego roku.
1
2
Ang. Primary database – czasami nazywana teĪ bazą produkcyjną na której pracują aplikacje klienckie
Ang. Standby database – baza gotowa do przejĊcia roli bazy gáównej w przypadku jej awarii
-279-
x Wykrywanie uszkodzeĔ – potencjalne zagroĪenia powinny byü automatycznie wykrywane przez
odpowiednie narzĊdzia systemu oraz przekazywane do informacji osoby administrującej nim.
Analiza moĪliwoĞci Oracle Data Guard Ğwiadczy, Īe system opierający na nim swoją dziaáalnoĞü posiada
wszystkie wymienione wyĪej cechy. Jest on odtwarzalny, a moĪliwoĞü utraty danych w wypadku posiadania
kilku baz zapasowych jest redukowana do minimum.
DziĊki mechanizmowi fast-start failover klienci korzystający z systemu w wiĊkszoĞci przypadków nie
są nawet w stanie zauwaĪyü, Īe zaszáa awaria, poniewaĪ podczas usterki bazy produkcyjnej jedna z baz
zastĊpczych przejmuje automatycznie jej rolĊ.
Zaawansowane monitorowanie i zarządzanie pracą caáego sytemu opartego o Data Guard dostĊpne jest
z poziomu Enterprise Menager (Oracle 10g, 11g), przez co w áatwy sposób moĪna wykryü i zapobiec wielu
problemom mogącym doprowadziü w póĨniejszym czasie do awarii.
Fizyczne bazy zapasowe w Oracle Data Guard mogą byü uĪywane do generowania raportów, dziĊki
czemu znacznie zwiĊkszona zostaje wydajnoĞü systemu.
Technologia Data Guard zapewnia nie tylko wysoką niezawodnoĞü systemu i dostĊpnoĞü, ale potrafi
równieĪ znacznie zwiĊkszyü jego wydajnoĞü.
-280-
§ 27.2. Funkcjonowanie i ogólny zarys mechanizmu.
PoniĪszy rysunek przedstawia nam ogólną koncepcjĊ funkcjonowania Oracle Data Guard.
Rysunek 27.2.1. Ogólna koncepcja funkcjonowania Oracle Data Guard
Do poprawnego dziaáania Data Guard muszą byü speánione nastĊpujące wymagania:
x Gáówna baza danych musi dziaáaü w trybie ARCHIVELOG – tryb archiwizacji dziennika powtórzeĔ.
x KaĪda z baz musi posiadaü swój plik kontrolny.
-281-
Konfiguracja Oracle Data Guard opiera siĊ na jednej bazie produkcyjnej oraz jednej lub wiĊcej
bazach zastĊpczych.
ODG umoĪliwia skonfigurowanie do dziewiĊciu baz zastĊpczych(???) dla produkcyjnego systemu
serwera bazy danych.
Bazy te są poáączone ze sobą za pomocą sieci Oracle Net i mogą znajdowaü siĊ w dowolnych
lokalizacjach.
WaĪne jest, aby miaáy zapewnione swobodną transmisjĊ plików dziennika powtórzeĔ.
Przykáadowo moĪemy posiadaü jedną bazĊ zastĊpczą na maszynie, na której znajduje siĊ baza
produkcyjna oraz kilka baz zapasowych rozproszonych na zdalnych platformach sprzĊtowych.
Gáówna baza danych (produkcyjna) to baza, z którą áączy siĊ wiĊkszoĞü aplikacji. MoĪe ona byü záoĪona
z jednej instancji lub wielu instancji tej samej bazy danych.
Zapasowe bazy uaktualniane są poprzez aplikowanie do nich zmian, które zarejestrowane zostaáy
w plikach dziennika powtórzeĔ gáównej bazy produkcyjnej.
-282-
Transfer danych w kierunku z bazy gáównej do zapasowej jest automatyczny i moĪe odbywaü siĊ w
jednym z dwóch trybów:
x synchronicznym;
x asynchronicznym.
W trybie synchronicznym, kaĪda z wprowadzonych i zatwierdzonych zmian na bazie produkcyjnej nie
zostanie utracona w przypadku jej nieoczekiwanej awarii. Dzieje siĊ tak, poniewaĪ transakcje gáównej
bazy danych zostają zatwierdzone dopiero po pomyĞlnej ich transmisji do co najmniej jednej bazy
zapasowej. Tryb ten jest zazwyczaj wykorzystywany przy dziaáaniu ODG, gdzie skupiamy siĊ gáównie na
maksymalnej ochronie danych i maksymalnej dostĊpnoĞci.
JeĪeli zaĞ podczas konfiguracji, najwaĪniejsze bĊdzie dla nas uzyskanie maksymalnej wydajnoĞci, to
wtedy dane dziennika powtórzeĔ bazy produkcyjnej przesyáane bĊdą w trybie asynchronicznym do
pozostaáych baz zapasowych.
Oznacza to, Īe transakcje na bazie gáównej mogą byü zatwierdzane przed ich poprawnym
przetransmitowaniem na bazy zapasowej.
-283-
WiąĪe siĊ to z czĊĞciową rozbieĪnoĞcią danych pomiĊdzy bazą produkcyjną, a zapasowymi co moĪe
prowadziü do utraty niektórych informacji podczas awarii.
§ 27.3. Logiczna i fizyczna zastĊpcza baza danych
27.3.1. Fizyczna zapasowa baza danych
Zapasowe bazy danych mogą byü fizycznymi albo logicznymi kopiami bazy produkcyjnej.
Fizyczna baza danych jest kopią bazy produkcyjnej, synchronizowaną poprzez aplikowanie binarnych
zmian zarejestrowanych w dziennikach powtórzeĔ bazy produkcyjnej.
MoĪe ona pracowaü w trybie tylko do odczytu co pozwala na znaczne zwiĊkszenie mocy obliczeniowej
caáego systemu, niezbĊdnej miĊdzy innymi do szybkiego generowania raportów.
Spójrzmy na przykáad dziaáania bazy danych z mechanizmem Oracle Data Guard opartym o fizyczną
zapasową bazĊ danych i transportem danych poprzez proces ARC.
-284-
Rysunek 27.3.1.1. ODG z bazą fizyczną i przesyáaniem danych przez proces ARC0
W przypadku dziaáania takiej konfiguracji bazy danych, wszystkie transakcje aplikowane na bazĊ
produkcyjną trafiają do procesu LGWR3, który to rejestruje w bieĪących plikach dziennika powtórzeĔ zmiany
3
LGWR – proces odpowiedzialny za rejestrowanie w bieĪących plikach dziennika powtórzeĔ wszystkich zmian wprowadzonych do bazy danych
-285-
wprowadzone na tą bazĊ.
NastĊpnie pliki dziennika powtórzeĔ są archiwizowane na bazie gáównej przez proces ARC4 oraz
przesyáane do baz zapasowych.
Proces RFS5 na bazie zapasowej odbiera zarchiwizowane pliki z dziennika powtórzeĔ bazy produkcyjnej
i zapisuje je na bazie zastĊpczej.
W dalszym kroku pliki te przejmuje proces MRP6, który to aplikuje zmiany na fizyczną bazĊ danych.
W zaleĪnoĞci od trybu ochrony bazy danych moĪliwe jest odtwarzanie plików dziennika powtórzeĔ na
bazie zapasowej.
W przypadku, gdy czĊĞü plików przesyáanych z bazy produkcyjnej nie dotaráo do bazy czuwającej na
skutek awarii bądĨ duĪego obciąĪenia sieci, powinna nastąpiü operacja odtworzenia transmisji tych plików.
Odpowiedzialny jest za to proces FAL7.
Fizyczne bazy danych wymagają do poprawnego dziaáania identycznych platform sprzĊtowoprogramowych na wszystkich wspóádziaáających ze sobą bazach.
4
ARC – proces archiwizujący pliki dziennika powtórzeĔ
RFS – proces odbierający pliki dziennika powtórzeĔ z bazy produkcyjnej
6
MPR – proces aplikujący zmiany z plików dziennika powtórzeĔ do fizycznej bazy danych
7
FAL – proces, który odtwarza powstaáe na skutek awarii transmisji danych dziury w plikach dziennika powtórzeĔ przesáanych do czuwającej bazy danych
5
-286-
Tak restrykcyjnych wymagaĔ nie posiada inny typ baz zapasowych, a mianowicie bazy logiczne.
27.3.2. Logiczna zapasowa baza danych
Logiczna baza danych jest logiczną kopiĊ obiektów (indeksów, widoków, tabel itp.) i danych z bazy
gáównej poprzez aplikowanie poleceĔ SQL.
Polecenia SQL wydobywane są za pomocą narzĊdzia LogMiner z przesyáanych do baz zapasowych
zarchiwizowanych plików dziennika powtórzeĔ bazy produkcyjnej.
Logiczne zapasowe bazy danych pracują w trybie odczyt-zapis i mogą byü dodatkowo wykorzystywane
jako hurtownie danych.
PoniĪszy rysunek przedstawia pracĊ systemu opartego o logiczną zapasową bazĊ danych.
-287-
Rysunek 27.3.2.1. ODG z bazą logiczną i przesyáem danych przez proces ARC0
Gáówną róĪnicą w stosunku do bazy fizycznej jest tu proces aplikujący zmiany na logiczną bazĊ
zapasową, w tym przypadku jest to LSP8.
8
LSP - proces aplikujący polecenia SQL znajdujące siĊ w plikach dziennika powtórzeĔ na bazĊ logiczną
-288-
Zarządzanie zarówno bazą produkcyjną jak i zapasowymi moĪe odbywaü siĊ z linii poleceĔ SQL lub
z poziomu tzw. zarządcy Data Guard, który posiada zarówno interfejs graficzny (zintegrowany w Oracle
Enterprise Manager) jak i tekstowy (DGMGRL).
Wszystkie zadania związane z konfiguracją Ğrodowiska ODG moĪna zautomatyzowaü w prosty sposób
przez wykorzystanie Oracle Enterprise Manager.
§ 27.4. Podsumowanie
Zalety:
Administratorzy baz opartych o ODG nie muszą martwiü siĊ o codzienne rĊczne wykonywanie kopii
bezpieczeĔstwa, poniewaĪ ciągle aktualizowane bazy zapasowe wyrĊczają ich z tego obowiązku.
DuĪa elastycznoĞü pozwalająca na zapewnienie zwiĊkszonej wydajnoĞci oraz wzrostu niezawodnoĞci
i dostĊpnoĞci systemu bazodanowego przy stosunkowo maáych nakáadach potrzebnych na wzrost obu tych
cech.
OdpornoĞü na nieplanowane awarie, jak i zaplanowane przestoje w pracy gáównej bazy, co zapewnia
duĪą dostĊpnoĞü systemu.
Wysoka ochrona danych skáadowanych w bazie. ODG posiada mechanizmy, dziĊki którym awaria
fizyczna plików na produkcyjnej bazie danych nie zostanie rozpropagowana na bazy zapasowe.
-289-
Wzrost efektywnoĞci wykorzystywanych zasobów. Fizyczne zapasowe bazy danych bĊdące
aktualizowane zarchiwizowanymi plikami dziennika powtórzeĔ mogą byü otwarte w trybie tylko do
odczytu. DziĊki temu moĪna w swobodny sposób uĪyü ich jako baz danych, na których wykonywane są
róĪnego rodzaju analizy. Pozwala to w znacznej mierze odciąĪyü gáówny serwer bazy danych biorąc pod
uwagĊ, Īe to wáaĞnie zapytania przewaĪnie wykorzystują duĪą moc obliczeniową procesora oraz iloĞü
dostĊpnej pamiĊci operacyjnej.
Wysoka ochrona danych skáadowanych w bazie. ODG posiada mechanizmy, dziĊki którym awaria
fizyczna plików na produkcyjnej bazie danych nie zostanie rozpropagowana na bazy zapasowe.
Jednak pomimo wielu plusów przemawiających na korzyĞü ODG podczas pracy z tym produktem jest
takĪe kilka cech negatywnych.
Jedną z nich jest wystĊpowanie maáego opóĨnienia pomiĊdzy zawartoĞcią danych z gáównej bazy,
a bazami zastĊpczymi. MoĪe to niekiedy doprowadziü do utraty niewielkiej iloĞci danych. Jednak iloĞü
informacji, które mogą zostaü zniszczone zaleĪy tak naprawdĊ od administratora, poniewaĪ to on okreĞla jak
wielkie ma byü to opóĨnienie. Poprzez analizĊ dziaáania systemu powinien on w jak najlepszy sposób
dostosowaü czĊstotliwoĞü archiwizacji mając na wzglĊdzie zarówno bezpieczeĔstwo danych i moĪliwoĞci
wydajnoĞciowe platformy sprzĊtowej.
28. STROJENIE INSTANCJI
- 290 -
Przed przystąpieniem do omawiania poszczególnych kroków strojenia instancji naleĪy najpierw wyjaĞniü
czym jest strojenie.
Shared pool - Obszar wspóádzielony
Database buffers
Bufor danych
Shared SQL Area
Redo
buffers
Bufor
dziennika
powtórzeĔ
Wspóádzielony obszar poleceĔ SQL
Dictionary cache
Bufor sáownika danych
Inne
Rysunek 28.1. Globalny obszar systemowy SGA.
Strojenie jest procesem dokonywania modyfikacji w sprzĊcie lub oprogramowaniu, którego celem jest
zmiana wáaĞciwoĞci systemu. NaleĪy podkreĞliü, Īe w powyĪszej definicji nie wystĊpuje sáowo wydajnoĞü,
poniewaĪ strojenie nie koniecznie ma sáuĪyü do polepszania wydajnoĞci.9
9
Whalen Ed.: Oracle – Optymalizacja wydajnoĞci. Helion, 2003 – str. 17
- 291 -
KoniecznoĞü strojenia moĪe zachodziü m.in. z nastĊpujących powodów:
Strojenie przetwarzania. Strojenie polegające na takim skonfigurowaniu systemu, aby moĪliwe byáo
przetwarzanie najwiĊkszej iloĞci danych w najkrótszym czasie.
Strojenie czasu odpowiedzi. Polega na takim skonfigurowaniu systemu, aby Īądane dane zwracane byáy
jak najszybciej.
Strojenie systemu dla duĪej liczby uĪytkowników. Strojenie polegające na skonfigurowaniu systemu,
aby mógá on obsáugiwaü jednoczeĞnie jak najwiĊkszą liczbĊ uĪytkowników.
Strojenie czasu áadowania. Strojenie polegające na poprawie parametrów procesu áadowania.
Strojenie wydajnoĞci procesu tworzenia kopii zapasowych i odtwarzania. Strojenie, którego celem
jest zminimalizowanie czasu tworzenia kopii bezpieczeĔstwa i odtwarzania systemu po awarii.
Do gáównych etapów strojenia instancji bazy danych Oracle naleĪą:
x
strojenie przydziaáu pamiĊci (SGA, PGA),
x
strojenie wykorzystania urządzeĔ dyskowych,
x
strojenie segmentów wycofywania (Rollback segments, undomanagement),
x
strojenie punktów kontrolnych (Checkpoint),
- 292 -
x
strojenie sortowaĔ,
x
zmniejszenie rywalizacji o semafory bufora dziennika powtórzeĔ,
x
minimalizacja rywalizacji o listĊ wolnych bloków.
§ 28.1. Strojenie pamiĊci
Instancja systemu Oracle przechowuje dane w dwóch miejscach: w pamiĊci oraz na dysku.
Przechowywanie danych w pamiĊci operacyjnej powoduje bardzo wysoką wydajnoĞü, ale jednoczeĞnie
wysoki koszt.
Z drugiej strony dysk moĪe przechowywaü ogromną iloĞü danych przy jednoczesnym relatywnie niskim
koszcie w stosunku do pamiĊci.
Biorąc pod uwagĊ wydajnoĞü osiąganą przy przechowywaniu danych w pamiĊci, naleĪy przechowywaü
w niej dane zawsze kiedy to moĪliwe. UwzglĊdniając ogromną iloĞü danych oraz liczbĊ uĪytkowników,
którzy potrzebują tych danych, trzeba uwzglĊdniü moĪliwoĞü wystĊpowania konfliktów związanych
z pamiĊcią. ĩeby moĪliwie efektywnie wykorzystaü uĪycie pamiĊci, naleĪy osiągnąü równowagĊ miĊdzy
pamiĊcią uĪywana przez bufor systemu Oracle oraz pamiĊcią wykorzystywaną przez uĪytkowników.
- 293 -
Strojenie pamiĊci w instancji systemu Oracle obejmuje nastĊpujące obszary:
x
strojenie bufora dziennika powtórzeĔ (Redo buffers),
x
strojenie przydziaáu prywatnego obszaru poleceĔ SQL (Shared SQL Area) ,
x
strojenie pamiĊci wspóádzielonej (Shared pool),
x
strojenie bufora danych (Database buffers),
x
zmniejszanie zajĊtoĞci pamiĊci operacyjnej.
28.1.1. Strojenie bufora dziennika powtórzeĔ (REDO BUFFERS)
W przypadku systemów wyposaĪonych w szybki procesor i stosunkowo wolny dysk, pozostaáa czĊĞü
bufora moĪe byü w caáoĞci zapeániona zanim LGWR zdąĪy zapisaü odpowiednia porcjĊ informacji na dysk.
Wówczas bufor ten moĪe staü siĊ ”wąskim gardáem” systemu. Z tego powodu wiĊkszy rozmiar bufora
dziennika powtórzeĔ powoduje mniejsze prawdopodobieĔstwo wystąpienia kolizji pomiĊdzy nowymi
wpisami a wpisami starymi – bĊdącymi w trakcie zapisu na dysk.
PoniewaĪ
rozmiar
bufora
dziennika
powtórzeĔ
(zdefiniowany
parametrem
inicjalizacyjnym
LOG_BUFFER) jest stosunkowo niewielki w porównaniu z caáym obszarem SGA, nawet maáe zwiĊkszenie
tego rozmiaru moĪe znacząco poprawiü wydajnoĞü.
- 294 -
OkreĞlenie rywalizacji o bufor dziennika powtórzeĔ moĪna dokonaü przeglądając dynamiczną
perspektywĊ V$SYSSTAT szukając tam statystyki REDO BUFFER ALLOCATION RETRIES. Statystyki
te moĪna uzyskaü za pomocą zapytania:
SQL> SELECT name, value FROM v$sysstat
WHERE name = ‘redo buffer allocation retries’;
NAME
VALUE
redo buffer allocation retries
0
WartoĞü parametru REDO BUFFER ALLOCATION RETRIES powinna byü bliska zeru.
JeĞli liczba ta permanentnie roĞnie w trakcie dziaáania systemu, wówczas naleĪy zwiĊkszyü wielkoĞü
buforu za pomocą parametru LOG_BUFFER.
SQL> ALTER SYSTEM SET log_buffer=7024640 SCOPE=spfile;
WielkoĞü tego parametru wyraĪona jest w bajtach i powinna byü wielokrotnoĞcią rozmiaru bloku systemu
plików (parametr DB_BLOCK_SIZE).
JeĪeli powiĊkszenie bufora nie przyniesie oczekiwanych rezultatów, wówczas naleĪy rozwaĪyü:
x
usprawnienie procesów wykonywania punktu kontrolnego (CKPT),
x
poprawienie wydajnoĞci archiwizacji dziennika powtórzeĔ (byü moĪe poprzez przeniesienie
- 295 -
plików dziennika na szybsze urządzenia zewnĊtrzne / dyski).
28.1.2. Strojenie przydziaáu prywatnego obszaru poleceĔ SQL
Prywatny obszar SQL jest obszarem pamiĊci zawierającym miĊdzy innymi bufory podrĊczne. KaĪda
sesja, w której jest wykonywane zapytanie SQL, posiada taki prywatny obszar. Zmniejszenie tego obszaru
moĪe okazaü siĊ efektywne w Ğrodowisku, gdzie pracuje wielu uĪytkowników.10
Strojenie prywatnego obszaru SQL polega na zidentyfikowaniu zbĊdnych parsowaĔ i nastĊpnie
ograniczeniu ich liczby. PoniewaĪ operacja parsowania nie musi byü wykonywana czĊsto (jest wykonywana
w miarĊ udostĊpniania pamiĊci), toteĪ zmniejszenie liczby pasowaĔ znacząco wpáywa na wydajnoĞü
systemu.
Aby okreĞliü liczbĊ niepotrzebnych parsowaĔ moĪna wykorzystaü widok V$SQLAREA wykonując
zapytanie:
SQL> SELECT sql_text, parse_calls, executions FROM v$sqlarea;
SQL_TEXT
select * from osoby
select * from pensje where pensja > 2000
10
Whalen Ed.: Oracle – Optymalizacja wydajnoĞci. Helion, 2003 – str.50
PARSE_CALLS
32
2
EXECUTIONS
32
24
- 296 -
Kiedy wartoĞü PARSE_CALLS jest bliska wartoĞci EXECUTIONS, wówczas liczba parsowaĔ jest zbyt
duĪa (kursory nie są wielokrotnie wykorzystywane).
Aby aplikacja mogáa wielokrotnie wykorzystywaü te same kursory musi posiadaü wystarczająco duĪą
pamiĊü podrĊczną.
WielkoĞü tĊ moĪna zmieniaü za pomocą parametru konfiguracyjnego OPEN_CURSORS. Parametr ten
okreĞla maksymalną liczbĊ otwartych kursorów przez aplikacjĊ uĪytkownika. Im wiĊksza jest wartoĞü tego
parametru, tym wiĊcej pamiĊci prywatnej rezerwuje sesja uĪytkownika i tym wiĊksze są moĪliwoĞci
przechowywania informacji związanej z kursorami. Warunkiem koniecznym wielokrotnego wykorzystania
kursorów jest takĪe aby aplikacja nie zwalniaáa obszaru pamiĊci prywatnej przy zamkniĊciu kursora lub przy
zakoĔczeniu transakcji.
28.1.3. Strojenie pamiĊci wspóádzielonej (Shared pool)
Aby zoptymalizowaü pamiĊü wspóádzieloną, naleĪy przeanalizowaü jej poszczególne czĊĞci. PamiĊü
wspóádzielona skáada siĊ z bibliotecznej pamiĊci podrĊcznej i bufora sáownika danych.
DostĊp do informacji w pamiĊci wspóádzielonej jest o wiele czĊstszy niĪ do bufora danych, zatem
odpowiednie dostrojenie tego obszaru ma bardzo istotne znaczenie.
- 297 -
BIBLIOTECZNA PAMIĉû PODRĉCZNA
Biblioteczna pamiĊü podrĊczna zawiera wspóádzielone obszary SQL oraz PL/SQL. Przechowują one
m.in. ostatnio wykonywane zapytania(na wypadek powtórzenia takiego samego zapytania przez któregoĞ
z uĪytkowników), oraz kody wykonywanych procedur, funkcji i pakietów PL/SQL.
Strojenie bibliotecznej pamiĊci podrĊcznej polega gáównie na zwiĊkszeniu tzw. wspóáczynnika
trafieĔ(ang. hit ratio) oraz zwiĊkszeniu szybkoĞci uzyskiwania dostĊpu do bufora biblioteki, uzyskiwane
poprzez dáuĪsze przechowywanie rzadziej wykonywanych zapytaĔ SQL.
Nietrafienie w bufor moĪe zajĞü, gdy parsowane jest zapytanie a jego poprzednio sparsowana postaü juĪ
nie istnieje buforze lub gdy próbujemy wykonaü zapytanie, a obszar pamiĊci wspóáuĪytkowanego SQL
przechowujący sparsowaną postaü tego zapytania zostaá zwolniony.
Korzystanie z wczeĞniej sparsowanych zapytaĔ SQL i PL/SQL jest moĪliwe jeĞli speánione bĊdą poniĪsze
kryteria:
ciąg znaków zapytania SQL musi byü identyczny z ciągiem znaków zapytania przechowywanego
w buforze (dotyczy to takĪe: spacji, komentarzy, wielkoĞci liter , itp.).
PoniĪsze zapytania nie mogą uĪywaü tego samego wspóádzielonego obszaru SQL:
- 298 -
SQL> SELECT * FROM Osoby;
SQL> SELECT * FROM osoby;
SQL> SELECT *
FROM osoby;
Referencje do obiektów schematu w zapytaniu SQL muszą wskazywaü na te same obiekty w tym samym
schemacie jak w zapytaniu przechowywanym w buforze. Przykáadowo jeĞli schematy uĪytkowników Jan
oraz Adam posiadają tabelĊ osoby, i jeĞli ci uĪytkownicy wykonają zapytanie:
SELECT * FROM osoby;
wówczas nie moĪliwe bĊdzie wspóádzielonie tego samego obszaru SQL.
MoĪliwe to byáoby gdyby obaj wykonali np. zapytanie:
SQL> SELECT * FROM adam.osoby;
Zmienne wiązane w zapytaniach SQL muszą mieü taką samą nazwĊ i byü tego samego typu. Przykáadowo
poniĪsze zapytania nie bĊdą uĪywaáy tego samego obszaru SQL:
SQL> SELECT * FROM osoby WHERE wydzial=:wydzial_nr;
SQL> SELECT * FROM osoby WHERE wydzial=:w_nr;
- 299 -
Zapytania SQL muszą mieü plany wykonania wyznaczone w tym samym trybie pracy optymalizatora.
W przypadku uĪycia optymalizatora kosztowego identyczny musi byü teĪ cel optymalizacji.
Statystyki opisujące efektywnoĞü bibliotecznej pamiĊci podrĊcznej są zawarte w perspektywie
V$LIBRARYCACHE. Najistotniejszymi kolumnami w tej tabeli są kolumny: PINS oraz RELOADS.
Pierwsza kolumna zawiera informacje o liczbie odwoáaĔ do obiektu znajdującego siĊ w buforze, natomiast
druga informuje o liczbie odwoáaĔ nietrafionych w bufor, powodujących ponowne zaáadowanie obiektu do
bufora. Aby wyĞwietliü liczbĊ nietrafieĔ do bufora moĪna posáuĪyü siĊ poniĪszym zapytaniem:
SQL> SELECT SUM(reloads) “nietrafieĔ”,
SUM(pins) “odwoáania do obiektu”,
100*(SUM(reloads)/SUM(pins)) “wsp. nietrafieĔ %”
FROM v$librarycache;
nietrafieĔ
odwoáania do obiektu
WSP. nietrafieĔ %
18
2821
0,638072
Z powyĪszego, przykáadowego raportu wynika, Īe wszystkich odwoáaĔ do SQL, PL/SQL oraz innych
obiektów byáo w sumie 2821, z czego 18 musiaáo zostaü powtórnie zaáadowane. Z tego wynika, iĪ tylko
0,63% zapytaĔ musiaáo zostaü sparsowanych powtórnie.
MoĪna równieĪ wygenerowaü podobny raport z podziaáem na typy obiektów:
- 300 -
SQL> SELECT namespace “typ objektu”, SUM(reloads) “nietrafieĔ”,
SUM(pins) “odwoáania”, 100*(SUM(reloads)/SUM(pins)) “wsp.nietrafieĔ %”
FROM v$librarycache;
typ
nietrafieĔ
odwoáania
wsp.nietrafieĔ %
SQL AREA
TABLE/PROCEDURE
BODY
TRIGGER
INDEX
CLUSTER
OBJECT
6
8
0
0
0
0
0
1426
402
0
0
24
16
0
0,420757
1,99005
0
0
0
0
0
8 rows selected.
Wspóáczynnik nietrafieĔ powinien byü mniejszy niĪ 1. JeĞli tak nie jest naleĪy podjąü kroki zmierzające
do obniĪenia tej wartoĞci. MoĪna tego dokonaü poprzez wykonywanie identycznych zapytaĔ lub przez
zwiĊkszenie rozmiaru bibliotecznej pamiĊci podrĊcznej za pomocą parametru konfiguracyjnego
SHARED_POOL_SIZE.
Nie naleĪy jednak przydzielaü wiĊcej pamiĊci niĪ jest fizycznie dostĊpne, gdyĪ stronicowanie pamiĊci
moĪe caákowicie zniweczyü zalety bufora biblioteki.11
11
Whalen Ed.: Oracle – Optymalizacja wydajnoĞci. Helion, 2003 – str.53
- 301 -
STROJENIE BUFORA SàOWNIKA DANYCH
Bufor sáownika danych jest zbiorem tabel i perspektyw zawierających informacje o wszystkich obiektach
bazy danych. Przechowywane są tu informacje, dotyczące miĊdzy innymi: uĪytkowników i ich uprawnieĔ,
wiĊzów integralnoĞci zdefiniowanych na tabelach bazy, nazw i typów danych wszystkich kolumn i tabel,
alokacji przestrzeni wykorzystywanej na potrzeby schematów obiektów.
Strojenie bufora sáownika danych odgrywa znaczącą rolĊ w caáym procesie strojenia instancji, gdyĪ
ewentualne „wąskie gardáa” istniejące w tym buforze są odczuwalne przez wszystkich uĪytkowników.
Aby sprawdziü wydajnoĞü bufora sáownika danych naleĪy posáuĪyü siĊ statystykami zawartymi
w dynamicznej perspektywie V$ROWCACHE.
NajwaĪniejszymi kolumnami w tej perspektywie są kolumny: GETS, GETMISSES.
Kolumna GETS zawiera liczbĊ odwoáaĔ do obiektu, natomiast kolumna GETMISSES zawiera liczbĊ
odwoáaĔ do obiektu zakoĔczonych nietrafieniem w bufor.
Aby wyĞwietliü wspóáczynnik nietrafieĔ moĪna posáuĪyü siĊ poniĪszym zapytaniem:
SQL> SELECT SUM(getmisses) Ile_nietrafien,
SUM(gets) Ile_odwoáan,
- 302 -
100*(SUM(getmisses)/SUM(gets)) Wspolczynnik_nietrafien
FROM v$rowcache;
Ile_nietrafien
Ile_odwoáan
Wspolczynnik_nietrafien
452
2478
18,24052
JeĞli chcielibyĞmy obejrzeü statystykĊ nietrafieĔ dla poszczególnych typów obiektów sáownika, wówczas
naleĪaáoby wykonaü nastĊpujące zapytanie:
SQL> SELECT parameter Typ,getmisses Nietrafien,
gets Odwolania,
100*(SUM(getmisses)/SUM(gets)) Wspolczynnik_ nietrafien
FROM v$rowcache;
Typ
dc_free_extents
dc_used_extents
dc_segments
dc_tablespaces
dc_tablespace_quotas
dc_files
dc_users
dc_rollback_segments
Nietrafien Odwolania Wspolczynnik_nietrafien
0
0
184
3
0
0
25
21
0
0
518
21
0
0
126
235
35,52123
14,28571
19,84126
8,93617
dc_objects
dc_global_oids
dc_constraints
dc_objects_ids
dc_sequences
dc_usernames
dc_database_links
dc_histogram_defs
dc_table_scns
...
- 303 -
167
6
0
164
1
10
0
24
0
...
685
16
0
687
1
192
0
24
0
...
24,37956
37,5
100
5,20833
100
...
„W przypadku intensywnie wykorzystywanego bufora sáownika wspóáczynnik nietrafieĔ nie powinien
byü wiĊkszy niĪ 10-15%.
JeĪeli wspóáczynnik ten roĞnie w trakcie pracy serwera, naleĪy zwiĊkszyü iloĞü pamiĊci dla tego bufora
przez podniesienie wartoĞci tego samego parametru, co dla bufora biblioteki – SHARED_POOL_SIZE.”
Zazwyczaj podstrojenie wspóáczynnika nietrafieĔ we wspóádzielony obszar SQL gwarantuje poprawną
wartoĞü nietrafieĔ w bufor sáownika danych.
Jest to spowodowane sposobem gospodarowania pamiĊcią przez system Oracle, który preferuje dáuĪsze
utrzymywanie w pamiĊci obiektów ze wspóádzielonego obszaru poleceĔ SQL niĪ obiektów z bufora
sáownika danych.
- 304 -
28.1.4. Strojenie bufora danych
Bufor danych jest najwaĪniejszym buforem spoĞród wszystkich buforów wystĊpujących w systemie
Oracle. Bufor ten zajmuje wiĊkszoĞü obszaru SGA i jest wykorzystywany podczas wykonywania kaĪdej
operacji odczytywania i modyfikowania danych z bazy.
Podczas wykonywania tych operacji proces serwera sprawdza najpierw, czy Īądane dane znajdują siĊ juĪ
w SGA. JeĞli tak, dane są bezpoĞrednio obsáugiwane w SGA, natomiast jeĞli nie dane zostaną obsáuĪone po
uprzednim skopiowaniu ich z dysku do SGA.
Strojenie bufora danych polega na dobraniu takiego rozmiaru tego bufora, aby zagwarantowaü dobry
wspóáczynnik trafieĔ. Przy dobieraniu rozmiaru naleĪy pamiĊtaü, Īe zaleĪnoĞü miĊdzy wielkoĞcią bufora
a wspóáczynnikiem trafieĔ nie jest liniowa. Przy duĪym wspóáczynniku trafieĔ dodatkowe zwiĊkszenie
bufora daje znikome efekty, moĪe natomiast zwiĊkszyü zuĪycie czasu procesora, który jest obciąĪony
zarządzaniem zbyt duĪą listą LRU.
Statystyka odwoáaĔ do bufora danych jest przechowywana w dynamicznej perspektywie V$SYSSTAT,
której najwaĪniejszymi kolumnami są:
- 305 -
DB BLOCK GETS
- Zwykáe odwoáania do bufora.
CONSISTENT GETS
- Odwoáania do bufora w trybie spójnym. Suma DB BLOCK
CONSISTENT GETS daje liczbĊ wszystkich odwoáaĔ od bufora.
PHYSICAL READS
- Ogólna liczba odwoáaĔ do bufora, które zakoĔczyáy siĊ fizycznym odczytem
danych z dysku, czyli nietrafieni.
GETS i
Aby uzyskaü informacje dotyczące poprawnoĞci dziaáania bufora moĪna posáuĪyü siĊ poniĪszym
poleceniem:
SQL> SELECT name, value FROM v$sysstat
WHERE name in
(‘db block gets’,‘consistent gets’,‘physical reads’);
NAME
VALUE
db block gets
155
consistent gets
5293
physical reads
334
Wspóáczynnik trafieĔ wylicza siĊ na podstawie wzoru:
Cache Hit Ratio = 1-(PHYSICAL READS/(DB BLOCK GETS + CONSISTENT GETS))
Cache Hit Ratio = 1-(334/(155+5293))=1-0,0613=0.938
- 306 -
Zatem w powyĪszym przykáadzie wspóáczynnik trafieĔ jest równy 93,8%.
JeĞli wspóáczynnik trafieĔ jest mniejszy niĪ 70% - 80%, naleĪy zwiĊkszyü wielkoĞü bufora danych w celu
poprawienia wydajnoĞci. MoĪna to zrobiü poprzez zwiĊkszenie wartoĞci parametru inicjalizacyjnego
DB_CACHE_SIZE.
Firma Oracle nie zaleca obecnie uĪywania do tego celu parametru DB_BLOCK_BUFFERS, który zostaá
pozostawiony w celu zachowania wstecznej kompatybilnoĞci.
28.1.5. Zmniejszenie zajĊtoĞci pamiĊci operacyjnej
Zmniejszenie wielkoĞci wykorzystywanej pamiĊci operacyjnej moĪna uzyskaü zarówno przez
zmniejszenie liczby równoczesnych sesji uĪytkownika, jak i poprzez zdefiniowanie maksymalnego czasu
bezczynnoĞci. Skorzystanie z pierwszego sposobu polega na zmniejszeniu wartoĞci parametru
inicjalizacyjnego
LICENSE_MAX_SESSIONS.
Aby zdefiniowaü maksymalny czas (w minutach) bezczynnoĞci uĪytkownika naleĪy w profilu
przypisanym temu uĪytkownikowi okreĞliü zasób IDLE_TIME.
- 307 -
§ 28.2. Strojenie wykorzystania urządzeĔ dyskowych
W procesie strojenia instancji kluczową rolĊ odgrywa optymalne wykorzystanie urządzeĔ dyskowych.
Do najwaĪniejszych zadaĔ administratora systemu Oracle, mających na celu strojenie urządzeĔ
dyskowych naleĪą:
x
diagnostyka obciąĪenia urządzeĔ dyskowych,
x
równowaĪenie obciąĪenia urządzeĔ dyskowych,
x
unikanie migracji i áaĔcuchowania bloków,
x
unikanie dynamicznego zarządzania rozszerzeniami,
x
strojenie procesu DBWR.
28.2.1. Diagnostyka obciąĪenia urządzeĔ dyskowych
Bardzo waĪnym etapem strojenia instancji bazy danych jest strojenie dostĊpu do dysków.
NajwaĪniejsze informacje o operacjach wejĞcia-wyjĞcia dysku moĪemy znaleĨü w dynamicznej tabeli
V$FILESTAT, której najwaĪniejszymi kolumnami są: PHYRDS, PHYWRTS.
Pierwsza kolumna zawiera liczbĊ fizycznych odczytów wykonywanych na plikach danych, natomiast
druga zawiera liczbĊ fizycznych zapisów na tych plikach.
- 308 -
Informacja w V$FILESTAT stosuje wewnĊtrzne identyfikatory plików, zatem aby uzyskaü peáne nazwy
tych plików moĪna skorzystaü z perspektywy sáownikowej V$DATAFILE. Jej najwaĪniejszymi kolumnami
są: NAME – zawiera nazwĊ pliku, STATUS – informuje o typie pliku i jego bieĪącym statusie, oraz BYTES –
mówiąca o wielkoĞci danego pliku.
Aby okreĞliü liczbĊ fizycznych operacji na plikach moĪna skorzystaü ze wspomnianych wyĪej obu tabel
wykonując poniĪsze zapytanie:
SQL> SELECT substr(name,1,40) Plik, phyrds, phywrts, status, bytes
FROM v$datafile df, v$filestat fs
WHERE df.file# = fs.file#;
PLIK
C:\ORACLE\ORADATA\TEST\SYSTEM01.DBF
C:\ORACLE\ORADATA\TEST\TEST_DANE.DBF
C:\ORACLE\ORADATA\TEST\TEST_RBS.DBF
PHYRDS
1579
8
7
PHYWRTS
178
53
96
STATUS
SYSTEM
ONLINE
ONLINE
BYTES
209715200
209715200
62914560
Liczba operacji wejĞcia-wyjĞcia jest sumą odczytów i zapisów.
NaleĪy pamiĊtaü aby nie przekraczaü fizycznych ograniczeĔ dysku, gdyĪ problemy z wydajnoĞcią
jednego dysku, w zaleĪnoĞci od typu danych mogą spowolniü pracĊ caáego systemu.
- 309 -
RedukcjĊ przeciąĪenia dysków moĪna osiągnąü przez:
x
zrównowaĪenie obciąĪenia,
x
odpowiednie skáadowanie danych w blokach,
x
unikanie dynamicznego zarządzania rozszerzeniami,
x
unikanie dynamicznego zarządzania przestrzenią w segmentach wycofania.
28.2.2. RównowaĪenie obciąĪenia
RównowaĪenie
obciąĪenia
urządzeĔ
dyskowych
polega
na
umieszczeniu
równoczeĞnie
wykorzystywanych zasobów systemu Oracle na róĪnych fizycznych dyskach.
Rozmieszczenie plików danych oraz plików dziennika powtórzeĔ na róĪnych dyskach jest szczególnie
zalecane przy duĪej liczbie operacji modyfikowania, wstawiania i usuwania danych, które wymagają
równoczesnego dostĊpu do danych i które generują intensywne zapisy do dziennika powtórzeĔ.
Biorąc pod uwagĊ sposób dziaáania procesu LGWR (koĔczy zapis do grupy dzienników w momencie
zakoĔczenia zapisu do wszystkich plików grupy), naleĪy pamiĊtaü aby podczas stosowania wielu kopii pliku
dziennika powtórzeĔ w grupie, uĪywane do tego celu dyski miaáy podobną wydajnoĞü. W przeciwnym razie
- 310 -
jeden plik dziennika umieszczony na wolniejszym dysku bĊdzie znacząco zmniejszaá wydajnoĞü procesu
LGWR.
Bardzo dobrym przykáadem równowaĪenia obciąĪenia urządzeĔ dyskowych jest umieszczenie
równoczeĞnie wykorzystywanych tabel (np. czĊsto áączonych) w róĪnych przestrzeniach tabel, na róĪnych
dyskach. Wówczas równolegáy dostĊp do tych tabel spowoduje przyĞpieszenie operacji áączenia. PoniĪej
zostaá przedstawiony inny przykáad rozproszenia tabeli na róĪne dyski korzystający z mechanizmu alokacji
rozszerzeĔ.
SQL> CREATE TABLESPACE rozproszona_przestrzeĔ_tabel
DATAFILE ‘C:\oradata\file1.dbf’ size 10M,
‘D:\oradata\file2.dbf’ size 10M,
‘E:\oradata\file3.dbf’ size 10M,
‘F:\oradata\file4.dbf’ size 10M;
SQL> CREATE TABLE rozproszona_tabela(…)
TABLESPACE rozproszona_przestrzeĔ_tabel
STORAGE (
INITIAL 10000K
NEXT 10000K
MINEXTENTS 4
PCTINCREASE 0
);
- 311 -
Pierwsze polecenie tworzy przestrzeĔ tabel skáadającą siĊ z czterech plików umieszczonych na róĪnych
dyskach, natomiast drugie tworzy tabelĊ w utworzonej wczeĞniej przestrzeni.
Parametry skáadowania tabeli umoĪliwiają przydzielenie jej pamiĊci we wszystkich plikach utworzonej
przestrzeni, z których kaĪdy znajduje siĊ na innym dysku.
Innym sposobem rozpraszania danych jest wykorzystanie mechanizmu partycjonowanych tabel.
RównowaĪąc obciąĪenie urządzeĔ dyskowych, nie ma potrzeby rozdzielania tabel i związanych z nimi
indeksów, gdyĪ dostĊp do nich nie jest równolegáy lecz sekwencyjny. Najpierw są odczytywane indeksy,
a nastĊpnie bloki tabel.
28.2.3. Migracja i áaĔcuchowanie bloków
Bardzo waĪną rolĊ w procesie strojenia wykorzystania urządzeĔ dyskowych odgrywa proces redukcji
operacji migracji oraz áaĔcuchowania rekordów.
Operacje te wystĊpują, gdy zmodyfikowanie wiersza powoduje zwiĊkszenie jego rozmiaru na tyle, iĪ nie
mieĞci siĊ on juĪ w jednym bloku danych. W takich sytuacjach system Oracle szuka innego bloku, który jest
w stanie pomieĞciü caáy, zmodyfikowany rekord. JeĞli taki blok zostanie znaleziony, wówczas
zmodyfikowany rekord jest do niego przenoszony i proces ten nazywany jest migracją rekordu.
- 312 -
Migracja rekordu zostaáa zilustrowana rysunkiem 28.2.3.1.
W przypadku nie znalezienia takiego bloku, Oracle dzieli zmieniony rekord na kilka czĊĞci i umieszcza je
w róĪnych blokach tworząc tzw. áaĔcuch bloków. Sytuacja taka zostaáa zobrazowana rysunkiem 28.2.3.2.
àaĔcuchowanie rekordu powoduje, iĪ póĨniejsze odczytanie tego rekordu zajmuje wiĊcej niĪ jedną
operacjĊ wejĞcia-wyjĞcia, gdyĪ wczytane do pamiĊci SGA bĊdą musiaáy byü wszystkie bloki danych
zawierające omawiany rekord.
Rysunek 28.2.3.1. Migracja rekordu
- 313 -
Rysunek 28.2.3.2. àaĔcuchowanie rekordu
Aby znaleĨü w tabeli rekordy, które ulegáy migracji lub áaĔcuchowaniu, naleĪy wykonaü na niej polecenie
ANALYZE z opcją LIST CHAINED ROWS.
Wyniki tego zapytania są gromadzone w tabeli o nazwie CHAINED_ROWS, którą moĪna utworzyü
uruchamiając skrypt UTLCHAIN.SQL. Tabela ta jest tworzona w schemacie uĪytkownika wykonującego
ten skrypt.
Przykáad 28.2.3.1. Przykáad pokazujący kroki umoĪliwiające zredukowanie zjawiska áaĔcuchowania
i migracji w tabeli OSOBY.
- 314 -
Znalezienie wierszy, które ulegáy áaĔcuchowaniu lub migracji, korzystając z polecenia ANALYZE TABLE.
SQL> ANALYZE TABLE osoby LIST CHAINED ROWS;
WyĞwietlenie wyjĞciowej tabeli za pomocą polecenia:
SQL> SELECT * FROM CHAINED_ROWS WHERE TABLE_NAME = ‘OSOBY’;
OWNER_NAME
HR
HR
HR
TABLE_NAME
OSOBY
OSOBY
OSOBY
…
…
…
…
HEAD_ROWID
AAAA1uAAHAAAAA1AAA
AAAA1uAAHAAAAA1AAB
AAAA1uAAHAAAAA1AAC
TIMESTAMP
04-JAN-06
04-JAN-06
04-JAN-06
Tabela ta zawiera zarówno áaĔcuchowane jak i migrowane wiersze.
JeĞli tabela ta nie jest pusta wówczas naleĪy podjąü kroki mające na celu eliminacje áaĔcuchowania
i migrowania wyĞwietlonych rekordów postĊpując zgodnie z poniĪszymi punktami:
x Utworzenie tymczasowej tabeli z takimi samymi kolumnami jak w tabeli OSOBY, do której
skopiujemy áaĔcuchowane i migrowane wiersze.
SQL> CREATE TABLE temp_osoby
AS SELECT * FROM osoby
WHERE ROWID IN (SELECT HEAD_ROWID FROM CHAINED_ROWS
- 315 -
WHERE TABLE_NAME = ‘OSOBY’);
x UsuniĊcie z tabeli OSOBY rekordów áaĔcuchowanych i migrowanych.
SQL> DELETE FROM osoby
WHERE ROWID IN (SELECT HEAD_ROWID FROM CHAINED_ROWS
WHERE TABLE_NAME = ‘osoby’);
x Wstawienie wierszy z tabeli TEMP_OSOBY do tabeli OSOBY.
SQL> INSERT INTO osoby SELECT * FROM temp_osoby;
x UsuniĊcie tabeli tymczasowej TEMP_OSOBY.
SQL> DROP TABLE temp_osoby;
x UsuniĊcie informacji zebranych w kroku 1 (z tabeli CHAINED_ROWS).
SQL> DELETE FROM CHAINED_ROWS WHERE TABLE_NAME = ‘OSOBY’;
x Ponowne wykonanie polecenia ANALYZE - wyĞwietlone zostaną wówczas rekordy áaĔcuchowane.
Wyeliminowanie áaĔcuchowania tych rekordów jest moĪliwe tylko poprzez zwiĊkszenie rozmiaru
bloków.
- 316 -
W pewnych sytuacjach nie moĪna uniknąü áaĔcuchowania tj. w tabelach z kolumnami typu LONG lub
dáugimi kolumnami CHAR lub VARCHAR2. Informacja o wystĊpowaniu w naszym systemie tego typu
kolumn musi byü wziĊta pod uwagĊ, podczas ustalania rozmiaru bloku w fazie projektowania bazy.
WielkoĞü bloku jest ustalana parametrem DB_BLOCK_SIZE. Wyznaczenie optymalnego rozmiaru bloku
pozwala efektywnie wykorzystaü te bloki, a takĪe na zminimalizowanie iloĞci operacji wejĞcia-wyjĞcia.
28.2.4. Unikanie dynamicznego zarządzania rozszerzeniami
Wraz ze wzrostem iloĞci danych w tabeli tworzone są nowe rozszerzenia, w których te dane mogą byü
przechowywane. Przydzielanie tych rozszerzeĔ jest procesem bardzo kosztownym, dlatego przy strojeniu
wykorzystania urządzeĔ dyskowych nie moĪna zapomnieü o redukowaniu liczby tych operacji.
Aby zmniejszyü liczbĊ operacji czĊstego przydzielania nowych rozszerzeĔ powinno siĊ okreĞliü
parametry skáadowania obiektów: initial, next, minextents, pctincrease.
KorzyĞcią stosowania duĪych rozszerzeĔ jest zmniejszenie liczby operacji przydziaáu kolejnego
rozszerzenia oraz ciągáoĞü zaalokowanego miejsca na dysku, co przyĞpiesza sekwencyjny odczyt wszystkich
rekordów tabeli. Minusem tego rozwiązania mogą byü problemy z przydzieleniem wystarczająco duĪej,
- 317 -
ciągáej przestrzeni na dysku. Rozwiązanie tych problemów wymaga rozszerzenia lub dodania pliku danych
do przestrzeni tabel.
Aby wyĞwietliü liczbĊ rozszerzeĔ naleĪy posáuĪyü siĊ perspektywą systemową DBA_EXTENTS.
Zapytanie oraz jego wynik mogą wyglądaü nastĊpująco:
SELECT owner, segment_name, segment_type,
count(*) liczba_rozszerzeĔ
FROM dba_extents
GROUP BY owner, segment_name, segment_type;
OWNER
SCOTT
SCOTT
SCOTT
SEGMENT_NAME
AB_DATA_ROZP
AB_DATA_ZAK
AB_ET_FK_I
SEGMENT_TYPE
INDEX
INDEX
INDEX
liczba_rozszerzeĔ
9
9
10
JeĞli po kilkukrotnym wykonaniu powyĪszego zapytania zauwaĪymy, iĪ liczba rozszerzeĔ któregoĞ
obiektu dynamicznie wzrasta, wówczas naleĪy rozwaĪyü zwiĊkszenie wartoĞci parametrów skáadowania
next oraz pctincrease tego obiektu.
- 318 -
28.2.5. Strojenie procesu DBWR
Proces DBWR dokonuje zapisu zmodyfikowanych bloków danych z bufora danych na dysk
w nastĊpujących przypadkach:
a) proces uĪytkownika stwierdzi, Īe lista LRU przekroczyáa okreĞlony rozmiar;
b) proces uĪytkownika nie znajdzie wolnego bloku w buforze danych, a bufor taki jest wymagany do
odczytu nowych danych na dysku;
c) upáyną … sekundy od ostatniego zapisu;
d) zostanie zgáoszony punkt kontrolny (Checkpoint).
W przypadku podpunktu d) proces DBWR zapisuje wszystkie zmodyfikowane bloki bufora danych,
natomiast w pozostaáych podpunktach, iloĞü kaĪdorazowo zapisywanych bloków okreĞlona jest przez
parametr DB_BLOCK_CHECKPOINT_BATCH. Ustawienie wartoĞci tego parametru na odpowiednio
niewielką wartoĞü zapobiega dyskryminacji pozostaáych zadaĔ realizowanych przez DBWR, natomiast
wyĪsza wartoĞü tego parametru umoĪliwia szybsze wykonanie punktu kontrolnego.
28.2.6. Strojenie segmentów wycofywania
We wczeĞniejszych wersjach systemu Oracle, spójnoĞü odczytu danych obsáugiwana byáa przez
mechanizm segmentów wycofania. Od wersji Oracle9i wprowadzony zostaá nowy, automatyczny
- 319 -
mechanizm zapewniający spójnoĞü odczytów, wycofywania zmian i odtwarzania bazy po awarii - SMU
(ang. System Management Undo). W przypadku serwerów od Oracle9i zaleca siĊ ustawienie ich w tryb
pracy SMU, co znacząco uáatwia zarządzanie bazą danych i usuwa koniecznoĞü rĊcznego strojenia
segmentów wycofania jak to ma miejsce w trybie pracy RBU (ang. Rollback Segment Undo). Praca w trybie
RBU jest moĪliwa ze wzglĊdu na koniecznoĞü zachowania zgodnoĞci z poprzednimi wersjami systemu
Oracle.
28.2.7. Strojenie serwera w trybie SMU- System Management Undo
PrzestrzeĔ wycofania musi byü na tyle duĪa, by byáa w stanie pomieĞciü caáą informacjĊ związaną
z wycofywaniem transakcji.
PrzybliĪony
rozmiar
tej
przestrzeni
moĪemy
wyliczyü
korzystając
z
wartoĞci
parametru
UNDO_RETENTION, okreĞlającego jak dáugo dane mają pozostawaü na dysku. Znając tą wartoĞü oraz iloĞü
generowanych danych wycofania na sekundĊ, moĪna wyliczyü wielkoĞü przestrzeni wycofania za pomocą
wzoru:
WielkoĞü przestrzeni=czas przechowywania * iloĞü informacji w jednostce czasu
Przykáadowo, jeĞli czas przechowywania wynosi 200s, a system generuje 100 bloków informacji
wycofania na sekundĊ, to otrzymamy:
- 320 -
Liczba bloków undo = (200s)*(100 bloków/s) = 20000 bloków
czyli wielkoĞü przestrzeni wycofania wynosi 20000 razy wielkoĞü bloku.
Mając „chodzący” system w trybie SMU moĪemy przejĞü do poprawienia jego wydajnoĞci. Statystyki
opisujące pracĊ w trybie automatycznym moĪemy znaleĨü w dynamicznej perspektywie V$UNDOSTAT,
która skáada siĊ m.in. z nastĊpujących kolumn:
- Początek badanego przedziaáu czasowego.
- Koniec badanego przedziaáu czasowego.
- Liczba bloków wycofania zuĪyta na potrzeby przechowywania informacji wycofania
w tym przedziale.
SSOLDERRCNT
- Liczba báĊdów snapshot too old, która wystąpiáa w trakcie trwania tego przedziaáu
czasu.
NOSPACEERRCNT - Liczba báĊdów snapshot too old, która wystąpiáa dla tej instancji.
JeĞli w kolumnach zawierających báĊdy wystĊpuje jakaĞ wartoĞü wiĊksza do zera, wówczas moĪna
BEGIN_TIME
END_TIME
UNDOBLKS
skróciü czas przechowywania lub zwiĊkszyü wielkoĞü przestrzeni wycofania.
DomyĞlna wartoĞü czasu przechowywania informacji sáuĪących do wycofywania transakcji jest
zazwyczaj wystarczającą wartoĞcią dla systemów, w których nie wykonuje siĊ dáugotrwaáych zapytaĔ. JeĞli
jednak wiemy, Īe w naszym systemie wykonywane bĊdą dáugotrwaáe transakcje (czĊsto wymagające
- 321 -
spójnego obrazu bazy przez caáy czas) warto zastanowiü siĊ nad zwiĊkszeniem tego czasu. JeĞli w trakcie
wykonywania takiej transakcji wystąpi báąd snapshot too old, wówczas czas przechowywania naleĪy
zwiĊkszyü.
28.2.8. Strojenie serwera w trybie RBU
Ze wzglĊdu na zalecenie Oracla ustawienia trybu pracy serwrów w tryb SMU pominiemy ten punkt.
§ 28.3. Strojenie punktów kontrolnych
Punkty kontrolne zapewniają, Īe wszystkie „brudne bloki” znajdujące siĊ w SGA zostaną zapisane na
dysk. PoniewaĪ proces DBWR bazuje na algorytmie LRU, jest zatem moĪliwoĞü wystąpienia sytuacji,
w której czĊsto modyfikowane bloki nie zostaną zapisane na dysku.
Rozwiązaniem tego problemu jest stosowanie punktów kontrolnych.
Punkty te są generowane w nastĊpujących przypadkach:
x nastĊpuje przeáączenie pliku dziennika powtórzeĔ;
x przekroczony zostanie czas okreĞlony parametrem konfiguracyjnym
LOG_CHECKPOINT_TIMEOUT
od poprzedniego punktu kontrolnego;
- 322 -
x przekroczona zostanie liczba zapisów okreĞlona parametrem konfiguracyjnym
LOG_CHECKPOINT_INTERVAL
od poprzedniego punktu kontrolnego;
x nastĊpuje przeáączenie przestrzeni tabel w tryb wykonywania kopii zapasowej;
x przy przeáączaniu pliku danych w tryb offline;
x przy zamykaniu bazy za pomocą poleceĔ SHUTDOWN NORMAL i SHUTDOWN IMMEDIATE;
x administrator moĪe jawnie wywoáaü punkt kontrolny za pomocą polecenia
ALTER SYSTEM CHECKPOINT.
x
inne.
CzĊste wykonywanie punktu kontrolnego przyspiesza operacjĊ odtwarzania instancji po awarii, jednak
jednoczeĞnie wprowadza dodatkowy narzut w postaci czĊstych zapisów zmodyfikowanych bloków danych
na dysk.
Punkty kontrolne mogą jednoczeĞnie obciąĪaü proces LGWR, odpowiedzialny za zapisanie informacji
kontrolnych do wszystkich plików danych i plików kontrolnych.
- 323 -
§ 28.4. Strojenie sortowaĔ
Podczas wykonywania operacji sortowania wykorzystywany jest obszar pamiĊci PGA, którego wielkoĞü
okreĞlona jest parametrem konfiguracyjnym SORT_AREA_SIZE.
JeĪeli wielkoĞü tego obszaru jest zbyt maáa, wówczas wystĊpuje tendencja do przeprowadzania operacji
sortowania na dysku. W takim przypadku naleĪy zwiĊkszyü wielkoĞü tego obszaru.
Aby sprawdziü wykorzystanie pamiĊci i dysku do operacji sortowania moĪna posáuĪyü siĊ dynamiczną
perspektywą V$SYSSTAT. Interesującymi statystykami tej perspektywy są Sorts(memory),
zawierająca liczbĊ sortowaĔ, które zmieĞciáy siĊ caákowicie w pamiĊci oraz Sorts(disk), zawierająca
liczbĊ sortowaĔ, które wymagaáy zapisania wyników poĞrednich na dysku.
Przykáadowe zapytanie moĪe wyglądaü nastĊpująco:
SELECT name, value
FROM v$sysstat
WHERE name IN (‘sorts(memory)’, ’sorts(disk)’);
NAME
sorts(memory)
sorts(disk)
VALUE
19
0
- 324 -
JeĪeli liczba operacji sortowania na dysku jest zbyt duĪa, wówczas moĪna rozwaĪyü zwiĊkszenie
wartoĞci parametru
SORT_AREA_SIZE.
ZwiĊkszenie tego parametru skutkuje szybszym wykonywaniem sortowania i zmniejszeniem liczby operacji
wejĞcia-wyjĞcia.
Po zwiĊkszeniu obszaru sortowania moĪna zmniejszyü wielkoĞü obszaru pozostawionego za pomocą
parametru
SORT_AREA_RETAINED_SIZE.
Parametr ten okreĞla minimalną wielkoĞü pamiĊci zwalnianej po wykonaniu operacji sortowania.
JeĪeli operacja sortowania wymaga wiĊkszej iloĞci pamiĊci niĪ rozmiar okreĞlony wartoĞcią parametru
SORT_AREA_SIZE, wówczas dane dzielone są na mniejsze czĊĞci i kaĪda z nich sortowana jest
indywidualnie.
W procesie sortowania, obok obszaru sortowania, udziaá bierze takĪe przestrzeĔ tymczasowa, która
przechowuje poĞrednie wyniki podczas sortowania duĪych iloĞci danych. WáaĞciwe skonfigurowanie
przechowywania danych tymczasowych przyczynia siĊ do wzrostu wydajnoĞci systemu.
Najbardziej efektywną metodą
- 325 -
strojenia przestrzeni tymczasowej jest umieszczenie jej na bardzo
szybkim noĞniku danych. Zastosowanie tego rozwiązania znacząco przyspiesza dostĊp do tabel
tymczasowych.
Innym sposobem na zwiĊkszenie wydajnoĞci operacji sortowania jest ustawienie wartoĞci rozszerzenia
przestrzenie tabel równej wartoĞci parametru SORT_AREA_SIZE, dziĊki czemu kolejne rozszerzenia nie
bĊdą przydzielane zbyt czĊsto.
NaleĪy takĪe ustawiü parametr PCTINCREASE na wartoĞü 0, a INITIAL i NEXT na wartoĞü bĊdącą
wielokrotnoĞcią wartoĞci SORT_AREA_SIZE. Trzeba upewniü siĊ, aby wielkoĞci te byáy dostatecznie duĪe,
co zmniejszy liczbĊ alokacji nowych rozszerzeĔ.
§ 28.5. Zmniejszenie rywalizacji o semafory bufora dziennika powtórzeĔ
DostĊp do buforów dziennika powtórzeĔ jest kontrolowany przez dwa typy semaforów: alokujące oraz
kopiujące.
Aby zapisaü dane w buforze dziennika powtórzeĔ, proces uĪytkownika musi najpierw uzyskaü semafor
alokujący, przydzielający fragment bufora dziennika powtórzeĔ, do którego nastĊpnie kopiowane są
stosowne informacje.
- 326 -
Kiedy proces uĪytkownika koĔczy kopiowanie danych do bufora, zwalniany jest ten semafor, zezwalając
w ten sposób uĪycie tego semafora innym procesom uĪytkownika.
PoniewaĪ istnieje tylko jeden semafor alokacyjny, zatem jednoczeĞnie do bufora zapisywaü moĪe tylko
jeden proces uĪytkownika. Maksymalna wielkoĞü danych, jaka moĪe byü zapisana po pojedynczym
uzyskaniu semafora alokującego okreĞlona jest parametrem konfiguracyjnym
LOG_SMALL_ENTRY_MAX_SIZE.
JeĞli wielkoĞü zapisu do bufora przekracza wartoĞü parametru LOG_SMALL_ENTRY_SIZE, wówczas
aby skopiowaü informacje do bufora, proces uĪytkownika musi uzyskaü semafor kopiujący.
W systemach wieloprocesorowych takich semaforów moĪe byü wiĊcej niĪ jeden. Pozwala to na
wykonywanie sekwencyjnego zapisu do bufora dziennika powtórzeĔ, co przyczynia siĊ do wzrostu
wydajnoĞci.
Liczba semaforów kopiujących okreĞlona jest parametrem konfiguracyjnym
LOG_SIMULTANEOUS_COPIES.
W systemach jednoprocesorowych nie wystĊpują semafory kopiujące i na dostĊp do bufora zezwala semafor
alokujący.
- 327 -
DostĊp do semaforów moĪe byü wykonywany w jednym z dwóch trybów: w trybie z oczekiwaniem i w
trybie natychmiastowym. JeĞli proces nie uzyskuje wyáącznego dostĊpu do semafora w trybie z
oczekiwaniem, to rozpoczyna oczekiwanie na jego zwolnienie. JeĪeli natomiast proces Īądający
wyáącznego dostĊpu do semafora w trybie natychmiastowym nie otrzyma dostĊpu, to kontynuuje swoje
przetwarzanie.
Aby uzyskaü informacje o stopniu rywalizacji o semafory bufora dziennika powtórzeĔ, naleĪy posáuĪyü
siĊ dynamiczna perspektywą V$LATCH, która zawiera m.in. poniĪsze kolumny:
GETS
- ogólna liczba dostĊpu w trybie z oczekiwaniem
MISSES
- liczba nieudanych dostĊpów w trybie z oczekiwaniem
IMMEDIATE_GETS
- ogólna liczba dostĊpu w trybie natychmiastowym
IMMEDIATE_MISSES
- liczba nieudanych dostĊpów w trybie natychmiastowym
Przykáadowe zapytanie moĪe wyglądaü nastĊpująco:
SELECT name, gets, misses, immediate_gets imm_gets,
immediate_misses imm_misses
FROM v$latch
WHERE name IN (‘redo allocation’, ‘redo copy’);
NAME
redo allocation
redo copy
GETS
563571
2
MISSES
523
2
IMM_GETS
0
23452
IMM_MISSES
0
3
- 328 -
StopieĔ rywalizacji w kaĪdym z tych przypadków okreĞla siĊ jako stosunek nieudanych dostĊpów do
ogólnej liczby dostĊpów i w obu trybach nie powinien on przekraczaü jednego procenta.
Aby zmniejszyü rywalizacjĊ o semafor alokujący, naleĪy zmniejszyü wartoĞü parametru
LOG_SMALL_ENTRY_MAX_SIZE,
dziĊki czemu mniej procesów bĊdzie blokowaáo ten semafor w czasie kopiowania.
Aby zmniejszyü rywalizacjĊ o semafor kopiujący, naleĪy zwiĊkszyü wartoĞü parametru
LOG_SIMULTANEOUS_COPIES,
co spowoduje moĪliwoĞü obsáuĪenia wiĊkszej liczby operacji zapisu do bufora dziennika powtórzeĔ.
§ 28.6. Minimalizacja rywalizacji o listĊ wolnych bloków
Kolejnym miejscem, gdzie moĪe wystąpiü rywalizacja jest lista wolnych bloków. Listy te przechowują
informacje związane z wolnymi blokami w buforze danych, w których jest miejsce na wstawienie danych.
Aby sprawdziü stopieĔ rywalizacji o listy wolnych bloków moĪna posáuĪyü siĊ poniĪszym zapytaniem do
dynamicznej perspektywy V$WAITSTAT.
SELECT class, count
FROM v$waitstat
- 329 -
WHERE class = ‘free list’;
CLASS
free list
COUNT
0
JeĞli liczba oczekiwaĔ na listĊ przekracza 1% wszystkich ĪądaĔ, wówczas naleĪy zwiĊkszyü liczbĊ takich
list poprzez ponowne utworzenie tabeli ze zwiĊkszoną wartoĞcią parametru FREELISTS. LiczbĊ
wszystkich odwoáaĔ do listy moĪemy uzyskaü sumując iloĞü odczytów bloków z perspektywy V$SYSSTAT.
SELECT SUM(value) Liczba_zadan
FROM v$sysstat
WHERE name in (‘db block gets’, ‘consistent gets’);
LICZBA_ZADAN
2332
Rywalizacja o listy wystĊpuje gáównie przy wspóábieĪnym wykonywaniu przez wiele sesji operacji
wstawiania insert, zatem optymalna liczba list wolnych bloków powinna byü równa liczbie sesji
równoczeĞnie wstawiających dane do bazy.
29. WYZWALACZE INSTEAD OF I SYSTEMOWE
- 330 -
§ 29.1. Wyzwalacze INSTEAD OF
Wyzwalacze INSTEAD OF (zamiast) umoĪliwiają np. modyfikowanie perspektyw (widoków), których
zawartoĞü nie moĪna zmieniaü uĪywając poleceĔ DML (np. perspektyw utworzonych z klauzulą GROUP
BY).
CREATE OR REPLACE TRIGGER nazwa_wyzwalacza
INSTEAD OF INSERT ON perspektywa
DECLARE
...
BEGIN
...
END;
§ 29.2. Wyzwalacze systemowe
Wyzwalacze systemowe mogą byü definiowane na poziomie bazy danych lub na poziomie schematu
uĪytkownika.
Przykáady zdarzeĔ systemowych:
AFTER STARTUP, BEFORE SHUTDOWN, AFTER LOGON, AFTER DROP, AFTER
GRANT, AFTER CREATE,…
Przykáad 29.2.1. Przykáad rejestracji logowaĔ:
CREATE TABLE rejestracja_logowania
(
user VARCHAR2(15),
data_logowania DATE
);
CREATE OR REPLACE TRIGGER rejestracja_logowania
AFTER LOGON
ON SCHEMA
BEGIN
INSERT INTO rejestracja_logowania VALUES (user, SYSDATE);
END;
-331-
-332-
Przykáad 29.2.2. Przykáad rejestracji operacji STARTUP i SHUTDOWN:
CREATE TABLE rejestracja_start (operacja VARCHAR2(15),data DATE);
CREATE OR REPLACE TRIGGER rejestracja_start
AFTER STARTUP
ON DATABASE
BEGIN
INSERT INTO rejestracja_start VALUES (‘startup’,SYSDATE);
END;
CREATE OR REPLACE TRIGGER rejestracja_start
BEFORE SHUTDOWN
ON DATABASE
BEGIN
INSERT INTO rejestracja_start VALUES (‘shutdown’,SYSDATE);
END;
-333-
§ 29.3. Wyzwalacze a transakcje autonomiczne
W przypadku gdy wyzwalacz jest czĊĞcią transakcji i chcemy aby wewnątrz nastąpiáo zatwierdzenie
(COMMIT) dokonanych wewnątrz zmian bez wzglĊdy na to czy caáa transakcja bĊdzie zatwierdzona czy teĪ
nie naleĪy w czĊĞci deklaracyjnej uĪyü PRAGMA AUTONOMOUS_TRANSACTION.
Przykáad 29.3.1. Przykáad wyzwalacza:
CREATE OR REPLACE TRIGGER rejestracja
BEFORE INSERT ON sprzedaz
FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO rejestracja VALUES (:NEW.id_towaru, :NEW.ilosc, SYSDATE);
COMMIT;
END;

administracja bazami danych

Transkrypt

Podobne dokumenty

Młodszy Specjalista ds. Utrzymania Systemów IT

Strojenie Modułów CAM

program_strojenie wydajnosciowe SQL

Przedmiotem jest usługa: STROJENIE SWR

Aplikacje mobilne Kurs Ruby on Rails Programowanie grafiki 3D

Zaawansowane bazy danych

Młodszy Programista Baz Danych

Programista Oracle PL/SQL - I

Administrator baz danych_cv

Kliknij aby pobrać moje CV (Polska wersja).