À l'aide de SQL Server Business Intelligence Development Studio, je fais beaucoup de fichiers plats vers des flux de données de destination OLE DB pour importer des données dans mes tables SQL Server. Sous «Mode d'accès aux données» dans dans l'éditeur de destination OLE DB, il est par défaut «table ou vue» plutôt que «table ou vue - chargement rapide». Quelle est la différence; la seule différence perceptible que je peux percevoir est que la charge rapide transfère les données beaucoup plus rapidement.
Mode d'accès aux données SSIS Data Flow - quel est l'intérêt de «table ou vue» par rapport à une charge rapide?
Réponses:
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.
Fast Load est bien documenté sous les options FAST LOAD
Conservez les valeurs d'identité du fichier de données importé ou utilisez des valeurs uniques attribuées par SQL Server.
Conservez une valeur nulle pendant l'opération de chargement en bloc.
Vérifiez les contraintes sur la table ou la vue cible lors de l'importation en bloc.
Acquérir un verrou au niveau de la table pour la durée de l'opération de chargement en bloc. Spécifiez le nombre de lignes dans le lot et la taille de validation.
Quelle est la différence; la seule différence perceptible que je peux percevoir est que la charge rapide transfère les données beaucoup plus rapidement.
Sous le capot, table or viewutilisera la commande SQL individuelle pour chaque ligne à insérer vs table or view - with fast loadutilisera la commande BULK INSERT.
Si vous voyez ci-dessus les options disponibles dans BULK INSERT, par exemple number of rows in the batch= ROWS_PER_BATCHet commit size=BATCHSIZE
Un autre scénario sera ..
La taille de validation d'insertion maximale par défaut (2147483647) est trop élevée. Ainsi, par exemple, vous insérez 500 000 lignes et en raison d'une violation de PK, le lot échoue. Dans ce scénario, le lot entier échouera lorsque vous utilisez l'option FAST LOAD. Vous ne pourrez pas non plus obtenir la description de l'erreur.
C'est là que vous pouvez avoir table or viewcomme sortie d'erreur de destination. Donc, sur 500K, vous utilisez FAST LOAD comme commençant avec une taille de validation d'insertion de 5K. Si 1 ligne de ce lot échoue, vous redirigerez ces lots de 5K vers le table or viewchargement - qui utilise l'insertion ligne par ligne UNIQUEMENT pour 5K lignes et vous pouvez également rediriger l'erreur de table or viewvers un fichier plat .. de sorte que si une ligne échoue le lot si 5K, vous pourrez identifier la cause de l'échec.
L'avantage de la méthode ci-dessus est que si aucune des lignes échoue, elle utilisera BULK INSERT (chargement rapide) pour l'ensemble du lot.
L'aficionado SSIS billinkc a répondu à une question similaire sur Stackoverflow .