wybrane zagadnienia z baz danych

Transkrypt

wybrane zagadnienia z baz danych
SPIS TREĝCI
- 277 -
28.1.1. Strojenie bufora dziennika powtórzeĔ (REDO BUFFERS) ............................................................................................................ 293
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
ADMINISTRACJA
BAZAMI DANYCH
U
Rozdziaáy 27-29
Rok akademicki – 2007/2008
Notatki do przedmiotu „Administracja bazami danych”
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
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
- 278 -
-279-
x Wykrywanie uszkodzeĔ – potencjalne zagroĪenia powinny byü automatycznie wykrywane przez
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).
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
1
2
System oparty o takie rozwiązanie, skáada siĊ z bazy produkcyjnej oraz z baz zapasowych , 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
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
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.
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
1
2
równieĪ znacznie zwiĊkszyü jego wydajnoĞü.
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-280-
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-281-
Konfiguracja Oracle Data Guard opiera siĊ na jednej bazie produkcyjnej oraz jednej lub wiĊcej
§ 27.2. Funkcjonowanie i ogólny zarys mechanizmu.
PoniĪszy rysunek przedstawia nam ogólną koncepcjĊ funkcjonowania Oracle Data Guard.
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.
Rysunek 27.2.1. Ogólna koncepcja funkcjonowania Oracle Data Guard
Zapasowe bazy uaktualniane są poprzez aplikowanie do nich zmian, które zarejestrowane zostaáy
Do poprawnego dziaáania Data Guard muszą byü speánione nastĊpujące wymagania:
w plikach dziennika powtórzeĔ gáównej bazy produkcyjnej.
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.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
-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
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
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.
pozostaáych baz zapasowych.
Oznacza to, Īe transakcje na bazie gáównej mogą byü zatwierdzane przed ich poprawnym
przetransmitowaniem na bazy zapasowej.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
-283-
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-284-
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-285-
wprowadzone na tą bazĊ.
NastĊpnie pliki dziennika powtórzeĔ są archiwizowane na bazie gáównej przez proces ARC 4 oraz
przesyáane do baz zapasowych.
Proces RFS 5 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 MRP 6 , 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 FAL 7 .
Rysunek 27.3.1.1. ODG z bazą fizyczną i przesyáaniem danych przez proces ARC0
Fizyczne bazy danych wymagają do poprawnego dziaáania identycznych platform sprzĊtowo-
W przypadku dziaáania takiej konfiguracji bazy danych, wszystkie transakcje aplikowane na bazĊ
produkcyjną trafiają do procesu LGWR 3 , który to rejestruje w bieĪących plikach dziennika powtórzeĔ zmiany
programowych 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
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
6
3
LGWR – proces odpowiedzialny za rejestrowanie w bieĪących plikach dziennika powtórzeĔ wszystkich zmian wprowadzonych do bazy danych
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
-286-
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-287-
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.
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 LSP 8 .
8
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
LSP - proces aplikujący polecenia SQL znajdujące siĊ w plikach dziennika powtórzeĔ na bazĊ logiczną
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-288-
Zarządzanie zarówno bazą produkcyjną jak i zapasowymi moĪe odbywaü siĊ z linii poleceĔ SQL lub
27. GàÓWNA KONCEPCJA DZIAàANIA ORACLE DATA GUARD
-289-
Wzrost efektywnoĞci wykorzystywanych zasobów. Fizyczne zapasowe bazy danych bĊdące
z poziomu tzw. zarządcy Data Guard, który posiada zarówno interfejs graficzny (zintegrowany w Oracle
aktualizowane zarchiwizowanymi plikami dziennika powtórzeĔ mogą byü otwarte w trybie tylko do
Enterprise Manager) jak i tekstowy (DGMGRL).
odczytu. DziĊki temu moĪna w swobodny sposób uĪyü ich jako baz danych, na których wykonywane są
Wszystkie zadania związane z konfiguracją Ğrodowiska ODG moĪna zautomatyzowaü w prosty sposób
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Ğü
przez wykorzystanie Oracle Enterprise Manager.
dostĊpnej pamiĊci operacyjnej.
§ 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.
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
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.
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Ğü
OdpornoĞü na nieplanowane awarie, jak i zaplanowane przestoje w pracy gáównej bazy, co zapewnia
duĪą dostĊpnoĞü systemu.
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
Wysoka ochrona danych skáadowanych w bazie. ODG posiada mechanizmy, dziĊki którym awaria
dostosowaü czĊstotliwoĞü archiwizacji mając na wzglĊdzie zarówno bezpieczeĔstwo danych i moĪliwoĞci
fizyczna plików na produkcyjnej bazie danych nie zostanie rozpropagowana na bazy zapasowe.
wydajnoĞciowe platformy sprzĊtowej.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 290 -
28. STROJENIE INSTANCJI
- 291 -
KoniecznoĞü strojenia moĪe zachodziü m.in. z nastĊpujących powodów:
28. STROJENIE INSTANCJI
Przed przystąpieniem do omawiania poszczególnych kroków strojenia instancji naleĪy najpierw wyjaĞniü
czym jest strojenie.
Strojenie przetwarzania. Strojenie polegające na takim skonfigurowaniu systemu, aby moĪliwe byáo
przetwarzanie najwiĊkszej iloĞci danych w najkrótszym czasie.
Shared pool - Obszar wspóádzielony
Strojenie czasu odpowiedzi. Polega na takim skonfigurowaniu systemu, aby Īądane dane zwracane byáy
jak najszybciej.
Database buffers
Bufor danych
Shared SQL Area
Redo
buffers
Bufor
dziennika
powtórzeĔ
aby mógá on obsáugiwaü jednoczeĞnie jak najwiĊkszą liczbĊ uĪytkowników.
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
Strojenie systemu dla duĪej liczby uĪytkowników. Strojenie polegające na skonfigurowaniu systemu,
Wspóádzielony obszar poleceĔ SQL
Whalen Ed.: Oracle – Optymalizacja wydajnoĞci. Helion, 2003 – str. 17
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
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),
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 292 -
28. STROJENIE INSTANCJI
- 293 -
Strojenie pamiĊci w instancji systemu Oracle obejmuje nastĊpujące obszary:
x
strojenie sortowaĔ,
x
zmniejszenie rywalizacji o semafory bufora dziennika powtórzeĔ,
x
strojenie bufora dziennika powtórzeĔ (Redo buffers),
x
minimalizacja rywalizacji o listĊ wolnych bloków.
x
strojenie przydziaáu prywatnego obszaru poleceĔ SQL (Shared SQL Area) ,
x
strojenie pamiĊci wspóádzielonej (Shared pool),
Instancja systemu Oracle przechowuje dane w dwóch miejscach: w pamiĊci oraz na dysku.
x
strojenie bufora danych (Database buffers),
Przechowywanie danych w pamiĊci operacyjnej powoduje bardzo wysoką wydajnoĞü, ale jednoczeĞnie
x
zmniejszanie zajĊtoĞci pamiĊci operacyjnej.
§ 28.1. Strojenie pamiĊci
28.1.1. Strojenie bufora dziennika powtórzeĔ (REDO BUFFERS)
wysoki koszt.
Z drugiej strony dysk moĪe przechowywaü ogromną iloĞü danych przy jednoczesnym relatywnie niskim
koszcie w stosunku do pamiĊci.
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.
Biorąc pod uwagĊ wydajnoĞü osiąganą przy przechowywaniu danych w pamiĊci, naleĪy przechowywaü
Wówczas bufor ten moĪe staü siĊ ”wąskim gardáem” systemu. Z tego powodu wiĊkszy rozmiar bufora
w niej dane zawsze kiedy to moĪliwe. UwzglĊdniając ogromną iloĞü danych oraz liczbĊ uĪytkowników,
dziennika powtórzeĔ powoduje mniejsze prawdopodobieĔstwo wystąpienia kolizji pomiĊdzy nowymi
którzy potrzebują tych danych, trzeba uwzglĊdniü moĪliwoĞü wystĊpowania konfliktów związanych
wpisami a wpisami starymi – bĊdącymi w trakcie zapisu na dysk.
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.
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Ğü.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 294 -
28. STROJENIE INSTANCJI
OkreĞlenie rywalizacji o bufor dziennika powtórzeĔ moĪna dokonaü przeglądając dynamiczną
plików dziennika na szybsze urządzenia zewnĊtrzne / dyski).
perspektywĊ V$SYSSTAT szukając tam statystyki REDO BUFFER ALLOCATION RETRIES. Statystyki
28.1.2. Strojenie przydziaáu prywatnego obszaru poleceĔ SQL
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Ğü
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.
buforu za pomocą parametru LOG_BUFFER.
SQL> ALTER SYSTEM SET log_buffer=7024640 SCOPE=spfile;
- 295 -
Aby okreĞliü liczbĊ niepotrzebnych parsowaĔ moĪna wykorzystaü widok V$SQLAREA wykonując
zapytanie:
WielkoĞü tego parametru wyraĪona jest w bajtach i powinna byü wielokrotnoĞcią rozmiaru bloku systemu
SQL> SELECT sql_text, parse_calls, executions FROM v$sqlarea;
plików (parametr DB_BLOCK_SIZE).
SQL_TEXT
select * from osoby
select * from pensje where pensja > 2000
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
10
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Whalen Ed.: Oracle – Optymalizacja wydajnoĞci. Helion, 2003 – str.50
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
PARSE_CALLS
32
2
EXECUTIONS
32
24
28. STROJENIE INSTANCJI
- 296 -
Kiedy wartoĞü PARSE_CALLS jest bliska wartoĞci EXECUTIONS, wówczas liczba parsowaĔ jest zbyt
duĪa (kursory nie są wielokrotnie wykorzystywane).
28. STROJENIE INSTANCJI
- 297 -
BIBLIOTECZNA PAMIĉû PODRĉCZNA
Biblioteczna pamiĊü podrĊczna zawiera wspóádzielone obszary SQL oraz PL/SQL. Przechowują one
Aby aplikacja mogáa wielokrotnie wykorzystywaü te same kursory musi posiadaü wystarczająco duĪą
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.
pamiĊü podrĊczną.
WielkoĞü tĊ moĪna zmieniaü za pomocą parametru konfiguracyjnego OPEN_CURSORS. Parametr ten
Strojenie bibliotecznej pamiĊci podrĊcznej polega gáównie na zwiĊkszeniu tzw. wspóáczynnika
okreĞla maksymalną liczbĊ otwartych kursorów przez aplikacjĊ uĪytkownika. Im wiĊksza jest wartoĞü tego
trafieĔ(ang. hit ratio) oraz zwiĊkszeniu szybkoĞci uzyskiwania dostĊpu do bufora biblioteki, uzyskiwane
parametru, tym wiĊcej pamiĊci prywatnej rezerwuje sesja uĪytkownika i tym wiĊksze są moĪliwoĞci
poprzez dáuĪsze przechowywanie rzadziej wykonywanych zapytaĔ SQL.
przechowywania informacji związanej z kursorami. Warunkiem koniecznym wielokrotnego wykorzystania
Nietrafienie w bufor moĪe zajĞü, gdy parsowane jest zapytanie a jego poprzednio sparsowana postaü juĪ
kursorów jest takĪe aby aplikacja nie zwalniaáa obszaru pamiĊci prywatnej przy zamkniĊciu kursora lub przy
nie istnieje buforze lub gdy próbujemy wykonaü zapytanie, a obszar pamiĊci wspóáuĪytkowanego SQL
zakoĔczeniu transakcji.
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
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.
ciąg znaków zapytania SQL musi byü identyczny z ciągiem znaków zapytania przechowywanego
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.
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:
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
kryteria:
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 298 -
28. STROJENIE INSTANCJI
- 299 -
SQL> SELECT * FROM Osoby;
Zapytania SQL muszą mieü plany wykonania wyznaczone w tym samym trybie pracy optymalizatora.
SQL> SELECT * FROM osoby;
W przypadku uĪycia optymalizatora kosztowego identyczny musi byü teĪ cel optymalizacji.
SQL> SELECT *
FROM osoby;
Statystyki opisujące efektywnoĞü bibliotecznej pamiĊci podrĊcznej są zawarte w perspektywie
Referencje do obiektów schematu w zapytaniu SQL muszą wskazywaü na te same obiekty w tym samym
V$LIBRARYCACHE. Najistotniejszymi kolumnami w tej tabeli są kolumny: PINS oraz RELOADS.
schemacie jak w zapytaniu przechowywanym w buforze. Przykáadowo jeĞli schematy uĪytkowników Jan
Pierwsza kolumna zawiera informacje o liczbie odwoáaĔ do obiektu znajdującego siĊ w buforze, natomiast
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:
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
SQL> SELECT * FROM osoby WHERE wydzial=:wydzial_nr;
SQL> SELECT * FROM osoby WHERE wydzial=:w_nr;
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
0,63% zapytaĔ musiaáo zostaü sparsowanych powtórnie.
MoĪna równieĪ wygenerowaü podobny raport z podziaáem na typy obiektów:
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 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
28. STROJENIE INSTANCJI
- 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.
8 rows selected.
Aby sprawdziü wydajnoĞü bufora sáownika danych naleĪy posáuĪyü siĊ statystykami zawartymi
Wspóáczynnik nietrafieĔ powinien byü mniejszy niĪ 1. JeĞli tak nie jest naleĪy podjąü kroki zmierzające
w dynamicznej perspektywie V$ROWCACHE.
do obniĪenia tej wartoĞci. MoĪna tego dokonaü poprzez wykonywanie identycznych zapytaĔ lub przez
NajwaĪniejszymi kolumnami w tej perspektywie są kolumny: GETS, GETMISSES.
zwiĊkszenie rozmiaru bibliotecznej pamiĊci podrĊcznej za pomocą parametru konfiguracyjnego
Kolumna GETS zawiera liczbĊ odwoáaĔ do obiektu, natomiast kolumna GETMISSES zawiera liczbĊ
SHARED_POOL_SIZE.
Nie naleĪy jednak przydzielaü wiĊcej pamiĊci niĪ jest fizycznie dostĊpne, gdyĪ stronicowanie pamiĊci
odwoáaĔ do obiektu zakoĔczonych nietrafieniem w bufor.
Aby wyĞwietliü wspóáczynnik nietrafieĔ moĪna posáuĪyü siĊ poniĪszym zapytaniem:
moĪe caákowicie zniweczyü zalety bufora biblioteki. 11
SQL> SELECT SUM(getmisses) Ile_nietrafien,
SUM(gets) Ile_odwoáan,
11
Whalen Ed.: Oracle – Optymalizacja wydajnoĞci. Helion, 2003 – str.53
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 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,
100*(SUM(getmisses)/SUM(gets)) Wspolczynnik_ nietrafien
FROM v$rowcache;
dc_free_extents
dc_used_extents
dc_segments
dc_tablespaces
dc_tablespace_quotas
dc_files
dc_users
dc_rollback_segments
dc_objects
dc_global_oids
dc_constraints
dc_objects_ids
dc_sequences
dc_usernames
dc_database_links
dc_histogram_defs
dc_table_scns
...
- 303 -
21
167
6
0
164
1
10
0
24
0
...
235
685
16
0
687
1
192
0
24
0
...
8,93617
24,37956
37,5
100
5,20833
100
...
„W przypadku intensywnie wykorzystywanego bufora sáownika wspóáczynnik nietrafieĔ nie powinien
gets Odwolania,
Typ
28. STROJENIE INSTANCJI
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
Nietrafien Odwolania Wspolczynnik_nietrafien
0
0
184
3
0
0
25
0
0
518
21
0
0
126
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
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ą
35,52123
14,28571
wartoĞü nietrafieĔ w bufor sáownika danych.
19,84126
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 304 -
Jest to spowodowane sposobem gospodarowania pamiĊcią przez system Oracle, który preferuje dáuĪsze
28. STROJENIE INSTANCJI
- 305 -
Statystyka odwoáaĔ do bufora danych jest przechowywana w dynamicznej perspektywie V$SYSSTAT,
utrzymywanie w pamiĊci obiektów ze wspóádzielonego obszaru poleceĔ SQL niĪ obiektów z bufora
której najwaĪniejszymi kolumnami są:
sáownika danych.
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.
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
GETS i
operacji odczytywania i modyfikowania danych z bazy.
Podczas wykonywania tych operacji proces serwera sprawdza najpierw, czy Īądane dane znajdują siĊ juĪ
Aby uzyskaü informacje dotyczące poprawnoĞci dziaáania bufora moĪna posáuĪyü siĊ poniĪszym
poleceniem:
w SGA. JeĞli tak, dane są bezpoĞrednio obsáugiwane w SGA, natomiast jeĞli nie dane zostaną obsáuĪone po
SQL> SELECT name, value FROM v$sysstat
uprzednim skopiowaniu ich z dysku do SGA.
WHERE name in
Strojenie bufora danych polega na dobraniu takiego rozmiaru tego bufora, aby zagwarantowaü dobry
(‘db block gets’,‘consistent gets’,‘physical reads’);
wspóáczynnik trafieĔ. Przy dobieraniu rozmiaru naleĪy pamiĊtaü, Īe zaleĪnoĞü miĊdzy wielkoĞcią bufora
NAME
db block gets
consistent gets
physical reads
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.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
VALUE
155
5293
334
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 306 -
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
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
28. STROJENIE INSTANCJI
- 307 -
Aby zdefiniowaü maksymalny czas (w minutach) bezczynnoĞci uĪytkownika naleĪy w profilu
przypisanym temu uĪytkownikowi okreĞliü zasób IDLE_TIME.
§ 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
bezczynnoĞci. Skorzystanie z pierwszego sposobu polega na zmniejszeniu wartoĞci parametru
Bardzo waĪnym etapem strojenia instancji bazy danych jest strojenie dostĊpu do dysków.
inicjalizacyjnego
NajwaĪniejsze informacje o operacjach wejĞcia-wyjĞcia dysku moĪemy znaleĨü w dynamicznej tabeli
LICENSE_MAX_SESSIONS.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
V$FILESTAT, której najwaĪniejszymi kolumnami są: PHYRDS, PHYWRTS.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 308 -
Pierwsza kolumna zawiera liczbĊ fizycznych odczytów wykonywanych na plikach danych, natomiast
druga zawiera liczbĊ fizycznych zapisów na tych plikach.
28. STROJENIE INSTANCJI
- 309 -
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.
Informacja w V$FILESTAT stosuje wewnĊtrzne identyfikatory plików, zatem aby uzyskaü peáne nazwy
RedukcjĊ przeciąĪenia dysków moĪna osiągnąü przez:
tych plików moĪna skorzystaü z perspektywy sáownikowej V$DATAFILE. Jej najwaĪniejszymi kolumnami
x
zrównowaĪenie obciąĪenia,
są: NAME – zawiera nazwĊ pliku, STATUS – informuje o typie pliku i jego bieĪącym statusie, oraz BYTES –
x
odpowiednie skáadowanie danych w blokach,
x
unikanie dynamicznego zarządzania rozszerzeniami,
x
unikanie dynamicznego zarządzania przestrzenią w segmentach wycofania.
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:
28.2.2. RównowaĪenie obciąĪenia
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
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
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.
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 310 -
dziennika powtórzeĔ w grupie, uĪywane do tego celu dyski miaáy podobną wydajnoĞü. W przeciwnym razie
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 311 -
PCTINCREASE 0
);
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 312 -
28. STROJENIE INSTANCJI
- 313 -
zmodyfikowany rekord jest do niego przenoszony i proces ten nazywany jest migracją rekordu.
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.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ü
Rysunek 28.2.3.1. Migracja rekordu
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.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 314 -
28. STROJENIE INSTANCJI
- 315 -
WHERE TABLE_NAME = ‘OSOBY’);
Znalezienie wierszy, które ulegáy áaĔcuchowaniu lub migracji, korzystając z polecenia ANALYZE TABLE.
x UsuniĊcie z tabeli OSOBY rekordów áaĔcuchowanych i migrowanych.
SQL> ANALYZE TABLE osoby LIST CHAINED ROWS;
WyĞwietlenie wyjĞciowej tabeli za pomocą polecenia:
SQL> DELETE FROM osoby
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
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).
skopiujemy áaĔcuchowane i migrowane wiersze.
SQL> DELETE FROM CHAINED_ROWS WHERE TABLE_NAME = ‘OSOBY’;
SQL> CREATE TABLE temp_osoby
AS SELECT * FROM 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
WHERE ROWID IN (SELECT HEAD_ROWID FROM CHAINED_ROWS
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 316 -
bloków.
28. STROJENIE INSTANCJI
- 317 -
ciągáej przestrzeni na dysku. Rozwiązanie tych problemów wymaga rozszerzenia lub dodania pliku danych
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
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:
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.
SELECT owner, segment_name, segment_type,
count(*) liczba_rozszerzeĔ
FROM dba_extents
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ü
GROUP BY owner, segment_name, segment_type;
przechowywane. Przydzielanie tych rozszerzeĔ jest procesem bardzo kosztownym, dlatego przy strojeniu
OWNER
SCOTT
SCOTT
SCOTT
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ü
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Ğ
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
obiektu dynamicznie wzrasta, wówczas naleĪy rozwaĪyü zwiĊkszenie wartoĞci parametrów skáadowania
next oraz pctincrease tego obiektu.
rekordów tabeli. Minusem tego rozwiązania mogą byü problemy z przydzieleniem wystarczająco duĪej,
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 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:
28. STROJENIE INSTANCJI
- 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
a) proces uĪytkownika stwierdzi, Īe lista LRU przekroczyáa okreĞlony rozmiar;
segmentów wycofania jak to ma miejsce w trybie pracy RBU (ang. Rollback Segment Undo). Praca w trybie
b) proces uĪytkownika nie znajdzie wolnego bloku w buforze danych, a bufor taki jest wymagany do
RBU jest moĪliwa ze wzglĊdu na koniecznoĞü zachowania zgodnoĞci z poprzednimi wersjami systemu
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
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
parametr DB_BLOCK_CHECKPOINT_BATCH. Ustawienie wartoĞci tego parametru na odpowiednio
UNDO_RETENTION, okreĞlającego jak dáugo dane mają pozostawaü na dysku. Znając tą wartoĞü oraz iloĞü
niewielką wartoĞü zapobiega dyskryminacji pozostaáych zadaĔ realizowanych przez DBWR, natomiast
generowanych danych wycofania na sekundĊ, moĪna wyliczyü wielkoĞü przestrzeni wycofania za pomocą
wyĪsza wartoĞü tego parametru umoĪliwia szybsze wykonanie punktu kontrolnego.
wzoru:
28.2.6. Strojenie segmentów wycofywania
We wczeĞniejszych wersjach systemu Oracle, spójnoĞü odczytu danych obsáugiwana byáa przez
WielkoĞü przestrzeni=czas przechowywania * iloĞü informacji w jednostce czasu
Przykáadowo, jeĞli czas przechowywania wynosi 200s, a system generuje 100 bloków informacji
mechanizm segmentów wycofania. Od wersji Oracle9i wprowadzony zostaá nowy, automatyczny
wycofania na sekundĊ, to otrzymamy:
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 320 -
- 321 -
wykonywania takiej transakcji wystąpi báąd snapshot too old, wówczas czas przechowywania naleĪy
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,
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.
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.
§ 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Ĕ;
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
28. STROJENIE INSTANCJI
spójnego obrazu bazy przez caáy czas) warto zastanowiü siĊ nad zwiĊkszeniem tego czasu. JeĞli w trakcie
Liczba bloków undo = (200s)*(100 bloków/s) = 20000 bloków
x przekroczony zostanie czas okreĞlony parametrem konfiguracyjnym
LOG_CHECKPOINT_TIMEOUT
od poprzedniego punktu kontrolnego;
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 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;
28. STROJENIE INSTANCJI
- 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.
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
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
jednoczeĞnie wprowadza dodatkowy narzut w postaci czĊstych zapisów zmodyfikowanych bloków danych
FROM v$sysstat
na dysk.
WHERE name IN (‘sorts(memory)’, ’sorts(disk)’);
Punkty kontrolne mogą jednoczeĞnie obciąĪaü proces LGWR, odpowiedzialny za zapisanie informacji
kontrolnych do wszystkich plików danych i plików kontrolnych.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
NAME
sorts(memory)
sorts(disk)
VALUE
19
0
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 324 -
JeĪeli liczba operacji sortowania na dysku jest zbyt duĪa, wówczas moĪna rozwaĪyü zwiĊkszenie
wartoĞci parametru
28. STROJENIE INSTANCJI
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.
SORT_AREA_SIZE.
ZwiĊkszenie tego parametru skutkuje szybszym wykonywaniem sortowania i zmniejszeniem liczby operacji
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
wejĞcia-wyjĞcia.
Po zwiĊkszeniu obszaru sortowania moĪna zmniejszyü wielkoĞü obszaru pozostawionego za pomocą
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ą
parametru
wielokrotnoĞcią wartoĞci SORT_AREA_SIZE. Trzeba upewniü siĊ, aby wielkoĞci te byáy dostatecznie duĪe,
SORT_AREA_RETAINED_SIZE.
co zmniejszy liczbĊ alokacji nowych rozszerzeĔ.
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
§ 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.
indywidualnie.
W procesie sortowania, obok obszaru sortowania, udziaá bierze takĪe przestrzeĔ tymczasowa, która
Aby zapisaü dane w buforze dziennika powtórzeĔ, proces uĪytkownika musi najpierw uzyskaü semafor
przechowuje poĞrednie wyniki podczas sortowania duĪych iloĞci danych. WáaĞciwe skonfigurowanie
alokujący, przydzielający fragment bufora dziennika powtórzeĔ, do którego nastĊpnie kopiowane są
przechowywania danych tymczasowych przyczynia siĊ do wzrostu wydajnoĞci systemu.
stosowne informacje.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
28. STROJENIE INSTANCJI
- 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.
28. STROJENIE INSTANCJI
- 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
PoniewaĪ istnieje tylko jeden semafor alokacyjny, zatem jednoczeĞnie do bufora zapisywaü moĪe tylko
oczekiwaniem, to rozpoczyna oczekiwanie na jego zwolnienie. JeĪeli natomiast proces Īądający
jeden proces uĪytkownika. Maksymalna wielkoĞü danych, jaka moĪe byü zapisana po pojedynczym
wyáącznego dostĊpu do semafora w trybie natychmiastowym nie otrzyma dostĊpu, to kontynuuje swoje
uzyskaniu semafora alokującego okreĞlona jest parametrem konfiguracyjnym
przetwarzanie.
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.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
IMM_MISSES
0
3
28. STROJENIE INSTANCJI
- 328 -
StopieĔ rywalizacji w kaĪdym z tych przypadków okreĞla siĊ jako stosunek nieudanych dostĊpów do
28. STROJENIE INSTANCJI
CLASS
free list
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
- 329 -
WHERE class = ‘free list’;
COUNT
0
JeĞli liczba oczekiwaĔ na listĊ przekracza 1% wszystkich ĪądaĔ, wówczas naleĪy zwiĊkszyü liczbĊ takich
LOG_SMALL_ENTRY_MAX_SIZE,
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.
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
SELECT SUM(value) Liczba_zadan
FROM v$sysstat
WHERE name in (‘db block gets’, ‘consistent gets’);
LOG_SIMULTANEOUS_COPIES,
LICZBA_ZADAN
2332
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
Rywalizacja o listy wystĊpuje gáównie przy wspóábieĪnym wykonywaniu przez wiele sesji operacji
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.
wstawiania insert, zatem optymalna liczba list wolnych bloków powinna byü równa liczbie sesji
równoczeĞnie wstawiających dane do bazy.
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
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
29. WYZWALACZE INSTEAD OF I SYSTEMOWE
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
- 330 -
29. WYZWALACZE INSTEAD OF I SYSTEMOWE
§ 29.1. Wyzwalacze INSTEAD OF
Wyzwalacze INSTEAD OF (zamiast) umoĪliwiają np. modyfikowanie perspektyw (widoków), których
29. WYZWALACZE INSTEAD OF I SYSTEMOWE
Przykáady zdarzeĔ systemowych:
AFTER STARTUP, BEFORE SHUTDOWN, AFTER LOGON, AFTER DROP, AFTER
GRANT, AFTER CREATE,…
zawartoĞü nie moĪna zmieniaü uĪywając poleceĔ DML (np. perspektyw utworzonych z klauzulą GROUP
Przykáad 29.2.1. Przykáad rejestracji logowaĔ:
BY).
CREATE TABLE rejestracja_logowania
(
CREATE OR REPLACE TRIGGER nazwa_wyzwalacza
user VARCHAR2(15),
INSTEAD OF INSERT ON perspektywa
data_logowania DATE
DECLARE
...
BEGIN
...
END;
§ 29.2. Wyzwalacze systemowe
Wyzwalacze systemowe mogą byü definiowane na poziomie bazy danych lub na poziomie schematu
);
CREATE OR REPLACE TRIGGER rejestracja_logowania
AFTER LOGON
ON SCHEMA
BEGIN
INSERT INTO rejestracja_logowania VALUES (user, SYSDATE);
END;
uĪytkownika.
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
-331-
29. WYZWALACZE INSTEAD OF I SYSTEMOWE
Przykáad 29.2.2. Przykáad rejestracji operacji STARTUP i SHUTDOWN:
CREATE TABLE rejestracja_start (operacja VARCHAR2(15),data DATE);
-332-
29. WYZWALACZE INSTEAD OF I SYSTEMOWE
-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Ī
CREATE OR REPLACE TRIGGER rejestracja_start
AFTER STARTUP
nie naleĪy w czĊĞci deklaracyjnej uĪyü PRAGMA AUTONOMOUS_TRANSACTION.
Przykáad 29.3.1. Przykáad wyzwalacza z transakcją autonomiczną:
ON DATABASE
BEGIN
INSERT INTO rejestracja_start VALUES (‘startup’,SYSDATE);
END;
CREATE OR REPLACE TRIGGER rejestracja
BEFORE INSERT ON sprzedaz
FOR EACH ROW
DECLARE
CREATE OR REPLACE TRIGGER rejestracja_start
BEFORE SHUTDOWN
ON DATABASE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO rejestracja VALUES (:NEW.id_towaru, :NEW.ilosc, SYSDATE);
BEGIN
INSERT INTO rejestracja_start VALUES (‘shutdown’,SYSDATE);
END;
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”
COMMIT;
END;
Rok akademicki – 2007/2008 - Notatki do wykáadów z przedmiotu „Administracja bazami danych”

Podobne dokumenty