Wykład 14

Realizacja SZBD w Oracle

 

Po przedstawieniu ogólnej organizacji systemów zarządzania bazami danych przyszedł czas na poznanie jak realizacja zadań SZBD wygląda w przypadku systemów konkretnych producentów baz danych jak Oracle i Microsoft. Informacje te są potrzebne do administrowania konkretnymi systemami zarządzania bazami danych.

Wybór firm Oracle i Microsoft nie jest przypadkowy. Oracle jest największym producentem baz danych na świecie z 48.6% udziałów na rynku baz danych, Microsoft jest trzeci z 15% udziałem, ale za to Microsoft najszybciej się rozwija się ze wszystkich producentów baz danych (16.6% rocznie). (Dane pochodzą z raportu firmy Gartner:  http://www.gartner.com/press_releases/asset_152619_11.html)

Rozpoczynamy od prezentacji systemu Oracle, o którego niektórych szczegółowych rozwiązaniach, jak indeksy, była już mowa przy omawianiu ogólnych zagadnień.

 


14.1 Serwer bazy danych Oracle

Serwer bazy danych Oracle obejmuje szereg plików, procesów i struktur pamięci, umożliwiających przede wszystkim trwałe przechowywanie danych i wykonywanie instrukcji SQL. Oprócz tego niektóre ze składowych służą do poprawienia efektywności korzystania z bazy danych, do zapewnienia odtwarzalności bazy danych w przypadku awarii oprogramowania lub sprzętu, do wykonywania innych zadań potrzebnych przy eksploatacji bazy danych.

Ogólnie rzecz biorąc, serwer bazy danych Oracle składa się z dwóch części:

  1. bazy danych złożonej z fizycznych plików do przechowywania danych,
  2. instancji złożonej ze struktur pamięci i procesów systemu umożliwiających dostęp do danych przechowywanych  w fizycznych plikach.

 


14.2 Baza danych

Baza danych Oracle składa się z plików systemu operacyjnego, nazywanych plikami bazodanowymi (ang. database files), które są miejscem przechowywania danych w bazie danych. Zwykle mamy do czynienia z sytuacją, w której tylko jedna instancja Oracle ma dostęp do bazy danych. Tylko w specjalnej konfiguracji klastrowej  (o nazwie Real Application Cluster) wiele instancji ma dostęp do pojedynczej bazy danych.

Struktury fizycznego przechowywania danych są dwóch rodzajów. Pierwszy rodzaj jest pod bezpośrednią kontrolą serwera bazy danych - będąc częścią bazy danych. Są to:

  • pliki danych (ang. data files),

  • pliki kontrolne (ang. control files),

  • pliki dziennika powtórzeń (ang. redo log files).

Pliki drugiego rodzaju znajdują się poza bazą danych. Są to:

  • plik z parametrami instancji (ang. parameter file),

  • plik z hasłami (ang. password file),

  • pliki zarchiwizowanego dziennika powtórzeń (ang. archived redo log files).

Oto krótkie ich omówienie.

Pliki danych - zawierają dane przechowywane w bazie danych.

Pliki dziennika powtórzeń - rejestrują operacje wykonywane na danych. Ze względu na cykliczny sposób ich użycia muszą być co najmniej dwa pliki dziennika powtórzeń. Gdy awaria uniemożliwi zapisanie zmian danych, które nastąpiły w buforach bazy danych, do plików danych, zmiany te można odtworzyć z plików dziennika powtórzeń. Stosuje się multipleksowanie plików dzienników powtórzeń - utrzymywanie kilku kopii plików dziennika powtórzeń (najlepiej na różnych dyskach) - nazywanych grupą dziennika powtórzeń.

Plik kontrolny - zawiera podstawowe informacje o fizycznej strukturze bazy danych takie jak nazwa bazy danych, lokalizacje plików danych i plików dziennika powtórzeń. Ze względu na ochronę danych jest on zwykle przechowywany w kilku kopiach na różnych nośnikach danych.

Plik z parametrami - zawiera ustawienia wartości podstawowych parametrów inicjalizacyjnych, z którymi zostaje uruchomiona instancja Oracle. Na przykład, plik z parametrami zawiera parametry określające rozmiary struktur pamięci używanych przez instancję.

Plik z hasłami - weryfikuje użytkowników uprawnionych do uruchamiania i zamykania instancji.

Pliki zarchiwizowanego dziennika powtórzeń - są skumulowanymi kopiami plików dziennika powtórzeń koniecznymi do odtworzenia bazy danych w przypadku awarii mediów (dysków).

Oprócz wyżej wymienionych rodzajów plików są jeszcze dwa rodzaje plików, w których system przekazuje administratorowi bazy danych informacje o działaniu serwera bazy danych w tym  ostrzeżenia oraz informacje o zaistniałych sytuacjach wyjątkowych. Są to:

Pliki ostrzeżeń (ang. alert files) - dotyczące działania całej instancji.

Pliki śladu (ang. trace files) - dotyczące działania poszczególnych procesów serwera bazy danych.

Łączenie się z bazą danych

Program kliencki komunikuje zlecenie użytkownika komputerowi serwera bazy danych używając sterowników OracleNet. Proces nasłuchujący OracleNet wykrywa zlecenie i zaraz po zweryfikowaniu nazwy użytkownika i jego hasła uruchamia proces serwera działający w imieniu procesu użytkownika.

 


14.3 Struktury danych w pamięci instancji bazy danych

Instancja Oracle, jak już wspomnieliśmy powyżej, jest kombinacją procesów systemu i struktur pamięci. Przy każdym uruchomieniu instancji, następuje alokacja w pamięci RAM struktury danych nazywanej Globalnym Obszarem Systemu, w skrócie SGA (ang. System Global Area) i jednocześnie zostają uruchomione stałe procesy systemu. Rysunek 14.1 przedstawia podstawowe struktury danych w pamięci wewnętrznej. Ich omówieniem zajmiemy się za chwilę.

Procesy systemu wykonują funkcje na rzecz procesów użytkowników. Realizują funkcje, które inaczej wymagałaby oddzielnych programów Oracle działających osobno dla każdego użytkownika. Procesy systemu wykonują operacje Wejścia/Wyjścia i monitorują inne procesy Oracle zwiększając stopień równoległości operacji na serwerze bazy danych w celu uzyskania lepszej wydajności i niezawodności.

Rys. 14.1 Struktury pamięci wewnętrznej Oracle

Globalny obszar systemu SGA

Globalny obszar systemu SGA jest używany do przechowywania w pamięci operacyjnej informacji z bazy danych, które są współdzielone przez procesy instancji.

SGA składa się z następujących części:

  1. Obszaru współdzielonego (ang. Shared Pool),
  2. Obszaru buforów bazy danych czyli pamięci podręcznej bloków bazodanowych (ang. Database Buffer Cache),
  3. Bufora dziennika powtórzeń (ang. Redo Log Buffer Cache),
  4. Dużego obszaru (ang. Large Pool),
  5. Obszaru Javy (ang. Java Pool).

SGA ma charakter dynamiczny - są możliwe zmiany konfiguracji SGA bez zamykania i otwierania  instancji. Na przykład, można w ten sposób zmienić rozmiar obszaru buforów bazy danych. Rozmiar tego obszaru może więc być na początku dowolnie określony, a następnie rozszerzać bądź kurczyć się w zależności od zapotrzebowania, w granicach maksimum określonego przez parametr inicjalizacyjny SGA_MAX_SIZE.

Ustalanie rozmiaru SGA

Początkowy, po uruchomieniu instancji, rozmiar SGA jest zdeterminowany kilkoma parametrami inicjalizacyjnymi, w tym:

  • DB_CACHE_SIZE - domyślny rozmiar pamięci podręcznej bloków bazodanowych,
  • LOG_BUFFER -  liczba bajtów alokowanych dla bufora dziennika powtórzeń,
  • SHARED_POOL_SIZE - liczba bajtów alokowanych dla obszaru współdzielonego,
  • LARGE_POOL_SIZE - rozmiar (pomocniczego) dużego obszaru, domyślnie 0.

Obszar współdzielony

Obszar współdzielony zawiera bufory biblioteczne, bufory słownika danych i struktury kontrolne. Bufory biblioteczne zawierają teksty instrukcji SQL i PL/SQL, ich rozbiór gramatyczny (sparsowany kod) i plan ich wykonania. Bufory słownika danych zawierają definicje obiektów bazy danych w tym tabel i kolumn jak również informacje o uprawnieniach użytkowników.

Rozmiar obszaru współdzielonego jest definiowany za pomocą parametru SHARED_POOL_SIZE i można go dynamicznie zmieniać używając instrukcji ALTER SYSTEM z klauzulą SET. Na przykład,

ALTER SYSTEM SET
SHARED_POOL_SIZE = 64M;
przy czym całkowity rozmiar SGA nie może przekroczyć wartości parametru inicjalizacyjnego  SGA_MAX_SIZE.

Bufory biblioteczne (ang. Library Cache)

Bufory biblioteczne przechowują informacje o ostatnio wykonywanych instrukcjach SQL i PL/SQL umożliwiając współdzielenie kodu wynikowego wielokrotnie używanych instrukcji.

Rozmiar buforów bibliotecznych jest zdeterminowany rozmiarem obszaru współdzielonego. Pamięć jest alokowana wtedy gdy dochodzi do przygotowania  do wykonania instrukcji SQL lub PL/SQL. Gdy rozmiar obszaru współdzielonego jest zbyt mały, instrukcje są nieustannie od nowa ładowane do buforów bibliotecznych, co powoduje spadek efektywności działania. Bufory biblioteczne są obsługiwane przy użyciu algorytmu zastępowania LRU ("najdawniej używany - najpierw") tzn. gdy zapełnią się używane bufory biblioteczne, pozycje opisujące plan najdawniej wykonywanej instrukcji są usuwane z buforów robiąc miejsce dla pozycji nowych instrukcji. Nawet jeśli plany wykonania instrukcji pozostaną w buforach, ale nie są używane przez dłuższy okres czasu, ulegają przeterminowaniu i przy kolejnym użyciu wymagają powtórnego przygotowania do wykonania.

Bufory biblioteczne składają się z kilku części. Oto one:

Bufory słownika danych (ang. Data Dictionary Cache)

Bufory słownika danych zawierają definicje obiektów bazy danych używanych ostatnio w tym informacje o plikach bazy danych, tabelach, indeksach, kolumnach, użytkownikach, uprawnieniach. W czasie fazy rozbioru gramatycznego (parsowania) instrukcji SQL, proces serwera wyszukuje w słowniku danych informacje dotyczące obiektów o podanych nazwach w tym także dotyczące walidacji dostępu. Zapisanie informacji słownika danych w pamięci polepsza czas odpowiedzi na zapytania. Rozmiar buforów słownika danych jest zdeterminowany rozmiarem obszaru współdzielonego.

Przechowywanie informacji słownika danych w pamięci poprawia czas odpowiedzi. Informacje o bazie danych (takie jak dane o koncie i uprawnieniach użytkownika, nazwy plików z danymi, nazwy segmentów,  opisy tabel i uprawnienia użytkowników) są przechowywane w tabelach słownika danych. Gdy te informacje są potrzebne do wykonania instrukcji SQL lub PL/SQL, są one odczytywane z tabel słownika danych a następne zapisywane i przechowywane w buforach słownika danych.

Całkowity rozmiar buforów słownika danych zależy od rozmiaru obszaru współdzielonego i jest zarządzany wewnętrznie przez bazę danych. Jeśli rozmiar buforów słownika danych jest za mały, wówczas przy wykonywaniu zapytania użytkownika trzeba wielokrotnie wykonywać zapytania do tabel słownika danych. Zapytania te noszą nazwę zapytań rekurencyjnych i ich wykonywanie jest wolniejsze niż sięganie bezpośrednio do buforów słownika danych.

Bufory bazodanowe (ang. Database Buffer Cache)

Bufory bazodanowe przechowują ostatnio używane bloki danych, które wcześniej zostały sprowadzone z plików danych.

Przy wykonywaniu zapytania, proces serwera Oracle najpierw sprawdza czy potrzebny blok danych znajduje się w jednym z buforów bazodanowych. Jeśli potrzebnego bloku z danymi nie ma w buforach, proces serwera odczytuje blok z pliku danych i umieszcza jego kopię w buforze bazodanowym. Następne żądania odczytania tego samego bloku, mogą być teraz zrealizowane bez sięgania do dysku (tzn. bez fizycznego odczytu). Używany jest algorytm LRU zastępowania bloków, polegający na zastępowaniu bloków, które najdłużej były nie używane, przez nowe bloki sprowadzane z dysku.

Wielokrotne rozmiary bloków

Parametr DB_BLOCK_SIZE określa podstawowy rozmiar bloku z danymi.

Baza danych może mieć określone aż do czterech niestandardowych rozmiarów bloku. Niestandardowe rozmiary bloków są potęgami dwójki między 2KB a 32KB.

Pamięć podręczna bloków bazodanowych składa się z trzech części:

  1. domyślnego obszaru, określonego przez parametr DB_CACHE_SIZE, który zawsze istnieje i nie może być ustawiony na zero;
  2. obszaru bloków preferowanych do przechowywania w pamięci, z powodu dużego prawdopodobieństwa ich powtórnego użycia, określony przez parametr DB_KEEP_CACHE_SIZE;
  3. obszaru bloków preferowanych do recyclingu z powodu małego prawdopodobieństwa ich powtórnego użycia, określony przez parametr DB_RECYCLE_CACHE_SIZE.

Rozmiar pamięci podręcznej bloków bazodanowych można zmieniać za pomocą instrukcji ALTER SYSTEM. Na przykład dla DB_CACHE_SIZE:

ALTER SYSTEM SET DB_CACHE_SIZE=96M;

Parametr DB_CACHE_ADVICE (wartości: OFF, READY, ON) służy do zbierania statystyk, które mogą pomóc administratorowi bazy danych w ustaleniu optymalnego rozmiaru pamięci podręcznej bloków bazodanowych. Zbierane statystyki są dostępne w dynamicznej perspektywie słownika danych: V$DB_CACHE_ADVICE.

Typy  buforów (bloków)

Algorytm zarządzania buforami korzysta z następującej klasyfikacji buforów:

1. do zapisu (ang. dirty) - zawartość bufora została zmieniona, ale jeszcze nie została przepisania na dysk;

2. wolny - bufor albo nie zawiera danych albo jego aktualna zawartość może zostać nadpisana przez zawartość nowego bloku;

3. zajęty (ang. pinned) - bufor albo jest aktualnie używany albo explicite wskazano, że może być wkrótce użyty np. przez umieszczenie bloku w buforze preferowanych bloków (KEEP CACHE).

Bufory znajdują się na dwóch rozłącznych listach:

  1. liście buforów do zapisu (ang. dirty buffer list) - na liście tej znajdują się bufory, których zawartość została zmodyfikowana a następnie transakcja która to zrobiła została zatwierdzona; bloki znajdujące się w tych buforach powinny zostać przepisane na dysk a same bufory zwolnione do zapisu nowych bloków;
  2. liście roboczej - na liście tej znajdują się bufory wolne, zajęte albo do zapisu (zanim zostaną umieszczone na liście buforów do zapisu). Bufory, które najbardziej niedawno były używane znajdują się na początku listy roboczej czyli na jej końcu MRU. Bufory, które najdawniej były używane, znajdują się na końcu listy roboczej czyli na jej końcu LRU.

Kiedy proces Oracle używa bufora, bufor ten zostaje przeniesiony na początek LRU listy roboczej - dzięki temu najczęściej używane dane są na ogół dostępne w buforach pamięci RAM. Z jednym wyjątkiem - kiedy odbywa się przejście całej tabeli (tzw. ang. full table scan) - wtedy używane bloki są zapisywane na koniec LRU listy roboczej.

Gdy proces Oracle potrzebuje dostępu do danych, najpierw szuka ich w pamięci podręcznej bloków - jeśli znajdzie, mamy do czynienia ze zjawiskiem nazywanym trafieniem (ang. cache hit). Jeśli nie znajdzie, ze zjawiskiem nazywanym brakiem (ang. cache miss) - dane muszą zostać sprowadzone z dysku do bufora.

Proces serwera przeszukuje listę roboczą od jej końca LRU, dopóki nie znajdzie wolnego bufora albo dopóki nie przeszuka określonej progowej liczby buforów. Przy okazji wszystkie napotkane bufory do zapisu przenosi na listę buforów do zapisu. Jeśli w ten sposób nie znajdzie wolnego bufora, proces serwera przepisuje pewną liczbę bloków z listy bloków do zapisu na dysk - zwalniając wolne bufory do użycia przez procesy serwera.

Bufor dziennika powtórzeń (ang. Redo Log Buffer Cache)

Bufor dziennika powtórzeń rejestruje wszystkie zmiany dokonywane w ramach jednej instancji - przede wszystkim zmiany zawartości bloków bazodanowych (zmiany te zachodzą w buforach bazodanowych a po pewnym czasie zostają przepisane na dysk). Głównym celem tego procesu, w którym bierze udział bufor dziennika powtórzeń, jest umożliwienie odtworzenia instancji i/lub bazy danych gdy zajdzie awaria. Rejestrowane zmiany mają postać rekordów nazywanych pozycjami powtórzeń (ang. redo entries). Mają one umożliwić powtórne wykonanie tej zmiany na bazie danych - gdy oryginalny zapis zostanie utracony.

Bufor dziennika powtórzeń jest używany sekwencyjnie i cyklicznie.

Rozmiar bufora dziennika powtórzeń jest określony przez parametr LOG_BUFFER.

Duży obszar (ang. Large Pool)

Jest opcjonalnym obszarem pamięci SGA używanym w środowisku współdzielonych serwerów. Jego celem jest zmniejszenie obciążenia nakładanego na obszar współdzielony.

Jest używany między innymi przy wykonywaniu operacji We/Wy, przy operacjach backupu i odtwarzania.

Inaczej niż w przypadku obszaru współdzielonego, duży obszar nie używa listy funkcjonującej na zasadzie LRU.

Jego rozmiar określa parametr LARGE_POOL_SIZE. Na przykład,

ALTER SYSTEM SET LARGE_POOL_SIZRE=64M;

Obszar Javy

Obszar Javy służy do przetwarzania poleceń języka Java. Jest wymagany, jeśli na serwerze bazy danych zostanie zainstalowana maszyna wirtualna Javy. Jego rozmiar określa parametr JAVA_POOL_SIZE - z domyślną wartością 24MB.

Alokacja pamięci SGA

Pamięć SGA jest alokowana i używana przez komponenty SGA za pomocą tzw. granul (ziaren). Granula jest jednostką spójnej pamięci wirtualnej. Rozmiar pojedynczej granuli zależy od parametru SGA_MAX_SIZE i wynosi:

Minimalną konfigurację SGA stanowią trzy granule:

Do sprawdzenia wartości podstawowych parametrów SGA służy instrukcja:

SHOW SGA;
Total System Global Area 36437964 bytes
Fixed Size 6543794 bytes
Variable Size 19521536 bytes
Database Buffers 16777216 bytes
Redo Buffers 73728 bytes

Globalny Obszar Programowy

Globalny obszar programowy (PGA, ang. Program Global Area) zawiera dane i informacje kontrolne potrzebne dla pojedynczego procesu systemu Oracle. Pamięć PGA jest alokowana przy tworzeniu procesu oraz dealokowana przy zamykaniu procesu. Obszar PGA nie jest współdzielony między procesami. Zawiera:

  1. obszar do sortowania - określony przez parametry SORT_AREA_SIZE i SORT_AREA_RETAINED_SIZE - rozmiar obszaru do sortowania może rosnąć lub zmniejszać się w zależności od potrzeb;
  2. informację o sesji;
  3. stan kursorów;
  4. obszar stosów.
     

14.4 Procesy Oracle

W systemie Oracle są dwa typy procesów: procesy użytkowników i procesy systemu. W systemie klient/serwer procesy użytkowników i systemu działają zwykle na oddzielnych komputerach.

Procesy systemu są wywoływane przez inne procesy w celu wykonania funkcji na rzecz wywołujących je procesów. Są dwóch rodzajów: procesy serwera i procesy tła.

Procesy serwera są tworzone przez system do obsługi zleceń od zgłaszających się przez sieć procesów użytkowników. Na przykład, jeśli użytkownik zgłasza zapotrzebowanie na dane, których nie ma w danej chwili w buforach bazy danych w SGA, realizujący to żądanie proces serwera odczytuje właściwe bloki danych z dysku i zapisuje je w buforach SGA.

Zadania procesu serwera

Proces serwera spełnia następujące zadania:

Zadanie Opis

Rozkład gramatyczny (parse) i przygotowanie planu wykonania instrukcji SQL

Sprawdzanie poprawności składni, uprawnień, identyfikacja obiektów, optymalizacja, wygenerowanie planu wykonania instrukcji SQL. Podczas rozkładu używane są obszary współdzielone SQL, stąd też procesy mogą używać wspólnych planów wykonania instrukcji SQL.

Wykonanie (execute)

Realizacja planu wykonania instrukcji SQL w tym sprowadzanie bloków danych z dysku.

Przekazanie wyników (fetch)

Przekazanie wyników instrukcji SQL.

Tabela 14.1 Zadania procesu serwera.
 

Procesy tła (ang. background processes) są to stałe procesy tworzone przez Oracle dla każdej instancji przeznaczone do wykonywania rutynowych zadań systemu zarządzania bazą danych. Procesy tła wykonują asynchronicznie operacje wejścia/wyjścia i monitorują inne procesy Oracle dostarczając zwiększonego poziomu równoległego wykonywania operacji i w ten sposób zwiększając wydajność działania systemu.

Rysunek 14.2 przedstawia architekturę procesów serwera Oracle. Poniżej omówimy podstawowe procesy tła.
 

Rys. 14.2 Architektura procesów Oracle
 

Pisarz bazy danych DBWn (ang. Database Writer)

Procesy serwera dokonują zmian w blokach danych i blokach segmentów wycofań zapisanych w buforach bazy danych. Pisarz bazy danych (DBWn) zapisuje zmodyfikowane (ang. dirty) bloki danych z buforów bazodanowych do plików danych. Zapewnia, aby w buforach bazy danych była dostępna dostateczna liczba wolnych buforów do zapisu bloków z danymi sprowadzanych z plików danych. W ten sposób zwiększa się wydajność bazy danych, ponieważ procesy serwera dokonują zmian tylko w buforach. Ze względu na sposób wykonywania zapisów do dziennika powtórzeń, DBWn nie musi zapisywać bloków w chwili, gdy transakcja kończy się zatwierdzeniem, co pozwala minimalizować liczbę zapisów na dysk. DBWn zapisuje w zasadzie bloki na dysk tylko wtedy, kiedy inne dane muszą zostać sprowadzone do SGA i za mało jest wolnych buforów, aby je pomieścić.

DBWn odracza zapis zmodyfikowanych bloków na dysk dopóki nie zajdzie jedno z następujących zdarzeń:

  1. punkt kontrolny (omawiany poniżej),
  2. liczba bloków do zapisu (dirty) osiągnie pewną wartość progową,
  3. proces przejrzy określoną liczbę bloków na liście roboczej i nie znajdzie wolnego,
  4. przy zmianie trybu przestrzeni tabel (omawianej poniżej) w tryb tylko do odczytu lub w tryb offline,
  5. przy usuwaniu lub opróżnianiu tabeli za pomocą instrukcji TRUNCATE,
  6. przed wykonaniem instrukcji ALTER TABLESPACE nazwa_przestrzeni_tabel BEGIN BACKUP.

Pisarz dziennika LGWR (ang. Log Writer)

Pisarz dziennika dokonuje sekwencyjnych zapisów zawartości bufora dziennika powtórzeń do plików dziennika powtórzeń w następujących sytuacjach:

  1. przy zatwierdzaniu transakcji,
  2. gdy bufor dziennika powtórzeń jest w 1/3 pełny,
  3. gdy jest więcej niż 1MB rekordów zmian w buforze dziennika powtórzeń,
  4. zanim DBWn zapisze zmodyfikowane bloki w buforach bazy danych do plików z danymi,
  5. co trzy sekundy.

W chwili gdy transakcja zostaje zatwierdzona, LGWR zapisuje zawartość bufora dziennika powtórzeń do pliku dziennika powtórzeń razem z informacją COMMIT i kolejnym numerem SCN tej transakcji (nazywanym systemowym numerem zmiany). Dopiero po przesłaniu zawartości bufora dziennika powtórzeń do plików dziennika powtórzeń uważa się transakcję za zatwierdzoną z możliwością odtworzenia stanu bazy danych w przypadku awarii instancji lub dysku z danymi. Dopiero w tym momencie LGWR potwierdza wykonanie instrukcji COMMIT.

Dziennik powtórzeń jest tylko jeden, więc może się zdarzyć, że nie zatwierdzone jeszcze zmiany wprowadzone przez inne transakcje także zostaną zapisane do pliku dziennika powtórzeń na dysku. W przypadku konieczności odtworzenia stanu bazy danych zmiany te trzeba będzie wycofać korzystając z zapisów w dzienniku powtórzeń dotyczących segmentów wycofań. Działania procesów tła DBWn i LGWR są niezależne od siebie.

Realizacja COMMIT

1. Proces serwera zapisuje informację o zatwierdzeniu w buforze dziennika powtórzeń.

2. LGWR przepisuje aktualną zawartość bufora dziennika powtórzeń do plików dziennika powtórzeń na dysku.

3. Proces serwera informuje proces użytkownika o wykonaniu COMMIT i zakończeniu transakcji.

4. Proces serwera aktualizuje struktury SGA w tym stan bloków używanych przez zatwierdzoną transakcję, usuwa zakończoną transakcję z tablicy aktualnie realizowanych transakcji.

Monitor systemu SMON (ang. System Monitor)

W przypadku awarii instancji Oracle, wszystkie informacje w SGA, które nie zostały zapisane na dysku są tracone. W szczególności awaria systemu operacyjnego powoduje awarię instancji.

Po stracie instancji, proces SMON działający w tle automatycznie dokonuje odtworzenia instancji gdy baza danych zostanie z powrotem otwarta. Odtworzenie instancji przebiega w następujących trzech krokach:

1. Odtwarzanie do przodu (ang. rolling forward) w celu odtworzenia danych, które nie zostały zapisane w plikach danych ale które zostały zapisane w dzienniku powtórzeń. Dane te nie zostały zapisane na dysku z powodu utraty zawartości SGA w chwili awarii instancji. Podczas tego procesu, SMON odczytuje pliki dziennika powtórzeń i stosuje zmiany zarejestrowane w pozycjach dziennika powtórzeń do bloków z danymi. Ponieważ wszystkie zatwierdzone transakcje zostały zapisane w dzienniku powtórzeń, proces ten w pełni odtwarza zmiany wprowadzone przez te transakcje.

2. Otwarcie bazy danych tak, że użytkownicy mogą się zalogować. Wszystkie dane, które nie zostały zablokowane przez nie zatwierdzone transakcje są natychmiast dostępne.

3. Wycofanie nie zatwierdzonych transakcji. Są one wycofywane przez SMON lub przez indywidualne procesy serwera w chwili gdy uzyskują one dostęp do zablokowanych danych.

Monitor procesów PMON (ang. Process Monitor)

Monitor procesów działający w tle oczyszcza system po awarii procesu serwera poprzez:

  1. wycofanie bieżącej transakcji użytkownika,
  2. zwolnienie wszystkich blokad założonych przez proces serwera, który realizował zlecenie użytkownika,
  3. zwolnienie wszystkich innych zasobów zarezerwowanych przez transakcję użytkownika.

Zdarzenie punktu kontrolnego (ang. checkpoint event)

Jest to zdarzenie polegające na tym, że Pisarz bazy danych zapisuje wszystkie zmodyfikowane bloki w buforach bazodanowych w SGA, zarówno ze zmianami zatwierdzonymi jak i nie, do plików danych. Pomaga to zredukować czas wymagany na odtworzenie instancji w przypadku jej awarii.

Proces punktu kontrolnego CKPT (ang. Checkpoint Process)

Sam proces punktu kontrolnego CKPT zapisuje numer punktu kontrolnego do wszystkich nagłówków plików z danymi.

Zapisuje także do pliku kontrolnego numer kolejny punktu kontrolnego, aktualny numer kolejny dziennika powtórzeń (LSN), nazwy zarchiwizowanych dzienników powtórzeń i systemowy numer zmian (SCN). CKPT nie zapisuje bloków z danymi do plików z danymi - robi to sam proces DBWn.

Archiwizator ARCn (ang. Archiver)

Archiwizator ARCn działając w tle automatycznie archiwizuje pozycje dziennika powtórzeń - chroniąc je przed nadpisaniem. W ten sposób zachowuje wszystkie zmiany dokonane na bazie danych umożliwiając odtworzenie bazy danych w przypadku awarii dysków z danymi. Działa tylko przy włączonym trybie ARCHIVELOG.

ARCn jest istoty do odtworzenia bazy danych po stracie dysku. Po zapełnieniu jednego pliku dziennika powtórzeń, serwer Oracle rozpoczyna zapis do następnego pliku dziennika powtórzeń nadpisując co było tam wcześniej. Proces przejścia z jednego pliku dziennika powtórzeń do drugiego nosi nazwę przełączenia dziennika (ang. log switch). Proces ARCn inicjuje archiwizację zapełnionej grupy dziennika powtórzeń przy każdym przełączeniu dziennika.

Tryb NOARCHIVELOG

Pliki dziennika powtórzeń są nadpisywane za każdym razem gdy zachodzi przełączenie dziennika. LGWR nie nadpisze grupy dziennika powtórzeń dopóki nie zakończy się zdarzenie punktu kontrolnego dotyczące danych opisanych pozycjami powtórzeń w danej grupie. Zapewnione zostaje to, że zatwierdzone dane mogą zostać odzyskane w przypadku awarii instancji. Przy awarii instancji np. przy awarii systemu operacyjnego nie ma straty informacji na dysku, traci się tylko informacje zapisane w obszarze SGA.

Dyspozytor Dnnn (ang. Dispatcher)

Procesy dyspozytory są częścią architektury współdzielonych procesów serwerów. Minimalizują one zapotrzebowanie na zasoby przez obsługę wielokrotnych połączeń z bazą danych przy użyciu ograniczonej liczby procesów serwera.

Gdy użytkownik zgłasza żądanie, dyspozytor umieszcza zgłoszenie w kolejce zleceń. Po wykonaniu zlecenia przez proces serwera, dyspozytor przekazuje użytkownikowi wyniki pobierając je z kolejki odpowiedzi.

Współdzielony proces serwera Snnn (ang. Shared Server)

Współdzielony proces serwera obsługuje zlecenia napływające od wielu procesów użytkowników.

Przy uruchomieniu instancji, Oracle uruchamia stałą liczbę procesów serwera, które pracują w trybie cyklicznym (ang. round-robin) aby obsłużyć zlecenia procesów użytkowników - umieszczone przez dyspozytorów w kolejce zleceń. Wyniki realizacji zlecenia są wkładane do kolejki odpowiedzi, z której pobiera je dyspozytor w celu przekazania procesowi użytkownika.

Odtwarzacz RECO (ang. Recoverer) - zajmuje się odtwarzaniem transakcji rozproszonych w przypadku awarii sieci lub systemu.

Blokada LCKn (ang. Lock) jest to proces obsługujący blokady między instancjami w środowisku serwera równoległego (ang. Oracle Parallel Server).

Procesy tła mogą być albo osobnymi procesami systemu operacyjnego, albo wątkami jednego procesu systemu operacyjnego (tak jest w systemie Windows).
 


14.5. Ilustracja jak działa serwer Oracle

W uproszczeniu serwer bazy danych Oracle działa w następujący sposób:

1. Instancja działa na jednym komputerze (serwerze bazy danych).

2. Aplikacja kliencka działa na drugim komputerze (stacji klienckiej) jako proces użytkownika. Aplikacja kliencka ustanawia połączenie z serwerem za pomocą programu sieciowego OracleNet.

3. Oprogramowanie sieciowe OracleNet działające po stronie serwera wykrywa żądanie przychodzące z aplikacji i tworzy dedykowany proces działający na serwerze w imieniu procesu użytkownika.

4. Użytkownik wykonuje instrukcję SQL i zatwierdza transakcję. Na przykład, użytkownik zmienia adres osoby w jednym z wierszy tabeli Pracownicy.

5. Proces serwera otrzymuje instrukcję i sprawdza, czy w którymś z obszarów współdzielonych SQL nie jest zapisana identyczna instrukcja SQL. Jeśli jest, proces serwera sprawdza uprawnienia użytkownika do żądanych danych i poprzednio używany obszar SQL zostaje jeszcze raz użyty do przetworzenia instrukcji; jeśli nie ma identycznej instrukcji, zadaniu zostaje przydzielony obszar pamięci w ramach obszaru współdzielonego SQL, w którym instrukcja SQL zostaje poddana rozbiorowi gramatycznemu i przetworzona.

6. Proces serwera znajduje wszystkie potrzebne wartości danych lokalizując je od razu w buforach bazodanowych w SGA albo sprowadzając je z plików z danymi na dysku.

7. Proces serwera modyfikuje dane w SGA. Proces DBWR zapisze zmodyfikowane bloki na stałe na dysk dopiero wtedy, kiedy będzie to konieczne. Ponieważ transakcja zostaje zatwierdzona, proces LGWR natychmiast zapisuje zmiany dokonane przez transakcję do pliku dziennika powtórzeń.

8. Gdy transakcja kończy się pomyślnie, proces serwera wysyła odpowiedni komunikat poprzez sieć do aplikacji. Gdy nie kończy się pomyślnie, przesyła odpowiedni komunikat o błędzie.

9. W czasie całej tej procedury, procesy tła działając "w tle", obserwują czy czasem nie zaszły warunki wymagające ich interwencji. Dodatkowo, serwer bazy danych zarządza transakcjami wszystkich użytkowników i rozwiązuje konflikty między transakcjami żądającymi tych samych danych.

Oprogramowanie sieciowe OracleNet stanowi mechanizm dostarczający interfejsu z protokołami komunikacyjnymi używanymi w sieciach. Serwer bazy danych Oracle komunikuje się ze stacjami klienckimi, jak i z innymi serwerami baz danych Oracle za pomocą tego oprogramowania.
 


14.6 Obowiązki administratora bazy danych

Ponieważ systemy baz danych Oracle są na ogół skomplikowane, obsługujące wielu użytkowników, niezbędne jest aby jedna osoba albo nawet cała grupa ludzi była odpowiedzialna za zarządzanie systemem bazy danych. Taką osobą jest administrator bazy danych nazywany w skrócie DBA.

Podstawowe obowiązki DBA

  1. Instalacja pierwszej i kolejnych wersji serwera Oracle i narzędzi aplikacyjnych.
  2. Utworzenie podstawowych struktur bazy danych i podstawowych obiektów.
  3. Planowanie przestrzeni zapisu tabel na dysku.
  4. Modyfikowanie struktury bazy danych.
  5. Zakładanie kont użytkowników i przyznawanie im uprawnień.
  6. Kontrolowanie i monitorowanie dostępu użytkowników do bazy danych.
  7. Archiwizacja i odtwarzanie bazy danych.
  8. Zapewnienie bezpieczeństwa systemu.
  9. Monitorowanie dostępności, wydajności i dostrajanie bazy danych.
     

14.7  Logiczne struktury przechowywania danych na dysku

Architektura bazy danych Oracle obejmuje strukturę logiczną i fizyczną, które łącznie tworzą bazę danych. Struktura fizyczna bazy danych obejmuje pliki kontrolne, pliki dziennika powtórzeń i pliki z danymi. Struktura logiczna bazy danych obejmuje przestrzenie tabel, segmenty, ekstenty i bloki danych.

Dane w bazie danych Oracle są podzielone na logiczne jednostki przechowywania danych na dysku nazywane przestrzeniami tabel (ang. tablespaces). Przestrzeń tabel to struktura pośrednia między strukturą logiczną (tabelami, indeksami) a fizyczną (plikami danych). Jednej przestrzeni tabel odpowiada z jednej strony jeden lub więcej obiektów w bazie danych, jak np. tabela, indeks, a z drugiej strony jeden lub więcej plików systemu operacyjnego. Baza danych Oracle zawiera co najmniej jedną przestrzeń tabel o nazwie SYSTEM, w której między innymi znajduje się słownik danych zawierający definicje obiektów bazy danych takich jak tabele, perspektywy, indeksy, procedury, pakiety, wyzwalacze. Oto podstawowe właściwości strukturalne przestrzeni tabel:

Rys. 14.3 Struktura bazy danych Oracle

Segment reprezentuje obszar dysku przeznaczony do zapisu jednego obiektu.

Typy segmentów:

  1. segmenty z danymi - przechowują dane tabeli lub klastra;
  2. segmenty indeksowe - przechowują dane indeksu;
  3. segmenty tymczasowe - pomocnicze obszary do zapisywania tymczasowych wyników sortowania i wykonywania instrukcji SQL;
  4. segmenty wycofań (ang. undo segments) - przechowują informacje umożliwiające wycofanie wprowadzonych zmian - pod warunkiem, że nie zostały one zatwierdzone. Znaczenie segmentu wycofań pokazuje rysunek 14.3.

 

Rys. 14.4 Zapisywanie poprzedniej wartości danych w segmencie wycofań w wyniku wykonania instrukcji DML.
 


14.8. Zarządzanie obiektami bazy danych

Zarządzanie przestrzeniami tabel

Grupowanie danych w przestrzeniach tabel

W każdej bazie danych jest systemowa przestrzeń tabel o nazwie SYSTEM zawierająca tabele słownika danych w tym kod źródłowy PL/SQL oraz segment wycofań o nazwie SYSTEM. Pozostałe dane powinny być zapisywane w niesystemowych przestrzeniach tabel. W niesystemowych przestrzeniach tabel znajdują się więc: dane użytkowników, indeksy, segmenty wycofań, segmenty tymczasowe.

Planowanie przestrzeni tabel powinno uwzględniać następujące zalecenia:

Metody zarządzania ekstentami

Są dwie metody zarządzania ekstentami w zależności od tego gdzie są przechowywane informacje o ekstentach (takie jak: czy jest on wolny czy przydzielony do segmentu, jego rozmiar). Mianowicie informacje o ekstentach są przechowywane albo:

  1. w samych plikach danych, albo
  2. w słowniku danych.

W Oracle pierwsza metoda jest domyślna i taka przestrzeń tabel nazywa się lokalnie zarządzana. Informacje o ekstentach w pliku danych są reprezentowane za pomocą mapy bitowej zapisywanej w tym samym pliku danych. Każdy bit odpowiada jednemu ekstentowi. Jego wartość wskazuje czy ekstent jest używany czy wolny. Taka reprezentacja jest bardziej efektywna i redukuje fragmentację używanego miejsca w pliku.

Natomiast druga metoda była stosowana w wersjach wcześniejszych serwera Oracle i tego rodzaju przestrzeń tabel nazywa się zarządzana słownikiem danych. Informacja o wszystkich wolnych ekstentach jest zapisywana w tabelach słownika danych. Zmiany alokacji są rejestrowane również w segmentach wycofań. Jest metodą bardziej elastyczną jeśli chodzi o optymalizację używanego miejsca na dysku.

Wybór jednej z tych dwóch metod ma miejsce przy tworzeniu przestrzeni tabel. Raz wybranego sposobu zarządzania ekstentami nie można już potem zmienić.

Metoda lokalnie zarządzanych przestrzeni tabel nie korzysta z tabel słownika danych - w związku z tym nie ma dodatkowego narzutu z tym związanego. Ponadto nie są generowane segmenty wycofań dotyczące alokacji ekstentów.

Składnia:

CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/userdata01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;

Dla lokalnie zarządzanych przestrzeni tabel mamy do dyspozycji dwie opcje:

  1. UNIFORM - określa, że ekstenty mają jednakowy rozmiar. Można albo określić rozmiar ekstentu w klauzuli SIZE albo skorzystać z domyślnej wartości rozmiaru 1MB.
  2. AUTOALLOCATE - (opcja domyślna) określa, że rozmiar ekstentów jest zarządzany przez system (nie podaje się wtedy klauzuli SIZE).

CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/data01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL
AUTOALLOCATE;

Metody zarządzania wolnym miejscem w blokach

Do tej pory wprowadzone struktury pozwalają śledzić, które ekstenty są aktualnie używane a które są w danej chwili wolne. Zachodzi potrzeba posiadania jeszcze informacji, do których bloków można wstawiać nowe wiersze. Są dwie metody zarządzania wolnym miejscem w blokach dla lokalnie zarządzanych przestrzeni tabel:

  1. MANUAL (opcja domyślna) - są używane listy wolnych bloków.
  2. AUTO - jest używana mapa bitowa wskazująca status bloku - czy jest dostępny dla operacji INSERT.

CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/data01.dbf' SIZE 500M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
SEGMENT SPACE MANAGEMENT AUTO;

Więcej informacji o zarządzaniu wolnym miejscem w blokach danych znajduje się w dalszej części tego wykładu.

Przestrzenie tabel zarządzane słownikiem danych

Każdy segment przechowywany w przestrzeni tabel może mieć osobną klauzulę STORAGE określającą charakterystykę użycia ekstentów. Uspójnianie ekstentów jest wykonywane przez DBA. Zarządzanie przestrzenią tabel za pomocą tej metody jest bardziej elastyczne ale mniej efektywne. Oto przykład definicji przestrzeni tabel zarządzanej słownikiem danych z ustaleniem domyślnej dla segmentów w tej przestrzeni tabel klauzuli STORAGE.

CREATE TABLESPACE userdata
DATAFILE '/u01/oradata/udata01.dbf' SIZE 500M
EXTENT MANAGEMENT DICTIONARY
DEFAULT STORAGE (INITIAL 2M NEXT 1M);

Dopasowanie charakterystyk użycia ekstentów

Ustawienia dotyczące alokacji ekstentów dla segmentów w przestrzeni tabel  - klauzula DEFAULT STORAGE - określa parametry przechowywania danych na dysku. Oto jej schemat:

DEFAULT STORAGE (
INITIAL l.całkowita
NEXT l.całkowita
MINEXTENTS l.całkowita
MAXEXTENTS l.całkowita
PCTINCREASE l.całkowita)

gdzie:

1. INITIAL to rozmiar w bajtach pierwszego alokowanego ekstentu (domyślnie 5 bloków). Znając ilość danych do wprowadzenia na samym początku możemy dobrać odpowiednią wielkość. Gdy planujemy migrację większej ilości danych ten parametr może być znacznie większy.

2. NEXT to rozmiar w bajtach następnego alokowanego ekstentu (domyślnie 5 bloków). Przez pewien okres korzystania z bazy danych, wprowadzamy nowe dane. Zwykle ta ilość jest nie większa od ilości danych wstawianych do bazy danych na samym początku.

3. PCTINCREASE to procent, o jaki wzrasta rozmiar kolejno alokowanego ekstentu po drugim (domyślnie 50%). W trakcie korzystania z bazy danych zwykle ilość wstawianych danych rośnie. Ten parametr można zmienić w trakcie działania bazy danych.

4. MINEXTENTS to całkowita liczba ekstentów alokowanych przy tworzeniu segmentu (domyślnie 1, dla segmentów wycofań 2).

5. MAXEXTENTS to maksymalna liczba ekstentów, jakie może przydzielić system Oracle dla obiektu.

Oto przykład:

STORAGE(INITIAL 100K NEXT 50K MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 5 );

System Oracle alokuje miejsce na dysku dla segmentu obiektu w następujący sposób:

1. MINEXTENTS=1, więc na początku jest tworzony segment złożony z dokładnie jednego ekstentu.

2. INITIAL=100K, więc rozmiar pierwszego ekstentu wynosi 100 kilobajtów.

3. NEXT=50K, więc gdy przepełni się pierwszy ekstent, następny alokowany ekstent będzie miał rozmiar 50 kilobajtów.

4. PCTINCREASE=5, więc każdy kolejno alokowany ekstent będzie miał rozmiar większy o 5%. Zakładając, że rozmiar bloku danych wynosi 2 kilobajty, trzeci alokowany ekstent będzie mieć rozmiar 52 kilobajty, co stanowi zaokrąglenie wartości 50kB powiększonej o 5%.

5. MAXEXTENTS=50, więc maksymalnie można alokować do segmentu 50 ekstentów.

Oracle alokuje odpowiedni segment z ekstentami, gdy obiekt jest tworzony. Gdy cała przydzielona pamięć zostanie zużyta, Oracle dynamicznie dodaje do segmentu obiektu nowe ekstenty (co zwiększa czas działania bo nowe ekstenty mogą być położone w innej części dysku).

Przestrzenie tabel wycofań

Są dwie opcje zarządzania segmentami wycofań:

  1. utworzenie explicite segmentów wycofań określając ich rozmiary i liczbę;
  2. opcja automatycznego zarządzania segmentami wycofań przy użyciu przestrzeni tabel wycofań.

Przestrzeń tabel dla segmentów wycofań - opcja automatycznego zarządzania segmentami wycofań

Są dwie metody tworzenia przestrzeni tabel wycofań. Pierwsza metoda polega na utworzeniu przestrzeni tabel wycofań przy tworzeniu bazy danych za pomocą instrukcji CREATE DATABASE. Wówczas instancja jest uruchamiania w trybie UNDO_MANAGEMENT = AUTO. Druga metoda polega na utworzeniu przestrzeni tabel wycofań w istniejącej bazie danych za pomocą instrukcji CREATE UNDO TABLESPACE.

CREATE UNDO TABLESPACE undo1
DATAFILE '/u01/oradata/undo101.dbf' SIZE 40M;

Przestrzeń tabel wycofań zawiera tylko segmenty wycofań - żadnych innych obiektów. Jej ekstenty są lokalnie zarządzane. Jedyną dopuszczalną klauzulą w CREATE UNDO TABLESPACE jest DATAFILE.

Ręczne zarządzanie segmentami wycofań

Przy ręcznym zarządzaniu segmentami wycofań wymagane jest ustawienie wartości parametru inicjalizacyjnego: UNDO_MANAGEMENT=MANUAL oraz użycie klauzuli UNIFORM SIZE.

CREATE TABLESPACE rbs_ts
DATAFILE 'rbs01.dbf' SIZE 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 100K;

Wtedy segment wycofań tworzymy za pomocą instrukcji:

CREATE ROLLBACK SEGMENT rbs_one
TABLESPACE rbs_ts;

Tymczasowe przestrzenie tabel

Tymczasowe przestrzenie tabel dostarczają pomocniczego miejsca na dysku do wykonywania instrukcji SQL w tym sortowania. Są dwa typy tymczasowych przestrzeni tabel: z lokalnym zarządzaniem ekstentami i zarządzaniem ekstentami za pomocą słownika danych. Oto przykład instrukcji tworzącej tymczasową przestrzeń tabel pierwszego typu.

CREATE TEMPORARY TABLESPACE sort
TEMPFILE '/DISK2/sort01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M;

Nie mogą one zawierać żadnych trwałych obiektów. Rekomendowane jest użycie lokalnego zarządzania ekstentami. Pliki specyfikowane w TEMPFILE nie są odtwarzalne. Nie można uczynić ich READ-ONLY ani nie można zmienić ich nazwy.

Oto składnia tworzenia tymczasowych przestrzeni tabel zarządzanych słownikiem danych na przykładzie:

CREATE TABLESPACE TEMP
DATAFILE '/disk5/oradata/mydb/emp01.dbf' SIZE 300M
DEFAULT STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0 MAXEXTENTS UNLIMITED)
TEMPORARY;

Domyślna tymczasowa przestrzeń tabel

Jeśli nie jest określona domyślna tymczasowa przestrzeń tabel oraz użytkownik nie ma przypisanej domyślnej tymczasowej przestrzeni tabel, wtedy do tego celu jest używana systemowa przestrzeń tabel SYSTEM. Oto instrukcja określania domyślnej tymczasowej przestrzeni tabel.

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE Temp;

Przestrzeń ta staje się domyślną przestrzenią dla wszystkich użytkowników dla których explicite nie podano domyślnej tymczasowej przestrzeni tabel. Przestrzeni tej nie można usunąć (dopóki nie określi się nowej domyślnej).

Przestrzenie tabel tylko do odczytu

W przestrzeni tabel tylko do odczytu można tylko odczytywać dane, nie można ich zmieniać,  ale za to można usuwać całe obiekty (bo usuwanie obiektów dotyczy tylko słownika danych!). Nie są tworzone rekordy dziennika powtórzeń, nie tworzone są  backupy. Zatem dostęp do danych jest szybszy.

ALTER TABLESPACE Userdata READ ONLY;

Zmianę trybu na zwykły realizuje klauzula READ WRITE.

Nie trzeba czekać na zakończenie działających transakcji. Przy wykonywaniu polecenia

ALTER TABLESPACE Userdata READ ONLY;

przestrzeń tabel pozostaje w przejściowym stanie, w którym nie są dozwolone operacje DML, natomiast transakcje mogą jeszcze wykonać COMMIT lub ROLLBACK. Po zakończeniu wszystkich działających transakcji przestrzeń tabel staje się READ ONLY.

Konfiguracja OMF - pliki zarządzane przez system Oracle

System daje możliwość uproszczenia zarządzania plikami przy skorzystaniu z opcji OMF (ang. Oracle Managed Files). Pliki są wtedy tworzone i usuwane automatycznie przez serwer Oracle. Aby użyć opcji OMF, należy ustawić parametry inicjalizacyjne:

Przykład

Przed utworzeniem bazy danych definiujemy parametry inicjalizacyjne:

DB_CREATE_FILE_DEST='u01/oradata/'
DB_CREATE_ONLINE_LOG_DEST_1='u02/oradata/'
DB_CREATE_ONLINE_LOG_DEST_2='u03/oradata/'

Wtedy przestrzeń tabel (z lokalnie zarządzanymi ekstentami) tworzy się bardzo prosto:

CREATE TABLESPACE dane_finansowe;

Plik danych zostaje utworzony w katalogu DB_CREATE_FILE_DEST rozmiaru 100MB z możliwością nieograniczonego zwiększania swojego rozmiaru. Przy usuwaniu przestrzeni tabel, wszystkie jej pliki są także usuwane.

Zarządzanie segmentami obiektów

Segmenty są fizycznymi zapisami obiektów zajmującymi miejsce w bazie danych. Są zapisywane w plikach danych bazy danych. Jest kilka typów segmentów:

1. Tabela (zwykła bez partycji) - dane w segmencie są zapisane w dowolnym porządku. Wszystkie dane są zapisywane w jednej przestrzeni tabel.

2. Partycja tabeli - tabela jest podzielona na partycje, z których każda jest przechowywana w osobnej przestrzeni tabel - jako osobny segment, którego parametry mogą być specyfikowane indywidualnie. Stosowana w przypadku współbieżnego użycia danych przez wielu użytkowników. Podziału dokonuje się przez podział względem wartości pewnego klucza, ewentualnie z użyciem funkcji haszującej.

3. Klaster - wiersze są przechowywane względem wartości kolumny klucza. W klastrze mogą być zapisane wiersze jednej lub więcej tabel.  Tabele w klastrze należą do tego samego segmentu - mają więc te same charakterystyki zapisu. Wiersze w tabeli w klastrze są dostępne albo przez indeks na B-drzewie albo za pomocą tablicy haszowanej.

4. Indeks - wszystkie pozycje konkretnego indeksu są zapisane w jednym segmencie. Celem indeksu jest umożliwić szybkie wyszukiwanie wierszy w tabeli na podstawie wartości kolumny (kolumn) klucza.

5. Tabela połączona z indeksem głównym (IOT, ang. Indexed-Organized Table) - wszystkie wiersze tabeli są zapisane w liściach indeksu B-drzewa.

6. Partycja indeksu - podobnie jak partycja tabeli.

7. Segment wycofań (ang. undo segment) - zawiera poprzednie wartości zmienianych danych co umożliwia wyliczenie i ewentualne przywrócenie poprzednich wartości danych.

8. Tymczasowy segment - obszar na dysku służący do przechowywania tymczasowych danych np. przy sortowaniu dużej ilości danych, które nie mieszczą się w pamięci wewnętrznej.

9. Segment LOB - duże obiekty w kolumnie tabeli mogą być zapisane w osobnym segmencie (różnym od segmentu tabeli). W kolumnie jest zapisywany tylko wskaźnik do dużego obiektu.

10. Tabela zagnieżdżona - wartościami w kolumnie mogą być osobne zagnieżdżone tabele. Są one zapisywane w osobnym segmencie.

11. Segment bootstrapowania - obszar na dysku służący do inicjalizacji słownika danych przy otwieraniu bazy danych.

Klauzula STORAGE

Klauzula STORAGE może być określona na poziomie przestrzeni tabel (jak już pokazaliśmy), ale także może być określona na poziomie konkretnego segmentu i wtedy zastępuje specyfikacje na wyższym poziomie.

Jeśli zmieniamy parametry STORAGE, nowe opcje stosują się tylko do alokowanych od tej chwili ekstentów.

Z puli wolnych ekstentów przestrzeni tabel alokowane są ekstenty do tworzonych segmentów. Gdy segment zwalnia miejsce, zwalniane ekstenty są dodawane do puli wolnych ekstentów dostępnych w przestrzeni tabel.

W przypadku przestrzeni tabel zarządzanych słownikiem danych, sąsiadujące na dysku wolne ekstenty są uspójniane przez DBA za pomocą operacji:

ALTER TABLESPACE data01 COALESCE;

Parametry wykorzystania miejsca w bloku

Są to parametry PCTFREE, PCTUSED, INITRANS i MAXTRANS.

Ustawienia stopnia zajętości miejsca w blokach jest związane z pytaniem, kiedy dany blok ma się znaleźć na liście wolnych bloków, to znaczy bloków mających wolne miejsce do wpisania nowego wiersza.

Dla każdego segmentu (tabeli, klastra, indeksu) Oracle utrzymuje jedną lub więcej list wolnych bloków, w których jest miejsce do zapisu wierszy wpisywanych przez kolejne instrukcje INSERT. Oprócz tego w każdym bloku pozostawia się trochę wolnego miejsca na zwiększające się rozmiary zapisanych w nim wierszy jako rezultatu instrukcji UPDATE. Ustala się mianowicie dwa parametry:

* PCTFREE - parametr określający procent miejsca w bloku pozostawiany dla wierszy zwiększających swoje rozmiary przez przyszłe operacje UPDATE.  PCTFREE musi być liczbą całkowitą z przedziału od 0 do 99.

Np. parametr PCTFREE = 20 określa, że 20% miejsca musi pozostać wolne w bloku do użycia przez przyszłe operacje UPDATE. W rezultacie blok zostaje usunięty z listy wolnych bloków, do których instrukcje INSERT mogą wstawiać kolejne wiersze. Wartość 0 umożliwia zapełnianie każdego bloku w całości przy wykonywaniu INSERT.

Wartością domyślną jest 10. PCTFREE ma podobne znaczenie dla klastrów, indeksów i migawek. Umożliwia ''dostrojenie'' gospodarki blokami pamięci do aplikacji - co może zwiększyć jej szybkość. Np. wysokie PCTFREE jest dobre dla segmentów, do których wykonuje się często aktualizacje, jak również w sytuacji wykonywania zapytań lub transakcji typu READ ONLY, gdy jednocześnie działa wiele transakcji innych użytkowników jeszcze nie zatwierdzonych - informacje o transakcjach są zapisywane razem z danymi. Niskie PCTFREE oszczędza pamięć.

* PCTUSED - parametr określający procent zajętego miejsca w bloku, po przekroczeniu którego (w dół) blok zostaje z powrotem wstawiony na listę wolnych bloków.

Np. PCTUSED = 60 oznacza, że gdy procent zajętego w bloku miejsca spadnie poniżej 60% (z powodu DELETE i UPDATE), blok zostaje z powrotem wstawiony na listę wolnych bloków - aby mogły w nim umieszczać wiersze kolejno wykonywane instrukcje INSERT.

Wartością domyślną jest 40. Suma PCTFREE+PCTUSED musi być mniejsza niż 100. PCTFREE ma podobne znaczenie dla klastrów, indeksów i perspektyw zmaterializowanych (migawek). Umożliwia ''dostrojenie'' gospodarki blokami pamięci do aplikacji - co może zwiększyć jej szybkość. Np. wysokie PCTUSED oszczędza pamięć, niskie przyśpiesza UPDATE i INSERT.

Przykład

CREATE TABLE Zamówienia( ........) PCTFREE 20 PCTUSED 60;

Gdy UPDATE zwiększa rozmiar wiersza tak, że nie mieści się już w bloku, Oracle szuka innego bloku wystarczająco dużego do pomieszczenia tego wiersza. Jeśli znajdzie taki blok, przenosi do niego wiersz - nazywa się to migracją wiersza. Jeśli nie znajdzie, dzieli wiersz na kawałki i zapisuje je w różnych blokach - nazywa się to łańcuchowaniem wierszy. Powoduje to pogorszenie czasu działania aplikacji bazodanowych. W takiej sytuacji może pomóc dobranie odpowiednich wartości parametrów PCTUSED i PCTFREE, a także zwiększenie wielkości bloku lub usunięcie i wstawienie od nowa podzielonych na łańcuchy wierszy.

Warto także wiedzieć, że NULL jest reprezentowany przez jeden bajt w zapisie wiersza tylko, jeśli po danej pozycji w wierszu występują pozycje nie NULL. Zatem opłaca się kolumnę, w której może być dużo wartości NULL, umieszczać jako ostatnią w schemacie tabeli - jej reprezentacja nie będzie wtedy zajmować żadnego miejsca na dysku w przypadku wystąpienia NULL.

Pozycje transakcji - miejsce w nagłówku bloku danych przeznaczone na informację o aktualnie wykonywanych transakcjach, używających wierszy zapisanych w bloku (przed wykonaniem COMMIT lub ROLLBACK).

* INITRANS - parametr określający, dla ilu transakcji są z góry wyznaczone ich pozycje w nagłówku bloku; dla pozostałych transakcji alokacja w bloku jest dynamiczna. INITRANS może mieć wartość od 1 do 255, domyślnie 1.

* MAXTRANS - parametr określający maksymalną liczbę transakcji, które mogą równocześnie korzystać z tego samego bloku. Liczba INITRANS transakcji ma statycznie przydzielaną pamięć w bloku - dla pozostałych pamięć jest alokowana dynamicznie. Domyślna wartość MAXTRANS jest ustalana przez system i zależy od wielkości bloku danych.

Zarządzanie blokami danych

Jak już wspominaliśmy, są dwie metody zarządzania blokami danych:

1. automatyczna - dostępna tylko w przestrzeniach tabel zarządzanych lokalnie;

2. ręczna - dostępna zarówno w przestrzeniach tabel zarządzanych lokalnie jak i w przestrzeniach tabel zarządzanych słownikiem danych.

Metoda automatyczna używa map bitowych zamiast list wolnych bloków.

Pozycja mapy bitowej określa status każdego bloku w segmencie względem dostępnego w nim miejsca. Mapa jest zawarta w osobnym zbiorze bloków nazywanych blokami BMB (ang. bitmapped blocks). Przy wstawianiu nowego wiersza, serwer przeszukuje mapę, w celu znalezienia bloku z wystarczającą ilością wolnego miejsca. Gdy ilość wolnego miejsca się zmienia, nowy stan jest uwzględniany w bitmapie.

CREATE TABLESPACE data02
DATAFILE '/u01/oradata/data02.dbf' SIZE 5M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
SEGMENT SPACE MANAGEMENT AUTO;

Specyfikacja dotyczy wszystkich segmentów wchodzących w skład danej przestrzeni tabel.

W ten sposób mogą być zarządzane segmenty tabel, indeksów, tabel połączonych z indeksami i duże obiekty LOB.

Ręczne zarządzanie blokami danych

Przy ustawieniu ręcznego zarządzania blokami danych podczas tworzenia segmentów obiektów jak np. w podanej przestrzeni tabel:

CREATE TABLESPACE data02
DATAFILE '/u01/oradata/data02.dbf' SIZE 5M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
SEGMENT SPACE MANAGEMENT MANUAL;

jest możliwe ustawienie parametrów takich jak PCTFREE i PCTUSED dla poszczególnych segmentów tej przestrzeni tabel.

 


14.9 Podsumowanie

Przedstawiliśmy organizację serwera bazy danych Oracle opisując struktury danych na dysku (czyli struktury bazy danych), struktury danych w pamięci wewnętrznej oraz podstawowe procesy systemu Oracle (czyli struktury i procesy instancji). Podaliśmy też informację o strukturach łączących poziom logiczny z poziomem fizycznym bazy danych.
 


14.10 Słownik

pliki danych - zawierają dane przechowywane w bazie danych.

pliki dziennika powtórzeń - rejestrują operacje wykonywane na danych.

plik kontrolny - zawiera podstawowe informacje o fizycznej strukturze bazy danych takie jak nazwa bazy danych, lokalizacje plików danych i plików dziennika powtórzeń.

plik z parametrami - zawiera ustawienia wartości podstawowych parametrów inicjalizacyjnych, z którymi zostaje uruchomiona instancja Oracle.

plik z hasłami - weryfikuje użytkowników uprawnionych do uruchamiania i zamykania instancji.

pliki zarchiwizowanego dziennika powtórzeń - są skumulowanymi kopiami plików dziennika powtórzeń używanymi do odtworzenia bazy danych w przypadku awarii mediów (dysków).

pliki ostrzeżeń (ang. alert files) - zawierają ostrzeżenia dotyczące działania całej instancji.

pliki śladu (ang. trace files) - zawierają informacje dotyczące działania poszczególnych procesów serwera bazy danych.

Globalny obszar systemu SGA jest używany do przechowywania w pamięci operacyjnej informacji z bazy danych, które są współdzielone przez procesy instancji.

Obszar współdzielony - zawiera bufory biblioteczne, bufory słownika danych i struktury kontrolne.

Bufory biblioteczne - przechowują informacje o ostatnio wykonywanych instrukcjach SQL i PL/SQL umożliwiając współdzielenie kodu wynikowego wielokrotnie używanych instrukcji.

Bufory słownika danych - zawierają definicje obiektów bazy danych używanych ostatnio w tym informacje o plikach bazy danych, tabelach, indeksach, kolumnach, użytkownikach, uprawnieniach.

Bufory bazodanowe - przechowują ostatnio używane bloki danych, które wcześniej zostały sprowadzone z plików danych.

Bufor dziennika powtórzeń - rejestruje wszystkie zmiany dokonywane w ramach jednej instancji - przede wszystkim zmiany zawartości bloków bazodanowych.

Globalny obszar programowy - zawiera dane i informacje kontrolne potrzebne dla pojedynczego procesu systemu Oracle.

proces serwera - tworzony przez system do obsługi zleceń od zgłaszających się przez sieć procesów użytkowników.

procesy tła - są to stałe procesy tworzone przez Oracle dla każdej instancji przeznaczone do wykonywania rutynowych zadań systemu zarządzania bazą danych.

Pisarz bazy danych - zapisuje zmodyfikowane bloki danych z buforów bazodanowych do plików danych.

Pisarz dziennika - dokonuje sekwencyjnych zapisów zawartości bufora dziennika powtórzeń do plików dziennika powtórzeń.

Monitor systemu - jest to proces działający w tle automatycznie dokonujący odtworzenia instancji gdy baza danych zostanie z powrotem otwarta po awarii instancji.

Monitor procesów - jest to proces działający w tle oczyszczający system po awarii procesu serwera.

zdarzenie punktu kontrolnego - zdarzenie polegające na tym, że Pisarz Bazy Danych zapisuje wszystkie zmodyfikowane bloki w buforach bazodanowych w SGA, zarówno ze zmianami zatwierdzonymi jak i nie, do plików danych.

Proces punktu kontrolnego - inicjuje i przeprowadza punkt kontrolny.

Archiwizator - proces działający w tle automatycznie archiwizujący pozycje dziennika powtórzeń - chroniąc je przed nadpisaniem.

Dyspozytor - gdy użytkownik zgłasza żądanie, Dyspozytor umieszcza zgłoszenie w kolejce zleceń. Po wykonaniu zlecenia, proces dyspozytora przekazuje użytkownikowi wyniki pobierając je z kolejki odpowiedzi.

współdzielony proces serwera - proces serwera, który jest współdzielony do wykonywania zleceń różnych użytkowników.

przestrzeń tabel - jest to struktura pośrednia między strukturą logiczną (tabelami, indeksami) a fizyczną (plikami danych).

segment - reprezentuje obszar dysku przeznaczony do zapisu jednego obiektu.

ekstent - składa się ze spójnego ciągu bloków alokowanych jako całość.

przestrzeń tabel zarządzana lokalnie - organizacja zapisu, w której informacja o ekstentach w pliku danych jest reprezentowana za pomocą mapy bitowej zapisywanej w tym pliku danych. Każdy bit odpowiada jednemu ekstentowi. Jego wartość wskazuje czy ekstent jest używany czy wolny.

przestrzeń tabel zarządzana słownikiem danych - organizacja zapisu, w której informacja o wszystkich wolnych ekstentach jest zapisywana w tabelach słownika danych.

przestrzeń tabel wycofań - przestrzeń tabel, która służy wyłącznie do przechowywania segmentów wycofań.

przestrzeń tabel tymczasowa - przestrzeń tabel, która dostarcza pomocniczego miejsca na dysku do wykonywania instrukcji SQL w tym sortowania.

przestrzeń tabel tylko do odczytu - stan przestrzeni tabel polegający na zablokowaniu instrukcji DML w odniesieniu do obiektów składowanych w tej przestrzeni tabel.

OMF - konfiguracja serwera, w której wszystkie pliki są zarządzane przez system.

 


14.11 Sprawdzenie wiedzy

  1. Z jakich części składa się serwer bazy danych? Odpowiedź
  2. Z jakich struktur składa się dziennik powtórzeń? Odpowiedź
  3. Która część struktury SGA zawiera kod SQL i PL/SQL, ich rozbiór gramatyczny (sparsowany kod) i plan ich wykonania? Odpowiedź
  4. Co to są zapytania rekurencyjne? Odpowiedź
  5. Na czym polega zjawisko trafienia? Odpowiedź
  6. Jak nazywają się rekordy dziennika powtórzeń? Odpowiedź
  7. Jak nazywa się pamięć alokowana dla każdego procesu systemu? Odpowiedź
  8. Wymień najważniejsze procesy tła? Odpowiedź
  9. Jakie zadania wykonuje proces serwera? Odpowiedź
  10. Jakie struktury serwera bazy danych łączy konstrukcja przestrzeni tabel? Odpowiedź
  11. Wymień typy segmentów? Odpowiedź

 


14.12 Zadania

1. Zapoznaj się z dokumentami opisującymi system Oracle, mianowicie:

Oracle Database Concepts: http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220.pdf

oraz

Oracle Database Administrator's Guide http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14231.pdf

 



Strona przygotowana przez Lecha Banachowskiego, PJWSTK, 08/09/06 .