Synchronizowanie baz danych nie należy do najłatwiejszych zadań. Jednak użytkownicy zdają sobie sprawę, że warto podjąć ten wysiłek.

Wszystkie dane zmagazynowano w relacyjnej bazie danych - a zawierała ona takie mnóstwo informacji o chorobach serca, jakiego zwykły śmiertelnik nie może sobie nawet wyobrazić. Baza danych miała pojemność 1,6 GB, przechowywała informacje o 92 tys. pacjentach i dysponowała ok. 500 tys. procedur. Do Medical Center of Duke Uniwersity w Durham napływały przez cały czas nowe dane z innych ośrodków medycznych na temat chorób serca. Analizując te dane lekarze mogli opracowywać strategiczne plany zwalczania dolegliwości kardiologicznych, co ratowało życie wielu tysiącom osób.

Cały problem polegał na tym, że bardzo intensywne i ciągłe eksploatowanie bazy danych doprowadziło do jej kompletnego zablokowania. Lekarze nie mogli już wstawiać do niej nowych informacji czy nawet aktualizować już istniejących tablic. Jak mówi Donald Fortin, administrator systemu informatycznego w Medical Center, wyszukiwanie stosownych informacji w bazie danych powinno ratować ludziom życie. Tymczasem, to właśnie te operacje "zabiły bazę danych".

Fortin zdecydował się więc wykonać kilka kopii bazy danych i udostępnić je lekarzom i naukowcom. Poszczególne kopie bazy danych muszą oczywiście zawierać te same informacje. Dlatego system powinien replikować je co kilka minut (np. w odstępach pięciominutowych). Na początku przypatrzono się ofercie firmy Sybase Inc. Okazało się, że Replication Server jest produktem za drogim i stosunkowo trudnym w obsłudze. Dlatego Fortin postawił na nowo opracowaną przez Microsoft technologię replikowania danych, zastosowaną w ostatniej wersji serwera SQL Server 6.0. Projekt ten wdrożono do użytku i użytkownicy mogą obecnie wyszukiwać interesujące ich dane w kilku kopiach bazy danych.

Nie obyło się oczywiście bez trudności. SQL Server wyposażono w graficzny interfejs zarządzania bazą danych, który ułatwia zadanie konfigurowania całego systemu. Żeby jednak zautomatyzować pracę aplikacji przeszukujących bazę danych i wyprofilować je stosownie do potrzeb zgłaszanych przez poszczególne grupy użytkowników, programiści musieli przejrzeć i przeprogramować tysiące linijek kodu. Zajęło to im ok. sześciu miesięcy i kosztowało 50 tys. USD. Cały problem sprowadzał się do takiego przebudowania serwera SQL Server, aby obsługiwał on w należyty sposób żądania generowane przez aplikacje statystyczne uruchamiane przez naukowców.

Problemy, które trapiły jeszcze pół roku temu centrum medyczne uniwersytetu Duke, dotykają obecnie coraz większej liczby przedsiębiorstw i instytucji. Wszystkie one kierują swoje zainteresowanie ku pracującym niezawodnie i skutecznie systemom replikowania danych. Popyt na tego rodzaju systemy nie jest jeszcze wielki. Jak podaje Gartner Group, tylko około kilkuset użytkowników eksploatuje obecnie tego rodzaju systemy.

Firmy te potwierdzają wielkie zalety systemów synchronizujących bazy danych. Superior National Insurance Inc. (Calabras, Calif.) używa produktu opracowanego przez Sybase Inc. (Replication Server). Serwer ten dostarcza agentom ubezpieczeniowym bieżących danych, dzięki czemu mogą oni oferować swoim klientom bardzo atrakcyjne warunki ubezpieczenia.

Motor tego systemu wpisuje do bazy danych (z systemów on-line do centralnego systemu informatycznego opartego na komputerze wyposażonym w 4 GB pamięci RAM) informacje biznesowe (różnego rodzaju płatności czy dane o użytkownikach). System EIS (Executive Information System) modyfikuje swoją bazę danych już w pięc sekund po odebraniu informacji z systemu on-line.

Jak twierdzi Felice Smith, dyrektor systemu informatycznego w National Insurane Inc., już po roku eksploatowania tego systemu agenci ubezpieczeniowi zwiększyli swoją wydajność na tyle, że zarobione przez nich dodatkowo pieniądze wystarczyły na utrzymanie w ruchu całego systemu informatycznego przez okres dwóch lat.

Producenci baz danych dołączają coraz częściej do swoich produktów dodatkowe pakiety replikowania danych. Ułatwia to użytkownikom zadanie wdrożenia do swoich systemów informatycznych pakietów replikowania danych, które kopiują i modyfikują całe bloki danych rezydujące w różnych miejscach systemu informatycznego i zarządzają konfliktami powstającymi w wyniku prób poddawania bazy danych edycji przez kilku użytkowników jednocześnie.

Brakujące elementy

Dysponując już wszystkimi niezbędnymi narzędziami, użytkownicy muszą się liczyć z tym, że wdrożenie do eksploatacji systemu replikowania danych wymaga sporego wysiłku. Po pierwsze, muszą oni stawić czoła typowym problemom towarzyszącym wprowadzaniu nowej technologii. Chodzi tu głównie o takie sprawy, jak niedostępność pewnych rozwiązań czy słabe wsparcie techniczne ze strony producenta. Zależnie od tego, z jakiego rodzaju bazą danych mamy do czynienia, najważniejsze opcje, jakie należałoby sprawdzić, to:

1. Możliwość zarządzania konfliktami. Żaden z systemów nie oferuje mechanizmu kaskadowego replikowania danych, to jest takiego, w którym serwer A modyfkuje serwer B, który z kolei modyfikuje serwer C. Brak takich rozwiązań może w efekcie powodować, że najświeższe dane są niszczone przez starsze.

2. Możliwość obsługiwania przez system komputerów różnych architektur. Przykład: SQL Server (Microsoft) może się komunikować tylko z bazami danych zarządzanymi przez inny SQL Server.

3. Dostępność narzędzi do administrowania pracą systemu i tworzenia nowych aplikacji. Systemy Replication Server (Sybase Inc.), Oracle (Oracle Corp.) i Informix (Informix Software Inc.) nie oferują np. żadnych mechanizmów śledzenia replikowanych danych. "Główną wadą cechującą systemy replikowania danych jest to, że użytkownik musi poświęcać bardzo wiele czasu na czynności administracyjne" - ostrzega Wayne Kernochan, dyrektor Aberdeen Group (Boston).

4. Replikacja dwukierunkowa. Produkty firmy IBM pozwalają np. przesyłać dane tylko w jednym kierunku. System nie może odesłać danych z powrotem do nadawcy.

Użytkownicy poznają niejednokrotnie tajniki pracy systemu replikowania danych w szczególny sposób: zdobywając nowe doświadczenia metodą prób i błędów. "Zdecydowaliśmy się jednym ruchem na wdrożenie do pracy systemu Replication Server, a następnie straciliśmy mnóstwo czasu na uczenie się, jak taki system obsługiwać" - mówi F. Smith.

F. Smith twierdzi, że po doświadczeniach zdobytych przez przedsiębiorstwo w ciągu ostatnich czterech lat (gdy wiele kompleksowych aplikacji oparto na produktach firmy Sybase), zrezygnowałaby ona teraz z wielu rozwiązań oferowanych przez Sybase. Nie radzi jednak tego trybu postępowania innym użytkownikom, dodając: "główna korzyść nie polega na tym, aby nauczyć się instalowania systemu, ale na tym, aby poznać jego konstrukcję i oferowane przez system możliwości".

Jaką strategię obrać?

Nie można w prosty sposób wprowadzać mechanizmów replikowania danych do eksploatowanych już aplikacji. Należy raczej tworzyć te aplikacje od początku, mając cały czas na uwadze zagadnienie zintegrowania ich z systemem replikowania danych.

"Aby zbudować system transakcyjnego replikowania danych (który będzie w stanie replikować dane rezydujące w każdym miejscu systemu informatycznego), należy przyjąć pewne założenia już w trakcie konstruowania aplikacji. W przeciwnym przypadku, cała sprawa może się skończyć niepowodzeniem" - mówi Bobby Cameron, programista pracujący w Forrester Research Inc. (Cambrodge, Mass.).

Relacyjne bazy danych nie tworzono z myślą o stosowaniu systemów synchronizujących ich zawartość. Dlatego użytkownicy muszą krok po kroku przebudowywać eksploatowane przez siebie bazy danych. Mało kto decydowałby się od razu powierzać lokalnym serwerom zadanie zapełniania korporacyjnej hurtowni danych.

Prawda jest taka, że systemy replikowania danych nie staną się produktami ogólnego stosowania jeszcze przez najbliższe kilka lat. Jest to zupełnie nowa technologia. Pionierem w tej dziedzinie była firma Sybase, która wprowadziła tę technologię pierwszy raz na rynek raptem dwa lata temu. Systemy replikowania baz danych firmy Oracle pojawiły się rok temu, a Microsoft zaprezentował swój pierwszy produkt latem br.

Przez cały czas producenci baz danych poszukują nowych sposobów replikowania informacji. Oracle pracuje np. nad narzędziami, które będą automatycznie wykonywać wiele zadań biznesowych. Jeśli użytkownik eksploatuje np. dzisiaj jeden duży, centralny serwer i zechce powielić go na szereg zapasowych serwerów (pracujacych w różnych miejscach systemu informatycznego), produkt firmy Oracle wykona to zadanie automatycznie. Użytkownik musi jedynie dostarczyć aplikacji wielu informacji, na podstawie których zbuduje ona odpowiedni mechanizm replikowania danych.

Microsoft pracuje natomiast nad sterownikami standardu ODBC (Open DataBase Connectivity), które pozwolą replikować dane między serwerami SQL Server i innymi bazami danych dysponującymi interfejsem ODBC. Sybase oferuje od niedawna użytkownikom usługi konsultingowe, pozwalające wdrażać do systemów informatycznych aplikacje replikowania danych.

Czy jest zatem sens podejmowania tego tematu już teraz i wertowania ofert niektórych firm? Uniwersyste Duke miał do wyboru dwie drogi: poddać swój system implementacji lub stworzyć nowy system od samego początku. Ta druga opcja nie wyglądała zbyt zachęcająco. London Life Insurance Co. nie miał natomiast wyboru i musiał jak najszybciej wdrożyć system replikowania danych. Dopiero po wprowadzeniu tego systemu firma ta mogła dostarczyć aktualne dane ok. trzem tysiącom pracowników.

London Life Insurance Co. eksploatuje 150 serwerów baz danych firmy Sybase, zlokalizowanych w terenowych biurach firmy. Dane z tych serwerów są replikowane (via bramę Sybase) na centralną bazę danych formatu DB2 (o pojemności 60 GB), zainstalowaną na komputerze mainframe firmy IBM. John Thompson, dyrektor działu informatycznego w London Life Insurance Co. mówi, że programiści koncentrują się obecnie na oprogramowaniu, które pozwalałoby użytkownikom pracującym pod systemem Windows uzyskiwać szybki dostęp do danych rezydujących na dyskach lokalnych serwerów.

Pracownicy terenowych biur tej firmy mogą teraz korzystać z aktualnych danych, które są przechowywane na serwerach pracujących w lokalnych sieciach komputerowych. Nie ma więc już potrzeby ciągłego komunikowania się z odległą, centralną bazą danych. Redukuje to ruch pakietów w sieci, zmniejsza koszty pozyskiwania informacji, odciąża centralną bazę danych i skraca czas dostępu do danych.

Tak jak wiele innych standardowych przedsięwzięć podejmowanych z myślą o usprawnieniu pracy środowiska klient/serwer, tak i wdrażanie systemów replikowania danych nie należy do najłatwiejszych zadań. Ale zyski mogą przewyższyć ewentualne nakłady.