Oracle

Serwery Oracle mają dwa podstawowe sposoby replikacji, które mogą być wykorzystane także w mechanizmach typu failover. Pierwszy (podstawowy) polega na tym, że wprowadzane zmiany są rejestrowane lokalnie, a następnie przekazywane na każdy zdalny serwer (wcześniej jest wymagane skonfigurowanie Oracle Net Services/SQL*Net). Ten mechanizm pozwala przesłać dane, ale nie umożliwia przekazywania zmian struktury bazy.

Drugi sposób (zaawansowany) sprowadza się do przesyłania informacji o zatwierdzonych transakcjach - bez względu na to, czy dotyczą danych, czy schemat bazy był zmieniony. W ten sposób zamiast jednostkowych operacji w zasadzie są przekazywane wyniki działania transakcji. W przypadku złożonych procesów biznesowych może to przynosić duże oszczędności - zwykle pakiet opisujący wynik działania transakcji będzie mniejszy niż suma "składowych operacji".

Replikacją w tym wydaniu zarządza komponent kolejkujący Oracle Advanced Queuing. OAQ jest w stanie komunikować się na wiele sposobów. Pakiet z informacją o transakcji może być zapisany jako XML i przekazany za pomocą protokołu HTTP (nie jest to jednak pakiet SOAP). Można też wykorzystać kanał SMTP. OAQ jest znacznie wygodniejszy niż pierwsza metoda, zwłaszcza w sytuacji, gdy bazy są połączone przez sieć WAN.

W Oracle replikacja standardowa jest związana z koncepcją zdalnych, utrwalonych widoków. Upraszczając, administrator definiuje w zdalnej bazie widok, który odwołuje się do bazy podlegającej replikacji. W momencie, gdy następuje zmiana w replikowanej porcji danych (wykrywa to trigger), zmiany są kolejkowane i przesyłane na zdalną maszynę. W ten sposób po drugiej stronie aplikacje mają do czynienia ze specjalnymi "widokami", które automatycznie ulegają zmianie podczas replikacji. Podobnie replikowane są zmiany wprowadzone po stronie "zdalnej".

Od wersji 9i w serwerach Oracle istnieje trzeci mechanizm replikujący - Oracle Stream. Jego działanie przypomina nieco dotychczasowy mechanizm replikacji przez OAQ, tak naprawdę jednak niewiele różni się od rozwiązania ETL służącego do zasilania hurtowni danych. Podobnie jak w ETL, operacja składa się z trzech etapów. Podczas etapu pierwszego (capture) przechwytywane są wykonywane na bazie operacje DDL/DML. W drugim etapie (staging) przechwycone operacje są analizowane przez specjalne algorytmy. Trzeci etap (consumption) polega na wykonaniu operacji w bazie docelowej na podstawie wyniku analizy.

Oracle Stream może też przechwytywać zdarzenia generowane programowo, np. aplikacja może informować o istotnych zmianach, które mają być dalej "replikowane". Definiując zdarzenia do przechwycenia, administrator tworzy zestaw reguł, które określają nie tylko, które zdarzenia są analizowane, ale także oznaczają zdarzenia w zależności od "cech", co później pozwala na analizowanie i agregowanie danych. W momencie analizy dodatkowe reguły mogą określić, do jakich innych obszarów (czy docelowych baz) dane zdarzenie zostanie propagowane. Ponadto zdarzenia można łączyć, wyrzucać zbędne, dane transformować itp. O ile w replikacji "zaawansowanej" system przechwytuje zmiany po zatwierdzeniu transakcji, o tyle tu można sprawować znacznie dokładniejszą kontrolę nad całym procesem.

IBM DB2 UDB

W DB2 do replikacji są wykorzystywane aplikacje zewnętrzne w stosunku do serwera, sama baza DB2 zaś jest tylko "pojemnikiem" na dane. Program Capture czyta pliki log, wyszukując w nim aktualizacje odnoszące się do określonego zakresu replikacji, i przenosi je do lokalnej tabeli DB2 nazywanej zwykle CD. Odbywa się to już po zatwierdzeniu transakcji. Capture kasuje dane z tabeli CD, gdy nie są już potrzebne. Program Apply odczytuje zarejestrowane w tabeli CD transakcje i wykonuje je na serwerze docelowym.

Apply może działać na dowolnym serwerze, pod warunkiem że może z niego uzyskać połączenie zarówno z tabelą CD, jak i bazą docelową.

Specjalny Replication Alert Monitor analizuje na bieżąco działanie programów Capture i Apply i na podstawie warunków zdefiniowanych przez administratora informuje, czy replikacja przebiega prawidłowo. Oprócz tego IBM oferuje interfejs użytkownika, który ma pomóc w konfiguracji programów wykonujących replikację. Warto dodać, że na platformach Windows i Unix jest dostępny także program asnclp, który pozwala na skonfigurowanie replikacji z linii poleceń.

Inne narzędzia

Oprócz mechanizmów wbudowanych w konkretne bazy danych, na rynku są dostępne dziesiątki rozwiązań, które - jak twierdzą ich producenci - mają sprawić, iż replikacja będzie "bezproblemowa".

DataMirror oferuje szeroką gamę narzędzi wspierających replikację. Jej Transformation Server pozwala na bezpośrednią wymianę informacji pomiędzy DB2, SQL Server, Oracle, Sybase na każdej platformie systemowej - od Windows po z/OS. Tworzenie rozwiązania replikacyjnego nie wymaga tu pracy programistów na konkretnej bazie danych - operacje są definiowane w ramach DataMirror. Administrator może przekształcać wartości, definiować nowe pola wyliczeniowe, wykonywać dowolne złączenia tabel itp. Specjalny język makr pozwala w efektywny sposób tworzyć własne transformacje. Dodatkowa aplikacja monitorująca umożliwia obserwowanie stanu całego systemu (opóźnień, konfliktów itp.). Podobne rozwiązanie o nazwie Mimix (obecnie już nie tylko dla AS/400 i iSeries, ale także Windows i AIX) znajduje się w ofercie firmy Lakeview Technology.

Innym ciekawym produktem DataMirror jest DB/XML Transform. Nie jest to rozwiązanie wyłącznie replikacyjne, a raczej moduł umożliwiający "tanią" integrację aplikacji za pośrednictwem XML. Narzędzie pozwala z dowolnego źródła danych (pliku, konkretnej platformy bazodanowej itp.) wygenerować dokument XML, a potem "odtworzyć" go w innej lokalizacji. Pakiet ten jest przeznaczony głównie do stosowania takich sytuacjach, gdy trzeba zmieniać struktury hierarchiczne w struktury "płaskie", i na odwrót. Oprócz wymiany danych pomiędzy bazami, DB/XML Transform może być używany, gdy np. dane z bazy mają się znaleźć na portalu i będą przetwarzane tak jak inne dokumenty w systemie zarządzania treścią. Podobnie jak Transformation Server, produkt ma dość prosty interfejs pozwalający wszystkie operacje wykonywać bez pisania kodu.