Embed Size (px)
Citation preview
Smetanova ulica 17
2000 Maribor, Slovenija
Aleš Flajšman
PRIMERJAVA ORODIJ ZA REPLIKACIJO PODATKOV MED PODATKOVNIMI BAZAMI
Diplomsko delo
Maribor, 2016
i
Smetanova ulica 17
2000 Maribor, Slovenija
Diplomsko delo univerzitetnega študijskega programa
PRIMERJAVA ORODIJ ZA REPLIKACIJO PODATKOV
MED PODATKOVNIMI BAZAMI
Študent: Aleš Flajšman
Študijski program: UN ŠP Računalništvo in informatika
Smer: Informatika
Mentor: izr. prof. dr. Boštjan Brumen, univ. dipl. inž. rač. in inf.
Lektorica: Kaja Horvat, prof. slovenskega jezika in zgodovine
Maribor, junij 2016
ii
iii
ZAHVALA
Najprej se z vsem spoštovanjem zahvaljujem mentorju, izr.
prof. dr. Boštjanu Brumnu, za razumevanje, pomoč in
usmeritve pri izdelavi diplomskega dela.
Podjetju Comtron se zahvaljujem za omogočanje testnega
okolja in Marku Budlerju za strokovno pomoč.
Posebno zahvalo si zasluži tudi moja družina, ki mi je študij
omogočila, me podpirala in verjela vame skozi vsa leta
študija.
Zahvaljujem se tudi iskrenim prijateljem, ki so mi vlivali voljo
in nudili moralno podporo. Najlepša hvala vsem!
iv
PRIMERJAVA ORODIJ ZA REPLIKACIJO PODATKOV
MED PODATKOVNIMI BAZAMI
Ključne besede: Podatkovne baze, replikacija podatkov, MS SQL, Comtron
TRONsync.
UDK: 004.633(043.2)
Povzetek: Zaradi zagotavljanja razpoložljivosti podatkov poslovnim
aplikacijam se je pojavila potreba po prenosu in osveževanju
podatkov na samo napravo odjemalca. Za prenos potrebujemo
orodje, ki zna iz strežniške podatkovne baze replicirati podatke v
klientovo podatkovno bazo in obratno.
V diplomskem delu smo predstavili in primerjali dve orodji, ki
služita temu namenu, replikacijo Microsoft SQL in replikacijsko
orodje Comtron TRONsync. Prikazani so tudi postopki
konfiguracije obeh orodij, izmerjene hitrosti prenosov in
integriteta podatkov.
Ugotovili smo, da obe orodji dobro služita svojemu namenu,
vseeno pa obstajajo določene razlike, zaradi katerih se lažje
odločimo za pravo izbiro. Če potrebujemo hitre prenose proti
odjemalcu in replikacijo med različnimi podatkovnimi bazami,
izberemo TRONsync. Uporabniku bolj prijazno in dodelano pa je
replikacijsko orodje MS SQL.
v
COMPARISON BETWEEN DATABASE REPLICATION
TOOLS
Keywords: databases, data replication, MS SQL, Comtron TRONsync.
UDK: 004.633(043.2)
Abstract: In order to ensure the availability of data to business
applications, the need for the transmission and the updating of
data directly to the customer's device has arisen. In order to
transfer data, we need a tool that is able to replicate data to the
client's database and vice versa. In this diploma thesis we have
presented and compared two tools that can be used to serve this
purpose; Microsoft SQL replication and Comtron TRONsync
replication tool. We have described the configuration processes
for both of the tools and presented the measured download
speeds and the integrity of data. It was noted that both of the
tools serve a positive purpose, however there are certain
differences that facilitate the choice between them. When one
needs fast data transmission to the subscriber and cross-
platform replication, he should choose TRONsync. MS SQL
replication tool is, however, more user-friendly and
sophisticated.
vi
KAZALO VSEBINE
1 UVOD ............................................................................................................................................. 1
2 OPREDELITEV BAZE PODATKOV IN SUPB ........................................................................................ 2
2.1 BAZA PODATKOV ................................................................................................................................... 2
2.2 SUPB ................................................................................................................................................. 7
2.2.1 Arhitektura SUPB ......................................................................................................................... 9
3 REPLIKACIJA PODATKOV IN DRUGE REŠITVE SQL- SERVERJA ZA VZDRŽEVANJE RAZPOLOŽLJIVOSTI
PODATKOV ............................................................................................................................................... 10
3.1 PREDSTAVITEV REŠITEV ZA VZDRŽEVANJE RAZPOLOŽLJIVOSTI PODATKOV ......................................................... 10
3.1.1 Strežniška grupa ........................................................................................................................ 10
3.1.2 Skupina za razpoložljivost .......................................................................................................... 11
3.1.3 Zrcaljenje podatkovne baze ....................................................................................................... 12
3.1.4 Prenos transakcijskega dnevnika ............................................................................................... 12
3.2 REPLIKACIJA PODATKOV ........................................................................................................................ 13
3.2.1 Prednosti in slabosti replikacije podatkov ................................................................................. 14
3.2.2 Uporabnost replikacije podatkov ............................................................................................... 15
4 MICROSOFT SQL SERVER ZA REPLIKACIJO PODATKOV .................................................................. 20
4.1 PRILOŽNOSTI IN PREDNOSTI UPORABE REPLIKACIJE PODATKOV MS SQL ......................................................... 20
4.2 REŠITVE IN TIPI REPLIKACIJ V MS SQL ..................................................................................................... 22
4.2.1 »Snapshot« replikacija ............................................................................................................... 25
4.2.2 Transakcijska replikacija ............................................................................................................ 26
4.2.3 »Merge« replikacija (kompozitna replikacija) ........................................................................... 27
4.3 ELEMENTI REPLIKACIJE V REŠITVI MS SQL ................................................................................................ 29
5 REPLIKACIJA PODATKOVNE BAZE COMTRON TRONSYNC ............................................................. 32
5.1 MOŽNOSTI ORODIJ IN KOMPONENTE ....................................................................................................... 32
5.2 OPIS DELOVANJA ................................................................................................................................. 34
5.2.1 Metoda posodobitve podatkov v podatkovni bazi ..................................................................... 35
5.2.2 Paketi TRONsync ........................................................................................................................ 36
5.2.3 Posodobitev podatkov naročnika .............................................................................................. 39
5.3 KONFIGURACIJA .................................................................................................................................. 40
5.4 ZAŠČITA PODATKOV ............................................................................................................................. 41
6 PRIMERJAVA REPLIKACIJ MS SQL IN TRONSYNC ........................................................................... 42
6.1 POSTAVITEV »MERGE« REPLIKACIJE MS SQL ........................................................................................... 42
6.1.1 Nameščanje SQL strežnikov in vzpostavljanje povezave ........................................................... 42
6.1.2 Nameščanje SQL-strežnikov in vzpostavljanje povezave ........................................................... 45
vii
6.2 POSTAVITEV REPLIKACIJE TRONSYNC ...................................................................................................... 49
6.3 MERJENJE HITROSTI INICIALIZACIJE PODATKOV .......................................................................................... 52
6.4 MERJENJE HITROSTI POSODOBITVE PODATKOV .......................................................................................... 53
6.4.1 Izvajanje sprememb nad podatkovno bazo publicista ............................................................... 54
6.4.2 Izvajanje sprememb na naročnikovi podatkovni bazi ................................................................ 57
6.5 INTEGRITETA PODATKOV ....................................................................................................................... 60
7 SKLEP ........................................................................................................................................... 63
8 BIBLIOGRAFIJA ............................................................................................................................. 64
viii
KAZALO SLIK
SLIKA 2.1: PRIKAZ MEDSEBOJNE ODVISNOSTI PROCESOV, BAZE PODATKOV IN ZUNANJEGA OKOLJA [3] ..................................... 3
SLIKA 2.2: ARHITEKTURA METAPODATKOVNE BAZE [2] .................................................................................................. 5
SLIKA 2.3: UPORABNIKI PODATKOVNIH BAZ ................................................................................................................. 6
SLIKA 2.4: UPORABNOST IN VEČNAMENSKOST SUPB [8] ............................................................................................... 7
SLIKA 2.5: FUNKCIJE SUPB ...................................................................................................................................... 8
SLIKA 3.1: STRUKTURA STREŽNIŠKE GRUČE [13] ......................................................................................................... 11
SLIKA 3.2: KONCEPT POŠILJANJA TRANSAKCIJSKEGA DNEVNIKA [14] ............................................................................... 13
SLIKA 3.3: PRIMERNOST IZBIRE REPLIKACIJE PODATKOV Z OZIROM NA RTO/RPO [24] ...................................................... 16
SLIKA 4.1: REPLIKACIJA ZA POTREBE IZMENJAVE PODATKOV (POSODOBITEV) MED ODDALJENIMI ENOTAMI [37] ...................... 21
SLIKA 4.2: PRIMER UPORABE REŠITVE ZA REPLIKACIJO V MSSQL [40] ............................................................................ 22
SLIKA 4.3: REŠITEV ZA IZDELAVO POROČIL V OBLIKI REPLIKACIJE PODATKOV [40] ............................................................... 23
SLIKA 4.4: TEHNIKI DODAJANJA PODATKOV [43] ........................................................................................................ 24
SLIKA 4.5: PRINCIP DELOVANJA »SNAPSHOT« REPLIKACIJE [40] .................................................................................... 26
SLIKA 4.6: PRINCIP DELOVANJA TRANSAKCIJSKE REPLIKACIJE [8] .................................................................................... 27
SLIKA 4.7: PRINCIP DELOVANJA »MERGE« REPLIKACIJE [8] ........................................................................................... 28
SLIKA 4.8: KRITERIJI ZA IZBIRO REPLIKACIJE PODATKOV [8] ............................................................................................ 29
SLIKA 4.9: ELEMENTI REPLIKACIJE V MS SQL [35] ..................................................................................................... 29
SLIKA 5.1: KOMPONENTE V REPLIKACIJI TRONSYNC .................................................................................................... 33
SLIKA 5.2: PRIMER XML-PAKETA ZA VNOS ALI POSODOBITEV PODATKOV ........................................................................ 37
SLIKA 5.3: PRIMER XML-PAKETA TIPA IZBRIS ............................................................................................................. 38
SLIKA 5.4: PRIMER VSEBINE DATOTEKE.FMT .............................................................................................................. 39
SLIKA 5.5. UKAZ ZA UVOZ PODATKOV BCP ................................................................................................................ 39
SLIKA 5.6: NASTAVITVENA DATOTEKA SPLETNEGA SERVISA TRONSYNC ........................................................................... 41
SLIKA 6.1: IZBIRA KOMPONENTE, NAMENJENE REPLIKACIJI ............................................................................................ 43
SLIKA 6.2: PRIKAZ PRIPOMOČKA SQL SERVER CONFIGUATION MANAGER ....................................................................... 44
SLIKA 6.3: NASTAVITVE VZDEVKA ZA POVEZAVO NA ODJEMALCA .................................................................................... 44
SLIKA 6.4: POVEZAVA V STREŽNIŠKO IN ODJEMALČEVO PODATKOVNO BAZO Z ORODJEM SSMS ........................................... 45
SLIKA 6.5: POT DO USTVARJANJA NOVE PUBLIKACIJE ................................................................................................... 46
SLIKA 6.6: POT DO USTVARJANJA NOVE SUBSKRIPCIJE .................................................................................................. 47
SLIKA 6.7: VSEBINA DATOTEKE RUNSYNC.BAT ............................................................................................................ 48
SLIKA 6.8: OPAZOVANJE STANJA REPLIKACIJE V REPLICATION MONITORJU ....................................................................... 48
SLIKA 6.9: HIERARHIJA SPLETNEGA STREŽNIKA............................................................................................................ 51
SLIKA 6.10: VNOS PODATKOV ZA POVEZAVO DO NAROČNIKOVE PODATKOVNE BAZE .......................................................... 51
SLIKA 6.11: OKNO ZA ZAGON SINHRONIZACIJE ........................................................................................................... 52
SLIKA 6.12: DEL POROČILA »DISK USAGE BY TOP TABLES« .......................................................................................... 53
ix
KAZALO TABEL
TABELA 6.1: REZULTATI INICIALIZACIJE NAROČNIKOVE PODATKOVNE BAZE ....................................................................... 53
TABELA 6.2: TRAJANJE PRENOSOV NA KLIENTA IZ VSEH KORAKOV ................................................................................... 56
TABELA 6.3: REZULTATI PRENOSOV NA STREŽNIK ........................................................................................................ 59
TABELA 6.4: REZULTATI MERJENJA INTEGRITETE PODATKOV .......................................................................................... 62
KAZALO SQL-UKAZOV
SPREMEMBA PODATKOV 6.1: SPREMEMBA NA VSEH ZAPISIH ........................................................................................ 54
SPREMEMBA PODATKOV 6.2: SPREMEMBA SAMO DOLOČENIH ZAPISOV .......................................................................... 54
SPREMEMBA PODATKOV 6.3: VEČKRATNA SPREMEMBA ISTIH ZAPISOV NA RAZLIČNIH POLJIH ............................................... 55
SPREMEMBA PODATKOV 6.4: VEČKRATNA SPREMEMBA ISTIH ZAPISOV NA ISTEM POLJU ..................................................... 55
SPREMEMBA PODATKOV 6.5: SPREMEMBA ENEGA POLJA ISTIH ZAPISOV .......................................................................... 55
SPREMEMBA PODATKOV 6.6: DODAJANJE ZAPISOV ..................................................................................................... 55
SPREMEMBA PODATKOV 6.7: BRISANJE ZAPISOV ........................................................................................................ 56
SPREMEMBA PODATKOV 6.8: VNOS ZAPISOV ............................................................................................................. 58
SPREMEMBA PODATKOV 6.9: SPREMEMBA ZAPISOV ................................................................................................... 58
SPREMEMBA PODATKOV 6.10: IZBRIS ZAPISOV ........................................................................................................... 59
x
Seznam uporabljenih kratic
BCP – Bulk Copy
CCD – Consistent change data
CD – Change data
DDL – Data Definition Language
DML – Data Manipulation Language
FRI – Fakulteta za računalništvo in informatiko
HPM – High Performance Module
HSM – High security Module
HTTPS – HyperText Transfer Protocol Secure
IIS – Internet Information Services
LOB – Large Object
LUN – Logical Unit Number
MS – Microsoft
NRT – Near Real-Time
PB – Podatkovna baza
POS – Point Of Sale
RM – Replication Management
RPO – Recovery Point Objective
RTO – Recovery Time Objective
SAN – Storage area network
SQL – Structured Query Language
SSD – Solid State Drive
SSL – Secure Sockets Layer
SSMS – SLQ Server Management Studio
SUPB – Sistem za upravljanje s podatkovno bazo
TCP/IP – Transmission Control Protocol/Internet Protocol
VPN – Virtual Private Network
XML – Extensible Markup Language
1
1 UVOD
Dandanes si ne moremo privoščiti, da neka mobilna ali namizna poslovna aplikacija ne bi
bila uporabna samo zato, ker nimamo povezave do spletnega ali delovnega omrežja.
Podatki, potrebni za poslovanje, morajo biti v določenih primerih dosegljivi vedno, kar
pomeni, da jih moramo shraniti na samo napravo. Ena izmed možnosti zagotavljanja
dostopnosti podatkov je replikacija.
Martin James [1] pravi, da se za replikacijo podatkov podjetja ali posamezniki odločajo
predvsem zaradi večje dostopnosti podatkov na različnih strežnikih, saj je koristna v primeru
motenj delovanja (izpadov), prav tako pa zagotavlja hiter dostop do potrebnih podatkov,
kajti večje število strežnikov prispeva pomnilnik za hitrejšo izvedbo transakcij v določenem
času.
Podatki sodobnih aplikacij so navadno shranjeni v podatkovnih bazah, zato govorimo o
orodjih za prenos podatkov med podatkovnimi bazami. Razvitih je nekaj orodij za
repliciranje podatkov. Odločili smo se, da v diplomskem delu opišemo, analiziramo in
primerjamo dve. Eno izmed rešitev ponuja Microsoft – Microsoft SQL Replication Tool je
orodje, ki omogoča več tipov repliciranja podatkov med podatkovnimi bazami MS SQL.
Drugo orodje, TRONsync, smo razvili v podjetju Comtron. Uporablja se pri prenosu
podatkov med podatkovnimi bazami v POS-sistemu, možno pa ga je uporabiti tudi v
katerem drugem okolju. Zanimivost tega orodja je, da omogoča sinhronizacijski prenos, ne
samo med MS SQL-podatkovno bazo, ampak tudi med MS SQL in SQLite PB.
Najprej smo opredelili podatkovne baze in sisteme za upravljanje s podatkovnimi bazami
(SUPB). Raziskali smo možnosti vzdrževanja dostopnosti podatkov in opisali različne
načine repliciranja le-teh. Podrobneje smo analizirali orodji SQL Replication in TRONsync.
Implementirali smo testno okolje in namestili obe orodji. Sledili so testi prenosa podatkov iz
strežnika in nanj. Na različne načine smo spreminjali podatke podatkovne baze in pri tem
merili hitrost prenosa in pravilnost podatkov.
2
2 OPREDELITEV BAZE PODATKOV IN SUPB
2.1 Baza podatkov
Baza podatkov nudi možnost zbiranja večje količine podatkov na enem mestu. To nam
omogoča, da se na bodisi podatke bodisi dokumente znotraj baz navzkrižno sklicujemo, jih
urejamo, vrednotimo oz. razvrščamo, brskamo po njih in med njimi ter iščemo niz podatkov,
ki ga potrebujemo. Craig in Buchanan [2] menita, da kvalitetna podatkovna baza sestoji iz
treh ključnih lastnosti: fleksibilnosti, logičnosti in ustreznega metodološkega pristopa
(principa).
Poleg tega izpolnjuje naslednje pogoje:
jedro oz. strukturo baze podatkov je možno kasneje spremeniti z ozirom na
drugačne zahteve;
tabele so razdeljene in umeščene smiselno, povezave med njimi pa so ustrezne in
logične glede na možnosti poizvedb;
baza podatkov zahteva minimalno obremenitev pomnilnika in prostora na mediju ter
deluje učinkovito.
Baza podatkov mora torej nuditi:
takojšen priklic informacij;
učinkovit in takojšen transfer podatkov;
precizno ter takojšnjo obdelavo želenih podatkov.
Podatkovna baza je abstrakcija »ekosistema« podjetja ali določene organizacije in ponuja
temelj za sprejemanje odločitev oz. izvršitev procesov. Mohorič meni, da s podatkovno bazo
vzpostavimo in definiramo relacijo med posameznikom (zaposlenim ali stranko) in zunanjim
okoljem (Slika 2.1) [3].
3
Slika 2.1: Prikaz medsebojne odvisnosti procesov, baze podatkov in zunanjega okolja [3]
Z vzpostavljanjem obojesmerne povezanosti med zunanjim okoljem in entiteto v obliki
bodisi posameznika bodisi celotne organizacije baza podatkov omogoča:
zapis aktivnosti iz okolja na način, ki osveži obstoječe podatke v podatkovni bazi;
subjektivno ovrednotenje podatkov v bazi zaposlenih s pomočjo njihovega znanja
in izvajanje oz. iniciiranje aktivnosti v okolju organizacije glede na lastno
razumevanje (znanje);
možnost začetka iniciacije določenega procesa s pomočjo računalniške obdelave
podatkov;
da, aktivnosti oz. procesi, ki se zaženejo, potekajo v organizacijskem ali zunanjem
okolju, zato se podatki o teh prenesejo in shranijo v podatkovni bazi;
zapis podatkov, ki so esencialnega pomena, da posameznika zgolj spodbudijo oz.
usmerijo k pravim podatkov, s katerimi lahko izvede nadaljnje akcije.
Omeniti velja tudi temeljni sektor podatkovne baze, tj. podatkovni del, ki ga običajno
razmejujeta fizična in metapodatkovna baza. Prva predstavlja hrambo podatkovnih
vrednosti, ki definirajo karakteristike objektov v formuliranem okolju, medtem ko se v meta-
podatkovnem tipu podatkovne zbirke hranijo zapisi o fizičnih podatkih – o tem, na kakšen
4
način so shranjeni, kaj predstavljajo in kako lahko uporabniki sistema do njih dostopajo,
dodaja Mohorič [3]. Tako fizični kot metapodatkovni segment podatkovne baze hranimo v
eksternem pomnilniku celotnega informacijskega sistema, oba sta zakodirana v datotekah,
v zapisu, katerega berljivost podpira izbran operacijski sistem.
Sistemi za upravljanje s podatkovnimi bazami (SUPB) dostopajo do shranjenih datotek na
osnovi nameščenega operacijskega sistema, saj le-ta omogoča uporabo SUPB na več
računalnikih ali informacijskih sistemih – ob pogoju, da je na vseh nameščen enak
operacijski sistem. Nekateri SUPB imajo možnost direktnega dostopa do hrambe podatkov
(pomnilnika), kar izniči potrebo po nameščanju operacijskega sistema, saj SUPB sam izvaja
branje in pisanje datotek, po potrebi pa disk tudi formatira. Glavna prednost takšnega
koncepta je, da neposredni dostop zniža odzivni čas SUPB in v celoti skrajša potreben čas
za izvajanje poizvedb.
Metapodatkovno bazo sestavlja trinivojska struktura, saj vsebuje tri tipe opisov podatkov iz
fizičnega segmenta podatkovne baze. Arhitekturo metapodatkovne baze tako tvorijo (Slika
2.2):
notranja shema;
konceptualna shema;
zunanja shema.
5
Slika 2.2: Arhitektura metapodatkovne baze [2]
Baloh in Vrečar [4] menita, da je hierarhično urejena arhitektura v obliki treh nivojev
ustvarjena zato, da se loči fizična hramba podatkov (notranja shema) od konceptualne
sheme, ki predstavlja oris zunanjega okolja, ter od zunanje, ki pomeni uporabo podatkov.
Fizična podatkovna zbirka oz. podatki, ki jih hrani, so lahko razvrščeni v 4-nivojsko
strukturo, ki se zunaj podatkovne baze odraža kot sklop fizičnih datotek v eksternem disku.
McDonald vidi pomen večnivojske arhitekture pri vpogledih posameznikov, ki ne zaznajo
sprememb na konceptualni ali notranji shemi, razen takrat, ko vpisujejo, moderirajo ali
brišejo trenutne vnose podatkov v bazi [5]. Uporabniki podatkovnih zbirk so vsi
posamezniki, ki imajo stik z bazo. Delimo jih na:
neposredne uporabnike (dostopajo do podatkovne zbirke preko informacijskega
sistema);
posredne uporabnike (običajno zaposleni v operativnem managementu ter
posredujejo informacije in zahteve po poizvedbi neposrednim uporabnikom, ki nato
izvedejo poizvedo ali druge spremembe v podatkovni bazi) [3].
Neposredni uporabniki, ki dostopajo do podatkovnih baz pogosto in se njihovi kriteriji za
poizvedbe precej razlikujejo, običajno uporabljajo določen povpraševalni jezik, med katerimi
je najbolj pogosto uporabljan in najbolj poznan SQL. Običajni (neposredni in posredni)
6
uporabniki morajo poznati osnove tega jezika in podatkovnih baz, medtem ko tretja skupina
uporabnikov, programerji, pišejo programe in programske vmesnike za ostali skupini
uporabnikov in jim s tem olajšajo dostop oz. uporabo podatkovnih baz (Slika 2.3).
Slika 2.3: Uporabniki podatkovnih baz
Zadnjo skupino uporabnikov predstavlja upravitelj podatkovne baze. Njegove temeljne
zadolžitve so:
opredelitev ter osvežitev notranjega, zunanjega in konceptualnega nivoja;
ustvarjanje in zagon fizične podatkovne zbirke;
spodbujanje razvoja in posodobitev programske opreme, ki omogoča delo
neposrednim uporabnikom in programerjem;
urejanje varnostnih pogojev v primeru nezgod in obnovitev podatkovnih baz po
nezgodah;
opredelitev procesa za zagotavljanje kvalitete podatkovne zbirke;
upravljanje z gesli in dovoljenji, ki jih dodeljuje uporabnikom;
kontroliranje dostopa do podatkovne baze in njene zmogljivosti ter modifikacije;
pomoč uporabnikom pri koriščenju programskega orodja, ki je v paketu SUPB [6].
7
2.2 SUPB
SUPB predstavlja programsko okolje, ki s pomočjo ustreznega »uporabniškega vmesnika«
običajnim uporabnikom omogoča dostop do okolja, ki nudi hrambo podatkov, potrebnih za
poizvedovalca [7]. Opredelitev FRI Univerze v Ljubljani je naslednja: »S SUPB razumemo
programski sistem, ki omogoča učinkovito, uporabnikom prijazno in zaščiteno
večuporabniško okolje, ki nudi shranjevanje, dostop in vzdrževanje večjih količin
medsebojno povezanih podatkov, shranjenih na trajnem pomnilniku. SUPB odlikuje dejstvo,
da je to programska oprema, ki je nepovezana z aplikacijami in na osnovi katere je
implementiran podatkovni model.« Slika 2.4 prikazuje, na katerih področjih je SUPB
uporabna.
Slika 2.4: Uporabnost in večnamenskost SUPB [8]
SUPB načeloma sestoji iz več različnih programskih orodij, s katerimi lahko v podatkovni
zbirki izvajamo naslednje akcije (Slika 2.5):
poizvedbo po podatkih;
izbris podatkov;
shranjevanje novih vnosov podatkov;
ustvarjanje nove podatkovne baze ali tabele;
modifikacijo obstoječih vnosov;
dodeljevanje dovoljenj, oz. upravljanje dostopa uporabnikov.
8
Slika 2.5: Funkcije SUPB
Ustvarjanje podatkovnih struktur, kakršni sta tabela in baza, omogoča modul DML (Data
Manipulation Language), medtem ko so spremembe, posodobitve in upravljanje z
dostopom mogoče zaradi modula DDL (Data Definition Language). Statistika pravi, da je
podatkovna baza v skoraj 70 % primerov identična za vse njene uporabnike, zato je
natančna opredelitev dovoljenj in dostopa esencialnega pomena za njeno upravljanje [9].
Baloh in Vrečar [4] dodajata, da mora del SUPB predstavljati tudi varnostni mehanizem, ki
nepooblaščenim uporabnikom onemogoča vnos, izbris ali spremembo vnesenih podatkov.
SUPB lahko vodimo preko povpraševalnega jezika SQL. Mrhar [10] k temu dodaja, da
lahko za izboljšano uporabniško izkušnjo uporabljamo grafične vmesnike.
9
2.2.1 Arhitektura SUPB
Z arhitekturo lahko prikažemo strukturo SUPB, pri čemer je potrebno opozoriti, da se le-ta
razlikuje glede na avtorja konstrukta. Werber [11] omenja naslednje logične enote SUPB:
zunanji vmesnik (orodje, ki omogoča dvosmerno izmenjavo informacij s SUPB, tako
da se lahko izvedejo vse potrebne aktivnosti na podatkovni bazi – opredelitev
podatkovnih tipov, raven varnosti ali pa aktivnosti za upravljanje SUPB –
vzpostavitev podatkovne zbirke po nezgodah, »backup« podatkov itd.);
jezikovni procesi podatkovnih zbirk (osrednji del podatkovne baze, saj se večina
procesov izvede z izrazi v povpraševalnih jezikih (kot je SQL), obenem pa premosti
nerazumevanje med izrazi uporabnika in izrazi, potrebnimi za izvedbo operacij
preko SUPB);
optimizator povpraševanj (orodje, namenjeno racionalni izvedbi povpraševanja, kar
pomeni, da pri uporabnikovi poizvedbi izvede najugodnejši niz operacij, potreben za
določeno aktivnost);
pogon podatkovne baze (mesto, kjer se izvedejo potrebne aktivnosti izpod ukazov
podatkovne zbirke);
skladiščni pogon (služi za prevod aktivnosti na operativni nivo v t. i. bite);
transakcijski pogon (zagotavlja preciznost in zanesljivost izvedenih aktivnosti znotraj
SUPB, tako da operacije grupira v t. i. transakcije);
upravljavska konzola SUPB in operativna izvedba (vključuje številne elemente in
orodja, ki skupaj omogočajo upravljanje SUPB, zaščitno, »backup«, nadzor
podatkov in dodeljevanje dostopa ustreznim uporabnikom).
10
3 REPLIKACIJA PODATKOV IN DRUGE REŠITVE SQL- SERVERJA ZA VZDRŽEVANJE RAZPOLOŽLJIVOSTI PODATKOV
Poleg replikacije podatkov, ki jo natančneje predstavljamo v nadaljevanju poglavja,
obstajajo še vsaj štirje dobro poznani principi vzdrževanje razpoložljivosti podatkov oz.
podatkovnih zbirk – vse omogoča Microsoftova platforma SQL Server. Po krajši predstavitvi
principov vzdrževanja razpoložljivosti podatkov oz. podatkovnih zbirk se bomo osredotočili
na replikacijo podatkov, ki je osrednja tema diplomskega dela. Rešitve za vzdrževanje
razpoložljivosti podatkov se lahko delijo glede na stopnjo in način delovanja [12].
Glede na prvi kriterij ločimo rešitve, ki delujejo na nivoje celotnega koncepta (instance) SQL,
in rešitve, ki so na stopnji individualne podatkovne baze. Pri slednjem načinu delovanja bo
rešitev za vzdrževanje razpoložljivosti podatkov razpolagala samo s podatki, ki so v dani
podatkovni zbirki. Glede na način funkcioniranja pa lahko rešitve za zagotavljanje oz.
vzdrževanje visoke razpoložljivosti podatkovnih zbirk oz. podatkov razdelimo na rešitve na
osnovi deljenja podatkovnih baz med strežniki in rešitve, ki replicirajo podatkovne baze med
strežniki.
3.1 Predstavitev rešitev za vzdrževanje razpoložljivosti podatkov
3.1.1 Strežniška grupa
Goswami [13] opredeljuje strežniško gručo kot sklop neodvisnih strežnikov, ki komunicirajo
na osnovi mrežne opreme in programskega orodja, ki omogoča zagotavljanje
razpoložljivosti funkcij, integriranih v strežniško gručo. Sklop strežnikov v gruči omogoča
zagotavljanje instance SQL-serverja, ta storitev oz. funkcija pa je s strani strežnikov prav
tako stalno kontrolirana. V kolikor je njeno delovanje moteno (nezgoda oz. motnje
delovanja), se funkcija strežniške gruče ponovno vzpostavi samodejno, ali pa se njeno
delovanje nadaljuje na sosednjem strežniku v gruči.
Schmidt [12] dodaja, da je pogoj za vzpostavitev delovanja SQL-strežniške gruče tudi
ustrezno diskovno polje, ki mora biti omrežno (SAN). Pri tej vrsti diskovnega polja
razpolagamo z več logičnimi diskovnimi enotami (LUN), ki predstavljajo mrežo več
povezanih trdih diskov. Strežnik LUN zazna kot en fizični disk, na katerem so zbrani podatki
iz podatkovne baze. Minimalni pogoj za obstoj strežniške gruče je en računalnik, čeprav je
zaželeno, da jo sestavljata najmanj dva strežnika (Slika 3.1), s čimer zagotovimo zadostno
11
mero zanesljivosti delovanja strežniške gruče. Strežniško gručo odlikujeta robustnost in
visoka stopnja učinkovitosti delovanja, medtem ko je čas izpadov bodisi zaradi vzdrževanja
bodisi zaradi motenj delovanja minimalen. Strežniška gruča deluje samostojno in
avtomatizirano, zato je vsakršno delo s to rešitvijo precej poenostavljeno, vendar je toliko
bolj zahtevna implementacija rešitve in zagotavljanje omrežnega diskovnega polja. Slabost
le-tega je tudi slabše varovanje podatkov pred izpadom delovanja ter neželenim izbrisom
ali vnosom podatkov.
Slika 3.1: Struktura strežniške gruče [13]
3.1.2 Skupina za razpoložljivost
Skupina za razpoložljivost izhaja iz strežniške gruče, ki omogoča vodenje in dostop do vseh
serverjev, vključenih v skupino za razpoložljivost. Le-ta predstavlja nadgradnjo zrcaljenja
podatkovnih zbirk, do nje pa dostopa t. i. poslušalec, ki je računalniški element s svojo
domeno, shranjen v hitrem pomnilniku celotnega sistema. Poslušalec zapisuje dogodke na
posebnem strežniku in s tem drugim, ki dostopajo, omogoča pristop k primarni repliki. Poleg
primarne obstaja še sekundarna replika, obe pa lahko zamenjata vlogo pri preklopu med
replikama, kar se zabeleži v poseben domenski server [14].
Skupino za razpoložljivost tvori 5 medsebojno povezanih replik, pri čemer je ena primarna,
ostale pa hierarhične, sekundarne, namenjene zgolj hrambi varnostne kopije podatkov in
zagotavljanju dostopa za potrebe branja in prepisovanja. Ena replika je en strežnik, ki lahko
12
gosti eno ali več instanc SQL-serverja. Instanca nudi podporo za eno ali več skupin
razpoložljivosti, slednje pa ponujajo prostor več podatkovnim bazam. Baze podatkov se
hranijo na fizičnem trdem disku strežnika, zato pri tem konceptu ni potrebno omrežno
diskovno polje (SAN), kot je bilo to pri strežniški gruči. Za razliko od strežniške gruče deluje
skupina za razpoložljivost izključno na stopnji podatkovne baze, vendar je teh lahko več in
skupaj tvorijo sklop podatkovnih zbirk.
3.1.3 Zrcaljenje podatkovne baze
Zrcaljenje podatkovne zbirke omogoča zagotavljanje dveh kopij baz podatkov na dveh
ločenih strežnikih. Primarna, produkcijska kopija je aktivna in se nahaja na glavnem
strežniku, medtem ko se zrcalna kopija hrani na zrcalnem strežniku. Vnos, izbris in
spremembe podatkov v bazi podatkov na glavnem strežniku se preslikajo na kopijo zbirke
v zrcalnem strežniku. Tudi zrcaljenje podatkovne zbirke deluje na nivoju ene baze, a za
nemoteno delovanje potrebuje vsaj dva strežnika z instanco SQL [15].
Zaželen je kontrolni (upravljavski) strežnik, ki vsebuje aktivno instanco SQL. Čas uporabe
kontrolnega strežnika je odvisen od nastavitev in funkcionalnosti zrcaljenja podatkovnih
zbirk. Dostop do glavnega in zrcalnega strežnika je zagotovljen s pomočjo povezovalnega
sklopa, v katerega uporabnik zabeleži glavni in zrcalni strežnik ter si tako zagotovi dostop
v primeru nedelovanja enega ali drugega. Zrcaljenje podatkovnih zbirk lahko deluje na:
način visoke varnosti (HSM);
način visoke zmogljivosti (HPM).
3.1.4 Prenos transakcijskega dnevnika
Sack in Mishra [16] definirata prenos transakcijskega dnevnika kot koncept, ki deluje na
stopnji baze podatkov in omogoča avtomatizirano podvajanje transakcijskega dnevnika za
potrebe varnosti in zavarovanja pred motnjami delovanja. Prenos transakcijskega dnevnika
oz. ustvarjanje varnostnih kopij zahteva samostojno vodenje vsake baze podatkov in deluje
ob najmanj dveh strežnikih, med katerima mora biti mrežna povezava, namenjena prenosu
podatkov, ključnih za zagotavljanje prenosa transakcijskega dnevnika.
V rešitev prenosa transakcijskega dnevnika je možno vključiti še en strežnik, ki je namenjen
kontroli in upravljanju drugih strežnikov v sklopu rešitve prenos transakcijskega dnevnika.
Temu nadzornemu strežniku lahko ostali strežniki integrirani v rešitev pošiljajo zapis
delovanja in osnovo za ustvarjanje varnostnih kopij. Najbolj pogosta je rešitev (Slika 3.2),
13
ki koncipira prenos transakcijskega dnevnika na osnovi dveh sekundarnih replik, kontrolnim
strežnikom in opcijskim strežnikom za hrambo varnostnih kopij podatkov. Nastavimo lahko
omejen bralni dostop za uporabnike sekundarne replike baze podatkov, zakasnitev pri
prenosu podatkov pa nam daje možnost, da na primarni bazi podatkov odpravimo
morebitne nevšečnosti. Prenos transakcijskega dnevnika je sicer ugodna rešitev za
vzdrževanje razpoložljivosti podatkov, vendar ne ponuja avtomatskega prestopa na
sekundarni strežnik, če pride do motenj delovanj zaradi dostopnih dovoljenj.
Slika 3.2: Koncept pošiljanja transakcijskega dnevnika [14]
3.2 Replikacija podatkov
Replikacija označuje dve aktivnosti, povezani s podatkovnimi elementi, kopiranje ter
zagotavljanje vnosov, tabel in drugih povezav med zbirkami podatkov, ki konstruirajo
informacijski sistem. Martin James [1] dodaja, da se podjetja ali posamezniki odločajo za
replikacijo podatkov predvsem zaradi večje dostopnosti podatkov na različnih strežnikih, saj
je koristna v primeru motenj delovanja (izpadov), prav tako pa zagotavlja hiter dostop do
potrebnih podatkov, saj večje število strežnikov prispeva pomnilnik za hitrejšo izvedbo
transakcij v določenem času.
Podatkovne zbirke, ki jih repliciramo, so običajno shranjene na oddaljenih in nepovezanih
računalniških sistemih, kajti replikacija je v osnovi namenjena zagotavljanju potrebnih
podatkov na različnih lokacijah. Replikacija je proces, v katerem pride do kopiranja izbranih
14
vnosov podatkov iz mesta izvora na ciljno mesto, pri tem pa se izvede sinhronizacija med
obema lokacijama. Čeprav sta običajno ločena, je teoretično možno, da se izvorno in ciljno
mesto nahajata na istem sistemu [17].
Replikacijo lahko razumemo kot proces kopiranja in ohranjanja elementov baze v več
zbirkah podatkov. Spremembe se izvedejo na izvornem mestu, kopirajo, začasno shranijo
lokalno in nato prenesejo na dislocirano mesto (ciljno mesto). Poleg tega, da replikacija
odjemalcem ponuja možnost hitrega dostopa do podatkov, koristi tudi aplikacijam, tako da
jim poveča dostopnost zaradi večjega števila virov podatkov [18]. Replikacija z ustvarjanjem
omrežnega segmenta (več dostopnih mest do podatkov) omogoča hitrejši dostop do
podatkov na račun možnosti opravljanja večjega števila transakcij. V te omrežne segmente
je možno dodati strežnik, tako da lahko izvajamo replikacijo podatkov med dislociranimi
enotami in zadostimo potrebam večjega števila odjemalcev. S takšnim povezovanjem
zmanjšamo potrebno število strežnikov in uredimo dostop do baz podatkov, medtem ko
replikacija omogoča enotnost podatkov v vseh podatkovnih zbirkah na ločenih sistemih.
3.2.1 Prednosti in slabosti replikacije podatkov
Ustrezno implementiran proces replikacije podatkov lahko v organizacijah in njihovem
poslovanju omogoča naslednje prednosti:
hiter in zanesljiv dostop do podatkov (replikacija mora biti celovita, natančna in mora
onemogočati napake med procesi v poslovanju);
trajen in kontinuiran prenos podatkov (ob tem je potrebno zagotoviti varnost in
ustrezen dostop uporabnikom);
izboljšane zmogljivosti informacijskih sistemov (replikacija lahko bolje izkoristi
možnosti distribucijske mreže, ne sme ovirati vira podatkov, temveč mora ponujati
rešitve za optimizacijo pri dostopu do podatkov);
poenostavljeno centralizirano upravljanje (pri tem mora biti upravljavec usposobljen
skrbeti za vse dislocirane komponente iz enega strežniškega mesta);
heterogeni pristop k zagotavljanju informacij (replikacija podatkov je lahko izvedena
tako, da prenaša podatke skozi različne aplikacije več proizvajalcev);
samostojno delovanje dislociranih enot (vsako mesto, ki prejema podatke od
replikacije, lahko poljubno izbira, katere podatke želi prejemati, kako naj se
prikazujejo in na kakšen način bodo do njih dostopalo oz. jih spreminjalo) [19].
Rankins in drugi [20] menijo, da je ključna odlika replikacije dostopnost do podatkov, v
kolikor neha delovati eden od strežnikov. Odjemalci so nemudoma in enostavno
15
preusmerjeni k drugemu (običajno najbližjemu) strežniku, zato izpada ali motenj delovanja
sploh ne zaznajo. Vse, kar se lahko zgodi v primeru motenj delovanja, je zgolj podaljšan
dostopni čas. Avtorji pravijo, da je ogromna prednost pri uporabi replikacije podatkov
lokalna dosegljivost podatkov, saj se čas dostopa tako občutno zreducira. Odjemalci
dostopajo do repliciranih baz na samostojnih enotah, zaradi česar je tudi celotno omrežje
manj obremenjeno, kar pohitri in izboljša delovanje drugih aplikacij.
Prav očitnih slabost replikacija podatkov nima, vendar obstajajo določene situacije, v katerih
morda ne želimo posegati po tem konceptu. V nadaljevanju navajamo nekaj situacij, v
katerih replikacija ni najbolj primerno orodje:
replikacija prinese številne spremembe, tako na programski kot tudi strojni opremi,
nekatere aplikacije pa niso prirejene za delovanje s spreminjanjem zapisov, ampak
samo vnašanjem novih, kar lahko privede do konfliktov;
izziv je zagotavljati trajen in kontinuiran prenos podatkov, saj aplikacije, ki so
povezane z realnimi časovnimi podatki (vrednost delnic, rezervacije kart, sledljivost
pisemskim pošiljkam itd.), razpolagajo s podatki, ki se lahko izgubijo med
sinhronizacijo po replikaciji;
spremembe na podatkih se morajo nemudoma prenesti do vseh odjemalcev, kar
nekatere aplikacije, ki zahtevajo nenehne posodobitve, težko dosegajo;
odjemalci ne smejo preveč obremeniti SUPB zaradi lastnosti primarne baze in
repliciranih baz ter nezadostnega pomnilnika, ki je na voljo določenim uporabnikom;
koristnost replikacije omejuje tudi podvajanje podatkov samo po sebi, saj morajo
vse replicirane zbirke podatkov vsebovati vse podatke, ki jih lahko najdemo v
katerikoli izmed repliciranih podatkovnih baz;
pomanjkljivost lahko predstavlja zahtevno skrbništvo in izmenjava podatkov
(sporočil) med bazami podatkov, ki smo jih replicirali [21].
3.2.2 Uporabnost replikacije podatkov
Replikacija je avtonomni koncept, ki je povezan v arhitekturo SUPB (v njej prednjačijo MS
SQL Server, DB2, Oracle itd). Če izvedemo osnovno namestitev programskega okolja (npr.
MS SQL Server), orodje replikacije ne bo aktivno, saj njegova uporaba ni pogosta, vendar
je narejen tako, da se ob iniciaciji replikacije avtomatsko zažene. Čeprav replikacija ne
predstavlja velike potrebe po virih pomnilnika in operacijskega sistema, je le-tega vseeno
priporočljivo nadzirati, da ne bi prišlo do motenj delovanja.
16
Replikacija temelji na fizičnem podatkovnem modelu, ki ga integriramo v celotno
podatkovno zbirko. V praksi to predstavlja kreiranje pripadajočih objektov, kot so tabele in
baze, ostalih indeksov in dodatnega tabelaričnega prostora. Ko imamo to urejeno, se lahko
začne ustvarjanje opredelitev in pogojev replikacije, ki bazirajo na vnosih v tabelah. Tako
izvorno mesto replikacije kot tudi ciljno mesto (sistem) imata svoj zapisnik, ki predstavlja
zbirko tabel z vsemi informacijami o repliciranih podatkih. Iz Database Replication [22] lahko
razberemo, da lahko posamezni strežnik v mreži samodejno in samostojno replicira
elemente na osnovi pridobljenih informacij iz tega zapisnika.
Replikacija podatkov zaradi svojih prednosti prednjači pred ostalimi metodami vzdrževanja
razpoložljivosti podatkov, saj v ospredje postavlja aplikacije, visoko zmogljivost in hiter ter
stalen dostop po podatkov. Yair in Ciprian [23] dodajata, da je potrebno zagotoviti
konsistenco med vsemi repliciranimi bazami, kar je običajno največji izziv replikacije. Ko
razmišljamo o replikaciji in drugih metodah zagotavljanja visoke razpoložljivosti podatkov,
moramo določiti kazalnika RPO (Recovery Point Objective) in RTO (Recovery Time
Objective). RPO predstavlja parameter, ki meri starost posodobljenih ali obnovljenih
podatkov, medtem ko RTO pomeni čas, ki je na razpolago za obnovitev podatkov po
nezgodi oz. motnji delovanja. Na podlagi teh dveh parametrov premislimo, kakšen koncept
je za nas najbolj zaželen (Slika 3.3).
Slika 3.3: Primernost izbire replikacije podatkov z ozirom na RTO/RPO [24]
17
O replikaciji kot rešitvi za vzdrževanje razpoložljivosti podatkov je smiselno premisliti tudi,
ko imamo precej razvejano mrežo, saj tako težje dostopamo do želenih podatkov [25]. V
takšnih primerih lahko zagotovimo nemoteno delovanje zgolj, če prenesemo določene
podatke lokalno do odjemalcev. Replikacija odjemalcem poveča dostopne čase v primerih,
ko so aplikacije narejene za večje število uporabnikov.
Zaradi repliciranih podatkov in podatkovne zbirke omogočimo delo več odjemalcem na
dislociranih mestih – čeprav so replicirane baze medsebojno oddaljene, omogočajo
medsebojno sinhronizacijo v doglednem času. Ob večanju mreže in dislociranih mest
repliciranih baz je potrebno imeti v mislih usklajenost replikacije s celotnim programskim
okoljem. Večje, tj. sistemske spremembe v okolju, bi lahko rezultirale v nekompatibilnost z
repliciranimi bazami in povzročile motnje v delovanju. Ko pride do sprememb samih v
podatkovni bazi, se beleži zapisnik, preko katerega se nato izvede zapis v tabele (faza
zajemanja), ki mu sledi faza dodajanja – ta preveri vnose in izvede spremembe na ciljnem
mestu tako, da je zagotovljena konsistenca [26].
Največ nevšečnosti pri replikaciji lahko povzroči prekinitev mrežnih povezav ali elementov,
zaradi česar se pri replikaciji običajno poslužujemo bolj zmogljive tehnike hrambe in
prenosa podatkov. Podatki se prenašajo kadarkoli so lokalno oddaljene enote aktivne in
dostopne. Če je dislocirana enota nedosegljiva, se spremembe in podatki shranijo, dokler
ni povezava ponovno vzpostavljena – procesu se reče avtomatična sinhronizacija. Ostale
enote in aplikacije lahko med nedelovanjem enega ali več sistemov še naprej opravljajo
operacije s pridobljenimi podatki [19].
Oviro pri replikaciji lahko predstavlja tudi t. i. propagacija, ki povzroči zakasnjen prenos
podatkov in s tem zakasnitev. Prav tako moramo biti pozorni na to, da ne prepletamo
recipročnih tabel s potekom replikacije podatkov, saj le-te predstavljajo elemente v SUBP,
poleg tega lahko motijo zmogljivosti namenskih programov za strojno opremo, ki ne beležijo
zapisov. Nekaj časa po opravljenem prenosu se izvede propagacija (generiranje
sprememb), za katero se lahko uporabijo različne metode izvedbe.
Daudjee in Salem [27] analogno z logističnimi metodami navajata princip FIFO, kar pomeni,
da sprememba, ki se izvede prva, pride na vrsto prva – tako proces kar se da poenostavimo
in ga naredimo robustnega. Metodologija FIFO pri transkripciji podatkov omogoča izvedbo
novih vnosov, modifikacije in morebitno brisanje brez uporabe zajemanja. Če bi prišlo do
motenj delovanja, bi se proces nadaljeval nemoteno, le posamezni vnosi bi postali
nedosegljivi.
Večina proizvajalcev storitev SUBP že ponuja lastne rešitve za replikacijo, proizvajajo pa
jih tudi tisti, ki se ne ukvarjajo s SUPB. Pomembno je, da je implementacija rešitev za
18
replikacijo izvedena strokovno in resno ter zajema vse potrebne elemente. Enostavne
konfiguracije s prilagodljivim uporabniškim vmesnikom so sicer priročne, vendar ne
ponujajo vseh rešitev in ne bodo zadovoljile vseh potreb podjetja. Pri implementaciji rešitve
za replikacijo je potrebno upoštevati tudi celotno podobo oz. delovanje SUPB, saj so
interakcije med obema neizbežne [28].
Zavedati se moramo, zakaj smo vzpostavili SUPB in za kaj ga uporabljamo. Thompson [29]
pravi, da moramo temu prilagoditi tabele mrežnih povezav, ki so vzpostavljene med
ločenimi zbirkami podatkov, opredeliti potrebne podatke in določiti tip replikacije.
Zahtevnejše opravilo je spreminjanje podatkovnega okvirja, torej tabel in primarnih ter
referenčnih ključev, saj ob vsakršni modifikaciji porušimo trenutno strukturo in vzpostavimo
novo podobo. Če je tabela na izvornem mestu obsežna, lahko replikacija podatkov traja tudi
nekaj ur, dokler se ne prenese po celotni mreži [30].
Ko generiramo spremembe, lahko pride do procesnih napak zaradi napačnih opredelitev
(kot rezultat nedoslednosti) ali zmote v generatorju, pojavijo pa se lahko tudi ostale napake
med delovanjem. V takšnih situacijah se je najbolje vrniti na začetno mesto, kar pa pomeni,
da moramo shraniti prvotno strukturo, opredelitve, podatke, elemente itd. V kolikor je naš
cilj povečevanje zmogljivosti sistema na račun replikacije, je smiselno premisliti, kakšna bo
zasnova baze. Pri tem velja upoštevati vsaj dva kriterija:
vstavljati in posredovati (sinhronizirati) je potrebno samo potrebne podatke, saj je
drugače oteženo tako vertikalno kot horizontalno filtriranje, obenem pa imamo
preveč podatkov, ki otežujejo delovanje sistema;
optimizacija števila indeksov (več kot jih imamo, dlje časa bo trajala replikacija, saj
mora biti vsak nov zapis označen s svojim indeksom). Prav tako se na ciljnem mestu
izvaja vnos podatkov ne le v tabelo, ampak tudi v svoj ustrezni indeks [31].
Johnston [32] pravi, da je distribucija aplikacij znotraj mreže zahtevnejše opravilo, saj ima
vsaka svoje specifične zahteve, ki jih je potrebno upoštevati. Pozornost je potrebno
posvečati prenosu podatkov znotraj mreže, saj lahko hitro preobremenimo celotno omrežje.
Nesmiselno je prenašati celotne baze naenkrat, zato podatke iz baz razdelimo v paketke,
ki jih lažje distribuiramo. Slednje zahteva dodatno tehnologijo, ki omogoča razčlembo
podatkov, tako da ostanejo enaki in sinhronizirani na vseh mestih.
Replikacijski sklop lahko torej zajema eno celotno bazo ali različno število repliciranih
paketkov podatkov, vendar lahko do sprememb prihaja le na primarni bazi (med prenosom).
Dove [33] dodaja, da se polja z večjimi elementi (LOB) običajno zaradi svoje velikosti ne
pošiljajo, sinhronizacija pa poteka le takrat, ko je na njih izvedena sprememba. Avtor v
nadaljevanju navaja, da moramo biti pazljivi na:
19
primarni ključ, saj je vnos lahko z njim blokiran, če hočemo podvajati vnose z enakim
enovitim ključem;
koherentnost tabel, saj se lahko zgodi, da nov vnos poseduje vrednost, ki ni
ustrezna opredelitvi polja;
zaklepanje, ki lahko onemogoči sinhronizacijo podatkov v primerih, ko drug
uporabnik zaščiti tabelo – ne glede na to se sinhronizacija izvaja toliko časa, dokler
se ne sprosti tabela za uporabo.
Pozornost je potrebno posvetiti tudi kontrolnim tabelam replikacije. Večino časa običajno
posvetimo izvornim in ciljnim tabelam, medtem pa pozabljamo na vmesne (kontrolne)
tabele, ki nastanejo pri replikaciji. Le-te delujejo znotraj podatkovne baze enako kot
navadne tabele, z več vnosi in brisanjem nepotrebnih podatkov, a za povečanje zmogljivosti
(zajemanje in dodajanje podatkov) in obnovo po motnjah delovanja potrebujejo ustrezne
varnostne kopije in vodeno statistiko [34].
20
4 MICROSOFT SQL SERVER ZA REPLIKACIJO PODATKOV
Replikacija v SQL Serverju je namenjena reprodukciji in kopiranju podatkov; uporabnik jo
lahko uporablja kadarkoli, ko potrebuje (varnostno) kopijo svojih podatkov. Le-ta lahko
ostane shranjena v isti bazi kot izvorni podatki, lahko je v drugi bazi, a na istem mestu, ali
pa je na povsem drugi instanci (serverju) in bazi (Fundamentals, 2012) [35]. Replikacija je
uveljavljen koncept kopiranja podatkov, vendar rešitev znotraj SQL Serverja ponuja precej
več kot zgolj reprodukcijo podatkov. Microsoft SQL Server omogoča nastavitev replikacije
tako, da stalno sinhronizira izvorno mesto podatkov s kopiranimi podatki v drugi bazi oz. na
drugem mestu. Dodatno je možna tudi nastavitev sinhroniziranja v poljubnih časovnih
intervalih. Poleg tega replikacija v SQL Serverju omogoča enosmerno ali obojestransko
sinhronizacijo in ohranjanje sklopa podatkov, ki se sicer izgubijo pri posodobitvah [35].
4.1 Priložnosti in prednosti uporabe replikacije podatkov MS SQL
Replikacija podatkov je uporabna v kar nekaj primerih; uporabimo jo lahko, ko želimo
kopirati podatke na drugo napravo za trenutne potrebe poročanja (podatkovna analitika),
ali za to, da uporabimo aplikacijo za analize (npr. Analysis Services Cube). Možnost
nastavitve sinhronizacije v različnih časovnih intervalih omogoča izvedbo replikacije ponoči,
tj. po končanem delovnem dnevu, kar nam zagotovi sliko celotnega delovnega dogajanja.
Aplikacije tako ni potrebno dodatno programirati, da bi razumela »nedokončana« opravila,
ki se sicer pojavljajo pri rešitvah za replikacijo, ki kontinuirano izvaja sinhronizacijo.
Koristna je tudi možnost uporabe transakcijske replikacije (ang. »transactional replication«),
ki omogoča prenos podatkov v skoraj realnem času za potrebe poročil podatkovne analitike.
Čeprav v SQL Serverju le-ta ne poteka sinhronizirano, je zamik minimalen, kar omogoča
skoraj realno časovno pripravo poročil in vpogled v izvorne podatke na mestu kopiranja
[35].
Replikacija je prav tako koristna za prodajne agente, ki delujejo na terenu. S sabo namreč
tovorijo svoje računalnike, na katerih imajo pomembne podatke, ki jih večkrat dnevno
posodobijo, podatke pa morajo nato prenesti v centralno bazo podjetja. Ker svoje
računalnike in podatke med bazami posodabljajo diskretno, na več različnih lokacijah, lahko
hitro pride do konfliktov pri prenosu podatkov. Prav za potrebe tega dela je Microsoft
dopolnil SQL Server Replication Database s komponirano replikacijo (ang. »merge
21
replication«), ki predstavlja rešitev v teh primerih in je poleg »snapshot« replikacije (ang.
»snapshot replication«) dodatna možnost programske rešitve Sql Server.
Hordila [36] ugotavlja, da se – kljub dostopnosti napredne replikacije že dlje časa in njeni
razširjeni uporabi – osnovna replikacija (posodobitev določene tabele v enem kliku) še
vedno pogosteje uporablja v večini nameščenih rešitev. Žal se pri omejenem delovanju
(enostavni rešitvi) podatki prenašajo zgolj v eno smer, predvsem za potrebe prenosa
podatkov v centralno skladišče (Slika 4.1), v razpoložljive spletne zbirke idr.
Slika 4.1: Replikacija za potrebe izmenjave podatkov (posodobitev) med oddaljenimi
enotami [37]
Ray [38] razlaga, kateri kriterij upoštevati pri izbiri rešitve replikacije, tako da bo ta ponudila
največ prednosti za organizacijo oz. odjemalce. Meni, da je potrebno razlikovati med
replikacijami v več oblikah. Tiste, ki zahtevajo potrditev v dveh stopnjah, delujejo tako, da
kopije podatkov v prvi stopnji prenesejo svojo potrditev hkrati z določeno spremembo v
zbirki podatkov, nato pa se v drugi stopnji izvede še replikacije (reprodukcija) podatkov.
Dvostopenjska potrditev lahko deluje nemoteno, če so povezani in usklajeni vsi serverji ter
ostale povezave v mreži, kar je načeloma težje omogočiti, zaradi česar se večina
organizacij odloča za enostavnejšo verzijo, ki v enem koraku opravi vse potrebno in so
prenosi takoj po vnosu podatkov na voljo vsem odjemalcem. S poslovno-finančnega vidika
replikacija nudi odjemalcem takojšen dostop do potrebnih podatkov ob nizki ceni strojne
opreme na dislociranih območjih. S tem postanejo podatki razpoložljivi lokalno in
omogočajo številne prednosti:
enostaven in takojšen dostop do podatkov;
22
izboljšajo se odzivni časi;
vzpostavi se nemotena obojesmerna komunikacija;
izdatki za strojno opremo se zmanjšajo, saj visokozmogljivi strežniki niso več nujno
potrebni.
Poleg naštetega je replikacija v okviru Microsoft SQL Serverja koristna tudi pri:
izvedbi sistemske migracije v več stopnjah;
prenosu podatkov na dodatna mesta v mreži (Slika 4.2);
omogočanju visoke razpoložljivosti podatkov na glavnem strežniku;
omogočanju neprekinjenega prenosa podatkov, saj vsebuje rešitev za zaznavanje
in odpravljanje napak;
izvedbi replikacije, saj se lahko ta izvrši tako zaporedno kot ob določenih časovnih
terminih [39].
Slika 4.2: Primer uporabe rešitve za replikacijo v MSSQL [40]
4.2 Rešitve in tipi replikacij v MS SQL
Yakushin [41] pravi, da moramo pred izdelavo osnutkov za registracijo tabel dobro vedeti,
katere so možnosti, s katerimi replikacija razpolaga. Na tak način bomo prišli do najboljše
rešitve za naše poslovne potrebe, izbiramo pa lahko med naslednjimi rešitvami:
osnovna rešitev za replikacijo podatkov je tista, ki povezuje ločene enote ter skrbi
za nemoten prenos in reprodukcijo podatkov (lokalni dostop je hiter, takojšen in
nemoten, saj so podatki razdeljeni po sekcijah, baze pa si medsebojno »ponujajo«
varnostne kopije (Slika 4.2);
varnostna rešitev s pomočjo replikacije podatkov pomeni, da uporabljamo replikacijo
podatkov za kreiranje varnostnih kopij v primerih izrednih dogodkov, kot so naravne
nesreče in nepričakovani izpadi – takšna rešitev omogoča takojšen preklop na
sekundarno zbirko;
23
rešitev replikacije za zbiranje poročil – določeni procesi se izvedejo na lokalni ravni
in tako ne povzročajo dodatnih obremenitev v celotni mreži povezav za mobilne
odjemalcev in podatkovno skladišče (Slika 4.3).
Slika 4.3: Rešitev za izdelavo poročil v obliki replikacije podatkov [40]
Pri opredelitvi replikacije lahko izbiramo med naslednjima opcijama:
kopiranje za potrebe odjemalcev (celovita, nasičena reprodukcijo podatkov, ki se
nahajajo v izvornih tabelah in vsebujejo primarni ključ (pogoj), saj lahko le tako
tabele na ciljnem mestu vsebujejo popolne kopije izvornih podatkov);
časovno vodeno reproduciranje podatkov (celovito kopiranje podatkov iz izvornih
mest (tabel), opremljenih s primarnimi ključi; poleg tega pa morajo imeti še dodatni
stolpec s časovno oznako (datum in čas) izvršene transakcije [42].
Pri uporabi replikacije podatkov velja omeniti še t. i. vmesne tabele tipa CD in CCD, ki imajo
več prednosti v procesu replikacije, vendar so v osnovi namenjene za vzdrževanje
trenutnega stanja, v katerem se zapisujejo vse spremembe na podatkih. Vmesne tabele
predstavljajo prednost, saj reprodukcija podatkov ne poteka več preko izvornih mest,
temveč preko teh tabel, zato podatke lažje ter hitreje prenese na ciljno mesto. Reprodukcija
podatkov se lahko poslužuje dveh tehnik, ki jih lahko vidimo na sliki (Slika 4.4).
24
Slika 4.4: Tehniki dodajanja podatkov [43]
Potiskanje podatkov predstavlja proces, v katerem se podatki iz izvornega mesta prenesejo
na ciljno, medtem ko (ali pa ne, glede na potrebe organizacije) se čaka na morebitne
dodatne zahteve glede dodajanja podatkov – le-ti morajo biti dostopni nemudoma, v
realnem času, zato se npr. transakcijska replikacija poslužuje metode potiskanja.
Vleka podatkov pomeni dodajanje podatkov v določenem časovnem zaporedju ali ob
določenem trenutku – glede na zahteve, ki jih imamo do izvornega mesta. Strategija je
primerna, ko želimo z replikacijo izpolniti več zastavljenih ciljev, a ni potrebe po realni
časovni dostopnosti do podatkov [44].
Ko govorimo o izvornem in ciljnem mestu, vemo, da ima lokacija podatkov dandanes velik
vpliv na odzivnost in uporabnost določene aplikacije. V ta namen je vsekakor pomembno
razmisliti o (de)centralizaciji dostopa z eno ali več kopijami baze podatkov, tako da
zagotovimo nemoteno delovanje. Yair [23] odsvetuje decentraliziran dostop, saj se lahko
pojavijo težave pri zagotavljanju razpoložljivosti in delovanju ob hkratnih dostopih več
25
oddaljenih odjemalcev do glavnega serverja in je oteženo ohranjanje zmogljivosti zaradi
preseženega optimalnega števila povezav.
4.2.1 »Snapshot« replikacija
»Snapshot« replikacija (Slika 4.5) naredi identično kopijo podatkov vsakič, ko jo zaženemo.
Ne omogoča sinhronizacije, saj vsaka iniciacija omenjene replikacije na novo kopira celotno
podatkovno zbirko in naredi zapis preko prejšnje verzije, ne glede na morebitne nastale
spremembe [35].
»Snapshot« replikacija uporablja aplikacijo BCP, ki se nahaja znotraj rešitve MS SQL. Na
osnovi tega orodja lahko zapiše vsebino določene tabele v mapo »snapshot« replikacije, ki
je mapa z deljenim dostopom. V njej je lahko več elementov, vendar moramo za vsakega
navesti, kdo lahko do njega dostopa.
Vsakič, ko se »snapshot« replikacija izvede, se vsi elementi oz. njihovi podatki ponovno
kopirajo na dislocirano mesto, kar zahteva veliko širokopasovno širino in fizično razpoložljivi
disk za shranjevanje podatkov. Redko je uporabljena sama zase, zato ne predstavlja
pomembnejše oblike replikacije pri uporabi rešitve MS SQL. Predstavlja pa pomemben
sestavni del za inicializacijo reprodukcije podatkov pri ostalih tipih replikacije, zato nadaljnje
zahtevnejše oblike brez nje skoraj niso mogoče.
26
Slika 4.5: Princip delovanja »snapshot« replikacije [40]
4.2.2 Transakcijska replikacija
Transakcijska replikacija (Slika 4.6) omogoča takojšnjo posodobitev sprememb v
»publisherju« (elementi replikacije, ki jih predstavljamo v naslednjem poglavju), takoj ko se
izvedejo. Poleg tega replikacija ne zahteva opredeljevanja dostopa do vseh elementov,
vendar pa se mora programsko orodje pri transakcijski replikaciji odzvati na vsako
posamezno spremembo, ki se zgodi. Za uporabo je ustrezna, ko ima Publisher dodane
»insert«, »update« in »delete« ukaze [8] oz. v primerih, ko Publisher ali Subscriber nista
SQL-strežnika podatkovne baze.
27
Slika 4.6: Princip delovanja transakcijske replikacije [8]
Posebna oblika transakcijske replikacije je »peer-to-peer« transakcijska replikacija, ki je bolj
ustrezna za aplikacije, ki lahko delujejo (zapisujejo in prebirajo podatke) v vseh podatkovnih
bazah. Takšna vrsta transakcijske replikacije je zmogljivejša, omogoča pa hitrejše branje in
zagotavlja boljšo razpoložljivost podatkov.
4.2.3 »Merge« replikacija (kompozitna replikacija)
»Merge« replikacija ponuja možnost sledenja vsem spremembam na Publisherju s sprožilci
(ang. »trigger«), medtem ko se Subscriber lahko sinhronizira s Publisherjem, s čimer pridobi
vse potrebne spremembe od zadnje sinhronizacije in hkrati od ostalih (predhodnih). Princip
delovanja replikacije je prikazan na sliki (Slika 4.7).
28
Slika 4.7: Princip delovanja »merge« replikacije [8]
Na odločitev, za kateri tip replikacije se bomo odločili v organizaciji ali oblikovanju
informacijskih rešitev, vpliva več dejavnikov. Zmogljivosti »snapshot« replikacije so
omejene, zato je pomembno vedeti, kako bo z dostopom do posodobljenih reprodukcij
podatkov, ali potrebujemo realno časovno kopijo podatkov iz izvornega mesta, kakšna naj
bo avtonomija rešitve za replikacijo in ali želimo popolne – identične – prepise podatkov ali
kakšno drugo obliko (Slika 4.8).
29
Slika 4.8: Kriteriji za izbiro replikacije podatkov [8]
4.3 Elementi replikacije v rešitvi MS SQL
Replikacija v MS SQL potrebuje za nemoteno delovanje usklajenost vseh sestavnih delov
(elementov, komponent), ki jih predstavljamo v nadaljevanju. Splet vseh in princip delovanja
lahko vidimo na sliki (Slika 4.9).
Slika 4.9: Elementi replikacije v MS SQL [35]
30
Elemente replikacije, ki jih vidimo na sliki (Slika 4.9), lahko opazujemo od Publisherja
naprej. Le-ta vsebuje več svojih publikacijskih podatkovnih baz. Takšna zbirka vsebuje
publikacijo (ang. »publication«), ki ima dva člena (ang. »article«). Nastavitve replikacije tako
vključujejo distributerja (ang. »distributor«) in njegovo distribucijsko podatkovno bazo kot
tudi naročnika (ang. »subscriber«) s svojo naročniško zbirko podatkov, ki vsebuje povezavo
z njim [35]. Nastavitve replikacije v rešitvi MS SQL vsebujejo tudi replikacijske agente, ki so
potrebni za zagon procesov, in nekaj obstranskih elementov, so pomembnih za vzdrževanje
reprodukcije podatkov. V nadaljevanju predstavljamo vsako izmed komponent nekoliko bolj
podrobno, pri čemer sledimo predpisom iz Fundamentals.
Členi so pomembni za vsak objekt SQL Serverja, ki želi biti repliciran, saj ga člen
opredeli in ustanovi. Vsak člen lahko pripada samo enemu objektu SQL Serverja, ki
mu je določena oznaka (npr. tabela dbo.tbl_3). Objekti, ki jim pripada določen člen,
so običajno tabele (ang. »table«), pogledi (ang. »view«) in procedure (ang. »store
procedures«). Lastnosti člena določajo, ali pripada celotnemu objektu ali samo
podmnožici njegovih delov (npr. člen lahko vsebuje celotno tabelo ali pa samo
vrstico oz. stolpec le-te). Če upoštevamo nekaj pogojev (omejitev), lahko enemu
objektu dodelimo več členov.
Publikacija je zbirka več členov, zbranih v enem sklopu kot posamezna enota. Na
sliki (Slika 4.9) je publikacija pikčasti krog, ki obdaja dva člena. Velja, da lahko le en
člen predstavlja del ene publikacije, vendar lahko več različnih členov dodelimo istim
objektom v več ločenih publikacijah.
Publikacijska baza je katerakoli baza, ki vsebuje objekte, ustvarjene enako kot členi.
Ko naredimo publikacijo na podatkovno bazo, SQL Server sam spremeni notranje
delovanje sistema, tako da ustvari več objektov, povezanih z replikacijo.
Publikacijska baza je dodatno zaščitena pred izgubami in motnjami delovanja.
Publisher je entiteta v SQL Serverju, ki omogoči publikacijo, pripravljeno za
replikacijo, čeprav sam Publisher nima aktivne vloge v procesu in nastavitvah
replikacije podatkov. Na sliki (Slika 4.9) predstavlja Publisherja celotni skrajno levi
stolpec, ob njem pa so publikacijska baza, publikacija in dva člena.
Distributer je povezan s Publisherjem. Je instanca v SQL Serverju, ki identificira
spremembe na členih v vsakem Publisherju. Glede na nastavitve replikacije je lahko
distributer ključen za obveščanje naročnika o prispeli publikaciji ali spremembah na
členih. Informacija o obojem je shranjena v distribucijski zbirki podatkov dokler niso
vsi naročniki obveščeni, ali pa se izteče določeno časovno obdobje. Distributerja
lahko v SQL Serverju opredelimo kot ločeno instanco od Publisherja, običajno pa
sta združena v isti instanci. Na sliki (Slika 4.9) je distributer najvišji del sredinskega
stolpca.
31
Vsakemu distributerju pripada vsaj ena distribucijska baza. Le-ta vsebuje določeno
število objektov, ki lahko hranijo tako podatke o replikaciji kot tudi replicirane
podatke. Distributer lahko ohranja več kot eno distribucijsko bazo, vendar morajo
vse publikacije na enem Publisherju uporabljati isto distribucijsko bazo.
Povezave oz. naročnine so element, skladen z ali enakovreden publikaciji. Vsaka
naročnina ustvari povezavo ali pogodbo med publikacijo in naročnikom. Obstajata
dva tipa naročnine, potisna in vlečna. V potisni se distributer neposredno posodablja
preko baze naročnika, medtem ko v vlečni naročnini naročnik prosi distributerja, če
so na voljo kakšne spremembe in potem posodobi podatke v naročniški podatkovni
bazi [35].
Tista podatkovna baza, na katero ciljamo med replikacijsko naročnino, je naročniška
podatkovna baza. Enako kot publikacijsko bazo tudi to SQL Server moderira med prvo
inicializacijo reprodukcije podatkov. Najbolj očitna sprememba je pri dodanih objektih, ki so
povezani z replikacijo. Pri naročniški podatkovni bazi moramo paziti, da ni varnostno
zaščitena, kot je publikacijska podatkovna baza.
32
5 REPLIKACIJA PODATKOVNE BAZE COMTRON TRONSYNC
Produkt TRONsync smo na podjetju Comtron razvili zaradi potreb do lastnega produkta za
vzdrževanje dostopnosti podatkov. Najprej smo uporabljali replikacijo MS SQL, a smo hitro
ugotovili, da ima konkurenčni produkt nekatere omejite, s katerimi se nismo zadovoljili.
Nekateri izmed njih so:
pri replikaciji MS SQL potrebujemo vsaj eno strežniško licenco MS SQL;
replikacija MS SQL ne omogoča repliciranja podatkov med podatkovnima bazama
MS SQL in SQLite;
pri velikem številu naročnikov (ang. »subscriber«) je začetna inicializacija klientove
baze trajala predolgo;
zahtevno nadgrajevanje struktur podatkovne baze;
replikacija MS SQL zahteva obojestransko povezavo SQL med server in klient bazo.
5.1 Možnosti orodij in komponente
TRONsync podpira transakcijski tip replikacije, kar pomeni, da je možno slediti vsaki
spremembi, ki se zgodi nad podatki v podatkovni bazi, in podatek sinhronizirati v
odjemalčevo podatkovno bazo. Prav tako je ob pravilni konfiguraciji podprt prenos
sprememb v obratni smeri (»merge« replikacija). Da sistem deluje, morajo biti prisotne in
konfigurirane vse komponente orodja. Komponente in povezave so prikazane na sliki (Slika
5.1).
33
Slika 5.1: Komponente v replikaciji TRONsync
Publisher je element, prisoten na strani strežnika. Vsebuje izvor podatkov in strežniško
podatkovno bazo. Za delovanje potrebuje instanco MS SQL, ki je lahko MS SQL Express,
kar pomeni, da lahko uporabimo brezplačno verzijo strežnika MS SQL.
Strežniška podatkovna baza je podatkovna baza, ki predstavlja vir podatkov za replikacijo.
V smeri proti odjemalcu se podatki vedno prenašajo iz te podatkovne baze.
Skupina predstavlja grupo več tabel, ki se upoštevajo ob prenosu. En odjemalec je lahko
prijavljen na eno skupino.
Tabela je element skupine. Predstavlja tabelo, katere podatke želimo prenašati. Na njej je
možno določiti filter, s katerim določimo, kateri podatki se prenašajo na odjemalca.
Distributor in agent sta spletni servis, ki omogoča prenos podatkov in ga je možno izpostaviti
na spletu. Skrbi za pravilno prenašanje podatkov iz strežniške podatkovne baze v
odjemalčevo podatkovno bazo in obratno. Za delovanje potrebuje dostop do distribucijske
podatkovne baze in strežniške podatkovne baze.
Distribucijska podatkovna baza je zbirka podatkov o konfiguraciji replikacije. Poimenujemo
jo TRONSync. Vsebuje podatke o skupinah, tabelah in uporabnikih. Baza mora imeti
neposredni dostop do strežniške podatkovne baze.
34
»Subscriber« je naročnik na replikacijo podatkov. Vsebuje lastno podatkovno bazo
(Odjemalčeva podatkovna baza), v katero replicira podatke. Ker replikacija TRONsync
deluje po »pull« principu, skrbi tudi za to, da podatke pridobi v določenem časovnem okvirju.
Odjemalčeva podatkovna baza je baza podatkov, v kateri so replicirani podatki. To bazo
uporablja aplikacija.
Posebnost orodja je, da omogoča replikacijo podatkov, ne samo med podatkovnimi bazami
MS SQL, ampak tudi med podatkovnima bazama MS SQL in SQLite, ki je zelo priljubljena
na platformah Android. To je ena izmed ključnih točk, zakaj smo se odločili za razvoj orodja
TRONsync. Na strani odjemalca se imamo možnost odločiti, ali bomo uporabljali
podatkovno bazo MS SQL ali SQLite. Na strani strežnika je uporaba podatkovne baze MS
SQL obvezna.
Orodje za komunikacijo med strežniškim in odjemalčevim delom uporablja spletne storitve
(ang. »web services«), kar pomeni, da sta lahko odjemalec in strežnik popolnoma
dislocirana. Med njima ni potrebno nobene povezave VPN ali SQL. Edini pogoj je dostop
do »web servisa«, bodisi v lokalnem omrežju bodisi preko spleta.
5.2 Opis delovanja
TRONsync beleži spremembe na nivoju vrstice v tabeli podatkovne baze in ne na nivoju
polja. To v praksi pomeni, da če se je spremenila vrednost katerega koli polja na tabeli, se
je na strani odjemalca posodobila celotna vrstica, v kateri je sprememba nastala. Vsaka
tabela, ki se replicira, mora biti opremljena s primarnim ključem tipa uniqueidentifier, ki ima
vklopljen parameter rowguidcol. Spremembe se beležijo v tabeli RowChange, ki se nahaja
v strežniški podatkovni bazi. Tabela se ustvari ob konfiguraciji replikacije in ima 5 polj:
RowChID je polje, ki predstavlja primarni ključ tabele in zaporedno številko
spremembe, ki se je zgodila v podatkovni bazi;
RowChDate predstavlja datum in čas spremembe;
ChTableName je ime tabele, na kateri se je sprememba zgodila;
ChRowGuid je vrednost primarnega ključa vrstice, nad katero se je sprememba
zgodila – vsaka tabela v podatkovni bazi mora biti označena z parametrom
ROWGUIDCOL;
ChAction je tip spremembe, ki se je zgodila – vnos vrstice, urejanje ali brisanje
vrstice.
35
V tabelo RowChange se zapisuje vsaka sprememba podatkov, ki se je zgodila na katerikoli
tabeli, določeni, da se upošteva pri replikaciji podatkov. Za zaznavanje sprememb se
uporabljajo sprožilci (ang. »triggers«). Sprožilec je implementiran tako, da po vsaki
spremembi vrstice naredi zapis v tabeli RowChange. V polju ChAction označi z »I« vnos v
tabelo, z »U« posodobitev enega izmed podatkov, z »D« pa izbris vrstice.
Ko se sprememba enkrat zapiše v to tabelo, je na vrsti spletni servis, da opravi svoje delo.
Replikacija TRONsync deluje po metodi »pull«, kar pomeni, da izvršuje procedure za
prenos podatkov odjemalec.
5.2.1 Metoda posodobitve podatkov v podatkovni bazi
Naročnik periodično ali na zahtevo izvršuje ukaze, potrebne za prenos podatkov. V vsaki
iteraciji posodobitve naprej pokliče metodo, ki vrne informacije o tem, katere tabele so bile
deležne sprememb in jih je potrebno posodobiti. Vhodni podatek v metodo je tudi zadnji
rowChID, ki ga vodi naročnik. Metoda vrne nazive tabel, za katere obstaja v tabeli
RowChange rowChID večji od zadnjega lokalnega rowChIDja.
Začetna inicializacija odjemalčeve podatkovne baze se zgodi s klicem te metode in vhodnim
parametrom allData = 1. Takrat dobimo nazaj vse tabele in podatke iz tabel, upoštevajoč
filtre, ki so definirani v distribucijski podatkovni bazi.
Postopek posodobitve poteka tako, da se naročnik z zanko sprehodi čez pridobljene tabele
in izvršuje ukaze za prenos podatkov. Podatki se prenašajo v paketih. Najprej se za
določeno tabelo pridobijo paketi, katerih podatke je potrebno v tabeli izbrisati, saj bi v
nasprotnem primeru lahko prišlo do konflikta pri vstavljanju podatkov. Recimo, da obstaja
tabela s poljema P1 in P2. P1 je primarni ključ tabele, P2 pa polje, nad katerim je definiran
unikatni indeks (ang. »unique index«). Na strežniku se je zgodila sprememba na tej tabeli.
Izbrisala se je vrstica P1 = 1 in P2=100 in se vstavila vrstica s podatki P1 = 2 in P2=100.
Če bi na odjemalca prenašali spremembo za vsako vrstico kronološko, ne bi imeli težav z
vrstnim redom, ker pa za vsako vrstico v tabeli prenesemo samo zadnje stanje, je
pomembno, da to naredimo v pravem vrstnem redu. Najprej pobrišemo vrstice, ki so bile
odstranjene na tabeli v strežniški podatkovni bazi, ter potem izvršimo posodobitve (ang.
»update«) in vnose (ang. »insert«) v tabelo. S tem postopkom se izognemo konfliktu
unikatnih indeksov. V primeru inicializacije naročnikove podatkovne baze so paketi, ki so
namenjeni brisanju podatkov, prazni.
36
Prenos podatkov se izvaja v paketih, katerih velikost je možno nastavljati po številu
vsebovanih vrstic podatkov. Manjše kot je število podatkov, večje je število paketov, ki se
morajo prenesti, da podatke v podatkovni bazi posodobimo na zadnji RowChID.
5.2.2 Paketi TRONsync
Paketi replikacije TRONsync so lahko sestavljeni na dva načina. V obeh primerih je to
objekt, ki nosi v glavi med drugim tudi podatek o tem, koliko zapisov vsebuje njegov
podatkovni del. S to informacijo je možno preveriti, ali se je paket prenesel v celoti. Drugi
del objekta je lahko zgrajen v obliki XML ali zapisa BCP. XML-oblika se uporablja pri
repliciranju podatkov v podatkovno bazo SQLite, BCP (bulk copy) pa pri prenosu med
dvema podatkovnima bazama MS SQL. BCP Utility je Microsoftov pripomoček za izvažanje
in uvažanje podatkov v podatkovno bazo. Je najhitrejši način, na katerega lahko podatke iz
podatkovne baze MS SQL izvozimo ali uvozimo. Med dvema podatkovnima bazama MS
SQL bi lahko podatke izvažali in uvažali s pomočjo XML-paketov, vendar se te opcije ne
poslužujemo, saj je veliko počasnejša.
Vsaki tip paketa obstaja v dveh dodatnih oblikah, odvisno od tega, ali gre za paket, ki bo
vsebino tabele izbrisal, ali paket, ki bo vsebino vstavil ali posodobil.
Primer vsebine XML-paketa je prikazan na sliki (Slika 5.2).
37
Slika 5.2: Primer XML-paketa za vnos ali posodobitev podatkov
Vsak XML-paket je sestavljen iz metapodatkov in podatkovnega dela. V metapodatkih je
zabeležen čas nastanka paketa (ang. »date«), ključ seje posodobitve podatkov (ang.
»tokenId«), zadnji ID sprememb (ang. »rowChId«) in tip paketa (ang. »packageType«). Tip
paketa pove, ali gre za paket, katerega podatkovni del je potrebno izbrisati ali
vstaviti/posodobiti.
Podatkovni del XML-paketa (ang. »data element«) vsebuje informacije za vnos v tabelo.
Vsak podelement »data« elementa predstavlja en zapis v tabeli, katere ime je enako imenu
elementa. Iz primera na sliki Slika 5.2 lahko razberemo, da je paket tipa vnesi/posodobi
podatke, saj ima parameter packageType v metapodatkih vrednost 1. iz podatkovnega dela
XML- dokumenta pa lahko razberemo, da bo paket vnesel/posodobil 5 zapisov v tabelo
PostalCode. Vrednost posameznega polja v tabeli PostalCode je razvidna iz najglobljega
nivoja data sekcije. Na sliki (Slika 5.3) je primer XML-paketa, ki definira, katere vrednosti
mora replikacija pobrisati iz naročnikove PB.
38
Slika 5.3: Primer XML-paketa tipa izbris
Strukturi paketa na sliki X - 1 in X sta zelo podobni. Razlika je v podatku packageType, ki
ima tokrat vrednost 0, kar označuje da paket nosi informacije o tem, katere vrstice je
potrebno izbrisati. Tudi podatkovni del ni čisto enak. Tokrat definicije vrstic v tabeli ne
vsebujejo podatkov vseh polj, ampak samo primarne ključe vrstic, ki jih je potrebno izbrisati
v tabeli PostalCode na strani odjemalca.
Ne glede na tip paketa XML se v obeh primerih po prenosu paketa podatkovna sekcija
prečrpa v začasno tabelo na odjemalčevi strani. Če gre za paket tipa vnesi/posodobi, je
rezultat začasna tabela s popolnoma enako strukturo kot je struktura dotične tabele na
strežniku. Če gre za paket tipa izbriši, je rezultat začasna tabela z enim poljem, ki ima naziv,
enak imenu primarnega polja ciljne tabele.
Paket BCP je sestavljen iz dveh datotek, ki se preko spletnega servisa prenašata v obliki
spominskega toka (ang. »memoryStream«). Prva datoteka ima končnico .fmt – v njej je
zapisana struktura tabele, v katero bomo uvažali podatke. Primer vsebine je prikazan na
sliki (Slika 5.4).
39
Slika 5.4: Primer vsebine datoteke.fmt
Druga datoteka ima končnico .dat in vsebuje podatke. Pripomoček BCP potrebuje za uvoz
podatkov obe datoteki. Najprej na osnovi datoteke .fmt ustvarimo začasno tabelo. Ker se je
ustvarila na podlagi izvorne tabele iz strežniške baze, bo imela tudi začasna tabela na
odjemalčevi strani enako strukturo. Z ukazom iz slike (Slika 5.5) sprožimo prenos podatkov
iz datoteke .dat v začasno tabelo.
Slika 5.5. Ukaz za uvoz podatkov BCP
Sedaj smo v isti točki kot bi bili, če bi prenos izvajali preko paketa XML. Imamo začasno
tabelo, v kateri so vsi potrebni podatki, da izvršimo posodobitev podatkov na odjemalčevi
strani.
5.2.3 Posodobitev podatkov naročnika
Do tega koraka se v odjemalčevi podatkovni bazi še ni zgodila nobena sprememba. Imamo
začasno tabelo s podatki za posodobitev in informacijo ter moramo podatke izbrisati ali
vstaviti/posodobiti. S pravilnimi poizvedbami lahko glede na tip paketa, ki ga prenašamo,
podatke prečrpamo iz začasne tabele v tabele, ki so v naročnikovi podatkovni bazi. Če je
parameter paketa packageType enak 0, izvršimo »delete ukaz«; če je enak 1, pa ukaz
insert/update SQL.
Ko smo zaključili obe zanki, zanko čez pakete in čez vse tabele, potrebne posodobitve, je
posodobitev zaključena. Zapomnimo si samo zadnji ident (rowChID) spremembe, ki smo jo
prenesli, da lahko naslednjič nadaljujemo tam, kjer smo zaključili. Če je v katerem koli
40
koraku posodabljanja podatkov prišlo do napake, si identa zadnje spremembe (rowChID)
ne zapomnimo in ob naslednjem prenosu postopek ponovimo.
5.3 Konfiguracija
Za uspešno vzpostavitev TRONsync replikacije podatkov potrebujemo:
instanco MS SQL, ki je lahko tudi verzije EXPRESS;
strežniško podatkovno bazo MS SQL;
spletni strežnik, zmožen zaganjati »web« servis WCF, recimo IIS;
začetno odjemalčevo podatkovno bazo MS SQL ali SQLlite;
mrežno povezavo med spletnim strežnikom in naročnikom;
povezavo SQL med spletnim strežnikom in strežniško podatkovno bazo;
aplikacijo, ki implementira TronRetail.Sync.dll (npr. TRONpos).
Na strežniško instanco MS SQL zraven strežniške podatkovne baze namestimo tudi
distribucijsko podatkovno bazo TRONsync. V slednji v tabeli syncTable definiramo tabele,
ki jih bomo replicirali. V tabeli GroupTable določimo tabele v skupine. Na enega naročnika
lahko določimo eno skupino tabel, ki se bodo replicirale. Naročniki so definirani v tabeli
ClientSync, v kateri jim tudi določimo uporabniško ime in geslo, s katerim se bodo prijavili
na publikacijo.
Na strežniški bazi izvršimo proceduro SyncEnable. Procedura ustvari vse potrebne
vpoglede (ang. »view«), procedure in sprožilce na tabele, ki bodo uporabljene v replikaciji.
Potrebno je še namestiti spletni servis (agent na distributerju), ki bo omogočal prenos
podatkov iz strežniške podatkovne baze na naročnikovo. Pri spletnem servisu je potrebno
konfigurirati nastavitveno datoteko. Primer nastavitvene datoteke je prikazan na sliki (Slika
5.6).
41
Slika 5.6: Nastavitvena datoteka spletnega servisa TRONsync
V sekciji, ki je na sliki (Slika 5.6) označena z 1, nastavimo povezavo do distribucijske
podatkovne baze. V sekciji 2 pa zraven povezave do baze še pot, kamor lahko spletni servis
odlaga datoteke BCP. Do te poti morata imeti uporabnik, pod katerim se zaganja instanca
dotičnega SQL in uporabnik, določen za zagonu spletnega servisa, pravico do zapisovanja
in branja.
5.4 Zaščita podatkov
Podatki, ki se prenašajo preko spleta, morajo biti dobro zaščiteni. TRONsync skrbi za
zaščito podatkov na dva načina. Prvi je kriptiranje celotnega prometa. Spletni servis, ki se
uporablja kot orodje za prenos podatkov, lahko nastavimo, da deluje preko SSL-protokola.
Tega uporablja večina spletnih aplikacij, pri katerih se pojavlja potreba po prenosu zaupnih
podatkov. Je uveljavljen način, kako zaščititi podatke na poti med pošiljateljem in
prejemnikom. Drugi način zaščite podatkov je zaščita z uporabniškim imenom in geslom.
Vsaki klic spletnega strežnika najprej zahtevo avtenticiranje. Če je geslo in uporabniško ime
primerno, vrne zahtevane podatke. Vsak naročnik replikacije mora imeti svoje unikatno
uporabniško ime in geslo. Replikacija dveh uporabnikov iz različnih lokacij ni možna. To je
onemogočeno tudi iz naslova filtriranja podatkov.
42
6 PRIMERJAVA REPLIKACIJ MS SQL IN TRONSYNC
V tem poglavju smo implementirali dve orodji, namenjeni repliciranju podatkov med
podatkovnimi bazami. Prva je replikacija Microsoft SQL, druga pa Comtron TRONsync. Pri
obeh smo uporabili isto strežniško (publikacijsko) podatkovno bazo.
6.1 Postavitev »merge« replikacije MS SQL
Za testno okolje smo uporabili virtualni strežnik, na katerega smo namestili operacijski
sistem Windows Server 2012 R1 x64. Strežnik ima dodeljena 2 procesorja Intel Xeon
X5660, ki dosežeta hitrost 2,8 GHz. Količina dodeljenega pomnilnika je 4 GB.
6.1.1 Nameščanje SQL strežnikov in vzpostavljanje povezave
Najprej smo namestili MS SQL 2014 Developer Edition na virtualni strežnik. Pri namestitvi
smo bili pozorni, da smo namestili tudi komponente, potrebne za replikacijo SQL. Izbira je
prikazana na sliki (Slika 6.1).
43
Slika 6.1: Izbira komponente, namenjene replikaciji
Po uspešni namestitvi strežnika smo nameščeni instanci (TIC) pripeli testno podatkovno
bazo (TronRetailServer), ki vsebuje 241 tabel. Velikost testne podatkovne baze je bila
približno 2,5 GB. Največ podatkov sta vsebovali tabeli Customer in Article – obe skupaj
preko 900.000 zapisov.
Sledila je namestitev odjemalca. Za odjemalca smo uporabili osebni prenosni računalnik, ki
ima 4-jedrni procesor Intel Core i7-3635QM, pri katerem posamezno jedro doseže hitrost
2,4 GHz. Računalnik ima nameščenega 8 GB pomnilnika, 128GB disk kapacitet SSD in
operacijski sistem Windows 8.1 64 bit.
Na prenosnik smo namestili Microsoft SQL Server 2014 Express. Pri instalaciji smo morali
ponovno biti pazljivi na izbiro replikacijskih komponent. Za ime instance smo izbrali
SQLEXPRESS. Ustvarili smo prazno podatkovno bazo z imenom TronRetailMS. Za
potrebe replikacije smo poskrbeli za obojestransko povezljivost med strežniško instanco in
odjemalčevo instanco SQL-strežnika. Ker sta strežnik in odjemalec na različnih lokacijah,
smo za povezavo vzpostavili tunel Cisco VPN. Na obeh lokacijah je bilo potrebno na SQL-
strežnikih omogočiti tudi protokol TCP/IP, ki ga omogočimo v orodju SQL Server
Configuration Manager, kot je prikazano na sliki (Slika 6.2).
44
Slika 6.2: Prikaz pripomočka SQL Server Configuation Manager
Ker so nastavitve na Cisco VPN takšne, da odjemalec vedno ob povezavi dobi drug IP-
naslov, domenskega imena odjemalca pa ni možno razbrati, smo na strežniku za klienta
ustvarili vzdevek (ang. »alias«). Nastavitve vzdevka so prikazane na sliki (Slika 6.3).
Slika 6.3: Nastavitve vzdevka za povezavo na odjemalca
Vsakič, ko ponovno vzpostavimo povezavo z omrežjem strežnika, je potrebno popraviti IP-
naslov, ki je na sliki (Slika 6.3) zapisan pod nastavitvijo Server. Z rešitvijo se v
produkcijskem okolju verjetno ne bi strinjali, za testne namene pa zadostuje našim
zahtevam. Paziti je potrebno tudi, da nam omrežnih vrat 1433, ki se uporabljajo pri
komunikaciji, ne blokira kateri izmed požarnih zidov. Povezava med strežnikom in
odjemalcem je tako omogočena, kar smo preverili z orodjem MS SQL Server Management
Studio. Kot je prikazano na sliki (Slika 6.4), se nam je iz strežnika uspelo povezati v obe
podatkovni bazi.
45
Slika 6.4: Povezava v strežniško in odjemalčevo podatkovno bazo z orodjem SSMS
Sledil je še test povezljivosti iz odjemalca, ki je bil prav tako uspešen.
6.1.2 Nameščanje SQL-strežnikov in vzpostavljanje povezave
Replikacijsko publikacijo MS SQL in subskripcijo lahko ustvarimo na dva načina. Uporabimo
lahko orodje MS SQL Management Studio in v njem za ta namen ustvarjen uporabniški
vmesnik, ali napišemo skripte T-SQL. V praksi se v primeru, ko imamo več naročnikov istih
nastavitev, uporablja oboje. Da ustvarimo samo publikacijo in prvo subskripcijo, uporabimo
uporabniški vmesnik. Za nadaljnje subskripcije pa iz prve ustvarimo skripto in jo potem
samo ustrezno priredimo.
Za testne namene smo najprej na strežniški podatkovni bazi ustvarili publikacijo s pomočjo
Management Studia. V pojavnem meniju na vozlišču Replication/Local Publication smo za
to izbrali New Publication, kot je prikazano na sliki (Slika 6.5).
46
Slika 6.5: Pot do ustvarjanja nove publikacije
Nato se odpre dialog, v katerem nastavimo vse potrebno. Na prvem koraku nas vpraša,
katero podatkovno bazo želimo publicirati – izbrali smo TronRetailServer. V naslednjem
koraku moramo izmed štirih možnosti (Snapchat publication, Transactional publication,
Peer-to-Peer publication in Merge publication) izbrati tip publikacije – izberemo Merge
publication. Naslednji korak je namenjen izbiri artiklov. Artikli v replikaciji MS SQL so lahko
tabele, shranjene procedure, pogledi in uporabniške funkcije. Izbrali smo 140 tabel.
Nekatere med njimi imajo po 50 polj in 300.000 zapisov, nekatere so pa samo pomožni
šifranti z recimo 5 polji in 10 zapisi. Na samem artiklu tabela lahko označimo tudi, katera
polja naj se prenašajo. Ker smo prenašali celotne tabele, polj nismo izključevali. V
naslednjem koraku smo določili filtre. Posameznem naročniku bi lahko iz iste tabele prenesli
podatke, namenjeni samo njemu, ampak smo želeli, da ima vsak naročnik vse podatke,
zato filtrov nismo določali. Uporabniški vmesnik nas je vprašal tudi, ali želimo posnetek
baze (Snapshot) ustvariti takoj in na koliko časa naj se posodablja. Kakšno časovno
obdobje izberemo, je odvisno od velikosti podatkovne baze in količine sprememb, ki se
dogajajo. Privzeta vrednost je na 14 dni. Če imamo veliko količino sprememb in naročnike
pogosto inicializiramo, je ta čas smiselno zmanjšati. Posnetek se uporablja pri inicializaciji
naročnikove podatkovne baze. Ko ustvarimo naročnika in ga inicializiramo, se najprej
prenese posnetek, za njim pa še vse spremembe, ki so ustvarjanju posnetka sledile. Če je
posnetek zastarel, lahko inicializacija naročnikove podatkovne baze traja precej časa. V
naslednjem koraku smo morali določiti še uporabnika, pod katerim se bo posnetek ustvarjal.
Za konec smo publikaciji določili ime SifrantiPub.
47
Namestiti je bilo potrebno še naročnika, ki smo ga ustvarili na povezavi do naročnikove
podatkovne baze. Na vozlišču Replication/Local Subscription smo iz pojavnega menija
izbrali New Subscriptions, kot je prikazano na sliki (Slika 6.6).
Slika 6.6: Pot do ustvarjanja nove subskripcije
Po korakih dodajanja nove naročnine moramo najprej izbrati publicista, nato pa še način
naročnine – »pull« ali »push«. Tehniki sta opisani v poglavju 3.2. Izbrali smo »pull«
subskripcijo, ker želimo posodobitev podatkov zaganjati iz klienta. V naslednjem koraku
izberemo naročnikovo podatkovno bazo, za katero je najbolje, če je kar prazna, saj MS
SQL-replikacija sama ustvari objekte, ki jih potrebuje. Podati je bilo potrebno še prijavne
podatke za povezavo v bazo in ustvarjanje naročnika je bilo končano.
Sledilo je proženje prenosov. »Pull« naročnino lahko sinhroniziramo na tri načine:
- z orodjem SQL Server Management Studio;
- z uporabo RM-objektov (Replication Management Objects);
- z replikacijskimi agenti.
Ob tem obstajajo določene omejitve. Orodje SSMS lahko uporabimo, če imamo plačljivo
licenco MS SQL. Ker naša postavitev določa, da imamo na strani naročnika nameščen MS
SQL Server 2014 Express, ta opcija odpade.
RM objekti so knjižnice, ki jih lahko vključimo v lastno aplikacijo. Sinhronizacijo lahko
prožimo sinhrono ali asinhrono, odvisno od potreb. Najprej se preko razreda
ServerConnection povežemo na naročnika, nato ustvarimo instanco razreda
MergePullSubscription in mu zagotovimo ustrezne parametre. Na koncu pa še preko
metode SynchronizeWithJob zaženemo sinhronizacijo.
Tretja opcija za zagon sinhronizacije je preko replikacijskega agenta. To je izvršilni program,
ki se namesti z instalacijo strežnika MS SQL. V primeru »merge« replikacije je to
REPLMERG.EXE, ki ga najdemo v mapi C:\Program Files\Microsoft SQL
48
Server\120\COM\. Pri zagonu programa je potrebno zagotoviti določene parametre za
dostop do publikacije in naročnine, zato smo ustvarili zagonsko datoteko runSync.bat, s
katero bomo zaganjali »merge« replikacijo MS SQL. Vsebina datoteke je prikazana na sliki
(Slika 6.7).
Slika 6.7: Vsebina datoteke runSync.bat
Zaradi optimalnega prikaza vsebine datoteke na sliki Slika 6.7 je ukaz, ki zažene
REPLMERG.EXE, razdeljen v več vrstic. Za delovanje morajo biti atributi zagona ločeni s
presledkom in ne z novo vrstico.
Na sliki (Slika 6.8) opazimo, da po zagonu datoteke runsync.bat vidimo v orodju za
spremljanje sinhronizacije (Replication Monitor), da sinhronizacija poteka. Konfiguracija je
torej bila uspešna.
Slika 6.8: Opazovanje stanja replikacije v Replication Monitorju
49
6.2 Postavitev replikacije TRONsync
Replikacijo TRONsync smo namestili na isti strežnik kot replikacijo MS SQL. Naprej je bilo
potrebno namestiti distribucijsko podatkovno bazo, ki je morala biti pripeta na isto instanco
SQL-strežnika kot publikacijska podatkovna baza. Distribucijska podatkovna baza vsebuje
tabele:
ActiveClient;
GroupSync;
GroupTable;
TableWhere;
UpGroup;
UpContext;
UpContextTable;
LogSync;
TableSync;
ClientSync;
TimeSync.
V tabeli Active Client se vodijo naročniki, ki trenutno prenašajo podatke. Tabela služi
avtentikaciji uporabnika. Ob pričetku repliciranja se ustvari seja, ki se zapiše v to tabelo.
Tabeli GroupSync in GroupTable služita definiciji skupine tabel, katerih podatki se
prenašajo v replikaciji iz strežnika na klienta. V tabeli GroupSync smo definirali zapis z
imenom WinTronPos, v tabeli GroupTable pa tabele. Izbrali smo iste kot pri replikaciji MS
SQL.
Ker za naročnike v nekaterih primerih ne potrebujemo celotne vsebine neke tabele, lahko v
tabeli TableWhere definiramo filter za to tabelo. Zapis povežemo preko tujega ključa na
tabelo GroupTable. V naši postavitvi filtrov nismo uporabljali.
Tabele UpContext, UpContextTable in UpGroup služijo definiciji tabel, katerih podatki se
replicirajo na publicista. Ustvarili smo skupino z nazivom TRONPos Win in v njej definirali
tematsko skupino Document. Ime tematske skupine predstavlja tudi ime primarne tabele.
Tematska skupina Document vsebuje zraven tabele Document še 21 drugih, vsebinsko
povezanih tabel. Ko smo sprožili prenos skupine Document, so se na strežnik prenesli
spremenjen ali vnesen zapis iz tabele Document in podatki, povezani s tem zapisom v
drugih 21 tabelah. Da je orodje znalo povezati pravilne podatke v paket nad vsako tabelo,
ki je v tematski skupini, smo naredili »where« pogoj po primarnem ključu iz primarne tabele.
V primeru, ko tabela v tematski skupini nima tujega ključa na primarno tabelo ali ime ključa
50
ni enako, lahko na tabeli UpContextTable definiramo pogojni stavek, s katerim povežemo
primarno tabelo in tabelo iz skupine.
Tabela LogSync distribucijske baze služi beleženju napak in procesov.
V tabeli TableSync definiramo tabele, ki jih uporabljamo v skupini za prenos na naročnika
(»GroupTable«) in tematskih skupinah za prenos na strežnik (»UpContextTabel«).
Tabela ClientSync služi definiranju naročnikov. Ustvarili smo naročnika z uporabniškim
imenom AlesNB. Določiti mu je bilo potrebno tudi ime publicistove podatkovne baze, iz
katere se podatki prenašajo (v našem primeru je to TronRetailServer). Nato smo izbrali že
prej definirano skupino za prenos iz strežnika in skupino za prenos na strežnik. Določili smo
tudi velikost paketa, izraženo v številu vrstic, ki se v paketu prenašajo. Za začetek smo
nastavili velikost paketa na 20.000 zapisov v tabeli. Velikost lahko priredimo glede na hitrost
širokopasovne povezave in zmogljivost strežnika, ki predstavlja publicista. Večjo kot
nastavimo velikost paketa, hitrejši bo prenos podatkov, a ob enem povečamo tudi trenutno
obremenjenost omrežja in strojne opreme.
V tabeli TimeSync smo določili urnik samodejnega proženja prenosa podatkov.
Po nastavitvi distribucijske podatkovne baze je bilo potrebno strežniško podatkovno bazo
povezati z distribucijsko. To smo naredili na tak način, da smo v strežniški podatkovni bazi
sprožili proceduro syncEnabled. Shranjena procedura je namestila potrebne poglede in
sprožilce na primerne tabele. Pogledi na podatkovno bazo TRONsync služijo zajemanju
pravilnih podatkov, prožilci pa beleženju sprememb, ki so se nad definirano tabelo za
prenos v distribucijski tabeli zgodile.
Namestiti je bilo potrebno tudi distributerja. Gre za spletni servis, ki ga lahko namestimo v
IIS (Internet Information Services). IIS je Microsoftov spletni strežnik, ki podpira spletne
servise HTTPS in ga je možno kot komponento namestiti na operacijski sistem, ki ga
uporabljamo. Za testne namene smo servis namestili na privzeto spletno stran, ki jo ob
namestitvi definira IIS. Servis smo poimenovali TRONSync. V produkcijskem okolju je
potrebno za varno komunikacijo vzpostaviti SSL. V našem spletnem strežniku smo tako
dobili eno spletno stran z enim spletnim servisom, kot je prikazano na sliki (Slika 6.9).
51
Slika 6.9: Hierarhija spletnega strežnika
Nastaviti je bilo potrebno še konfiguracijsko datoteko spletnega servisa, kar je opisano v
poglavju 5.3.
Replikacija TRONsync ne zagotovi začetnih struktur v naročnikovi podatkovni bazi, zato je
bilo potrebno prazno podatkovno bazo z vsemi strukturami zagotoviti ročno. Nato smo na
klienta namestili vzorčno podatkovno bazo, ki smo jo poimenovali TronRetailCS.
Obe replikaciji – MS SQL in TRONsync – potrebujeta agenta, ki proži sinhronizacijo. Za
agenta smo uporabili aplikacijo TRONpos, sistem za maloprodajo, ki uporablja replikacijo
TRONsync za zagotavljanje dostopnosti podatkov, tudi ko povezava do strežnika ni
mogoča.
Najprej smo nastavili povezavo do naše začetne podatkovne baze. V aplikaciji TRONpos
smo izbrali »Orodja« in »Povezava do podatkovne baze«. Odprlo se je okno, v katero smo
vnesli vse potrebne podatke. Okno vnosa je prikazano na sliki (Slika 6.10).
Slika 6.10: Vnos podatkov za povezavo do naročnikove podatkovne baze
Da smo odprli okno za vnos dostopnih podatkov in spremljanje prenosa podatkov, smo v
aplikaciji na začetni strani izbrali »Orodja« in »Prenos podatkov«. Odprl se nam je dialog, v
52
katerega smo vnesli naslov, uporabniško ime in geslo naročnika. Z gumbom »Prenesi« smo
nato podatke inicializirali v naročnikovi podatkovni bazi. »Posodobi šifrante« je sprožilo
sinhronizacijo podatkov od zadnjega stanja do stanja na strežniku. Okno za vnos
naročnikovih podatkov in zagon sinhronizacije je prikazano na sliki (Slika 6.11).
Slika 6.11: Okno za zagon sinhronizacije
6.3 Merjenje hitrosti inicializacije podatkov
Hitrost prenosa posnetka podatkovne baze smo zaganjali izmenično, najprej smo sprožili
prenos z orodjem MS SQL Replication in po zaključku s Comtron TRONsync. Da smo
zmanjšali vpliv nihanja pasovne širine internetne povezave, smo prenos ponovili 5-krat.
Rezultati so prikazani v tabeli (Tabela 6.1).
ŠTEVILKA
PONOVITVE
TRAJANJE (MIN)
REPLIKACIJA MS SQL
TRAJANJE (MIN)
REP. TRONSYNC
1. 14:56 9:40
53
2. 14:55 9:48
3. 14:32 9:45
4. 14:29 9:40
5. 14:26 9:41
POVPREČJE 14:39 9:42
Tabela 6.1: Rezultati inicializacije naročnikove podatkovne baze
Iz tabele (Tabela 6.1) je razvidno, da je Microsoftovo orodje za iste podatke porabilo
približno 50 % več časa za prenos inicializacijskih podatkov. Pri tem je vredno omeniti, da
je orodje MS v primerjavi s TRONsync moralo ustvariti tudi objekte (tabele, procedure,
poglede ...). V bazi TronRetailCS so vsi objekti bili ustvarjeni že prej, saj orodje tako
zahteva.
6.4 Merjenje hitrosti posodobitve podatkov
Iz standardnega poročila MSSMS »Disk Usage by Top Tables« je razvidno, katere tabele
zasedejo največ prostora. Del tega poročila je prikazan na sliki (Slika 6.12).
Slika 6.12: Del poročila »Disk Usage by Top Tables«
Predvidevamo lahko, da bodo posodobitve podatkov nad tabelami, ki so večje, trajale dlje,
saj posodabljanje zahteva lociranje podatka. Spreminjali smo podatke tabel:
54
- Customer;
- Article;
- ArticlePrice;
- ArticleCode.
6.4.1 Izvajanje sprememb nad podatkovno bazo publicista
Postopek testiranja je potekal na sledeč način:
1. izvršitev ukaza, ki izvedel spremembe na strežniškem PB;
2. zagon MS-replikacije;
3. beleženje časa, potrebnega za prenos sprememb;
4. zagon replikacije TRONsync;
5. beleženje časa, potrebnega za prenos sprememb;
6. merjenje pravilnosti podatkov.
Na strežniški PB smo v več korakih izvršili ukaze TSQL in po vsakem izmerili trajanje
posodobitve. Izvajali smo v nadaljevanju opisane ukaze.
Korak 1.1
update Customer set LastName = Lastname + '_modified' update Article set ArticleTitle = ArticleTitle + '_modified' update ArticlePrice set ModificationDate = GETDATE() update ArticleCode set ArticleCode = ArticleCode + '_modified'
Sprememba podatkov 6.1: Sprememba na vseh zapisih
Korak 1.2
update Customer set LastName = Lastname + '1' where lastname not like 'SKALA D.O.O.%' update Article set ArticleTitle = ArticleTitle + '1' where len(ArticleID) <8 update ArticlePrice set ModificationDate = GETDATE() where ValidFrom is not null update ArticleCode set ArticleCode = ArticleCode + '1' where ArticleCode like '11%'
Sprememba podatkov 6.2: Sprememba samo določenih zapisov
Korak 1.3
55
update Customer set LastName = Lastname + '1' where customerID like '12000%' update Customer set FirstName = FirstName + '2' where customerID like '12000%' update Customer set SearchAlias = SearchAlias + '3' where customerID like '12000%' update Customer set [Address] = [Address] + '4' where customerID like '12000%' update Customer set Phone1 = Phone1 + '5' where customerID like '12000%'
Sprememba podatkov 6.3: Večkratna sprememba istih zapisov na različnih poljih
Korak 1.4
update Customer set LastName = Lastname + '1' where customerID like '12000%' update Customer set LastName = Lastname + '2' where customerID like '12000%' update Customer set LastName = Lastname + '3' where customerID like '12000%' update Customer set LastName = Lastname + '4' where customerID like '12000%' update Customer set LastName = Lastname + '5' where customerID like '12000%'
Sprememba podatkov 6.4: Večkratna sprememba istih zapisov na istem polju
Korak 1.5
update Customer set LastName = Lastname + '6' where customerID like '12000%'
Sprememba podatkov 6.5: Sprememba enega polja istih zapisov
Korak 1.6
WITH e1(n) AS (SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1), /* 10 */ e2(n) AS (SELECT 1 FROM e1 CROSS JOIN e1 as b), /* 10*10 */ e3(n) AS (SELECT 1 FROM e1 CROSS JOIN e2), /* 10*100 */ e4(n) AS (SELECT 1 FROM e1 CROSS JOIN e3) /* 10*1000 */ SELECT n = ROW_NUMBER() OVER (ORDER BY n) into #t FROM e4 INSERT INTO [dbo].[Article]([RowGuidArticle],[ArticleID],[ArticleType],[ArticleTitle],[SearchAlias],[RowGuidTaxRate],[RowGuidArticleUnit],[WeighableItem],[CheckSerialNumbers]) SELECT newid(), cast(newid() as nvarchar(40)), 0,'title_'+ cast(newid() as nvarchar(40)),'search_'+ cast(newid() as nvarchar(40)),'F4DD85CF-CE1E-E2D1-3171-650938ABD2B7','A293D768-B68C-E311-B524-005056904834',0,0 FROM #t drop table #t
Sprememba podatkov 6.6: Dodajanje zapisov
Korak 1.7
56
delete Article where len(ArticleID) = 36
Sprememba podatkov 6.7: Brisanje zapisov
Trajanje posameznih korakov je prikazano v spodnji tabeli (Tabela 6.2).
KORAK
ŠT. SPREMENJENIH
ZAPISOV
TRAJANJE (MIN)
REPLIKACIJA MS SQL
TRAJANJE (MIN)
REP.TRONSYNC
1.1 1.682.734 41:53 32:13
1.2 327.175 10:04 3:18
1.3 9.741 1:10 0:12
1.4 9.741 1:17 0:09
1.5 9.741 1:23 0:08
1.6 10.000 2:28 0:10
1.7 10.000 1:28 0:09
Tabela 6.2: Trajanje prenosov na klienta iz vseh korakov
Iz tabele (Tabela 6.2) je razvidno, da je trajanje prenosa podatkov v veliki meri odvisno od
količine podatkov, ki jih je potrebno prenesti. Replikacijsko orodje TRONsync se je pri tem
odrezalo bolje. Precejšnja razlika je v času sinhronizacije pri majhni količini spremenjenih
podatkov, ki so v praksi ravno najpogostejše. Iz zapisnika prenosa replikacije MS SQL je
razvidno, da ob vsakem zagonu orodje preverja vse tabele, vključene v publikacijo. To
preverjanje traja približno 1,5 minute, kar posledično pri manjši količini podatkov predstavlja
večji del porabljenega časa. Orodje TRONsync pa preveri samo tabele, ki so bile deležne
sprememb, in s tem pridobi očitno razliko. Poleg tega replikacija MS prenaša spremembe
po samo 100 zapisov hkrati, medtem ko jih TRONsync prenaša 10.000 naenkrat.
V korakih 3, 4 in 5 smo preizkusili, kako se orodji obnašata pri sinhronizaciji več sprememb
nad istimi vrsticami. Glede na to, da je čas vseh treh korakov iz tabele (Tabela 6.2) skoraj
identičen, je razvidno, da je pomembno le, koliko različnih vrstic v podatkovni tabeli je bilo
spremenjenih, in ne kolikokrat se je sprememba nad neko vrstico zgodila.
57
6.4.2 Izvajanje sprememb na naročnikovi podatkovni bazi
Kot v prejšnjem podpoglavju smo tudi v tem spremembe izvajali po korakih, a tokrat na
strani naročnika. Za testiranje smo izbrali tabelo WorkTime, ki je v obeh orodjih nastavljena
kot tabela, ki se ne prenaša samo na klienta, ampak tudi na strežnik. Postopek testiranja je
potekal na sledeč način:
1. izvršitev spremembe na strani naročnika v PB TronRetailMS;
2. zagon replikacije MS;
3. beleženje trajanja prenosa na strežnik;
4. izvršitev spremembe na strani naročnika v PB TronRetailCS;
5. zagon replikacije TRONsync (prenos na strežnik);
6. beleženje trajanje prenosa na strežnik;
7. zagon replikacije MS;
8. zagon replikacije TRONsync (prenos na klienta);
9. merjenje pravilnosti podatkov.
Ker replikacija MS SQL Merge ne omogoča, da bi prenos na strežnik in iz strežnika izvajali
ločeno, smo z izvajanjem sprememb pričeli v PB, ki uporablja to replikacijo. Na tak način
smo lahko izmerili čas, ki ga orodje porabi samo za prenos na strežnik (ker sprememb za
prenos iz strežnika še ni). Po vseh devetih korakih mora biti stanje podatkov v vseh treh PB
enako. Spremembe, ki smo jih naredili na eni in drugi naročnikovi PB, pričakujemo v vseh
treh PB.
Koraki sprememb podatkov, ki smo jih izvajali nad naročniškima PB, so prikazani v
nadaljevanju.
58
Korak 2.1
WITH e1(n) AS (SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1), /* 10 */ e2(n) AS (SELECT 1 FROM e1 CROSS JOIN e1 as b), /* 10*10 */ e3(n) AS (SELECT 1 FROM e1 CROSS JOIN e2) /* 10*100 */ SELECT n = ROW_NUMBER() OVER (ORDER BY n), newid() as RowGuidWorkTimeMS, newid() as RowGuidWorkTimeCS ,DATEADD(DAY, (ROW_NUMBER() OVER (ORDER BY n)), 0) as DateToMS ,DATEADD(DAY, (ROW_NUMBER() OVER (ORDER BY n))+1000, 0) as DateToMSUpdate ,DATEADD(DAY, (ROW_NUMBER() OVER (ORDER BY n))+2000, 0) as DateToCS ,DATEADD(DAY, (ROW_NUMBER() OVER (ORDER BY n))+3000, 0) as DateToCSUpdate INTO #t FROM e3 INSERT INTO TronRetailMS.[dbo].[WorkTime] ([RowGuidWorkTime],[RowGuidUser],[WorkTimeFrom],[WorkTimeTo],[WorkTimeDuration]) SELECT RowGuidWorkTimeMS, '3c21b63c-1709-e111-a97b-005056904834',DateToMS, DateToMS,0 FROM #t INSERT INTO TronRetailCS.[dbo].[WorkTime] ([RowGuidWorkTime],[RowGuidUser],[WorkTimeFrom],[WorkTimeTo],[WorkTimeDuration]) SELECT RowGuidWorkTimeCS, '3c21b63c-1709-e111-a97b-005056904834',DateToCS, DateToCS,0 FROM #t INSERT INTO TronRetailCS.[dbo].[SyncUP] ([ContextName],[RecordKey],[RecDate],[Status]) SELECT 'WorkTime', #t.RowGuidWorkTimeCS, getdate(),0 FROM #t
Sprememba podatkov 6.8: Vnos zapisov
Korak 2.2
UPDATE WorkTimeMS SET [WorkTimeFrom] = #t.DateToMSUpdate FROM TronRetailMS.[dbo].[WorkTime] WorkTimeMS INNER JOIN #t ON #t.RowGuidWorkTimeMS = WorkTimeMS.RowGuidWorkTime UPDATE WorkTimeCS SET [WorkTimeFrom] = #t.DateToCSUpdate FROM TronRetailCS.[dbo].[WorkTime] WorkTimeCS INNER JOIN #t ON #t.RowGuidWorkTimeCS = WorkTimeCS.RowGuidWorkTime UPDATE su SET [Status] = 0 FROM TronRetailCS.[dbo].[SyncUP] su INNER JOIN #t ON #t.RowGuidWorkTimeCS = su.[RecordKey]
Sprememba podatkov 6.9: Sprememba zapisov
59
Korak 2.3
DELETE WorkTimeMS FROM TronRetailMS.[dbo].[WorkTime] WorkTimeMS INNER JOIN #t ON #t.RowGuidWorkTimeMS = WorkTimeMS.RowGuidWorkTime DELETE WorkTimeCS FROM TronRetailCS.[dbo].[WorkTime] WorkTimeCS INNER JOIN #t ON #t.RowGuidWorkTimeCS = WorkTimeCS.RowGuidWorkTime UPDATE su SET [Status] = 0 FROM TronRetailCS.[dbo].[SyncUP] su INNER JOIN #t ON #t.RowGuidWorkTimeCS = su.[RecordKey]
Sprememba podatkov 6.10: Izbris zapisov
KORAK
ŠT. SPREMENJENIH
ZAPISOV
TRAJANJE (MIN)
MS SQL REPLIKACIJA
TRONSYNC REP.
2.1 1.000 0:35 2:05
2.2 1.000 0:34 1:56
2.3 1.000 0:28 0:48
Tabela 6.3: Rezultati prenosov na strežnik
Rezultati iz tabele (Tabela 6.3) kažejo, da je prenos podatkov od odjemalca na strežnik pri
orodju TRONsync precej počasnejši. Razliko lahko pripišemo tehniki izvajanja prenosa.
Replikacija MS zajema in zapisuje podatke na strežnik na enak način kot iz strežnika, s
pomočjo orodja BCP, ki je najhitrejši možen način, da neke podatke zapišemo v tabelo.
Podatkovni paket BCP je tudi najmanjši možni paket, katerega podatke podatkovna baza
MS razume in jih lahko zapiše v svoje tabele. TRONsync podatke na strežnik prenaša v
obliki XML-paketov, ki so predstavljeni v poglavju 5.2.2. Operacija pretvarjanja podatkov v
XML-paket je potratnejša. Poleg tega je omenjeni paket z istimi podatki tudi približno enkrat
večji ob BCP-paketa. Velikost paketa poglavitno vpliva na čas prenosa preko omrežja. Vsi
dejavniki skupaj odražajo pričakovani rezultat, ki smo ga prikazali v tabeli (Tabela 6.3).
Vprašati se je potrebno, zakaj TRONsync ne uporablja enake metode kot replikacija MS.
Paketi XML so res počasnejši, vendar imajo možnost prenosa podatkov več tabel hkrati v
enem paketu. V sistemu TRONpos, kjer se orodje tudi uporablja, je pomembno, da podatki
dokumenta, ki je v osnovi sestavljen iz tabel Document in DocumentPos, prispejo na
strežnik istočasno, saj se tam dogajajo še nadaljnje obdelave, pri katerih je pomembno, da
so podatki dokumenta prisotni v celoti.
60
6.5 Integriteta podatkov
Med testiranjem, opisanim v podpoglavju 6.4, smo po vsakem koraku naredili še test
skladnosti podatkov med strežniško in naročnikovo podatkovno bazo. Uporabili smo dve
metodi, primerjavo števila zapisov v tabeli in primerjavo kontrolnih vsot.
Za štetje vrstic v tabeli smo uporabili SQL-ovo funkcijo COUNT. Primer za eno tabelo je
naslednji:
SELECT COUNT(*) FROM TronRetailCS.dbo.Article
Kontrolne vsote smo izračunali s pomočjo funkcije CHECKSUM in CHECKSUM_AGG.
Funkcija CHECKSUM vrne kontrolno vsoto za eno vrstico, CHECKSUM_AGG pa je
agregatna funkcija, ki iz kontrolnih vsot vseh vrstic naredi skupno kontrolno vsoto. Na tak
način dobimo eno število, ki reprezentira vsebino celotne tabele. Primer za izračun
kontrolne vsote nad tabelo Article je sledeč:
SELECT '[dbo].[Article]' table_name, CHECKSUM_AGG (CHECKSUM ([RowGuidArticle], [ArticleID], [ArticleType] …)) CHECKSUM FROM TronRetailCS.[dbo].[Article]
V funkciji CHECKSUM smo upoštevali vsa polja dotične tabele. V tabeli (Tabela 6.4) so
prikazani rezultati.
KORAK TABELA – METODA
(C-COUNT,
CS-CHECKSUM)
STREŽNIŠKA
PB
REPLIKACIJA
MS SQL
ODJEMALČEVA
PB
REPLIKACIJA
TRONSYNC
ODJEMALČEVA
PB
INI ARTICLE – CS -1905601347 -1905601347 -1905601347
ARTICLE – C 325058 325058 325058
ARTICLECODE – CS -1909983505 -1909983505 -1909983505
ARTICLECODE – C 330510 330510 330510
ARTICLEPRICE – CS -1911884987 -1911884987 -1911884987
ARTICLEPRICE – C 405647 405647 405647
CUSTOMER – CS 1009719609 1009719609 1009719609
61
CUSTOMER – C 624175 624175 624175
1.1 ARTICLE – CS 2132638785 2132638785 2132638785
ARTICLE – C 325058 325058 325058
ARTICLECODE – CS -260850399 -260850399 -260850399
ARTICLECODE – C 330510 330510 330510
ARTICLEPRICE – CS 2131425869 2131425869 2131425869
ARTICLEPRICE – C 405647 405647 405647
CUSTOMER – CS -1822182583 -1822182583 -1822182583
CUSTOMER – C 624175 624175 624175
1.2 ARTICLE – CS -789921029 -789921029 -789921029
ARTICLE – C 325058 325058 325058
ARTICLECODE – CS 2133997310 2133997310 2133997310
ARTICLECODE – C 330510 330510 330510
ARTICLEPRICE – CS 269135458 269135458 269135458
ARTICLEPRICE – C 405647 405647 405647
CUSTOMER – CS 1719147651 1719147651 1719147651
CUSTOMER – C 624175 624175 624175
1.3 CUSTOMER – CS -621839475 -621839475 -621839475
CUSTOMER – C 624175 624175 624175
1.4 CUSTOMER – CS 1307861000 1307861000 1307861000
CUSTOMER – C 624175 624175 624175
1.5 CUSTOMER – CS -657161648 -657161648 -657161648
CUSTOMER – C 624175 624175 624175
1.6 ARTICLE – CS -260930992 -260930992 -260930992
62
ARTICLE – C 335058 335058 335058
1.7 ARTICLE – CS -789921029 -789921029 -789921029
ARTICLE – C 325058 325058 325058
2.1 WORKTIME – CS -162781550 -162781550 -162781550
WORKTIME – C 2001 2001 2001
2.2 WORKTIME - CS -162781592 -162781592 -162781592
WORKTIME – C 2001 2001 2001
2.3 WORKTIME – CS -1170899550 -1170899550 -1170899550
WORKTIME – C 1 1 1
Tabela 6.4: Rezultati merjenja integritete podatkov
Podatki števila vrstic in kontrolne vsote se v vseh treh podatkovnih bazah ujemajo v vseh
korakih, tako da lahko z gotovostjo trdimo, da sta obe orodji podatke pravilno prenesli in
posodobili. Integriteta podatkov med publikacijsko podatkovno bazo in naročnikovo
podatkovno bazo je ključnega pomena. Če skladnost podatkov ne bi bila dosežena, je
orodje neuporabno.
63
7 SKLEP
Izbira pravega orodja za replikacijo podatkov med podatkovnimi bazami, kljub mali izbiri, ni
lahko delo. Strokovna literatura tako rekoč ne obstaja, vsi viri, s tem mislimo predvsem
spletna socialna omrežja, so preveč subjektivni, kar je sicer razumljivo, saj vsak član
zagovarja orodje, ki ga sam uporablja in s tem najbolje pozna. V diplomskem delu se nismo
ukvarjali z analizo znanstvenih metod vrednotenja izbire pravega orodja, ampak smo
poskušali preko treh najpomembnejših atributov, poiskati najprimernejše orodje. Ti atributi
so enostavnost uporabe, čim večja hitrost in brez pogojni atribut - zagotovljena integriteta
podatkov. Dobra izbira orodja za replikacijo podatkov med podatkovnimi bazami prinese
podjetju kakovostno zagotavljanje podatkov in lažje ter cenejše vzdrževanje.
Orodji, ki smo ju primerjali, Microsoft SQL Replication in Comtron TRONsync, opravljata
svoje delo odlično, vendar se v določenih točkah pojavijo razlike. Orodje TRONsync je
hitrejše, kar izstopa v sistemih, v katerih je potreba po skoraj realnih podatkih (NRT) velika.
Orodje je bilo sicer razvito za uporabo v katerem koli poslovnem sistemu, vendar se opazi,
da je namenjeno predvsem POS-sistemom. S tem mislimo predvsem na omogočanje filtrov
nad tabelami in prenosu podatkov na strežnik. Prenos podatkov na strežnik je v obliki XML-
podatkov, kar pomeni, da ni namenjen prenosu velike količine podatkov. V POS-sistemih
se na strežnik večinoma prenašajo dokumenti, katerih podatki so v več tematsko povezanih
tabelah. Podatke več tabel je enostavno zapakirati v XML in jih poslati na strežnik. Orodje
omogoča replikacijo podatkov tudi na podatkovno bazo SQLite. Funkcija je zelo
pomembna, saj je slednjo možno uporabiti v operacijskem sistemu Android. Trend
poslovnih mobilnih aplikacij je vedno večji, hitro se zgodi, da moramo sinhronizirati podatke
iz katerega večjega sistema. Šibkost orodja je v nastavljanju samih publikacij. Ker ni
grafičnega vmesnika, je vsako definicijo potrebno nastaviti ročno v distribucijski podatkovni
bazi.
Microsoftovo orodje je komercialno orodje, ki je uporabniku prijaznejše. Izdelan ima grafični
vmesnik, ki poenostavi definicijo publikacij in nadzor nad replikacijo. Za sam zagon
posodobitve ima na voljo tri načine. V plačljivi verziji SQL lahko posodobitev zaženemo brez
kakršne koli implementacije, kar na klik. Pri TRONsync je v vsakem primeru potrebno
implementirati knjižnico, ki omogoča zagon replikacije podatkov. Replikacija MS SQL je
zelo obširno orodje, zato se v samih funkcionalnostih in vseh možnih nastavitvah hitro
izgubimo. Za dobro implementacijo je potrebno odlično poznavanje orodja.
Glede na to, da obe orodji zagotavljata integriteto podatkov, za naslednji najpomembnejši
atribut pa smo izbrali hitrost, lahko sklepamo, da je TRONsync boljša izbira.
64
8 BIBLIOGRAFIJA
[1] James, M., Design and strategy for distributed data processing, London: Prentice-
Hall, 2011, str. 624.
[2] Craig, E. in Buchanan, T., Teach yourself Microsoft Access 2000 in 24 Hours,
Canada: SAMS Publishing, 1999.
[3] Mohorič, T., Podatkovne baze, Ljubljana: BI-TIM, 2002.
[4] Baloh, P. in Vrečar, P., Ob praktičnih primerih skozi Microsoft Access 2007 in
informatizacijo poslovanja, Ljubljana: Pasadena, 2009.
[5] McDonald, M., Access 2007, Beijing: Pogue Press, 2006.
[6] Frye, C., Microsoft Access 2007 hitro in jasno, Ljubljana: Pasadena, 2007.
[7] Ramakrishnan, R., Database management systems, Boston: MacGraw-Hill, 1997.
[8] Perpar, M., Sql Server 2012, FRI, Ljubljana, 2013.
[9] Bradač, P., Popolni vodič skozi Access 2003, Ljubljana: Pasadena, 2005.
[10] Mrhar, P., Uvod v SQL, Nova Gorica: Flamingo založba, 2002.
[11] Werber, B., Uporaba MS ACCESS-a 2003 v praksi, Kranj: Moderna organizacija,
2003.
[12] Schmidt, K., High Availability and Disaster Recovery, Frankfurt: Springer Berlin
Heidelberg, 2006, str. 108−125, 199−205.
[13] Goswami, H. S., Microsoft SQL Server 2008 High Availability, Birmingham: Packt
Publishing, 2011, str. 13−83, 203−253.
[14] MSDN, C# Programming Guide, 2014. [Elektronski]. Dostopno na:
https://msdn.microsoft.com/sl-si/enus/library/67ef8sbd.aspx. [Poskus dostopa 9. 4.
2016].
[15] Technet, High Availability Solutions (SQL Server), 2014. [Elektronski]. Dostopno na:
https://technet.microsoft.com/en-us/library/ms190202(v=sql.110).aspx. [Poskus
dostopa 9. 4. 2016].
[16] Sack, J. in Mishra, S., AlwaysOn Architecture Guide: Building a High Availability and
Disaster Recovery Solution by Using Failover Cluster Instances and Availability
Groups, 2012. [Elektronski]. Dostopno na: http://download.microsoft.com/
download/D/2/0/D20E1C5F-72EA-4505-9F26-FEF9550EFD44/Building_a_HA_and
_DR_Solution_using_AlwaysON_SQL_FCIs_. [Poskus dostopa 9. 4. 2016].
65
[17] Replication Guide and Reference, 2010. [Elektronski]. Dostopno na:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c2711210.pdf. [Poskus
dostopa 9. 4. 2016].
[18] Replication, Oracle, 1999. [Elektronski]. Dostopno na: http://www.csee.umbc.edu/
help/oracle8/server.815/ a67781/c31repli.htm#12636. [Poskus dostopa 15. 9. 2015].
[19] Sybase, Replication Server: An Architecture for Distributing and Sharing Corporate
Information, 2012. [Elektronski]. Dostopno na: http://www.sybase.com/content/
1019249/4427RepServerArch_3.v4.pdf. [Poskus dostopa 15. 9. 2015].
[20] Rankins, R., Jensen, P. in Bertucci P., Microsoft SQL Server 2000 Unleashed, Izv.
II, Canada: Sams, 2002.
[21] What is Database Replication?, Microsoft, 2001. [Elektronski]. Dostopno na:
http://support.microsoft.com/default.aspx?scid=/support/access/content/repl/replovr
vw.asp. [Poskus dostopa 16. 9. 2015].
[22] Oracle, Database Replication, 1999. [Elektronski]. Dostopno na: http://www.csee.
umbc.edu/portal/help/oracle8/server.815/a67781/c31repli.htm#12636. [Poskus
dostopa 9. 4. 2016].
[23] Yair, A. in Cipirian, T., From Total Order to Database Replication, 2012. [Elektronski].
Dostopno na: http://www.cnds.jhu.edu/pub/papers/AT02_icdcs.pdf. [Poskus dostopa
9. 4. 2016].
[24] Kodrič, A., Ali že uporabljate D2D «backup« rešitev?, Maribor: LanCom, 2012.
[25] Stodder, D., Bound to Succeed, DB2magazine, 2003. [Elektronski]. Dostopno na:
http://www.ibm.com/db_area/archives/2003/q1/stodder.shtml. [Poskus dostopa
16. 9. 2015].
[26] Why Use Database Replication?, 2014. [Elektronski]. Dostopno na: http://perso.
wanadoo.fr/mnfauvel/Kb/html/using_da.htm. [Poskus dostopa 16. 9. 2015].
[27] Daudjee, K. in Salem, K., Lazy Database Replication with Freshness Guarantees,
2002. [Elektronski]. Dostopno na: http://www.cs.uwaterloo.ca/cs-archive/CS-
2002/31/techrep.pdf. [Poskus dostopa 10. 9. 2015].
[28] Beth, H., New Features in DB2 Replication Version 8, 2014. [Elektronski]. Dostopno
na: http://www-3.ibm.com/software/data/dpropr/pres13/v8featuresprz.pdf. [Poskus
dostopa 10. 9. 2015].
[29] Charles, T., Database Replication, DB2magazine 5, 2007. [Elektronski]. Dostopno
na: http:// www.dbmsmag.com/9705d15.html. [Poskus dostopa 11. 9. 2015].
66
[30] Arup, N., Altering the Master Table in a Snapshot Replication Environment without
Recreating the Snapshot, 2012. [Elektronski]. Dostopno na: http://www.dbazine.
com/nanda2.html. [Poskus dostopa 11. 9. 2015].
[31] Tips for Performance Tuning SQL Server Replication, 2011. [Elektronski]. Dostopno
na: http://www.sqlserver-performance.com/replication_tuning.asp. [Poskus dostopa
15. 8. 2015].
[32] Johnston, D., PostgreSQL Database Replication Options, 2013. [Elektronski].
Dostopno na: http://conferences.oreillynet.com/presentations/os2013/johnson_dar
ren.pdf. [Poskus dostopa 15. 8. 2015].
[33] Database Replication in Microsoft Jet 4.0, Microsoft Corporation, 2009. [Elektronski].
Dostopno na: http://www.homelancs.com/Download_Files/dbrepjet.htm]. [Poskus
dostopa 15. 8. 2015].
[34] Building the Operational Data Store on DB2 UDB Using IBM Data Replication,
WebSphere MQ Family, and DB2 Warehouse Manager, 2011. [Elektronski].
Dostopno na: http://www.tower.com/building-operational-data-store-on-db2-udb-
using-ibm-redbooks-paperback/wapi/101741342. [Poskus dostopa 15. 8. 2015].
[35] Meine, S., Fundamentals of SQL Server, Poulsbo, WA: Simple Talk Publishing,
2013.
[36] Mike, H., «Automated Replication Management«, 2012. [Elektronski]. Dostopno na:
http://www.dbazine.com/hordila5.html. [Poskus dostopa 16. 9. 2015].
[37] «Replication Server: An Architecture for Distributing and Sharing Corporate
Information«, 2012. [Elektronski]. Dostopno na: http://www.sybase.com/content/
1019249/4427RepServerArch_3.v4.pdf. [Poskus dostopa 17. 9. 2015].
[38] Rankins, R., Jensen, P. in Bertucci, P., Microsoft SQL Server 2000 Unleashed, druga
ured., Sams, 2008.
[39] The Need for Replication Technology, 2014. [Elektronski]. Dostopno na:
http://www.unifx.com/data/replication.html. [Poskus dostopa 15. 8. 2015].
[40] Pensak, D., Cristy, J. in Singles, S., An Architecture for Distributing and Sharing
Corporate Information and Information security architecture for encrypting
documents for remote access while maintaining access control, 2012.
[41] Yakushin, I., Selected features of DB2 & metadatabase replication, 2015.
[Elektronski]. Dostopno na: http://www.ligo.caltech.edu/docs/G/G020413-00.pdf.
[Poskus dostopa 15. 9. 2015].
67
[42] Kemme, B. in Alonso, P., Using Optimistic Atomic Broadcast in Transaction
Processing Systems, 2010. [Elektronski]. Dostopno na: http://csdl.computer.org/
comp/trans/tk/2003/04/k1018abs.htm. [Poskus dostopa 16. 9. 2015].
[43] Baragoin, C., Building the operational data store on DB2 UDB using IBM Data
Replication, WebSphere MQ Family, and DB2 Warehouse Manager, San Jose,
California: IBM Corp., International Technical Support Organization, 2001.
[44] Otey, M., Database Replication Components, SQL Server Magazine, 2009.
[Elektronski]. Dostopno na: http://www.sqlmag.com/Articles/Print.cfm?ArticleID=
5677. [Poskus dostopa 16. 9. 2015].
68
69
70
