Les modes d'accès aux données du composant de destination OLE DB sont disponibles en deux versions: rapide et non rapide.
Rapide, soit "table ou vue - chargement rapide" ou "variable de nom de table ou de vue - chargement rapide" signifie que les données seront chargées de manière basée sur un ensemble.
Lent - soit la «table ou la vue» ou la «variable de nom de la table ou de la vue» entraînera l'émission par SSIS d'instructions d'insertion singleton dans la base de données. Si vous chargez 10, 100, voire 10000 lignes, il y a probablement peu de différence de performances appréciable entre les deux méthodes. Cependant, à un moment donné, vous allez saturer votre instance SQL Server avec toutes ces petites demandes délirantes. En outre, vous allez abuser de votre journal des transactions.
Pourquoi voudriez-vous jamais les méthodes non rapides? Mauvaises données. Si j'envoyais 10000 lignes de données et que la 9999e ligne avait une date du 29/02/2015, vous auriez 10k insertions atomiques et commits / rollbacks. Si j'utilisais la méthode Fast, ce lot entier de 10k lignes sera soit enregistré, soit aucun d'entre eux. Et si vous voulez savoir quelle (s) ligne (s) avez commis une erreur, le niveau de granularité le plus bas que vous aurez sera de 10k lignes.
Maintenant, il existe des approches pour obtenir autant de données chargées aussi rapidement que possible et toujours gérer les données sales. C'est une approche d' échec en cascade et cela ressemble à quelque chose
L'idée est que vous trouviez la bonne taille pour insérer autant que possible en une seule fois, mais si vous obtenez de mauvaises données, vous allez essayer de réenregistrer les données en lots successivement plus petits pour accéder aux mauvaises lignes. Ici , j'ai commencé avec un maximum insert engagement taille (FastLoadMaxInsertCommit) de 10000. À la disposition de la ligne d'erreur, je change à Redirect Rowpartir Fail Component.
La destination suivante est la même que ci-dessus, mais ici, j'essaie de charger rapidement et de l'enregistrer par lots de 100 lignes. Encore une fois, testez ou faites semblant de trouver une taille raisonnable. Cela entraînera l'envoi de 100 lots de 100 lignes car nous savons quelque part , qu'il y a au moins une ligne qui a violé les contraintes d'intégrité de la table.
J'ajoute ensuite un troisième composant au mix, cette fois-ci, j'enregistre par lots de 1. Ou vous pouvez simplement changer le mode d'accès à la table loin de la version Fast Load car cela donnera le même résultat. Nous enregistrerons chaque ligne individuellement et cela nous permettra de faire "quelque chose" avec la ou les mauvaises lignes.
Enfin, j'ai une destination de sécurité. C'est peut-être la "même" table que la destination prévue, mais toutes les colonnes sont déclarées comme nvarchar(4000) NULL. Tout ce qui finit à cette table doit être recherché et nettoyé / jeté ou quel que soit votre mauvais processus de résolution des données. D'autres sauvegardent dans un fichier plat mais vraiment, tout ce qui a du sens pour la façon dont vous souhaitez suivre les mauvaises données fonctionne.
