Architektura bazy Oracle

 Struktura

W bazie danych Oracle występują trzy główne struktury:

• pamięci
• procesu
• danych

Pod określeniem bazy danych należy rozumieć bazę danych oraz instancję bazy danych.

Baza składa się zarówno ze struktur fizycznych, jak i struktur logicznych. Ponieważ są one od siebie oddzielone, możliwe jest przechowywanie danych w strukturach fizycznych bez wpływu na dostęp do logicznych struktur danych.

W skład instancji wchodzą struktury pamięci i procesy tła powiązane z instancją. Za każdym razem kiedy instancja jest uruchamiana, alokowany jest obszar pamięci współdzielonej nazywany System Global Area (SGA) i uruchamiane są procesy w tle.

Procesy są jobami, które wykonywane są w pamięci komputera. Proces jest definiowany jako wątek lub mechanizm w systemie operacyjnym, który może wykonywać sekwencję działań. Po uruchomieniu instancji bazy danych, oprogramowanie Oracle łączy instancję z konkretną fizyczną bazą danych. Określane jest to jako mapowanie bazy danych. Po tym kroku baza danych jest gotowa do pracy i może być udostępniona autoryzowanym użytkownikom.

Uwaga! System Automatycznego Zarządzania Miejscem, Oracle Automatic Store Management (ASM), używa instancji dla komponentów pamięci i procesów w tle i nie jest powiązany z konkretną bazą danych.

Połączenie z bazą danych

Połączenie i sesja są ściśle związane z procesami użytkownika, ale różnią się znaczeniem. 

Połączenie jest ścieżką komunikacyjną pomiędzy procesem użytkownika, a instancją bazy danych Oracle. Ścieżka komunikacyjna jest nawiązywana za pomocą dostępnych mechanizmów obsługujących procesy, kiedy komputer obsługuje proces użytkownika i bazę danych, lub poprzez oprogramowanie sieciowe, kiedy różne komputery obsługują aplikację kliencką oraz bazę danych i następuje komunikacja sieciowa.

Sesja reprezentuje stan zalogowania użytkownika do instancji bazy danych. Kiedy użytkownik uruchamia np. SQL*Plus, musi wprowadzić poprawny login i hasło, a wtedy zakładana jest sesja. Sesja trwa od momentu połączenia, dopóki użytkownik nie rozłączy połączenia lub wyjdzie z aplikacji klienckiej. Wiele sesji może zostać utworzonych i istnieć jednocześnie dla pojedynczego użytkownika bazy danych używającego tego samego loginu. Na przykład, użytkownik o danych logowania XX/YY może połączyć się z tą samą instancją bazy danych Oracle klika razy.

Struktury pamięci bazy danych

Baza danych Oracle tworzy i korzysta ze struktur pamięci do różnych celów. Struktury pamięci przechowują, kod który jest aktualnie wykonywany, dane udostępniane pomiędzy użytkownikami i dedykowane obszary danych dla każdego połączonego użytkownika.

Dwie podstawowe struktury pamięci są powiązane z instancją: 

• System Global Area (SGA): grupa struktur pamięci określana jako SGA, komponenty zawierające dane i informacje sterujące dla pojedynczej instancji bazy danych. SGA jest współdzielone przez cały serwer bazy danych i procesy w tle. Przykładowe dane przechowywane w SGA to data bloki wczytane do pamięci podręcznej i współdzielony obszar zapytań SQL.
  
• Program Global Area (PGA): Obszary pamięci zawierające dane i informacje sterujące dla serwera i procesów w tle. PGA jest niewspółdzielonym obszarem tworzonym przez bazę danych Oracle, kiedy serwer lub procesy w tle są uruchamiane. Dostęp do PGA jest możliwy tylko dla procesu serwera. Każdy proces serwera i proces w tle ma swój własny PGA.

System Global Area jest obszarem pamięci, który zawiera dane i informacje sterujące dla instancji. SGA zawiera następujące struktury danych:

• Shared pool (wspólny obszar) - buforuje różne konstrukcje, które mogą być współdzielone przez użytkowników.
• Database buffer cache (pamięć podręczna bufora) - buforuje bloki danych pobrane z bazy danych.
• Redo log buffer (bufor logu Redo) - buforuje informacje redo (potrzebne przy odzyskiwaniu instancji) dopóki nie będzie można zapisać ich do pliku logu redo na dysku fizycznym.
• Large pool (duży obszar) - opcjonalny obszar, który zapewnia alokację dużych zasobów pamięci dla dużych procesów jak np. kopia zapasowa, operacje odzyskiwania oraz procesy we/wy.
  
• Java pool (obszar Javy) - używany przez Wirtualną Maszynę Javy do obsługi sesji opartych o kod i dane Javy.
• Streams pool (obszar strumieni) - używany przez Oracle Streams do przechowywania informacji potrzebnych do przechwytywania i stosowania
• Fixed SGA - Wewnętrzny obszar porządkowy zawierający ogólne informacje o stanie bazy danych i instancji oraz informacje przekazywane między procesami. Po uruchomieniu instancji wyświetlana jest ilość pamięci przydzielonej dla SGA.

Program Global Area (PGA) to obszar pamięci, który zawiera dane i informacje sterujące dla każdego procesu serwera. Proces serwera Oracle obsługuje żądania klienta. Każdy proces serwera ma własne prywatne PGA, które jest przydzielane podczas uruchamiania procesu serwera. Dostęp do konkretnego PGA jest wyłączny dla konkretnego procesu serwera, a PGA jest odczytywany i zapisywany tylko przez kod Oracle działający na rzecz konkretnego procesu. PGA dzieli się na dwa główne obszary: przestrzeń stosu i globalny obszar użytkownika (UGA).

Dzięki dynamicznej infrastrukturze SGA rozmiary pamięci podręcznej bufora bazy danych, shared pool, large pool, Java pool i Streams pool mogą się zmieniać bez wyłączania instancji.

Serwer bazy danych Oracle używa parametrów określanych przy inicjalizacji do tworzenia struktur pamięci i zarządzania nimi. Najprostszym sposobem zarządzania pamięcią jest umożliwienie bazie danych automatycznego zarządzania i dostrajania jej dla użytkownika. Aby to zrobić (na większości platform), wystarczy ustawić parametr rozmiaru pamięci docelowej (MEMORY_TARGET) i parametr maksymalnego rozmiaru pamięci (MEMORY_MAX_TARGET).

Architektura procesów

Procesy w bazie danych Oracle można podzielić na trzy główne grupy:

• Procesy użytkownika, które uruchamiają aplikację lub kod narzędzia Oracle,
• Procesy bazy danych Oracle, które uruchamiają kod serwera bazy danych Oracle (w tym procesy serwera i procesy w tle),
• Demony Oracle i procesy aplikacji niespecyficzne dla pojedynczej bazy danych.

Gdy użytkownik uruchamia aplikację lub narzędzie Oracle, takie jak SQL*Plus, termin proces użytkownika jest używany w odniesieniu do aplikacji użytkownika. Proces użytkownika może, ale nie musi znajdować się na serwerze bazy danych. Baza Oracle tworzy również proces serwera do wykonywania poleceń wydawanych przez proces użytkownika. Ponadto serwer ma również zestaw procesów działających w tle instancji, współdziałających ze sobą i z systemem operacyjnym w celu zarządzania strukturami pamięci, asynchronicznego wykonywania operacji we/wy zapisujących dane na dysku oraz wykonywania innych koniecznych zadań. Struktura procesu różni się dla różnych konfiguracji bazy danych Oracle, w zależności od systemu operacyjnego i opcji bazy danych. Kod dla podłączonych użytkowników można obsługiwać jako serwer dedykowany lub serwer współdzielony.

Serwer dedykowany

W każdej sesji aplikacja bazy danych jest uruchamiana przez proces użytkownika, obsługiwany przez dedykowany proces serwera, który wykonuje kod serwera bazy danych Oracle.

Serwer współdzielony

Eliminuje potrzebę stosowania dedykowanego procesu serwera dla każdego połączenia. Dispatcher kieruje wiele przychodzących żądań sesji sieciowych do puli współdzielonych procesów serwera. Współdzielony proces serwera obsługuje każde żądanie klienta.

Struktura procesów

Procesy serwerowe

Baza danych Oracle tworzy procesy serwerowe do obsługi żądań procesów użytkownika podłączonych do instancji. Proces użytkownika reprezentuje aplikację lub narzędzie, które łączy się z bazą danych Oracle. Może się on znajdować na tym samym serwerze co baza danych, lub może istnieć zdalnie i korzystać z sieci, aby uzyskać dostęp do bazy. Proces użytkownika najpierw komunikuje się z procesem nasłuchującym (listener), który tworzy proces serwera w dedykowanym środowisku.

Procesy serwera utworzone dla aplikacji każdego użytkownika mogą wykonywać jedną lub więcej z następujących czynności: 

• Analizować i uruchamiać instrukcje SQL wydawane za pośrednictwem aplikacji. 
• Wczytywać niezbędne bloki danych z plików danych na dysku do współdzielonych buforów bazy danych SGA (jeśli bloki nie są już obecne w SGA). 
• Zwracać wyniki w taki sposób, aby aplikacja mogła przetworzyć informacje.

Procesy w tle 

 

Aby zmaksymalizować wydajność i jednocześnie obsłużyć wielu użytkowników, multiprocesowy system bazy danych Oracle wykorzystuje dodatkowe procesy bazy danych Oracle, zwane procesami w tle. Instancja bazy danych może mieć wiele procesów w tle. 

Procesy w tle często spotykane w środowiskach innych niż RAC i ASM mogą obejmować:

• Database Writer process (DBWn) - Proces zapisu bazy danych
• Log Writer process (LGWR) - Proces zapisu dziennika
• Checkpoint process (CKPT) - Proces punktu kontrolnego
• System monitor process (SMON) - Proces monitorowania systemu
• Process monitor process (PMON) - Proces monitorowania procesu
• Recoverer process (RECO) - Proces odzyskiwania
• Listener registration process (LREG) - Proces rejestracji listenera
• Manageability monitor process (MMON) - Proces monitorowania zarządzania
• Manageability monitor lite process (MMNL) - Proces uproszczony monitorowania zarządzania
• Job queue coordinator (CJQ0) - Koordynator kolejki zadań
• Job slave processes (Jnnn) - Podrzędne procesy zadań
• Archiver processes (ARCn) -Procesy archiwizujące
• Queue monitor processes (QMNn) - Procesy monitorowania kolejek
• The process spawner process (PSP0) - Proces uruchamiania procesu

Procesy w tle można znaleźć w bardziej zaawansowanych konfiguracjach, takich jak RAC. W widoku V$BGPROCESS, można zobaczyć szczegółowe informacje o procesach w tle. Niektóre z nich są tworzone automatycznie po uruchomieniu instancji, inne są uruchamiane zgodnie z wymaganiami. Struktury procesów nie są specyficzne dla pojedynczej bazy danych, ale mogą być współużytkowane przez wiele baz danych na tym samym serwerze. Infrastruktura Grid i procesy sieciowe należą do tej kategorii.

Procesy Oracle Grid Infrastructure w systemach Linux i UNIX obejmują:

• ohasd (demon Oracle High Availability Service): odpowiada za uruchamianie procesów klastrowych
• ocssd: demon usługi synchronizacji klastra
• diskmon (demon Disk Monitor): jest odpowiedzialny za monitorowanie wejścia i wyjścia do Oracle Exadata Storage
• cssdagent: uruchamia, zatrzymuje i sprawdza stan demona CSS, ocssd
• oraagent: rozszerza oprogramowanie klastrowe do obsługi specyficznych wymagań i złożonych zasobów Oracle
• orarootagent: wyspecjalizowany proces agenta Oracle, który pomaga zarządzać zasobami należącymi do użytkownika root, takimi jak sieć. 

 

Sesja i obsługa transakcji

W ramach jednej sesji użytkownik może realizować jedną lub więcej transakcji Transakcja jest jednostką interakcji użytkownika z bazą danych i składa się z pojedynczych operacji realizowanych w bazie danych. Użytkownik realizuje swoje transakcje albo przez polecenia SQL, które są kierowane bezpośrednio do systemu zarządzania bazą danych (DBMS), albo pośrednio - przy użyciu aplikacji bazy danych, odwołujących się do DMBS.

Mechanizm blokowania danych

Transakcje wykonujące operacje odczytu nie wpływają na siebie nawzajem, ich działania nie kolidują za sobą. Problem pojawia się w przypadku operacji zmieniających jednocześnie te same dane w bazie. Jeśli dwóch użytkowników zmienia jednocześnie dwa różne obiekty, nie wywołuje to konfliktu. Jeśli natomiast te operacje dotyczą tego samego obiektu powstaje konflikt. Aby uniknąć zakleszczeń będących efektem takiej sytuacji baza danych Oracle posiada złożony mechanizm zakładania blokad na obiekty. W przypadku kiedy rozpoczyna się transakcja pierwszego użytkownika na obiekcie A, drugi użytkownik może odczytywać dane z modyfikowanego obiektu A, ale nie może ich zmieniać do czasu zakończenia transakcji pierwszego użytkownika. Polecenie drugiego użytkownika zostanie skolejkowane jako oczekujące na wykonanie.

Użytkownicy i schematy

Kiedy użytkownik bazy danych tworzy obiekt, zostaje jego właścicielem. Obiekty te tworzone są w schemacie, czyli przestrzeni logicznej bazy danych. Schemat użytkownika jest tworzony automatycznie podczas definiowania użytkownika i posiada unikalną nazwę, identyczną z nazwą użytkownika. Nazwa schematu wykorzystywana jest do odwoływania się do obiektów, będących własnością danego użytkownika. Odwołanie do obiektu znajdującego się w innym schemacie umożliwia składnia:

NAZWA_UŻYTKOWNIKA.NAZWA_OBIEKTU

Nazwy obiektów muszą być unikalne w zakresie danego schematu. Dwóch użytkowników może posiadać obiekty o tej samej nazwie w swoich schematach, jednak różnie będą się do nich odwoływać. Jeśli użytkownik X i Y posiadają w swoich schematach obiekty o nazwie AAA, to mogą się do nich odwoływać, jeśli posiadają uprawnienia, dodając nazwę użytkownika przed nazwą obiektu.

Użytkownik X odnosząc się do swojego obiektu wywołuje go:

AAA

odnosząc się do obiektu AAA użytkownika Y wywołuje go

Y.AAA