MSSQL Datenbank in eine MYSQL Datenbank mehrmals Täglich synchronisieren

Hallo zusammen,

evtl. kann mir wer weiterhelfen. Ich stehe vor folgender Herausforderung. Ich müsste unsere 150GB große WAWI Datenbank welche auf unseren Internen Microsoft SQL Server 2016 liegt in eine extern gehostete MYSQL Datenbank synchronisieren.

Beim ersten lauf soll einmal die komplette Datenbank synchronisiert werden und danach 3 mal täglich nur immer Änderungen.

Kennt jemand eine gute Software? Musst nicht unbedingt eine Freeware sein.

Getestet aber eher unzufrieden bin ich bis jetzt von folgender Software.

- DBMoto (da man für jede Tabelle eine einen eigenen Replikationsjob anlegen muss, sehr sehr aufwendig bei mehreren Tabellen)
- DBSync for MSSQL & MySQL (Software stürzt immer wieder ab)

ich wäre sehr dankbar für eure Hilfe.

Vorab besten Dank

Viele Grüße
Tom

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 356363

Url: https://administrator.de/contentid/356363

Ausgedruckt am: 22.11.2024 um 19:11 Uhr

10 Kommentare

Neuester Kommentar

Moin,

mal abgesehen von der techn. Machbarkeit:
Weshelb wollt ihr täglich den Bestand in eine andere Hersteller-Datenbank kopieren?

Einfach nur, damit ihr die Daten als Backup irgendwo liegen habt oder greift da am Ende eine andere Applikation auf ALLE Daten des ERPs zu?
Oder wollt ihr einfach nur Teile der Daten für z.B. einen WebShop (oder was auch immer) bereit stellen?

Weshalb frage ich:
Ich persönlich empfinde es als ziemlich aufwendig, Daten von einer MS-DB zu einer MySQL-DB zu kopieren, da ja alles brücksichtigt werden muss: Primärschlüssel, Fremdschlüssel, etwaige Views, irgendwelche Trigger....
Das reine Kopieren von Tabellendaten bringt es ja nicht alleine...

Und was passiert, wenn der ERP-Hersteller mal ein Update einspielt und die Tabellenstruktur dabei anpasst (nicht selten, sowas)

Wenn allerdings nur bestimmte Daten bereitgestellt werden sollen, könnte man über eine Export/ Import der Daten nachdenken....
Auf Seiten der MySQL-DB entsprechende DB-Layouts und Schlüsselbeziehungen erstellen, und dann halt die Daten entsprechend von MS nach MySQL in Form von zuvor erzeugten Views kopieren.
Hat den Vorteil: ändert sich an der DB-Struktur der Quelle etwas, muss nur die View angepasst werden, nicht aber die gesamte Schnittstelle...

Gruß
em-pie

Hallo em-pie,

vielen Dank für deine schnelle Antwort. Unsere Webshop Entwickler benötigen die Daten in einer MYSQL Datenbank um diese auszuwerten und weiterzuverarbeiten.

Am liebsten wäre mir wirkliche eine Software welche einfach die Tabellen nacheinander konvertiert und synchronisiert.

Viele Grüße
Tom

Moin,

Unsere Webshop Entwickler benötigen die Daten in einer MYSQL Datenbank um diese auszuwerten und weiterzuverarbeiten.

Aber doch sicher nicht die kompletten 150GB, oder?

Da würde ich, wie von em-pie vorgeschlagen, Views basteln und die dann per MSSQL-Tasks (via DTC Paket, wenn ich mich recht erinnere) oder notfalls per Python/PHP/Perl/Whatever und ODBC Anbindung von A nach B transportieren lassen.

Soll die Ziel-DB vom öffentlichen Web aus zugreifbar sein? Dann ist eine 1:1 Kopier des ERPs sowieso ein NoGo

lg,
Slainte

Hallo Slainte,

danke für deine Hilfe. Nein also die komplette Datenbank wird nicht benötigt aber doch einige Tabellen. Ich werde mich mal mit dem Thema Views erstellen auseinander setzen.

Danke schön

VG
Tom

Ich will dir eurer Vorhaben nicht kaputt reden. Eher im Gegenteil.

Überlege dir, was das bedeutet, wenn ihr "blind" alles 1:1 kopiert:
Wenn ihr in den Webshop alle ERP-Daten reinschaufelt, sind dort auch eure Lieferanten, Artikel-Lieferantenbeziehungen sowie Einkaufspreise, Konditionen etc. enthalten. Von sämtlichen Rechnungsdaten mal abgesehen (Gut, ggf. sollen die zum Großteil ja auch für Kunden einsehbar sein). Das gilt dann auch für Produkte/ GEschäftsvorfälle, die ihr für den Eigenbedarf einkauft. Das können Bleistifte/ Klopapierrollen aber auch (je nach Unternehmen/ ERP) Investitionsgüter wie Fahrzeuge/ Server, etc. sein...
Nicht auszumalen, was passiert, wenn die Daten mal einen anderen Interessenten finden...
Hinzu kommen vermutlich noch zig ERP-interne Kenner, die für externe Applikationen vermutlich irrelevant sind.

Seit ihr reiner Handel oder auch produzierendes Gewerbe?
Wenn letzteres: Interessieren den Webshop die ganzen Zwischenprodukte /Baugruppen und dessen Lagerbestände!?

Ich persönlich würde da nur das reinschieben, was tatsächlich benöltigt wird und schon sind es keine 150GB mehr sondern vermutlich nur noch 30 GB (k.A., Zahlen mal ausgedacht)...

Zu einem guten Konzept gehört immer ein Lasten und Pflichtenheft. Indem steht genau drin, welche Daten von wem benötigt werden/ wer die Daten wie bereitstellt. Und nicht mehr und nicht weniger würde ich dann entsprechend austauschen...

Hallo!

Ich will auch noch einen Gedanken einwerfen:

Warum macht ihr bei eurer MSSQL-DB nicht einen neuen User für den Webshop und vergebt entsprechende Berechtigungen, damit dieser via Web Zugriff hat.

Selbst von PHP/PERL kann man auf MSSQL-Datenbanken zugreifen und damit arbeiten.

Somit muss nichts "außer Haus" gegeben und synchronisiert werden.

Gruß
eisbein

Edit: Wenn der Web-Entwickler keinen Zugriff auf MSSQL zustande bringt, dann habt ihr den falschen Fisch an der Angel