Ich habe einen gut vernetzten Remote-Standort, an den ich zweimal täglich Snapshots bestimmter Tabellen liefere. Aufgrund der Schemabeschränkungen der zugrunde liegenden Anwendung ist die Snapshot-Replikation die einzige Methode, die ich verwenden kann.
Der Snapshot wird über den UNC-Pfad und FTP veröffentlicht und ist mit etwa 6 MB ziemlich klein. Ich bin mir nicht 100 % sicher, ob tatsächlich FTP oder UNC verwendet wird. Es dauert etwa 5 Minuten von der Komprimierung des Snapshots in die Datei snapshot.cab bis zu dem Zeitpunkt, an dem mir der Replikationsmonitor das erste der angewendeten Skripts anzeigt. Ich gehe also davon aus, dass diese Lücke die Übertragungszeit ist. Ich denke, es liegt an UNC/SMB, da es viel weniger Zeit in Anspruch nimmt, so viele Daten über unsere 3-MB-Verbindung per FTP zu kopieren.
Das Laden des Snapshots dauert etwa 25 Minuten länger, was für eine bescheidene Datenmenge viel Zeit zu sein scheint. Viele Zeilen (mehrere Tabellen haben 100.000 Zeilen), aber die tatsächliche Datenmenge ist ziemlich gering.
Der Abonnent verwendet SQLExpress 2005 auf einem 2,8 GHz ProLiant mit 3 GB RAM, der ansonsten nicht ausgelastet ist. Ich habe noch keine ausführliche Profilerstellung durchgeführt, um zu sehen, ob es Festplattenkonflikte gibt oder was sonst los sein könnte.
Ich frage mich, was hier wahrscheinlich der Geschwindigkeitsbegrenzer ist und ob es eine Möglichkeit gibt, dies überhaupt zu beschleunigen. 30 Minuten zum Kopieren und Laden von 6 MB komprimierter Daten scheinen lange zu sein.
Antwort1
Da Sie SQL Express auf der Remote-Seite haben, sind Ihre Optionen ziemlich begrenzt, da Sie nur ein Push-Abonnement durchführen können.
Die Replikation funktioniert so, dass die Daten per BCP in eine Binärdatei übertragen werden. Wenn der Replikationsagent erkennt, dass der Snapshot fertig ist, verwendet er BCP, um die Daten über das Netzwerk in den Abonnenten zu laden. BCP über das Netzwerk ist nicht gerade der schnellste Prozess überhaupt.