7
Migration von Daten aus Datenbank1 in Datenbank2 (MS SQL 2012)
Hallo,
ich möchte die Daten der Datenbank von Kunde1 in die Datenbank von Kunde2 überführen da diese miteinander fusioniert haben.
Die Datenbanken sind abgesehen von den Tabelleninhalten (Daten) identisch.
Weiterhin wurde beim Aufsetzen der Datenbanken bereits berücksichtigt, die Id's der Tabelle eindeutig zu halten,
d.h. die Id's sind BIGINT Werte deren Anfangswerte mit z.B. 111110000000001 oder mit z.B. 222220000000001 beginnen,
um genau diesen Fall leichter händeln zu können.
Wie muss das Ganze durchgeführt werden ?
Möglichkeit 1: Mit dem Assistenten aus MSSQL ?
Möglichkeit 2: Per Skript
Zu 1:
Funktioniert das mit den ForeignKeys automatisch oder muss da irgendwas gemacht werden.
Wie schaut es mit dem IdentyInsert aus ?
Arbeitet der Assistent zuverlässig/problemlos ?
Zu 2:
Wenn ich die Übernahme der Daten aus allen Tabellenobjekte manuell skripte, müsste ich ja die Reihenfolge wegen den FK's beachten.
Weiterhin müsste ich den IdentyInsert jeweils Ein-und wieder Ausschalten.
Ich denke das ist recht aufwändig bei einer Datenbank von ca. 500 Tabellen.
Kann man die Abhägigkeiten per Select auf die z.b. SysObjects Tabelle ermitteln ?
Gibt es dazu evtl. schon ein Skript ?
Oder sollte ich einfach die FK-Prüfung vor dem Kopieren deaktivieren und danach wieder aktivieren ?
Eigentlich sollten die Datenbanken keine Fehler bei der FK-Prüfung aufweisen.
Oder gibt es eine andere Möglichkeit ?
Die Anschaffung eines kostenpflichtigen Migrationstool kommt leider nicht in Frage
Für Eure Tipps wäre ich sehr dankbar
ich möchte die Daten der Datenbank von Kunde1 in die Datenbank von Kunde2 überführen da diese miteinander fusioniert haben.
Die Datenbanken sind abgesehen von den Tabelleninhalten (Daten) identisch.
Weiterhin wurde beim Aufsetzen der Datenbanken bereits berücksichtigt, die Id's der Tabelle eindeutig zu halten,
d.h. die Id's sind BIGINT Werte deren Anfangswerte mit z.B. 111110000000001 oder mit z.B. 222220000000001 beginnen,
um genau diesen Fall leichter händeln zu können.
Wie muss das Ganze durchgeführt werden ?
Möglichkeit 1: Mit dem Assistenten aus MSSQL ?
Möglichkeit 2: Per Skript
Zu 1:
Funktioniert das mit den ForeignKeys automatisch oder muss da irgendwas gemacht werden.
Wie schaut es mit dem IdentyInsert aus ?
Arbeitet der Assistent zuverlässig/problemlos ?
Zu 2:
Wenn ich die Übernahme der Daten aus allen Tabellenobjekte manuell skripte, müsste ich ja die Reihenfolge wegen den FK's beachten.
Weiterhin müsste ich den IdentyInsert jeweils Ein-und wieder Ausschalten.
Ich denke das ist recht aufwändig bei einer Datenbank von ca. 500 Tabellen.
Kann man die Abhägigkeiten per Select auf die z.b. SysObjects Tabelle ermitteln ?
Gibt es dazu evtl. schon ein Skript ?
Oder sollte ich einfach die FK-Prüfung vor dem Kopieren deaktivieren und danach wieder aktivieren ?
Eigentlich sollten die Datenbanken keine Fehler bei der FK-Prüfung aufweisen.
Oder gibt es eine andere Möglichkeit ?
Die Anschaffung eines kostenpflichtigen Migrationstool kommt leider nicht in Frage
Für Eure Tipps wäre ich sehr dankbar
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 384215
Url: https://administrator.de/forum/migration-von-daten-aus-datenbank1-in-datenbank2-ms-sql-2012-384215.html
Ausgedruckt am: 23.12.2024 um 14:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
von Hand zu Fuß bietet es sich an, mittels scripting alle Constraints zu deaktivieren, Identity-Spalten zu ersetzen und die Daten zusammenzuführen. Danach sind selbige zu reaktivieren und zu prüfen.
Trigger sind ebenfalls zu deaktivieren für den Merge / Insert.
Die Reihenfolge der Tabellen ist in diesem Falle egal, sofern alle PK/FK über beide Dbs eindeutig sind.
Ob dies Sinn macht, ist was anderes denn folgendes gilt es zu berücksichtigen:
Tools zur Synchronisation von DML und DDL gibt es einige und die, die wir verwenden, haben eine vollumfängliche 14 Tage Trial.
Implizite Annahmen im Sinne von "in jedem Fall identisches DDL" würde ich grundsätzlich in Frage stellen / prüfen und mir auch die Businesslogik ansehen. Es sei denn, ich bin nur Ausführungsgehilfe und muss den Müll nicht verantworten, der dabei raus kommt.
Wenn noch nicht einmal 0.5k€ zur Verfügung stehen (Lizenz für einen User für ein Tool vom Marktführer zum Vergleichen der SQL Daten), sind entweder die Firmen winzig oder der Entscheider inkompetent - kann auch beides zutreffen.
Die Zeitersparnis des Ausführungsgehilfen alleine sollte schon mehr Wert sein.
Gruß
Grinskeks
von Hand zu Fuß bietet es sich an, mittels scripting alle Constraints zu deaktivieren, Identity-Spalten zu ersetzen und die Daten zusammenzuführen. Danach sind selbige zu reaktivieren und zu prüfen.
Trigger sind ebenfalls zu deaktivieren für den Merge / Insert.
Die Reihenfolge der Tabellen ist in diesem Falle egal, sofern alle PK/FK über beide Dbs eindeutig sind.
Ob dies Sinn macht, ist was anderes denn folgendes gilt es zu berücksichtigen:
- Gibt es Konflikte in der Datenhaltung (z.B. Kundennummern überschneiden sich)
- Sind Redundanzen zu beachten oder gibt es gemeinsame Stammdaten, Verwaltungsdaten
- Sind Vorab die Daten von Kunde2 auf Kunde1 zu migrieren im Sinne einer Übernahme nach Business-Regeln?
- Wie gestaltet sich der Übergang, gibt es noch trennenswerte Informationen oder wie wird auseinandergehalten, was zu wem gehört(e)?
Tools zur Synchronisation von DML und DDL gibt es einige und die, die wir verwenden, haben eine vollumfängliche 14 Tage Trial.
Implizite Annahmen im Sinne von "in jedem Fall identisches DDL" würde ich grundsätzlich in Frage stellen / prüfen und mir auch die Businesslogik ansehen. Es sei denn, ich bin nur Ausführungsgehilfe und muss den Müll nicht verantworten, der dabei raus kommt.
Wenn noch nicht einmal 0.5k€ zur Verfügung stehen (Lizenz für einen User für ein Tool vom Marktführer zum Vergleichen der SQL Daten), sind entweder die Firmen winzig oder der Entscheider inkompetent - kann auch beides zutreffen.
Die Zeitersparnis des Ausführungsgehilfen alleine sollte schon mehr Wert sein.
Gruß
Grinskeks
Es geht alles, automatisch wirds nur immer kompliziert und manuell dauert es sehr sehr lange. Bei einer 500 Tabellen starken DB würde ich auch Geld für ein Tool oder Support in die Hand nehmen.
Sind das wirklich IDENTITY Spalten? Die solltest du nicht einfach abändern im Sinne von IDENTITY deaktivieren, dann muss die Tabelle meines Wissens nach neu erzeugt werden. Nutze:
https://www.mssqltips.com/sqlservertutorial/2521/insert-into-sql-server- ...
UNIQUEIDENTIFER hingegen sollten ziemlich problemlos sein und immer eindeutig. Da wirst du keine Probleme bekommen.
Welche IDs meinst du, auch die aller Unter- und Zwischentabellen?
Sind in der Datenbank selbst überhaupt FKs definiert? In vielen Fällen ist dem nicht so.
Sind das wirklich IDENTITY Spalten? Die solltest du nicht einfach abändern im Sinne von IDENTITY deaktivieren, dann muss die Tabelle meines Wissens nach neu erzeugt werden. Nutze:
https://www.mssqltips.com/sqlservertutorial/2521/insert-into-sql-server- ...
UNIQUEIDENTIFER hingegen sollten ziemlich problemlos sein und immer eindeutig. Da wirst du keine Probleme bekommen.
Welche IDs meinst du, auch die aller Unter- und Zwischentabellen?
Sind in der Datenbank selbst überhaupt FKs definiert? In vielen Fällen ist dem nicht so.
Vielen Dank für Deine ausführliche Antwort.
Der Hinweis mit den Triggern ist super.
Die hatte ich irgendwie nicht bedacht.
Die PK's sind alle Datenbankspezifisch.
Insofern eindeutig.
Die Stamm-/Verwaltungsdaten werden direkt nach der Zusammenführung vom Kunden neu geliefert.
Die Übernahme der "Alt-Daten" dient nur der Historisierung.
Das Auseinanderhalten der Daten ist an dem unterschiedlichen Aufbau der Id's in den Tabellen möglich.
Dies ist dann auch nur für die "Altdaten" relevant, weil dann die Unterscheidung "Wer zu Wem gehörte" obsolet ist.
Mein Problem ist das die Firma zu gross ist.
Bis da eine Entscheidung getroffen wird wie hoch das Budget ist und welches Tool eingesetzt werden soll...................
Bisher wurde alles immer selber programmiert.
Welches Tool würdest Du denn dafür vorschlagen bzw. mit welchem Tool hast Du gute Erfahrungen gemacht ?
Leider bin ich tatsächlich nur Ausführungsgehilfe der das Ganze dann trotzdem auch Verantworten muss.
Gruß
Stefan
Der Hinweis mit den Triggern ist super.
Die hatte ich irgendwie nicht bedacht.
Die PK's sind alle Datenbankspezifisch.
Insofern eindeutig.
Die Stamm-/Verwaltungsdaten werden direkt nach der Zusammenführung vom Kunden neu geliefert.
Die Übernahme der "Alt-Daten" dient nur der Historisierung.
Das Auseinanderhalten der Daten ist an dem unterschiedlichen Aufbau der Id's in den Tabellen möglich.
Dies ist dann auch nur für die "Altdaten" relevant, weil dann die Unterscheidung "Wer zu Wem gehörte" obsolet ist.
Mein Problem ist das die Firma zu gross ist.
Bis da eine Entscheidung getroffen wird wie hoch das Budget ist und welches Tool eingesetzt werden soll...................
Bisher wurde alles immer selber programmiert.
Welches Tool würdest Du denn dafür vorschlagen bzw. mit welchem Tool hast Du gute Erfahrungen gemacht ?
Leider bin ich tatsächlich nur Ausführungsgehilfe der das Ganze dann trotzdem auch Verantworten muss.
Gruß
Stefan
Zitat von @ukulele-7:
Es geht alles, automatisch wirds nur immer kompliziert und manuell dauert es sehr sehr lange. Bei einer 500 Tabellen starken DB würde ich auch Geld für ein Tool oder Support in die Hand nehmen.
Sind das wirklich IDENTITY Spalten? Die solltest du nicht einfach abändern im Sinne von IDENTITY deaktivieren, dann muss die Tabelle meines Wissens nach neu erzeugt werden. Nutze:
https://www.mssqltips.com/sqlservertutorial/2521/insert-into-sql-server- ...
UNIQUEIDENTIFER hingegen sollten ziemlich problemlos sein und immer eindeutig. Da wirst du keine Probleme bekommen.
Welche IDs meinst du, auch die aller Unter- und Zwischentabellen?
Sind in der Datenbank selbst überhaupt FKs definiert? In vielen Fällen ist dem nicht so.
Es geht alles, automatisch wirds nur immer kompliziert und manuell dauert es sehr sehr lange. Bei einer 500 Tabellen starken DB würde ich auch Geld für ein Tool oder Support in die Hand nehmen.
Sind das wirklich IDENTITY Spalten? Die solltest du nicht einfach abändern im Sinne von IDENTITY deaktivieren, dann muss die Tabelle meines Wissens nach neu erzeugt werden. Nutze:
https://www.mssqltips.com/sqlservertutorial/2521/insert-into-sql-server- ...
UNIQUEIDENTIFER hingegen sollten ziemlich problemlos sein und immer eindeutig. Da wirst du keine Probleme bekommen.
Welche IDs meinst du, auch die aller Unter- und Zwischentabellen?
Sind in der Datenbank selbst überhaupt FKs definiert? In vielen Fällen ist dem nicht so.
Wenn ich die Daten mit INSERT INTO einfüge ohne die FK's zu deaktivieren, müsste ich erst die Reihenfolge der Abarbeitung kennen.
Insofern war meine Frage auch, ob man das per Select auf die Systemtabellen herausfinden kann.
Nur Konfigurationstabellen (Listentabellen) haben ID's die bei 1 beginnen.
Diese sind bei Beiden Datenbanken identisch bzw. evtl. durch die Eine oder Andere erweitert.
Die Erweiterung des Eintrags hat dann allerdings wieder die eindeutige Id mit 111xxxxxx beginnend.
Auch hier sollte beim Kopieren keine Überschneidung stattfinden.
Natürlich gibt es eindeutige benannte FK's
Gruss
Stefan
Der Entscheider ist beliebig langsam - stimmt, kommt auch immer wieder vor 
PN mit dem Softwarelink ist raus - für die anderen: Google Suche nach SQL Data Compare.
Gruß
Grinskeks
PN mit dem Softwarelink ist raus - für die anderen: Google Suche nach SQL Data Compare.
Gruß
Grinskeks
Ja wenn es Foreign Key Constraints als solche denn auch in der DB gibt. Es ist häufig so das diese Beziehung zwischen den Tabellen zwar existiert, in der DB aber nicht definiert wurde. Guck dir mal deine Tabellen mit dem Management Studio an ob da unter Einschränkungen unter der Tabelle überhaupt Constraints enthalten sind. Ansonsten ist die Reihenfolge unerheblich, dann wird die Datenbank nicht meckern. Theoretisch kannst du die auch für den Import im Management Studio per Rechtsklick deaktivieren und er prüft dann erst nach dem Import aller Daten beim Aktivieren ob die Bedingung erfüllt ist.
So wie sich das ließt musst du eigentlich nur Copy Paste machen oder kannst dir tatsächlich auch selbst ein Script schreiben. Nur die Sache mit den Constraints ist etwas tricky.
So wie sich das ließt musst du eigentlich nur Copy Paste machen oder kannst dir tatsächlich auch selbst ein Script schreiben. Nur die Sache mit den Constraints ist etwas tricky.
"SQL Data Compare" schaut interessant aus.
Danke dafür
Danke dafür
