Ein Tool für Datenübertragungssituationen, das nur für theorische Zwecke erstellt wurde und möglicherweise nützlich sein kann, um eine große Datenmenge von einem SQL -Server (2000 oder höher) und/oder Oracle (10G oder höher) auf einen anderen (SQL> SQL, SQL> Oracle, Oracle> SQL und Oracle> Oracle) zu übertragen.
Es ist üblich, SQL Server und/oder Oracle -Tabellen von einer Instanz in eine andere zu kopieren.
Normalerweise entscheiden wir uns wahrscheinlich, den SSMS -Import/Export -Assistenten, ein Integration Services -Paket oder eine Methode zum Übertragen von Daten als Textdatei zu verwenden.
Es können jedoch Probleme auftreten, wenn wir über Tische mit mehr als 300 Millionen Datensätzen oder 30 GB und mehr sprechen, wenn sie in einer Mindestzeit kopiert werden müssen.
Wenn wir Glück haben, kann diese Tabelle einen Cluster -Index in SQL Server oder einen Index mit einem Frequenzhistogramm in Oracle haben. Das ist das Szenario, in dem dieses kleine Projekt eine Rolle spielt.
Wenn wir keinen Cluster -Index in der Quellentabelle haben, gibt es einige Hoffnung, haben wir eine neue Methode implementiert (etwas langsamer als Clustered, aber eine gute), um Daten aus einer Heap -Tabelle sowohl auf Oracle als auch auf SQL Server zu kopieren.
Seine Logik ist sehr einfach: Es scannt Clustered -Index -Statiten in SQL Server oder Histogramm in Oracle und definieren ausgeglichene Datencluster.
Dies bedeutet, dass so viele Abfragen wie die Threads parametrisiert werden, und diese Abfragen filtern auf dem Clustered -Index -Feld, das versucht, das gleiche Datenvolumen jeweils zu erhalten. Dann feuert es sie mit der SQLBulkCopy .NET FW oder OracleBulkcopy aus der ODP.NET -Methode ab. Als Haufen "partitionieren" die Tabelle mit einer determinikten Funktion und einem Modul (%% Lockres %% in SQL Server und Rowid in Oracle) und starten Sie jede Abfrage in einem Thread.
Wir müssen raten, dass es je nach Anzahl der Threads ein sehr ressourcenintensiver Prozess ist und in einigen Fällen der CPU -Verbrauch bis zu 100% steigen kann und die Länge der Scheibenwarteschlangen lange Wartezeiten verursachen kann.
Aus diesem Grund empfehlen wir, auf einem anderen Server als der Datenquelle und des Ziels auszuführen.
Somit haben wir mit einer Struktur von 2 Netzwerken mit zwei 100 -Mbit -Netzwerkkarten in jedem Server 190 MB/SEG -Übertragungsraten erreicht.
Sie sollten es für statistische Zwecke testen, bevor Sie darüber nachdenken, es in einer Produktionsumgebung zu verwenden.
Zusätzliche Anmerkungen: Der Leistungsgewinn wird unter bestimmten Zirkumntanzen erzielt, und manchmal wird er aufgrund der Art der Daten innerhalb der Cluster -Spalte nicht wahrgenommen. Zunächst muss klargestellt werden, dass der Clustered -Index Statistikinformationen nur der ersten Spalte eines zusammengesetzten Index spart, sodass es kritischer wurde, dass der Clustered -Index gut gestaltet wird. Wir meinen, es sollte besser der Spitze der Bestellung von Feldern von der mit größten Granularität zu den weniger folgen. Ein weiteres Problem, das möglicherweise begegnet wird, ist die Menge an Nulldaten. Statistiken sprechen über Nicht -Null -Daten. Wenn in der Tabelle 80% der Nulldaten -Multithreading nicht davon profitieren, profitiert nicht davon, da alle Nulldaten als eindeutige Stapel in einem Thread kopiert werden. Natürlich empfehlen wir auch, dass die Zieltabelle keine Indizes enthält (um mehrere Masseneinsatz -Threads zu ermöglichen), keine Partitionen und unkomprimiert sein, um den Einsatzprozess zu beschleunigen.
Diese DLL könnte in andere ETL -Projekte, die nicht abhängen oder die nicht über die SSIS -Plattform aufgebaut sind, in anderen ETL -Projekten beeinträchtigt werden.