Replikacja w rozproszonych heterogenicznych bazach danychna przykładzie Microsoft SQL Server 2000 i Oracle 9i.

Abstract

W niniejszej pracy pragnę poruszyć temat replikacji w heterogenicznych rozproszonych systemach baz danych i korzyści jakie wynikają z jego zastosowania w firmach i instytucjach, na przykładzie baz danych Microsoft SQL Server 2000 oraz Oracle 9i. Okazuje się, że w praktycznych zastosowaniach bardzo często zupełnie wystarczające jest gdy dane w bazach na różnych serwerach firmy są zbieżne z niewielkim opóźnieniem. Dane są zbieżne w odniesieniu do np. początku danego dnia. W wyjątkowych wypadkach wymagana może być zbieżność danych np. w kilka - kilkanaście sekund po zmodyfikowaniu danych na jednym z serwerów. Wszystkie te sytuacje najlepiej rozwiązać za pomocą replikacji. Natomiast sytuacje gdy wymagana jest jednoczesna spójność danych czyli: zmiana jest wprowadzana jednocześnie na wszystkich serwerach biorących udział w replikacji jest żadka i rozwiązuje się je przy pomocy transakcji rozproszonych i dwu fazowego protokołu zatwierdzania (2PC – two phase commit). Replikacja w przeciwieństwie do 2PC nie wymaga stałego i niezawodnego łącza miedzy wszystkimi serwerami. Daje nam to np. mniejsze koszty utrzymania łączy sieciowych. Ponadto są sytuacje w których praktycznie nie jest możliwe zapewnienie takiego stałego podłączenia do sieci. Przykładem mogą być tutaj regionalni przedstawiciele handlowi z np. własnym laptopem. Przedstawiciel będąc poza biurem (w terenie) może mieć np. wyłączonego laptopa lub nie mieć połączenia z siecią. Replikacja również w takich sytuacjach sprawdza się znakomicie. Dlatego pragnę wykazać, że replikacją jest opłacalna, a w wielu wypadkach jest to najlepsze rozwiązanie. Dzisiejsze bazy danych firm i różnych instytucji są bardzo często rozproszone. Oznacza to, że baza danych firmy czy instytucji nie znajduje się tylko na jednym serwerze lecz na kilku które mogą być w różnych miastach czy nawet państwach. Dzieje się tak, dlatego że dostęp do danych zawartych w bazie danych jest szybszy, gdy serwer znajduje się „tam gdzie my” oraz dlatego że dany oddział firmy czy instytucji z reguły najczęściej potrzebuje informacji dotyczących „swojego terenu”, które gdyby były przechowywane na scentralizowanym odległym serwerze byłyby trudniej dostępne i czas dostępu do nich byłby zdecydowanie dłuższy, wymagałoby to również bezpiecznego, szybkiego i niezawodnego łącza internetowego. Niedostępność serwera centralnego, na którym znajduje się cała baza firmy, powodowałaby niemożność jakiegokolwiek korzystania z danych tam zawartych, a co za tym idzie, z reguły całkowity paraliż danego oddziału. Niedostępność serwera może być spowodowana np.: awarią sieci w centrali, awarią serwera centralnego czy awarią sieci w oddziale. Dlatego dane coraz częściej przechowywane są na lokalnym serwerze w lokalnej bazie danych, a nie w „centrali”. Taka lokalna baza danych może pracować samodzielnie w razie awarii sieci czy serwera centralnego. Jest ona stale uaktualniana i może również mieć możliwość propagowania zmian wprowadzonych lokalnie. Replikacja danych w takich systemach wprowadza właśnie uaktualnianie danych między serwerami. Heterogeniczność w systemach rozproszonych baz danych daje firmom, które np.: przejęły inną firmę, możliwość nie wprowadzania nowego systemu do tamtej części organizacji w przypadku, gdy jest on inny niż w pozostałej „starej” części organizacji. Postępowanie takie ma wymierne korzyści w postaci oszczędności, których dokonujemy nie zakupując nowego systemu dla tej „nowej części naszej organizacji”, nie musimy przeprowadzać szkoleń pracowników w celu nauczenia ich obsługi nowego systemu. Takie szkolenia, poza ich oczywistym kosztem, pociągają za sobą koszty w postaci ograniczenia wydajności, gdyż pracownicy nie będą w stanie „z miejsca przesiąść się na nowy system”. Nawet po ukończeniu szkolenia osiągnięcie poprzedniej wydajności pracy może trochę potrwać. Kolejnym wydatkiem będzie migracja danych do nowych systemów. Cały proces wraz z przetestowaniem nowego systemu to okres, w którym taka „nowa część organizacji” nie będzie w pełni sprawna. W heterogenicznym środowisku baz danych z reguły jeden z systemów jest dominujący. W swojej pracy, a w szczególności w części praktycznej przyjąłem za dominujący system Microsoft SQL Server 2000.