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?
À l'aide de SQL Server Business Intelligence Development Studio, je fais beaucoup de fichiers plats pour OLE flux de données de destination DB pour importer des données dans mes tables SQL Server. Sous "Mode d'accès aux données" dans dans le = OLE Éditeur de destination de base de données, il utilise 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 est transférée les données beaucoup plus rapidement.
Les modes d'accès aux données OLE DB Destination Component 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 selon un mode basé 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. De plus, vous allez abuser de votre journal de transactions.
Pourquoi voudriez-vous jamais les méthodes non rapides? Données incorrectes. 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 10 000 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 échec en cascade et cela ressemble à quelque chose comme
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 dans des lots successivement plus petits pour accéder aux mauvaises lignes. Ici, j'ai commencé avec une taille de validation d'insertion maximale (FastLoadMaxInsertCommit) de 10000. Sur la disposition de la ligne d'erreur, je la change en Redirect Row De Fail Component.
La prochaine destination 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 là-dedans, 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 mélange, 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 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 la capuche, table or view utilisera une commande SQL individuelle pour chaque ligne pour insérer vs table or view - with fast load utilisera la commande BULK INSERT.
Si vous voyez les options ci-dessus disponibles dans BULK INSERT par ex. number of rows in the batch = ROWS_PER_BATCH et commit size = BATCHSIZE
Un autre scénario sera ..
La taille de validation d'insertion maximale par défaut (2147483647) est trop élevée. Donc, par exemple vous insérez 500K 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 ici que vous pouvez avoir table or view comme destination Erreur de sortie. 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 5 000 lots vers table or view load - qui utilise l'insertion ligne par ligne UNIQUEMENT pour 5 000 lignes et vous pouvez également rediriger l'erreur de table or view dans un fichier plat .. afin que si une ligne échoue au lot si 5K, vous serez en mesure d'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.
Aficionado SSIS billinkca répondu à une question similaire sur Stackoverflow .