Rozdział monografii: `Bazy Danych: Struktury, Algorytmy, Metody

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 9
w
Zarządzanie danymi rozproszonymi na przykładzie
serwera bazy danych Oracle
w
1 Wstęp
da
.b
w
Streszczenie. Rozproszenie stanowi obecnie ważny aspekt rozwoju systemów baz danych. Możliwe jest łączenie baz danych za pomocą pomostów,
które stwarzają sposobność wykonywania zdalnych zapytań i replikacji danych. W rozdziale omówione zostaną na przykładzie serwera bazy danych
Oracle mechanizmy wykorzystywane do tworzenia środowisk rozproszonych. Szczególny nacisk zostanie położony na zaprezentowanie różnych wariantów replikacji. Przedstawiona zostanie też aplikacja i pakiety zawierające
funkcje API umożliwiające zarządzanie bazami rozproszonymi.
pl
s.
Rozproszenie to jedna z najistotniejszych cech współczesnych systemów informatycznych.
System rozproszony (ang. distributed system) określamy jako zbiór samodzielnych komputerów połączonych za pomocą sieci, wyposażonych w oprogramowanie zaprojektowane
z myślą o utworzeniu zintegrowanego środowiska przetwarzania. Oprogramowanie takiego
systemu umożliwia komputerom koordynowanie ich działań oraz dzielenie zasobów systemu: sprzętu, oprogramowania i danych. Użytkownicy systemu rozproszonego powinni odbierać go jako jedno zintegrowane środowisko przetwarzania, pomimo że może ono być realizowane za pomocą wielu komputerów znajdujących się w różnych miejscach. Rozproszenie może przejawiać się w różnoraki sposób. Daje możliwość rozproszenia przetwarzania, polegającego na tym, że wiele komputerów pracuje na rzecz jednej aplikacji oraz rozproszenia danych, polegającego na tym, że dane potrzebne jednej aplikacji są przechowywane na kilku komputerach.
Współczesne systemy informatyczne często ewoluują od rozwiązań scentralizowanych
w kierunku systemów rozproszonych. Działanie takie jest spowodowane korzyściami płynącymi z wykorzystania systemów rozproszonych. Do podstawowych cech takich systemów zaliczamy bowiem: możliwość wspólnego użytkowania zasobów, otwartość, współbieżność, skalowalność, tolerowanie uszkodzeń i przezroczystość. Szczegółową specyfikację systemów rozproszonych przestawia praca [1].
W ostatnich latach szczególnie daje się zauważyć rozwój rozproszonych baz danych
(ang. distributed database systems). Aby zaspokoić potrzeby klientów firm, mających swoje oddziały w coraz bardziej odległych geograficznie miejscach, zaistniała konieczność łączenia pojedynczych baz w systemy rozproszone. Wielu producentów komercyjnych systeMarcin Włodarski: Uniwersytet Łódzki, Wydział Matematyki,
ul. Banacha 22, 90-238 Łódź, Polska
email: [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
M. Włodarski
mów zarządzania bazami danych oferuje możliwość tworzenia środowisk rozproszonych.
Na podstawie serwera bazy danych Oracle zostaną omówione podstawowe aspekty projektowania systemów rozproszonych ze szczególnym uwzględnieniem mechanizmów replikacji. Ponieważ ręczna konfiguracja rozproszenia jest dość skomplikowana i wymaga znajomości funkcji API, dlatego w celu ułatwienia tego procesu powstał program Replication
Configurator, stanowiący graficzny interfejs użytkownika w procesie tworzenia takich
środowisk.
w
2 Podstawy replikacji
w
w
Replikacja jest to proces kopiowania i zarządzania obiektami wielu baz danych stanowiący
podstawową koncepcję systemów baz rozproszonych. Zmiany wprowadzone w jednym
miejscu są najpierw zapisywane i składowane lokalnie, a następnie wysyłane i zapisywane
w każdym zdalnym punkcie sytemu rozproszonego. Replikacja zapewnia użytkownikom
szybki dostęp do lokalnych współdzielonych danych i niezawodność w działaniu aplikacji.
W przypadku, gdy jeden węzeł systemu rozproszonego staje się niedostępny, użytkownik
nadal może wykonywać operacje (zapytania a nawet zmiany) na zdalnych danych.
da
.b
2.1 Pomosty bazodanowe
W celu zapewnienia komunikacji pomiędzy bazami replikacyjnymi niezbędne jest utworzenie pomostu bazodanowego. Umożliwia on odwoływanie się z bazy lokalnej do obiektów
z bazy odległej. Pomosty bazodanowe mogą być definiowane jako prywatne bądź publiczne. Nazwa użytkownika specyfikowana przy definiowaniu połączenia określa kontekst
uprawnień i bezpieczeństwa odwołań do zdalnych obiektów. Składnia polecenia tworzącego pomost bazodanowy:
CREATE [PUBLIC] DATABASE LINK NAZWA_POMOSTU CONNECT TO UZYTKOWNIK
IDENTIFIED BY HASLO USING ‘NAZWA_POLACZENIA’;
2.2 Obiekty, grupy i strony replikacyjne
pl
s.
Wyspecyfikowana powyżej NAZWA_POLACZENIA oznacza nazwę połączenia do bazy
zdalnej zdefiniowaną w pliku tnsnames.ora na serwerze lokalnym.
Obiektem replikacyjnym (ang. replication object) nazywamy obiekt bazodanowy istniejący
na wielu serwerach tworzących rozproszony system baz danych. SZBD Oracle wspomaga
replikacje obiektów takich jak tabele, perspektywy, wyzwalacze, pakiety, indeksy i synonimy.
Aby ułatwić zarządzanie zaawansowanej replikacji, obiekty replikacji są grupowane
w grupy replikacji (ang. replication group), które mogą zawierać obiekty replikacyjne
z różnych schematów baz danych. Jedynym ograniczeniem jest to, że każdy obiekt replikacji może być włączony tylko do jednej grupy replikacji. Grupa replikacji na głównym
komputerze macierzystym jest zwana grupą główną (ang. master group). Grupa replikacji
na komputerze macierzystym zawierającym obraz (ang. snapshot site) jest zwana grupą
obrazową lub grupą migawek (ang. snapshot group). Grupa migawek jest zbiorem obiektów zawierającym częściową lub pełną kopię grupy obiektów ze strony źródłowej.
90
Zarządzanie danymi rozproszonymi na przykładzie serwera bazy danych Oracle
w
Zbiór grup replikacyjnych składa się na stronę replikacyjną – komputer macierzysty replikacji. Rozróżniamy dwie podstawowe strony replikacyjne:
− strona źródłowa (ang. master site) – komputer macierzysty główny. Zawiera pełną
kopię wszystkich obiektów z grup replikacyjnych. Wszystkie strony źródłowe w replikacji wieloźródłowej komunikują się między sobą w celu propagacji zmian danych i schematów w grupach replikacyjnych. Grupy tworzące stronę źródłową nazywają się grupami źródłowymi. Każda grupa źródłowa ma dokładnie jedną definicyjną
stronę źródłową. Grupy z definicyjnej strony źródłowej stanowią punkt kontrolny do
zarządzania innymi grupami i obiektami replikacyjnymi.
− strona migawek (ang. snapshot site) – komputer macierzysty zawierający obraz.
Składa się z obrazów (tylko do odczytu lub modyfikowalnych), zbudowanych na
podstawie tabel, które są dostępne ze strony źródłowej za pośrednictwem połączeń
bazodanowych (ang. database links). Po stronie migawek mogą zostać zreplikowane
wszystkie tabele ze strony źródłowej lub dowolny podzbiór tych tabel. Migawki muszą być oparte na dokładnie jednej tabeli źródłowej. Strona migawek może więc
zawierać obrazy utworzone tylko dla wybranych obiektów z grupy replikacyjnej. Co
więcej migawka może przechowywać tylko pewną porcję danych z tabeli źródłowej.
Grupy replikacyjne po stronie migawek nazywają się grupami migawkowymi. Grupy
takie mogą oprócz tabel zawierać też inne obiekty: perspektywy, procedury, funkcje,
pakiety, wyzwalacze, indeksy i synonimy.
da
.b
w
w
2.3 Replikacja wieloźródłowa
Replikacja wieloźródłowa (ang. multimaster replication) pozwala wielu stronom replikacyjnym na zarządzanie grupami replikowanych obiektów bazodanowych. Rys. 1 ilustruje
system replikacji wieloźródłowej.
pl
s.
Rys. 1. Replikacja wieloźródłowa
91
M. Włodarski
w
Serwery baz danych Oracle pracujące jako strony (bazy) źródłowe w konfiguracji wieloźródłowej automatycznie zbierają dane ze wszystkich replikowanych tabel oraz zapewniają
spójność i integralność danych. Replikacja wieloźródłowa jest przydatna w wielu systemach użytkowych posiadających specjalne wymagania odnośnie ciągłej dostępności danych. Na przykład środowisko rozproszone może replikować wszystkie dane z określonej
bazy w celu zapewnienia bazy rezerwowej (ang. failover site) w przypadku, gdy niedostępna jest baza podstawowa (z powodu awarii systemu lub uszkodzenia sieci komputerowej).
Z drugiej strony zapasowy serwer baz danych może działać jako w pełni funkcjonalna baza
wspomagająca dostęp aplikacji do danych, nawet gdy serwer podstawowy jest sprawny.
Replikacja wieloźródłowa jest też wykorzystywana przez transakcje pochodzące od aplikacji wymagających wielu punktów dostępu do danych. Działanie takie umożliwia rozproszenie dużego obciążenia aplikacji przy jednoczesnym zapewnieniu ciągłej dostępności danych o możliwie najbliższej lokalizacji. W SZBD Oracle własność taką zapewnia wykorzystanie zapisywalnych migawek.
w
w
2.4 Replikacja migawkowa
W replikacji migawkowej, zwanej też obrazową (ang. snapshot replication) migawki mogą
stanowić pełną lub częściową replikę tabeli źródłowej. Migawki dzielimy na tylko do odczytu (ang. read-only snapshots) i modyfikowalne (ang. updateable snapshots).
da
.b
3 Koncepcja i architektura migawek
Oracle używa migawek-obrazów (ang. snapshots), mających w systemie postać perspektyw zmaterializowanych, aby zapewnić dostarczanie danych do nieźródłowych stron środowiska replikacyjnego i buforować czasochłonne zapytania do bazy. Migawka jest to replika
tabeli lub tabel ze strony głównej, przechowująca podzbiór danych tych tabel. Aby umożliwić różne konfiguracje środowiska rozproszonego Oracle udostępnia wiele typów migawek.
pl
s.
3.1 Migawki z kluczem głównym
Podstawowym rodzajem migawek są migawki z kluczem głównym. Są one modyfikowalne, jeśli obraz był tworzony jako część grupy migawek i polecenie tworzące zawierało
klauzulę FOR UPDATE. Zmiany są propagowane zgodnie z modyfikacjami wierszy identyfikowanymi przez klucz główny. Komenda języka SQL tworząca modyfikowalną migawkę
z kluczem głównym ma postać:
CREATE SNAPSHOT NAZWA_SCHEMATU.NAZWA_MIGAWKI FOR UPDATE AS
SELECT * FROM NAZWA_SCHEMATU.NAZWA_TABELI@NAZWA_POMOSTU;
Migawki z kluczem głównym mogą zawierać podzapytania, umożliwiające stworzenie
poziomego podzbioru danych na bazie zdalnej. Podzapytania mogą być proste (zawierające
podstawową klauzulę WHERE) lub złożone (zawierające wielopoziomową klauzulę
WHERE EXISTS). Migawki z kluczem głównym budowane przy pomocy poleceń zawierających podzapytania mogą być odświeżane przyrostowo. Poniższe polecenie tworzy obraz
odświeżany inkrementacyjnie i zawierający podzapytanie:
92
CREATE SNAPSHOT NAZWA_SCHEMATU.NAZWA_MIGAWKI REFRESH FAST AS
SELECT * FROM NAZWA_SCHEMATU.NAZWA_TABELI@NAZWA_POMOSTU
WHERE EXISTS
(
SELECT 1 FROM NAZWA_SCHEMATU.NAZWA_TABELI@NAZWA_POMOSTU
WHERE WARUNEK );
w
3.2 Migawki z identyfikatorem wiersza ROWID
w
Aby zapewnić zgodność wstecz Oracle wspomaga migawki z identyfikatorem wiersza. Bazują one na fizycznych identyfikatorach wierszy (ang. ROWIDs) z tabeli źródłowej. Ten rodzaj migawek powinien być stosowany tylko w przypadku obrazów bazujących na tabelach
z bazy danych Oracle 7. Nie zaleca się jego używania w przypadku budowania nowych migawek opartych o tabele z bazy danych Oracle w wersjach późniejszych od 8.
CREATE SNAPSHOT NAZWA_SCHEMATU.NAZWA_MIGAWKI REFRESH WITH ROWID AS
SELECT * FROM NAZWA_SCHEMATU.NAZWA_TABELI@NAZWA_POMOSTU;
w
3.3 Migawki tylko do odczytu
da
.b
W podstawowej konfiguracji migawki zapewniają dostęp tylko do odczytu danych replikowanych z tabel ze strony źródłowej. Aplikacje, niezależnie od stanu sieci i dostępności bazy
podstawowej, mogą korzystać z lokalnych danych. Programy mają więc możliwość wysyłania zapytań do lokalnej bazy. Jednakże gdy zachodzi konieczność dokonania zmian w danych wówczas aplikacje operują na podstawowej bazie. Rys. 2 przedstawia podstawową replikację tylko do odczytu.
pl
s.
Rys. 2. Replikacja opierająca się na migawkach tylko do odczytu
93
M. Włodarski
Podstawowe korzyści płynące z wykorzystania migawek tylko do odczytu:
− tabela źródłowa nie musi należeć do replikacyjnej grupy źródłowej,
− migawki mogą być złożone tzn. mogą bazować na jednej lub wielu tabelach. Zapytania tworzące obrazy tylko do odczytu mogą zawierać dodatkowo funkcje agregujące,
łączące i klauzule CONNECT BY,
− zapewniają lokalny dostęp, co skraca czas oczekiwania i ułatwia dostępność danych,
− odciążenie zapytań kierowanych do strony źródłowej.
w
3.4 Migawki modyfikowalne
da
.b
w
w
W bardziej zaawansowanej konfiguracji można wykorzystać migawki modyfikowalne, pozwalające programom użytkowym na dodawanie, zmianę i usuwanie wierszy z tabeli źródłowej. Obrazy modyfikowalne mogą stanowić tylko podzbiór wszystkich tabel ze strony
źródłowej. Aby móc używać tego typu migawek strona źródłowa musi być skonfigurowana
do wspierania replikacji typu multimaster. Migawki modyfikowalne muszą zaś należeć do
grup replikacyjnych bazujących na grupach ze strony źródłowej. Migawki modyfikowalne
posiadają następujące cechy:
− są zawsze oparte na pojedynczej tabeli i mogą być odświeżane przyrostowo (ang.
fast refresh),
− SZBD Oracle propaguje zmiany wprowadzone w modyfikowanej migawce do tabeli
źródłowej, znajdującej się na serwerze zdalnym. Jest to konieczne do kaskadowej
zmiany w innych stronach źródłowych,
− Oracle odświeża migawki modyfikowalne w ramach grup odświeżania (ang. refresh
group), zapewniających spójność danych,
Migawki modyfikowalne dają następujące korzyści:
− pozwalają użytkownikom na wykonywanie zapytań i zmian na lokalnych danych replikacyjnych nawet w przypadku rozłączenia ze stroną podstawową,
− zwiększają bezpieczeństwo danych poprzez replikację wybranych tabel źródłowych
(stanowią kopię bezpieczeństwa wybranego zbioru danych),
− zajmują mniejszą przestrzeń dyskową niż replikacja wieloźródłowa.
pl
s.
3.5 Migawki złożone
Jeśli w danym środowisku replikacyjnym nie istnieje konieczność odświeżania przyrostowego, wówczas można utworzyć migawki złożone, zawierające funkcje agregujące lub
operatory zbiorowe. Migawki nazywamy złożonymi jeśli zapytanie tworzące zawiera:
− funkcję DISTINCT lub funkcje agregujące,
− klauzulę CONNECT BY,
− operatory zbiorowe (UNION, INERSECT, MINUS).
3.6 Budowa migawki
Mechanizmy używane przez migawki są przedstawione na rys. 3. Niektóre z nich są opcjonalne i bywają używane tylko w celu wspomagania tworzenia danego środowiska rozproszonego, np. dla migawek tylko do odczytu nie powstają na bazie zdalnej dzienniki modyfi-
94
kacji i wewnętrzne wyzwalacze. Ponadto dla migawek złożonych, które nie mogą być odświeżane przyrostowo nie jest konieczne tworzenie dzienników na bazie głównej.
w
da
.b
w
w
Rys. 3. Replikacyjne mechanizmy migawek
pl
s.
Po stronie bazy źródłowej można wyróżnić następujące elementy migawki:
− tabela źródłowa (ang. master table). Tabela źródłowa stanowi podstawę migawki
i jest usytuowana na bazie wzorcowej. Zmiany wprowadzone do tej tabeli są zapisywane w dzienniku i propagowane do migawki w procesie odświeżania. Tabela źródłowa występuje zarówno dla replikacji wieloźródłowej jak i migawkowej.
− wewnętrzny wyzwalacz (ang. internal trigger). Jeśli na tabeli źródłowej dokonano
zmian w wyniku użycia poleceń DML, to wewnętrzny wyzwalacz zapisuje klucz
główny i/lub ROWID wierszy, których dotyczyły modyfikacje i filtruje odpowiednie
kolumny do dziennika migawki. Wewnętrzny wyzwalacz powstaje i jest aktywowany w momencie tworzenia dziennika migawki na tabeli podstawowej.
− dziennik migawki (ang. snapshot log) Dziennik migawki jest reprezentowany w systemie Oracle przez wewnętrzną tabelę. Dziennik obrazu przechowuje klucze główne
i opcjonalnie ROWID dla wierszy, które były zmieniane na bazie źródłowej. Dziennik może zawierać ponadto filtrowane kolumny w celu zapewnienia możliwości
odświeżania przyrostowego dla migawek z podzapytaniami. Dziennik migawki nazywa się MLOG$_NAZWA_TABELI_PODSTAWOWEJ i powstaje w tym samym schemacie co tabela źródłowa. Pojedynczy dziennik utworzony dla danej tabeli może
obsługiwać wiele migawek.
95
M. Włodarski
w
Kiedy powstaje migawka, szereg dodatkowych mechanizmów jest tworzonych po stronie
bazy zdalnej:
− tabela bazowa (ang. base table). Począwszy od SZBD Oracle 8i wersji 8.1.5, tabela
bazowa stanowi aktualny obraz (nie jest potrzebna żadna perspektywa). Tabela bazowa ma tą samą nazwę jaka została wyspecyfikowana w procesie tworzenia. Jeśli
kompatybilność bazy migawek jest mniejsza niż 8.1, to tabela bazowa stanowi ukryty
mechanizm wspomagania powstałego widoku. Gdy tabela bazowa stanowi mechanizm wspomagania dla perspektywy, to posiada ona nazwę SNAP$ _NAZWA
_MIGAWKI. Wszystkie indeksy generowane podczas tworzenia migawki powstają
na tabeli bazowej.
− perspektywa – jest tworzona dla wspomagania replikacji na bazach Oracle w wersji
8.0 i wcześniejszych (jeśli kompatybilność bazy migawek jest ustawiona na mniejszą
niż 8.1, to perspektywa jest zawsze tworzona). Jeśli widok był utworzony, to posiada
on tą samą nazwę co wyspecyfikowana nazwa migawki w poleceniu tworzącym.
− indeks – przynajmniej jeden indeks jest tworzony na zdalnej bazie migawek dla każdego powstającego obrazu. Indeks ten odpowiada kluczowi głównemu z tabeli źródłowej. Dodatkowe indeksy mogą być tworzone przez Oracle do wspomagania odświeżania przyrostowego migawek z podzapytaniami. Podstawowy indeks nosi nazwę I_SNAP$_NAZWA_MIGAWKI.
− lokalny dziennik (ang. local log). Lokalny dziennik zmian (USLOG$_NAZWA
_MIGAWKI) jest używany do określania, które dane muszą być propagowane do tabeli źródłowej. Migawki tylko do odczytu nie potrzebują tego mechanizmu.
− wewnętrzny wyzwalacz. Tak samo jak w przypadku strony źródłowej, wewnętrzny
wyzwalacz po stronie migawek zapisuje zmiany DML zaistniałe w obrazie do dziennika zmian USLOG$_NAZWA_MIGAWKI.
da
.b
w
w
3.7 Proces odświeżania migawki
pl
s.
Dane zawarte w migawkach i odpowiadających im tabelach nie zawsze są zgodne. Migawka jest dokładnym odzwierciedleniem danych z tabeli źródłowej tylko w pewnych momentach – w czasie tworzenia obrazu i po jego odświeżeniu. Dlatego aby zapewnić jak największą zgodność danych trzeba periodycznie aktualizować migawki. Proces odświeżania jest
operacją przetwarzania wsadowego zapewniającą uzgodnienie danych pomiędzy stronami
środowiska rozproszonego. Kiedy i jak często powinna być przeprowadzana aktualizacja
zależy od konkretnej sytuacji i właściwości bazy, np. migawki bazujące na tabelach, które
są często zmieniane przez aplikacje powinny być często odświeżane, natomiast obraz oparty na statycznej tabeli (zmieniającej się relatywnie rzadko) nie wymaga tak częstej aktualizacji. W efekcie do określenia najodpowiedniejszych interwałów odświeżania należy przeanalizować charakterystyki aplikacji stanowiących interfejs bazy i wymagania użytkowników co do zgodności danych. Oracle udostępnia kilka typów odświeżania i metod inicjalizacji tego procesu:
− odświeżanie kompletne – podczas wykonywania tego rodzaju odświeżania serwer zarządzający bazą replikacyjną wywołuje zapytania definiujące poszczególne migawki.
Ich wynik zastępuje dotychczasowe dane przechowywane w obrazach. Odświeżanie
zupełne można stosować do wszystkich rodzajów migawek. W zależności od ilości
danych spełniających warunki zapytań definicyjnych, odświeżanie kompleksowe
może zabrać znacznie więcej czasu niż aktualizacja przyrostowa.
− odświeżanie przyrostowe – na początku procesu odświeżania przyrostowego są znajdowane zmiany jakie nastąpiły od ostatniej aktualizacji w danych z tabeli źródłowej.
96
Tylko te zmiany są uwzględniane w modyfikacji migawek. Odświeżanie to jest bardziej efektywne niż odświeżanie kompletne (szczególnie gdy ilość zmian w tabeli
źródłowej jest niewielka), gdyż zmniejsza obciążenie sieci komputerowych (mniejsza
ilość danych wymaga przesłania). Odświeżanie przyrostowe jest możliwe tylko wtedy, gdy tabela źródłowa posiada dziennik zmian.
Więcej informacji na temat budowy i funkcjonowania replikacyjnych mechanizmów migawek można znaleźć w dokumentacji technicznej Oracle (patrz [4]) i pracy [3].
w
4 Replikacyjny interfejs programów
da
.b
w
w
Utworzenie środowiska rozproszonego jest możliwe dzięki wykorzystaniu udostępnianego
przez Oracle replikacyjnego interfejsu programów użytkowych (API – ang. Application
Program Interface), określającego sposób odwoływania się z wnętrza programów do
SZBD. Komunikację tę umożliwia zestaw standardowych funkcji i procedur, które są składowane w bazie. Metody z systemowych pakietów DBMS_REPCAT_ADMIN, DBMS
_DEFER, DBMS_DEFER_SYS, DBMS_REPCAT, DBMS_REFRESH, DBMS_MVIEW
umożliwiają pełną konfigurację i zarządzanie bazami migawkowymi i centralowymi.
Szczegóły wywołań poszczególnych funkcji API w procesie konfiguracji baz rozproszonych Oracle Czytelnik znajdzie w pracy [2].
5 Aplikacja do zarządzania bazami rozproszonymi
pl
s.
W celu ułatwienia procesu konfiguracji i zarządzania środowiskiem rozproszonym został
stworzony program Replication Configurator, stanowiący graficzny interfejs mechanizmów
replikacyjnych. Replication Configurator został zbudowany przy użyciu Forms Builder
z pakietu iDS firmy Oracle. W programie zostało wykorzystane API replikacyjnego interfejsu programów. Aplikacja obsługuje zarówno prostą jak i zaawansowaną konfigurację
baz rozproszonych. Możliwe jest to dzięki modułowości programu. Replication Configurator stanowi zbiór kreatorów i narzędzi pomocniczych, które mogą być używane niezależnie. Dzięki wykorzystaniu tych programów użytkownik, bez znajomości funkcji API (niezbędnych przy rozproszeniu), może skonfigurować bazy centralowe i oddziałowe. Replication Configurator jest aplikacją uniwersalną i może zostać wykorzystany do konfiguracji
dowolnego środowiska rozproszonego. Jego pierwotnym przeznaczeniem miała być konfiguracja rozproszonej bazy uczelnianej, na którą składałyby się serwery wydziałowe i serwer rektoratu gromadzący dane wydziałowe. Rozwiązanie takie umożliwiałoby niezależną
pracę każdego z Wydziałów. Dodatkowo automatycznie zapewniona byłaby separacja danych, ponieważ każdy Wydział miałby dostęp tylko do swoich danych. Osiągnięcie tego samego w systemie scentralizowanym wymagało zastosowania wyrafinowanego mechanizmu
uprawnień (uprawnienia definiowane na poziomie wierszy).
6 Podsumowanie
Tworzenie współczesnych systemów informatycznych wymaga od projektantów stosowania różnych technik rozproszenia. Replikacja, fragmentacja i alokacja stanowią obecnie nieodzowne metody implementacji baz danych. Ich stosowanie jest następstwem funkcjono97
M. Włodarski
w
wania przedsiębiorstw i instytucji, które wymagają od systemów informatycznych rozczłonkowania danych przy jednoczesnym zachowaniu ich zgodności. Ważnym czynnikiem
sprzyjającym rozwojowi baz rozproszonych jest ich przezroczystość. Aplikacje klienta
ukrywają bowiem fakt stosowania mechanizmów rozproszenia w ten sposób, że końcowy
użytkownik odbiera je jako jeden scentralizowany system. Przekształcenie pojedynczych
baz na system rozproszony nie wymaga też dużych zmian w programach użytkowych.
Niekiedy nie potrzeba dokonywać żadnych zmian w kodzie źródłowym aplikacji. Wszystkie te czynniki sprawiają, że bazy rozproszone stały się niezbędnym elementem współczesnych systemów informatycznych i stanowią jedną z dominujących tendencji ich rozwoju.
w
Literatura
1.
da
.b
w
2.
3.
4.
Coulouris G., Dollimore J., Kindberg T.: Systemy rozproszone. Podstawy i projektowanie,
Warszawa. Wydawnictwa Naukowo-Techniczne 1998.
Dokumentacja techniczna. Oracle9i Replication Management API Reference, rel. 9.2.
Wrembel R., Bębel B.: Oracle. Projektowanie rozproszonych baz danych. Helion 2003.
Dokumentacja techniczna. Oracle9i Advanced Replication, rel. 9.2.
pl
s.
98

Rozdział monografii: `Bazy Danych: Struktury, Algorytmy, Metody

Transkrypt

Podobne dokumenty

Formularz - Biblioteka Gdynia

Tryb T (Tv, S) – Priorytet Migawki

MIGAWKI, Plewiński W.

FORMULARZ DO KONKURSU FOTOGRAFICZNEGO „Migawki z

Firma Sekonic

Zdalny wyzwalacz migawki aparatu, kompatybilny z iOS

Tryb Manualny - Ręczny

DIAGNOSTYKA USZKODZENIA APARATU LEICA mod... nr

Jak powstaje analogowy obraz fotograficzny?