Oracle 10g pod Windowsem

Jadwiga Gnybek
Jadwiga_Gnybek@nofer.lodz.pl

Najnowsze dziecko Oracle – baza 10g ze sporym opóźnieniem
pojawiło się w wersji pod Windows. Nie przeszkodziło to jednak, że produkt
ten jest równie skalowalny i wydajny jak wersje pracujące pod uniksowatymi
systemami operacyjnymi. Mimo znanej niechęci obu korporacji do wzajemnej współpracy,
10g wykorzystuje wiele zaawansowanych możliwości Windows Serwera 2003.
Poza oczywistymi celami stawianymi przed windowsową wersją bazy czyli
skalowalnością i wydajnością, tym razem równie ważne są takie cechy jak
ścisła integracja motoru bazy danych z okienkowym systemem operacyjnym i
warstwą sprzętową. W sumie starania takie podejmowane są już od ponad 10
lat, więc chyba najwyższa pora na jakieś sukcesy. Przypomnijmy że w 1993
roku Oracle była pierwszym profesjonalnym silnikiem bazy danych pracującym w
microsoftowych NT okienkach. Teraz mamy 64 bitową wersję bazy na 64 bitowego
Windowsa!

Meandry architektury 10g pod Windowsem

Tak jak to dzieje się już od wielu lat, funkcjonalność
serwerów bazy danych Oracle nie jest zależna od wyboru płaszczyzny systemu
operacyjnego. Niemniej jednak należy zauważyć, że z każdą kolejną wersją
instalacje windowsowe sięgają coraz to głębiej w głąb microsoftowych
okienek, wykorzystując coraz to bardziej zaawansowane technologie. Przekłada
się to w sposób oczywisty na stabilność pracy wydajności skalowalność.

Wielowątkowość

Podstawową zmianą jaka nastąpiła w wersji 10g jest
odejście od stosowanej w poprzednich wersjach budowy procesowej, na rzecz
architektury opartej na wątkach. Jak wiadomo w implementacjach uniksowych
drugoplanowe procesy wchodzące w skład silnika bazy realizowane są poprzez
uruchamianie na poziomie systemu operacyjnego kolejnych procesów, takich jak:
DBWR, LGWR itd. W podobny sposób w systemie operacyjnym realizowane jest każde
połączenie dedykowane. W architekturze windowsowej wszystkie te zadania
realizowane są jako wątki jednego dużego procesu. Oznacza to w praktyce, że
dla jednego serwera bazy danych uruchamiany jest pod windowsem tylko jeden
proces.

Oczywiście ta zmiana architektury serwera jest zupełnie
niezauważalna dla użytkownika bazy. Nie wpływa ona w żaden sposób na zwiększenie
lub zmniejszenie jej funkcjonalności. Wszystkie beneficja tej zmiany pozostają
po stronie technologii przetwarzania, a więc objawiają się wzrostem wydajności,
stabilności i zarządzalności. Zastąpienie procesów wątkami znacznie
upraszcza lokowanie SGA w systemie Windows, gdyż nie musimy już wykorzystywać
pamięci dzielonej. Dużo szybsza jest też obsługa wątków – choćby
dlatego, że przełączanie pomiędzy wątkami odbywa się szybciej niż przełączanie
procesów. Windows potrzebuje również mniej czasu na wykreowanie wątku i
mniej pamięci operacyjnej, gdyż wątki w znacznie większym (w porównaniu z
procesami) stopniu współdzielą pomiędzy sobą obszary pamięci.

Na marginesie dodać można, że kod realizujący wątkową
architekturę serwera bazy jest znacznie bardziej zwięzły i odizolowany od głównego
kodu serwera.

Serwisy

Kolejną rewolucją architektoniczną w 10g jest fakt,
że nie jest on implementowany w Windowsie jako typowy proces; instancja Oracle
jest teraz serwisem, czyli procesem drugoplanowym uruchamianym podczas startu
systemu w ściśle określonym kontekście systemu zabezpieczeń. Dzięki
wprowadzeniu tych zmian, automatyczne podnoszenie się bazy po restarcie systemu
nie wymaga żadnych działań administracyjnych. Start serwisu bazy danych
Oracla nie powoduje jednak utworzenia wszystkich standardowych wątków
odpowiadających procesom drugoplanowym. Tworzony jest jedynie proces oczekujący
na połączenie inicjujące podniesienie bazy danych (na przykład poleceniem
wydanym w SQL*Plus’ie). Dopiero to polecenie tworzy wątki standardowych
procesów drugoplanowych. Podobnie rzecz się ma podczas zamykania bazy danych.
Zamykane są wątki odpowiadające procesom takim jak LGWR czy DBWR, ale sam
proces serwera bazy jest wciąż aktywny i oczekuje na kolejne polecenie
podniesienia bazy, czyli utworzenia wszystkich elementów instancji Oracle.
Została tu wykorzystana istniejąca już wcześniej możliwość wydawania
poleceń podnoszenia i zamykania baz danych z poziomu poleceń SQL* Plus’a.
Analogicznie zaimplementowany został Listener Oracle Net – z tym, że
Listener będąc serwisem Windowsa, aby odebrać i zrealizować połączenie użytkownika
z bazą, musi być uprzednio uruchomiony. Wszystkie te detale budowy serwera są
oczywiście zupełnie niewidoczne dla użytkownika bazy i prawdę mówiąc nie
od razu rzucają się w oczy administratorom systemu. Ale generalnie o to właśnie
chodziło. Wszystkie te zmiany mają skutkować lepszym wykorzystaniem możliwości
systemu, nie zaś zmianie przyzwyczajeń użytkowników i administratorów bazy.
Powiedzmy więc kilka słów o tym wykorzystaniu technologicznych nowinek
Windowsa.

Dużo więcej RAMu

Zarówno Windows Server 2000 jak i Windows Server 2003
posiadają funkcjonalność zwaną 4GB RAM Tubing (4GT). Funkcjonalność ta umożliwia
aplikacjom szczególnie intensywnie wykorzystującym pamięć RAM, używanie
obszaru o wielkości powyżej 3GB. Przypomnijmy, że pozostałe wersje Windowsa
tę granicę mają ustawioną na poziomie 2GB. W praktyce oznacza to 50% wzrost
maksymalnej wielkości SGA lub zwiększenie się liczby jednoczesnych połączeń.
Właściwość tę w zasadzie zaimplementowano we wszystkich wersjach serwera od
7.3.4 w górę, jednak jej uruchomienie nie następowało w wyniku standardowej
instalacji.

Dużo więcej użytkowników

Wspominając zamierzchłe czasy Oracle 7, Windows NT był w
stanie obsłużyć systemy posiadające ponad 1000 jednoczesnych użytkowników.
Wprowadzenie technologii Shared Server zwiększyło liczbę jednoczesnych użytkowników
dziesięciokrotnie. Kolejny wielki skok na skali liczby użytkowników jednej
„windowsowej” bazy, to technologia RAC umożliwiająca dostęp do
plików tej samej bazy danych przez kilka serwerów jednocześnie.

Tak prawdę mówiąc, ten ostatni zabieg jest raczej obejściem
granicy niż jej poszerzeniem, ale niech tam…

VLM

Konfiguracja Very Large Memory, to osiągnięcie Windowsa
2000 i jego następcy Windowsa 2003, wykorzystane przez Oracle już w wersji 8i.
Ale dopiero 10g przełamała 2 GB granicę ustanowioną przez 32-bitowe
wersje Windowsa. Teraz pojedyncza instancja Oracle może wykorzystywać nawet 64
GB, o ile system operacyjny jest w stanie to obsłużyć. Tak olbrzymie
poszerzenie obsługiwanego obszaru pamięci pozwala na alokację ogromnej liczby
buforów, co w konsekwencji minimalizuje liczbę odwołań do zasobów
dyskowych.

Technologicznie rozpatrując to zagadnienie, 10g
wykorzystuje zaimplementowany zarówno w Windows 2000 jak i 2003 API Address
Windowing Extensions (AWE). API umożliwia ominięcie bariery 3 GB, a w połączeniu
z nowoczesną technologią procesorów Xeon, umożliwia użycie szybkich
interfejsów mapujących całą dostępną w serwerze pamięć RAM. Jednym słowem,
olbrzymie bufory Oracla dzięki Windowsowemu AWE.

Large Page

Jest to nowinka zarówno w Windowsie jak i w Oraclu.
Funkcjonalność przygotowana przez Microsoft zarówno w 32 jak i 64 bitowej
wersji, dla aplikacji mających szczególnie duży apetyt na zasoby pamięci.
Dzięki szybkiej implementacji nowych możliwości systemu operacyjnego, 10g
w większym stopniu wykorzystuje zasoby pamięci. W konfiguracji systemu umożliwiającej
obsługę dużych stron pamięci „Large Pages”, CPU znacznie
szybciej uzyskuje dostęp do buforów bazy danych Oracle. Oprócz standardowej
dla 32-bitowych systemów 4KB strony pamięci i odpowiednio dla systemów
64-bitowych strony pamięci o rozmiarze 8KB, mamy teraz do dyspozycji również
strony o rozmiarze od 4 do 16 MB! Wykorzystanie tej funkcjonalności wymaga
ustawiania w rejestrze klucza ORA_LPENABLE na wartość 1. Oczywiście jest to
propozycja dla naprawdę dużych SGA, osiągających rozmiary kilku czy
kilkunastu GB.

Fibers zamiast threads

Dopiero co przekonywałam o wyższości wątków nad
procesami, a tu nagle kolejna gradacja wewnętrznej architektury serwera.
Zamiast wątków (threads) mamy… powiedzmy… włókna (fibers), których użycie
w określonych konfiguracjach po raz kolejny poprawia wydajność przetwarzania.
Tak jak wątki z punktu widzenia CPU były „szybsze w obsłudze” niż
procesy, tak z kolei obsługa „włókien” jest szybsza niż obsługa
wątków. Odczuwalne jest to zwłaszcza w przypadku dużych aplikacji.
Funkcjonalność tę włącza się edytując pliki konfiguracyjne, gdyż domyślnym
ustawieniem serwera 10g jest architektura oparta na przetwarzaniu wątkowym.

Fibers czyli włókna, to pomysł twórców Windowsa nieco
podobny do wątków. Różnica pomiędzy nimi polega na tym, że włókna mogą
być sterowane (kreowane lub zamykane) przez użytkownika, a właściwie przez
życie wewnętrzne aplikacji. Wątki są tworzone i zamykane z poziomu systemu
operacyjnego. Tak więc wykorzystując architekturę przetwarzania opartą o włókna,
to aktualny stan bazy oraz zadania stawiane w danej chwili przed serwerem bazy
decydują o wykreowaniu nowych włókien i uruchomieniu określonego fragmentu
kodu serwera.

Affinity i priority czyli priorytety i przypisania

Dzięki lepszej integracji serwera 10g z Windowsem,
administrator bazy może wpływać na modyfikację parametrów priority i
affinity. Służą one najprościej rzecz ujmując, zapewnieniu procesom lub wątkom
odpowiedniego priorytetu ważności, uwzględnianego w kolejkowaniu zadań
przetwarzanych przez procesor lub do przypisywania procesów lub wątków do
konkretnych zasobów w celu zapewnienia im ciągłego do nich dostępu. Oczywiście
parametry te odnoszą się do procesów i wątków, czyli ustawiane i
realizowane są na poziomie systemu operacyjnego. Administrator serwera 10g
będzie jednak mógł ingerować w te parametry poprzez ustawianie kluczy
ORACLE_PRIORITY i ORACLE_AFFINITY. Możemy sobie zatem wyobrazić, że jeśli
administrator wie, iż planowane przez niego przetwarzanie obciąży szczególnie
jeden z procesów drugoplanowych, wtedy może przypisać mu wysoki priorytet
zapewniający wzrost wydajności dla tej szczególnej operacji. W podobny sposób
można w bardziej rozbudowanych maszynach przypisać procesowi serwera lub
wybranemu wątkowi na przykład jeden z dostępnych w maszynie procesorów lub
całą ich grupę, zapewniając w ten sposób stałą wydajność bez względu
na intensywność pozostałych zadań realizowanych przez tę maszynę.

NUMA

NUMA skrót od Non-Uniform Memory Access jest funkcjonalnością
zaimplementowaną w Windows Server 2003 i Oracle 10g. Wyobraźmy sobie środowisko
przetwarzania rozproszonego złożone z wielu komputerów, charakteryzujących
się różną architekturą sprzętową. Mamy w takim przypadku do czynienia z
koniecznością zarządzania zasobami z uwzględnieniem ich parametrów
technicznych, czyli składania obszaru elementów RAM o różnej prędkości.
Zadanie to realizuje właśnie maszyna NUMA, która przydziela bazie
najwydajniejszy obszar dostępnej w danej chwili pamięci operacyjnej.
Integracja systemu operacyjnego z 10g jest na tyle zaawansowana, iż w
momencie uruchomienia maszyny NUMA, w serwerze bazy automatycznie ustawiana jest
wartość klucza ORACLE_AFFINITY zapewniająca już w chwili startu serwera bazy
maksymalne wykorzystanie zasobów maszyny. Ponadto podczas alokacji obszaru SGA
i PGA, maszyna NUMA dokonuje przydziału najbardziej wydajnych obszarów dostępnej
pamięci, a tworzenie wątków lub włókien DBWR rozmieszczane jest w taki sposób,
aby na każdej maszynie tworzącej środowisko rozproszone uruchomiona była
jedna jego instancja.

64 bity Windowsa i Oracla

Serwer 10g jest pierwszą komercyjną bazą danych
wykorzystującą 64-bitową wersję Windows Server 2003 i możliwości
architektury procesorów Intel Itanium.

Podobnie jak to ma miejsce z 64-bitowymi wersjami serwera
Oracle pracującymi pod systemami unikowymi, 64- bitowa windowsowa wersja Oracle
umożliwia realizację większej liczby jednoczesnych połączeń do bazy,
alokacje większej ilości pamięci operacyjnej i uzyskanie większej wydajności
przetwarzania. Do najważniejszych zalet należy tu zaliczyć duży obszar cachu
dostępnego w architekturze procesorów Itanium i zniesienie obowiązującego w
systemach 32-bitowych ograniczenia wielkości pamięci do 4GB, co pozwala
serwerom bazy na sprawne przetwarzanie szczególnie dużych transakcji lub
funkcji z obszaru business intelligence. Jednym słowem, wszystkie zalety
64-bitowego Windowsa uruchomionego na Itanium są nie tylko dla Oracle dostępne
ale i w zasadzie nie absorbują uwagi zarówno programistów jak i administratorów.
Dzięki zastosowaniu optymalizatora PGO (Profile-Guided Optimization) serwer
bazy zyskał 15-25% wzrost wydajności przetwarzania.

Co ważne, migracja pomiędzy serwerem 32 a 64-bitowym nie
wymaga żadnych prac związanych z przebudową bazy. Wystarczy przekopiować
pliki bazodanowe do 64 bitowej instalacji serwera i uruchomić kilka skryptów
aktualizujących słownik bazy.

Obsługa I/O

Kolejne zmiany mające znaczący wpływ na wydajność 10g
nastąpiły w obszarze obsługi I/O. Przebudowany został kod obsługujący duże
pliki, pliki typu raw (raw files), oraz pliki klastrowane. System klastrowania
plików Oracle jest integralną częścią 10g, dzięki czemu instalacja
klastrów jest w tej wersji znacznie uproszczona. Dzięki wykorzystaniu
64-bitowej obsługi plików w Windowsie, pokonana została również 4GB granica
wielkości pliku bazodanowego. 64-bitowe pliki I/O wywołały również
zniesienie granicy wielkości pliku, wynoszącej poprzednio 2 lub 4 GB. Prawdę
mówiąc limity te wynikały bezpośrednio z założeń przyjętych przez
projektantów Oracle i występowały na wszystkich platformach. Obecnie granice
te ustanowione zostały na poziomie 4 milionów bloków w pliku, przy
maksymalnym rozmiarze bloku równym 16KB i 64K plików w bazie danych. Parametry
te umożliwiają tworzenie plików bazodanowych o maksymalnej wielkości 64GB,
co daje nam maksymalny rozmiar bazy przy 16KB bloku wynoszącym 4 petabajty.

Raw files czyli pliki surowe

Pliki surowe, to koncepcja znana od dawna w środowisku
uniksowym, z tym że mówimy wtedy o tak zwanych „raw devices”.
Teraz podobna idea zaimplementowana została w środowisku Windows. Pliki surowe
to nic innego, jak niesformatowane partycje dysku używane przez bazę jako
jeden duży plik. Zaletą takiego zapisu danych na dysku jest pominięcie części
procedur komunikowania się z zasobami dyskowymi za pośrednictwem systemu
operacyjnego. Wadą tego rozwiązania jest utrudniona obsługa tych zasobów
dyskowych, zwłaszcza w kontekście procedur backupowych. Jest to zdecydowanie
propozycja dla bardzo dużych baz danych i instalacji typu RAC, nie wykorzystujących
mechanizmów CFS.

Reasumując: Oracle 10g to już nie windowsowa imitacja funkcjonalności
serwerów pracujących pod uniksem; to produkt zintegrowany z nie lubianymi, ale
wciąż popularnymi okienkami. Produkt starający się wykorzystać wszelkie
nowe i stare zalety tego systemu.