Tabellen syncronisieren II

tbillen

Benutzer
Beiträge
5
Hallo zusammen,

nachdem ich beim googlen keinen Erfolg hatte und nicht den passen Thread gefunden habe, versuche ich mein Problem in diesem Thread zu beschreiben:

Ich habe 2 Server auf denen jeweils eine MS SQL Instanz laufen. Nun muss ich bestimmten von einem Server auf den anderen syncroniseren (Jeweils einmal am Tag muss dieser Abgleich stattfinden). Dazu habe ich mir folgendes Query zusammengebaut (Da hatte mir Google wirklich geholfen):
Code:
DELETE FROM [ZielDB].[DBO].[Tabelle];
INSERT INTO [ZielDB].[DBO].[ZielTabelle] SELECT * FROM OPENQUERY(Verbindung, 'SELECT * FROM [AusgangsDB].[DBO].[Tabelle]') WHERE ...

Diese Statements funktionieren soweit auch ganz gut. Die Tabellen die ich auf dieser Weise "syncronisere" sind extakt gleich, sodass ich sie hier einfach nur [Tabelle] genannt habe. Durch das WHERE Statement werden nur die interessanten Daten übertragen (Da die WHERE Statements immer unterschiedlich sind, habe ich sie hier mit ... gekennzeichnet).

Meine Frage an euch ist:
1. Ist dieses Vorgehen optimal oder kann man das noch optimieren (Laufzeiten von >10 sec. für <100k Datensätze ist keine Seltenheit)?
2. Diese Quieres werden über die Windows Aufgabenplanung angetriggert, in die Aufgabenplanung ein entsprechendes PHP Script mit diesen Quieres ausführt. Gibt es hier eine bessere Lösung?
3. Kann man eine solche Sysncroniserung nicht direkt durchführen? (Leider habe ich beim SMSS keine solche Funktion gefunden.)

Ich hoffe, ihr könnt mir eine Antwort auf meine Fragen geben.

Viele Grüße und Glückauf

Tobias Billen
 
Werbung:
Die Laufzeit hängt von verschiedenen Dingen ab:
a) Bandbreite
b) Select - Zeit und - Komplexität
c) Treiberqualität
d) Remote Server Last

b) ist u.U. ein nicht triviales Optimierungsproblem, sobald Joins zwischen lokalen und remoten Mengen durchgeführt werden. So oder so, auch eine langweilige Remote Where Condition muss erstmal alles selektieren. Eine Aggregation bspw. überträgt im Extremfall nur sehr wenig Daten, aber scant dafür ein Vielfaches an Daten durch.
c) Schau Dir mal "Linked Server" an, das ist vielleicht "nativer" als Dein Ansatz und meistert daher verschiedene Klippen besser.
 
@dabadepdu Danke für deine Antwort.

Zu den Laufzeitabhängigkeit: Auf die Hardware habe ich keinen Einfluss und die Queries sind dahingehend ausgelegt, dass andere User ohne großem Delay Daten abrufen können.

Was meinst du mit
"Eine Aggregation bspw. überträgt im Extremfall nur sehr wenig Daten, aber scant dafür ein Vielfaches an Daten durch. "? Gibt es hier ein Datenlimit oder wird die Last nur größer?

Edit:
"Verbindung" ist mein Linked Server.
 
Zuletzt bearbeitet:
Ich kenne keine Limits dieser Systeme, es gibt aber sicher welche in weiter Ferne. Das meinte ich aber nicht.

Gegenfrage, was bedeutet "die Querries sind dahingehend ausgelegt, ohne großes Delay"? Ist das ein Design/Entwurf für den es bereits evidentes Verhalten gibt? Oder gibt es lediglich lokale Tests, die schnell sind? Oder gibt es nur die Anforderung und gewissenhaften Entwurf?

"Linked Server": Ich bin kein MS SQL Fan oder Spezialist, aber
"Select *from <LinkedServer>.DB.Table"
ist/macht etwas anderes als
"SELECT * FROM OPENQUERY(<LinkedServer>, 'SELECT * FROM.."
Dazu nochmal 2 Überlegungen:
1 Ein Datenbanklink unter gleichartigen oder sogar identischen Systemen (gleicher Hersteller) kann vielleicht besser aufgebaut/ abgewickelt werden, als ein Link unter Fremdsystemen. Entsprechende Verfahren würde ich bevorzugen.
2 Wie schon in der ersten Antwort angedeutet. Die Größe der Antwortmenge hat nichts mit der Komplexität der Abfrage und ihrer Laufzeit zu tun. Das gilt bereits ohne Linked Server. Mit gilt es um so mehr.

Keine Ahnung, ob der Optimizer es kann, aber Du kannst ja mal ein EXPLAIN auf die unterschiedlichen LinkedServer Varianten absetzen.
 
Hallo

1. Ist dieses Vorgehen optimal oder kann man das noch optimieren (Laufzeiten von >10 sec. für <100k Datensätze ist keine Seltenheit)?
Das ganze klingt für mich wie die Übertragung von Daten zu Auswertungszwecken.
Handelt es sich nur um Tagesdaten? Dann stellt sich die Frage ob es
a) nicht effizienter wäre beim Schreiben die Daten in beiden Datenbanken zu ändern/ergänzen statt immer alle Daten zu übertragen.
b) Nachträglich nur Änderungen zu übertragen.​

2. SQL Agent
 
Werbung:
Hallo Tobias,

der Einsatz eines "Linked Server" ist aus Performance-Gründen nicht unbedingt empfehlenswert.
In einigen Firmen wird der Einsatz dieser Verbindungen aus Sicherheitsgründen sogar untersagt (nicht nötig - meiner Meinung nach - alles eine Frage der richtigen Konfiguration - aber anderes Thema).

Deine Beschreibung habe ich so verstanden, dass diese Daten-Synchronisation nur einmal am Tag vorgenommen werden muss, eine Synchronisation während des laufenden Betriebs also nicht gefordert ist.
Auf der sicheren Seite bei einer solchen Anforderung ist man bei Einsatz des SSIS (SQL Server Integration Service).
Der muss allerdings eingerichtet und Konfiguriert werden, bevor man diesen nutzen kann (Installation, Konfiguration, SSIS-Catalog erstellen).
Auch wird die Programmierung sogenannter "SSIS-Pakete" nicht im Management Studio sondern in Visual Studio vorgenommen und man muss sich hier natürlich auch das Wissen über die Programmierung solcher Pakete aneignen.
(Hier gibt es die DataTools, die entsprechende Umgebungen mitbringen)
Ein paar zusätzliche Hinweise gibt es hier: Installieren von SQL Server Integration Services - SQL Server Integration Services (SSIS)

Der SSIS ist für Anforderungen von Datenübertragungen über Instanz-Grenzen hinweg aber die gängige Praxis. Auch ich würde das hier empfehlen.
Es ist zwar erst mal etwas mehr Aufwand, die Techniken an den Start zu bekommen, aber es ist stabiler und auch performanter.
Auch die Programmierung von SSIS-Paketen ist sehr einfach, besonders wenn es nur um die 1:1-Übertragung von Daten geht.

Für einen regelmäßige wiederholte und automatisch gestartete Ausführung der Datenübertragung benutzt man sinnvollerweise des SQL Server Agent.
Hier können Ausführungs-Sequenzen festgelegt und automatisierte Ausführungen durch einen hinterlegten Zeitplan gesteuert werden.

Den SQL Server Agent und auch den Integration Service gibt es aber nur in höheren Versionen, der SQL Server Express bringt diesen nicht mit!

Die Hinweise von MDDaniel sind gut. Wenn man auf Performance achten muss, ist ein so genannter Delta-Load (also nur geänderte Daten übertragen) sehr hilfreich.
Wenn man trotzdem immer alle Daten 1:1 übertragen möchte, dann solltest du die Ziel-Tabelle aber nicht mit einem DELETE sondern mit einem TRUNCATE leeren - das geht schneller und setzt auch gleich die Zieltabelle komplett zurück. (Speicher-Reservierungen, Identity-Spalten etc.)

Viele Grüße,
Tommi
 
Zurück
Oben