Oracle XE, Standard, Enterprise – którą wersję bazy danych

Oracle XE, Standard, Enterprise – którą wersję bazy danych

XVII Konferencja PLOUG
Kościelisko
Październik 2011
Oracle XE, Standard, Enterprise – którą
wersję bazy danych wybrać aby nie
przepłacić
Mariusz Masewicz
e–mail: [email protected]
Abstrakt. Kupując licencję serwera bazy danych Oracle mamy do wybory wiele opcji. Począwszy od wersji Express Edition (XE),
poprzez warianty Standard Edition a na Enterprise Edition skończywszy. O wyborze wariantu droższego decyduje jego funkcjonalność,
natomiast za wariantem tańszym przemawia zdecydowanie niższa cena.
W tym artykule postaramy się przeanalizować możliwości poszczególnych wersji. Zastanowimy się nad tym, które z rozszerzeń dostępnych w droższej opcji są warte „grzechu”, a które nawet mimo ich braku w wersji tańszej dają się w pewnych sytuacjach zastąpić mniej
lub bardziej niekonwencjonalnym zastosowaniem mechanizmów z wersji niższej.
Coraz częściej zdarza się, że firmy staja przed kolejnymi wyznaniami dotyczącymi składowania, przeszukiwania, czy tez analizowania
danych. Aby sprostać tym wyznaniom potrzebują coraz wydajniejszych a przez to coraz bardziej wyrafinowanych mechanizmów. Najważniejsze z tych wyzwań, to zapewnienie wysokiej dostępności (Data Guard), wydajności (RAC), efektywnego składowania dużych
zbiorów danych (partycjonowanie), oraz ich efektywnego przeszukiwania (operacje równoległe). Do tego coraz częściej wdrażane są
rozwiązania typu Hurtownie Danych, dla których opracowano szereg wyrafinowanych mechanizmów zwiększania wydajności – od
indeksów bitmapowych począwszy, a na perspektywach zmaterializowanych z mechanizmem przepisywania zapytań skończywszy. Jeżeli
to tego dołożymy chęć ciągłego monitorowania systemu i automatyzacji procesu jego strojenia, to okazuje się, że komplet narzędzi może
zapewnić nam tylko licencja Enterprise z wykupionymi dodatkowymi pakietami.
Po wykonaniu analizy potrzebnych funkcjonalności nadchodzi moment refleksji – czy faktycznie to co oferuje najdroższa wersja wykorzystamy w 100% i czy przypadkiem nie można przynajmniej części z wymienionych powyżej funkcjonalności zasymulować stosując
prostsze mechanizmy?
W niniejszym artykule zebrano odpowiedzi na powyższe pytania. Zaprezentowano też rozwiązania, których wdrożenie pozwoliło zaoszczędzić sporo pieniędzy. Przy czym należy tu zaznaczyć iż w większości przypadków oszczędność taka nie oznaczała całkowitej rezygnacji z zakupu droższych wersji licencji. Wdrożenie proponowanych tu rozwiązań pozwoliło w kilku przypadkach na odsunięcie takiego
wydatku w czasie o kilka lat.
Oracle XE, Standard, Enterprise – którą wersję bazy danych wybrać aby nie przepłacić
65
1. Wersje, edycje, funkcjonalność, cena…
Obecnie możemy wybierać spośród 5 różnych wariantów licencji dla bazy danych Oracle. Różnią się one między sobą ceną, funkcjonalnością i zakresem zastosowań. Zgodnie z definicjami zawartymi w [ORA11gLIC] dostępne edycje to:
• Oracle Database Standard Edition – podstawowa wersja oprogramowania serwera bazy
danych Oracle, zapewniająca łatwe i efektywne zarządzanie składowanymi danymi. Licencja
pozwala na instalację oprogramowania wykorzystującą maksymalnie 4 procesory (w wariancie licencjonowania per-procesor). Ciekawostką jest fakt, iż te 4 procesory mogą stanowić
wyposażenie różnych komputerów połączonych przy pomocy Oracle Real Application
Clusters (Oracle RAC). Przeznaczona głownie dla małych i średnich zastosowań, gdzie nie są
wymagane zaawansowane funkcje dodawane w formie dodatkowych pakietów do wersji
Enterprise.
• Oracle Database Standard Edition One – funkcjonalność podobna jak w wersji Standard
Edition. Z głównych różnic należy tu wymienić ograniczenie liczby wykorzystywanych procesorów do 2 oraz brak możliwości stosowania RAC. Ograniczenie sprzętowe oraz brak możliwości skonfigurowania środowiska o podwyższonej niezawodności (RAC) sprawia, że jest
to doskonały wybór dla przechowywania i przetwarzania mniejszych zbiorów danych. Dodatkowym atutem tego rozwiązania jest jego zdecydowanie niższa cena niż wersji Standard
Edition.
• Oracle Database Express Edition – najmniejszy i najtańszy produkt z rodziny serwerów
baz danych Oracle. Posiadający funkcjonalność zbliżoną do wersji Standard Edition, ale dodatkowo ograniczoną możliwościami wykorzystania zasobów sprzętowych serwera (1 procesor, 1GB pamięci, 4GB1 lub 11GB2 danych użytkownika składowanych w tej wersji bazy danych). Największą zaletą tego produktu jest jego cena – a dokładniej jej brak, gdyż jest bezpłatny do praktycznie wszelkich zastosowań (w tym także komercyjnych). Idealna jako serwer dla małych baz danych – jako zamiennik współużytkowanych arkuszy kalkulacyjnych,
osobistych baz danych, ale także jako silnik dla małych serwisów WWW (zwłaszcza w połączeniu ze środowiskiem Oracle Application Express). Oracle nie oferuje wsparcia dla użytkowników tej wersji bazy danych.
• Oracle Database Enterprise Edition – największa i najdroższa wersja oprogramowania.
Oprócz tego co oferuje wersja Standard zawiera dziesiątki dodatkowych funkcjonalności,
które sprawiają, że jest to doskonały wybór dla dużych baz danych, lub też dla baz danych
w których wykonuje się zaawansowane operacje na danych. Rozbudowana funkcjonalność
może być dodatkowo rozszerzana przez szereg opcjonalnych pakietów i opcji: Oracle Active
Data Guard, Oracle Advanced Compression, Oracle Advanced Security, Oracle Data Mining,
Oracle Database Vault, Oracle In-Memory Database Cache, Oracle Label Security, Oracle
On-Line Analytical Processing (OLAP), Oracle Partitioning, Oracle RAC One Node, Oracle
Real Application Clusters (Oracle RAC), Oracle Real Application Testing, Oracle Spatial,
Oracle Total Recall. Niektóre z tych pakietów mają za zadanie ułatwić życie administratorom, inne z kolei dodają do serwera bazy danych funkcjonalność znacząco zwiększającą jej
funkcjonalność, niezawodność, czy wydajność. Niestety – praktycznie nieograniczone możliwości tego wariantu przeciwstawiane są zawsze jego wysokiej cenie powiększonej dodatkowo o koszty dodatkowych pakietów/opcji.
• Oracle Database Personal Edition – jak sama nazwa wskazuje – wersja przeznaczona do
wykorzystania przez jednego użytkownika – jako jego baza osobista, czy to jako serwer do
testowania tworzonych właśnie aplikacji, czy tez jako składnica prywatnych danych. Funk1
2
W wersji 10g XE
W wersji 11g XE
66
Mariusz Masewicz
cjonalnością odpowiada wersji Enterprise (z wyjątkiem tych, które wymagają współpracy
wielu serwerów: np. RAC, oraz zawaansowanych opcjonalnych pakietów ułatwiających administrację: Management Pack).
Jak wspomniano powyżej – podstawowym produktem, od którego należy rozpocząć rozważania
związane z zakupem licencji bazy danych Oracle jest zawsze wersja Standard Edition. Po przeanalizowaniu wszystkich potrzeb i skonfrontowaniu ich z możliwościami finansowymi można podjąć
decyzje o zakupie wersji Enterprise, a może o wyborze wersji XE. Dochodzi jednak do sytuacji,
w których potrzeby kierują nas w stronę wersji Enterprise, a budżet utrzymuje na poziomie wersji
XE. W dalszej części artykułu zostanie omówionych kilka metod, na całkowicie legalne „obejście”
ograniczeń licencyjnych występujących w wersjach niższych i pozwalających opóźnić zakup wersji
droższej.
2. Pierwsza migracja – z wersji XE do wersji Standard
Wersja Express Edition została przedstawiona we wstępie do tego artykułu jako świetny wybór
dla małych baz danych, do których dostęp mają pracownicy jednego departamentu. Jeżeli do tego
dołoży się środowisko Oracle Application Express – to uzyskuje się tanie i wydajne rozwiązanie,
które w wygodny sposób udostępnia składowane w nim dane.
W przypadku wersji XE dość szybko można się zetknąć z problemami związanymi z dość rygorystycznymi ograniczeniami nałożonymi na możliwość wykorzystania zasobów sprzętowych serwera. Jeden procesor i 1GB pamięci operacyjnej pozwolą na wydajne przetwarzanie niewielkich tabel,
w których liczba rekordów rzadko przekracza milion. O ile proste zapytania nie są tu problemem,
o tyle wszelkie operacje związane z łączeniem tabel, sortowaniem, wyliczaniem agregatów – które
najefektywniej wykonałyby się w pamięci operacyjnej serwera, tutaj ze względu na ograniczenia
będą musiały wykonywać się z wykorzystaniem tymczasowej przestrzeni tabel na dysku. Czy to
oznacza, że to rozwiązanie nie jest wydajne? Ależ skąd – wystarczy tylko zadbać o to, aby ilość
danych przetwarzana przez zapytanie była możliwie mała. A jak to osiągnąć?
• zbędne rekordy – o ile ciągle są potrzebne w bazie danych przenosić do tabelek przeznaczo-
nych na dane „archiwalne”, jeżeli jednak nie są w niczym potrzebne – usunąć z bazy danych.
Oczywiście najlepiej, gdy projekt aplikacji uwzględnia tego typu operacje na danych. Ale
w końcu każda baza (a dokładniej przygotowana dla niej aplikacja), nawet te słynące z super
wydajności w przetwarzaniu wielkich wolumenów danych, musi być przygotowana na to, że
kiedyś może ulec pod naporem zgromadzonych w niej danych,
• zadbać o utworzenie właściwych indeksów, przeliczenie statystyk – czyli tradycyjne metody
optymalizacji wykonywania pojedynczych zapytań, czy wręcz strojenia całej bazy danych.
Co jednak w przypadku kiedy problemem jest brak miejsca w bazie danych? W końcu
4GB/11GB to z jednej strony bardzo dużo – gdy mówimy o danych tekstowych, liczbach, czy datach, ale z drugiej strony bardzo niewiele, gdy wpadniemy na pomysł przechowywania w bazie
danych treści multimedialnych – obrazy, audio, czy wręcz wideo. Licencja i ograniczenia techniczne nie pozwolą na skonfigurowanie na serwerze kolejnych baz w wersji XE, żeby w ten sposób
uzyskać zwielokrotnienie dostępnej pojemności na dane użytkownika. Ale od czego jest wirtualizacja? Nic nie stoi na przeszkodzie aby zwielokrotnić liczbę serwerów i na każdym z nich zainstalować bazę danych w wersji XE. Nie łamiąc licencji możemy uzyskać w ten sposób praktycznie nieograniczoną pojemność. Otwartym pozostaje jednak pytanie, o sensowność tego rozwiązania
w którym, oszczędzając na kosztach licencji musimy zainwestować w zasoby sprzętowe w celu
zapewnienia odpowiedniego poziomu wirtualizacji oraz musimy stworzyć wydają i niezawodną
warstwę zarządzania takim ciekawym środowiskiem rozproszonego przetwarzania danych.
Czego w takim razie na pewno nie wolno nam zrobić z wersją XE? Nie można wykorzystać instalacji tej bazy danych jako metody obejścia ograniczeń licencyjnych dotykających wersje płatne.
Jednym z takich pomysłów jest wykorzystanie bazy danych Oracle XE i zbudowanej na niej aplika-
Oracle XE, Standard, Enterprise – którą wersję bazy danych wybrać aby nie przepłacić
67
cji WWW (na przykład w technologii APEX) jako serwera proxy do właściwej składnicy danych
jaką jest baza danych w wersji Standard/Enterprise w przypadku, gdy te „duże” bazy danych są
licencjonowane w modelu „na użytkownika”. Licencja bazy XE nie nakłada ograniczeń na liczbę
użytkowników korzystających z takiej bazy danych, natomiast licencje wersji płatnej w przypadku
modeli licencjonowania „na użytkownika” wyraźnie precyzują, czym w rozumieniu takiej bazy
danych jest użytkownik. W dużym skrócie jest każda osoba, system, urządzenie, … uzyskujące
dostęp do bazy danych. Jeżeli użytkownicy uzyskują dostęp do danych zgromadzonych w bazie
danych za pomocą serwera aplikacyjnego, czy innego mechanizmu Proxy, to wówczas użytkownikiem bazy danych nazywamy użytkownika takiego rozwiązania, nawet mimo tego, że serwer aplikacyjny uzyskuje dostęp do bazy danych z wykorzystaniem jednego współdzielonego konta użytkownika.
3. Wersja Standard – co zyskujemy
We wstępie do artykułu wspomniano, że wersja standard posiada funkcjonalność pozwalającą jej
na efektywne przetwarzanie zgromadzonych w niej danych. Jej funkcjonalność pozwala na bezpieczne i w miarę wydajne obsługiwanie powierzonych jej danych. Znajdziemy w niej:
• podstawowe struktury składowania i optymalizowania dostępu do danych – tabele relacyjne,
i indeksy typu B*-drzewo,
• dane możemy chronić przed utratą wykonując ich kopie zapasowe programem RMAN,
• dodatkowo pełna wersja Standard pozwoli na zbudowanie wydajnego i bezpiecznego klastra
– RAC,
• programiści będą mogli w swoich aplikacjach wydajnie wykorzystać możliwości tej wersji
bazy danych dzięki wsparci dla platformy .NET, Javy, czy PHP,
• jeżeli z różnych powodów przyjdzie nam do głowy replikować składowane dane – w cenę li-
cencji wliczono mechanizm standardowej replikacji bazującej na perspektywach materializowanych oraz mechanizm Streams,
• po dokupieniu dodatkowej licencji dla mechanizmu Oracle Gateways taką replikację będzie-
my mogli zdefiniować także między bazami pochodzącymi od innych dostawców (Microsoft,
IBM, Sybase, …).
W porównaniu do wersji XE otrzymujemy możliwość wykorzystania 4 razy większej liczby
procesorów, praktycznie nieograniczonej ilości pamięci operacyjnej (ograniczeniem są tu głownie
możliwości sprzętowe) i brak ograniczeń dotyczących rozmiaru składowanych danych.
Do powyższych zalet należy doliczyć możliwość skorzystania z pomocy asysty technicznej firmy Oracle – co w przypadku wielu zakupów decyduje właśnie o wyborze rozwiązań płatnych zamiast być może wystarczających funkcjonalnie, ale pozbawionych wsparcia produktów bezpłatnych.
Dużym atutem wersji Standard jest też opcja RAC wliczona w cenę licencji – nie mają jej wersje
„mniejsze” niż Standard, natomiast w przypadku wersji Enterprise za możliwość zbudowania klastra zwiększającego wydajność i niezawodność całego środowiska należy słono dopłacić, gdyż jest
on dodatkowo płatną opcją.
Wraz z licencją na dowolną płatną wersję bazy danych firma Oracle dodatkowo pozawala wykorzystać:
• narzędzie Oracle Internet Directory – jako mechanizm zarządzający danymi dla mechanizmu
Oracle Directory Naming (inne zastosowania OIDa mogą wymagać zakupu licencji na ten
produkt),
68
Mariusz Masewicz
• kontener aplikacji JEE – OC4J – jako silnik dla aplikacji Oracle Enterprise Manager (Data-
base Control i Grid Control), serwletów związanych z opcjami: Advanced Queuing, Ultra
Search, Application Express, oraz Warehouse Builder,
• serwer WWW – Oracle http Server – o ile jest on zainstalowany i skonfigurowany na tej sa-
mej maszynie ma której uruchomiono licencjonowaną wersję serwera bazy danych,
• dodatkową instalację bazy danych Oracle, o ile jest ona wykorzystywana tylko jako re-
pozytorium narzędzi: katalog odtwarzania RMAN oraz repozytorium Oracle Enterprise Manager Grid Control.
4. Wersja Standard – czego tu brakuje
Jak już wielokrotnie wspomniano – wersja Standard ma zapewniać podstawową funkcjonalność
serwera bazy danych. Wszystko to, co zdaniem twórców tej bazy danych stanowi wartość dodaną
do mechanizmów składowania, wyszukiwania, udostępniania danych – znalazło się w wersji Enterprise. Tak więc w wersji standard nie znajdziemy:
• zaawansowanych struktur wspierających składowanie i wyszukiwanie danych: klastry, tabele
indeksowe, indeksy bitmapowe, bitmapowe indeksy połączeniowe, mechanizmy przebudowywania indeksów i schematów tabel w czasie działania systemu (on-line), tabel i indeksów
partycjonowanych, brak tu także opcji kompresji danych,
• zaawansowanych mechanizmów wspierających tworzenie kopii zapasowych: kompresja nie-
używanych bloków, mechanizm śledzenia zmieniających się bloków, zwielokrotnionych zestawów kopii zapasowych, odtwarzania pojedynczych bloków danych, w tym także automatycznego odtwarzania bloków danych, mechanizmów ochrony przed nieprawidłowym zapisem danych, mechanizmów zrównoleglenia operacji tworzenia kopi zapasowych i ich odtwarzania, opcji związanych z mechanizmami Flashback,
• w zakresie podwyższonej niezawodności nie znajdziemy tu mechanizmów wspierających
utrzymanie zapasowej bazy danych zarówno na poziomie fizycznym (Redo Apply Data
Guard) jak i logicznym (SQL Apply Data Guard), nie wspominając już o wyrafinowanych
rozwiązaniach typu Active data Guard. Ograniczenie licencji Wersji Standard do 4 procesorów sprawiają, że także rozwiązanie RAC jest tu ograniczone do maksymalnie 4 węzłów
(każdy z jednym procesorem),
• optymalizator zapytań ma tu także ograniczone możliwości działania – nie znajdziemy tu
możliwości równoległego wykonywania zapytań, także nowo wprowadzone w wersji 11g
dodatkowe poziomy buforowania wyników zapytań i wyników działania funkcji PL/SQL:
w pamięci, czy z wykorzystaniem napędów Flash, a także po stronie klienta,
• mechanizmy bezpieczeństwa także często okazują się niewystarczające dla szczególnie wy-
magających zastosowań. Takie mechanizmy jak szyfrowanie danych w bazie danych, szyfrowanie komunikacji z klientem, szyfrowanie kopii bezpieczeństwa, silne uwierzytelnianie
znalazły się dopiero w dodatkowej opcji, którą można dokupić tylko do wersji Enterprise –
Advanced Security Option. Mechanizmy zaawansowanego uwierzytelniania opartego o etykiety, którymi oznaczono dane i użytkowników, oraz opcja izolująca administratorów od danych przechowywanych w bazie danych – Database Vault, to także opcje płatne. Do tego
możliwość oparcia mechanizmów bezpieczeństwa danych o drobnoziarnistą kontrolę dostępu, dająca wrażenia posiadania wirtualnych prywatnych baz danych, oraz audyt drobnoziarnisty, które co prawda już bez dodatkowej dopłaty, są dostępne tylko w wersji Enterprise,
• opcji ułatwiających zarządzanie, strojenie, zarządzanie konfiguracjami i zmianami, których
znaczenie zaczyna wzrastać wraz z rozrastaniem się środowiska bazodanowego w firmie.
Opcje te znajdziemy przeważnie jako dodatkowo, które należy dokupić do wersji Enterprise,
Oracle XE, Standard, Enterprise – którą wersję bazy danych wybrać aby nie przepłacić
69
• szeregu funkcjonalności bez których raportowanie, analiza danych, czy każda inna postać
udostępniania dużych wolumenów danych jest nieefektywna. Do tych funkcjonalności można
zaliczyć wspomniane już wcześniej partycjonowanie, wariacje na temat indeksów bitmapowych, mechanizmy przepisywania zapytań w oparciu o perspektywy materializowane, czy
indeksy funkcyjne, równoległe wykonywanie zapytań, ale także zrównoleglenie ładowania
danych przy pomocy pompy danych.
5. Druga migracja – z wersji Standard do wersji Enterprise
Rozwój bazy danych rzadko ma charakter rewolucyjny. Najczęściej mówimy o ewolucji już istniejącego systemu. Podczas takiej ewolucji oczywiście dojrzewamy do podjęcia decyzji o zakupie
wersji Enterprise. W tym rozdziale spróbujemy omówić opcje, których brak w wersji Standard najczęściej skutkuje podjęciem decyzji o migracji do wersji Enterprise.
O ile to możliwe spróbujemy zaproponować rozwiązania bazujące na funkcjonalności wersji
Standard, tak aby wprowadzić choć namiastkę zaawansowanej funkcjonalności z wersji Enterprise.
5.1. Partycjonowanie
Już podczas omawiania migracji z wersji XE do wersji Standard jako jeden z argumentów użyto
stwierdzeń, że zbyt duża ilość danych przetwarzanych w każdym wykonywanym zapytaniu nie
sprzyja wydajności. Jako jeden ze sposobów radzenia sobie ze zbyt dużą ilością danych w tabelach
przedstawiono zmiany w projekcie struktury bazy danych polegające na stworzeniu dodatkowych
tabel, do których będą przepisywane dane historyczne.
Rozwinięcie tej idei znajdziemy w opcji partycjonowania tabel. Opcja ta pozwala nam zdefiniować reguły na podstawie których serwer bazy danych decyduje w której z tabel umieścić wprowadzony, modyfikowany rekord. Przed użytkownikami zbiór tabel o identycznej strukturze plus zestaw reguł przyporządkowujących reguły do jednej z tabel jest prezentowany jako jedna spójna
struktura – tabela partycjonowana. Jest to mechanizm całkowicie przezroczysty dla aplikacji i o ile
aplikacja/użytkownik nie będzie świadomie próbował korzystać konkretnej partycji – to nie zauważy tego, ze korzysta z tabeli partycjonowanej.
Główne zalety mechanizmu partycjonowania to możliwość automatycznego rozdzielenia danych
w tabeli na kilka niezależnych tabel/partycji. Reguły tego podziału mogą być zdefiniowane w formie list wartości, lub zakresów do których dopasowujemy wartości wybranych kolumn w partycjonowanych tabelach. Dostępne są jeszcze mechanizmy partycjonowania opartego o wynik funkcji
hashującej lub też całkowicie bazujące na wskazaniu przez użytkownika wykonującego operacje na
danych. Można zdefiniować aż dwa poziomy partycjonowania tabel.
Najczęściej jako klucz partycjonowania przynajmniej na pierwszym poziomie wskazuje się takie
kolumny, których wartości podzielą dane z tabeli na niezależne grupy a podział ten będzie miał
znacznie z biznesowego punktu widzenia. Na przykład może to być rok powstania rekordu, lub
region z którego pochodzi klient opisywany w takiej partycjonowanej tabeli.
Jeżeli optymalizator widzi zapytanie sięgające do tabeli partycjonowanej i warunki selekcji
w zapytaniu opowiadają regułom zdefiniowanym dla pewnej grupy partycji to wygeneruje plan
wykonania zapytania pomijający te partycje, dla których ten warunek nie jest spełniony. Mechanizm ten nazywamy przycinaniem partycji. Jeżeli dodatkowo w zapytaniu uda się wykorzystać fakt,
że łączymy dwie tabele o podobnym kluczu partycjonowania i jeszcze powiążemy to z możliwością
zrównoleglenia procesu wykonania takiego zapytania, to wówczas jest spora szansa, ze optymalnie
wykorzystamy całą moc obliczeniową naszego serwera – łączymy efektywnie stosunkowo małe
porcje/partycje danych i dodatkowo robimy to obciążając wszystkie dostępne zasoby.
Oprócz partycjonowania tabel istniej także możliwość partycjonowania indeksów, przy czym
klucz partycjonowania indeksu może być identyczny jak tabeli partycjonowanej, lub też od niego
70
Mariusz Masewicz
różny. Mechanizmy partycjonowania tabel i indeksów mogą być wykorzystywane niezależnie od
siebie.
Jak zatem dodać mechanizm partycjonowania do wersji standard? Najprostsze rozwiązanie polega na utworzeniu szeregu tabel, do których będziemy wstawiać dane oraz zestawu kryteriów rozstrzygających o tym, do której tabeli będzie należał wiersz. Na przykład tabele: sprzedaz_2009,
sprzedaz_2010, sprzedaz_2011. Kolejnym etapem jest utworzenie perspektywy, która połączy
w sobie wyniki zapytania do wszystkich utworzonych tabel/partycji. Zapytanie może mieć postać:
select * from sprzedaz_2009
union all
select * from sprzedaz_2010
union all
select * from sprzedaz_2011
Dobrym pomysłem byłoby podpowiedzenie optymalizatorowi, że dla tabel/partycji zdefiniowaliśmy jakieś kryteria przynależności właśnie do tej partycji.
select * from sprzedaz_2009 where rok=2009
union all
select * from sprzedaz_2010 where rok=2010
union all
select * from sprzedaz_2011 where rok=2011
Zaproponowany mechanizm posiada większość cech partycjonowania dostępnego w wersji standard – kazda partycja jest niezależnym obiektem ze swoja polityka składowania danych. Łatwo jest
takie partycje dodawać i wyłączać z zakresu widoczności perspektywy udającej interfejs dostępu do
tabeli partycjonowanej. Jeżeli dodatkowo utworzymy indeksy w oparciu o poszczególne partycje –
to mamy namiastkę indeksów partycjonowanych. Problemem pozostają jedynie Operacje DML na
takiej „partycjonowanej” tabeli. Można to rozwiązać na dwa sposoby: albo dostarczyć wyzwalacza
instead-of i tym samym ukryć przed użytkownikiem fakt partycjonowania tabelki także na poziomie
tych operacji, albo poprosić użytkowników, żeby w przypadku operacji DML świadomie wstawiali
dane do właściwej tabeli/partycji będącej składową naszej tabeli partycjonowanej.
5.2. Perspektywy materializowane i przepisywanie zapytań
Kolejnym mechanizmem, bez którego nie może się obejść żadna porządna hurtownia danych jest
mechanizm przepisywania zapytań – w oparciu o częściowo przygotowane półprodukty (najczęściej
wyniki zapytań składowane w postaci perspektyw materializowanych, z całym dobrodziejstwem
tego mechanizmu: automatyczne odświeżanie, partycjonowanie, …).
Przepisywanie zapytań w wersji Enterprise polega na tym, że optymalizator dopasowuje zapytanie użytkownika do treści zapytań stanowiących definicje perspektyw zmaterializowanych i jeżeli
tylko znajdzie podobieństwa, to stara się wykorzystać taka perspektywę jako źródło dla zmodyfikowanej wersji zapytania – uwzględniającej już to, że dane zamiast czytać wprost z tabel wymienionych w zapytaniu, czyta z perspektywy materializowanej.
Jeżeli uwzględni się fakt, iż taka perspektywa materializowana może być zdefiniowana przez
skomplikowane zapytanie zawierające w sobie różnego rodzaju agregaty, czy wyniki łączenia tabel,
to zastosowanie mechanizmu przepisywania zapytań może przynieść ogromne korzyści, zwłaszcza
w systemach analitycznych.
Jak w takim wypadku symulować działanie mechanizmu przepisywania zapytań? Wersja Standard oferuje co prawda mechanizm perspektyw materializowanych, ale są one tu traktowane jako
element rozwiązań związanych z replikacją danych a nie optymalizacją zapytań. Sprawę komplikuje
też fakt, że w zasadzenie nie istnieje mechanizm pozwalający poznać i zmodyfikować zapytanie
użytkownika zanim zostanie ono zrealizowane. Pozostaje więc podejście stosowane od dawna
w tego typu sytuacjach – poinformowanie programistów o tym, ze przygotowaliśmy szereg perspektyw materializowanych zawierających dane przetwarzane w aplikacjach i niech programiści
Oracle XE, Standard, Enterprise – którą wersję bazy danych wybrać aby nie przepłacić
71
zadbają o to, że ich zapytania korzystają właśnie z perspektyw materializowanych a nie sięgają do
danych źródłowych.
W zaproponowanym podejściu nie mamy gwarancji na to, że programiści poprawnie skorzystają
z przygotowanych dla nich struktur zawierających zagregowane dane. O ile oczywiście w ogóle
skorzystają z takich podsumowań.
5.3. Równoległe wykonywanie zapytań
Zrównoleglenie wykonania zapytania w wielu przypadkach pozwala znacząco skrócić czas
oczekiwania na jego zakończenie. Aby takie zrównoleglenie przynosiło zauważalne efekty muszą
zostać spełnione pewne warunki:
• serwer musi dysponować wolną mocą obliczeniową (przepustowość urządzeń I/O, nieobcią-
żone procesory),
• zapytania muszą być dostatecznie złożone,
• ilości przetwarzanych danych muszą być odpowiednio duże. Wynika z tego, że nie ma sensu
zrównoleglić zapytania, które ma za zadanie zwrócić jeden wiersz, do którego dotrze przy
pomocy indeksu.
Brak opcji zrównoleglenia zapytań w wersji standard można spróbować zrekompensować sobie
dzieląc zakres danych przeglądanych przez zapytanie na mniejsze porcje, po czym w wielu sesjach
jednocześnie uruchomić zapytania przetwarzające fragment danych. Na koniec należy oczywiście
skonsolidować wyniki zwrócone przez te zapytania. Jako mechanizm podziału tabel na mniejsze
porcje doskonale sprawują się partycje w przypadku tabel partycjonowanych.
Jak łatwo można wywnioskować – powyższe rozwiązanie dla wersji Standard ma szanse sprawdzić się w przypadku przetwarzania wsadowego, gdzie odpowiednio spreparowane skrypty mogą
symulować równoległość. Niestety nie jesteśmy w stanie zaimplementować tego rozwiązania jako
mechanizmu chociażby częściowo przezroczystego dla aplikacji.
5.4. Wysoka wydajność i niezawodność
Jak już wielokrotnie wspomniano – wersja standard pozwala uruchomić bazę danych w środowisku w którym jest ona obsługiwana przez jedną do czterech instancji uruchomionych w tym ostatnim przypadku na czterech różnych serwerach. Rozwiązanie takie oferuje nam wzrost niezawodności środowiska, gdyż w razie awarii jednego z serwerów pozostałe węzły klastra przejmują na siebie
jego obowiązki. Wadą rozwiązań typu RAC jest jednak to, że wymagają one tego aby baza danych
była utrzymywana w jednej kopi – wspólnej dla wszystkich instancji obsługujących dane. Ta
wspólna baza danych jest tutaj najsłabszym ogniwem – pojedynczym punktem awarii. Sprawę ratuje tu fakt, że obecnie urządzenia na których składowane są dane to kontrolery macierzy dyskowych
zapewniające silne mechanizmy niezawodnego dostępu do danych (redundancja, sumy kontrolne, …). Wersja Enterprise oferuje rozwiązania pozwalające skonfigurować całkowicie niezależną
zapasową bazę danych – Data guard. W dużym skrócie oferowane są tam 3 warianty środowiska
z zapasową bazą danych.
5.4.1. Fizyczny Data guard
W tym rozwiązaniu pracuje tylko baza Głowna kopia bazy danych. Kopia zapasowa jest idealną
kopią bazy danych głównej (uruchomiona w trybie „przywracania nośników” – czyli oczekuje na
logi transakcyjne z systemu głównego. Logi takie mogą być dostarczane na bieżąco, lub jako zarchiwizowane pliki dziennika powtórzeń. W sytuacji awaryjnej baza zapasowa jest w stanie przejąć
obciążenie bazy podstawowej.
W wersji standard można zasymulować działanie podobnego mechanizmu. Należy w tym celu
w środowisku zapasowym uruchomić kopię bazy danych trybie przywracania no ścinków (recovery
72
Mariusz Masewicz
until cancel). Następnie ręcznie należałoby dostarczać zarchiwizowane pliki dziennika powtórzeń
wyprodukowane przez bazę podstawową (proces dostarczania można oczywiście w dowolny sposób zautomatyzować).
W proponowanym rozwiązaniu otwarte pozostaje pytanie o licencje dla bazy danych w centrum
zapasowym – w wersji Enterprise sprawy te zostały uregulowane i obecnie i baza główna i baza zapasowa wymagają osobnej licencji.
5.4.2. Logiczny Data guard
W przypadku logicznego Data guarda obie bazy danych pozostają otwarte i w obu może odbywać się ruch transakcyjny. Zakłada się tu jednak, że tabele replikowane z głównej bazy danych do
zapasowej są modyfikowane tylko po stronie bazy głównej. Mechanizmy Data guarda dbają tu jedynie o to, aby polecenia, które wykonały się po stronie systemu głównego zostały powtórzone po
stronie systemu zapasowego.
W przypadku baz Standard Edition nic nie stoi na przeszkodzie, aby takie zachowanie zasymulować przy pomocy mechanizmów replikacji bazujących na przykład na Oracle Streams.
Głowna wada takiego symulowania działania logicznego Data guarda jest to, że trudno jest uzyskać rozwiązanie, które da nam gwarancje, że wszystkie zatwierdzone zmiany w bazie źródłowej
zostały przeniesione do bazy docelowej.
5.4.3. Aktywny Data guard
Jest to rozwiązanie stosunkowo nowe (wprowadzone w wersji 11g), pozwalające na pełne uruchomienie zarówno bazy podstawowej, jak i zapasowej. Zmiany wprowadzane w każdej z nich są
automatycznie przenoszone także do drugiej bazy danych. Rozwiązanie to pozwala w pełni wykorzystać moc obliczeniową obu serwerów (głównego i zapasowego).
Jak zaimplementować to rozwiązanie samodzielne bazując tylko i wyłącznie na mechanizmach
oferowanych w wersji standard? Tutaj niestety rozwiązanie wymaga sporej ilości kodowania
w języku PL/SQL, stworzenia szeregu tabel pomocniczych, wykorzystania wyzwalaczy wykrywających zmiany po stronie źródła i stworzenia mechanizmu dostarczania powiadomień o tych zmianach do systemu docelowego.
5.5. Kompresja
Kompresja danych w bazach danych ma za zadanie zmniejszenie rozmiaru tabel, a tym samym
zmniejszenie obciążenia systemu I/O podczas operacji odczytu danych z tabeli. Przeważnie okupione jest to dodatkowym kosztem wynikającym z konieczności kompresowania i dekompresowania
danych przez procesory serwera bazy danych.
Wersja Standard w zasadzie nie oferuje żadnych mechanizmów kompresji danych. Znajdziemy
je dopiero w wersji Enterprise jako opcje standardowej kompresji oraz dodatkowo płatny pakiet
zaawansowanej kompresji.
Nic nie stoi jednak na przeszkodzie, aby to nasza aplikacja wysyłając dane do serwera wysyłała
je od razu w wersji skompresowanej. Takie podejście ma jednak tą zasadniczą wadę, że baza danych widzi tylko i wyłącznie skompresowaną wersję danych, a więc nie może na przykład stworzyć
efektywnych indeksów wspierających wyszukiwanie zakresowe.
Można też sobie wyobrazić rozwiązanie pośrednie – czyli stworzenie własnych procedur/funkcji
odpowiedzialnych za szyfrowanie i składowanych w bazie danych. Ale i to rozwiązanie niewiele
zmienia jeżeli chodzi o wsparcie dla mechanizmów wydajnego przetwarzania, wyszukiwania, czy
porównywania tak skompresowanych danych.
Oracle XE, Standard, Enterprise – którą wersję bazy danych wybrać aby nie przepłacić
73
5.6. Szyfrowanie
Podobnie jak w przypadku kompresji, taki w przypadku szyfrowania – w bazie danych w wersji
Standard nie znajdziemy żadnego wsparcia dla szyfrowanie. A jeżeli chodzi o szyfrowanie, to pomysłów tutaj można mieć sporo – od szyfrowania pojedynczych komórek, poprzez szyfrowanie
całych kolumn, tabel, czy wręcz bazy danych. Do tego cały fakt szyfrowania danych w bazie danych może być zupełnie przezroczysty dla użytkowników, gdyż w odpowiedzi na ich zapytania
baza danych może zwracać im dane w wersji już odszyfrowanej. Do tego dochodzi bezpieczne bo
szyfrowane połączenie z klientem i na przykład obsługa szyfrowania podczas tworzenia kopii zapasowych. Podobnie jak w przypadku kompresji – w zasadzie wszystko co dotyczy szyfrowania
znajdziemy dopiero w wersji Enterprise a dokładniej w dodatkowo płatnym pakiecie zaawansowanego bezpieczeństwa.
I znów, podobnie jak w przypadku kompresji danych – jeżeli do wersji Standard chcielibyśmy
dołożyć szyfrowanie danych składowanych w bazie danych – to musimy to obsłużyć na poziomie
aplikacji klienckiej – z wszelkimi zaletami takiego rozwiązania (szyfrujemy co chcemy i jak chcemy) oraz z jego wadami (baza danych zna tylko zaszyfrowane wersje danych, więc pewne właściwości na przykład indeksów nie mogą być wykorzystywane). Pomysł z szyfrowaniem za pomocą
składowanych procedur czy funkcji tez można tu rozważyć pamiętając, że nie likwiduje on wad
szyfrowania przez aplikację – zmienia się tylko miejsce w którym to szyfrowanie jest wykonywane,
a tym samym dodatkowe obciążenie związane z szyfrowaniem przejmuje na siebie serwer bazy
danych.
Gdy myślimy o szyfrowaniu połączenia z bazą danych – to pakiet zaawansowanego bezpieczeństwa gwarantuje nam to szyfrowanie na poziomie protokołu SQL*Net. Alternatywą jest szyfrowanie transmisji na poziomie na przykład protokołu TCP, gdzie znamy cały wachlarz rozwiązań bazujących na VPN, tunelowaniu, czy sprzętowych szyfratorach.
Podobnie wygląda sytuacja z tworzeniem kopi bezpieczeństwa – pakiet zaawansowanego bezpieczeństwa pozwoli nam uzyskać zaszyfrowana kopie już na wyjściu z narzędzia RMAN (wspierając na różne sposoby fakt, że w bazie danych mamy zaszyfrowane na przykład tylko wybrane kolumny). Ale nic nie stoi na przeszkodzie, żeby szyfrować takie kopie zaraz po wyjściu z narzędzia
RMAN, albo wręcz wyjście z narzędzia RMAN przesłać do programowego lub sprzętowego szyfratora, jeszcze zanim przybierze postać pliku wynikowego na dysku twardym, czy też taśmie magnetycznej.
Podsumowanie
Celem artykułu było wskazanie najważniejszych różnic funkcjonalnych pomiędzy poszczególnymi wersjami bazy danych Oracle – począwszy od wersji XE, poprzez wersję Standard, a na Enterprise skończywszy. W artykule zwrócono uwagę na mocne strony każdej z opcji, która pojawia
się w droższych wersjach serwera bazy danych. Wskazano także mechanizmy, których wdrożenie
pozwoliłoby w pewnym sensie zrekompensować brak tych mocnych elementów w słabszych wersjach bazy danych. Często jest tak, że takie wdrożenie pozwala na pewien czas odsunąć myśl o migracji z wersji słabszej na wersję mocniejszą. Czasami jednak koszt wdrożenia i utrzymania zaproponowanych rozwiązań może znacząco przewyższyć koszty związane z zakupem droższej, ale bardziej funkcjonalnej wersji bazy danych. Ważne jest jednak to, że składając zapotrzebowanie na
zakup droższej wersji jesteśmy w stanie przedstawić decydentom alternatywne rozwiązania wraz
z ich mocnymi i słabymi stronami.
Bibliografia
[ORA11gLIC]
Oracle® Database Licensing Information 11g Release 2 (11.2) – Part Number E10594-17.