JSystems Administracja Oracle Kompendium wiedzy 2010-01-04 1
2
Globalny obszar systemowy - SGA Serwer Oracle składa się z plików bazy danych oraz instancji Oracle, której budowa jest przedstawiona na powyższym rysunku. Instacja Oracle składa się z zaalokowanych buforów pamięci, znanych jako SGA (System Global Area) oraz procesów, obsługujących dużą część niskopoziomowych zadań związanych z pracą instancji. Instancja Oracle zaczyna swoje życie wraz z wystartowaniem bazy danych w pierwszej fazie startu odczytywany jest plik parametrów inicjalizacyjnych, na podstawie którego konfigurowane są właściwości instancji. Po wystartowaniu instancji oraz otworzeniu bazy danych, użytkownicy mogą się łączyć do serwera Oracle. Wielkość buforów w ramach SGA jest określana automatycznie na podstawie dwóch parametrów: SGA_MAX_SIZE maksymalny rozmiar, jaki może przyjąć SGA; SGA_TARGET rozmiar SGA, jaki chcielibyśmy docelowo uzyskać; ustawienie tego parametru na wartość niezerową oznacza, że włączyliśmy automatyczne strojenie wielkości buforów składających się na obszar SGA; jedynym buforem, który nie podlega automatycznemu strojeniu jest Redo Buffer; 3
Sreams Pool Streams Pool jest buforem, który pojawił się dopiero w bazie 10g. Jest on wykorzystywany przez technologię streams, szczególnie przydatną, gdy chcemy skonfigurować replikację lub bazę typu Stand By. Jego wielkość określana jest poprzez parametr STREAMS_POOL_SIZE. 4
Large Pool Large Pool, to opcjonalny obszar wykorzystywany przy dużych operacjach dyskowych. Staje się szczególnie przydatny, gdy konfigurujemy bazę danych w trybie serwera współdzielonego, lub korzystamy z narzędzia RMAN. Jego wiekość określa parametr inicjalizacyjny LARGE_POOL_SIZE. 5
Java Pool Java Pool, bufor przeznaczony do operacji na klasach języka JAVA, składowanych bezpośrednio w bazie danych. 6
Shared Pool Shared Pool jest częścią SGA, która zawiera współdzielone obszary pamięci takie jak obszar SQL, bufor słownika danych oraz sparsowane lub skompilowane reprezentacje bloków PL/SQL. Głównymi komponentami Shared Pool są bufory Library Cache (bufor biblioteczny),dictionary Cache (bufor słownika danych) oraz Result Cashe (bufor wynikowy). Rozmiar bufora Shared Pool znacząco wpływa na ilość fizycznych odczytów dyskowych. Kiedy zapytanie SQL jest wykonywane, proces serwera sprawdza, czy informacje obiektach, do których odwołuje się to zapytanie (właściciel obiektu, poziom uprawnień dostępu do obiektów, typ obiektu itp. ) znajdują się w buforze słownika danych. Jeśli nie, informacje te są ładowane do bufora za pomocą fizycznego odczytu z dysku (z tabel słownika danych z przestrzeni tabel SYSTEM). Następnie proces serwera weryfikuje, czy sparsowana forma wykonywanego zapytania SQL znajduje się w buforze bibliotecznym. Jeśli tak, zapytanie jest natychmiast wykonywane. Jeśli nie, przechodzi ono drogę parsowania (mechanizm zostanie dokładnie omówiony w następnych rozdziałach), następnie umieszczane jest w buforze bibliotecznym i dopiero wykonane. Ponieważ proces parsowania zapytań oraz odczyty dyskowe są operacjami kosztownymi, staramy się dążyć do tego, aby wielokrotnie powtarzane zapytania posiadały odpowiednie informacje zbuforowane w strukturach pamięci operacyjnej (Shared Pool). Informacje przechowywane w Dictionary Cache oraz Library Cache są zarządzane za pomocą algorytmu LRU (Last Recently Used). 7
Dictionary Cashe Dictionary Cache przechowuje natomiast takie informacje jak nazwa użytkownika, uprawnienia do obiektów, informacje o segmentach, przestrzeniach tabel oraz numery wykorzystywanych sekwencji. 8
Library Cashe Library Cache jest odpowiedzialny za przechowywanie wykonywalnych postaci ostatnio używanych poleceń SQL oraz kodu PL/SQL. 9
Shared SQL Area Główne cechy współdzielonego obszaru SQL: Współdzielony obszar SQL jest modułem wymaganym do przeprocesowania każdego unikalnego polecenia SQL zadanego do bazy danych; Zawiera informacje na temat planu wykonania zapytania dla korespondującego wyrażenia języka SQL; Pojedynczy obszar SQL jest wykorzystywany przez wielu użytkowników bazy danych w ramach korzystania z tego samego zapytania SQL; Wewnątrz współdzielonego obszaru SQL, każde wyrażenie jest parsowane we własnym podobszarze, znanym jako kursor. Jeżeli dwóch różnych użytkowników wykona identyczne zapytanie SQL, mogą oni korzystać z tego samego, współdzielonego kursora. Mechanizm współdzielonych kursorów wpływa pozytywnie na utylizację pamięci oraz poprawia ogólnie pojmowaną wydajność poleceń SQL. 10
0 Result Cashe Result Cashe jest nowo powstałym buforem, zaimplementowanym w wersji 11g bazy danych Oracle. Bufor ten odpowiedzialny jest za przechowywanie zbuforowanych wyników zapytań lub funkcji, w których jawnie poleciliśmy skorzystanie z omawianego bufor. Główne parametry bufora: result_cache_max_size maksymalny rozmiar bufora. Standardowo parametr ten ustawiany jest dynamicznie podczas startu instancji. Isnieje możliwość modyfikacji parametru. Jeśli wartość parametru zostanie ustawiona na 0, oznaczało to będzie wyłączenie funkcjonalności buforowania wyników. result_cache_mode parametr może przyjąć jedną z dwóch wartości : MANUAL (ustawienie standardowe) lub FORCE. Ustawienie warości na FORCE spowoduje wykorzystanie przez Oracle bufora zawsze, jeżeli będzie to możliwe. W przypadku wartości MANUAL konieczne jest jawne dołącznie instrukcji wymuszającej korzystanie z bufora np.: hint w zapytaniu SQL (/*+ result_cache */). result_cache_max_result parametr określa maksymalną, procentową wielkość, jaką może zająć jeden zbuforowany wynik w result cache. 11
12
Default Bufor bazy danych jest zbiorem buforów pamięci w obszarze SGA, odpowiedzialnych za przechowywanie bloków danych, pochodzących z przestrzeni tabel (składowanie danych na dysku zostanie szerzej omówione w następnych rozdziałach). Standardowa wielkość pojedynczego bloku danych jest ustalana na etapie kreowania bazy danych za pomocą parametru DB_BLOCK_SIZE. Za umieszczenie bloków danych w buforze danych odpowiedzialne są procesy serwera, zapisów natomiast dokonuje proces, zwany DBWR (Database Writer). Bufor może znajdować się w jednym z trzech stanów: Free zawartość bufora została wyczyszczona, lub jego stan jest identyczny, jak bloku danych przechowywanego na dysku. Bufor w tym stanie może zostać nadpisany przez dowolny blok danych w każdym momencie; Dirty bufor przetrzymuje blok danych, który został zmieniony; Pinned bufor jest w trakcie modyfikacji; jest to bardzo krótki stan związany z chwilą zapisu lub odczytu bloku danych. Kiedy inny proces próbuje się dostać do bufora w momencie kiedy jest on używany, generowany jest komunikat oczekiwania (tzw. wait event ) o nazwie buffer busy wait (zdarzenia typu wait event są szerzej omówione w kursie optymalizacji wydajności instancji Oracle); Kiedy blok danych zostanie zmodyfikowany, zmiany są aplikowane do jego oryginalnej wersji, jednak w celu zachowania spójności odczytu (Consistensy Read), tworzona jest jego osobna kopia (CR), która związana jest z przestrzenią tabel UNDO. 13
Bufor danych nie jest jednolitym obszarem w ramach SGA. Przy standardowej konfiguracji mamy możliwość korzystania tylko z bufora typu DEFAULT, którego wielkość określana jest automatycznie na podstawie parametrów, odpowiedzialnych za automatyczne strojenie wielkości SGA. W razie potrzeby możemy jednak stworzyć dodatkowe bufory danych. 14
Keep Keep ten bufor jest przeznaczony do korzystania z małych lub często używanych obiektów, które mogłyby skorzystać ze stałego przebywania w pamięci. Jego rozmiar określa się na sumę wielkości obiektów, które chcielibyśmy utrzymywać na stałe w buforze plus niewielki procent przeznaczony na kopie typu CR. Rozmiar tego bufora jest określany za pomocą parametru inicjalizacyjnego DB_KEEP_CACHE_SIZE. Zachowanie algorytmu LRU (Last Recently Used) jest takie samo w przypadku każdego z typów buforów danych jeżeli wielkość bufora Keep będzie mniejsza niż suma wielkości obiektów, które będziemy chcieli przetrzymywać, niektóre bloki będą usuwane z bufora. 15
Recycle Recycle ten bufor jest używany przez obiekty, które nic nie uzyskują przez przetrzymywanie w pamięci a mogą wręcz przeszkadzać, zabierając zasoby innym obiektom. To są zazwyczaj duże tabele, do których dostęp następuje na zasadach losowych a pobrane bloki danych nie są wykorzystywane przez inne procesy w systemie Oracle. Zazwyczaj rozmiar takiego bufora jest minimalny, tak aby móc przechować w pamięci tylko wiersze niezbędne dla bieżących transakcji. Rozmiar bufora Recycle jest ustalany na podstawie parametru DB_KEEP_CACHE_SIZE 16
nk buffer cache nk buffer cache wszystkie omówione do tej pory rodzaje buforów danych przechowują bloki o standardowej wielkości ustalonej na etapie tworzenia bazy danych (zazwyczaj 8 kb). Istnieje jednak możliwość zdefiniowania buforów danych do przechowywania obiektów o wielkości bloku danych innej niż standardowa aby to osiągnąć należy stworzyć osobną przestrzeń tabel, specyfikując inną wielkość bloku danych a następnie ustawić rozmiar odpowiedniego bufora za pomocą parametrów inicjalizacyjnych: DB_2K_CACHE_SIZE DB_4K_CACHE_SIZE DB_8K_CACHE_SIZE DB_16K_CACHE_SIZE DB_32K_CACHE_SIZE 17
Uruchomienie wielu buforów Klauzula BUFFER_POOL jest używana do zdefiniowania standardowego bufora danych, który ma być używany przez dany obiekt. Gdy standardowy bufor danych, który ma być używany przez obiekt jest zmieniany za pomocą polecenia ALTER, jego bloki danych, które znajdują się już w buforach pozostają w nich aż do momentu usunięcia za pomocą standardowych mechanizmów. Do nowej lokalizacji bloki danych trafiają dopiero przy fizycznym odczycie z dysku. Jeżeli przy tworzeniu obiektu nie zostanie określony żaden bufor, obiekt będzie wykorzystywał bufor typu DEFAULT. Ponieważ rodzaje buforów można przypisywać do segmentów, obiekty które składają się z wielu segmentów mogą być przechowywane w różnych buforach danych. Np. w przypadku partycjonowania, każda z partycji tabeli lub indeksu może być przechowywana w innym buforze danych. 18
Redo Buffer - Bufor dziennika powtórzeń Redo zawiera przepisy zmian bazy danych. Oznacza to, że każda instrukcja zmieniająca bazę danych (instrukcje UPDATE, INSERT, DELETE, ALTER, CREATE, itp. ) po skąpilowaniu zostanie umieszczona w buforze redo (bufor dziennika powtórzeń) a następnie zostanie umieszczona w tzw. Redo Log ach (pliki dziennika powtórzeń zostaną one szczerzej omówione w następnych rozdziałach). Mechanizm ten chroni bazę danych przed utratą spójności danych w razie awarii (np. spowodowanej uszkodzeniem zasilania). 19
Obszar pamięci - PGA Globalny Obszar Programu lub Globalny Obszar Procesu ( PGA ) jest to obszar pamięci zawierający informacje wykorzystywaną przez pojedynczy proces serwera lub proces drugoplanowy. PGA jest alokowany podczas uruchamiania procesu i de alokowany podczas jego zatrzymywania. W przeciwieństwie do SGA, który jest współdzielony przez wiele procesów PGA jest obszarem pamięci wykorzystywanym przez pojedynczy proces i nie może być współdzielony. W konfiguracji zwanej dedykowaną PGA zawiera następujące składniki: Obszary wykonawcze SQL: Obszar sortowania: wykorzystywany przez operacje sortowania w ramach poleceń SQL; Obszar hash join: używany przy wykorzystywaniu operacji łączenia zbiorów wierszy za pomocą algorytmów HASH owych; Obszar operacji bitmapowych: obszar używany przy opracjach związanych z użyciem indeksów typu BITMAP; Obszar informacji o sesji użytkownika: zawiera przywileje użytkownika i statystyki wydajności dla danej sesji; Stan kursora: Określa stan wykonywanych w ramach danej sesji poleceń SQL; Obszar stosu: Zawiera zmienne wykorzystywane przez dany proces; Jeśli porcje danych są zbyt duże aby zmieściły się w obszarach buforu PGA, dane zostają podzielone na mniejsze porcje, gdzie część z nich zostaje chwilowo przechowywana w tymczasowych przestrzeniach tabel (zjawisko to powoduje wzmożone operacje zapisów i odczytów dyskowych). 20
Uwaga: Niektóre z tych struktur w konfiguracji wielokanałowej (serwer współdzielony) są składowane w SGA. W konfiguracji takiej możliwe jest współdzielenie pojedynczego procesu serwera przez wiele sesji użytkowników. Jeżeli large pool istnieje to jest on wykorzystywany do składowania danych związanych z sesją użytkownika, w przeciwnym wypadku dane te są składowane w obszarze dzielonym (shared pool). 21
22
0 Proces Monitora Systemu - SMON System Monitor (SMON) proces odpowiedzialny za automatyczne odtwarzanie bazy danych po krytycznej awarii (odtwarzanie odbywa się na podstawie mechanizmu REDO szerzej omawianego w dalszej części kursu). Dodatkowo proces odpowiedzialny jest za czyszczenie segmentów tymczasowych we wszystkich przestrzeniach tabel, odbywające się podczas restartu systemu. 23
Proces Monitora Procesów - PMON Process Monitor (PMON) jest to proces, którego zadaniem jest monitorowanie zasobów przydzielonych do określonych sesji oraz de alokację ich w przypadku utraty przez sesję połączenia z Serwerem Oracle np.: Użytkownik dokonał modyfikacji kilku wierszy w tabeli A, lecz nie zatwierdził jeszcze zmian. Źródła zostały zablokowane przez daną sesje. Następnie nastąpiła awaria stacji roboczej użytkownika (sesja z Serwerem została przerwana). PMON w tym momencie wykrywa, iż nastąpiło przerwanie sesji oraz wykonuje następujące operacje: Wycofuje zmiany, które dokonała dana sesja (ROLLBACK), Oznacza bloki danych znajdujące się w BUFFER CACHE (te które zostały zmodyfikowane przez użytkownika), jako wolne, Zdejmuje blokady z modyfikowanych rekordów tabeli, Usuwa ID procesu z listy procesów aktywnych. Process Monitor dodatkowo dostarcza inforamcji do LISTENERA(procesu nasłuchu bazy danych) o statusie instancji dla nadchodzących żądań nawiązania połączenia z Serwerem. 24
Proces Punktu Kontrolnego - CKPT Checkpoint mechanizm checkpoint w bazie Oracle ma charakter inkrementalny, dzięki czemu w połączeniu z mechanizmem Redo baza Oracle posiada podniesioną odporność na krytyczne awarie. Checkpoint jako proces działający na systemie operacyjnym, uaktualnia nagłówki plików danych oraz plików kontrolnych najświeższymi informacjami, określając wersję bazy danych na podstawię numeru SCN (System Change Number). Z informacji zapisywanych przez proces checkpoint korzysta System Monitor podczas odtwarzania bazy w trakcie awarii. 25
Proces Sekretarza Bazy Danych - DBWn Proces Sekretarza Bazy Danych (DBWRn) znany w starszych wersjach bazy danych Oracle jako DBWR (database writer process) zapisuje nowe, bądź modyfikuje stare bloki danych znajdujące się w buforze danych (Buffer Cashe) do plików bazy danych. Liczba "sekretarzy" może być modyfikowana za pośrednictwem parametru: DB_WRITER_PROCESSES. 26
Proces Sekretarza Dziennika Powtórzeń - LGWR Proces Sekretarza Dziennika Powtórzeń - LGWR jest jedny z najaktywniejszych i najważniejszych procesów instancji podczas wykonywania operacji DML. Zapisuje on "przepisy" modyfikujące bazę danych do plików dziennika powtórzeń. Transakcja DML włącznie z transakcją COMMIT nie zostaną poprawnie zakończone jeśli LGWR nie zapisze informacji do plików redo log. Dodatkowo "brudne" bloki danych z bufora danych także nie zostaną zapisane na dysk, jeśli informacja o ich modyfikacji nie zostanie zapisana w plikach dziennika powtórzeń. 27
Proces archiwizacji ARCn Jeśli baza danych znajduje się w trybie ARCHIVELOG, wtedy archiver process (ARCn) zapisuje kopie plików dziennika powtórzeń do innych lokalizacji. Sytuacja ta następuje wtedy, gdy plik dziennika powtórzeń osiągnie swój maksymalny rozmiar i następuje przełączenie zapisu danych na kolejny plik redo log. Ilość procesów ARCn rególowana jest poprzez parametr inicjalizacyjny ARCHIVE_MAX_PROCESSES. 28
Perspektywy słownika danych W celu przeglądania metadanych naszej bazy, Oracle udostępnia szereg interfejsów w postaci perspektyw słownika danych. Mamy do czynienia z perspektywami o trzech różnych przedrostkach: USER_* - zestaw perspektyw, umożliwiający dostęp do obiektów posiadanych przez użytkownika, na którego jesteśmy zalogowani w danym momencie; ALL_* - zestaw perspektyw, pozwalający na przeglądanie metadanych obiektów, do których mamy uprawnienia; DBA_* - perspektywy z tym przedrostkiem pozwalają na przeglądanie informacji o wszystkich obiektach w bazie danych, do odpytywania tych perspektyw trzeba mieć osobne uprawnienia; 29
30
Aby uruchomic instancję serwer Oracle musi odczytać plik parametrów inicjalizacyjnych. Istnieją dwa typy plików parametrów inicjalizacyjnych: Statyczny plik parametrów inicjalizacyjnych, PFILE, zwykle nazywany plikiem initsid.ora Dynamiczny plik parametrów inicjalizacyjnych, SPFILE, zwykle nazywany plikiem spfilesid.ora Zawartość pliku parametrów inicjalizacyjnych Lista parametrów inctancji Nazwa bazy danych związanej z instancją Rozmiary struktur pamięciowych System Global Area (SGA) Informacje o metodach postępowania z zapełnionymi plikami dziennika powtórzeń Nazwy i lokalizacje plików kontrolnych Informacje o segmentach wycofania 31
PFILE jest plikiem tekstowym, który może być edytowany przy pomocy standardowego w danym systemie operacyjnym edytora tekstów. Plik ten jest odczytywany jedynie podczas uruchamiania instancji, nie jest natomiast przez instancję zapisywany stąd jeśli wprowadzimy do niego jakieś zmiany, to instancję należy zamknąć i ponownie uruchomić aby zmiany wartości parametrów przyniosły jakieś efekty. Niektóre parametry inicjalizacyjne są dynamiczne, co oznacza, że mogą być modyfikowane podczas pracy instancji. Zmiany wartości parametrów dynamicznych w instancji nie są odzwierciedlane w PFILE. Domyślnie plik PFILE jest umieszczony w systemie Unix w katalogu $ORACLE_HOME/dbs, jego domyślną nazwą jest initsid.ora. Podczas instalacji oprogramowania serwera Oracle11g Universal Installer tworzy przykładowy plik init.ora. Ów przykładowy plik może być użyty do tworzenia plików wykorzystywanych przez rzeczywiste instancje. 32
SPFILE jest plikiem binarnym. Plik ten nie jest przeznaczony do ręcznych modyfikacji. Domyślnie plik ten znajduje się w katalogu $ORACLE_HOME/dbs, jego domyślna nazwa ma format spfilesid.ora. Plik ten jest tworzony i utrzymywany przez serwer Oracle. SPFILE dostarcza możliwości dokonywania zmian wartości parametrów inicjalizacyjnych, które będą widoczne również po ponownym uruchomieniu instancji. W celu dokonania zmiany wartości parametru inicjalizacyjnego należy wykonać polecenie ALTER SYSTEM. Klauzula SCOPE tego polecenia służy do określenia zakresu dokonanej zmiany. MEMORY: Zmiana wartości parametru tyczy się jedynie aktualnie uruchomionej instancji, nie jest odzwierciedlana w pliku SPFILE SPFILE: Zmiana wartości parametru tyczy się jedynie pliku SPFILE, nie powoduje zmiany parametru w obrębie uruchomionej instancji BOTH: Zmiana tyczy się zarówno instancji jak i pliku SPFILE ALTER SYSTEM SET parameter = value [SCOPE = MEMORY SPFILE BOTH] Począwszy od bazy danych Oracle 11g mamy możliwość zmiany parametrów inicjalizacyjnych z opcją MEMORY a następnie tworzenia pliku SPFILE z pamięci za pomocą komendy: Create spfile from memory; 33
34
Gdy baza danych zostaje zamontowana otwierane są pliki kontrolne. Są to jedne z najbardziej krytycznych plików dla działania bazy danych. Pliki kontrolne przechowują informacje o położeniu wszystkich plików danych oraz plików redo bazy danych. Kiedy nowe pliki są dodawane, zawartość plików kontrolnych jest natychmiast uaktualniana. W plikach kontrolnych mogą również znajdować się informacje o przeprowadzonych backup ach. Lokalizacja plików kontrolnych znajduje się w pliku parametrów inicjalizacyjnych. W celu uniknięcia awarii bazy danych należy stworzyć wiele lokalizacji położeń plików kontrolnych (zalecane są przynajmniej trzy osobne kontrolery). W przypadku utraty przynajmniej jednego z plików kontrolnych baza Oracle nie uruchomi się. Jeśli jednak przechowujemy pliki kontrolne w różnych lokalizacjach, wystarczy skopiować nieuszkodzony plik z jednej z zachowanych lokalizacji. 35
Pliki dziennika powtórzeń są zorganizowane w grupy. Każda grupa musi posiadać przynajmniej jednego członka, przy czym każdy z członków grupy posiada dokładnie taką samą zawartość. Dla celów bezpieczeństwa wskazane jest posiadanie po dwóch lub więcej członków w grupie, chyba że zapewniona została redundancja na poziomie sprzętowym (np. RAID). W chwili, gdy tworzymy grupy dzienników powtórzeń określamy ich wielkość (każdy z członków grupy ma dokładnie taką samą wielkość bez możliwości modyfikacji). Proces Log Writer zapisuje informacje z bufora redo do grupy (do każdego z jej członków) aż do chwili, gdy skończy się miejsce w grupie. Następnie następuje przełączenie (tzw. switch) i proces zapisuje dane do kolejnej grupy, itd.. Kiedy w ostatniej grupie skończy się miejsce nadpisywana jest pierwsza i proces się powtarza. Dla zachowania ciągłości odtwarzania bazy danych uruchamia się tryb archiwizacji (ARCHIVELOG). Dzięki temu, po każdym switchu następuje skopiowanie grupy redo we wskazane przez nas miejsce oraz oznaczenie jej unikalną nazwą. Takie skopiowane pliki redo noszą nazwę ARCHIVELOG ÓW. Położenie plików ARHCIVELOG rejestrowane jest w pliku kontrolnym. Powyższy diagram pokazuje jedną z metod rozmieszczenia plików dziennika powtórzeń na przestrzeni dyskowej w celu uzyskania bezpiecznej konfiguracji. 36
Architektura bazy danych Oracle składa się ze struktur logicznych i fizycznych. Struktury fizyczne obejmują pliki kontrolne, bieżące pliki dziennika powtórzeń i pliki danych. Struktury logiczne obejmują przestrzenie tabel, segmenty, ekstenty i bloki bazy danych. Serwer Oracle umożliwia szczegółową kontrolę przestrzeni dyskowej poprzez przestrzenie tabel i logiczne struktury składowania takie jak segmenty, ekstenty i bloki danych. Dane w bazie danych są składowane w przestrzeniach tabel. Baza danych może zostać podzielona na mniejsze struktury logiczne zwane przestrzeniami tabel. Przestrzeń tabel może należeć tylko do jednej bazy danych. Każda przestrzeń tabel składa się z jednego lub kilku plików systemu operacyjnego zwanych plikami danych. Przestrzeń tabel może zawierać zero lub więcej segmentów. Przestrzenie tabel mogą być włączane podczas normalnej pracy bazy danych. Poza przestrzenią tabel SYSTEM oraz przestrzeniami z aktywnymi segmentami wycofania pozostałe przestrzenie tabel mogą zostać wyłączone podczas normalnej pracy bazy danych. Przestrzenie tabel mogą być przełączane z trybu Do Odczytu I Zapisu do trybu Tylko Do Odczytu i odwrotnie. 37
Serwer Oracle 11g przedstawia nową metodę zarządzania wykrywaniem, diagnozowaniem oraz rozwiązywaniem problemów związanych z różnymi rodzajami korupcji bazy danych. ADR stanowi repozytorium dla plików śledzenia, zawierających informacje o problemach występujących w bazie danych. Pliki są przechowywane w systemie plików systemu operacyjnego w katalogach o specjalnej strukturze a każda instancja Oracle posiada własny zestaw katalogów. Nowy parametr inicjalizacyjny diagnostic_dest określa położenie struktury repozytorium ADR i tym samym sprawia, że parametry [user core background]_dump_dest stają się bezużyteczne. Repozytorium ADR dzieli się na następujące katalogi: Alert w tej lokalizacji znajduje się plik alert log, sformatowany do postaci XML; Cdump ten folder zawiera pliki zrzutu typu core; Trace stanowi zbiór plików śledzenia, wygenerowanych przez system; tutaj znajduje się też tekstowa wersja pliku alert log; Incident w tym katalogu znajduje się wiele podkatalogów, po jednym na każdy incydent. Nowa perspektywa wydajnościowa V$DIAG_INFO dostarcza informacji na temat szczegółowego położenia poszczególnych elementów ADR. W celu skutecznego poruszania się po repozytorium ADR, sprowadzone zostało nowe narzędzie: ADRCI (dokładny opis narzędzia ADRCI można znaleźć w dokumentacji Oracle 11g). 38
39
Celowość wprowadzenia przestrzeni tabel Architektura bazy danych Oracle składa się ze struktur logicznych i fizycznych. Struktury fizyczne obejmują pliki kontrolne, bieżące pliki dziennika powtórzeń i pliki danych. Struktury logiczne obejmują przestrzenie tabel, segmenty, ekstenty i bloki bazy danych. Serwer Oracle umożliwia szczegółową kontrolę przestrzeni dyskowej poprzez przestrzenie tabel i logiczne struktury składowania takie jak segmenty, ekstenty i bloki danych. Przestrzenie tabel: Dane w bazie danych są składowane w przestrzeniach tabel. Baza danych może zostać podzielona na mniejsze strultury logiczne zwane przestrzeniami tabel. Przestrzeń tabel może należeć tylko do jednej bazy danych. Każda przestrzeń tabel składa się z jednego lub kilku plików systemu operacyjnego zwanych plikami danych. Przestrzeń tabel może zawierać zero lub więcej segmentów. Przestrzenie tabel mogą być włączane podczas normalnej pracy bazy danych. Poza przestrzenią tabel SYSTEM oraz przestrzeniami z aktywnymi segmentami wycofania pozostałe przestrzenie tabel mogą zostać wyłączone podczas normalnej pracy bazy danych. Przestrzenie tabel mogą być przełączane z trybu Do-Odczytu-I-Zapisu do trybu Tylko-Do- Odczytu i odwrotnie. 40
Sposób zarządzania przestrzeniami tabel Ekstenty mogą być zarządzane poprzez słownik danych lub mapy bitowe. Podczas tworzenia przestrzeni tabel administrator określa metodę zarządzania ekstentami. Później nie można już jej zmienić. Lokalnie zarządzane przestrzenie tabel Przestrzeń tabel, która sama zarządza swoimi ekstentami utrzymuje ich mapę bitową w każdym pliku danych. W mapie tej znajduje się informacja o każdym wolnym lub zajętym ekstencie. Każdy bit w owej mapie jest związany z blokiem lub grupą bloków danych. Podczas alokacji lub dealokacji ekstentu serwer Oracle zmienia wartości odpowiednich bitów aby odzwierciedlić nowy stan bloków danych. Przestrzenie tabel zarządzane poprzez słownik danych Alokacja lub dealokacja ekstentu w tak zarządzanej przestrzeni tabel przekłada się na modyfikacje zawartości odpowiednich tabel słownika danych przechowujących informacje o zajętych i wolnych ekstentach. Zalety lokalnie zarządzanych przestrzeni tabel Lokalnie zarządzane przestrzenie tabel mają w porównaniu do przestrzeni zarządzanych przez słownik danych następujące zalety: umożliwiają redukcję rekursywnych operacji zarządzania przestrzenią, które występują w przestrzeniach tabel zarządzanych przez słownik danych podczas wykonywania operacji powodujących rozszerzanie segmentów wycofania lub tabel słownika danych. Ponieważ lokalnie zarządzane przestrzenie tabel nie zapisują informacji o wolnej przestrzeni w słowniku danych, to umożliwiają tym samym redukcję rywalizacji o dostęp do tabel systemowych. 41
Lokalnie zarządzane ekstenty są automatycznie scalane podczas ich zwalniania, eliminując tym samym potrzebę wykonywania ręcznych scaleń lub okresowych automatycznych przy pomocy procesu tła SMON. Rozmiary ekstentów w lokalnie zarządzanych przestrzeniach tabel mogą być obliczane automatycznie przez system. Metodą alternatywną jest określenie zuniformizowanego rozmiaru wszystkich ekstentów w danej przestrzeni tabel. Zmiany w mapach bitowych ekstentów nie generują informacji wycofania, ponieważ nie powodują zapisów do tabel słownika danych ( poza szczególnymi przypadkami takimi jak kwoty na przestrzeniach tabel ). Tworzenie przestrzeni tabel Polecenie CREATE TABLESPACE Przestrzenie tabel są tworzone przy pomocy polecenia CREATE TABLESPACE : CREATE TABLESPACE tablespace [DATAFILE clause] [MINIMUM EXTENT integer[k M]] [BLOCKSIZE integer [K]] [LOGGING NOLOGGING] [DEFAULT storage_clause ] [ONLINE OFFLINE] [PERMANENT TEMPORARY] gdzie: tablespace jest nazwą tworzonej przestrzeni tabel DATAFILE określa pliki danych wchodzące w skład tworzonej przestrzeni tabel 42
MINIMUM EXTENT - zapewnia, że każdy ekstent tworzony w danej przestrzeni tabel będzie miał rozmiar będący całkowitą wielokrotnością wartości danej klauzuli LOGGING określa, że domyślnie każda operacja na każdej tabeli lub indeksie umieszczonych w danej przestrzeni tabel będzie zapisywana do dziennika powtórzeń. Wartość LOGGING jest domyślna. NOLOGGING określa że domyślnie niektóre operacje DML wykonywane na tabelach i indeksach w danej przestrzeni tabel będą pomijały dziennik powtórzeń. Klauzula ta jest związana tylko z niektórymi poleceniami DML, na przykład z załadunkiem danych ścieżką bezpośrednią. DEFAULT określa domyślne parametry alokacji przestrzeni dla segmentów tworzonych w danej przestrzeni tabel OFFLINE oznacza, że przestrzeń tabel po utworzeniu jest wyłączona PERMANENT oznacza, że dana przestrzeń tabel może zawierać trwałe segmenty TEMPORARY oznacza, że dana przestrzeń tabel może zawierać tylko segmenty tymczasowe, na przykład segmenty wykorzystywane w operacji ORDER BY. Tymczasowe przestrzenie tabel Przestrzenią dyskową wykorzystywaną przez operacje sortowania można zarządzać znacznie efektywniej poprzez desygnowanie do operacji sortowania tymczasowych przestrzeni tabel. W przestrzeniach takich nie można utworzyć żadnych trwałych segmentów. Jedynym typem segmentu, jaki może być utworzony w takiej przestrzeni tabel jest segment tymczasowy wykorzystywany właśnie do operacji sortowania. Segmenty tymczasowe są wykorzystywane przez operacje sortowania wtedy, gdy ilość danych podlegających sortowaniu jest tak duża, że nie mogą być one wszystkie jednocześnie utrzymywane w pamięci operacyjnej (PGA). Tymczasowe przestrzenie 43
tabel umożliwiają zwiększenie efektywności wykorzystywania segmentów tymczasowych. W przestrzeni tymczasowej tworzony jest segment tymczasowy podczas pierwszego sortowania od ostatniego uruchomienia instancji. Segment ten później może się rozszerzać alokując dodatkowe ekstenty dopóty dopóki jego rozmiar nie będzie większy bądź równy rozmiarowi wszystkich jednocześnie sortowanych w danej przestrzeni danych. Tymczasowe przestrzenie tabel mogą być układane w grupy. Zmiana rozmiaru przestrzeni danych Rozmiar przestrzeni tabel można zwiększyć na dwa sposoby: Zmienić rozmiar plików danych wchodzących w skład danej przestrzeni lub zezwolić na ich automatyczny rozrost. Dodać do danej przestrzeni tabel nowy plik danych. 44
Metody przenoszenia plików danych Aby zmienić lokalizację lub nazwę pliku danych należy zastosować następującą procedurę: Przełącz przestrzeń tabel do trybu "OFFLINE" lub przełącz bazę danych do trybu "MOUNT" (wyaga wyłączenia i ponownego uruchomienia bazy danych) Przy pomocy poleceń systemu operacyjnego zmień nazwę lub lokalizację pliku. Wykonaj polecenie ALTER DATABASE RENAME FILE lub ALTER TABLESPACE RENAME DATAFILE. Włącz przestrzeń tabel lub przestaw bazę danych do trybu "OPEN". Jeśli to konieczne, to stary plik danych usuń z poziomu systemu operacyjnego. 45