7
Tabellen aus zwei verschiedenen SQL-Datenbanken abgleichen
Hallo,
ich habe ein Problem, dass ich auf einem Datenbankserver zwei verschiedene Datenbanken laufen habe. Die eine ist eine ECHT-Datenbank, welche für unser ERP + Kassen System benutzt wird und ständig im Zugriff ist und die zweite ist eine Datenbank, die als Replikation - nennen wir sie repldb - verwendet wird. Das ist einfach nur eine Kopie der ECHT-Datenbank.
Nun haben wir das Problem, dass sich in der ECHT-Datenbank laufend Artikelpreise ändern und Artikel hinzukommen und so weiter. Das wird in ein paar Tabellen in der ECHT-Datenbank gepflegt. Diese Änderungen sollen nun aber auch in die repldb. Wir wollen nun aber nicht immer wieder ein Backup der ECHT-Datenbank einspielen, da dort viele Sachen drin sind, die nicht in der "repldb" benötigt werden und deshalb immer wieder manuell gelöscht werden.
Wie kann ich das realisieren? Reicht ein ganz normales SQL-Script, dass die beiden Tabellen vergleicht und dann einfach nur ein INSERT / UPDATE macht? Oder gibt es vom SQL Server noch eine Möglichkeit, außer die "repldb" wirklich zu einer Replikation der ECHT-Datenbank zu machen? So hatten wir es nämlich vorher und das hatte sehr starke Perfomance einbrüche gebracht.
Vielen lieben Dank für die Hilfe,
Gruß,
sippi
ich habe ein Problem, dass ich auf einem Datenbankserver zwei verschiedene Datenbanken laufen habe. Die eine ist eine ECHT-Datenbank, welche für unser ERP + Kassen System benutzt wird und ständig im Zugriff ist und die zweite ist eine Datenbank, die als Replikation - nennen wir sie repldb - verwendet wird. Das ist einfach nur eine Kopie der ECHT-Datenbank.
Nun haben wir das Problem, dass sich in der ECHT-Datenbank laufend Artikelpreise ändern und Artikel hinzukommen und so weiter. Das wird in ein paar Tabellen in der ECHT-Datenbank gepflegt. Diese Änderungen sollen nun aber auch in die repldb. Wir wollen nun aber nicht immer wieder ein Backup der ECHT-Datenbank einspielen, da dort viele Sachen drin sind, die nicht in der "repldb" benötigt werden und deshalb immer wieder manuell gelöscht werden.
Wie kann ich das realisieren? Reicht ein ganz normales SQL-Script, dass die beiden Tabellen vergleicht und dann einfach nur ein INSERT / UPDATE macht? Oder gibt es vom SQL Server noch eine Möglichkeit, außer die "repldb" wirklich zu einer Replikation der ECHT-Datenbank zu machen? So hatten wir es nämlich vorher und das hatte sehr starke Perfomance einbrüche gebracht.
Vielen lieben Dank für die Hilfe,
Gruß,
sippi
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 145386
Url: https://administrator.de/forum/tabellen-aus-zwei-verschiedenen-sql-datenbanken-abgleichen-145386.html
Ausgedruckt am: 17.04.2025 um 04:04 Uhr
7 Kommentare
Neuester Kommentar
Danke! Aber das wäre doch nur, wenn die Tabellen in EINER Datenbank sind, oder? Oder geht das auch von zwei verschiedenen Datenbanken aus?
Gibt es nicht einen MSSQL-Task oder so dafür, der das direkt abhandelt?
Gibt es nicht einen MSSQL-Task oder so dafür, der das direkt abhandelt?
USE DestinationDB
UPDATE DestinationDB.dbo.DestTable
SET
Feld1 = TableDest.Feld1,
Feld2 = TableDest.Feld2,
FROM SourceDB.dbo.SourceTable TableDest
WHERE TableDest.IndexKey = SourceTable.IndexKey
Oder Du machst nen Copy-Job der die Tabelle komplett in die andere kopiert.
UPDATE DestinationDB.dbo.DestTable
SET
Feld1 = TableDest.Feld1,
Feld2 = TableDest.Feld2,
FROM SourceDB.dbo.SourceTable TableDest
WHERE TableDest.IndexKey = SourceTable.IndexKey
Oder Du machst nen Copy-Job der die Tabelle komplett in die andere kopiert.
Zitat von @Karo:
USE DestinationDB
UPDATE DestinationDB.dbo.DestTable
SET
Feld1 = TableDest.Feld1,
Feld2 = TableDest.Feld2,
FROM SourceDB.dbo.SourceTable TableDest
WHERE TableDest.IndexKey = SourceTable.IndexKey
Oder Du machst nen Copy-Job der die Tabelle komplett in die andere kopiert.
USE DestinationDB
UPDATE DestinationDB.dbo.DestTable
SET
Feld1 = TableDest.Feld1,
Feld2 = TableDest.Feld2,
FROM SourceDB.dbo.SourceTable TableDest
WHERE TableDest.IndexKey = SourceTable.IndexKey
Oder Du machst nen Copy-Job der die Tabelle komplett in die andere kopiert.
Hallo,
wie mache ich einen Copy-Job?
Gruß,
sippi
Moin sippiseincousin,
ist jetzt ein bisschen schwer herauszulesen, ob das nun "Danke, klappt. Zusatzfrage.."-Kommentar ist oder ob du immer noch auf der Stelle trittst..
Gib doch erst mal Statusmeldung bitte.
Zu den verschiedenenen Optionen, die die hast oder haben könntest.
Nach deinen Ausführungen scheint - wer auch immer das zu verantworten hat- auf dieser Teil-ProdDB-Kopie eben nur ein willkürlicher Teil der Tabellen nachgestellt zu sein.
[Ich weiss gar nicht, wie ich die nennen soll? "Repl-Db" geht mir in dem Fall gar nicht über die Tasten].
Dementsprechend dürften dort auch Relationen und FroreignKey-Contraints gar nicht funktionieren und sind wahrscheinlich aus Platzersparnisgründen weggelassen.
Der Ansatz,den Karo vorgeschlagen hat, macht es zwar nicht wirklich schlimmer (wer sollte das erreichen), aber dadurch, dass nur die IDs aktualisiert werden, die in PROD-Quelltabelle und Pseudo-Repl-Clone-Tabelle sind...
-> ID vorhanden in PROD, ID vorhanden in ZIEL --> Update
-> ID vorhanden in PROD (neues Satz), noch nicht im Ziel--> nix wird im Ziel geschrieben
-> ID gelöscht in Quelle, noch vorhanden im Ziel --> nix wird im Ziel geschrieben.
> jedes Mal mehr Inkonsistenzen und Abweichungen.
Dieser Ansatz ist also fast noch schlechter als wenn du
Aber steck doch da nicht so viel Aufwand in ein inkonsistentes Abziehbild.
Kopiere die Prod-Datenbank 1:1 rüber mit allen Tabellen, allen Indices, allen Constraints und allen Datensätzen.
Und wenn du aus religiösen Gründen oder als Veganer "Replizieren" ablehnst... dann mach es eben spontan und sporadisch von Hand.
WTHF kann der Grund dafür sein, dass ihr nicht alles kopiert?? Die Festplattenpreise?? Geheime Daten im Prod-System und keine Rechte-Absicherung auf dem Clone?
Grüße
Biber
ist jetzt ein bisschen schwer herauszulesen, ob das nun "Danke, klappt. Zusatzfrage.."-Kommentar ist oder ob du immer noch auf der Stelle trittst..
Gib doch erst mal Statusmeldung bitte.
Zu den verschiedenenen Optionen, die die hast oder haben könntest.
Nach deinen Ausführungen scheint - wer auch immer das zu verantworten hat- auf dieser Teil-ProdDB-Kopie eben nur ein willkürlicher Teil der Tabellen nachgestellt zu sein.
[Ich weiss gar nicht, wie ich die nennen soll? "Repl-Db" geht mir in dem Fall gar nicht über die Tasten].
Dementsprechend dürften dort auch Relationen und FroreignKey-Contraints gar nicht funktionieren und sind wahrscheinlich aus Platzersparnisgründen weggelassen.
Der Ansatz,den Karo vorgeschlagen hat, macht es zwar nicht wirklich schlimmer (wer sollte das erreichen), aber dadurch, dass nur die IDs aktualisiert werden, die in PROD-Quelltabelle und Pseudo-Repl-Clone-Tabelle sind...
-> ID vorhanden in PROD, ID vorhanden in ZIEL --> Update
-> ID vorhanden in PROD (neues Satz), noch nicht im Ziel--> nix wird im Ziel geschrieben
-> ID gelöscht in Quelle, noch vorhanden im Ziel --> nix wird im Ziel geschrieben.
> jedes Mal mehr Inkonsistenzen und Abweichungen.
Dieser Ansatz ist also fast noch schlechter als wenn du
- ein logisches "Kopiere Quelle, übernagle alle evtl vorhandenen Zielsätze" machst [SELECT * FROM ProdDB.Prod_table INTO PseudoCloneDB.Clone_table]
- oder aber ein physisches Kopieren "Kopiere Quelle, übernagle alle evtl vorhandenen Dateisektoren" machst mit irgendeiner Dump/Load/Unload-Mimik.
Aber steck doch da nicht so viel Aufwand in ein inkonsistentes Abziehbild.
Kopiere die Prod-Datenbank 1:1 rüber mit allen Tabellen, allen Indices, allen Constraints und allen Datensätzen.
Und wenn du aus religiösen Gründen oder als Veganer "Replizieren" ablehnst... dann mach es eben spontan und sporadisch von Hand.
WTHF kann der Grund dafür sein, dass ihr nicht alles kopiert?? Die Festplattenpreise?? Geheime Daten im Prod-System und keine Rechte-Absicherung auf dem Clone?
Grüße
Biber
Zitat von @Biber:
Moin sippiseincousin,
ist jetzt ein bisschen schwer herauszulesen, ob das nun "Danke, klappt. Zusatzfrage.."-Kommentar ist oder ob du immer
noch auf der Stelle trittst..
Gib doch erst mal Statusmeldung bitte.
Zu den verschiedenenen Optionen, die die hast oder haben könntest.
Nach deinen Ausführungen scheint - wer auch immer das zu verantworten hat- auf dieser Teil-ProdDB-Kopie eben nur ein
willkürlicher Teil der Tabellen nachgestellt zu sein.
[Ich weiss gar nicht, wie ich die nennen soll? "Repl-Db" geht mir in dem Fall gar nicht über die Tasten].
Dementsprechend dürften dort auch Relationen und FroreignKey-Contraints gar nicht funktionieren und sind wahrscheinlich aus
Platzersparnisgründen weggelassen.
Der Ansatz,den Karo vorgeschlagen hat, macht es zwar nicht wirklich schlimmer (wer sollte das erreichen), aber dadurch, dass nur
die IDs aktualisiert werden, die in PROD-Quelltabelle und Pseudo-Repl-Clone-Tabelle sind...
-> ID vorhanden in PROD, ID vorhanden in ZIEL --> Update
-> ID vorhanden in PROD (neues Satz), noch nicht im Ziel--> nix wird im Ziel geschrieben
-> ID gelöscht in Quelle, noch vorhanden im Ziel --> nix wird im Ziel geschrieben.
> jedes Mal mehr Inkonsistenzen und Abweichungen.
Dieser Ansatz ist also fast noch schlechter als wenn du
Aber steck doch da nicht so viel Aufwand in ein inkonsistentes Abziehbild.
Kopiere die Prod-Datenbank 1:1 rüber mit allen Tabellen, allen Indices, allen Constraints und allen Datensätzen.
Und wenn du aus religiösen Gründen oder als Veganer "Replizieren" ablehnst... dann mach es eben spontan und
sporadisch von Hand.
WTHF kann der Grund dafür sein, dass ihr nicht alles kopiert?? Die Festplattenpreise?? Geheime Daten im Prod-System und keine
Rechte-Absicherung auf dem Clone?
Grüße
Biber
Moin sippiseincousin,
ist jetzt ein bisschen schwer herauszulesen, ob das nun "Danke, klappt. Zusatzfrage.."-Kommentar ist oder ob du immer
noch auf der Stelle trittst..
Gib doch erst mal Statusmeldung bitte.
Zu den verschiedenenen Optionen, die die hast oder haben könntest.
Nach deinen Ausführungen scheint - wer auch immer das zu verantworten hat- auf dieser Teil-ProdDB-Kopie eben nur ein
willkürlicher Teil der Tabellen nachgestellt zu sein.
[Ich weiss gar nicht, wie ich die nennen soll? "Repl-Db" geht mir in dem Fall gar nicht über die Tasten].
Dementsprechend dürften dort auch Relationen und FroreignKey-Contraints gar nicht funktionieren und sind wahrscheinlich aus
Platzersparnisgründen weggelassen.
Der Ansatz,den Karo vorgeschlagen hat, macht es zwar nicht wirklich schlimmer (wer sollte das erreichen), aber dadurch, dass nur
die IDs aktualisiert werden, die in PROD-Quelltabelle und Pseudo-Repl-Clone-Tabelle sind...
-> ID vorhanden in PROD, ID vorhanden in ZIEL --> Update
-> ID vorhanden in PROD (neues Satz), noch nicht im Ziel--> nix wird im Ziel geschrieben
-> ID gelöscht in Quelle, noch vorhanden im Ziel --> nix wird im Ziel geschrieben.
> jedes Mal mehr Inkonsistenzen und Abweichungen.
Dieser Ansatz ist also fast noch schlechter als wenn du
- ein logisches "Kopiere Quelle, übernagle alle evtl vorhandenen Zielsätze" machst [SELECT * FROM
- oder aber ein physisches Kopieren "Kopiere Quelle, übernagle alle evtl vorhandenen Dateisektoren" machst mit
Aber steck doch da nicht so viel Aufwand in ein inkonsistentes Abziehbild.
Kopiere die Prod-Datenbank 1:1 rüber mit allen Tabellen, allen Indices, allen Constraints und allen Datensätzen.
Und wenn du aus religiösen Gründen oder als Veganer "Replizieren" ablehnst... dann mach es eben spontan und
sporadisch von Hand.
WTHF kann der Grund dafür sein, dass ihr nicht alles kopiert?? Die Festplattenpreise?? Geheime Daten im Prod-System und keine
Rechte-Absicherung auf dem Clone?
Grüße
Biber
Hallo Biber,
danke für deine ausführliche Antwort.
Es war leider keine Zusatzfrage - ich trete immer noch auf einer Stelle!
Noch einmal zur Erklärung unseres Konzepts:
Wir haben eine ECHT-Datenbank auf der cirka 250 User ständig arbeiten - 200 davon sind Kassenuser, die in unseren Filialen halt kassieren und die restlichen 50 sind User in der Zentrale und im Lager.
Am Anfang hatten wir von hier aus direkt eine Replikation in Filialdatenbanken für einen Notfallbetrieb laufen, damit die Filialen auch kassieren können, wenn keine Verbindung zur Zentrale besteht. Dies hatte aber starke Performanceprobleme auf der ECHT-Datenbank verursacht und wir haben diese Konstellation wieder abgeschafft.
Nun haben wir die ECHT-Datenbank einfach kopiert und dadurch eine zweite Datenbank gemacht. Diese heißt bei uns "repldb", da sie für die Replikation der Filialen verantwortlich ist! Von hier aus werden die Datenbanken in den Filialen mit Daten versorgt!
Das Problem ist nun, dass im ECHT-System laufend Änderungen passieren: Artikel kommen hinzu, Preise werden geändert, Bezeichnungen werden geändert!
Diese Änderungen finden dann nicht in der "repldb" statt.
Da diese Änderungen aber nur zwei drei Tabellen betrifft, möchte ich nicht immer wieder ein komplettes Backup der Datenbank einspielen, sondern nur die zwei drei Tabellen quasi "sychronisieren" oder halt komplett löschen und neu anlegen.
Ich hoffe das ist nun besser beschrieben!
Gruß,
sippi
Moin sippiseincousin (oder sippi selbst?),
na ja, ein bisschen klarer ist es schon... aber so richtig appetitlich hört es sich für mich noch nicht an.
Kann aber daran liegen, dass es das wohl nicht ist.
Entscheidend für die Frage, welche Strategie du wählen kannst sind doch zwei (und eine halbe) Rahmenbedingungen:
Dann bleibt doch die Frage, ob die (erstrebenswerte) Datenkonsistenz auf dem Clone-System auch von der DB getragen wird.
Gibt es denn dort auch ForeignKeys, Constraints, Master und Child-Beziehungen auf DB-Ebene?
Oder stehen dort die Tabellen "einzeln" rum wie Excel-Tabellen?
Ich hoffe, dass es nicht so ist...das würde aber bedeuten, dass du durchaus die 2 Tabellen komplett als Datenklumpen austauschen kannst (Load/Unload oder auch die "SELECT From Original Into Fälschung"-Variante .> ABER du musst davor sinnvollerweise alle PKs/FKs/Constraints DROPpen oder deaktivieren und hinterher neu aufbauen. Oder über ein ETL-Tool machen lassen.
Anyway --> alle diese Varianten stellen aus meiner Sicht keine alltagstaugliche Synchronität sicher... die laufen halt zeitgesteuert .> einmal am Tag oder alle 6 Stunden... aber nicht alle 2 Minuten.
Und zumindest auf der Clone-DB ist ein ein volkswirtschaftlich kaum zu vertretenes Gerödel.
Und du musst letzten Endes nur unterstützt von deiner Gewissenhaftigkeit und einer Checkliste sicherstellen, dass auch alle Strukturen und Relationen und Constraints auf Test und Clone identisch sind/bleiben.
Sinnvoller wäre aber m.E schon ein Replikations-Lösung ODER aber ein Synchronhalten über Trigger auf den Prod-Tabellen, die die Clone-Tabelle aktualisieren oder aber eine Lösung über Data Capture ... also eine Lösung, die bei der Änderung eines Datensatzes greift.
--> grenzen wir es anders ein:
Grüße
Biber
na ja, ein bisschen klarer ist es schon... aber so richtig appetitlich hört es sich für mich noch nicht an.
Kann aber daran liegen, dass es das wohl nicht ist.
Entscheidend für die Frage, welche Strategie du wählen kannst sind doch zwei (und eine halbe) Rahmenbedingungen:
- die Quelle (das Prod-System) soll möglichst wenig belastet werden, deshalb keine Replikation
- im Ziel sollen Daten verglichen mit dem Prod-System aber "möglichst zeitnah synchron sein"
- (die halbe) wobei eine der drei Tabellen ...tja eingefroren? statisch? uninteressant? ist und nicht aktualisiert werden soll.---> wieso das Heu frisst/Aufwand macht ist mir nicht klar.
Dann bleibt doch die Frage, ob die (erstrebenswerte) Datenkonsistenz auf dem Clone-System auch von der DB getragen wird.
Gibt es denn dort auch ForeignKeys, Constraints, Master und Child-Beziehungen auf DB-Ebene?
Oder stehen dort die Tabellen "einzeln" rum wie Excel-Tabellen?
Ich hoffe, dass es nicht so ist...das würde aber bedeuten, dass du durchaus die 2 Tabellen komplett als Datenklumpen austauschen kannst (Load/Unload oder auch die "SELECT From Original Into Fälschung"-Variante .> ABER du musst davor sinnvollerweise alle PKs/FKs/Constraints DROPpen oder deaktivieren und hinterher neu aufbauen. Oder über ein ETL-Tool machen lassen.
Anyway --> alle diese Varianten stellen aus meiner Sicht keine alltagstaugliche Synchronität sicher... die laufen halt zeitgesteuert .> einmal am Tag oder alle 6 Stunden... aber nicht alle 2 Minuten.
Und zumindest auf der Clone-DB ist ein ein volkswirtschaftlich kaum zu vertretenes Gerödel.
Und du musst letzten Endes nur unterstützt von deiner Gewissenhaftigkeit und einer Checkliste sicherstellen, dass auch alle Strukturen und Relationen und Constraints auf Test und Clone identisch sind/bleiben.
Sinnvoller wäre aber m.E schon ein Replikations-Lösung ODER aber ein Synchronhalten über Trigger auf den Prod-Tabellen, die die Clone-Tabelle aktualisieren oder aber eine Lösung über Data Capture ... also eine Lösung, die bei der Änderung eines Datensatzes greift.
--> grenzen wir es anders ein:
- Welchen Charakter/welche Priorität hat diese Aufgabe? Wird die Notwendigkeit einer "Synchronität" und eines "Notfallsystems" von der GL mitgetragen, auch Budgetmäßig?
- Oder lassen es alle drauf ankommen, dass ggf. die Daten der letzten x Stunden bei einem Abrauchen des Prod-Systems verloren sind?
- Oder bist du gar der einzige in der Firma, der es überhaupt weiß?
Grüße
Biber
