Baza danych Oracle w wersji 11g imponuje wydajnością, wspomaganiem zarządzania, efektownym testowaniem aplikacji, łatwością utrzymywania bazy w dobrej kondycji oraz możliwościami zmniejszenia zapotrzebowania na pamięć masową.

Użytkownicy bazy danych Oracle mogą oczekiwać różnorodnych ulepszeń w Oracle Database 11g, zmieniających sposób ich współdziałania z bazą danych. Jednak już sam mechanizm Real Application Testing jest na tyle przekonujący, że może być wystarczającym argumentem za podjęciem decyzji o uaktualnieniu. Przy częstych zmianach w kodach aplikacji istnieje potrzeba solidnego ich sprawdzania, bez oddziaływania na środowisko produkcyjne. To właśnie umożliwia mechanizm Real Application Testing, który pozwala na przechwytywanie stanów aplikacji i odtwarzanie ich na tym samym sprzęcie lub na innym, a następnie porównanie wyników wydajności.

Innymi, nowymi ważnymi mechanizmami w Oracle Database 11g są: Snapshot Standby, Active Data Guard, Advanced Compression, ulepszenie w zarządzaniu zasobami, strojenie SQL i kontrola kondycji bazy danych.

Active Data Guard, choć trochę kłopotliwy z powodu trudnej instalacji i słabej dokumentacji (przynaj-mniej na platformie Windows), to jest bardzo przydatny dla każdego administratora bazy danych (DBA), który musi włączać rezerwową bazę danych, pracującą na jałowych obrotach. Także nowy mechanizm Snapshot Standby w Data Guard ma pomagać administratorom w sterowaniu zmianami lub testowaniu aplikacji.

Do wdrażania Advanced Compression trzeba podchodzić ostrożnie, ponieważ jest kosztowna, jednak poprawnie wdrożona może pomóc w osiągnięciu wysokiego poziomu deduplikacji danych.

Result Cache jest kolejnym nowym mechanizmem, który może zapewnić pożądane rezultaty, jeśli jest odpowiednio używany. Testy pokazały, że dla uzyskania dobrych wyników potrzebne są: właściwe zrozumienie tej technologii, jasne zdefiniowanie swoich celów i praca w ramach ograniczeń stawianych przez system. Także automatyczne monitorowanie kondycji bazy danych i kontrola uszkodzeń danych to zalety tego wydania.

W sumie wersję 11g bazy Oracle można uznać za bardzo udaną, oferuje ona wiele nowych mechanizmów, które mogą odpowiadać zarówno małym, jak i większym organizacjom.

Strojenie bazy danych

Database 11g początkującym udostępnia samouczący się automat strojenia SQL. Silnik SQL potrafi wykrywać mocno obciążające wyrażenia SQL, by można je było wykorzystać do strojenia silnika w czasie konserwacji. Niektóre poprawki może przeprowadzać automatycznie lub sugerować zmiany strukturalne, takie jak indeksy. Automatyczny zakres strojenia można też ograniczyć, pozwalając silnikowi przechwytywać kwerendy i sugerować poprawki.

Istnieje wiele sposobów kwantyfikowania obciążeń, których nie daje się opanować. Obciążenia okazują się zbyt wielkie zazwyczaj z powodu problemów wydajnościowych w jednym z trzech głównych elementów serwera: CPU, pamięci i we/wy pamięci masowej. Zarządzanie zasobami pozwala ocenić nadmierne obciążenia, przeważnie poprzez pomiar używania CPU lub pamięci operacyjnej, ale Oracle Database 11g może także ustanawiać ograniczenia sesyjne we/wy.

Pozwalają one specyfikować maksymalne wartości obciążenia połączenia (w postaci liczby zleceń we/wy lub megabajtów), jakie dopuszcza się na serwerze. Ograniczenia we/wy są istotne zwłaszcza dla dużych hurtowni danych, ponieważ systemy te mogą łatwo osiągać graniczne wartości dla transmisji dyskowych, a ograniczenia zasobów CPU i pamięci nie rozwiązują odpowiednio problemu rywalizacji o dysk.

Ograniczenia te mogą także pomóc DBA w kończeniu długo przetwarzanych kwerend, gdyż nie ma sposobu naturalnego zdefiniowania polityki, która kontrolowałaby, czy kwerenda używa np. 20% CPU w ciągu 20 minut. Takie kwerendy, jeżeli zaczynają stanowić problem, można też przesunąć do grupy zasobów o niższym priorytecie.

Buforowanie wyników kwerend

Result Cache (bufor wyników) jest mechanizmem, który pozwala na efektywne wpisywanie wyników kwerendy do pamięci podręcznej w celu ponownego wykorzystania w przyszłości, do kolejnego wywołania tej samej kwerendy. Można w ten sposób buforować całe kwerendy, subkwerendy lub nawet funkcje PL/SQL. Wywołanie kwerendy musi być jednak takie same jak w wersji buforowanej - i w tym właśnie tkwi problem. Bardzo często kwerendy różnią się jedynie parametrami (zwłaszcza większość kwerend OLTP), można więc mieć bardzo dużo buforowanych kwerend i niewielkie możliwości ich ponownego wykorzystania.

W tym celu Oracle daje użytkownikowi trzy różne poziomy, na których można specyfikować buforowanie wyników: poziom bazy danych, sesji i kwerendy. Opcje te zapewniają dużo różnych możliwości: zarówno korzystnych, jak i niekorzystnych. Na początek, dopóki nie przetestuje się gruntownie poziomu bazy danych, dopóty lepiej korzystać z poziomu sesji lub kwerendy. Na poziomie bazy danych wszystkie wyniki kwerend będą buforowane, również te zbędne. Ponadto bufor wyników domyślnie jest przydzielany jako dość mała porcja całego bufora i mało prawdopodobne jest uzyskanie dobrych wyników, jeżeli nie poszerzy się tego przydziału.

Podczas testów na początek przeprowadzono kilka kwerend i można było zaobserwować lepsze wyniki czasów ich wykonania. Po znacznym zwiększeniu liczby kwerend i ich sparametryzowaniu, takich zmian już nie zaobserwowano. Jednak nie można tego uważać za wadę mechanizmu. Po prostu przed wykorzystaniem tych możliwości trzeba przygotować staranny plan i przetestować je przed oddaniem systemu do produkcji.

Jeżeli pojawiają się problemy z pamięcią, wykrojenie bufora w już ograniczonym systemie może tylko pogorszyć sytuację. Buforowanie wyników obejmujących wiele milionów wierszy nie jest najlepszym wykorzystaniem istniejącej pamięci.

Result Cache może natomiast być wykorzystywana do wywoływania kłopotliwych kwerend, które opierają się na przeszukiwaniu całych tablic.

Usuwanie uszkodzeń bazy danych

Oracle Database 11g zapewnia skuteczne monitorowanie i odtwarzanie uszkodzonych rekordów, a także wydajności kwerendowania. Automatyczne monitorowanie "kondycji zdrowotnej" jest wartościowym mechanizmem, ponieważ zapewnia zarówno kontrole reaktywne, jak i ręczne. Kontrole reaktywne są uruchamiane, gdy pojawi się błąd krytyczny. Mogą one sprawdzać strukturę bazy danych, integralność bloków danych i inne stany. W wyniku takich kontroli tworzone są raporty i bardzo często sugerowane poprawki.

Z kolei mechanizm Fast Analyze to lekarstwo na jeden z większych problemów, jaki napotykają administratorzy dużych baz danych. Pozwala on na skanowanie wyszukujące uszkodzenia indeksów dużo szybciej niż dotychczas. Jest to szczególnie ważne zważywszy, iż większość tego typu zabiegów jest realizowana w czasie konserwacji, i jeżeli wtedy nie uda się operacja analizy, to cóż dopiero mówić o naprawieniu uszkodzenia!

Snapshot Standby

Data Guard jest technologią zapewniającą transakcyjnie kompletną gotowość bazy danych w razie katastrofy. Chroni przed wszystkimi rodzajami uszkodzeń systemu i sieci, i nie jest ograniczona lokalizacją. Rezerwa bazy danych może być umiejscowiona w tym samym pomieszczeniu lub oddalona o tysiące kilometrów. Jednak, podobnie jak inne rozwiązania do obchodzenia uszkodzeń, w tym zdalny mirroring i lokalny klastering, rezerwa taka jest całkowicie bezczynna i niedostępna w czasie, gdy pierwotna baza danych jest online.

Nowy mechanizm Data Guard, o nazwie Snapshot Standby, pozwala na postawienie rezerwowej bazy danych w przejściowy tryb czytaj/pisz, pozwalający na testowanie zmian w bazie danych przy jednoczesnym zapewnieniu pełnej ochrony HA/DR (High Availability/Disaster Recovery). Sam mechanizm może radykalnie zmienić sposób zarządzania dobrymi praktykami związanymi z projektowaniem bazy danych, kontrolą zmian, uaktualnianiem aplikacji i powiązanych z tym zadań.

Jeżeli trzeba wykonać większe zmiany, np. w procedurach składowanych w bazie danych, to problem polega na tym, że bez przetestowania tego na produkcyjnych obciążeniach trudno wyrobić sobie pogląd, w jakim zakresie, jeżeli w ogóle, takie zmiany polepszą wydajność systemu. Łącząc Snapshot Standby z Database Replay, można testować nieograniczone scenariusze. Wystarczy przełączyć rezerwową bazę danych w tryb czytaj/pisz i dokonać w niej zmiany. Następnie można odtworzyć obciążenia w rezerwowej bazie danych i porównać uzyskane wskaźniki wydajności z tymi osiąganymi wcześniej.

Kiedy rezerwę przestawia się w tryb Snapshot Standby, to zatrzymuje się rejestrowanie zmian z pierwotnej bazy danych (zmiany są nadal przesyłane, ale nie są rejestrowane). Gdy zakończy się testowanie, rezerwa może być ponownie przywrócona do stanu "czytaj", w którym automatycznie usuwane są wszystkie zmiany oraz następuje powrót do stanu sprzed rozpoczęcia testowania, i następnie rejestruje się wszystkie oczekujące zmiany z bazy produkcyjnej.

Istnieje wiele innych scenariuszy, gdzie funkcja Snapshot Standby może okazać się bardzo przydatna - od lokalizowania problemów produkcyjnych po strojenie indeksów i partycjonowanie dysków. Mechanizm ten może być użyty do testowania składowania i reorganizacji indeksów w czasie intensywnego użytkowania bazy danych.

Istnieją też inne praktyczne zastosowania. Jednym z największych problemów DBA jest trzymanie analityków, projektantów i innych osób z dala od systemów produkcyjnych. Przeważnie przydziela się im inny serwer i utrzymuje się go w synchronizacji z produkcyjną bazą danych - zazwyczaj drogą składowania i odtwarzania lub replikacji. Korzystając z mechanizmu Snapshot Standby, można to wszystko wykonywać w jednym systemie.