szerver es laptopok
Question
-
hali
van az alabbi feladatra "kiforrott" modszer?
adott egy szerver es 4 laptop,
sql2005 rol van szo, a szerver enterprise, a kliensek express
egy adatbazis 6-7 tablaval, amibol 1-2 az nagyon ritkan valtozik (kodszotar, konfiguracios tabla) van 1-2 olyan amibe csak beszurni lehet de a tobbi az olyan amiben lehet insert is meg update is. ezek kozt is akad 1 amiben sok mezo van (20nal tobb) a tobbiben keves (5-6)
a problema:
ha bent van a laptop a kozpontban, akkor halozaton at eleri a szervert
de ha nincs bent, akkor is dolgoznak a laptopon, tehat kerulnek be uj rekordok es valtoznak meg rekordok. maikor bemegy a laptop az irodaba, akkor szinkronba kell hozni a 2 adatbazist.
es 4 laptop van amik egymastol fuggetlenul akar ugyan azt a rekodot is modostihatjak (akar meg ugyan azt a mezot is!)
es persze szepen be kene mindenkit szinkorizalni.
ami tulkepp 3 esetet jelent:
- belepek a laptoppal a halozatba
- a halozaban dolgozom es masok is dolgoznak itt
ennek egy specialis esete amikor belep egy masik laptop is a halozatra
- kilepek a halozatrol (ez ha minden jol megy igazabol nincs, mert a "halozatban dolgozom" allapotban jo lenne minnel naprakeszebben tartani a lokalis DB-t.
a valtozasok mennyisege laptoponkent:
napi 10-20 uj rekord olyan tablakba, amikbe csak insert lehet
napi 3-5 update/ insert olyan tablakba, amin lehet update is
en mar egy hete ragodom kulonfele verziokon
ezert erdekelne, hogy van-e erre elfogadott, bevalt jo modszer meg persze minden egyeb otlet, hogy ki hogyan csinalna szoval johet minden, reszmegoldasok is (pl megoldas csak az insertes tablakra vagy csak az update tablakra)
Answers
-
Szia,
Én Merge replikációval próbálkoznék, abból is az SQL2K-ban is ismert "central publisher" modellel. A központ lenne a kiadó (publisher), a laptop-ok pedig lennének az előfizetők (subscriber, az express változat, csak előfizető lehet a merge replikációs modellben). SQL2K-s környezetben közel 5 éve üzemeltetek egy hasonló modellt, annyi külöbséggel, hogy ebben a modellben a kiadó mellett csak 1 előfizető laptop van + 6 távoli telephely (ezek is előfizetők, régebben, amíg kicsi volt a DB, <2GB, MSDE-k voltak, mára már mindegyik Standard Edition). A modellemben van particionálás, dinamikus filterezés, meg minden, amit el tudsz képzelni, de ez a Te példádhoz képest egy hatalmas DB, kb. 100 replikált táblával (ezen felül mégegyszer ennyi nem szinkronizált tábla halmaz). A laptop érdekessége, hogy gyakorlatilag egy egészségügyi szűrőbuszon van, amely a helyhez kötött telephelyek körzetében végez lakossági szűrést, így az adatrögzítéshez a laptop-on mindig arra a telephelyre kell bejeltkezni és adatokat tárolni, ahol a szakmai kiértékelést majd el fogják végezni (amelyik a legközelebbi helyhez kötött centrum).
Ami viszont kemény dolog lesz az hosszú ideig tartó aszinkron offline adatrögzítésből következő konfliktuskezelés, amikről Te is írtál és nyílván ezeken töprengsz. Ennek vannak egyszerűbb esetei és nagyon bonyolult esetei is. Pl. ha 2 offline telephely szerkeszti ugyanazt a sort, akkor megoldható az oszlop szintű követés (column tracking) így amennyiben eltérő oszlopok módosultak, automatikusan megtörténik az összefésülés. Ha ugyanazt a cellát módosítják, egy online rendszerben is konfliktus helyzet alakul ki, egy eredendően optimista zárolást végző rendszer, vagy a "last in wins", vagy egy ügyesebb GUI-n megmutatott felhasználói beavatkozásos változás összefésülő algoritmus fut le (egy ilyen megírása sem egyszerű, de nem elképzelhetetlen).
Tervezéskor mindeképpen érdemes bekalkulálni az auto inkrementes oszlopok kezelését (vagy eltérő identity range-ekkel dolgozni, vagy összetett kulcsokat alkalmazni, amelyben az ID mellett, egy telephelyazonosító alkotja a kulcsot, így a PK violation elkerülhető, vagy egy méretben, sebességben erőforrsáigényesebb, viszont globális egyediséget adó GUID típusú PK-kal dolgozni). Az is tény, hogy egy jó tervezéssel a konfliktusok keletkezésének valószínűsége csökkenthető, ha nem is szűntethető meg teljesen.
Vallom, hogy a merge replikáció nem egy transzparens, a meglévő DB-nkhez néhány kattintással hozzáadható kiegészítő szolgáltatás. A hosszú távú jól működő, gondtalan renszer kialakításának előfeltétele egy gondos előkészítői, tervezői és fejlesztői munka...
A merge szinkron alatt keletkező hibák az ún. "custom resolver" eljárásban feloldhatók, amely eljárást mi magunk tudjuk megírni, vagy tovább delegálhatjuk a problémát a GUI-ra és ezzel a megdás felelősségét a felhasználókra terhelni (pl. az utolsó szinkron óta 2 előfizetőn is átírták ugyanazt a lakcímet, 2 eltérő értékre, a fejlesztő ezt a problémát nem tudja megoldani, persze lehet itt is a "last in wins"-t alkalmazni, vagy azt mondani, hogy az x. előfizetőnek prioritása van ebben a kérdésben).
SQL2000-ben a merge replikáció kofliktuskezelési automatizmusának testreszabásához a köv. eszközkészlet állt rendelkezésre:
- Előre elkészített resolver sablonok (Additive, Averaging, DATETIME (Earlier Wins/Later Wins), Subscriber Always Wins, Minimum, Maximum, stb.)
- Saját tárolt eljárás meghívása, "custom stored procedure resolver" (ez csak UPDATE konfiktusokat kezelt), paraméterben megkapta a konliktus főbb jellemzőit, az előfordulás GUID azonosítóját).
- Az ICustomResolver interfészt megvalósító COM komponens készítése (DLL), a fentivel ellentétben ez minden típusú konliktts kezelésére alkalmas volt
- Interaktív resolver meghívása (a Windows Synchronization Manager GUI-s eszköz segítségével), az op. rendszer nyelvének megfelelő fordításban igyekezett kilistázni 2 gép szinkronizálása alatt konfliktusba került sorokhoz tratozó oszlopértékeket és az eltérő oszlopokat feélkövéren hozta, nyomógombokkal lehetett választani, hogy helyben hagyjuk a default resolver döntését, vagy felülbíráljuk és a másik szerver (a konfliktusban alulmaradt) eredményét hagyjuk érvényben.
- Merge ActiveX vezérlők és az SQL-DMO, amelyeket saját alkalmazásunkból használhattunk a szinkronizálási folyamat monitorozására és a beavatkozásra, menedzselésre.
SQL2005-ben a konfliktuskezeléshez a fentiek jó része még használható, de pl. a korábbi ActiveX vezérlők és az SQL-DMO nem támogatottak (http://msdn2.microsoft.com/en-us/library/ms143550.aspx), elkészült ugyanis egy új objektum modell: RMO (Replication Management Object).
Bővebben:
Programming with Replication Management Objects
http://msdn2.microsoft.com/fr-fr/library/ms146869.aspx
Advanced Merge Replication Conflict Detection and Resolution
http://msdn2.microsoft.com/en-us/library/ms151257.aspx
Exchanging Data with Mobile Users
http://msdn2.microsoft.com/en-us/library/ms151323.aspx
The Advantages of Microsoft Merge Replication for Mobile and Distributed Applications
Microsoft Replication Conflict Viewer and Interactive Resolver
http://msdn2.microsoft.com/en-us/library/ms186562.aspx
Remélem adtam szempontokat a merengéshez...
All replies
-
egy aprosag, arra termeszetesen van lehetoseg, hogy gazos esetben rakerdezunk a usernel, hogy ezzel mi legyen.
tehat ha pl egy rekordban ugyan azt a mezot tobben is piszkaltak, akkor ra lehet kerdezni annal akieppen bekapcsolodott a halozatram hogy mi legyen, a halozati vagy az ove?
de azert az ilyen kerdesek szamanak minimalizalas fontos cel
-
Szia,
Én Merge replikációval próbálkoznék, abból is az SQL2K-ban is ismert "central publisher" modellel. A központ lenne a kiadó (publisher), a laptop-ok pedig lennének az előfizetők (subscriber, az express változat, csak előfizető lehet a merge replikációs modellben). SQL2K-s környezetben közel 5 éve üzemeltetek egy hasonló modellt, annyi külöbséggel, hogy ebben a modellben a kiadó mellett csak 1 előfizető laptop van + 6 távoli telephely (ezek is előfizetők, régebben, amíg kicsi volt a DB, <2GB, MSDE-k voltak, mára már mindegyik Standard Edition). A modellemben van particionálás, dinamikus filterezés, meg minden, amit el tudsz képzelni, de ez a Te példádhoz képest egy hatalmas DB, kb. 100 replikált táblával (ezen felül mégegyszer ennyi nem szinkronizált tábla halmaz). A laptop érdekessége, hogy gyakorlatilag egy egészségügyi szűrőbuszon van, amely a helyhez kötött telephelyek körzetében végez lakossági szűrést, így az adatrögzítéshez a laptop-on mindig arra a telephelyre kell bejeltkezni és adatokat tárolni, ahol a szakmai kiértékelést majd el fogják végezni (amelyik a legközelebbi helyhez kötött centrum).
Ami viszont kemény dolog lesz az hosszú ideig tartó aszinkron offline adatrögzítésből következő konfliktuskezelés, amikről Te is írtál és nyílván ezeken töprengsz. Ennek vannak egyszerűbb esetei és nagyon bonyolult esetei is. Pl. ha 2 offline telephely szerkeszti ugyanazt a sort, akkor megoldható az oszlop szintű követés (column tracking) így amennyiben eltérő oszlopok módosultak, automatikusan megtörténik az összefésülés. Ha ugyanazt a cellát módosítják, egy online rendszerben is konfliktus helyzet alakul ki, egy eredendően optimista zárolást végző rendszer, vagy a "last in wins", vagy egy ügyesebb GUI-n megmutatott felhasználói beavatkozásos változás összefésülő algoritmus fut le (egy ilyen megírása sem egyszerű, de nem elképzelhetetlen).
Tervezéskor mindeképpen érdemes bekalkulálni az auto inkrementes oszlopok kezelését (vagy eltérő identity range-ekkel dolgozni, vagy összetett kulcsokat alkalmazni, amelyben az ID mellett, egy telephelyazonosító alkotja a kulcsot, így a PK violation elkerülhető, vagy egy méretben, sebességben erőforrsáigényesebb, viszont globális egyediséget adó GUID típusú PK-kal dolgozni). Az is tény, hogy egy jó tervezéssel a konfliktusok keletkezésének valószínűsége csökkenthető, ha nem is szűntethető meg teljesen.
Vallom, hogy a merge replikáció nem egy transzparens, a meglévő DB-nkhez néhány kattintással hozzáadható kiegészítő szolgáltatás. A hosszú távú jól működő, gondtalan renszer kialakításának előfeltétele egy gondos előkészítői, tervezői és fejlesztői munka...
A merge szinkron alatt keletkező hibák az ún. "custom resolver" eljárásban feloldhatók, amely eljárást mi magunk tudjuk megírni, vagy tovább delegálhatjuk a problémát a GUI-ra és ezzel a megdás felelősségét a felhasználókra terhelni (pl. az utolsó szinkron óta 2 előfizetőn is átírták ugyanazt a lakcímet, 2 eltérő értékre, a fejlesztő ezt a problémát nem tudja megoldani, persze lehet itt is a "last in wins"-t alkalmazni, vagy azt mondani, hogy az x. előfizetőnek prioritása van ebben a kérdésben).
SQL2000-ben a merge replikáció kofliktuskezelési automatizmusának testreszabásához a köv. eszközkészlet állt rendelkezésre:
- Előre elkészített resolver sablonok (Additive, Averaging, DATETIME (Earlier Wins/Later Wins), Subscriber Always Wins, Minimum, Maximum, stb.)
- Saját tárolt eljárás meghívása, "custom stored procedure resolver" (ez csak UPDATE konfiktusokat kezelt), paraméterben megkapta a konliktus főbb jellemzőit, az előfordulás GUID azonosítóját).
- Az ICustomResolver interfészt megvalósító COM komponens készítése (DLL), a fentivel ellentétben ez minden típusú konliktts kezelésére alkalmas volt
- Interaktív resolver meghívása (a Windows Synchronization Manager GUI-s eszköz segítségével), az op. rendszer nyelvének megfelelő fordításban igyekezett kilistázni 2 gép szinkronizálása alatt konfliktusba került sorokhoz tratozó oszlopértékeket és az eltérő oszlopokat feélkövéren hozta, nyomógombokkal lehetett választani, hogy helyben hagyjuk a default resolver döntését, vagy felülbíráljuk és a másik szerver (a konfliktusban alulmaradt) eredményét hagyjuk érvényben.
- Merge ActiveX vezérlők és az SQL-DMO, amelyeket saját alkalmazásunkból használhattunk a szinkronizálási folyamat monitorozására és a beavatkozásra, menedzselésre.
SQL2005-ben a konfliktuskezeléshez a fentiek jó része még használható, de pl. a korábbi ActiveX vezérlők és az SQL-DMO nem támogatottak (http://msdn2.microsoft.com/en-us/library/ms143550.aspx), elkészült ugyanis egy új objektum modell: RMO (Replication Management Object).
Bővebben:
Programming with Replication Management Objects
http://msdn2.microsoft.com/fr-fr/library/ms146869.aspx
Advanced Merge Replication Conflict Detection and Resolution
http://msdn2.microsoft.com/en-us/library/ms151257.aspx
Exchanging Data with Mobile Users
http://msdn2.microsoft.com/en-us/library/ms151323.aspx
The Advantages of Microsoft Merge Replication for Mobile and Distributed Applications
Microsoft Replication Conflict Viewer and Interactive Resolver
http://msdn2.microsoft.com/en-us/library/ms186562.aspx
Remélem adtam szempontokat a merengéshez...
-
váó!
ezer köszönet! ismét tanulam/tanulok valami újat
hetvégén olvasás (meg pirostojás
) aztán kedden mehet a próbálkozás tutti lesznek még kérdéseim, ahogy így elnézem
de az nagyon jó, hogy van rá "gyári" megoldás.
