RAC, Data Guard i Stream to trzy narzędzia w systemie wysokiej dostępności Oracle. Każde z nich może być używane niezależnie lub w połączeniu. Mają różne zastosowania i są odpowiednie w różnych scenariuszach.
RAC doskonale radzi sobie z problemem pojedynczego punktu awarii i równoważeniem obciążenia. Dlatego RAC jest często stosowany w systemach krytycznych działających 24/7. Jednak w rozwiązaniu RAC dane istnieją w jednej kopii. Mimo że awarie pamięci masowej można uniknąć dzięki mechanizmom takim jak RAID, same dane nie posiadają nadmiarowości, przez co są narażone na awarie pojedynczego punktu.
Data Guard zapewnia ochronę danych dzięki danych nadmiarowych. Wykorzystując mechanizmy synchronizacji dziennika, Data Guard gwarantuje spójność danych nadmiarowych z danymi podstawowymi. Tę spójność można osiągnąć w różnych formach, takich jak synchronizacja w czasie rzeczywistym, opóźniona, synchroniczna lub asynchroniczna. Data Guard jest powszechnie stosowany w rozwiązywaniu problemów odzyskiwania po katastrofach oraz w rozwiązaniach zapewniających wysoką dostępność w małych przedsiębiorstwach. Chociaż pozwala na wykonywanie zapytań tylko do odczytu na maszynie w stanie oczekiwania, aby zmniejszyć obciążenie wydajnościowe bazy danych podstawowej, Data Guard nie jest przede wszystkim przeznaczony jako rozwiązanie wydajnościowe.
Streams, zbudowane na bazie Oracle Advanced Queue, umożliwiają synchronizację danych i oferują elastyczne konfiguracje na wielu poziomach. Ze względu na obszerne wsparcie programistyczne oferowane przez Oracle, w tym bogate API, Streams są bardziej odpowiednie do wymiany danych na poziomie aplikacji.
Czym jest Data Guard?
W środowisku Data Guard istnieje co najmniej dwie bazy danych: jedna w stanie otwartym, udostępniająca usługi na zewnątrz, znana jako Główna Baza Danych, oraz druga w stanie odzyskiwania, znana jako Baza Danych Standby. W czasie pracy Główna Baza Danych obsługuje klientów, a operacje użytkowników są zapisywane w dziennikach online i archiwalnych, które następnie są przesyłane przez sieć do bazy danych Standby. Dzienniki te są odtwarzane w bazie danych Standby, aby osiągnąć synchronizację danych między obiema bazami.
Oracle Data Guard dalej optymalizuje ten proces, automatyzując i usprawniając transmisję i odzyskiwanie dzienników, a jednocześnie oferując szereg parametrów i poleceń ułatwiających pracę administratorów baz danych (DBA).
Jeśli występują przewidywane czynniki wymagające wyłączenia głównej bazy danych, takie jak aktualizacje oprogramowania lub sprzętu, bazę pomocniczą można przełączyć, aby stała się główną bazą danych i kontynuować obsługę klientów. To minimalizuje przestój usług i zapewnia integralność danych. W przypadku nieoczekiwanych problemów powodujących niedostępność głównej bazy danych, bazę pomocniczą można w sposób wymusony przełączyć, aby stała się główną bazą danych i kontynuować obsługę klientów. Poziom utraty danych w takich przypadkach zależy od skonfigurowanego poziomu ochrony danych. Z tego względu role główne i pomocnicze są to pojęcia logiczne, które nie są przypisane na stałe do konkretnych baz danych.
Architektura Data Guard
Architektura Data Guard może być podzielona na trzy funkcjonalne części:
1) Powtórne wysyłanie:
Podczas działania bazy danych podstawowej, dzienniki powtórzeń są generowane w sposób ciągły i muszą być wysyłane do bazy danych rezerwowej. Ta operacja wysyłania może być realizowana przez procesy LGWR lub ARCH bazy danych podstawowej. Różne miejsca archiwizacji mogą wykorzystywać różne metody, jednak dla konkretnego miejsca docelowego można wybrać tylko jedną metodę. Wybór procesu ma istotny wpływ na możliwości ochrony danych oraz dostępność systemu.
2) Ponowne odbieranie:
Proces RFS (Remote File Server) w Bazie Danych Standby odbiera dzienniki i zapisuje je do plików dziennika odtwarzania (Standby Redo Log) lub do zarchiwizowanych plików dziennika (Archived Log), w zależności od metody transportu dzienników Bazy Danych Głównej i położenia Bazy Danych Standby. Jeśli dzienniki są zapisywane do plików Standby Redo Log, to w momencie zmiany dziennika w Głównej Bazie Danych, zostaje uruchomiona zmiana dziennika w plikach Standby Redo Log Bazy Danych Standby oraz archiwizowany jest ten dziennik odtwarzania. Jeśli dzienniki są zapisywane do zarchiwizowanych dzienników (Archived Logs), to tę czynność można uznać za operację archiwizacji.
3) Ponowne zastosowanie:
Usługa ponownego zastosowania odpowiada za odtwarzanie dzienników z bazy danych podstawowej na bazie danych rezerwowej, umożliwiając tym samym synchronizację danych między tymi dwiema bazami danych.
W zależności od sposobu, w jaki baza danych w trybie gotowości odtwarza dzienniki, wyróżnia się dwa typy: Physical Standby i Logical Standby.
W zależności od momentu wystąpienia funkcji Redo Apply, istnieją również dwa typy:
a) Real-Time Apply: Ta metoda wymaga użycia Standby Redo Log. Za każdym razem, gdy log jest zapisywany do Standby Redo Log, uruchamia ona proces odzyskiwania. Zaletą tej metody jest skrócenie czasu wymaganego do przełączenia bazy danych, ponieważ pozostałe logi są już odzyskiwane w czasie rzeczywistym.
b) Stosuj w archiwizacji: Ta metoda stosuje dzienniki, gdy wystąpi przełączenie dziennika na podstawowej bazie danych i uruchomi archiwizację na pomocniczej bazie danych. Odbudowa zostaje zainicjowana po zakończeniu procesu archiwizacji. Jest to również domyślny tryb odbudowy.
Physical Standby kontra Logical Standby
Inne istnieją dwa typy baz danych standby: Physical Standby i Logical Standby.
1. Baza danych Physical Standby:
Baza danych Physical Standby jest identyczna jak baza danych Primary. Data Guard utrzymuje bazę danych Physical Standby poprzez stosowanie REDO. Ogólnie rzecz biorąc, gdy Physical Standby nie stosuje REDO, można ją otworzyć w trybie tylko do odczytu (READ ONLY). Jeżeli w bazie danych określono obszar Flashback Area, baza może zostać nawet tymczasowo przełączona do trybu odczytu i zapisu (READ WRITE) w celu wykonania operacji. Po wykonaniu niezbędnych operacji, bazę danych można przywrócić do stanu sprzed przełączenia na tryb READ WRITE z wykorzystaniem funkcji Flashback Database, pozwalając tym samym na kontynuację stosowania danych REDO z bazy Primary.
Uwaga: Funkcjonalność aplikacji Physical Standby została wzbogacana w wersji Oracle 11g. W tej wersji, Physical Standby może kontynuować stosowanie danych REDO, będąc w trybie OPEN READ ONLY. To znacznie poprawia użyteczność baz danych Physical Standby.
Cechy dodatków fizycznych:
1) Odbudowa po katastrofie i wysoka dostępność: Standby fizyczny zapewnia skuteczne i wydajne rozwiązanie do odbudowy po katastrofie i zapewnienia wysokiej dostępności. Upraszcza zarządzanie przełączeniami/przejęciami oraz zmniejsza planowany lub nieplanowany czas przestoju.
2) Ochrona danych: Dzięki bazie danych Physical Standby, Data Guard zapewnia minimalizację utraty danych, nawet w przypadku nieprzewidzianych katastrof.
3) Odciążenie obciążenia głównej bazy danych: Poprzez przeniesienie niektórych zadań, takich jak kopie zapasowe i zapytania tylko do odczytu, na bazę danych typu Physical Standby, można oszczędzić zasoby procesora i wejścia/wyjścia na głównej bazie danych.
4) Poprawiona wydajność: Mechanizm aplikowania REDO używany w bazach danych typu Physical Standby działa na najniższym poziomie odzyskiwania, omijając wykonanie kodu SQL. Pozwala to na osiągnięcie największej wydajności.
2. Stojący w trybie logicznym (Logical Standby):
Baza danych w trybie logicznym tworzona jest również w oparciu o bazę podstawową (lub jej kopie zapasowe czy repliki, takie jak baza stojąca fizycznie – Physical Standby). Dlatego początkowo przypomina bazę stojącą fizycznie. Jednak ponieważ baza w trybie logicznym stosuje dane REDO za pomocą wykonania poleceń SQL, jej struktura fizyczna, a nawet struktura logiczna danych, może się różnić od struktury bazy podstawowej.
W przeciwieństwie do fizycznej bazy danych w trybie standby, logiczna baza danych w trybie standby jest zazwyczaj otwierana w trybie odczytu i zapisu (READ WRITE), co pozwala użytkownikom na dostęp do niej w dowolnym momencie. Innymi słowy, wykonanie poleceń SQL zachodzi wtedy, gdy logiczna baza danych w trybie standby jest w stanie otwartym (OPEN). Ma to zarówno zalety, jak i wady. Ze względu na naturę wykonywania poleceń SQL, istnieją pewne ograniczenia operacyjne dotyczące niektórych typów danych oraz niektórych instrukcji DDL/DML w logicznej bazie danych w trybie standby. Nieobsługiwane typy danych można sprawdzić w widoku DBA_LOGSTDBY_UNSUPPORTED. Jeżeli wykorzystywane są takie typy danych, nie można zagwarantować pełnej spójności bazy danych.
Uruchomienie trybu READ WRITE dla logicznego rezerwowego serwera sprawia, że nadaje się on do wykorzystania jako system raportujący, odciążając tym samym obciążenie głównego systemu.
Cechy rezerwowego systemu logicznego:
Oprócz wymienionych wcześniej cech dotyczących fizycznej kopii zapasowej, takich jak odzyskiwanie po katastrofie, wysoka dostępność i ochrona danych, logiczna kopia zapasowa posiada następujące funkcje:
1) Efektywne wykorzystanie zasobów sprzętowych na serwerze rezerwowym: Baza danych Logiczna Rezerwowa może być wykorzystywana do tworzenia dodatkowych indeksów, widoków materializowanych oraz do zaspokajania konkretnych potrzeb biznesowych. Można w niej również tworzyć nowe schematy (które nie istnieją w bazie danych głównej) oraz wykonywać operacje DDL i DML, które nie są odpowiednie do wykonania w bazie danych głównej.
2) Odciążenie obciążenia bazy danych głównej: Utrzymując otwartą bazę danych Standby, jednocześnie pozostając zsynchronizowaną z główną bazą danych, może ona służyć zarówno ochronie danych, jak i operacjom raportowym. Pozwala to odciążyć główną bazę danych zadań raportowych i zapytań, oszczędzając cenne zasoby procesora i wejścia/wyjścia.
3) Płynne uaktualnienia: Logical Standby można wykorzystać do operacji takich jak uaktualnianie między wersjami czy poprawianie bazy danych.
Tryby ochrony danych
Data Guard umożliwia trzy tryby ochrony danych: Maksymalna ochrona, Maksymalna dostępność i Maksymalna wydajność.
1. Maksymalna ochrona:
Ten tryb gwarantuje brak utraty danych. Aby tego dokonać, wszystkie transakcje muszą zostać zapisane nie tylko do lokalnych dzienników Online Redo przed zatwierdzeniem, ale także jednocześnie do dzienników Standby Redo w bazie danych Standby. Dane REDO muszą być dostępne przynajmniej w jednej bazie danych Standby (jeśli ich wiele istnieje), zanim mogą zostać zatwierdzone w bazie danych Primary. W przypadku niedostępności bazy danych Standby spowodowanej awarią (np. przerwą w łączności sieciowej), baza danych Primary zostanie wyłączona w celu zapobieżenia utracie danych.
Włączenie tego trybu wymaga skonfigurowania bazy danych w trybie gotowości (Standby Database) z dziennikami rejestru aktywności (Standby Redo Logs) oraz użycia przez główną bazę danych (Primary Database) trybu LGWR, SYNC, AFFIRM do archiwizacji w bazie danych w trybie gotowości.
2. Maksymalna Dostępność:
Ten tryb zapewnia najwyższy poziom strategii ochrony danych, bez wpływu na dostępność bazy danych podstawowej. Wykorzystuje podobną implementację jak tryb Maksymalna Ochrona, w którym transakcje lokalne muszą zostać zapisane przynajmniej w jednej bazie danych rezerwowej (Standby) w dziennikach Standby Redo przed zatwierdzeniem. Jednak różnica polega na tym, że jeśli wystąpi błąd uniemożliwiający dostęp do bazy danych rezerwowej, baza danych podstawowej automatycznie przełączy się w tryb Maksymalnej Wydajności zamiast wyłączać się. Po odzyskaniu bazy danych rezerwowej, baza danych podstawowej automatycznie powróci do trybu Maksymalnej Dostępności.
Chociaż ten tryb ma na celu minimalizację utraty danych, nie może zagwarantować absolutnej spójności danych. Podobnie jak w przypadku Maksymalnej Ochrony, w tym trybie konieczne jest skonfigurowanie Bazy Danych Stalejącej z Dziennikami Czerwonymi Stalejącymi, a Bazie Danych Podstawowej należy używać trybu LGWR, SYNC, AFFIRM do archiwizacji w Bazie Danych Stalejącej.
3. Maksymalna wydajność:
Ten tryb zapewnia najwyższy poziom strategii ochrony danych, bez wpływu na wydajność bazy danych podstawowej. Transakcje mogą być zatwierdzane w dowolnym momencie, a dane REDO z bieżącej bazy danych podstawowej muszą zostać zapisane przynajmniej w jednej bazie danych rezerwowej, choć może to być zrobione asynchronicznie. W warunkach idealnych połączenia sieciowego, ten tryb może zapewnić ochronę danych podobną do trybu Maksymalna dostępność, mając jedynie nieznaczny wpływ na wydajność bazy danych podstawowej. Jest to domyślny tryb ochrony przy tworzeniu bazy danych rezerwowej. Może być osiągnięty za pomocą procesów LGWR ASYNC lub ARCH, a dzienniki REDO rezerwowe nie są wymagane dla bazy danych rezerwowej.
Kroki do zmiany trybu ochrony danych:
1. Wyłącz bazę danych i uruchom ją ponownie w stanie Mount. Jeśli jest to konfiguracja RAC, wyłącz wszystkie instancje i uruchom tylko jedną instancję w stanie Mount.
2. Zmodyfikuj tryb używając następującej składni:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
Na przykład: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Otwórz bazę danych: ALTER DATABASE OPEN;
4. Potwierdź zmodyfikowany tryb ochrony danych:
SQL>select protection_mode,protection_level from v$database;
Usługi stosowania dziennika
Data Guard zapewnia spójność między bazą danych podstawową a bazami danych rezerwowymi poprzez stosowanie dziennika REDO. W tle wspierając tym procesie są znane usługi stosowania dziennika. Istnieją dwa typy usług stosowania dziennika:
1. REDO Apply: Jest to funkcja wyłącznie dla fizycznych baz danych w trybie Standby, która utrzymuje je zsynchronizowane z główną bazą danych poprzez odzyskiwanie nośników.
2. Zastosowanie SQL: Wyłącznie dla logicznych baz danych typu Standby, jego podstawową funkcją jest analizowanie instrukcji SQL za pomocą LogMiner oraz ich wykonanie po stronie Standby.
Dlatego podczas stosowania danych REDO baza danych fizyczna typu Standby musi znajdować się w stanie MOUNT, natomiast baza danych logiczna typu Standby jest otwierana w trybie READ WRITE w celu aplikacji danych REDO. Jednakże domyślnie obiekty, które są utrzymywane, ustawiane są jako tylko do odczytu i nie mogą być bezpośrednio modyfikowane po stronie logicznej Standby.
Ochrona bazy danych Oracle za pomocą profesjonalnego rozwiązania
Oracle Data Guard to solidne rozwiązanie zapewniające wysoką dostępność, ochronę danych i odzyskiwanie po katastrofach. Jest to kluczowe narzędzie dla firm, które nie mogą sobie pozwolić na znaczące przestoje lub utratę danych. Jednak aby dalej zabezpieczyć środowisko bazy danych, zaleca się tworzenie kopii zapasowych bazy danych Oracle przy użyciu profesjonalnego rozwiązania do tworzenia kopii zapasowych i odzyskiwania po katastrofach.
Vinchin Backup & Recovery oferta potężne funkcje do ochrony baz danych zarówno na maszynach wirtualnych, jak i na serwerach fizycznych. Jest to rozwiązanie bardzo automatyczne, elastyczne i wydajne. Zapewnia ochronę wielu typów baz danych, w tym Oracle DB, MySQL, SQL Server, Postgres Pro i MariaDB, wspiera kompresję baz danych, scentralizowane zarządzanie zadaniami, inteligentne strategie tworzenia kopii zapasowych, tworzenie kopii zapasowych aktywnych baz danych oraz zaawansowaną obsługę SQL Servera i Oracle. Ponadto oferuje także zaawansowaną funkcję ochrony przed oprogramowaniem wymuszającym okup oraz migrację V2V między ponad 10 platformami wirtualnymi.
System Vinchin Backup & Recovery wybrano już tysiące firm, a Ty również możesz zacząć korzystać z tego potężnego systemu wraz z 60-dniową wersją próbną z pełnymi funkcjami! Skontaktuj się z nami i zostaw swoje potrzeby, a następnie otrzymasz rozwiązanie dostosowane do Twojego środowiska IT. Kontakt
Podsumowanie
Oracle Data Guard to kluczowy komponent dla każdego wdrożenia systemu Oracle Database na poziomie przedsiębiorstwa, oferujący kompleksowe rozwiązanie do odzyskiwania po katastrofach, zapewniania wysokiej dostępności, ochrony danych i równoważenia obciążenia. Jego elastyczna architektura i różne tryby pracy czynią go dostosowanym do szerokiego w zakresu potrzeb biznesowych i wymagań operacyjnych.
Możesz wybrać Vinchin Backup & Recovery, aby łatwo wykonywać kopie zapasowe i odzyskiwać swoje bazy danych Oracle. Nie przegap bezpłatnej wersji próbnej!
