Synkronisere data mellem SQL Server 2005 databaser

[larscph]

Er der mon nogen her der har erfaring med at synkronisere data mellem SQL Server databaser? Der findes cirka en milliard værktøjer mv til det, men det ville være rart at høre fra nogen der har praktisk erfaring med noget der rent faktisk kan fungere godt i stedet for bare at læse producentens egne lovprisninger. Setup'et er noget i stil med at der findes en "master" database og et antal "sekundære" databaser - alle databaserne har samme skema. De sekundære databaser er placeret på lokationer hvor der ikke altid er online adgang til, det er derfor der er relevant at synkronisere. Applikationen der anvender databasen kan opdatere data, både i master og i de sekundære databaser. Med andre ord skal synkroniseringen kunne foregå begge veje. Det er klart, at der skal være et regelsæt for hvordan konflikter håndteres. Den database der skal synkroniseres har ikke selv indbygget funktionalitet til at understøtte synkroniseringen (fx tidstempler ved opdatering af records) så det skal være i synkroniseringsværktøjet. Nogen der har praktisk erfaring med sådan en lille opgave?

[Gio]

Dit største problem hér er jo netop, at de forskellige lokationer kan risikere at oprette nye (forskellige) entries på samme (lokale) lokation - og derved får du en masse konflikter, når der skal sync'es op. Store Enterprise-databaser kan tage højde for dette - men så er de også ofte lavet som et cluster, der løbende opdateres. Måske du kan sætte det op sådan, at hver enkelt lokal database kun må oprette nye entries i et defineret område. Disse kendes så af "hoved-databasen", og kan bruges til at skelne imellem hvor opdateringerne kommer fra, og opdateres i hoved-databasen udfra tidsstempel m.m.. Om det vil virke i praksis?..tja...ikke optimalt. Og du vil jo nok også løbe tør for plads pludselig. Og så er det noget rod... Der er jo en grund til at de store databaser koster kassen - netop fordi de sættes op med lokale (offsite) kopier, og stadig holde styr på tingene. Men igen...jeg bør nok holde min kæft, da jeg bestemt ikke er database-dude. Så betragt ovenstående som mig der bare tænker højt, imens jeg taster :p

[larscph]

Ja tak... Jeg kan nemlig også forudse 1000 mærkelige og ubehagelige ting der kan opstå i sådan et setup. Det sagde jeg også til ham IT gutten hos vores kunde der vældig gerne ville lave sig sådan en løsning. Jeg tror nemlig helt ærligt heller ikke at det bliver særlig let at få til at fungere. Jeg lavede faktisk tidligere et setup der kunne synkronisere sig med andre systemer via en helt seperat synkroniserings database der var designet til præcist det. Det fungerede faktisk rigtig godt, men der havde vi også fuld kontrol over hoved-applikationen der brugte databasen. Anyhow, hvis nogen med held har lavet sådan noget så hører jeg gerne ;)

[Tomcat]

Det du er interesseret i, er hvad Microsoft i SQL 2005 kalder "Database Mirroring" (Advanced high availability solution that includes fast failover and automatic client redirection). Denne funktion er først tilgængelig i SQL 2005 Standard Edition. http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx Hvis du allerede har 2 licenser til SQL Standard 2005 kan du foretage al opsætning via SQL Management Studio 2005 fra Microsoft. \Tom

[larscph]

Databaselicenserne har jeg og det er en std edition. Men er den ikke specifikt beregnet til at have en "hot standby" datbase - hvor den der er standby ikke opdateres direkte af klient applikationen?

[zabel]

Måske lowlevel løsning men... Var det en ide at hver lokation gemmer rækker i db med et "seed", Dvs. lokation 1 gemmer altid en række med id xxxxx1, mens lokation 2 altid gemmer med xxxxx2 som id osv. Det er selvfølgelig lidt træls hvis der er er mange tabeller, og de allerede er lavet i databasen. Og det kræver jo så at id er af typen int. På den måde skal lokation 1 kun pushe dem med seed xxxx1 som til de andre DB'er osv osv.

[larsk]

Du har jo et samtidighedsproblem. Hvis datterbase 1 og datterbase 2 begge får opdateret samme post lokalt, så kan du IKKE lave en teknisk regel der afgør hvilken af disse 2 rettelser, der skal være den gældende ved syncronisering. Kun hvis du kører med 'konstant' syncronisering (eg. mirror/cluster) kan du håndtere det problem. Og jeg læser at det ikke er planen? Hvis du kun vil synkroniserede periodisk (1/flere gange på et døgn) så skal du definere hvilke poster hver enkelt datter må opdatere, og så kun syncronisere ind mod masteren fra disse poster, og efter en tur rundt og hente deldatabaser fra de lokale døtre, distribuere den samlede og komplet opdaterede masterbase ud til døtrene. Forudsætningen er så, at 2 døtre aldrig vil have skriverettigheder på de samme poster. Kan se det er foreslået før, men det er den eneste vej, hvis baserene skal være 'off-line' i forhold til hinanden. Disciplinen bliver derfor at definere hvilke 'ejere' der er på de enkelte poster/tabeller, og SÅ oprette syncroniseringsregler (og låsning af tabeller) efter disse regler.

[Buddha]

Hvorfor ikke kører en "on the fly" backup af MasterDB og lade dem editere direkte i den via en VPN eller andet, hvor de er online med den??? Mht til at de ikke altid er online, så definerer du at den sidst indtastede post gælder ved sykronisering og når de kommer online, overføres alle data. Så har alle den seneste version af DB og du bliver mindre sårbar for nedbrud osv. Så har du bare en lokal backup eks. hvert 5 min.