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: Mariusz@Masewicz.pl 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ęp-nych 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. Naj-waż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 wyko-rzystamy 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 zaosz-czę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 rezy-gnacji 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 za-wartymi 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 warian-cie 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 pro-cesoró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. Do-datkowym 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 do-datkowo ograniczoną możliwościami wykorzystania zasobów sprzętowych serwera (1 proce-sor, 1GB pamięci, 4GB1 lub 11GB2 danych użytkownika składowanych w tej wersji bazy da-nych). Największą zaletą tego produktu jest jego cena – a dokładniej jej brak, gdyż jest bez-płatny do praktycznie wszelkich zastosowań (w tym także komercyjnych). Idealna jako ser-wer 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żyt-kownikó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 administrato-rom, 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 dodat-kowo 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. Funk-

1 W wersji 10g XE 2 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 ad-ministrację: 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 przeanali-zowaniu 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ść rygo-rystycznymi ograniczeniami nałożonymi na możliwość wykorzystania zasobów sprzętowych serwe-ra. 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 da-tach, 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 technicz-ne 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 wirtualiza-cja? Nic nie stoi na przeszkodzie aby zwielokrotnić liczbę serwerów i na każdym z nich zainstalo-wać bazę danych w wersji XE. Nie łamiąc licencji możemy uzyskać w ten sposób praktycznie nie-ograniczoną 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ć in-stalacji 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żytkowni-kiem bazy danych nazywamy użytkownika takiego rozwiązania, nawet mimo tego, że serwer apli-kacyjny uzyskuje dostęp do bazy danych z wykorzystaniem jednego współdzielonego konta użyt-kownika.

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 bez-pieczne 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 materiali-zowanych 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 fir-my Oracle – co w przypadku wielu zakupów decyduje właśnie o wyborze rozwiązań płatnych za-miast być może wystarczających funkcjonalnie, ale pozbawionych wsparcia produktów bezpłat-nych.

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 kla-stra 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 wyko-rzystać:

• 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 Enterpri-se 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 Enter-prise. 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 przebudo-wywania 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 ze-stawów kopii zapasowych, odtwarzania pojedynczych bloków danych, w tym także automa-tycznego odtwarzania bloków danych, mechanizmów ochrony przed nieprawidłowym zapi-sem danych, mechanizmów zrównoleglenia operacji tworzenia kopi zapasowych i ich odtwa-rzania, 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 proceso-ró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, szy-frowanie 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 ety-kiety, którymi oznaczono dane i użytkowników, oraz opcja izolująca administratorów od da-nych 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 drobnoziar-nisty, 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 bitmapo-wych, 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ż ist-nieją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 naj-częś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 zdefinio-wać reguły na podstawie których serwer bazy danych decyduje w której z tabel umieścić wprowa-dzony, modyfikowany rekord. Przed użytkownikami zbiór tabel o identycznej strukturze plus ze-staw 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 for-mie list wartości, lub zakresów do których dopasowujemy wartości wybranych kolumn w partycjo-nowanych 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. Mecha-nizm 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 pole-ga na utworzeniu szeregu tabel, do których będziemy wstawiać dane oraz zestawu kryteriów roz-strzygają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 zdefiniowa-

liś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 stan-

dard – 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 zapyta-nie 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 zmodyfi-kowanej wersji zapytania – uwzględniającej już to, że dane zamiast czytać wprost z tabel wymie-nionych 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 Stan-dard 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 per-spektyw 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 spraw-dzić 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 środowi-sku w którym jest ona obsługiwana przez jedną do czterech instancji uruchomionych w tym ostat-nim 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ę ratu-je 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 kontrol-ne, …). 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 zar-chiwizowane 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 spo-só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 za-pasowa wymagają osobnej licencji.

5.4.2. Logiczny Data guard W przypadku logicznego Data guarda obie bazy danych pozostają otwarte i w obu może odby-

wać 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 je-dynie 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 zasymu-lować 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 uzy-skać 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 uru-

chomienie 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 wyko-rzystać 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 wykrywa-jących zmiany po stronie źródła i stworzenia mechanizmu dostarczania powiadomień o tych zmia-nach 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 okupio-ne 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 da-nych 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 po-mysłó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 da-nych 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 zapa-sowych. Podobnie jak w przypadku kompresji – w zasadzie wszystko co dotyczy szyfrowania znajdziemy dopiero w wersji Enterprise a dokładniej w dodatkowo płatnym pakiecie zaawansowa-nego 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 chce-my) oraz z jego wadami (baza danych zna tylko zaszyfrowane wersje danych, więc pewne właści-woś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 szyfrowa-nie transmisji na poziomie na przykład protokołu TCP, gdzie znamy cały wachlarz rozwiązań bazu-jących na VPN, tunelowaniu, czy sprzętowych szyfratorach.

Podobnie wygląda sytuacja z tworzeniem kopi bezpieczeństwa – pakiet zaawansowanego bez-pieczeństwa pozwoli nam uzyskać zaszyfrowana kopie już na wyjściu z narzędzia RMAN (wspiera-jąc na różne sposoby fakt, że w bazie danych mamy zaszyfrowane na przykład tylko wybrane ko-lumny). 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 szyfra-tora, jeszcze zanim przybierze postać pliku wynikowego na dysku twardym, czy też taśmie magne-tycznej.

Podsumowanie

Celem artykułu było wskazanie najważniejszych różnic funkcjonalnych pomiędzy poszczegól-nymi wersjami bazy danych Oracle – począwszy od wersji XE, poprzez wersję Standard, a na En-terprise 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 wer-sjach bazy danych. Często jest tak, że takie wdrożenie pozwala na pewien czas odsunąć myśl o mi-gracji z wersji słabszej na wersję mocniejszą. Czasami jednak koszt wdrożenia i utrzymania zapro-ponowanych rozwiązań może znacząco przewyższyć koszty związane z zakupem droższej, ale bar-dziej 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.