Notatki Techniczne IBM Oracle

Strojenie i Architektura Oracle w AIX

Damir Rubic

IBM SAP & Oracle Solution Advanced Technical Support

Version 1.31Date:01 July 2009

Tłumaczenie: Waldemar “Mark” Duszyk @ http://wmduszyk.com©

1

PodziękowaniaDziękuję Dale Martin, Ralf Schmidt-Dennert and Jim Dilley za ich pomoc w tym i wielu innych artykułach związanych z wydajnością Oracle & IBM Power Systems

• ZastrzeżenieIBM nie sprawdziło formalnie tego dokumentu. Ten dokument może zawierać błędy, pomimo że starano się sprawdzić zawartą w nim informację. IBM nie daje żadnych gwarancji w stosunku do jego zawartości i szczególnie odmawia jakichkolwiek gwarancji domyślnych w stosunku do przydatności tego produktu do potrzeb klienta. IBM nie przyjmuje żadnej odpowiedzialności za błędy, które ten dokument może zawierać. Informacja zawarta w tym dokumencie może być zmieniona w każdej chwili. IBM rezerwuje prawa zmiany tego dokumentu bez obowiązku powiadomienia nikogo o tych zmianach. IBM nie zobowiązuje się do utrzymywania na bieżąco informacji zawartej w tym dokumencie.

• Znaki HandloweNastępujące terminy są rejestrowanymi znakami handlowymi International Business Machines Corporation w Stanach Zjednoczonych i/lub w innych krajach: AIX, AIX/L, AIX/L (logo), IBM, IBM (logo), pSeries, Total Storage, Power PC.

Następujące terminy są rejestrowanymi znakami handlowymi International Business Machines Corporation w Stanach Zjednoczonych i/lub w innych krajach: Power VM, Advanced Micro-Partitioning, AIX 5L, Micro Partitioning, Power Architecture, POWER5, POWER6, Redbooks, System p, System p5, Sustem p6, System Storage.

Pełna lista U.S. znaków handlowych posiadanych przez IBM może być znaleziona tutaj: http://www.ibm.com/legal/copytrade.shtml

Oracle jest zarejestrowanym znakiem handlowym Oracle Corporation w USA i innych krajach.

UNIX jest zarejestrowanym znakiem handlowym w Stanach Zjednoczonych i/oraz w innych krajach.

SAP R/3, SAP BI 7.0 i NW2004s są zarejestrowanymi znakami handlowymi SAP Corporation.

Java i wszystkie związane z Javą znaki handlowe i loga są zarejestrowanymi znakami handlowymi Sun Microsystems, Inc. w USA i/oraz innych krajach.

2

1. Architektura Bazy Danych Oracle

1.1 Struktura Bazy Danych

Baza danych Oracle to kolekcja daty traktowana jako jednostka. Celem bazy danych jest przechowanie i przetwarzanie danych. Kluczowym składnikiem systemu informacyjnego jest serwer bazy danych. Bez zagłębiania się w szczegóły, serwer utrzymuje dużą liczbę danych w środowisku umożliwiającym dużej liczbie użytkowników jednoczesny dostęp do jego danych. Serwer wykonujący te czynności powinien charakteryzować się wysoką wydajnością. Serwer bazy danych uniemożliwia dostęp do swoich zasobów jednostką do tego nie autoryzowanym oraz jest odpowiednio przygotowany na wypadek awarii swoich urządzeń składowych.

Baza danych składa się z niezależnych elementów fizycznych i logicznych. Ten fakt umożliwia zarządzanie fizycznym systemem przechowywania danych niezależenie od jego logicznego użytkownika (bazy danych).

1.1.1 Struktura Logiczna

Baza Danych Oracle składa się z kilku logicznych elementów, takich jak bloki danych (blocks), ekstenty (extent), segmenty, (segments), tablice (tablespaces) oraz obiektów typu schemat (schema).

Jej dane są przechowywane w blokach plików systemu. Najmniejsza jednostka danych w plikach zawierających dane czy w plikach zawierających indeksy jest określona wartością parametru DB_BLOCK_SIZE. Oracle rezerwuje część pojemności bloku do przechowania informacji takiej jak adres zawartych w nim rzędów oraz rodzaj przechowywanej w nim informacji.

Ekstent to kolekcja sąsiadujących i logicznie ze sobą powiązanych bloków danych. Te bloki mogą się znajdować w różnych plikach systemu, folderach, LUNach czy dyskach. Tablice to obiekt składający się z jednego lub więcej ekstentów. Pierwszy z nich jest znany jako ekstent początkujący (initial extent). Oracle przydzieli następny extent po wypełnieniu pojemności początkowego extent, który nie musi być tego samego rozmiaru (w bytes) jak jego poprzednik.

Segment to kolekcja extents zawierających wszystkie dane określonej logicznej struktury w tablicy typu table czy index. Oracle posiada cztery różne rodzaje segmentów, każdy z nich odpowiada logicznej konstrukcji przechowującą dane:

Data segmentIndex segmentRollback (Undo) segmentsTemporary segments

Informacja przechowywane w tablicy, partition czy w cluster jest przechowywana w Segmentach Danych (Data Segments). W podobny sposób, dane typu indeks (index), Oracle przechowuje w Segmentach Indexów (Index Segment). Segmenty wycofania (Rollback segments) przechowują poprzednią zawartość (ich kopię) bloku danych – bez zmian będących wynikiem danej transakcji. W przypadku kiedy transakcja czy jakiś z jej elementów nie może być pomyślnie zakończony, informacja zawarta w segmencie wycofania zostaje użyta do odtworzenia oryginalnej danej. W przypadku Oracle 9i, 10g oraz 11g, jest to możliwe dzięki elementom automatycznego wycofania (automatic undo) oraz automatycznej tablicy wycofania (undo tablespace), które pozwalają również na lepszą kontrolę i użycie zasobów serwera.

Segmenty wycofania gwarantują konsystencję (spójność) czytania (read-consistency). Istnieją dwa rodzaje konsystencji czytania: na poziomie instrukcji (statement-level)oraz na poziomie transakcji (transaction-level).

Instrukcyjna konsystencja czytania powoduje, że data indywidualnego pytania (query) ma swój początek w określonym momencie czasu – czasu jego wydania. To gwarantuje, że pytanie jest w stanie dostrzec zmianę danych będącą rezultatem pomyślnie zakończonych od chwili jej egzekucji transakcji. To jest domyślny poziom konsystencji czytania (read consitency) bazy danych Oracle.

3

Oracle oferuje również możliwość wymuszenia konsystencji czytania (read-consistency) na poziomie transakcji. Tego rodzaju konsystencja czytania gwarantuje, że pytania (queries) wydane w granicach tej samej transakcji nie są w stanie dostrzec zmian będących rezultatem pytań wydanych przez inne transakcje – pytania mogą dostrzec zmiany danej będącej rezultatem tylko tej transakcji, której są składnikiem. Tego rodzaju transakcje są znane jako transakcje nadające się do serializacji (serializable).

Segmenty Tymczasowe (Temporary Segments) to obszary używane podczas egzekucji pytania (query) do tymczasowego przechowania rezultatów. Wszystkie operacje, które nie mogą być wykonane w pamięci (jak na przykład sortowanie) są typowymi operacjami wymagającymi tego typu segmentów. Następujące rodzaje pytań mogą wymagać do ich wykonania segmentów tymczasowych:

• SELECT....ORDER BY• SELECT....GROUP BY• SELECT....UNION• SELECT....INTERSECT• SELECT....MINUS• SELECT....DISTINCT....• CREATE INDEX....

Przestrzenie tabeli (Tablespaces) w celu uproszczenia fizycznego zarządzania bazą danych grupują elementy czy obiekty, które mają jakiś związek logiczny. Przestrzeń tabeli jest głównym sposobem przydzielenia i rozłożenia danych w bazie danych na poziomie foldera czy dysku systemu operacyjnego. Przestrzenie tabeli są użyte do:

• Kontrolowania przydzielenia bazie danych fizycznej pojemności dysków• Kontrolowanie dostępności do danych przez kontrolowanie dostępu do przestrzeni tabeli (online /off-line)• Dystrybucja obiektów bazy danych na urządzeniach fizycznych przechowujących dane w celu

zwiększenia jej wydajności• Zarządzanie pojemnością indywidualnych użytkowników

Każda baza danych typu Oracle zawiera przestrzeń tabeli nazwaną SYSTEM. Ta przestrzeń jest tworzona przez Oracle w czasie tworzenia bazy danych. Zawiera ona tablice słowników (data dictonary tables) używane przez bazę danych do opisu jest własnej struktury. SYSAUX jest tabelą pomocniczą tabeli SYSTEM. Inne tablespaces również używają SYSAUX jako tabelę domyślną do przechowania ich danych. Z tej przyczyny, SYSAUX jest zawsze tworzona w czasie tworzenie czy unowocześniana (upgrade) bazy danych. SYSAUX przedstawia sobą centralną lokację metadanych (metadaty) bazy danych nienależącej do tabeli SYSTEM. To pozwala na redukcję ilości tworzonych tablic przestrzeni zarówno w bazach danych użytkowników, jak i systemu. Ty musisz podać definicję co najmniej jeden tymczasowej tablicy przestrzeni (tablespace) w przypadku tworzenia bazy danych z lokalnie zarządzaną tabelą SYSTEM. Ta lokalnie zarządzana tablica przestrzeni SYSTEM nie może być użyta jako domyślny tymczasowy pojemnik do przechowywania danych. Jeżeli SYSTEM jest zarządzany przez dictionary (słownik) i jeżeli ty w czasie tworzenia bazy danych nie zadeklarowałeś domyślnej tymczasowej tablicy przestrzeni wtedy SYSTEM będzie użyty jako domyślna tablica przestrzeni - tymczasowe miejsce zaspakajające potrzeby przechowywania danych.

Obiekty typu schemat (schema) to obiekty logiczne używane do referowania daty bazy danych. Kilka przykładów tych obiektów to tabele (tables), indeksy (indexes), perspektywy (views), procedury składowane (stored procedures). Relacyjna baza danych to obiekty typu schemat i ich relacje.

1.1.2 Struktury fizycznego przechowywania danych

Baza danych typu Oracle składa się z trzech rodzajów plików: pliki danych (data files), dzienniki powtórzenia (redo logs) oraz plików kontrolujących (control files).

Do działania, baza danych wymaga obecności jednej lub więcej plików danych. Te pliki zawierają aktualne dane bazy danych reprezentowane przez tabele (tables) i indeksy (indexes). Na poziomie systemu operacyjnego, pliki

4

danych są zrealizowane w różne sposoby (JFS, JFS2, GPFS, Veritas FS, Oracle ASM). W tym dokumencie, skupimy się wyłącznie na plikach danych typu JFS i JFS2. Dane zawarte w tych plikach są czytane za dysków i przechowywane w obszarze pamięci maszyny znanym jako Oracle SGA.

Przestrzeń tablic Oracle (table space) składa się z jednego lub wielu pliku danych (data files). Jeden plik danych może być związany tylko z jedną table space i może być użyty tylko przez jedną bazę danych. W czasie tworzenia, pojemność fizycznego dysku związanego z plikiem danych jest formatowana – w tym momencie plik nie zawiera danych użytkownika. Podczas ładowania danych, Oracle rezerwuje przestrzeń dla daty lub indeksów w plikach typu ekstent (extends).

Oracle używa dzienników powtórzenia (redo logs) do rejestrowania zmian stanu bazy danych. Każda baza danych typu Oracle musi posiadać co najmniej dwa dzienniki powtórzenia – w przeciwnym razie odmówi ona działania. Dzienniki powtórzenia są manipulowane w systemie cyklicznym (circular); kiedy jeden z tych dzienników zostanie wypełniony, Oracle zacznie używać następnego i jeżeli wyniknie taka potrzeba, Oracle stworzy z pełnego dziennika (log) archiwum. W przypadku awarii, baza danych może zostać zrekonstruowana używając jako punkt początkowy do aplikowania redo logs kopii DB (backup typu point in time). Z uwagi na ich ważną rolę, Oracle posiada wbudowany mechanizm multipleksujący (mirroring) dzienniki powtórzenia; w każdym momencie, na dysku istnieją ich dwie kopie.

Plik kontrolujący (control file) opisuje fizyczną strukturę bazy danych. Zawiera on informację taką jak nazwa bazy danych, data i czas jej powstania, nazwy i położenie wszystkich jej plików (data files) oraz dzienniki powtórzenia (redo logs). Podobnie jak w przypadku redo logs, Oracle chroniąc się przed logiczną lub fizyczną korupcją, utrzymuje kilka kopi pliku kontrolującego.

1.2 Procesy Instancji i Aplikacji

Proces jest zdefiniowany, jako ciąg kontroli użyty przez system operacyjny w celu wykonania jednego czy kilku czynności. Oracle, do osiągnięcia tego celu używa trzy rodzaje procesów:

• Procesy użytkownika/klienta (user or client processes)• Procesy serwera (server processes)• Procesy tła (background processes)

Procesy użytkownika wykonują polecenia jego aplikacji. Proces użytkownika używa sesji (session) do porozumiewania się z procesem serwera Oracle. Sesja to specyficzne łącze programu użytkownika z instancją Oracle. Sesja trwa od momentu, w którym program użytkownika łączy się z bazą danych do momentu, w którym to połączenie jest zakończone.

Procesy serwera Oracle są tworzone do obsługi poleceń procesów użytkowników. One są odpowiedzialne za współpracę z bazą danych polegającą na wykonywaniu poleceń wydawanych przez procesy użytkowników. Liczba procesów użytkowników w stosunku do procesów serwera jest funkcją konfiguracji Oracle. W przypadku konfiguracji znanej jako “serwer przydzielony” (dedicated server), jeden proces serwera przypada na jeden proces użytkownika. W przypadku “serwera wspólnego” (shared serwer), procesy użytkowników są rozdzielone pomiędzy z góry określoną liczbą procesów serwera. Oracle 11g wprowadziło po stronie serwera nowy proces tła służący (background process) do pomocy w komunikacji znany jako DRCP (Database Resident Connection Pooling). DRCP jest zbiorem (pool) łącz bazy danych dla typowych połączeń typu Web. DRCP monitoruje wyznaczone serwery bazy danych obserwując ich sesje tworząc w ten sposób zbiory serwerów. Typowa aplikacja Web łączy się z bazą danych i używa tego połączenia na krótki czas, po czym je kończy. DRCP zaspakaja potrzeby komunikacyjne wielu nitek (threads) i procesów typu Web korzystając z zasobów danego zbioru serwerów. DRCP jest szczególnie przydatne w sytuacji, w której wieloprocesorowe (multi pocess) jedno nitkowe (single threaded) aplikacje nie są w stanie monitorować połączeń z aplikacjami pośrednimi (middle-tier). Baza danych jest w stanie obsłużyć dziesiątki tysięcy jednoczesnych sesji z DRCP.

Procesy tła bazy danych są tworzone w czasie jej startu i inicjalizacji (initialization). Pewne procesy tła są niezbędne dla normalnej operacji systemu, podczas gdy inne wykonują specyficzne funkcje w zakresie utrzymania jej w ruchu czy odzyskania jej danych.

5

Figura 1-1 Architektura Procesów Oracle

6

System Global Area (SGA)

Pamięć Podręczna

Bufora Bazy Danych

BuforRedo Log

RECO SMONPMON

Procesy Użytkownika

LGWR

ARC0CKPT

D000

Wspólne Procesy Serwera

Dedykowane Procesy Serwera

CKPTCKPTCKPTProces

Użytkownika

Procesy Użytkowników

DBW0

Pliki Kontrolujące

Offline Storage

Pliki .dbf

Pliki Redo Logs

Legenda:---------------------------------------------RECO - Proces ”Odzyskiwujący”PMOB - Monitor ProcesówSMON - Monitor SystemuCKPT - Punkt KontrolnyARCO - ArchiwistaLGWR - Pisarz DziennikówD000 - Proces Dispozytora

Oracle posiada (między innymi) następujące procesy drugoplanowe (tła):

• Sekretarz bazy Danych (DBWn/Data Base Writer)Sekretarz bazy danych jest odpowiedzialny za wpisanie zawartości “brudnych” buforów (buffers)bazy danych do dysków. Ten proces używa logarytmu Najmniej Ostatnio Użyty (Least Recently Used/LRU). Zawartość brudnych buforów zwykle jest wpisywana do dysków jeden blok fizyczny po drugim. W celu zwiększenia prędkości tej operacji, dodatkowe procesy tego rodzaju mogą być przywołane do życia. W przypadku AIXu, włączenie Asynchronicznego I/O (Asynchronous I/O) eliminuje potrzebę istnienia wielu procesów sekretarzy bazy danych oraz zwiększa ono wydajność systemu.

• Sekretarz dziennika (Log Writer/LGWR)Ten proces jest odpowiedzialny za wpisanie zawartości buforów dzienników powtórzenia (redo logs) do znajdujących się na dyskach plików dziennika powtórzenia. Podczas takiej operacji może być zapisana nawet taka małą ilość daty jak 512 bytów (w przypadku użycia DIO/CIO w AIX porównaj to z wartością agblksize). To ma miejsce w przypadku spełnienia się jednego z następujących warunków:

• Minęły trzy sekundy od ostatniego zapisu brudnego buffera do dysku.• Jedna trzecia pojemności bufora dziennika powtórzenia (redo log) została zużyta.• Proces DBWn potrzebuje wpisać do dysków zmienione bloki danych, których elementy przebywające w

buforach dzienników powtórzenia (redo logs) nie zostały jeszcze wpisane do dysków.• Transakcja została zatwierdzona (commit).

W chwili, w której użytkownik wyda polecenie COMMIT, symbol zwany rekord zatwierzenia (commit record) jest umieszczony w buforze dziennika powtórzenia (redo log) co powoduje natychmiastowy transfer zawartości bufora do dysku. Elementy buffera dziennika powtórzenia (redo log) są wpisywane w systemie Pierwszy-Wszedł-Pierwszy-Wyszedł (First-In-First-Out/FIFO) To znaczy, że po wpisaniu rekordu zatwierdzenia (commit record), wszystkie pozostałe elementy związane z tą transakcją znajdujące się w buforze również zostały wpisane do dysku. Aktualne bloki bazy danej zawierające zmienioną daną, zostają wpisane do dysków w terminie późniejszym – jest to znane jako szybkie zatwierdzenie (fast commit). Zatwierdzona (commited) w danym momencie czasu wersja bazy danych jest oznaczona przy pomocy Numeru Zmiany Systemu (System Change Number/SCN). Każda zatwierdzona transakcja posiada swój własny, unikalny Numer Zmiany Systemu (SCN).

• Proces Punktu Kontrolnego (Checkpoint Process / CKPT)Ten proces jest odpowiedzialny za informowanie procesu DBWn o potrzebie wpisania zmodyfikowanych bloków SGA bazy danych do odpowiednich plików fizycznych na dyskach. Jest on również odpowiedzialny za uaktualnianie nagłówków (headers) plików danych Oracle i jej plików kontrolujących w celu zarejestrowania faktu obecności najnowszego punktu kontrolnego.

• Archiwista (Archiver / ARCn)Po wypełnieniu plików bieżącego dziennika powtórzeń (online redolog), archiwista kopiuje ich zawartości do plików podrzędnych. Ten proces istnieje tylko w przypadku bazy danych skonfigurowanej w systemie ARCHIVELOG w obecności automatycznego archiwizowania.

• Monitor Systemu (System Monitor / SMON)Ten proces jest odpowiedzialny za odtwarzenie instancji bazy danych w czasie jest startu. Jest on również odpowiedzialny za takie czynności administracyjne jak czyszczenie nieużywanych segmentów tymczasowych oraz jednoczenie wolnych ekstentów (free extenfds) w przestrzeni tabel (tablespaces) zarządzanych przez słownik (dictonary).

• Monitor Procesów (Process Monitor / PMON)Monitor procesów porządkuje środowisko po awarii procesu użytkownika. Do jego obowiązków należy usuwanie niedziałających procesów z listy procesów, usuwanie zamków (locks) oraz zwalnianie użytych bloków w pamięci

7

podręcznego bufora bloków danych związanych z niedziałającymi poprawnie procesami. Ten sam proces jest także odpowiedzialny za startowanie dyspozytora (dispatcher) oraz innych nieoczekiwanie niedziałających procesów bazy danych.

• Odtwarzania (Recover / RECO)Ten proces odpowiada za odtworzenie wszystkich transakcji, o których pomyślnym wykonaniu baza danych nie jest pewna w 100%. RECO kontaktuje wszystkie bazy danych biorące udział w takiej transakcji w celu usunięcia referencji do tej transakcji z tablicy transakcji czekających na obsługę. Proces RECO jest obecny w czasie startu instancji bazy danych, jeżeli DISTRIBUTED_TRANSACTIONS > 0 oraz pozwolenia na obecność transakcji rozłożonych (distributed).

• Koordynator Pracy (Job Coordinator / CJQn)Ten proces instancji Oracle jest podobny w działaniu do procesu cron w UNIXie. Jego zadaniem jest startowanie procesów odpowiedzialnych za obsługę zadań wsadowych (batch jobs). Te czynności to deklaracje lub procedury PL/SQL danej instancji. W chwili startu zadań wsadowych proces CJQn przywołuje do życia związany z tą czynnością proces i umieszcza go w kolejce procesów do wykonania. Procesy w tej kolejce są nazwane J000 do J999. CJQN jest odpowiedzialny za wykonanie danego zadania wsadowego. Koordynator Pracy nie działa, kiedy JOB_QUWUW_PROCESSES=0.

• Procesy Monitorujące Kolejkę (Queue Monitoring Processes / QMNn)To są nieobowiązujące procesy drugoplanowe (background processes) monitorującego kolejki przesyłek (message queues) środowiska “Oracle Streams Advanced Queueing”. Maksymalnie, może istnieć dziesięć procesów tego rodzaju. Te procesy, podobnie jak proces koordynatora pracy różnią się od innych procesów Oracle tym, że ich awaria nie powoduje awarii instancji bazy danych.

Architektura wspólnego serwera (shared server) eliminuje konieczność obsługi sesji komunikacyjnej z bazą danych przez indywidualny i tylko jej dedykowany proces. Dyspozytor kieruje nadchodzące żądania rozpoczęci sesji do wspólnego pula (pool) procesów. Pierwszy, napotkany w pulu wolny proces zostaje przyznany do obsługi procesu sesji czekającego w kolejce procesów żądających otwarcia komunikacji z bazą danych. To znaczy, że mała liczba procesów “serwera wspólnego” jest w stanie wykonać to samo co znacznie większa liczba procesów indywidualnych. Wynikiem tego jest mniejsze zużycie pamięci co zmniejsza wymogi jej administracji, co umożliwia obsłużenie większej liczby użytkowników. Środowisko “serwera wspólnego” wymaga obecności następujących procesów:

• Proces nasłuchu sieciowego (network listener), który łączy proces użytkownika z dyspozytorem lub określonym serwerem (ten proces jest składnikiem Oracle Net Services – on nie jest elementem bazy danych Oracle)

• Jeden lub więcej procesów dyspozytora.• Jeden lub więcej wspólnych procesów serwera.

• Dyspozytor (Dispatcher / Dnnn)Dyspozytor wspomaga środowisko serwera wspólnego pozwalając procesom użytkowników na dzielenie się ograniczoną liczbą procesów serwera bazy danych. Wspólny serwer umożliwia obsługę większej ilości użytkowników, szczególnie w środowisku klient/serwer, w którym aplikacja klienta oraz serwer bazy danych są zainstalowane na innych komputerach. Ty możesz stworzyć wiele procesów tego typu. Te procesy startuje DBA. Ich liczba jest funkcją systemu operacyjnego, liczby połączeń każdy z nich obsługuje, itp. Administrator może zmienić ich liczbę bez potrzeby wyłączania bazy danych.

• Procesy Serwera Wspólnego (Shared Server Processes / Snnn)W środowisku wspólnego serwera, każdy proces obsługuje sesje wielu klientów. Te procesy mają taką samą funkcjonalność jak procesy dedykowanego serwera z jednym wyjątkiem – the pierwsze nie są związane z określonym procesem użytkownika. Proces serwera wspólnego obsługuje polecenia każdego klienta danego środowiska.

Procesy specyficzne do Oracle RAC to:

8

• Procesy Obsługujące Globalną Pamięć Podręczną (Global Cache Service Processes / LMSn)Procesy LMSn kontrolują przepływ komunikaty (messages) do instancji zdalnych oraz zarządzają dostępem do globalnych bloków daty. Te procesy również przesyłają kopię zawartości bloków pomiędzy buforami pamięci podręcznej różnych instancji bazy danych. Są składnikiem programu Cache Fusion. W zależności od ilości przesyłanych komunikatów, liczba n ma zakres od 0 do 9.

• Monitor Globalnego Serwisu Enqueue (Global Enqueue Service Minitor / LMON)Ten proces monitoruje globalne enqueues oraz inne zasoby w klasterze wykorzystane do globalnych operacji odzyskiwania enqueue. To są elementy pamięci wspólnej (shared memory) użyte do serializacji dostępu do zasobów bazy danych.

• Demon Obsługujący Globalne Enqueues (Global Enqueue Service Daemon / LMD))Zarządza globalnymi enqueue oraz globalnym dostępem do zasobów. W granicach instancji, proces LMD zarządza nadchodzącymi zapytaniami o użycie zasobów.

• Proces Blokujący (Lock Process / LCK)Zarządza zasobami nienależącymi do Cache Fusion takimi jak polecenia w kierunku biblioteki oraz rzędów pamięci podręcznej.

• Demon Diagnozowalności (Diagnosability Daemon / DIAG)Zbiera i gromadzi informację niezbędną do diagnozy przyczyn awarii procesów w środowisku danej instancji bazy danych. Ten demon działa automatycznie. Jego akcje są wpisywane do dziennika błędów (error log).

Figura 1-2 Procesy Specyficzne dla instancji Oracle RAC

9

1.3 Struktury Pamięci Oracle Oracle używa różnych obiektów do przechowywania i manipulowania danymi. Te obiekty to Globalny Obszar Systemowy (System Global Area) (SGA) oraz Program Global Area (PGA1).**** Oracle SGA jest wspólnym obszarem pamięci wykorzystanym do przechowywania daty oraz elementów kontrolujące bazę danych. W AIXie, detale tego typu pamięci mogą być wyświetlane wydając polecenie ipcs -ma. Oracle SGA i związane z nią procesy (background processes) są znane jako instancja bazy danych. Instancja bazy danych jest identyfikowana przy pomocy krótkiego imienia - SID. Wszystkie procesy bazy danych związane z daną instancją używają tego samego SID. W celu połączenia się z wybraną instancją bazy danych należy przyznać zmiennej $ORACLE_SID odpowiedni SID lub należy użyć ten SID w poleceniu “connect” otoczenia SQL*Plus. Każda instancja bazy danych ma swój indywidualny obszar pamięci SGA, który jest jej przyznany w chwili jej startu i który zostaje jej odebrany w chwili jej wyłączenia. Oracle administruje SGA działających instancji bazy danych. Informacja zawarta w SGA jest logicznie podzielona na trzy do pięciu obszarów takich jak: pamięć podręczna bufora bazy danych (database buffer cache), bufor dziennika powtórzeń (redo log buffer), pula wspólna (shared pool), pula Javy (Java pool) oraz duża pula (large pool).

Figura 1-3 Struktura Pamięci Oracle

1 PGA – rejon pamięci zawierający dane i informację kontrolującą jednego procesu (serwer lub proces tła). PGA jest przyznane w chwili połączenia użytkownika z bazą danych – w momencie powstania sesji. Każdy proces ma swój prywatny PGA, który może być manipulowany tylko przez polecenia Oracle działające dla danego procesu.

10

Pamięć podręczna bufora bazy danych (database buffer cache) składa się z bloków daty bazy danych Oracle oraz buforów, których zawartość została odczytana z dysków i umieszczona w pamięci. Te bufory są klasyfikowane jako wolne (free), brudne (dirty) czy używane (pinned) i są organizowane w dwóch listach: lista buforów do zapisania oraz lista LRU2. Bufory wolne to bufory gotowe do użytku, których zawartość nie została jeszcze zmodyfikowana. Bufory brudne są przechowywane na liście buforów do zapisania – one zawierają zmodyfikowane dane, które nie zostały jeszcze wpisane do dysku. Bufory używane to bufory aktualnie będące w użyciu.

Oracle używa algorytmu LRU do migracji brudnych bloków z pamięci do dysku. Informacja o stanie buforów nadających się do użytku i ich kondycja (brudne, wolne lub używane) utrzymywana jest w obiektach znanych jako listy LRU. Data, która nie jest często manipulowana jest przesunięta na koniec listy LRU. W przypadku braku wolnych buforów Oracle proces DBWn wpisze tą daną do dysków. Zwolniona w ten sposób pojemność zostanie oddana do dyspozycji listy wolnych buforów. Strony brudne najprawdopodobniej zostają wpisane do dysku długo za nim osiągną one koniec listy LRU.

Rozmiar bufora pamięci podręcznej bazy danych jest określony w czasie jej startu przez kombinację jej kilku parametrów. Baza danych może posiadać bloki o różnych rozmiarach przywiązując do nich odpowiedniej wielkości pamięć podręczną (cache). Parametr DB_BLOCK_SIZE reprezentuje wartość domyślną bloku daty, a parametr DB_CACHE_SIZE ustala rozmiar pamięci podręcznej używając bloków o wielkości DB_BLOCK_SIZE. Do określenia bloków innych rozmiarów służy parametr DB_nK_CACHE_SIZE, gdzie “n” ma zakres 2KB do 32KB. Administrator Bazy Danych może zmienić wartości tych parametrów nawet po starcie bazy danych z wyjątkiem parametru DB_BLOCK_SIZE, który wymaga stworzenia nowej bazy danych. Wybór wartości tych parametrów wymaga dużej uwagi oraz uwzględnienia możliwości montażu folderów AIXu w systemie DIO/CIO, które są omówione w rozdziale 2.4.5.

Jeżeli pozwolono Javie na działania w danej instancji bazy danych to pula (pool) Javy przechowuje jej kod razem z informacją na temat jej klas.

Bufory dzienników powtórzenia (redo logs) są użyte do przechowania informacji o zmianach danych bazy danych. Ta informacja może zostać użyta do rekonstrukcji bazy danych w przypadku jej awarii. Proces LGWR jest odpowiedzialny za kopiowanie zawartości buforów dzienników powtórki (redo log) do bieżących dzienników powtórzeń (online redo logs). Rozmiar bufora dziennika powtórzeń jest określony parametrem LOG_BUFFER znajdującym się w pliku inicjalizującym parametry bazy danych.

Obszar pamięci wspólnej przechowuje elementy takie jak wspólne obszary SQL, prywatne obszary SQL, pamięć podręczna słowników danych (data dictionaries) i jeżeli duży obszar pamięci nie istnieje to również przechowywane są tam bufory wiadomości równoległych egzekucji. Wspólnie używane obszary SQL zawierają plan wykonania poleceń SQL oraz drzewo genologii gramatycznej. Identyczne polecenia SQL dzielą się planami wykonania poleceń. Identyczne polecenia JĘZYKA MANIPULACJI DANYMI (DATA MANIPULATION LANGUAGE / DML) mogą dzielić się tym samym rejonem pamięci co redukuje jej zapotrzebowanie. Deklaracje DML są poleceniami SQL takimi jak SELECT, UPDATE, INSERT i DELETE używanymi do inwestygacji (query) i manipulacji danych przechowywanych w bazie danych. Prywatne obszary SQL zawierają informację wiążącą (bind) Oracle i jej bufory run-time. Informacja wiążąca zawiera aktualne wartości zmiennych użytkownika zawartych w pytaniach (query) SQL.

Bufor podręczny słownika danych (data dictionary cache) przechowuje informację związaną z Oracle słownikiem danych. Ten słownik jest planem i mapą struktury bazy danych. Zawarta w nim informacja jest używana przez Oracle w czasie analizy składniowej instrukcji SQL.

Bufory operacji równoległych (parallel execution) przechowują informację niezbędną do synchronizacji operacji bazy danych wykonywanych równolegle. Kiedy duży zbiornik (large pool) nie jest skonfigurowany to te bufory otrzymują pamięć ze zbiornika głównego.

Duży zbiornik (large pool) jest opcjonalnym obszarem pamięci używanym w przypadku dużego użycia i związanego z tym brakiem pamięci wspólnej (shared memory). W tym zbiorniku przechowuje się informację taką

2 LRU – least recently used

11

jak interfejs Oracle XA (element Oracle pozwalający na użycie transakcji rozproszonych (distributed transactions)), procesy I/O serwera bazy danych oraz jeżeli wartość atrybutu inicjalizującego PARALLEL_AUTOMATIC_TUNING wynosi TRUE, to również jest tam przechowywany wcześniej wspomniany bufor egzekucji równoległej. Duży zbiornik (large pool) jest aktywowany, kiedy wartość LARGE_POOL_SIZE > 0.

Zaczynając od Oracle 9i mamy do czynienia z nowym elementem zwanym Dynamiczny Globalny Obszar Systemowy (Dynamic SGA). Ten element pozwala instancji bazy danych na dynamiczne zmienianie wartości parametrów kontrolujących SGA. Pozwala on również zmienić wielkość pamięci fizycznej używanej przez Oracle bez potrzeby zatrzymania bazy danych - ponieważ DBA może teraz zmienić wielkość SGA aktywnej bazy danych wydając polecenie ALTER SYSTEM. Jest to również możliwe do wykonania w przypadku Oracle 10g i 11g.

Oracle PGA (Program Global Area) jest zbiorem obszarów pamięci nienależących do obszaru pamięci wspólnej, z których przechowywane są dane oraz informacja kontrolująca indywidualnego procesu usługowego bazy danych. W chwili startu, proces usługowy zostaje związany z obszarem pamięci PGA. Ten obszar PGA może być użyty wyłącznie przez proces, któremu został on przyznany. Mówiąc ogólnie, PGA zawiera część prywatną SQL (przechowuje informację wiążącą (bind) oraz elementy run-time związane ze wspólnymi obszarami SQL), oraz pamięć należąca do danej sesji razem z jej specyficznymi zmiennymi jak na przykład informacja typu logon. W przypadku korzystania z architektury współdzielonego procesu usługowego (shared server, MTS), proces usługowy i związane z nim obszary pamięci PGA mogą być użyte do obsługi procesów wielu klientów.

PGA może również być użyte jako miejsce pracy skomplikowanych zapytań (queries) używających operatorów wymagających znacznych ilości pamięci takich jak:

• Operacje typu SORT jak na przykład ORDER BY, GROUP BY, ROLLUP oraz WINDOW• HASH JOINS• BITMAP MERGE• BITMAP CREATE

PGA jest administrowana automatycznie po połączeniu się sesji użytkownika z dedykowanym serwerem Oracle. DBA musi tylko określić wartość docelową pamięci przeznaczonej do obsługi tego serwisu używając do tego celu zmienną inicjalizującą PGA_AGGREGATE_TARGET. Pamiętaj, że wartość PGA_AGGREGATE_TARGET jest tylko wartością zamierzaną. W niektórych okolicznościach, pamięć zużyta przez wszystkie PGA może być dużo większa od wartości określonej tym parametrem.

2. Konfiguracja i Strojenie AIXu dla ORACLE

Zrzeczenie od odpowiedzialności: Prezentowane w tym dokumencie sugestie należy rozumieć jako podstawowe elementy strojenia lub jako punkt początkowy tego procesu - w przypadku typowych instalacji Oracle. Rodzaj instalacji każdego klienta jest inny. Ciągłe śledzenie wydajności i strojenie systemu jest niezbędne do osiągnięcia przez niego optymalnego poziomu.

Ta sekcja zawiera informację na temat elementów administracji systemów AIX mających coś wspólnego ze środowiskiem bazy danych Oracle. Omawiane tutaj elementy są niezbędne do zabezpieczenia dobrych warunków pracy bazy danych i jej środowiska. Pokazane tutaj elementy należy sprawdzić przed rozpoczęciem szczegółowego strojenia bazy danych.

Ponieważ poprawnie skonfigurowany VMM (Virtual Memory Manager / Manager Pamięci Wirtualnej) jest podstawowym wymogiem dobrze pracującej bazy danych, zaczniemy naszą dyskusję omawiając jego funkcję oraz metody strojenia jego elementów.

2.1 Wprowadzenie do Managera Pamięci Wirtualnej (VMM)

VMM obsługuje wymogi pamięci systemu operacyjnego i używających go aplikacji. Segmenty pamięci wirtualnej są dzielone na jednostki zwane stronami. Strony znajdują się w pamięci fizycznej (RAM) lub są ‘paged out’ i przechowywane na dysku (ich wartość i adres) do momentu, w którym są potrzebne – zwalniając przez to

12

pamięć, która zostaje przydzielona innym procesom. AIX używa pamięci wirtualnej, ponieważ to umożliwia adresowanie większej ilości pamięci niż fizycznie obecnej w maszynie. VMM zarządza stronami pamięci w RAM i na dyskach.

Wirtualne adresy są podzielone na segmenty. Segmentu to nieprzerwane 256MB przestrzeni pamięci wirtualnej, do której można wpisać datę. Związek pomiędzy procesem a jego datą jest zarządzany na poziomie segmentu co umożliwia użycie segmentu przez kilka procesów (segment publiczny) oraz pozwala to również na ograniczenie użycia segmentu do jednego procesy (segment prywatny). Na przykład, proces może dzielić się segmentem kodu i również posiadać indywidualne i prywatne segmenty danych.

2.1.1 Zarządzanie Pamięcią

Segmenty pamięci wirtualnej są dzielone na tego samego rozmiaru strony. AIX 5.3 ML04 (lub wersje późniejsze) operujący na POWER5+ (lub późniejszej wersji procesorów typu POWER) pozwala na ustalenie rozmiaru strony o następujących wartości: 4KB, 64KB, 16MB o 16GB. Zadaniem VMM jest zarządzanie stronami pamięci rzeczywistej i rozwiązanie zależności pomiędzy programem a stronami pamięci wirtualnej, które nie są jeszcze obecne w pamięci rzeczywistej, lub które nie zostały jeszcze stworzone (na przykład, kiedy program po raz pierwszy woła swoją stronę segmentu daty).

Ponieważ rozmiar używanej pamięci wirtualnej może być większy od zainstalowanego RAMu, VMM musi przechowywać jej nadmiar na dysku/dyskach (stronicowanie/paging). Z punktu widzenia wydajności systemu, VMM ma dwa sprzeczne ze sobą zadania:

• Ograniczenie do minimum kosztów użytku pamięci wirtualnej w jednostkach czasu użycia CPU i I/O dysków.

• Ograniczenie do minimum kosztów związanych z błędami braków stron (page fault).

Do tego celu, VMM utrzymuje listę wolnych segmentów stron gotowych na zaspokojenie wymagań pamięci procesów.Używając algorytmu wymiany stron VMM ustala, które segmenty stron pamięci wirtualnej obecnie przebywającej w pamięci (RAM) można przesunąć do listy segmentów wolnych. Ten algorytm pracuje w następujący sposób:

• Segmenty pamięci wirtualnej są klasyfikowane jako segmenty zawierające instrukcje programu (computational) lub jako segmenty zawierające jego datę (file).

• Obserwuje się strony pamięci wirtualnej, do których dostęp powoduje błąd braku strony.• Page faults są kwalifikowane jako nowe (new page faults) lub ponowne błędy braku strony(re-page

faults).• Algorytm utrzymuje statystykę częstotliwości ponownych błędów braku strony każdego segmentu

pamięci wirtualnej.• Decyzje tego algorytmu są uzależnione od wartości parametrów systemu operacyjnego i bazy danych,

które mogą być modyfikowane przez użytkownika.

Następujące sekcje opisują bardziej szczegółowo listę wolnych segmentów oraz mechanizm użyty do manipulacji stron pamięci.

2.1.2 Lista Wolnych Segmentów

VMM utrzymuje i zarządza logiczną listę wolnych segmentów stron, które używane są do łagodzenia efektów błędów braku stron. W większości przypadków, VMM od czasu do czasu musi, zwiększyć ilość wolnych segmentów obecnych na liście co robi zabierając je wybranym procesom. VMM używając do tego celu odpowiedniego algorytmu (page-replacement algorithm) decyduje, które segmenty stron pamięci wirtualnej będą przyznane innym procesom. Liczba stron zmieniających właścicieli jest funkcją specyficznych parametrów VMM.

2.1.3 Segmenty Długotrwałe versus Segmenty Pracujące

Każda strona segmentów długotrwałych (permanent) jest związana z określonymi blokami fizycznymi dysku

13

(physical partitions). Zawartością tego rodzaju segmentów są pliki wykonywalne programu (executable) oraz pliki zawierające jego dane. Ponieważ każda strona segmentu długotrwałego jest związana z określonym położeniem na dysku, w przypadku zmiany zawartości tej strony lub kiedy nie może ona być dłużej przechowywana w pamięci, VMM wpisze jej zawartość z jej przydzielonego obszaru na dysku. Umieszczenie na liście stron wolnych tej strony, której zawartość nie uległa zmianie nie wymaga I/O. W czasie późniejszym, ponowna referencja tej samej strony powoduje czytanie jej zawartości z miejsca jej pobytu stałego - dysku.

Segmenty pracujące są nietrwałe i nie mają stałego położenia na dysku. Używający ich proces decyduje, kiedy one powstają i kiedy one giną. W segmentach pracujących są przechowywane takie elementy procesu jak jego stos (stack) oraz segmenty pracujące. Można w nich również znaleźć segmenty tekstu jądra systemu operacyjnego oraz tekst i segmenty daty wspólnych bibliotek (shared libraries). Strony segmentów pracujących, które nie mogą być przechowywane w pamięci również są wpisywane do określonych bloków na dyskach. Do tego celu służy przestrzeń stronicowania.

Następna ilustracja pokazuje związek pomiędzy niektórymi typami segmentów i położeniem ich stron na dysku. Ta sama ilustracja pokazuje aktualne (przypadkowe) położenie stron w chwili kiedy one znajdują się w pamięci rzeczywistej (RAM).

Figura 1-4 Segmenty Długotrwałe i Pracujące

Segmenty długotrwałe można podzielić na:Segmenty klienta używane do:

• określenia (mapping) położenia plików odległych (na przykład, pliki dostępne dzięki NFS), włącznie z odległymi programami wykonywalnymi (remote executables). Strony związane z segmentami klientów są chronione i odzyskiwane via sieć do ich stałych lokacji, a nie do tomów stronicowych (paging space) lokalnej maszyny.

• mapowania położenia plików lokalnych znajdujących się w folderach typu JFS2 lub Veritas.

Segmenty nienależące do klientów są używane do:

• określenia położenia plików lokalnych przebywających w folderach typu JFS.

Segmenty dziennikowe (journaled) i odłożone (deferred) to segmenty stałe (persistent), które muszą być automatycznie aktualizowane. Jeżeli strona segmentu dziennikowego lub odłożonego zostaje przeznaczona na usunięcie z pamięci rzeczywistej (paged out) to zostaje ona zapisana do tomu stronicowego, chyba że jej stan pozwala na jej zatwierdzenie (commit) czyli na jej wpisanie do jej stałego pliku.

14

2.1.4 Pamięć Obliczeniowa versus Pamięć Plikowa

Pamięć obliczeniowa (computational memory) znana również jako strony obliczeniowe składa się ze stron należących do segmentów pracujących oraz segmentów tekstu programu (pliki egzekwowane (executable files)). Pamięć plikowa (czy strony plików) składa się ze stron pozostałych. Z reguły, te strony pochodzą ze stałych plików danych przechowywanych na dyskach.

2.1.5 Wymiana Stron

Obniżenie liczby nadających się do użytku klatek (frames) pamięci (RAM) na liście klatek wolnych (free list) poniżej pewnego określonego poziomu kończy się włączeniem złodzieja stron (page stealer). Ten złodziej przegląda Tablice Ram Stron (Page Frame Table/PFT) szukając stron nadających się do “kradzieży”. Tablica PTF zawiera flagi sygnalizujące czy dana strona pamięci była wspomniana (przez proces) lub, czy jej zawartość uległa zmianie. Złodziej nie kradnie strony wspomnianej, ale usuwa flagę sygnalizującą ten fakt. Złodziej “ukradnie” tę stronę, jeżeli przy ponownej inspekcji PTF wartość tej flagi nie uległa zmianie. Strony, które nie były wspomniane podczas pierwszej inspekcji zostają natychmiast kradzione. Flaga zmiany zawartości strony wskazuje zmianę zawartości od momentu wpisania strony do pamięci. Jeżeli strona jest kandydatką na kradzież a jej flaga zmiany zawartości wskazuję ten fakt to przed jej kradzieżą złodziej przywołuje do akcji funkcję kopiującą jej zawartość do pliku stronicowania (pageout). Strony będące częścią segmentów pracujących są zapisane do obszaru stronicowania zaś segmenty długotrwałe zostają wpisane do dysku.

Figura 1-5 Przykład Wymiany Stron

Powyższa ilustracja zawiera wyjątki z trzech tablic. Pierwsza tablica jest tablicą ram stron z czterema kolumnami zawierającymi adresy rzeczywiste, typ segmentu, flagę referencji oraz flagę modyfikacji. Druga tablica nazywa się tabelą wolnych stron i zawiera ona adresy wszystkich wolnych w danym momencie stron. Ostatnia tablica reprezentuje sobą tablicę klatek stron będącą rezultatem usunięcia wszystkich wolny adresów.

Algorytm nie tylko zajmuje się wymianą stron (page-replacement) ale także śledzi on nowe błędy (page faults) (wspomniane po raz pierwszy) oraz błędy ponowne (re-page) czyli wspominanie stron, które zostały już zapisane w obszarze stronicowania (paging space) lub do odpowiednich plików na dyskach używając do tego celu buforu historycznego zawierającego numery identyfikujące (ID) najnowszych page faults. Ten algorytm stara się zrównoważyć page outs plików (długotrwałe dane) z obliczeniowymi page outs. W przypadku AIX 6.1 wartość domyślna parametru jądra systemu operacyjnego odpowiadającego za tę równowagę wynosi 0 (lru_file_repage=0) co sygnalizuje jego wyłączenie.

15

Po zakończeniu procesu, jego nośnik danych pracujących (working storage) oraz związana z nim pamięć (strony pracujące) są natychmiastowo zwalniane a związane z nimi ramy (klatki) pamięci są natychmiastowo zwracane do list ram wolnych. Wszystkie ramy pamięci oddane do użycia plikom otwartym przez zakończony proces pozostają dalej w użyciu zakładając, że inny proces w najbliższej przyszłości może je potrzebować.

W przypadku maszyn posiadających więcej niż jeden CPU, wymiana stron jest dokonana przez proces kernela o nazwie lrud, który jest wysłany do CPU po osiągnięciu przez system progu oznaczonego wartością parametru minfree. W przypadku AIXu 5L, lrud jest procesem wielowątkowym (multithreaded) z jednym zbiornikiem pamięci (memory pool) przypadającym na jeden wątek. Pamięć fizyczna jest podzielona na jeden lub więcej zbiorników (pools), których liczba jest funkcją ilości CPU oraz ilości pamięci przyznanej partycji. W celu określenia liczby tych zbiorników pamięci należy wydać polecenie “echo mempool \* | kdb”.Jak opisano powyżej, do AIX 5.3.0, omówiona poprzednio metoda oparta na tablicach ram stron była jedyną możliwą metodą. Ta wersja AIXu wprowadziła LRU dla AIX Menażera Obciążenia Pracą (AIX Workload Manager)opartą na liście (spis). Ta cecha była domyślnie aktywna do czasu uniezależnienia LRU na Menażera Obciążenia Pracą (WLM). AIX 5.3.0 TL04 wprowadził LRU oparty na listach, którego praca nie wymaga działającego WLM.Algorytm oparty na liście jest wyposażony w listę stron do przeglądu dla każdego rodzaju segmentu. Przełączenie LRU z tego opartego na liście na ten oryginalny oparty na inspekcji fizycznych adresów jest możliwe dzięki poleceniu vmo i jego atrybutowi page_steal_method. W AIX 5.3 wartość domyślna page_steal_method wynosi 0, co znaczy, że LRU opierające się na liście jest wyłączone a w jego miejsce używane jest LRU oparte na inspekcji fizycznych adresów. Jeżeli page_steal_method=1 (wartość domyślna w AIX 6.1) to znaczy, że do inspekcji stron używane są listy. Aktualizacja zmiany wartości page_steal_method wymaga restartowania maszyny.

Figura 1-6 Legacy page_steal_method=0 versus oparta na liście page_steal_method=1(w/s – strony pracujące)

2.1.6 Stronicowanie Powtórne (repaging)

Błąd braku strony jest rozumiany jako nowy błąd braku strony lub jako błąd powtórny. Mamy do czynienia z nowym błędem braku strony, kiedy nie istnieje informacja of jej użyciu. Powtórny błąd braku strony występuje, jeżeli taka wzmianka istnieje. Mamy do czynienia z błędem powtórnym (repage fault) kiedy poprzednio wspomniana strona zostaje ponownie wspomniana i nie można znaleźć jej w pamięci od chwili jej ostatniego

16

użycia, ponieważ jest już zastąpiona czy nawet jej zawartość została poprzednio wpisana do dysku.

Doskonała polisa wymiany stron (page-repacement policy) byłaby w stanie całkowicie wyeliminować błędy ponownego braku stron (repage) (zakładając odpowiednią ilość RAM) zawsze kradnąc ramy stroną, które nie będą już więcej wspomniane. Dlatego, liczba błędów powtórnych jest odwrotnością efektywności algorytmu wymiany stron (page-replacement algorithm) przechowującego w pamięci strony często używane obniżając wymagania I/O i tym samym poprawiają ogólną wydajność systemu.

W celu kategoryzowania błędu braku strony jako błędu nowego lub powtórnego (repage), VMM posiada specjalny “historyczny” bufor zawierający numery identyfikacyjne ostatnich N błędów braku stron, gdzie N jest liczbą ram stron, które mogą być przechowane w pamięci. Na przykład, 512MB pamięci wymaga bufor historyczny o pojemności 128KB. W chwili page-in, jeżeli number identyfikacyjny strony jest znaleziony w tym buforze, to liczy się to jako repage. VMM dla każdego rodzaju pamięci, osobno szacuje ratę repage pamięci obliczeniowej oraz ratę repage pamięci plików. W momencie egzekucji algorytmu wymiany stron te raty są mnożone przez 0.9, żeby podkreślić ich wartość obecną, a nie ich historyczną perspektywę.

2.2 Pamięć i Stronicowanie

Intencje VMM są ustalane przy pomocy parametrów i ich wartości granicznych (thresholds). Kiedy wartość parametru osiągnie lub przekroczy wartość jej progu, VMM podejmuje odpowiednie kroki w celu przywrócenia pamięci do odpowiedniego stanu. Ta sekcja dyskutuje parametry, których wartości graniczne można zmienić używając do tego celu polecania vmo.

2.2.1 Koncept Parametrów Ograniczonego Dostępu (Restricted Tunables) w AIXie 6.1

Począwszy od wersji 5.3, AIX posiada sześć poleceń (vmo, ioo, schedo, raso, no i nfso) do strojenia systemu operacyjnego z punktu widzenia jego obciążenia (workload). Począwszy z AIX 6.1 niektóre z parametrów są znano jako parametry ograniczonego dostępu (restricted tunable). Wartości domyślne tych parametrów są uznane za optymalne dla większości użytkowników. Ich modyfikacja powinna być dokonana tylko na polecenie IBM.

Do wyświetlenia wartości parametrów ograniczonego dostępu należy użyć opcji -F (force) razem z -a, -L czy -x. Wartość wybranego parametru ograniczonego dostępu może być również wyświetlona beż opcji -F w przypadku podania jego nazwy w związku z odpowiednią opcją modyfikacyjną.

2.2.2. Pamięć Wolna AIXu

W przypadku AIX, pamięć jest reprezentowana hierarchicznie w postaci struktur danych takich jak vmpool, mempool oraz frameset. Vmpool reprezentuje domenę pokrewieństwa (affinity domain) pamięci. Vmpool jest podzielony na wiele mempools, każdy z nich administrowany przez indywidualny demon najdawniej użytej strony (LRU – least recently used). W celu polepszenia skalowalności alokatorów (allocator) ram wolnych, każdy pula pamięci (mempool) jest dzielona na jedną lub więcej pul klatek/ram (framesets) zawierających listy ram wolnych (free frames).

Ilość wolnych klatek stron na liście wolnych jest zarządzana indywidualnie dla każdego zbiornika pamięci (memory pool) – kontrolują ją następujące wartości graniczne następujących parametrów:

• minfree• najmniejsza akceptowana liczba klatek pamięci rzeczywistej na liście klatek wolnych (free list).

Jeżeli rozmiar listy wolnych klatek spadnie poniżej tej wartości, VMM zaczyna kradzież stron. Kradzież stron trwa do momentu, w którym rozmiar listy klatek wolnych osiągnie wartość określoną parametrem maxfree.

17

• maxfree• maksymalny rozmiar listy wolnych stron pamięci osiągnięty dzięki kradzieży stron przez VMM.

Rozmiar listy stron wolnych może przekroczyć tę wartość w rezultacie zakończenia procesów i zwolnienia ich stron segmentów pracujących lub wymazania ich plików przechowywanych w pamięci.

Użyte jednostki to liczba 4 kilobytowych stron pamięci.

We wcześniejszych wersjach AIXu (5.2 oraz 5.1), nawet w przypadku obecności wielu zbiorników pamięci (memory pools) wartości minfree oraz maxfree dotyczą całego systemu. Dlatego, całkowita liczba stron listy stron wolnych jest zazwyczaj >= minfree.

W przypadku AIX 5.3 i 6.1 progi minfree oraz maxfree dotyczą indywidualnych zbiorników pamięci. Kiedy liczba wolnych stron danego zbiornika spadnie poniżej wartości minfree to LRU demon tego zbiornika pamięci zacznie zwalniać jego strony do momentu osiągnięcia w tym zbiorniku poziomu określonego przez maxfree. Z tego powodu, lista wolnych stron >= (minfree * liczba memory pools).

Do zmiany wartości minfree oraz maxfree służy polecenie vmo. Mówiąc ogólnie chcemy, żeby wartość minfree była na tyle duża, że lista wolnych stron nigdy nie jest całkowicie wykorzystana co w przypadku zapotrzebowania na nowe strony pozwala na uniknięcie konieczności użycia lrud i jego mechanizmu kradzieży stron. Różnica pomiędzy maxfree oraz minfree powinna być tak duża, że nie ma potrzeby na zatrudnienie demona lrud.

Polecane wartości początkowe parametrów minfree oraz maxfree są ustalane w następujący sposób:

Wartości Początkowe dla AIX 5.3 i 6.1 Wartości Początkowe dla AIX 5.2

minfree = nie zmieniaj początkowej wartości minfree = max (960, lcpus 8 120)maxfree= nie zmieniaj początkowej wartości maxfree = minfree + (Max Read Ahead * lcpus)

gdzie,

Max Read Ahead – max (maxpgahead, j2_maxPageReadAhead)(*) jeżeli pracuje SMT, lcpu=2 * liczba procesorów fizycznych (CPU)

2.2.3 Wielkość Pamięci Podręcznej Folderów Systemu (file system cache) AIXu

W przypadku, kiedy źródłem obciążenia systemu jest baza danych Oracle, musimy być pewni, że strony obliczeniowe używane przez wykonywalny kod obiektowy (executable) Oracle, Oracle SGA, PGA, i tak dalej, są zawsze obecne w pamięci. Również, skoro bufory własne bazy danych Oracle buforują jej własne pliki “dbf”, buforowanie systemów plikowych (file systems) przez AIX jest w widoczny sposób czymś zbędnym czy wręcz niepotrzebnym. Z tego powodu, system administrator powinien użyć te polisy VMM, które preferują strony obliczeniowe, a nie strony buforów systemów plikowych.

Nadmierne przydzielenie pamięci fizycznej może być przyczyną nadmiernej aktywności stronicowej co w znaczny sposób obniża wydajność systemu. W przypadku środowiska Oracle o ograniczonej pamięci, możemy zmniejszyć efektywną pojemność buforów plików systemu (w celu zmniejszenia wymagań pamięci fizycznej) bez negatywnego wpływu na wydajność I/O bazy danych. W takiej sytuacji, duża liczba buforów SGA może również posiadać odpowiedniki w buforach plików systemowych zawierających najczęściej wspominane (używane) dane. Zachowanie buforów plików systemu AIXu ma poważny wpływ na wydajność systemu. W AIXie można stroić bufory pamięci podręcznej związanej ze stronicowaniem (buffer-cache paging), ale musi być robione ostrożnie i rzadko.

Optymalny rozmiar pamięci podręcznej plików systemu jest funkcją obciążenia, charakterystyki I/O bazy danych oraz tym czy ona używa JFS(2) czy tomów logicznych (logical volumes). W przypadku użycia DIO czy CIO,

18

system operacyjny nie używa buforów plików systemu (file systems) do obsługi działalności związanej z plikami .dbf czy online redo logs bazy danych.

Następujące wartości progowe są wyrażone jako procenty. Przedstawiają sobą część rzeczywistej pamięci maszyny (RAM) zajętej przez strony plików (strony dla segmentów nieobliczeniowych (non-computational segments)).

• minperm%• jeżeli procent pamięci rzeczywistej zajmowanej przez strony plików (numperm%, numclient%)

spadnie poniżej wartości MINPERM to algorytm wymiany stron (page-replacement) niezależnie od raty tej kradzieży czy wartości parametru lru_file_repage będzie kradł strony plików oraz strony obliczeniowe.

• maxperm%• jeżeli procent pamięci rzeczywistej zajęty przez strony plików (numperm%) przekracza

MAXPERM to algorytm wymiany stron kradnie tylko strony plików.

• maxclient%• jeżeli procent pamięci rzeczywistej zajęty przez strony plików klientów (numclient%) przewyższa

wartość MAXCLIENT to algorytm wymiany stron kradnie tylko strony klientów• maxcleint% <= maxprerm (maxperm% zawiera maxclent%)

• minperm%<>maxperm%• jeżeli wartość procentu pamięci rzeczywistej zajmowanej przez strony plików (numperm%) jest

pomiędzy MINPERM i MAXPERM to VMM kradnie tylko strony plików, ale w przypadku kiedy rata odzyskiwania stron plików jest większa od raty odzyskiwania stron obliczeniowych to te strony są również kradzione. Rata odzyskiwania stron nie jest brana pod uwagę w przypadku lru_file_repage=0 – w tym przypadku kradzione są tylko strony plików.

Prosty sposób zapamiętania tych reguł: AIX próbuje utrzymać wielkość pamięci podręcznej buforów plików systemu (numperm) pomiędzy minperm% a maxperm% procentu pamięci rzeczywistej. Do określenia i zmiany wartości minperm%, maxperm% oraz maxclient% używaj polecenia “vmo”. To polecenie pokazuje wartości tych parametrów jako procenty pamięci rzeczywistej. Pokazuje ono również całkowitą liczbę 4kb stron (minperm, maxperm i maxclient). Do wyświetlenia wartości minperm%, maxperm% i maxclient% można również użyć polecanie “vmstat -v”. Tp polecenie pokazuje obecną liczbę stron pamięci plików i klientów (numperm%, numclient%) jak również obecny procent pamięci zajętej przez te strony.

W przypadku bazy danych Oracle, wartości typowych parametrów VMO wynoszą:

• lru_file_repage=0 (w AIX 5.2/5.3 wartość domyślna wynosi 1, w przypadku AIX 6.1 wynosi ona 0)• Ten parametr został wprowadzony w użycie w ML4 AIX 5;2 oraz ML1 AIX5.3• On sugeruje VMM czy podejmując decyzje o kradzieży pamięci należy wziąć pod uwagę

wartość licznika re-page.

• minperm%=3 (wartość domyślna w AIX 5.2/5.3 wynosi 20 a w przypadku AIX6.1 zaś 3)• minimalny procent pamięci fizycznej wykorzystanej jako pamięć podręczna plików systemu (file

systems cache)• minperm%<numperm% (sprawdź produkt polecenia vmstat -v)

• maxperm%=90 (wartość domyślna w AIX 5.2/5.3 wynosi 80 oraz 90 w przypadku AIX 6.1)• maksymalny procent pamięci fizycznej użytej jako pamięć podręczna plików systemowych.• maxperm%>=maxclient%>=numclient% (sprawdź co pokazuje vmstat -v)• Przed AIX 5.3 przyznanie dużej wartości pamięci podręcznej plików systemu może obniżyć

wydajnością systemu. W przypadku partycji używających AIX 5.2 (lub wersję wcześniejszą) posiadających więcej niż 25GB pamięci fizycznej, należy zmniejszyć maxperm% tak, że

19

maksymalna wartość pamięci podręcznej plików jest <=20GB. Na przykład, jeżeli system ma 50GB pamięci, to maxperm% powinno być ustawione na 40 lub mniej oraz strict_maxperm=1.

• strict_maxperm=0 (wartość domyślna w AIX 5.2/5.3/6.1)• Pozwala/Nie pozwala na traktowane maxperm jako “twardy” (niemożliwy do modyfikacji) limit.• Przed AIX 5.3 duża pojemność przyznana pamięci podręcznej plików systemu może być

przyczyną obniżonej wydajności maszyny i jej aplikacji. W przypadku lparów z zainstalowanym AIX 5.2 (lub wersją wcześniejszą) z >25GB pamięci fizycznej, należy zmniejszyć maxperm% tak, że maksymalna wartość cache plików systemowych jest <=20GB. Jeżeli to jest zrobioine, to wartość strict_maxperm powinien być równa 1 w celu narzucenia twardych limitów na maxperm%.

• Zmiana wartości tego parametru powinna być dokonana pod ścisłym nadzorem zespołu pomocy (support team) IBM.

• maxclient%=90 (w AIX 5.2/5.3 wartość domyślna wynosi 80, w AIX 6.1 wynosi ona 90)• Maksymalna wartość docelowa procentu pamięci fizycznej użytej jako pamięć podręczna plików

systemu JFS2 i NFS.• maxclient% powinien zwykle równać się maxperm%. Zmianie wartości maxpem% powinna

towarzyszyć zmiana wartości maxclient%.

• strict_maxclient=1 (wartość domyślna AIX 5.2/5.3/6.1)• Pozwala/Niepozwala na narzucenie maxclient% jako “twardy” limit (ważne: wartość tego

parametru może być zmieniona, ale należy to robić bardzo ostrożnie ze względu na potencjalny wpływ tej akcji na zużycie pamięci).

• Mając wartość 0, chroni pamięć obliczeniową – kradzione są wyłącznie strony pamięci plikowej.• Zmiana wartości tego parametru powinna być dokonana pod ścisłym nadzorem zespołu pomocy

IBM.

• page_steal_method=1 (wartość domyślna w AIX6.1, w przypadku AIX5.3/5.2 wynosi ona 0)• W AIX 5.3 algorytm LRU może użyć nie tylko listę stron, ale również tablicę ram stron. Przed AIX

5.3 jedyną możliwą metodą była użycie tablicy ram stron (page frame table). Algorytm opierający się na liście wprowadza listę stron do przeglądnięcia dla każdego rodzaju segmentu.

2.2.4 Pokrewieństwo Pamięci (Memory Affinity)

Systemy IBM POWER oparte na SMP zawierają podwójne, poczwórne lub wieloskładnikowe elementy (DCM/QCM/MCM), każdy zawierający wiele procesorów. Pomimo że każdy procesor ma dostęp do całej pamięci systemu, ten dostęp jest najszybszy w przypadku procesora adresującego pamięć przyłączoną bezpośrednio do jego własnego elementu wieloukładowego (multichip module). Dlatego, AIX usiłuje zadowolić błędy braku stron (page faults) używając do tego celu pamięci dołączonej do elementu wieloukładowego zawierającego procesor będący przyczyną tego właśnie błędu strony.

W środowiskach AIX5.2, w których wiele lparów istnieje na jednym systemie zarządzanym (managed system), dany lpar może mieć różnej wielkości (unbalanced) pule pamięci (memory pools). W takiej sytuacji demon LRU obsługujący mniejszą pulę pamięci jest często wołany do akcji szukając stron do zwolnienia. Tego wskaźnikiem jest wysokie tempo skanowania/uwalniania (scan/free) danego zbiornika. Tempo skanowania może być określone przy użyciu polecenia vmstat. W takim zbiorniku, AIX w celu zwolnienia stron może być zmuszony do przeniesienia do dysku (page-out) zawartości stron obliczeniowych, nawet jeżeli inne pule pamięci posiadają wolne strony.

20

Określenie czy zbiorniki pamięci są wyważone może być dokonane przy pomocy polecenie kdb:

Taką sytuację można naprawić wyłączając pokrewieństwo pamięci. Jeżeli wersja jądra AIX 5.3 jest poniżej 5.3.0.41 to polecamy jego modyfikację do najwyższego możliwego poziomu, w którym ten problem jest rozwiązany. W AIX 5.3.41+ oraz AIX6.1 zbiornik pamięci może być w dalszym ciągu niezrównoważony, ale zmiany wprowadzone w tych wersjach AIXu są w stanie zapobiec stronicowaniu.

W przypadku AIX5.2 można to osiągnąć wydając następujące polecenie:

# vmo -r -o memory_afinity=0

W tym przypadku AIX widzi pamięć jako jednolity element, w którym zbiorniki pamięci mają prawie identyczny rozmiar. Po wydaniu tego polecenia należy restartować maszynę.

2.2.5 Przyznanie stronicowaniu (paging space) odpowiedniej pojemności

Niewystarczająca pojemność stronicowania powoduje terminację procesów, zawiesza jej system operacyjny czy kończy się awarią AIX wymagającą zastartowania maszyny. W przypadku AIXu, wielkość tomów logicznych użytych do stronicowania może być zmieniona dynamicznie bez potrzeby restartowania maszyny. Wielkość tomów stronicowych jest funkcją zainstalowanej w systemie pamięci oraz wymaganiami jego aplikacji. Dobry sposób określenia początkowej wielkości tomów stronicowania to wartość połowy zainstalowanej pamięci plus 4GB. Do monitorowania stronicowania używaj polecenia lsps a do monitorowania aktywności systemu stronicowania używaj polecenia vmstat.

AIX 5L i później, używa stronicowania opóźnionego, to znaczy, że pojemność stronicowa nie jest przyznana do momentu jej aktualnej potrzeby. System używa stronicowania tylko w przypadku braku pamięci rzeczywistej (RAM). Posiadając odpowiednią ilość pamięci rzeczywistej, system nie ma potrzeby na stronicowanie, przez co rozmiar jego tomów stronicowych może być bardzo mały.

Projektując system należy dążyć do minimalizacji stronicowania. W dobrze zaprojektowanym systemie stronicowanie ma miejsce tylko w celu ochrony systemu w przypadku nagłej konsumpcji pamięci. Pamiętaj, po przeniesieniu do obszaru stronicowego (page out) strona obliczeniowa, przebywa tam tak długo, jak istnieje posiadający ją proces - nawet jeżeli z czasem jej zawartość zostaje z powrotem przeniesiona do pamięci głównej (paged in). To znaczy, że nawet w przypadku minimalnej aktywności stronicowania spowodowanej niewielkim brakiem pamięci, zużycie przestrzeni stronicowej będzie rosnąć – potencjalnie do momentu jej całkowitego zużycia.

Stałe, nadmierne stronicowanie wskazuje na brak pamięci rzeczywistej. Stronicowania należy unikać.

Następujące polecenia AIXu podają status i statystyki stronicowania:

# vmstat -s# lsps -a

21

2.2.6 Wsparcie przez AIX dla Oracle umiejętności posiadania stron o różnych rozmiarach i unieruchomionego SGA

Jak wytłumaczono w Rozdziale 2.1.1, AIX 5.3 ML04 (oraz jego następne wersje) używający procesorów POWER5+ (i późniejszych) jest w stanie obsłużyć strony pamięci o następujących rozmiarach: 4KB (mała strona), 64KB (strona średnia), 16MB (strona duża) i 16GB (strona olbrzymia). Objaśnienie sposobu zastosowania stron o rozmiarze powyżej 16GB wykracza poza ramy tego artykułu.

Aplikacje bazy danych Oracle używające dużych ilości pamięci wirtualnej oraz te, które wymagają częstego dostępu do pamięci mogą polepszyć swoją wydajność używając średnich i dużych stron razem z unieruchomieniem (pinned) SGA. Polepszenie wydajności związane z użyciem stron średnich i dużych jest osiągnięte dzięki zmniejszonej liczbie błędów TLB (translation look aside buffer). Średnie i duże strony, również usprawniają przygotowanie pamięci (memory prefetching) eliminując potrzebę rozpoczęcia tej aktywności wzdłuż granic opartych na 4KB.

Oracle 10g (<=10.2.0.3) jest w stanie użyć strony o rozmiarze 4kb oraz 16MB. Podczas startu instancji, w czasie inicjalizacji SGA, Oracle próbuje przyznać stroną pamięci wspólnej (shared memory) wielkość 16MB zakładając, że LOCK_SGA=TRUE. Jeżeli także ustawiony jest parametr v_pinshm to będzie to powodem unieruchomienia ORACLE SGA we wspólnej pamięci. Jeżeli LOCK_SGA=FALSE to żadne nieuruchomianie nie będzie miało miejsca i rozmiar stron zostanie ustalony na 4kb.

Wersje Oracle 10g (10.2.0.4) i 11gR11 są w stanie użyć strony pamięci o rozmiarze 64kb. Jeżeli w czasie startu Oracle, zmienne LOCK_SGA=TRUE oraz v_pinshm=1 to instancja bazy danych będzie początkowo próbować użyć i unieruchomić w pamięci wspólnej strony o rozmiarze 16MB. Jeżeli to nie będzie możliwe, to proces inicjowania SGA nie wymagając żadnej konfiguracji automatycznie użyje strony o rozmiarze 64KB. Strony o rozmiarze 64KB są preferowane, ponieważ pomimo ich minimalnego wpływu na wydajność, one w znacznym stopniu upraszczają konfigurację.

Podstawową przyczyną rozważania unieruchomienia SGA jest zapobieżenie stronicowania (page out) tego obszaru pamięci. Stronicowanie nie ma miejsca we właściwie dostosowanym środowisku AIX, w takim przypadku strony SGA powinny pozostawać w pamięci fizycznej nawet bez ich wyraźnego unieruchomienia. Unieruchomienie SGA w nieprawidłowo zaprojektowanym systemie nie polepszy tej sytuacji. Przeciwnie może to być przyczynną wzrostu stronicowania (pageout) stron obliczeniowych. Takie zachowanie może jeszcze bardziej obniżyć wydajność niż w przypadku pozwolenia na stronicowanie sporadycznie używanych stron SGA.

Unieruchomienie Oracle SGA w systemie cierpiącym na niedostatek pamięci razem z użyciem dużych stron może w drastyczny sposób zmniejszyć wydajność, a nawet być przyczyną awarii systemu. Dla wielu typów obciążeń, przypinanie SGA nie przynosi widocznych korzyści. Dlatego powinno być brane po uwagę tylko w przypadku kiedy nie można poprawić wydajności przy pomocy innymi sposobami jak na przykład przy pomocy VMM.

• Unieruchomienie Wspólnej Pamięci• Parametry AIXu

• vmo -p -o v_pinshm=1 (pozwolenie na dzielenie się wspólnymi segmentami pamięci (Shared Memory Segments).

• Zostaw wartość umowną maxpin%=80• Parametry Oracle

• LOCK_SGA=TRUE• Pozwolenie systemu operacyjnemu na użycie dużych stron

• -p -o lgpg_size=16777216 -o lgpg_regions=liczba_dużych_stron• obliczanie wartości: liczba_dużych_stron=INT[(SGA size -1) / 16MB] + 1

• Pozwolenie Oracle na użycie Dużych Stron:• zmień możliwości użytkownika=CAP)BYPASS_RAC_VMM, CAP_PROPAGETE oracle

22

Poniżej przedstawione są ogólne wskazówki, które powinny być wzięte pod uwagę przez klientów rozważających przydatność unieruchomienia SGA:

1. Ich środowisko powinno mieć dobrze określony proces dokumentacji zmian oraz dobrą komunikację pomiędzy Oracle DBA i Administratorami AIX. Na przykład, DBA nie powinien być w stanie zmienić Oracle parametrów SGA lub PGA bez uprzedniej koordynacji z administratorem AIX.

2. Należy śledzić (svmon czy vmstat) użycie pamięci unieruchomionej (przypiętej) systemu w celu sprawdzenia istnienia możliwości zwiększenia zapotrzebowania na tego rodzaju strony powyżej maxpi% w przypadku unieruchomienia SGA.

3. Unikaj zmiany wartości maxpin%. Wyjątkowe sytuacje powinny być krytycznie egzaminowane z punktu widzenia założonych wymagań, profilu obciążenia i związanego z tym ryzyka.

4. Unieruchomienie pamięci SGA nie powinno być wzięte pod uwagę, jeżeli potrzeby wszystkich obszarów SGA (potrzeby wszystkich instancji bazy danych danego lparu) przekraczają 60% pamięci fizycznej. Dzięki temu, 20% pamięci lub więcej może być przeznaczone na cele inne niż unieruchamianie SGA. Wyjątki powinny zostać poddane krytycznej analizie technicznej z punktu widzenia założonych wymagań, profilu obciążenia i związanego z tym ryzyka.

5. Jeżeli do unieruchomienia SGA użyto dużych stron (16MB), jakiegokolwiek zmiany rozmiaru SGA dokonane przez DBA powinny być ściśle związane z odpowiednimi zmianami lgpg_regions (vmo) dokonanymi przez administratora AIX. Brak równowagi pomiędzy rozmiarem SGA i lgpg_regions może być przyczyną niezmiernie małej wydajności.

6. W celu zabezpieczenia ich odpowiedniej rezerwy, należy nieprzerwanie obserwować zużycie unieruchomionych stron (svmon lub vmstat). Należy się zastanowić nad koniecznością wprowadzenia automatycznej notyfikacji w przypadku kiedy liczba wolnych stron spada poniżej dozwolonej wartości.

7. Wydajność aplikacji i systemu operacyjnego powinna być obserwowana z i bez unieruchomionej SGA (jeżeli możliwe, w środowisku laboratoryjnym). Unieruchomionych SGA nie należy używać, jeżeli ich obecność nie polepsza to wydajności systemu.

2.3 Asynchroniczne I/O

Oracle, w pełni wykorzystuje asynchroniczne I/O (AIO) AIXu osiągając dzięki temu szybszy dostęp do bazy danych. Użycie LVM oraz techniki przeplatania dysków (striping) zwiększa efektywność AIO. LVM przeplatając dane pomiędzy wieloma dyskami redukuje ich rywalizację (contention) o dyski. Użycie AIO razem z LVM znacznie poprawia wydajność RDBMS. Zaczynając od AIX 5L, mamy do wyboru dwa rodzaje AIO: zastane (legacy) AIO oraz POSIX AIO. Wszystkie wersje Oracle włącznie z wersją 11g używają zastanej (legacy) wersji AIO.AIX 5L oraz wersje późniejsze, obsługują asynchroniczne I/O (AIO) plików bazy danych umieszczonych w plikach systemu (file systems) lub w tomach logicznych (logical volumes). AIO współdziałające z tomami logicznymi jest całkowicie zintegrowane z kernelem AIXu i nie używa procesów serwera do pomocy w obsłudze I/O. Używając AIO do obsługi I/O w środowisku plików systemu serwer używa procesów usługowych jądra (kproc), które kontrolują każde polecenie od momentu zabrania go z kolejki to momentu jego zakończenia. Liczba procesów usługowych serwera kproc ustala maksymalną liczbę poleceń AIO, które mogą być wykonane jednocześnie. Z tego właśnie powodu, wybranie odpowiednio dużej liczby procesów usługowych kproc jest bardzo ważne w przypadku kiedy pliki bazy danych są przechowywane w plikach systemu (file systems). W przypadku wersji AIX wcześniejszych niż 6.1 i bazy danych używającej AIO to ten system musi być włączany automatycznie wybierając available jako parametr auto konfiguracji. W przypadku AIX 6.1, AIO jest zawsze włączane automatycznie w czasie startu systemu operacyjnego. Zmiana wartości tego parametru wymaga ponownego restartowania systemu.

Używając AIO na tomach logicznych i dyskach w środowisku Oracle ASM, IO wykonywane jest używając do tego celu fastpath, jeżeli ta opcja jest aktywna (wartość domyślna w AIX 5.3 oraz 6.1). Dzięki temu, IO jest

23

przekazane sternikowi hdisku redukując w ten sposób przełączanie kontekstu (context switching) CPU. Zaczynając z AIXem 5.3 funkcjonalność fastpath jest włączana przy użyciu parametru fsfastpath=1(aio). Ta zmiana nie przeżywa restartowania systemu. W AIX 6.1, wartość domyślna parametru ograniczonego dostępu fsfastpath wynosi 1 (aio_fsfastpath).

Określ minimalną liczbę serwerów AIO, które będą startować razem ze startującym system operacyjnym. Wybierz maksymalną liczbę serwerów, które mogą być przywołane do akcji w odpowiedzi na dużą liczbę równoczesnych poleceń I/O. Te parametry mają zastosowanie tylko w przypadku plików systemu, one nie mają znaczenia w przypadku tomów logicznych.

W AIXie 5.3, wartość domyślna minimalnej liczby serwerów AIO wynosi 1, a domyślna wartość maksymalnej liczby serwerów to 10. W AIX 6.1 zarówno wartość domyślna, jak i zasięg AIO uległ zmianie – aio_minserver=3, aio_maxserver=30 a jego zasięg jest indywidualne CPU. Nazwy wszystkie parametrów w 6.1 zaczynają się od aio_.

W dodatku do zmiany wartości parametrów minservers i maxservers należy również zwracać uwagę na parametr maxreqs i zmieniać jego wartość, jeżeli wymaga tego sytuacja. Zmienna maxreqs kontroluje liczbę dozwolonych przez system poleceń AIO i odnosi się zarówno do (fs)fastpath oraz do operacji I/O opartych na kproc.

Do określenia liczby działających serwerów AIO wydaj następujące polecenie:

# pstat -a | grep -c aios | wc -l

AIX 5.3 wprowadził nową opcję do polecenia iostat (iostat -A), które pozwala wyświetlać statystyki AIO w określonych odstępach czasu oraz w określonej liczbie repetycji. Począwszy od AIX 6.1, wartości wszystkich parametrów systemu AIO mogą być zmieniane przy pomocy polecenia ioo (użycie do tego celu aioo nie jest więcej polecane).

Kolumny raportu asynchronicznego I/O mają następujące nagłówki:

• avgc: średnia liczba na sekundę wszystkich poleceń AIO w podanym przedziale czasu.• avfc: średnia liczba na sekundę poleceń fastpath w podanym przedziale czasu.• maxgc: maksymalna liczba wszystkich poleceń AIO od czasu ta wartość była podana ostatni raz.• maxfc: maksymalna liczba poleceń fastpath od ostatniego czasu ta wartość była podana.• maxreqs: maksymalna liczba dozwolonych poleceń AIO.

Polecane wartości początkowe:

• minservers:• wartość początkowa dla AIX5.3 jest określana w zależności od maszyny, jej początkowa wartość

powinna być 10, dodatkowe serwery będą startować automatycznie w zależności od obciążenia systemu.

• w przypadku AIX6.1, wartość początkowa dotyczy logicznego CPU, wartość domyślna wynosi 3 (aio_minservers)

• maxservers:• wartość początkowa dla AIX 5.3 jest określona na CPU, wartość początkowa powinna wynosić

100• wartość początkowa dla AIX 6.1 jest określona na CPU, wartość początkowa powinna wynosić

100 (aio_maxservers)• maxreqs:

• wielokrotność 4096 > 4 * liczba dysków * pojemność kolejek dysków, typowa wartość wynosi 16348 lub 65536 dla AIX 6.1 (aio_maxreqs)

24

Jeżeli wartość parametrów maxreqs lub maxservers jest zbyt mała, to możesz zobaczyć następujące komunikaty o błędzie:

Warning: lio_listio returned EAGAINPerformance degradation may be seen.

Użyj jednego z pokazanych poniżej poleceń do ustawienia minimalnej i maksymalnej liczby serwerów oraz maksymalną liczbę jednoczesnych poleceń I/O:

• AIX 5.3:• ‘smitty aio’ • chdev -P -l aio0 -a maxservers=’m’ -a minservers=’n’• chdev -P -l aio -a maxreqs=’q’

• AIX 6.1:• polecenia ioo jest używane do zmiany wartości parametrów związanych z AIO• ioo -p -o aio_maxservers=’m’ -a aio_minservers=’n’• ioo -p -o aio_maxreqs=’q’

Dodatkowo należy również sprawdzić następujące parametry Oracle. Opis ich znaczenia można znaleźć na następnych stronach. Poniżej pokazane są ich wartości domyślne:

DISK_ASYNC_IO = TRUEFILESYSTEMIO_OPTIONS = (ASYCH | SETALL)DB_WRITER_PROCESS = zazwyczaj nie zmienia się wartości tego parametru.

2.4 Konfiguracja I/O

System I/O jest jednym z najważniejszych elementów systemu obsługującego Oracle RDBMS. Wydajność aplikacji może być ograniczona nieodpowiednią konfiguracją systemu dysków oraz/lub przez wielką liczbę I/O wynikającego z egzekucji poleceń SQL. Aplikację, która spędza większość swojego CPU czasu czekając na zakończenie I/O nazywa się aplikacją ograniczoną I/O. W takim przypadku system I/O nie jest w stanie wystarczająco szybko obsłużyć polecenia I/O. W celu uniknięcia tej sytuacji, przed instalacją bazy danych należy zastanowić się nad odpowiednim systemem przechowywania danych oraz ich topologią. Najbardziej podstawową zasadą wiodącą do optymalnej wydajności w tym zakresie jest równomierne rozłożenie obciążenia I/O na wszystkich urządzeniach I/O oddanych do dyspozycji systemu.

Ten rozdział koncentruje się wyłącznie na wybranych zmiennych, odpowiedzialnych za wydajność I/O AIXu z zainstalowaną bazą danych rodzaju Oracle.

2.4.1 AIX LVM – Grupy Dysków (Volume Groups)

Grupa dysków to element logiczny grupujący fizyczne dyski, które AIX traktuje jako nieprzerwany, możliwy do adresowania obszar do przechowywania danych. Manager Tomów Logicznych AIXu (Logical Volume Manager) zarządza elementami przechowującymi dane (grupy dysków, dyski, tomy logiczne, pliki system, itp.).Począwszy z AIX 5.3 mamy do czynienia z trzema rodzajami grup dysków: normalna, duża oraz skalowana (scalable). Następująca ilustracja opisuje te grupy:

Rodzaj VG Max liczba PVs Max liczba LVs Max ilość PP w VG Max rozmiar PP

Normalna 32 256 32,512 (1016 * 32) 1GB

Duża 128 512 130,048 (1016 * 128) 1GB

Skalowana 1024 4096 2097152 128GB

25

W przypadku bazy danych Oracle rekomendujemy używanie grup skalowanych.

Appendix A – Dokument zatytułowany “Configuration IBM System Strage DS4000 Series for Oracle Database Applications” posiada więcej rekomendacji na ten temat.

2.4.2 AIX LVM – Tomy Logiczne (Logical Volumes)

Tom logiczny to zbiór bloków logicznych (logical paritions), które AIX przedstawia użytkownikowi jako pojedynczy element przechowujący dane. W celu zmniejszenia rezultatów konkurencji o dysk, LVM może przepleść (stripe) tomy logiczne na wielu dyskach. Efektywne użycie tej umiejętności LVMu pozwala na równomierne rozłożenie I/O pomiędzy dyskami zwiększając w ten sposób ogólną wydajność systemu I/O.

LVM AIXu posiada dwie metody przeplatania:• propagacja PP (physical parition spreading) • przeplatanie LVM (LVM striping)

Propagacja PP rozpoczyna się w momencie tworzenia tomu logicznego. Jej rezultatem jest tom logiczny, który jest rozłożony na wielu dyskach (hdisk, vpath, hdiskpower, itp) danej grupy dysków. W celu stworzenia tomu logicznego, którego PP są równomiernie rozłożone na dyskach jego grupy należy wydać następujące polecenie:

# mklv -e x ….

Używająć przeplatania (striping), radzimy używać pasma o jak największym rozmiarze. Wymiar pasma powinien wynosić co najmniej 1MB i nie powinien być mniejszy niż wynik następujących kalkulacji:

DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT (>= 1MB)

• często, db_block_size * db_file_multiblock_read_count jest dużo mniejsza niż 1MB. Z tego powodu, wymiar pasma powinien być co najmniej równy wynikowi powyższej kalkulacji. Na przykład, dla środowiska 11i E-Business Suite polecamy db_block_size=8k, db_file_multiblock_read_count=8 == 64k maksymalny rozmiar transferu i/o.

Okoliczności wymagające pasma o mniejszych rozmiarach są rzadkimi wyjątkami – środowiska wymagające niezmiernie wysokiej wydajności w przypadku aplikacji sekwencyjnego pisz/czytaj w systemie jednej nitki.

Obowiązujące wymiary pasm to:

• AIX 5.2: 4k, 8k, 16k, 32k, 64k, 128k, 256k, 512k, 1M• AIX 5.3/6.1: rozmiary AIX5.2 + 2M, 4M, 16M, 32M, 64M, 128M

Ważnym założeniem/wymogiem w tej dziedzinie to konfiguracja LUN jako urządzenia RAID10 lub RAID5/RAID6. Używając tych dwóch technik (przeplatanie przez SW / HW) pozwala na optymalny rozkład systemu przechowywania danych dla bazy danych Oracle.

26

Figura 1-7 Optymalna Topografia Przechowania Danych

Propagowanie PP jest lepsze niż przeplatanie LVMu co najmniej z jednej przyczyny. Tom logiczny, stworzony z uwzględnieniem propagowania może być powiększony bez zwracania uwagi na liczbę dodatkowych dysków wymaganych przez tę operację. Po dodaniu dysku czy dysków do grupy, optymalny rozkład PP (bloków fizycznych) jest osiągalny wydając polecenie ‘reorgvg’. Zwiększenie pojemności tomu przeplatanego jest bardziej skomplikowane. W tym przypadku liczba dysków dodana do grupy musi być równa szerokości pasma użytego tworząc tom logiczny.

Przechowanie danych bezpośrednio w tomach logicznych (raw volumes) wymaga tworzenia tomów logicznych typu zerowego przesunięcia (zero offset). Pierwsze 4kb tomu normalnej czy dużej grupie dysków jest zarezerwowane dla Bloku Kontrolującego Tom Logiczny (LVCB – Logical Volume Control Block). Obecność LVCB nie pozwala Oracle na użycie tego obszaru zmuszając aplikację do przechowania swoich danych zaczynając od drugiego 4KB bloku tomu logicznego. Użycie zerowego przesunięcia pozwalającego danym bazy danych na korzystanie z pojemności tomu logicznego zaczynając od jego bajtu 0 jest możliwe zaczynając z Oracle 9i R2. Łącząc tę metody z db_block_size > 4k szczególnie w obecności przeplatanego I/O (AIX LVM lub hardware RAID5 czy RAID10) jest w stanie znacznie poprawić wydajność I/O.

Poniżej, omawiam kroki niezbędne do budowy tomów logicznych w systemie zerowego przesunięcia:

• Wydając polecenie “mkvg -S” lub “mkvg -B” stwórz “skalowaną” lub “dużą” grupę dysków. • Do budowania tomów logicznych, używaj polecenia “mklv -T O (nie 0)”. Opcja “-T O” pozwala

Oracle na użycie pierwszych 4KB tomu logicznego. Tomy logiczne należące do grupy “skalowanej” są automatycznie tworzone z opcją “-T O”.

2.4.3 AIX czytanie sekwencyjne z wyprzedzeniem (AIX sequential read ahead)

VMM jest w stanie przewidzieć zapotrzebowanie na strony w przypadku plików sekwencyjnych obserwując sposób czytania danych. Po przeczytaniu dwóch kolejnych stron (z tego samego pliku), VMM zakłada, że ten proces będzie kontynuowany w wyniku czego VMM planuje następne seryjne odczyty. Te odczyty zbiegają się z procesem aplikacji w wyniku czego Oracle otrzymuje szybciej wymagane przez siebie dane.Dwie zmienne VMM określają liczbę stron czytanych z wyprzedzeniem:

• MINPAGEAHEAD (JFS) lub j2_minPageReadAhead (JFS2) – liczba stron czytanych z wyprzedzeniem, kiedy VMM po raz pierwszy zauważa seryjny dostęp do danych.

• Wartość domyślna: 2• Polecana wartość początkowa: MAX (2, DB_BLOCK_SIZE/4096)

27

• przykład: ioo -p -i j2_minPageReadAhead=8• jest to element strojący ograniczonego dostępu w AIX6.1

• MAXPGAHEAD (JFS) lub j2_maxPageReadAhead (JFS2) – maksymalna liczba stron czytanych seryjnie przez VMM,

• wartość domyślna: 8 (JFS) lub 128 (JFS2)• polecana wartość początkowa: to samo lub wielokrotność największego rozmiaru I/O Oracle• max [256, (DB_BLOCK_SIZE / 4096) * DB_FILE_MULTIBLOCK_READ_COUNT]• przykład: ioo -p -o j2_maxPageReadAhead=256• jest to element strojący ograniczonego dostępu w AIX6.1

Ustaw wartości parametrów MINPAGEAHEAD oraz MAXPAGEAHEAD (oraz ich odpowiedniki jfs2) odpowiednio do twojej aplikacji (druga potęga). Do zmian ich wartości użyj polecenia ioo. W środowisku, w którym wydajność przeplatanych tomów logicznych jest szczególnie ważna zwiększyć wartość zmiennej MAXPAGEAHEAD.

2.4.4 Strojenie buforów plików systemu

Do kontroli czekającego na obsługę przez dyski I/O, LVM używa obiektów zwanych “pbuf”. Pbuf to unieruchomiony bufor (pinned memory buffer). LVM używa jednego pbuf dla każdego polecenia I/O niezależnie od wielkości danych przekazanych tym poleceniem. We wcześniejszych wersjach AIXu liczba tych elementów była przyznawana w skali maszyny. Począwszy z AIX 5.3 każda grupa dysków ma swoją własną pulę pbuffers przyznanych i kontrolowanych przez LVM.

W celu wyjaśnienia procesu strojenia pbufers użyjemy jako przykładu wyników następującego polecenia:

# vmstat -v | tail -5 (potrzebujemy tylko pięć ostatnich linijek)

0 pending disk I/Os blocked with no pbuf• zwiększ liczbę pv_min_pbuf używając do tego celu ioo, to wymaga varyoff/on

0 paging space I/Os blocked with no psbuf• dotyczy psbuf - zwiększ pojemność stronicowania, najlepiej zrób wszystko, żeby usunąć

stronicowanie 8755 filesystem I/Os blocked with no fsbuf <-JFS

• dotyczy fsbufs - używając ioo zwiększ liczbę numfsbufs, ich wartość domyślna = 196, wartość polecana = 1568

• element strojenia ograniczonego dostępu. 0 client filesystem I/Os blocked with no fsbuf <-NFS/Veritas

• w przypadku fsbufs folderów systemu klienta, zwiększ:• używając nfso nfs_vX_pdts oraz nfs_vX_vm_bufs (gdzie X reprezentuje wersję NFS – 2, 3 lub

4)• element strojenia ograniczonego dostępu

2365 external pager filesystem I/Os blocked with no fsbuf <-JFS2• Jeżeli system nie posiada wystarczającej ilości buforów JFS2:• j2_dynamicBufferPreallocation powinien być strojony w pierwszej kolejności bez jakiegokolwiek

zmian wartości j2_nBufferPerPageDevice. Zmiany wartości są akceptowane dynamicznie – nie wymagają remount pliku systemu.

• Jeżeli wartość parametru j2_nBufferPerPageDevice wymaga zwiększenia, polecana wartość wynosi 2048 – w AIX 6.1. ten parametr stracił na znaczeniu.

Można bezpiecznie założyć, że każda zmiana tych parametrów wymaga re-mount danego pliku systemu.

Komentarz końcowy:• Należy rozumieć, że same w sobie wartości tych zmiennych nie mają znaczenia. Ważna jest wartość

zmiany ich wartośc w określonym przedziale czasu. Obserwuj rezultaty kilku kolejnych egzekucji polecenia ‘vmstat -v’ wydanych pewnym przedziale czasu. Nie podejmuj decyzji polegając na wynikach

28

jednej obserwacji.• W AIX5.2 (lub wersja wcześniejsza) strojenie pbufs dotyczy całego systemu (pv_min_pbuf) oraz

wymaga varyoffvg/varyonvg.• W AIX5.3 i AIX6.1 te czynności stają się bardziej ziarniste. Obecnie, używając do tego celu polecenia

lvmo możemy nimi manipulować na poziomie indywidualnej grupy dysków.

2.4.5 Montowania plików systemu rodzaju JFS2 z opcją CIO/DIO

◦ Bezpośrednie I/O (DIO)

Dla pewnego aplikacji (i związanych z nimi czynnościami bazy danych) buforowania ich plików przez system operacyjny nie przynosi żadnych korzyści. Bazy danych posiadają swój własny mechanizm buforowania danych co usuwa potrzebę na buforowanie I/O na poziomie plików systemu przez system operacyjny. W takich przypadkach, podwójnego buforowanie danych obniża wydajność – dane są przenoszone z dysku do bufora pliku systemu, po czym ta sama dana jest skopiowana do własnego bufora aplikacji. To podwójne buforowanie/kopiowanie danych nie tylko wymaga dodatkowego czasu, ale również powoduje dodatkowe zużycie CPU. To nie wszystko, kopia danych znajdująca się w buforach plików zwiększa zapotrzebowanie na pamięć co z kolei redukuje ilość pamięci dostępnej dla aplikacji co jeszcze bardziej zwiększa obciążenie systemu.

Aplikacje, które nie chcą korzystać z mechanizmu buforowania pamięci podręcznej plików systemu operacyjnego mają możliwość użycia bezpośredniego I/O (DIO – Direct I/O), które jest jedną z opcji JFS. Bezpośrednie I/O typu pozwala na transfer danych bezpośrednio z dysku do bufora aplikacji pomijając pamięć podręczną plików system. Dzięki temu, niektóre aplikacje mogą osiągnąć wyższą wydajność. Pamiętaj, że DIO uniemożliwia dostęp do mechanizmu buforowania w pamięci podręcznej plików systemu, co uniemożliwia czytanie danych sekwencyjnie z wyprzedzeniem (sequential read-ahead). Aplikacje, które charakteryzują się tego rodzaju I/O mogą doświadczyć w środowisku DIO poważnej degradacji ich wydajności.

JFS2 posiada nie tylko opcję DIO, ale również opisaną poniżej opcję równoczesnego (Concurrent/CIO) I/O. CIO jest zbudowane na bazie DIO. CIO należy używać w środowiskach JFS2, w których najważniejszym celem jest uniknięcie buforowania systemu operacyjnego.

Bezpośrednie I/O (DIO) należy używać w przypadku plików danych (.dbf) Oracle w środowiskach, w których DB_BLOCK_SIZE jest równy lub większy niż 4kb. Użycie DIO w przypadku plików takich jak redo logs, czy pliki kontrolujące powoduje poważny spadek wydajności wywołany naruszeniem wymagań zbieżności (alignment) DIO oraz/lub ograniczeniami rozmiaru transakcji I/O.

• I/O Równoczesne (CIO)

Rezerwacja i-węzłów (inode lock), zmusza do serializacji zapisu danych na poziomie pliku. JFS2 (tak jak JFS) jest plikiem systemu odpowiadającym konwencji POSIX. Dlatego, JFS2 w celu zapewnienia aktualności zapisywanych danych zatrudnia ten mechanizm serializacji I/O. Rezerwacja i-węzłów gwarantuje, że w danym momencie istnieje tylko jedno zaległe polecenia zapisu danych, czytanie danych nie jest dozwolone, ponieważ czytana dana może nie być najnowszą daną (stale data). Oracle chroni swoje dane, używając własny system serializacji. Z tego powodu, Oracle nie polega i nie używa serializacji oferowanej przez system operacyjny. W środowiskach z dużą częstotliwością wpisywania danych, serializacja i-węzłów obniża wydajność zbędnie serializując niekonkurujące ze sobą polecenia dostępu do danych.

Dla aplikacji posiadających własny mechanizm serializacji (takich jak baza danych Oracle), JFS2 (poczynając z AIX5.2.10) oferuje możliwość użycia równoczesnego I/O (CIO / Concurrent I/O). W tym przypadku wiele wątków może prowadzić jednocześnie operacje pisania i czytania na tym samym pliku. Aplikacje nieprzestrzegające serializacji dostępu do pliku (włącznie z aplikacjami systemu operacyjnego) nie powinny używać jednoczesnego I/O, ponieważ konkurujące ze sobą polecenia I/O mogą spowodować korupcję danych lub poważnie obniżyć

29

wydajność systemu.

Jednoczesne IO należy używać wyłącznie w przypadku plików .dbf (dane i indeksy, rbs lub ‘undo’, system i temp), bieżące dzienniki powtórzeń (online redo logs) oraz/lub plików kontrolnych (control files). W przypadku użycia z bieżącymi dziennikami powtórzeń lub z plikami kontrolnymi - te pliki muszą być położone w swoich własnych systemach plików typu JFS2 tworzonych z agblksize=512. Systemy plików zawierające pliki ‘.dbf’ należy tworzyć z aglbksize=2048, jeżeli DB_BLOCK_SIZE=2k oraz z aglbksize=4096, jeżeli DB_BLOCK_SIZE >=4k. Nieprzestrzeganie tych wskazówek najprawdopodobniej spowoduje poważne spadek wydajności serwera. W żadnych okolicznościach nie należy używać CIO do montowania plików systemu zawierających pliki binarne Oracle (!!!). Nie używaj DIO/CIO dla plików systemu zawierających “archive logs” oraz inne rodzaje plików, które nie były jeszcze dyskutowane.

CIO jest preferowaną metodą dla aplikacji dążącej do uniknięcia buforowania pamięci w środowisku plików systemu typu JFS2. Używając CIO kończy się bezpośrednim przekazaniem danych z pliku do bufora aplikacji pomijając bufory plików systemu. CIO, również wyłącza mechanizm serializujący I/O typu POSIX co usprawnia “jednoczesność” (concurrency) I/O w przypadku aplikacji z intensywnym zapisem danych. Użycie CIO może przynieść pożytek wybranym aplikacją. Należy pamiętać, że zatrudnienie CIO uniemożliwia użycie pamięci podręcznej (cache) plików systemu. W środowisku CIO, aplikacje ze znacznym /O z seryjnym czytaniem mogą doświadczyć poważnego obniżenia wydajności.

Aplikacje przechowujące dane w tomach logicznych (raw volumes) nie mają do czynienia się z rezerwacją ii-węzła, ponieważ jest to możliwe tylko dla operacji w sferze plików systemu.

2.5 Strojenie CPU

Strojenie CPU jest tematem “zaawansowanym”. Z tego powodu nie będzie ono omawiane w takich samych detalach jak tematy poprzednie. Do strojenia CPU używamy polecenia schedo. Nasza rekomendacja to pozostawienie w spokoju zmiennych kontrolowanych tym poleceniem. Jakakolwiek zmiana w tym zakresie powinna być dokonana tylko na polecenie IBM.

Dlatego, tutaj ograniczymy się do tematów jak Równoczesne Tkanie Wieloma Nitkami” (Simultaneous Multi-Threading) czyli SMT, Partycje Logiczne (Logical Partitioning) oraz MikroPartycje (Micropartitioning). Więcej informacji można być znaleźć w IBM RedBook “PowerVM Virtualization on IBM System P: Introduction and Configuration, Fourth Edition” (http://www.redbooks.ibm.com/abstracts/sg247940.html)

2.5.1 Równoczesne Tkanie Wieloma Nitkami (SMT)

SMT jest wynikiem postępu w projektowaniu i produkcji procesorów POWER5 i ich następców, które pozwala jednemu procesorowi wykonywać polecenia (instrukcje) pochodzące z dwóch indywidualnych wątków. Do korzystania z tej funkcji, wymagany jest AIX 5L wersja 5.3 lub późniejsza.

SMT oferuje aplikacją wielowątkowym znaczny wzrost wydajności i mocy przerobowej Każda instalacja Oracle powinna używać SMT. Z drugiej strony, aplikacje, które zostały zaprojektowane do maksymalnego wykorzystania zasobów procesora takie jak pamięć podręczna czy High Performance Computing oraz te, które wymagają dużo pamięci często mają gorszą wydajność w środowisku z działającym SMT. Ten spadek wydajności jest rezultatem aplikacji rywalizacji o dostęp do pamięci podręcznej i pamięć. Niektóre aplikacje jednowątkowe (z małą konsumpcją CPU) mogą również doświadczyć pogorszonej wydajności. W takich przypadkach polecamy wyłączenie SMT.

AIX 5.3, niezależnie od typu partycji, każdy wątek sprzętu (hardware) jest traktowany jako indywidualne logiczne CPU. Partycja wyposażona w jeden fizyczny procesor i działające SMT będzie pokazywał dwa logiczne CPU, partycja wyposażona w 2 wirtualne procesory będzie posiadać 4 logiczne CPU, itp. Dwa aktywne wątki, działające na dwóch logicznych procesorach reprezentują dwa wątki SMT. Te wątki są zawsze koordynowane przez Hypervisor z dedykowanym lub wirtualnym CPU.

30

Dlatego, że SMT jest kontrolowane przez system operacyjny to można je włączyć i wyłączyć na poziomie partycji. Do tego celu służy polecenie smtctl,które pozwala upoważnionym użytkownikom i aplikacją włączyć/wyłączyć SMT na wszystkich procesorach partycji w danej chwili czy w rezultacie następnego reboot.

2.5.2 Partycje Logiczne (Logical Partitioning)

Partycja logiczna maszyny typu “IBM POWER Systems” to wynik dzielenia jej zasobów fizycznych takich jak CPU, pamięci, adaptery czy dyski i ich grupowanie w zestawy logiczne (partycje) posiadające swój własny system operacyjny i aplikacje. Partycje nie mają ze sobą nic wspólnego z wyjątkiem “opakowania”. Pierwsza wersja partycji była statyczna – zmiana posiadanych przez nią urządzeń była niemożliwa do wykonania bez jej restartowania. Począwszy z rokiem 2002, partycja jest jednostką dynamiczną (DLPAR) mogącą zmienić stan posiadanych przez nią elementów składowych bez restartowania.

Oracle 9i wprowadziło koncept dynamicznej administracji pamięcią, która w połączeniu z możliwościami dynamicznych partycji częściowo uprościła zarządzanie instancjami bazy danych. Pamięć użyta przez Oracle składa się głównie z pamięci kontrolowanej przez SGA i PGA. Początkowy rozmiar bloku pamięci SGA jest deklarowany wartością zmiennej SGA_MAX_SIZE. Po uruchomieniu bazy danych (oraz zainicjowania SGA) pewne rejony pamięci można zmodyfikować używając do tego celu odpowiednich poleceń bazy danych. Administracja elementów PGA jest całkowicie zautomatyzowana, jak długo zadeklarowano jej początkowy rozmiar, używając do tego celu zmiennej PGA_AGGREGATE_TARGET. Wielkość tego obszaru pamięci może być zmieniona przez DBA. Więcej detali na ten temat można znaleźć w Rozdziale 4.

Możliwości AIXu połączone z możliwościami DLPARu wraz z nowymi dynamicznymi możliwościami zarządzania pamięcią Oracle wersji 9i, 10g oraz 11g oferują razem dużo więcej możliwości administracji pamięcią używaną przez bazę danych. Mówiąc o partycji dynamicznej (DLPAR) warto wspomnieć, że liczba jej procesorów nie jest wartością stałą – ich liczba może w każdym momencie być zmieniona przez administratora systemu czy nawet jako rezultat planowanej egzekucji skryptu. Oracle przechowuje bieżącą liczbę procesorów w zmiennej CPU_COUNT. Jej wartość ma decydujący wpływ na kilka parametrów bazy danych. Te najważniejsze to: parallel_max_servers, fast_start_parallel_rollback, db_block_lru_latches_log_buffer, itp..... Niestety, w przypadku Oracle 9i dynamiczna zmiana wartości tej zmiennej jest niemożliwa. Nie dotyczy to zarządcy procesów systemu operacyjnego (scheduler), który jest w stanie wykorzystać każde dodatkowe CPU przyznane partycji. Wolny procesor można dynamicznie usunąć z partycji. Oracle 10g oraz Oracle 11g aktualizują automatycznie wartość zmiennej CPU_COUNT.

2.5.3 Mikro-Partycjonowanie

Mikro-Partycjonowanie jest możliwe dzięki PowerVM (poprzednio znane jako Advanced Power Virtualization). PowerVM pozwala partycją logicznym dzielić się fizycznymi procesami. Partycja może otrzymać od 10 do 100% mocy przerobowej zestawu procesorów (processor pool). W przypadku maszyn POWER5 zbiór wspólnych procesorów składa się z procesorów fizycznych nienależących do żadnej partycji logicznej. W przypadku maszyn typu POWER6 grupy wspólnych procesorów znane jako Multiple Shared Processor Pools (MSPPs) pozwalają tworzyć micro-partycji (micro paritions), których używają zasoby CPU określonej puli procesorów wspólnych. Jest to możliwe dzięki POWER Hypervisor, który jest elementem składowym oprogramowania wbudowanego (firmware), które odgrywa rolę pośrednika pomiędzy systemem operacyjnym a hardware maszyny. Hypervisor koordynuje pracę wirtualnych CPUs na ich fizycznych odpowiednikach. Zbiór procesorów wspólnych może posiadać dowolną liczbę procesorów fizycznych, zaczynając od jednego a kończąc na wszystkich zainstalowanych w maszynie.

Mikro-partycje można charakteryzować jako:

• ograniczone (Capped)Micro-partycje ograniczone posiadają gwarantowany dostęp do ściśle określonej liczby zasobów przerobowych procesora. Tego rodzaju partycja, pod żadnym warunkiem nie otrzyma więcej CPU niż jest do tego uprawniona.

• nieograniczone (Uncapped)Nieograniczona mikro-partycja w niektórych okolicznościach może otrzymać dostęp do większej ilości CPU niż

31

ilość podana w momencie jej powstania. Typowo, mikro-partycja nieograniczona otrzyma dodatkowe CPU jako funkcja swojej wagi (weight) jeżeli jej zbiór procesorów wspólnych ma wolną moc przerobową.

Partycje ograniczone oraz nieograniczone mogą czerpać zasoby CPU z tego samego puli wspólnych procesorów fizycznych.

Poniżej, podajemy kilka ogólnych rekomendacji dla użytkowników Oracle w środowisku mikro-partycji:

• Używaj SMT • W partycji, liczba wirtualnych CPU nie powinna być większa od liczby procesorów fizycznych należących

do jej puli procesorów wspólnych. Wartość “Maximum VP” może być większa co pozwala na dynamiczne zwiększenie liczby procesorów wirtualnych w odpowiedzi na zwiększenie ilości procesorów fizycznych w puli procesorów wspólnych.

• Wartość przyznanej partycji gwarantowanej mocy CPU powinna reprezentować minimalną wartość CPU pozwalającą jej na osiągnięcie rezultatów oczekiwanych przez jej klienta (service level agreement) dla danego typu i wartości obciążenia używającej jej bazy danych.

• W partycjach ograniczonych należy zaokrąglić posiadanją przez nie liczbę wirtualnych CPUs do najbliższej liczby całkowitej >= wartości granicznej (capping limit). Na przykład, jeżeli limit CPU wynosi 3.4 to VCPUS = 4.

• W środowisku partycji nieograniczonych, liczba wirtualnych CPU powinna odpowiadać maksymalnemu chwilowemu obciążeniu, jakie partycja może doświadczyć. Jest możliwe, że w takim środowisku należy wprowadzić do życia (często weryfikować i dostosowywać do zmieniających się warunków) pewne zasady regulujące maksymalną liczbę procesorów wirtualnych przypadających na jeden procesor fizyczny (tzn. Nie więcej niż 2 lub 3 razy).

• Gdzie jest to możliwe, w celu maksymalnego wykorzystania istniejącego hardware partycje tworzone w środowiskach jednego lub wielu zbiorów wspólnych procesorów powinny się charakteryzować następującymi cechami:

• Każda partycja wymaga maksymalnej mocy przerobowej w innym czasie (o innej porze dnia/nocy)

• Wymagania mocy przerobowej każdej partycji są inne.

• Zbiór procesorów wspólnych powinien być tak zaprojektowany, że największe zapotrzebowanie na jego moc nie przekracza 90% jego mocy całkowitej. Zużycie zasobów procesorów wspólnych należy śledzić na bieżąco. Nie używane procesory fizyczne danego zbioru mogą być wyświetlone przy użyciu polecenie ‘lparstat -h’ (kolumna app).

• W przypadku aplikacji posiadającej charakter wsadowy (batch), jeden wirtualny procesor powinien wspomagać co najmniej dwa wątki (w SMT każdy procesor wirtualny to 2 procesory logiczne). Pełne wykorzystane istniejących zasobów CPU w zależności od stosunku zużytego przez aplikację czasu CPU do czasu jej czekania (wait time) na I/O może wymagać dwa lub więcej jednoczesnych wątków przypadających na każdy na wirtualny procesor. W zależności od stosunku CPU do czasu czekania na I/O, więcej niż dwa jednoczesne wątki na Wirtualne CPU mogą być potrzebne do wykorzystania wszystkich zasobów CPU.

3. Strojenie Sieci (Network Tuning)

• Strojenie UDP (UDP Tuning)

Procesy wewnętrzne Oracle 9i, 10g oraz 11g Real Application Clusters komunikują się ze sobą przy pomocy User Datagram Protocol (UDP). Kernel AIXu posiada specyficzne parametry do strojenia środowiska UDP, które mogą być użyte w celu polepszenia wydajności bazy danej. Te parametry to udp_sendspace oraz udp_recvspace. Do zmiany ich wartości służy polecenie ‘no’.

• Zmień wartość parametru tak, że udp_sendspace = [(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096] ale nie mniej niż 65536.

32

• Zmień wartość parametru udp_recvspace = (10 * udp_sendspace).• Jeżeli jest to wymagane, zwiększ wartość parametru sb_max (wartość domyślna 1048576),

ponieważ sb_max musi być >= udp_recvspace.

Wartość parametru udp_recvspace powinna być co najmniej cztery do dziesięciu razy większa od wartości udp_sendspace, ponieważ UDP może nie być w stanie wysłać jednego pakietu (packet) do aplikacji przed otrzymaniem następnego pakietu.Określenie konieczności zmiany parametru udp_recevspace może być dokonane przy pomocy:

• netstat -s | grep “socket buffer overflows”

Zwiększ wartość udp_recvspace, jeżeli liczba overflows jest większa od zera.

• Strojenie TCP (TCP Tuninng)

W środowisku Oracle RDBSM kilka parametrów AIXu może mieć wpływ na wydajność TCP. Te parametry to:

• tcp_recvpsace – określa ile bajtów odbieranych danych system odbiorczy może buforować w jądrze w kolejce odbieranych gniazd (in the kernel on the receiving sockets queue). Ten parametr jest również użyty przez TCP do ograniczenia rozmiaru swojego okna (TCP window size), które jest używane przez TCP do ograniczenia ilości danych przesłanych do systemu odbierającego w celu zapobieżenia przepełnienia jego buforów.

• tcp_sendspace – określa wielkość daty, którą wysyłająca aplikacji może umieścić w buforze kernela przed zablokowaniem jej następnej operacji wysłania danych.

• rfc1323 – zezwolenie na opcję do zmiany rozmiaru okna (window scaling) TCP. To jest opcja wymagająca negocjacji i zgody pomiędzy wszystkimi komunikującymi się obiektami.

• sb_max – ustala górną granicę liczby buforów związanych z indywidualnym gniazdem (socket), kontrolując w ten sposób wielkość pojemności buforów zużytej przez bufory kolejek gniazd nadawcy lub gniazd odbiorcy.

Do strojenia tych parametrów należy użyć opcji danego adaptera3 (Intrerface Specific Network Options). To pozwala na strojenie indywidualnych adapterów sieci w celu umożliwienia im osiągnięcia maksymalnej wydajność. Wartości atrybutów adaptera sieci mają pierwszeństwo nad odpowiadającymi im parametrami regulującymi kernela systemu operacyjnego, którymi manipulujemy poleceniem no. W celu ustalania wartości parametrów adaptera należy użyć opcji use_isno polecenia no.Następująca ilustracja podaje wybrane wartości parametrów najczęściej używanych adapterów. To są wartości optymalne, które należy zmienić tylko na polecenie personelu IBM.

Fig.1-8 Sugerowane wartości parametrów

3 lscfg -vl ent# - do wyświetlenia ISNO, chdev -d ent ….... - do zmiany wartości parametru

33

(1) Radzimy użyć wartość domyślną sb_max=1048576. Wartości pokazane w powyższej tablicy reprezentują ogólnie akceptowane wartości minimalne tej zmiennej.

4. Strojenie Bazy Danych Oracle

W tym rozdziale omówimy najważniejsze elementy umożliwiające wydajną pracę bazie danych w środowisku AIX. Ta prezentacja omawia wybraną liczbę, wewnętrznych parametrów Oracle bez omawiania detali związanych z regulowaniem wewnętrznego działania Oracle (czynności związane z indeksami i optymalizatora zapytań, śledzenia i strojenia, optymalizatora poleceń SQL, itp.).Jeżeli używasz aplikacji pakowanych w systemie ISV takich jak Oracle E-Business Suite czy SAP R/3 to być może ich sprzedawca przekazał ci wskazówki ich instalacji i strojenia. W takim przypadku należy pierw zastosować jego rekomendacje.

• Podstawowe Parametry OracleKilka parametrów Oracle ma olbrzymi impakt na jej wydajność. Nie posiadając odpowiedniej wartości, obniżają jej wydajność i sprawność. Regulację Oracle należy zacząć od sprawdzenia ich wartości. Dopiero po nadaniu tym parametrom odpowiednich wartości należy się zająć regulacją pozostałych parametrów bazy danych. Parametry, które mają największy wpływ (i które należy regulować w poniższej kolejności) na sprawność Oracle są omawiane w następnych sekcjach.

• DB_BLOCK_SIZEOkreśla wartość domyślną bloków bazy danych. Ustalenie wartości tego parametru jest niezmiernie ważne, ponieważ jest on określony tylko raz - w momencie tworzenia bazy danych. Optymalny rozmiar tego parametru jest funkcją charakteru aplikacji bazy danych. Jego typowe wartości to 8KB w przypadku przetwarzania danych online (workload OLTP) oraz 16KB i 32KB w przypadku obciążeń typu rozproszonego systemu danych (DDS). Chcąc użyć DB_BLOCK_SIZE=2KB razem z JFS2 należy pamiętać, że takie pliki systemu należy tworzyć stosując agblksize=2048.

Pomimo że większość klientów przyznaje DB_BLOCK_SIZE jego wartość domyślną, w tej samej bazie danych w zależności od rodzaju używającego go obiektu blok danych może mięć pięć innych wartości. Administracja bazy danych posiadającej bloki danych o różnych wartościach komplikuje jej administrację (w przypadku złego zaprojektowania i wykonania) i jest w stanie obniżyć jej wydajności. Decyzja użycia bloków o różnej wielkości nie powinna być pochopnie podejmowana.

Rozważając nad rozmiarem bloku bazy danych należy wziąć pod uwagę następujące okoliczności:

Tablice z relatywnie niewielką ilością rzędów (rows), które są typowo manipulowane jeden rząd naraz mogą skorzystać z mniejszego DB_BLOCK_SIZE, ponieważ jego transfer pomiędzy dyskiem a pamięcią wymaga mniejszego rozmiaru I/O zużywając mniej pamięci i potencjalnie redukując konkurencję bloków danych o pamięć.Indeksy, które są manipulowane przy pomocy klucza dopasowanego (matching key) również mogą skorzystać z mniejszego DB_BLOCK_SIZE.

Duży rozmiar DB_BLOCK_SIZE jest preferowany przez tablice, z dużą ilością wierszy. Duży DB_BLOCK_SIZE może pozwolić na umieszczenie całego rzędu w jednym bloku oraz/lub może to zmniejszyć marnotrawstwo pojemności bloku.

Tablice i indeksy manipulowane sekwencyjnie, również mogą skorzystać z większego DB_BLOCK_SIZE, ponieważ jest to rezultatem większego rozmiaru przesyłanego I/O co pozwala na wydajniejsze czytanie danych. Także tablice i indeksy z wysoką lokalnością referencji (prawdopodobieństwo, że po manipulacji pewnej danej/rzędu celem następnego aktu manipulacji będzie sąsiednia dana/rząd) mogą skorzystać z większego bloku, ponieważ im większy blok tym większe szanse na to, że sąsiedni rząd/dana w nim spoczywa już został wpisany do pamięci podręcznej (cache) bazy danych.

34

• DB_BLOCK_BUFFERS lub DB_CACHE_SIZETe parametry określają rozmiar bufora pamięci podręcznej bazy danych używanego do tymczasowego przechowania (caching) w SGA bloków o rozmiarze domyślnym (DB_BLOCK_SIZE). Jeżeli DB_BLOCK_SIZE jest określony to wielkość całkowita domyślnego bufora pamięci podręcznej wynosi DB_BLOCK_BUFFERS * DB_BLOCK_SIZE. Wartość DB_CACHE_SIZE (jeżeli podana) określa całkowitą wielkość domyślnego buffera pamięci podręcznej.

W przypadku użycia w środowisku bazy danych bloków o różnych rozmiarach, zmienna DB_nK_CACHE_SIZE jest użyta do określenia wielkości dodatkowych obszarów pamięci podręcznej bazy danych przeznaczonych na przechowanie bloków o rozmiarach innych niż domyślny DB_BLOCK_SIZE. Na przykład, jeżeli DB_BLOCK_SIZE=8K oraz DB_16K_CACHE_SIZE=32M, te wartości sugerują, że do przechowania bloków 16 KB zostanie stworzony specjalny obszar pamięci podręcznej o rozmiarze 32MB.

Głównym celem buforów pamięci podręcznej bazy danych jest przechowanie często używanej daty (lub indeksów) w celu uniknięcie lub zmniejszenia fizycznego I/O dysków obsługując polecenie klienta. Bez zagłębiania się w szczegóły, wymiar bufora pamięci podręcznej powinien gwarantować mu najwyższy procent trafiania (buffer cache hit rate). Zwiększenie jego rozmiaru, wymaga więcej zasobów do jego administracji (pamięć, cpu, etc) co z kolei powoduje większe zapotrzebowanie na moc przerobową systemu zmniejszając wydajność i sprawność bazy danych. Publikacja Oracle po tytułem “Oracle Stackpack or Workload Repository Report” zawiera sekcję “Buffer Pool Advisory” przedstawiającą statystykę, która może być przydatna do określenia optymalnej wartości bufora pamięci podręcznej.

• DISK_ASYNC_IOW przypadku plików systemu (JFS, JFS2, GPFS, Veritas) oraz tomów logicznych (logical volumes), AIX w pełni wspomaga asynchroniczny I/O. Wielu Oracle DBA nie zdaje sobie z tego sprawy i dlatego tego nie używają. Ta zmienna powinna mieć zawsze wartość TRUE (jego wartość domyślna). Należy pamiętać, że ta opcja systemu operacyjnego musi być włączona (w AIX6.1 jest ona włączana domyślnie w czasie startu maszyny) a jej atrybuty muszą być odpowiednio dobrane.

• FILESYSTEMIO_OPTIONSTa opcja włącza/wyłącza Asynchroniczny i Bezpośredni (Direct) I/O dla plików w plikach systemu. FILESYSTEMIO_OPTIONS może posiadać następujące wartości:

• ASYNCH używaj Asynchroniczny I/O razem oraz pamięcią podręczną plików systemu• DIRECTIO użyj Synchroniczne I/O razem z Bezpośrednim I/O• SETALL użyj Asynchroniczny I/O razem z Bezpośrednim I/O• NONE użyj Synchroniczne I/O razem z Bezpośrednim I/O

Przed połączeniem tego parametru z nowymi metodami montowania plików systemu (DIO/CIO) przez AIX powinieneś skorzystać z następujących rekomendacji:

• Chcąc skorzystać z buforowania plików systemu JFS/JFS2 (pomaga to w przypadku znacznych obciążeń sekwencyjnych z małym procentem pisania danych), montując foldery systemy użyj domyślnych wartości systemu operacyjnego oraz FILESYSTEMMIO_OPTIONS=ASYNCH.

• W sytuacji, kiedy inne aplikacje (cp, dd, cpio) żądają dostępu do plików otwartych przez Oracle to pliki systemu, w których one się znajdują należy montować używając wyłącznie opcji własnych AIXu. W przypadku przeciwnym faworyzowane są FILESYSTEMIO_OPTIONS.

• Wyłączenie buforowanie plików systemu JFS/JFS2 (DIO faworyzuje znaczne obciążenia będące rezultatem niesekwencyjnego dostępu do danych. CIO nadaje się bardziej do użycia w przypadku poważnego obciążenia wynikającego z uaktualniania zawartości bazy danych), proszę kierować się następującymi wskazówkami:

35

ORACLE 9i:filesystemio_options JFS (domyślne

montowanie)JFS (montowanie

DIO) JFS2 (domyślne

montowanie)JFS2 (montowanie

CIO)asynch Asynchroniczne,

buforowane I/OAsynchroniczne, DIO Asynchroniczne,

buforowane I/OAsynchroniczne CIO

setall Asynchroniczne, buforowane I/O

Asynchroniczne, DIO Asynchroniczne, buforowane I/O

Asynchroniczne CIO

directio(*) Synchroniczne, buforowane I/O

Asynchroniczne, DIO Synchroniczne, buforowane I/O

Synchroniczne CIO

none(*) Synchroniczne, buforowane I/O

Asynchroniczne, DIO Synchroniczne, buforowane I/O

Synchroniczne CIO

ORACLE 10g, 11g

filesystemio_options JFS (domyślne montowanie)

JFS (montowanie DIO)

JFS2 (domyślne montowanie)

JFS2 (montowanie CIO)

asynch Asynchroniczne, buforowane I/O

Asynchroniczne, DIO Asynchroniczne, buforowane I/O

Asynchroniczne CIO

setall Asynchroniczne, DIO

Asynchroniczne, DIO Asynchroniczne, CIO Asynchroniczne CIO

directio(*) Synchroniczne, DIO

Asynchroniczne, DIO Synchroniczne, CIO Synchroniczne CIO

none(*) Synchroniczne, buforowane I/O

Asynchroniczne, DIO Synchroniczne, buforowane I/O

Synchroniczne CIO

• DB_WRITER_PROCESS and DBWR_IO_SLAVES

Te parametry określają liczbę procesów pisarzy (writers) bazy danych użytych do modyfikacji jej dysków po modyfikacji bloków buforów dysków w buforze pamięci podręcznej bazy danych. W niektórych systemach operacyjnych, często używa się wielu procesów db_writer_processes w celu pokonania braku asynchronicznego I/O. Ta funkcjonalność można użyć, nawet jeżeli system operacyjny (jak na przykład AIX) posiada asynchroniczne I/O.

Zwykle, wartości domyślne tych parametrów są wystarczające i powinny być zmienione wyłącznie w celu rozwiązania specyficznego problemu na rekomendację personelu Oracle.

• SHARED_POOL_SIZE

Precyzyjne określenie wartości tego parametru jest niezmiernie trudne nie posiadając historycznej statystyki aktualnego użycia zbiornika pamięci wspólnej (shared pool). Dobrze, że zaczynając od Oracle 9i jest to wartość dynamiczna, oraz że jej górny limit jest kontrolowany zmienną SGA_MAX_SIZE. Z czego wynika, że jeżeli ustalona wartość zmiennej SHARED_POOL_SIZE okaże się zbyt mała to można ją zwiększyć aż do osiągnięcia przez nią wartości SGA_MAX_SIZE. Pamiętaj, że zbiornik pamięci wspólnej zawiera pamięć podręczną słowników danych (tablice o tablicach i indeksach), pamięć podręczną biblioteki (polecenia SQL oraz plany egzekucji), jak również w przypadku użycia wspólnego serwera (shared server) datę sesji. Z czego wynika, że nie zamierzone zużycie pamięci podręcznej jest czymś niewymagającym wysiłku. W zależności od sposobu użycia przez aplikację poleceń SQL oraz wynikającego z tego obciążenia wartość parametru SHARED_POOL_SIZE może wynosić kilka MB do kilkudziesięciu GB. Wielu dostawców aplikacji sugeruje lub

36

wymaga specyficznej wartości parametru SHARED_POOL_SIZE. Jego wartość jest funkcją ilości tablic bazy danych; słownik danych będzie większy dla większej liczby tablic i znacznej ilości regularnie wykonywanych poleceń SQL.

• SGA_MAX_SIZE

Zaczynając od Oracle 9i, wartość SGA może być zmieniona dynamicznie. To znaczy, że administrator bazy danych musi określić maksymalną ilość pamięci dostępniej dla Oracle (SGA_MAX_SIZE) oraz wartości początkowe kilku obszarów pamięci takich jak: DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, itp. Wielkość tych indywidualnych obszarów pamięci można zmienić w czasie późniejszym wydając polecenie ALTER SYSTEM zakładając, że wartość całkowita zużytej przez nie pamięci nie przekracza wartości eprezentowanej parametrem SGA_MAX_SIZE.

• SGA_TARGET

SGA_TARGET określa całkowity wymiar wszystkich elementów składowych SGA. Jeżeli SGA_TARGET jest podany, to wielkości następujących obszarów pamięci są ustalone automatycznie.

• Bufor pamięci podręcznej (DB_CACHE_SIZE)• Obszar wspólny (SHARED_POOL_SIZE)• Obszar duży (LARGE_POOL_SIZE)• Obszar Java (JAVA_POOL_SIZE)• Obszar strumieni (streams pool) (STREAMS_POOL_SIZE)

Jeżeli te automatycznie strojone obszary pamięci posiadają wartości większe niż zera, to Automatyczny Administrator Pamięci Wspólnej (Automatic Shared Memory Management) traktuje je jako wartości minimalne. Ustawiasz wartości początkowe, jeżeli aplikacji lub jej element wymagają minimalnej ilość pamięci do normalnego działania.

Następujące obszary pamięci są ustawiane ręcznie i nie są pod kontrolą Automatycznego Administratora Pamięci Wspólnej:

• bufor dziennika (log buffer)• inne pamięci podręczne buforów, takie jak KEEP, RECYCLE, oraz inne rozmiary bloków• Stałe SGA oraz inne przydziały wewnętrzne

W środowisku, w którym Automatyczny Administrator Pamięci Wspólnej oblicza wartości automatycznie strojonych obszarów pamięci pamięć przekazana tym obszarom jest odliczona od pamięci możliwej do osiągnięcia przez SGA_TARGET.

• MEMORY_TARGET, MEMORY_MAX_TARGET (11g)

MEMORY_TARGET określa wartość pamięci serwera dostępnej dla Oracle. Baza danych reguluje pamięć mając na uwadze MEMORY_TARGET, odpowiednio zwiększając lub zmniejszając wielkość SGA oraz PGA. Jeżeli plik inicjalizujący nie przyznaje wartości zmiennej MEMORY_MAX_TARGET, ale ustala wartość zmiennej MEMORY_TARGET to baza danych automatycznie przyzna zmiennej MEMORY_MAX_TARGET wartość zmiennej MEMORY_TARGET. W sytuacji odwrotnej, plik inicjalizujący nie zawiera definicji MEMORY_TARGET ale przyznaje wartość zmiennej MEMORY_MAX_TARGET, w tym przypadku wartość MEMORY_TARGET=0. Po starcie bazy danych, można dynamicznie zmieniać wartość MEMORY_TARGET zakładając, że jej wartość nie przekroczy MEMORY_MAX_TARGET.

• PGA_AGGREGATE_TARGET

Ten parametr ustala wartość pamięci (w MB) używanej do “sortowania w pamięci”. W środowiskach OLTP

37

sortowanie nie jest częstym zjawiskiem i nie jest związane z dużą liczbą wierszy. W środowiskach przetwarzania wsadowego (batch) oraz DSS, sortowanie jest czynnością najważniejszą wymagającą PGA_AGGREGATE_TARGET o dużej wartości. W przeciwieństwie do innych parametrów, ten obszar pamięci jest przydzielony z PGA. Zaczynając od Oracle 9, baza danych posiada zdolności samo zarządzania w związku z czym nie musisz ustawić wartości tego parametru jak długo twój serwer bazy danych pracuje jako serwer dedykowany (dedicated server) a wartość jego WORKING_SET_POLICY=‘automatic’.

Rozdział “PGA Memory Advisory” raportu “Oracle Statspack or AWR” dostarcza statystyki, które mogą być stosowne w ustaleniu optymalnego rozmiaru tez zmiennej.

38