mbulkcopy

Copie en vrac multithread

Un outil pour les situations de transfert de données, construits uniquement à des fins théoriques, qui peuvent être utiles pour transférer une grande quantité de données d'une instance SQL Server (2000 ou plus) et / ou Oracle (10G ou supérieur) vers une autre (SQL> SQL, SQL> Oracle, Oracle> SQL et Oracle> Oracle).

Il est habituel de copier SQL Server et / ou Oracle Tables d'une instance à une autre.
Habituellement, nous décidons probablement d'utiliser l'assistant d'importation / exportation SSMS, un package de services d'intégration ou une méthode pour transférer des données sous forme de fichier texte.
Mais des problèmes peuvent survenir si nous parlons de tables avec plus de 300 millions de dossiers ou 30 Go et plus s'ils doivent être copiés au minimum.
Si nous avons de la chance, ce tableau peut avoir un index cluster dans SQL Server ou un index avec un histogramme de fréquence dans Oracle. C'est le scénario où ce petit projet joue un rôle.
Si nous n'avons pas d'index cluster sur la table source, il y a un certain espoir, nous avons implémenté une nouvelle méthode (un peu plus lente que celle en grappes, mais une bonne) pour copier des données à partir d'une table de tas, dans Oracle et SQL Server.

Sa logique est très simple: il scanne les statistiques d'index en cluster dans SQL Server, ou histogramme dans Oracle, et définit des grappes équilibrées de données.
Cela signifie qu'il crée autant de requêtes que les threads paramétrisés, et ces requêtes filtrent sur le champ d'index en cluster essayant de manière à obtenir le même volume de données chacun. Ensuite, il les tire à l'aide de la méthode SQLBULKCOPY .NET FW ou OracleBulkCopy à partir de la méthode ODP.NET. En tant que tas, il "partitionne" le tableau avec une fonction déterminictique et un module (%% Lockres %% dans SQL Server et Rowid dans Oracle), et lancez chaque requête dans un thread.

Nous devons conseiller que selon la quantité de threads, il s'agit d'un processus très intensif en ressources et, dans certains cas, la consommation de processeur pourrait atteindre 100% et la longueur de la file d'attente du disque peut provoquer de longues attentes.

Pour cette raison, nous vous recommandons d'exécuter un serveur différent autre que la source de données et la destination.

Ainsi, avec une structure de 2 réseaux avec deux cartes réseau de 100mbit dans chaque serveur, nous avons atteint des taux de transfert de 190 Mo / SEG.

Vous devez le tester à des fins statistiques avant de penser à l'utiliser dans un environnement de production.

Remarques supplémentaires: Le gain de performance sera atteint sous certaines circonstances, et parfois il ne sera pas perçu en raison de la nature des données à l'intérieur de la colonne en cluster. Tout d'abord, il est nécessaire de clarifier que l'index cluster enregistre les informations de statistiques uniquement de la première colonne d'un index composé, il est donc devenu plus critique que l'index cluster soit bien conception. Nous entendons qu'il serait préférable de suivre la pointe des champs de commande de celui avec la plupart de la granularité à la moins. Un autre problème qui peut être rencontré est la quantité de données nulles. Les statistiques parlent de données non nulles, donc si le tableau contient 80% des données nuls multithreading n'en bénéficiera pas, car toutes les données nuls sont copiées dans un seul thread en tant que lot unique. Naturellement, nous recommandons également que la table de destination n'ait pas d'index (pour permettre plusieurs threads d'insertion en vrac), pas de partitions et non compressés pour accélérer le processus d'insertion.

Cette DLL pourrait être empruntée dans d'autres projets ETL qui ne dépend pas ou qui ne sont pas construits sur la plate-forme SSIS.