Chargement de fichiers plats volumineux dans la table SQL est trop lent via le paquetage SSIS

Question

Je reçois environ 8 grands fichiers plats délimités à charger dans une table SQL Server (2012) une fois par semaine. Le nombre total de lignes dans tous les fichiers serait d'environ 150 millions et chaque fichier a un nombre différent de lignes. J'ai un simple paquetage SSIS qui charge les données de flatfiles (en utilisant le conteneur foreach) dans une table d'historique. Ensuite, une requête select s'exécute sur cette table d'historique pour sélectionner les données de la semaine en cours et les charger dans une table de transfert.

Nous avons rencontré des problèmes car la table d'historique est devenue très volumineuse (8 milliards de lignes). J'ai donc décidé de sauvegarder les données dans la table d'historique et de les tronquer. Avant la troncature, le temps d'exécution du colis variait de 15 heures à 63 heures dans cet ordre. Nous espérions qu'après la troncature, il devrait revenir à 15 heures ou moins. Mais à ma grande surprise, même après 20 heures, le paquet fonctionne encore. Le pire, c'est qu'il charge toujours la table d'historique. Le dernier compte est d'environ 120 millions. Il doit encore charger les données de transfert et cela peut prendre autant de temps.

Ni la table d'historique ni les tables de transfert n'ont d'index, ce qui explique pourquoi la requête sélectionnée dans la table d'historique prend la plus grande partie du temps d'exécution. Mais le chargement de tous les fichiers plats à l'historique était toujours inférieur à 3 heures. J'espère que j'ai du sens. Quelqu'un peut-il m'aider à comprendre quelle pourrait être la raison de ce temps d'exécution inhabituel pour cette semaine? Merci.

Remarque: Le fichier le plus volumineux (8 Go) a été lu à la source flatfile en 3 minutes. Donc je pense que la source n'est pas le goulot de la bouteille ici.

Answer 1

Il y a pas bonne raison, à mon humble avis, pourquoi ce serveur devrait prendre ce temps pour charger autant de données. Êtes-vous en train de dire que le processus qui prenait auparavant 3 heures, prend maintenant 60+? Est-ce la première partie (chargement de données) ou la deuxième partie (table d'historique) qui est soudainement devenue lente? Ou, les deux à la fois?

Je pense que la première chose que je ferais est de "faire confiance, mais vérifier" qu'il n'y a pas d'index en jeu ici. La deuxième chose que je regarderais est l'allocation de stockage pour cet espace de table ... est-ce qu'il manque de place, de sorte que le serveur de SQL doit faire un tas d'extra calesthenics pour obtenir et pour maintenir le stockage? Comment ce processus s'engage-t-il? Après chaque rangée? Pouvez-vous prouver que la définition du paquet n'a pas changé dans le moindre, récemment?

De toute évidence, "150 millions de lignes" n'est pas beaucoup de données, ces jours-ci; aucun n'est 8Go. Si vous "déplaciez" simplement ces lignes dans une table non indexée, "3 heures" serait une attente généreuse. De toute évidence, la seule cause fondamentale crédible de ce type de comportement est que la charge d'E/S disque a considérablement augmenté, et Je suis sceptiquement sceptique que "COMMITs excessive" pourrait bien faire partie de la cause: réécriture à la place de «paresseux-écriture», relire au lieu de la mise en cache.