Architektura pamięci Oracle – SGA i PGA

Kluczem do zrozumienia jak działa Oracle Database, jest poznanie obszarów pamięci dla instancji bazodanowej. Istotny jest sposób wykorzystywania pamięci i cel jakiemu służy, oraz znajomość podstawowych procesów, które wykorzystują tę pamięć do obrabiania danych w bazie. W tym wpisie szczegółowo opisze architekturę pamięci Oracle Database, w tym pamięć SGA i PGA.

Architektura pamięci Oracle dzieli się na następujące struktury pamięci:

  • System Global Area (SGA): Wspólny segment pamięci, do którego dostęp ma praktycznie każdy proces Oracle.
  • Process Global Area (PGA): Pamięć prywatna dla pojedynczego procesu lub wątku; nie jest dostępna dla innych procesów/wątków.
  • User Global Area (UGA): Pamięć związana z Twoją sesją. Znajduje się ona albo w SGA, albo w PGA, w zależności od tego, czy łączysz się z bazą danych za pomocą Shared Server (będzie w SGA), czy Dedicated Server(będzie w PGA).
eBook Niezbędnik Administratora Baz Danych cover

Co to PGA (Program or Process Global Area)?

Pamięć zarezerwowana dla każdego procesu użytkownika podłączającego się do bazy danych Oracle. PGA jest przydzielane przy tworzeniu procesu i zwalniana przy zakończeniu procesu.

Zawartość PGA:

  • Private SQL Area: zawiera dane takie jak informacje o zmiennych i struktury pamięci czasu wykonania. Składa się z dwóch obszarów: Obszaru Trwałego, który zawiera informacje o zmiennych i jest zwalniany tylko wtedy, gdy kursor zapytania jest zamknięty, oraz Obszaru Czasu Wykonania, który jest tworzony jako pierwszy krok żądania wykonania. Ten obszar jest zwalniany tylko po wykonaniu instrukcji. Liczba prywatnych obszarów SQL, które mogą być przydzielone do procesu użytkownika, zależy od parametru inicjalizacyjnego OPEN_CURSORS.
  • Pamięć sesji: Składa się z pamięci przydzielonej na przechowywanie zmiennych sesji i innych informacji związanych z sesją.
  • Obszary robocze SQL: Służą do operacji wymagających dużo pamięci, takich jak sortowanie, łączenie metodą haszową, scalanie bitowe i tworzenie map bitowych.

Dynamiczne zarządzanie buforami PGA

Przed wprowadzeniem dynamicznego zarządzania buforami Administrator Baz Danych musiał przydzielać pamięć dla:

  • SORT_AREA_SIZE: Całkowita ilość pamięci RAM używana do sortowania informacji przed przeniesieniem ich na dysk.
  • SORT_AREA_RETAINED_SIZE: Ilość pamięci używana do przechowywania posortowanych danych po zakończeniu sortowania.
  • HASH_AREA_SIZE: Ilość pamięci, którą proces serwera może używać do przechowywania tablic haszowych w pamięci. Struktury te są używane podczas łączenia metodą haszową, zwykle podczas łączenia dużego zbioru z innym zbiorem. Mniejszy z dwóch zbiorów jest haszowany do pamięci, a wszystko, co nie mieści się w obszarze pamięci przeznaczonym na tablicę haszową, jest przechowywane w przestrzeni tymczasowej przez klucz łączenia.

Aby włączyć automatyczne zarządzanie pamięcią PGA, należy wyłączyć parametr WORKAREA_SIZE_POLICY i przydzielić całkowitą pamięć do użycia dla PGA_AGGREGATE_TARGET.

PGA_AGGREGATE_TARGET jest celem górnego limitu. Nie jest to wartość, która jest przydzielana podczas uruchamiania bazy danych. Można to zauważyć, ustawiając PGA_AGGREGATE_TARGET na wartość znacznie wyższą niż dostępna pamięć fizyczna na serwerze. Nie zobaczysz dużego przydziału pamięci w wyniku tego. Sesja i zapytanie będzie korzystać z niewielkiego procentu PGA_AGGREGATE_TARGET, zwykle około 5 procent lub mniej. Algorytm przydziela 5% PGA do procesu użytkownika, dopóki nie zabraknie miejsca na PGA, a następnie modyfikuje przydział w oparciu o wymagania dotyczące użycia procesu użytkownika.


Praktyczne ćwiczenia z konfiguracji zarówno SGA i PGA dostępne w kursie: Praktyczna Administracja – Oracle Database!


Co to SGA (System lub Shared Global Area)?

SGA służy do przechowywania informacji o bazie danych, które są współdzielone przez procesy bazy danych. Zawiera dane i informacje kontrolne dla serwera Oracle i jest przydzielana w pamięci wirtualnej komputera, na którym działa Oracle. Bufory te są typu LRU(Last Recently Used).

Bufor ponownego wykonywania (Redo Buffer)

Bufor ponownego wykonywania to miejsce, w którym dane, które muszą zostać zapisane w dziennikach ponownego wykonywania(REDO Log), są tymczasowo buforowane, zanim zostaną zapisane na dysku. Ponieważ transfer pamięć-pamięć jest znacznie szybszy niż transfer pamięć-dysk, użycie bufora ponownego wykonywania może przyspieszyć działanie bazy danych. Dane nie będą długo znajdować się w buforze ponownego wykonywania. Faktycznie, LGWR rozpoczyna opróżnianie tego obszaru w jednym z następujących przypadków:

  • Co trzy sekundy
  • Za każdym razem, gdy ktoś wykonuje commit
  • Gdy LGWR jest proszony o zmianę plików dziennika
  • Gdy bufor ponownego wykonywania jest wypełniony w jednej trzeciej lub zawiera 1 MB buforowanych danych dziennika ponownego wykonywania

Bufor blokowy (Buffer Cache)

Bufor bloków to miejsce, w którym Oracle przechowuje bloki bazy danych przed zapisaniem do ich na dysk i po odczytaniu ich z dysku(zapis do plików danych posegregowanych w tablespace). Istnieją trzy miejsca do przechowywania buforowanych bloków z poszczególnych segmentów w SGA:

  • Pula oracle domyślna (gorący bufor): Miejsce, w którym normalnie buforowane są wszystkie bloki segmentów.
  • Pula oracle keep (ciepły bufor): Alternatywny bufor, w którym zazwyczaj przypisuje się segmenty, które są stosunkowo często używane, ale wypadają z domyślnego bufora z powodu potrzeby miejsca dla innych segmentów.
  • Pula oracle recycle: Alternatywny bufor, w którym zazwyczaj przypisuje się duże segmenty, które są dostępne w bardzo losowy sposób i które spowodowałyby nadmierny zrzut buforów z wielu bloków z wielu segmentów. Nie ma korzyści z buforowania takich segmentów, ponieważ w momencie ponownego potrzebowania bloku zostałby już usunięty z pamięci podręcznej. Segmenty te są oddzielane od segmentów w pulach domyślnych i keep, aby nie powodowały one wydalenia tych bloków z pamięci podręcznej.

Shared Pool

Pula współdzielona to miejsce, w którym Oracle buforuje wiele elementów „programowych”. Podczas parsowania zapytania, sparsowana reprezentacja jest tam buforowana. Zanim przystąpimy do parsowania całego zapytania, Oracle przeszukuje pulę współdzieloną, aby sprawdzić, czy praca została już wykonana.

Kod PL/SQL, który uruchamiasz, jest buforowany w puli współdzielonej, więc przy następnym uruchomieniu nie trzeba go ponownie odczytywać z dysku. Kod PL/SQL nie tylko jest buforowany tutaj, ale także jest tu udostępniany. Jeśli masz 1000 sesji, które wszystkie wykonują ten sam kod, tylko jedna kopia kodu jest ładowana i udostępniana wszystkim sesjom.

Oracle przechowuje parametry systemowe w puli współdzielonej. Tutaj przechowywane są także informacje pamięci podręcznej słownika danych (informacje buforowane o obiektach bazy danych).

Pula współdzielona zarządza pamięcią na zasadzie LRU, podobnie jak bufor blokowy, co jest idealne do buforowania i ponownego wykorzystywania danych.

Large Pool

Duża pula nie nazywa się tak ze względu na „dużą” strukturę (choć może być w rzeczywistości duża pod względem rozmiaru). Nazywa się tak, ponieważ jest używana do alokacji dużych fragmentów pamięci, które są większe niż pula współdzielona jest w stanie obsłużyć. Duże alokacje pamięci mają tendencję do pobrania kawałka pamięci, jej użycia, a następnie jej zwolnienia. Nie było potrzeby buforowania tej pamięci jak w przypadku bufora blokowego i puli współdzielonej, dlatego została przydzielona nowa pula. W zasadzie pula współdzielona przypomina pulę keep, podczas gdy duża pula jest podobna do puli recycle. Duża pula jest używana w szczególności przez:

  • Połączenia współdzielonego serwera, aby przydzielić region UGA w SGA.
  • Wykonywanie równoległe instrukcji, aby umożliwić przydzielenie buforów wiadomości międzyprocesowych, które są używane do koordynacji serwerów równoległego zapytania.
  • Rezerwa dla buforów wejścia-wyjścia na dysk procesów backup/restore RMAN w niektórych przypadkach.

Java Pool

Pula Java jest używana w różny sposób, w zależności od trybu pracy serwera Oracle. W trybie serwera dedykowanego całkowita pamięć wymagana dla puli Java jest dość skromna i można ją określić na podstawie liczby klas Java, które będą używane. W połączeniu z serwerem współdzielonym pula Java obejmuje udostępnioną część każdej klasy Java i niektórą część UGA używaną do stanu sesji na sesję, która jest przydzielana z JAVA_POOL w ramach SGA.

Streams Pool

Pula strumieniowa (lub do 10 procent puli współdzielonej, jeśli nie jest skonfigurowane inaczej) jest używana do buforowania wiadomości kolejki używanych przez procesy strumieniowe podczas przenoszenia lub kopiowania danych z jednej bazy danych do drugiej.

Dynamiczne zarządzanie buforami SGA

Jeżeli ustawisz wartość SGA_TARGET na wartość niezerową (na wartość, którą decydujesz się przydzielić do SGA), włączysz dynamiczne zarządzanie buforami SGA. Aby to zrobić, ustaw parametr STATISTICS_LEVEL na TYPICAL lub ALL. Jeśli nie masz włączonego zbierania statystyk, baza danych nie będzie miała niezbędnych informacji historycznych do podejmowania odpowiednich decyzji dotyczących rozmiaru.

Można dynamicznie dostosowywać wartość SGA_TARGET podczas działania bazy danych, tak aby była równa wartości ustawionej dla parametru SGA_MAX_SIZE. Domyślnie SGA_TARGET jest ustawiony na tę samą wartość co SGA_MAX_SIZE. Jeśli planujesz zwiększyć SGA_TARGET, musisz wcześniej ustawić większą wartość dla parametru SGA_MAX_SIZE przed uruchomieniem instancji bazy danych.