5
MS SQL 2005 - 2 DB Synchronisieren
2 DBs Synchronisieren
Hallo ich habe eine MS SQL 2005 DB mit dem aktuellsten Stand nun wurde mir mitgeteilt das Daten aus dem Letzten Monat fehlen (sehr viele)
Nun habe ich ein Backup wieder hergestellt unter einem anderen Namen sprich:
DB1 = Firma (aktuell)
DB2 = Firma2 (stand mit fehlenden Daten altes Datum)
nun möchte ich DB1 und DB2 Synchronisieren das er die alten Daten wieder einspielt die in der DB1 fehlen.
wie kann ich das bei MS SQL 2005 Server Management Studio Express am besten machen???
Bin auch nicht so ein perfekter kenner in SQL deshalb möglichst genau erklären.
Danke schon mal
Hallo ich habe eine MS SQL 2005 DB mit dem aktuellsten Stand nun wurde mir mitgeteilt das Daten aus dem Letzten Monat fehlen (sehr viele)
Nun habe ich ein Backup wieder hergestellt unter einem anderen Namen sprich:
DB1 = Firma (aktuell)
DB2 = Firma2 (stand mit fehlenden Daten altes Datum)
nun möchte ich DB1 und DB2 Synchronisieren das er die alten Daten wieder einspielt die in der DB1 fehlen.
wie kann ich das bei MS SQL 2005 Server Management Studio Express am besten machen???
Bin auch nicht so ein perfekter kenner in SQL deshalb möglichst genau erklären.
Danke schon mal
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: 120424
Url: https://administrator.de/forum/ms-sql-2005-2-db-synchronisieren-120424.html
Ausgedruckt am: 21.04.2025 um 23:04 Uhr
5 Kommentare
Neuester Kommentar
Hi,
MS SQL 2005 Server Management Studio Express hat eine solche Funktion meines Wissens nach nicht.
Das wäre auch nicht so einfach. Stell dir vor wenn in der Zwischenzeit alte Einträge wieder gelöscht worden wären. Diese hättest du ja danach wieder. Also totale Unordnung und Chaos wäre die Folge. Wenn es sich nur um eine Tabelle handelt, wovon ich nicht ausgehe, dann schreibe ich dir gerne ein paar Zeilen Code in C# oder PHP, doch da müsstest du schon genauer sagen wie die Tabellenstruktur ist, ob gelöschte Eintrage als gelöscht markiert werden oder ob sie endgültig gelöscht werden, ob es ein Feld gibt dort wo das Änderungsdatum eingetragen wird usw.
Doch wie gesagt, sollte es sich hierbei um einige Tabellen handeln dann wird das sehr schnell aufwändig.
Grüße Michael.
MS SQL 2005 Server Management Studio Express hat eine solche Funktion meines Wissens nach nicht.
Das wäre auch nicht so einfach. Stell dir vor wenn in der Zwischenzeit alte Einträge wieder gelöscht worden wären. Diese hättest du ja danach wieder. Also totale Unordnung und Chaos wäre die Folge. Wenn es sich nur um eine Tabelle handelt, wovon ich nicht ausgehe, dann schreibe ich dir gerne ein paar Zeilen Code in C# oder PHP, doch da müsstest du schon genauer sagen wie die Tabellenstruktur ist, ob gelöschte Eintrage als gelöscht markiert werden oder ob sie endgültig gelöscht werden, ob es ein Feld gibt dort wo das Änderungsdatum eingetragen wird usw.
Doch wie gesagt, sollte es sich hierbei um einige Tabellen handeln dann wird das sehr schnell aufwändig.
Grüße Michael.
gelöscht wird nix in der Tabelle da es sich um Lieferscheine handelt ich bin mir auch nicht 100%ig sicher das es nur eine Tabelle ist oder ob es meherere betrifft ich weiss nur das alle Daten die in der aktuellen DB nicht drin sind wieder rein müssen.
Moin Dipps,
Du bist momentan auf einem falschen (und gefährlichen) Weg.
Das, was Du so scherzhaft als "Synchronisieren" bezeichnest, gibt es im Kontext EINER einzelnen Datenbank nicht.
Du meinst Recovery, und dafür stehen Dir, wenn wir mal die Schnörkel weglassen, zwei Alternativen offen.
Du hast zwei jeweils in sich konsistente Datenbestände
und kannst jetzt nur
Was Du davon kannst oder gar automatisieren kannst hängt ab vom Vorhandensein der Transaktionslogs.
Danach musst Du als erstes fahnden.
Erst wenn sich herausstellt, das jegliche Transaktionssicherheit und jegliche Backup/Recovery-Strategie in dieser Firma (oder bei dieser Privatperson) restlos verschnarcht wurde, dann ließe sich überlegen, dieses vorhandene Backup auf einer anderen DB-Instanz einzuspielen und mittels ein, zwei PraktikantInnen die dort vorhandenen (und in der heutigen Version fehlenden) Lieferscheine rauszulutschen.
Und in die "aktuelle" DB-Instanz per Import oder per Insert-Statements zu schaufeln.
Aber wenn es denn Lieferscheine sind (also vermutlich eine generierte Beleg-Nummer), dann wirst Du für diesen Ferienjob schon mehr als 7 Euro Stundenlohn ausloben müssen... das wird frickelig.
Denn dann hast Du mehrfach die gleiche Lieferscheinnummer mit unterschiedlichen Inhalten.
Wie um Himmels willen konnten denn "viele" Lieferscheine gelöscht werden?
Menschliches Versagen?
Grüße
Biber
Du bist momentan auf einem falschen (und gefährlichen) Weg.
Das, was Du so scherzhaft als "Synchronisieren" bezeichnest, gibt es im Kontext EINER einzelnen Datenbank nicht.
Du meinst Recovery, und dafür stehen Dir, wenn wir mal die Schnörkel weglassen, zwei Alternativen offen.
Du hast zwei jeweils in sich konsistente Datenbestände
- den des letzten Full Backups, meinetwegen den 14 Tage alten Stand
- den heutigen Tabellenstand
und kannst jetzt nur
- entweder zurück auf den Stand von vor 14 Tagen und alle Transaktionen, die seitdem gelaufen sind nochmalig drüberlaufen lassen (natürlich "alle" außer dem versehentlichen Löschen der Lieferscheine)
- oder aber vom heutigen Stand ausgehen und alle Transaktionen rückgängig machen, die in den letzten 2 oder 6 oder 14 Tagen gelaufen sind... je nachdem, wie weit Du zurück musst.
Was Du davon kannst oder gar automatisieren kannst hängt ab vom Vorhandensein der Transaktionslogs.
Danach musst Du als erstes fahnden.
Erst wenn sich herausstellt, das jegliche Transaktionssicherheit und jegliche Backup/Recovery-Strategie in dieser Firma (oder bei dieser Privatperson) restlos verschnarcht wurde, dann ließe sich überlegen, dieses vorhandene Backup auf einer anderen DB-Instanz einzuspielen und mittels ein, zwei PraktikantInnen die dort vorhandenen (und in der heutigen Version fehlenden) Lieferscheine rauszulutschen.
Und in die "aktuelle" DB-Instanz per Import oder per Insert-Statements zu schaufeln.
Aber wenn es denn Lieferscheine sind (also vermutlich eine generierte Beleg-Nummer), dann wirst Du für diesen Ferienjob schon mehr als 7 Euro Stundenlohn ausloben müssen... das wird frickelig.
Denn dann hast Du mehrfach die gleiche Lieferscheinnummer mit unterschiedlichen Inhalten.
Wie um Himmels willen konnten denn "viele" Lieferscheine gelöscht werden?
Menschliches Versagen?
Grüße
Biber
Moin,
Biber hat zu 100% Recht
Meine Erfahrung hat allerdings gezeigt, das verschwundene Daten, nicht immer wirklich verschwunden sind
Wie wurde denn festgestellt, das Daten aus den Vormonat(en) verschwunden sind? Hast Du per SELECT mal überprüft ob die Daten auch wirklich nicht mehr da sind? Evtl. wurde auch nur ein Kunde/Verkaufsgebiet geändert/verschoben/umbenannt o.Ä.
Und Nebenbei: Eine WaWi die das löschen von Lieferschein-Datensätzen erlaubt gehört verbotenm da kannst Du dann gleich Excel benutzen
lg,
Slainte
Biber hat zu 100% Recht
Meine Erfahrung hat allerdings gezeigt, das verschwundene Daten, nicht immer wirklich verschwunden sind
Wie wurde denn festgestellt, das Daten aus den Vormonat(en) verschwunden sind? Hast Du per SELECT mal überprüft ob die Daten auch wirklich nicht mehr da sind? Evtl. wurde auch nur ein Kunde/Verkaufsgebiet geändert/verschoben/umbenannt o.Ä.
Und Nebenbei: Eine WaWi die das löschen von Lieferschein-Datensätzen erlaubt gehört verbotenm da kannst Du dann gleich Excel benutzen
lg,
Slainte
Moin Dipps,
also gleich zu Anfang: ganz so schwarz wie meine Vorredner sehe ich die Sache nicht
Aber bei den Aussagen, die Du gemacht hast, kann ich Dir nur abraten, selber Hand anzulegen.
Voraussetzung für die Wiederherstellung ist eine exakte Kenntnis der Datenstruktur.
Außerdem mußt Du natürlich auch genau wissen, was fehlt. Wenn wirklich nur ein paar DS fehlen und keine Vermischung aus alten und neuen DS stattgefunden hat (z.B. daß eine Lieferscheinnummer neu vergeben wurde), dann könnte es möglich sein, die Daten einfach zu übertragen.
Und drittens brauchst Du auch ordentliche SQL-Kenntnisse. Ohne die wirst Du auch kaum sicher die beiden anderen Punkte erfüllen können.
Auf jeden Fall stimme ich Slainte zu, daß scheinbar verschwundene Daten oft noch da sind. Hat jemand vielleicht die Lieferscheine archiviert, daß da vielleicht ein Flag gesetzt wurde und sie dadurch in der Standardansicht nicht mehr auftauchen? Oder in eine andere Tabelle verschoben worden sind?
Ein guter Ansprechpartner für Dein Anliegen, sei es, daß die Daten nur versteckt sind oder wirklich verschwunden, ist in jedem Fall der Hersteller des Programms. Im Idealfall kennt der die Strukturen und hat auch ausreichende Kenntnisse, die Daten zu analysieren und ggf. direkt auf der DB zu manipulieren.
Gruß, Mad Max
also gleich zu Anfang: ganz so schwarz wie meine Vorredner sehe ich die Sache nicht
Aber bei den Aussagen, die Du gemacht hast, kann ich Dir nur abraten, selber Hand anzulegen.
Voraussetzung für die Wiederherstellung ist eine exakte Kenntnis der Datenstruktur.
Außerdem mußt Du natürlich auch genau wissen, was fehlt. Wenn wirklich nur ein paar DS fehlen und keine Vermischung aus alten und neuen DS stattgefunden hat (z.B. daß eine Lieferscheinnummer neu vergeben wurde), dann könnte es möglich sein, die Daten einfach zu übertragen.
Und drittens brauchst Du auch ordentliche SQL-Kenntnisse. Ohne die wirst Du auch kaum sicher die beiden anderen Punkte erfüllen können.
Auf jeden Fall stimme ich Slainte zu, daß scheinbar verschwundene Daten oft noch da sind. Hat jemand vielleicht die Lieferscheine archiviert, daß da vielleicht ein Flag gesetzt wurde und sie dadurch in der Standardansicht nicht mehr auftauchen? Oder in eine andere Tabelle verschoben worden sind?
Ein guter Ansprechpartner für Dein Anliegen, sei es, daß die Daten nur versteckt sind oder wirklich verschwunden, ist in jedem Fall der Hersteller des Programms. Im Idealfall kennt der die Strukturen und hat auch ausreichende Kenntnisse, die Daten zu analysieren und ggf. direkt auf der DB zu manipulieren.
Gruß, Mad Max
