MSSQL Replikation

[haentschman]

Hallöle...

Da ich Alleinunterhalter in der Firma bin, und nur auf meine eigenen Entscheidungen höre , wollte ich diesmal lieber noch andere Meinungen einholen...

Gegeben:

1. 1 DB Server in der Firma
2. DB Server in den verschieden Niederlassungen

Frage vorweg:
Die einzelnen Transanktionsmöglichkeiten habe ich schon ausprobiert...funktionieren alle. Ich habe aber verschiedene Konstellationen die eigentlich ein Mischen erfordern. Geht auch...nur welche sind die besseren für die Konstellation? Welche Fallstricke erwarten mich?
...wie macht man es richtig.

Konstellation 1:
1. Daten die "sofort" synchronisiert werden müssen. Bidirektional. - Mergereplikation (1 Minute Intervall) funktioniert
Info: Jeder Datensatz wird in einer Sperrtabelle "gesperrt" bevor er geöffnet wird. In dieser einen Minute könnte der Andere auch den DS öffen und schreiben. Wie oft kommt das vor?
vs.
1. Jede "Niederlassung" hat seinen Verleger, der Server hat seinen Verleger - Transaktionsreplikation noch nicht probiert
Info:
https://docs.microsoft.com/de-de/sql...l-server-ver15

Zitat:

Wenn Sie ein Abonnement unter Verwendung des vollqualifizierten Domänennamens (FQDN) zu einer bidirektionalen Veröffentlichung hinzufügen möchten, sollten Sie überprüfen, ob der Servername (@@SERVERNAME) des Abonnenten den FQDN zurückgibt. Wenn der Servername des Abonnenten den FQDN nicht zurückgibt, führen Änderungen durch den Abonnenten möglicherweise zu Primärschlüsselverstößen.

Konstellation 2:
1. "statische" Daten unidirektional zum Abonnenten - Transaktionsreplikation funktioniert
Option: ggf. Umstellung auf bidirektional

Danke für Infos...

[Bernhard Geyer]

Funktionieren werden alle.
Frage ist nur ob alle Anwendungen mitspielen.

Es ist immer problematisch wenn die Anwendung Autoinc-Felder nutzt.
Das zweite Problem sind immer Cascatierte Löschoperationen.

Da kann es leicht passieren das die Replikationen "die Krätsche machen".

[haentschman]

Zitat:

Frage ist nur ob alle Anwendungen mitspielen.

...überall meine Anwendungen. Allerdings Umbau von Desktopversion zu Filialsystem...mal eben so.

Zitat:

Es ist immer problematisch wenn die Anwendung Autoinc-Felder nutzt.

Code:

create table xxx(
  ID int identity(1,1) not null,

Die ID Felder sind AutoInc... Lassen wir auf uns zukommen. Da sind noch einige Leichen im Keller...
Was greift eher... die identity oder AutoInc? Bringt es was das auf NONE umzustellen?

Zitat:

Das zweite Problem sind immer Cascatierte Löschoperationen.

Im Moment habe ich eine Cascade die aber nie benutzt werden "sollte", weil diese Daten nicht gelöscht werden. Die Cascade ist nur für "Wartungen"...
Kann ich mal ausprobieren.

Danke

[Frickler]

Kann man bei Identity eine Art Startwert vorgeben? Dann addiere doch eine sehr hohe Zahl oben drauf, und zwar auf jede zu mergende Tabelle einen anderen. Ich nehme mal an, das sind BigInt, also 64 Bit Integer? Dann auf eine Tabelle 1.000.000.000.000 draufaddieren, bei der nächsten 2.000.000.000.000 usw. Die Ids zählen dann nicht 1, 2, 3, ... usw sondern halt 1.000.000.000.001, 1.000.000.000.002, 1.000.000.000.003, ...usw. - und es gibt keine Konflikte beim Mergen.

Wenns sich um Filialen handelt, wäre auch die Filial-ID möglich, vorausgesetzt, das ist ne Zahl...

[haentschman]

Zitat:

und es gibt keine Konflikte beim Mergen.

...dafür ist die Sperrtabelle da. Damit nur einer schreiben kann. Bei Mergerepikation könnte es vorkommen, das 2 dann den DS offen haben...

Zitat:

1.000.000.000.003, ...usw. - und es gibt keine Konflikte beim Mergen

Wenn 2 die 1.000.000.000.003 schreiben könnte das auch zu Konflikten führen.

[Bernhard Geyer]

Zitat von Frickler:

Kann man bei Identity eine Art Startwert vorgeben?

Kann man.

Wir hatten zwei CRM-Systeme, welche laut Feature-Matrix Replikation bei MS SQL Unterstützten.
Beide haben nach kurzer Zeit die Replikation nicht mehr unterstützt, da trotz dieser Möglichkeiten die ganzen Filialen doch irgendwann mal Replikations/Merge-Probleme zeigten.

[Bernhard Geyer]

Zitat von haentschman:

Wenn 2 die 1.000.000.000.003 schreiben könnte das auch zu Konflikten führen.

Filiale 1 bekommt Nummernbereich 1.000.000.000.000 bis 1.999....
Filiale 2 bekommt Nummernbereich 2.000.000.000.000 bis 2.999....

Theoretisch gibts keine Überschneidungen.
Praktisch sind bei uns 2 Hersteller von CRMs an genau diesem Problem gescheitert...

[haentschman]

Zitat:

Wenn 2 die 1.000.000.000.003 schreiben könnte das auch zu Konflikten führen.

...wenn aber 2 Niederlassungen oder der Hauptsitz gleichzeitig, was möglich ist, am Beleg arbeiten, hast du trotzdem evt. Konflikte...unabhängig von der ID des Datensatzes...weil die ID ist in diesem Falle gleich!

[Bernhard Geyer]

Zitat von haentschman:

...wenn aber 2 Niederlassungen oder der Hauptsitz gleichzeitig, was möglich ist, am Beleg arbeiten, hast du trotzdem evt. Konflikte...unabhängig von der ID des Datensatzes...weil die ID ist in diesem Falle gleich!

Gleiche schon existierende ID.
Das ist eigentlich immer das "kleinere Problem", da hierfür entweder die Anwendung eine Konflikt-Wizward anbieten muss/wird oder das über die DB-Tools der Hersteller läuft.

Unsere Anwendung läuft auch bei einem Kunden mit zwei großen Standorten mit Merge-Replikation.
Auch wenn unsere Anwendung nicht für Replikation ausgelegt ist, funktioniert es. Aber auch nur weil die Nummernbereiche getrennt sind und praktisch der o.g. Fall nicht vorkommen sollte. Und falls doch ist der en IT so fähig die Merge-Konflikte selbständig zu lösen.

[haentschman]

Hallöle...

Zitat:

die Anwendung eine Konflikt-Wizward anbieten muss

...ich stelle sicher, daß nur einer im "System" diesen DS schreiben kann. Alle anderen kennen die Sperre, weil sie ist auf der "Masterdatenbank" eingetragen. Jeder Client setzt beim Bearbeiten die Sperre "zentral"...und nimmt sie auch wieder raus.

Klar kann trotzdem noch einiges schiefgehen. Sowas wie: Sperre kann nicht entfernt werden...weil Internet kaputt. Dafür kann man die Sperre im Notfalle manuell entfernen.

...aber wenigstens keine überschriebenen Daten.

Danke an Alle...