Dwunastka od Oracle'a
-
- 21.08.2013
Najnowsza baza Oracle 12c wprowadza mechanizmy ochrony danych. Wersja jest przeznaczona do obsługi wielu podmiotów jednocześnie i zastosowania do architektury usługowej w modelu cloud.
Poprzednie wydania bazy Oracle były stopniowym usprawnieniem istniejącego modelu pracy, w którym pojedyncza instancja była przeznaczona do pracy z bazą pojedynczego klienta lub z pojedynczą aplikacją. Wersja 12c umożliwia obsługę baz wielu klientów jednocześnie, wieloma bazami można zarządzać jak jedną, bez konieczności wprowadzania zmian w aplikacjach.
Wiele baz w jednej instalacji
Wprowadzona do wersji 12c opcja Oracle Multitenant to funkcja, dzięki której aplikacje mogą postrzegać każdą bazę danych podłączoną do nowej architektury jako standardową bazę danych Oracle – istniejące aplikacje mogą działać bez dodatkowych zmian. Wprowadzenie obsługi wielu klientów w pojedynczej warstwie bazy danych sprawia, że nie będzie potrzebne kreowanie osobnych instancji w wirtualizowanym środowisku, dzięki czemu zmniejsza się narzut na osobne kopie systemu operacyjnego oraz procesów bazy danych. W porównaniu do kilku osobnych instancji uruchomionych w maszynach wirtualnych obserwujemy istotną redukcję zużycia pamięci RAM. Przy wdrożeniu w architekturze Multitenant można wykorzystać wszystkie opcje bazy danych Oracle, m.in.: klastrowanie, kompresję, partycjonowanie, ochronę danych, zarządzanie przestrzenią składowania, szyfrowanie.
Gorące i zimne porcje danych
W najnowszej wersji narzędzia RMAN przeznaczonego do wykonywania i odtwarzania danych z kopii bezpieczeństwa wprowadzono precyzyjne odzyskiwanie tabel z backupu. Za pomocą RECOVER TABLE można odzyskać jedną lub kilka tabel, zarówno w najnowszej, jak i starszej wersji. Dzięki temu można uniknąć odtwarzania pełnego backupu przestrzeni tabel do innej instancji, a następnie eksportowania wybranych tabel w celu importu do bazy docelowej. Proces odtworzenia pojedynczej tabeli wprost z backupu umożliwia radykalne skrócenie czasu przywrócenia części danych wprost z kopii bezpieczeństwa wykonanej za pomocą RMAN. Razem z koncepcją Multitenant w narzędziu RMAN w bazie 12c wprowadzono także prosty w użyciu sposób backupu baz danych oznaczanych jako PLUGGABLE (komendy BACKUP/RECOVER PLUGGABLE DATABASE).
W najnowszej wersji uproszczono również migrację danych między bazami pracującymi na różnych platformach, gdyż opcjonalna konwersja big/little endian i eksport metadanych wykonuje się automatycznie.
Ochrona danych
Podczas testowania i eksploatacji aplikacji często pojawia się potrzeba zamaskowania szczególnie istotnych porcji danych, np.: informacje o płatnościach, numery identyfikacyjne PESEL, informacje medyczne i inne. Dotychczas nad maskowaniem informacji czuwały opcje oprogramowania, a mechanizm uprawnień umożliwiał tylko zablokowanie odczytu wybranych miejsc. Obecnie informacje uznane za szczególnie ważne można zamaskować za pomocą reguł – zwracane w ten sposób do aplikacji informacje są edytowane w czasie rzeczywistym, podczas realizacji zapytania. W regułach można uwzględnić uprawnienia użytkownika, informacje o sesji czy aplikacji. W ten sposób można także opracować mechanizmy zabezpieczeń, dzięki którym dane będą bezpieczne nawet przy przejęciu konta o uprawnieniach DBA.
Jakie uprawnienia są niezbędne?
Przy projektowaniu i wcielaniu w życie mechanizmu uprawnień dostępu do bazy danych podstawowym problemem jest określenie minimalnych przywilejów niezbędnych do wykonania operacji. Przy wyjątkowo skomplikowanej aplikacji określenie minimalnego poziomu uprawnień jest trudne, dlatego ustawia się je znacznie wyżej niż to niezbędne. Wprowadzenie zasady przywilejów koniecznych może wiązać się z zablokowaniem dostępu do aplikacji lub z utratą danych – dla działu IT to wyzwanie. Jeszcze trudniej ustalić minimalny zestaw uprawnień dla administratorów.
Nowa wersja bazy danych ma mechanizm ustalania przywilejów niezbędnych do wykonania realizowanych transakcji i zadań, czyli po określeniu uprawnień zbędne role i przywileje można bezpiecznie odwołać bez zakłócania biznesowej działalności operacyjnej.
Odtworzenie uszkodzonej transakcji
Problemy z dostępnością bazy mogą powodować rozłączenie sesji, podwójne wprowadzanie tej samej porcji informacji, utratę danych. Aby minimalizować ryzyko takich zdarzeń, w bazie Oracle 12c wprowadzono protokół oraz API, które umożliwiają zwrócenie wyników ostatnio przetworzonej transakcji. Razem z opcją ciągłości działania aplikacji rozpoczęte, a przerwane zadania bazodanowe na jednym serwerze mogą być bezpiecznie wykonane ponownie na innej maszynie, co od strony aplikacji przejawia się jedynie nieco dłuższym czasem odpowiedzi. Awaria jest w ten sposób maskowana przed użytkownikami.
Nowa analiza danych
Pośród zapowiadanych nowości związanych z analizą danych warto wymienić opcję dopasowania wzorców w języku SQL. Zapytania, które dotąd wymagały korzystania wielu połączeń (self join), zapytań rekursywnych albo funkcji okien (SQL window – kwerendy wykonywane na zestawie krotek w pewien sposób ze sobą powiązanych) w Oracle 12c można zdefiniować bardzo prosto, za pomocą wyrażeń regularnych. Za pomocą MATCH_RECOGNIZE można wykryć powtarzające się zdarzenia w zbiorach danych takich jak transakcje biznesowe, zapisy logów z różnych urządzeń, a także strumienie informacji o aktywności, na przykład kliknięcia poszczególnych podstron serwisu.
Aby ułatwić analizę ściśle matematyczną i statystyczną, usprawniono także mechanizmy integracji bazy danych z systemem R. Rozwiązania te są szczególnie użyteczne przy analizie dużych zbiorów danych.
Aby zapewnić ochronę przed utratą danych, firmy stosują replikację do zdalnego ośrodka, przy czym najlepsze efekty osiąga się za pomocą replikacji synchronicznej. W tym modelu aplikacja i baza danych zatwierdza transakcję dopiero wtedy, gdy dane dotrą jednocześnie do ośrodka głównego i rezerwowego. Rozwiązanie to sprawdza się przy niskich opóźnieniach. Jeśli firma chce zrealizować replikację danych do data center na innym kontynencie, opóźnienia spowodowane przez czas, w jakim światło przebywa tę odległość, są zbyt duże. Aby rozwiązać problem skutecznej replikacji przez ocean, Oracle w rozwiązaniu Global Data Services wprowadza opcję Far Sync, w której replikacja do bazy rezerwowej na najdłuższym odcinku odbywa się asynchronicznie, ale z bazy produkcyjnej do instancji Far Sync dane są replikowane synchronicznie. Przy normalnym przepływie danych informacje z głównej bazy produkcyjnej przepływają do repliki Far Sync natychmiast, by następnie zasilić replikę rezerwową. W razie utraty danych baza rezerwowa przejmuje zadania głównej bazy produkcyjnej, wszystkie zamknięte transakcje z bazy głównej zostaną dosłane w sposób asynchroniczny z kopii w instancji Far Sync, dzięki czemu nie ma utraty danych. Replika rezerwowa jest regularnie zasilana danymi i opóźnienie między instancją główną jest o wiele mniejsze niż przy standardowej replikacji asynchronicznej na poziomie logów archiwalnych. W ten sposób można zrealizować lokalną kopię synchroniczną do drugiej instancji w pobliskim data center, ale i skomplikowany scenariusz disaster recovery, wykorzystujący odległe centrum przetwarzania danych, zlokalizowane w innym kraju lub na innym kontynencie. Mechanizm będzie działać przy dowolnym połączeniu WAN o wystarczającej przepustowości, więc jeśli potrzeby biznesowe to uzasadniają, kopia może znajdować się nawet w Azji, Ameryce czy Australii.
Przy kaskadowej replikacji z dwiema instancjami rezerwowymi w wersji 11.2 baza rezerwowa nr 1 oczekiwała na przełączenie plików logów przed wysłaniem informacji z logami archiwalnymi do bazy rezerwowej nr 2. Obecnie baza rezerwowa, która otrzymuje aktualizację transakcji z bazy produkcyjnej, od razu wysyła logi wycofań do bazy numer 2 w kaskadzie replikacji, dzięki czemu druga baza nie musi oczekiwać na przełączenie plików. W ten sposób druga replika może być wykorzystana do zapytań tylko do odczytu, a także do skomplikowanych raportów i nie będzie obciążać bazy produkcyjnej.
