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”