Oracle XE, Standard, Enterprise – którą wersję bazy danych
advertisement
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.
