BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











SQL Server CE – replikacja i synchronizacja danych

27-09-2004 20:04 | jedrekwie
Mechanim Remote Data Access (RDA)

Wstęp

Nie tak dawno pojawiła się pewna liczba artykułów traktujących o SQL Server CE. Szeroko prezentowano możliwości i zalety stosowania tego serwera. Wydawałoby się, że kolejna porcja informacji na temat SQL Server CE jest zbędna... Nic bardziej mylnego! Faktycznie – w do tej pory prezentowanych zastosowaniach, poza zmianą przestrzeni nazw z System.Data.SqlClient na System.Data.SqlServerCe, trudno było się dopatrzeć jakichś innych różnić pomiędzy wykorzystaniem SQL Server 2000 i SQL Server CE. Jednak prawdziwe oblicze omawianego serwera bazodanowego, odkrywa dopiero wykorzystanie mechanizmów replikacji i synchronizacji danych. Przy odpowiednim wsparciu ze strony warstw pośredniczących (o których będzie mowa dalej), możliwe jest wykorzystanie mobilnej wersji SQL Server w zakresie podobnym do stacjonarnej.

Wprowadzenie

Czym jest tak naprawdę replikacja? Replikacja jest mechanizmem umożliwiającym dystrybuowanie (często automatyczne) kopii danych z jednego serwera do pojedynczego lub wielu serwerów dostępnych lokalnie lub poprzez sieć. W wydaniu SQL Server CE, replikacja możliwa jest nie tylko przez sieć w tradycyjnym tego słowa znaczeniu. Wykorzystane mogą zostać również takie media jak: podczerwień, Bluetooth, czy zwykły przewód szeregowy... Ogólnie rzecz biorąc, można wyróżnić dwa sposoby organizacji replikacji:

  1. replikacja zarządzana na centralnym serwerze,

  2. replikacja kontrolowana po stronie klienta.

Jeśli chodzi o SQL Server 2000, to jego możliwości w zakresie replikacji są bardzo rozbudowane. Do dyspozycji administratora są replikacje typu migawkowego (ang. snapshot replication), transakcyjnego (ang. transactional replication) oraz replikacja scalana (ang. merge replication) – wszystkie wspomniane tutaj typy replikacji zaliczyć można do pierwszej kategorii organizacji replikacji. Oczywiście, zgodnie z intuicją, wersja mobilna serwera bazodanowego firmy Microsoft nie może pochwalić się aż takim bogactwem opcji. Oferuje, bowiem możliwość wykorzystania, spośród wyróżnionych powyżej, tylko (i aż!) replikacji scalanej.

Nasuwają się teraz pytania: Gdzie w tym wszystkim umiejscowić mechanizm RDA? A cóż to w ogóle takiego RDA?

RDA (ang. Remote Data Access) to również mechanizm replikacji, z tym jednak wyjątkiem, że nie kontrolowany przez centralny serwer bazodanowy. Zaliczyć więc należałoby do drugiej kategorii organizacji replikacji. Oczywiście cecha ta implikuje spore ograniczenia w porównaniu do standardowych mechanizmów replikacji. Objawiają się one głównie w:

  • braku zaawansowanych mechanizmów kontroli współdzielenia danych – RDA używa współdzielenia optymistycznego na centralnym serwerze SQL. Rekordy pobierane z bazy danych nie są blokowane i kiedy następuje odesłanie zmian na serwer, wówczas SQL Server CE Agent może nadpisać inne zmiany, które w międzyczasie zostały wprowadzone przez pozostałych klientów. Z tego powodu RDA powinno być używane w aplikacjach, w których dopuszczalna jest „utrata uaktualnień”.

  • braku możliwości przesyłania w momencie synchronizacji pull, czyli pobierania danych z centralnego serwera, wyłącznie uaktualnień, które wprowadzili inni klienci w pobranych w przeszłości rekordach. Za każdym razem istnieje konieczność przesłania wszystkich danych, które obejmuje replikacja.

Dlaczego zatem warto dokładniej przyjrzeć się mechanizmowi RDA? Przede wszystkim dlatego, że bardzo złożone mechanizmy replikacji scalanej angażują sporą ilość zasobów urządzenia mobilnego, które w każdych okolicznościach są „zasobem krytycznym”. Jeśli zatem mamy prostą strukturę bazy danych, niewielu klientów i jesteśmy w stanie pogodzić się z „utratą niektórych uaktualnień”, to RDA może okazać się najlepszym wyborem. Ponadto RDA daje programiście możliwość większej kontroli nad procesem replikacji (wiąże się to oczywiście z większą ilością wysiłku, który należy włożyć w prawidłowe oprogramowanie synchronizacji danych).

Tyle już zostało powiedziane o rożnych sposobach replikacji. W czym jednak sama replikacja może być przydatna? Kiedy należałoby ją wykorzystać? Myślę, że czytelnik w tej chwili już doskonale wyczuwa obszary zastosowań replikacji. Tak! – Replikacja znajduje swoje zastosowania w aplikacjach, które wymagają znacznie bardziej solidnych repozytoriów danych (pod względem niezawodności, możliwości technicznych, pojemności), niż te, które oferuje SQL Server CE. W takich sytuacjach mobilna wersja serwera firmy Microsoft stanowi głównie coś w rodzaju bufora, tymczasowej składnicy danych, których docelowym miejscem jest zawsze centralny serwer (bądź grupa serwerów). Zgromadzone w bazie dane mogą być przechowywane w bardzo dużych ilościach i współdzielone z innymi użytkownikami.

Wyobraźmy sobie firmę, która posiada centralną siedzibę we Wrocławiu. Jej działalność bazuje na marketingu bezpośrednim – jedyną formą pozyskania klienta jest osobisty kontakt z nim. W związku z tym, firma zatrudnia przedstawicieli handlowych, którzy obsługują klientów z całego województwa dolnośląskiego. Ci sami przedstawiciele prezentują ofertę marketingową przedsiębiorstwa, bazując na danych, które pobierają na Pocket PC przed wyjazdem służbowym (np. przez Internet lub Bluetooth). Samo pobranie danych jest niczym innym, jak replikacją! Podczas całodniowej pracy przedstawiciele gromadzą dane o zamówieniach na urządzeniach mobilnych, po to, by móc wieczorem przesłać je do centralnej bazy danych i udostępnić współpracownikom. Czy taki przykład wystarczająco przemawia do wyobraźni czytelnika...? Nie pozostaje nam więc nic innego, jak przyjrzeć się RDA z bliska.

Architektura RDA

Uwaga: Przed zapoznaniem się z dalszą częścią artykułu zaleca się, aby czytelnik zainstalował następujące składniki:

Architektura Remote Data Access oparta jest o warstwę pośredniczącą, w której skład wchodzą:

  • SQL Server CE Client Agent,

  • serwer IIS,

  • SQL Server CE Server Agent.

Lokalizacja poszczególnych składników wymienionych powyżej przedstawiono na rysunku 1.

Rysunek 1. Architektura RDA.

Klasą odpowiedzialną po stronie klienta z mechanizmy RDA jest SqlCeRemoteDataAccess. Każda operacja, związana z wymianą danych, inicjalizowana jest przez SQL Server CE Client Agent, który za pośrednictwem protokołu HTTP przesyła żądanie do SQL Server CE Server Agent, rezydującego w wirtualnym katalogu serwera IIS. Inicjowane jest wówczas jedna z trzech podstawowych operacji związanych z replikacją danych przy użyciu mechanizmu RDA. Są nimi:

  • operacja Pull – operacja, w trakcie której dane są pobierane z centralnego serwera; SQL Server CE Server Agent kontaktuje się z centralną bazą danych > pobiera stosowne dane > odsyła do urządzenia klienckiego, gdzie zostają one zapisane w tabeli, znajdującej się w lokalnej bazie danych,

  • operacja Push – operacja, w trakcie której dane są odsyłane do centralnego serwera; uaktualnienia przesyłane są za pośrednictwem HTTP do SQL Server CE Server Agent, który modyfikuje centralną bazę i zwraca błędy; rekordy, które spowodowały ewentualne błędy (np. dodanie rekordu o kluczu głównym, który już w centralnej bazie istnieje), zapisywane są wraz z informacją o błędzie w specjalnie przeznaczonej do tego calu tabeli (patrz Odsyłanie uaktualnień danych na serwer (Push) w dalszej części artykułu),

  • operacja SubmitSql – operacja bezpośredniego wykonywania poleceń SQL na zdalnym serwerze.

Jak już wspomniano, architektura RDA oparta została o mechanizmy komunikacji serwera IIS. Z faktu tego wynikają zalety związane z zachowaniem bezpieczeństwa (możliwość wykorzystania SSL i metod uwierzytelniania IIS – np. Active Directory), oraz ograniczenia dostępu do zasobów bazodanowych na podstawie adresu IP i domeny klienta.

RDA w praktyce

Dla zobrazowania sposobu użycia Remote Data Access posłużymy się przykładową aplikacją, której kod dołączony jest do treści artykułu. Jej ogólnym przeznaczeniem jest zapewnienie namiastki systemu do zarządzania urlopami pracowników. W centralnej bazie danych będziemy przechowywać dane pracowników oraz informacje o ich urlopach. Schemat bazy danych pokazuje rysunek 2.

Rysunek 2. Schemat logiczny bazy danych.

Konfiguracja mechanizmu RDA

Aby mechanizm RDA zadziałał poprawnie, spełnione muszą być następujące warunki:

  • należy stworzyć katalog wirtualny na serwerze IIS; dokonuje się tego przy użyciu narzędzia SQL Server CE Connectivity Managment i dostępnego z jego poziomu kreatora „Create a Virtual Directory”. W kolejnych krokach określamy nazwę katalogu wirtualnego, oraz sposób uwierzytelniania, jaki zostanie wykorzystany w trakcie połączenia z klientem. Do naszej dyspozycji pozostają identyczne opcje jak w przypadku konfiguracji zabezpieczeń zwykłego folderu wirtualnego; my będziemy wykorzystywać zintegrowane uwierzytelnianie Windows; nie planujemy wykorzystywać replikacji scalanej, wobec czego ostatni krok kreatora pomijamy,

  • Rysunek 3. Kreator katalogu wirtualnego SQL Server CE.

  • należy poprawnie skonfigurować urządzenie mobilne (w naszym przypadku emulator Pocket PC 2003); w tym celu należy zapewnić, by Pocket PC mógł połączyć się z serwerem IIS. Dostępność IIS’a z poziomu urządzenia mobilnego najłatwiej sprawdzić wpisując w polu adresu ciąg: http://<serwer_iis>/<wirtualny_katalog>/sscesa20.dll. Jeśli w odpowiedzi uzyskamy stronę zawierającą tekst: „SQL Server CE Server Agent”, znaczy to, że poprawnie skonfigurowaliśmy usługę RDA.

  • Uczciwie należy zaznaczyć, że prawidłowa konfiguracja usługi RDA bywa kłopotliwa. Świadczyć może o tym chociażby spora ilość grup dyskusyjnych i forów poświęconych temu zagadnieniu (w szczególności konfiguracji zabezpieczeń). W związku z tym, w razie problemów, polecam przeglądnięcie zasobów Internetu.

  • Wykorzystanie mechanizmu RDA

    „Jedyną” rzeczą, jaka nam w tej chwili pozostaje, to wprawienie w ruch maszyny replikacji i wykorzystanie jej możliwości.

    Naszym zadaniem będzie pobranie ze zdalnego serwera porcji danych, zapisanie ich w lokalnej bazie danych, a następnie zaprezentowanie ich użytkownikowi. W dalszej kolejności dane na urządzeniu mobilnym będą mogły być modyfikowane (dodawane, usuwane, edytowane), po czym odesłane na serwer centralny i tym samym udostępnione innym użytkownikom.

    Pobieranie danych ze zdalnego serwera (Pull)

    Jak już wspomniałem na początku, aby wykorzystać mechanizm RDA, należy użyć obiektu klasy SqlCeRemoteDataAccess. W momencie tworzenia tego obiektu należy podać adres katalogu wirtualnego na serwerze ISS, gdzie rezyduje SQL Server CE Server Agent, oraz wskazać ConnectionString, którego używać ma agent do komunikacji z centralną bazą danych.

    this.rda = new SqlCeRemoteDataAccess(this.URL, this.LocalConnectionString);

    W pierwszej chwili wydaje się, że to już wszystko, że wystarczy wywołać metodę Pull i korzystać z pobranych danych. Niestety, by tego dokonać należy podjąć jeszcze kilka dodatkowych czynności związanych z przygotowaniem lokalnej bazy danych do replikacji. Kolejno należy:

    1. zadbać o to, żeby plik bazy danych w ogóle istniał

    2. if(!File.Exists(this.DatabasePath)) {
      SqlCeEngine eng = new SqlCeEngine(this.LocalConnectionString);
           eng.CreateDatabase();
      }

    3. zadbać o to, żeby plik bazy danych nie zawierał tabel o nazwach identycznych z tymi, które zostaną utworzone w trakcie replikacji danych; wiąże się to z koniecznością wykonania operacji DROP TABLE dla tabel, które mają wkrótce przechowywać zareplikowane dane.

    Dopiero na tak przygotowanej bazie danych możemy przeprowadzić operację replikacji.

    this.rda.Pull("tEmployees", "EXEC spGetEmployees", this.ConnectionString,
    RdaTrackOption.TrackingOn, "tRDAEmployeesErrors");
    this.rda.Pull("tHolidays", "EXEC spGetHolidays", this.ConnectionString,
    RdaTrackOption.TrackingOn, "tRDAHolidaysErrors");

    Kolejne parametry wywołania metody Pull mają następujące znaczenie:

    1. nazwa tabeli, jaka powstanie w lokalnej bazie danych w wyniku replikacji danych,

    2. zapytanie SQL, jakie zostanie wykonane na zdalnej bazie; za pomocą tego parametru możemy manipulować, praktycznie w dowolny sposób,  ilością i strukturą pobieranych danych (można np. fragmentować dane pionowo i/lub poziomo – czyli pobierać tylko niektóre kolumny z tabel i/lub ograniczać zakres pobieranych wierszy),

    3. ConnectionString, jaki użyje agent SQL Server CE rezydujący w wirtualnym katalogu IIS, w celu komunikacji ze zdalną bazą danych,

    4. określa, czy SQL Server CE powinien śledzić zmiany dokonywane w pobranej tabeli (by w przyszłości pozwolić na wykonanie operacji Push),

    5. nazwa tabeli w lokalnej bazie danych, używanej jako pojemnik na błędy wykonania operacji Pull (nie ma znaczenia, czy tabela na błędy istnieje przed wykonaniem operacji Pull, czy nie; każda tabela na błędy może być użyta tylko raz; jeśli nastąpi próba jej ponownego użycia, wówczas zostanie zgłoszony wyjątek).

  • W trakcie pobierania danych z centralnego serwera następuje konwersja niektórych typów danych (bliższe informacje - SQL Server CE 2.0 Books Online).

Wykorzystanie lokalnie dostępnych danych

Jeśli replikacja zakończyła się sukcesem, to można praktycznie dowolnie operować na danych zgromadzonych w lokalnej bazie danych, w sposób jaki został pokazany chociażby w artykule Tomasza Popów „Baza danych na palmtopie, czyli Pocket PC i SQL Serwer CE”. W tabeli 1 zebrano ograniczenia nakładane na operacje DDL (ang. Data Definition Language – język definiowania struktur danych, który jest wykorzystywany do utrzymywania struktury bazy danych).

Tabela 1. Ograniczenie nakładane na operacje DDL.

Operacje dozwolone

Operacje niedozwolone

Usuwanie tabeli

Zmiana nazwy tabeli

Dodawanie/Usuwanie indeksów

Usuwanie kolumny klucza głównego

Dodawanie/Usuwanie wartości domyślnych

Dodawanie/Usuwanie/Zmiana nazwy kolumn

Dodawanie/Usuwanie ograniczeń związanych z kluczami obcymi

Zmiana typu danych kolumny

Odsyłanie uaktualnień danych na serwer (Push)

Przesłanie uaktualnień danych na centralny serwer możliwe jest tylko i wyłącznie w przypadku, gdy początkowa replikacja odbyła się z uwzględnieniem opcji śledzenia zmian (RdaTrackOption.TrackingOn lub TrackingOnWithIndexes), a dane, które zostały zareplikowane, pobrane zostały z możliwego do uaktualniania zestawu rekordów (tabela, możliwy do uaktualniania widok). Samego przesłania uaktualnień dokonuje się wywołując metodę Push obiektu SqlCeRemoteDataAccess w sposób, jaki pokazano poniżej

this.rda.Push("tEmployees", this.ConnectionString,
rdaBatchOption.BatchingOff);
this.rda.Push("tHolidays", this.ConnectionString,
RdaBatchOption.BatchingOff);

Kolejne parametry wywołania metody Push mają następujące znaczenie:

  1. nazwa tabeli, której zawartość zostanie odesłana do bazy danych,

  2. ConnectionString – jak w przypadku Pull,

  3. określa, w jakim trybie SQL Server CE Server Agent powinien przeprowadzać zastosowywanie uaktualnień:

  4. RdaBatchOption.BatchingOff – każdy rekord uaktualniany jest wewnątrz osobnej transakcji – błędy, które mogą wystąpić podczas scalania niektórych rekordów nie mają wpływu na pozostałe uaktualnienia,

  5. RdaBatchOption.BatchingOn – wszystkie rekordy uaktualniane są wewnątrz jednej transakcji; każdy błąd powoduje odwołanie całej operacji aktualizacji.

Oczywiście podczas operacji przesłania uaktualnień na serwer, ciągle pamiętać należy, że możliwa jest „utrata uaktualnień”, która związana jest z wykorzystywanym przez RDA optymistycznym współużytkowaniem.

Uwagi i spostrzeżenia

  1. Pomimo zdefiniowania następującej referencji pomiędzy tabelami: (tEmployees(1,1) : tHolidays(0,N); id = employee_id) i określenia kaskadowego usuwania danych, opcja ta nie była egzekwowana (stąd też „ręczne” usuwanie danych o urlopach pracownika podczas usuwania samych danych pracownika – patrz RDAHelper.DeleteEmployee())

  2. Próba zachowania właściwości IDENTITY klucza głównego zakończyła się niepowodzeniem. W trakcie wstawiania nowej wartości do bazy danych zgłaszany był wyjątek naruszenia unikalności klucza głównego (stąd też „ręczne” przygotowywanie nowej wartości klucza przed dodaniem nowego rekordu – patrz RDAHelper.AddEmployee(), RDAHelper.AddHoliday()).

Podsumowanie

Niniejszy artykuł na pewno nie wyczerpuje w stu procentach zagadnienia replikacji z wykorzystaniem mechanizmu RDA. Nie było jednak moim zamierzeniem przytaczanie całej dokumentacji dotyczącej RDA. Podobnie jak w przypadku innych zakamarków platformy .NET, ich poznanie wiąże się z koniecznością samodzielnego przebrnięcia przez dostępną dokumentację.

W następnym artykule pozwolę sobie przedstawić uzupełnienie zagadnienia replikacji o tematykę związaną z replikacją zarządzaną przez centralny serwer, czyli replikacją scalaną. Wtedy też, mając pełny obraz możliwości oferowanych przez Microsoft .NET Compact Framework, spróbujemy porównać możliwości oferowane w zakresie replikacji danych na urządzeniach mobilnych i wybrać najodpowiedniejsze rozwiązania do konkretnych zastosowań.

Dodatkowe informacje

  1. A. Wigley, S. Weelwright: Microsoft .NET Compact Framework (Core Reference), Microsoft Press, 2003

  2. D. Fox, J. Box: Building Solutions with the Microsoft .NET Compact Framework: Architecture and Best Practices for Mobile Development, Addison Wesley, 2003

  3. E. Rubin, R. Yates: Microsoft .NET Compact Framework Kick Start, Sams Publishing, 2003

  4. SQL Server CE 2.0 Books Online (http://www.microsoft.com/sql/ce/techinfo/20bol.asp)

Załączniki:

tagi: Replikacja

Komentarze 10

User 79017
User 79017
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
Świetnie i przede wszystkim zrozumiale napisany artykuł. Nareszcie ktoś pokazał do czego tak naprawdę można wykorzystać "mobilną" bazę danych. Mimo, że ma ona pewne ograniczenia, to przy umiejętnym połączeniu z pełnym SQL Serverem okazuje się potężnym narzędziem. Zwraca uwagę przejrzystość opracowania - kodu jest "w sam raz", brak także zbędnej gałkologii. Czekam na następną część!
User 79013
User 79013
171 pkt.
Junior
21-01-2010
oceń pozytywnie 0
Jeśli to początek serii, to rozumiem podejście - jesli to zamkniety artykuł, wielu danych tu brakuje - głównie dotyczących tworzenia artykułów replikacji. Wiem że temat wykracza poza podstawy, ale jest bardzo wygodną techniką wymiany danych pomiędzy SQL CE i jego stacjonarną wersją. Jako szybkie wprowadzenie, bardzo dobrym, jako przykład wykrozystania - średnio. Andrzej stać Cię na więcej, czekam na drugą część ;-)
grugar
grugar
1 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
No! W końcu to, czego szukałem od początku na CodeGuru, gdy tylko zobaczyłem pierwszy artykuł o SQL Server CE! Zawsze brakowało mi punktu spięcia PocketPC z normalnym komputerem - bo przecież w sumie samo trzymanie danych na urządzeniu przenośnym to niezbyt dobre rozwiązanie...Miejsce w pamięci się kiedyś wyczerpie, a po drugie przetwarzanie danych na urządzeniu przenośnym jest utrudnione z uwagi na jego możliwości. Ten ostatni argument wydaje sie szczegolnie wazny. Brawo. Czekam na następne artykuły.
enowak8762
enowak8762
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
Świetny artykuł, napisany bardzo zrozumiale i zawierający wszystko to czego chciałem się dowiedzieć o replikacji.Zgodnie z obietnica autora, czekam na czesc dotyczaca replikacji scalanej.
tokarski_798764
tokarski_798764
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
"Bardzo dobry artykul!W koncu ktos pomyslal, zeby powiedziec cos wiecej o SQL Serwerze CE, a nie tylko jak czytac/zapisywac dane!Nic dodac, nic ujac.A kiedy wersja dotyczaca replikacji scalanej?? :-)"
iwonarygiel8679
iwonarygiel8679
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
Taki sobie ten artykuł...
tgmaverick8907
tgmaverick8907
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
Artykuł jest trafny, żadnego lania wody. Konkretny i na temat - po prostu !! Pozdrawiam - TGMAVERICK :)
adidas3068945
adidas3068945
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
Jasno, wyraznie, na temat. Swoja droga szkoda, ze tak malo na codeguru pisze sie o .NET dla urzadzen mobilnych :-(
godlewskigo
godlewskigo
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
całkiem ciekawy. występuje jednak NADMIAR informacji. z reszta widać, że na CG to króluje... w miarę dobrze się czyta. niektóre fragmenty nieco zagmatwane...
andbed
andbed
0 pkt.
Nowicjusz
21-01-2010
oceń pozytywnie 0
Artykuł merytorycznie poprawnie wprowadza w zagadnienia RDA. Myślę, że zainspirował wielu czytelników do korzystania z SQL CE, a przynajmniej do bliższego zapoznania się z możliwościami tej technologii.
pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.