2017-04-07 1 views
2

J'utilise SQL Server 2012 et SSIS. J'ai deux tables dans le même serveur et la même base de données. J'ai besoin de transférer tous les enregistrements des deux tables dans la troisième table.SSIS union tous vs sql server Union Tous

Je dois ajouter quelques colonnes (comme l'ID d'exécution et certains paramètres de paquet) au résultat de UNION ALL et après que je dois transférer les enregistrements dans la troisième table.

J'ai deux solutions pour cela, mais je ne sais pas lesquelles sont les plus efficaces.

Solution 1: Utilisez deux OLE DB DataSource s et utiliser Union All Component dans SSIS

enter image description here

Solution 2: Utilisez Union All dans le côté SQL Server et utiliser un seul OLE DB Source dans SSIS.

enter image description here

Lequel est le plus efficace?

+1

Je parie ce dernier mais avez-vous remarqué un décalage horaire? J'ai tout simplement plus de sens à faire moins d'appels à votre source de données. – scsimon

+1

Je devrais dire que votre deuxième option est plus efficace parce que vous faites l'union sur la base de données de sql et vous faites seulement un appel à la base de données. Y a-t-il une grande différence de temps dans l'exécution? – Kevin

+0

À l'heure actuelle, Mes tables contiennent moins de 10000 lignes chacune. Mais à l'avenir, ils auront plus de millions de lignes. En raison de cela, je veux choisir la meilleure pratique ici et dans certains paquets, j'ai besoin d'UNION plus de deux tables –

Répondre

2

Toujours favoriser les opérations de base de données lorsque cela est possible. Si 2 tables sont dans la même base de données, il n'y a absolument aucune raison de favoriser une opération SSIS sur l'optimiseur de requête. Union Tout est une opération sans blocage, donc il n'y aura presque aucune différence dans ce cas, mais s'il s'agissait d'une jointure ou d'une opération plus complexe, alors l'optimiseur de requête entrerait en jeu.

Utilisez la solution de base de données comme règle générale.

+0

L'une des raisons pour lesquelles vous pouvez le faire dans SSIS est que vous préférez le style de développement et de débogage de SSIS.Mais pour la performance, bien sûr, pour quelque chose comme ça dans le même DB, vous préféreriez la requête DB. – Rich

+0

Bonne réponse. Je veux juste souligner que l'union est une transformation partiellement bloquante, et non une transformation non bloquante. – Khaled

0

Vous pouvez également envisager de le faire dans une tâche d'exécution SQL simple.

Insert into T3 
select * from T1 
union all 
select * from T2 
+0

Si la troisième table est dans la même base de données, alors bien sûr, ce serait la manière optimale. –

0

Désolé d'être en désaccord avec le Café Con Leche, mais une fois que vous êtes à l'aise avec SSIS vous devriez toujours utiliser une tâche SSIS sur TSQL. À l'exception des opérations de tri, SSIS est généralement plus rapide et permet une gestion des erreurs très facile à configurer (y compris les lignes 'mauvaises' étant redirigées pour être traitées/réparées plus tard) et la journalisation. Presque tout ce qui peut être fait dans SSIS peut être fait dans TSQL (surtout si vous êtes à l'aise avec sp_cmdshell) mais il est beaucoup plus difficile de faire la journalisation et la gestion des erreurs dans TSQL qui est intégré à SSIS.

+1

Je suis d'accord avec tout ce que vous dites ici à part le bit «SSIS est généralement plus rapide». Le choix dépend le plus souvent de ce qui convient le mieux à vos compétences. Les avantages de la gestion des erreurs et de l'audit sont définitivement là pour SSIS, tout comme un style visuel clair. Je préfère SSIS pour ETL, c'est sûr. Mais dire que SSIS est généralement plus rapide n'est pas vrai - ce ne serait pas plus rapide pour des choses comme des jointures à d'autres tables dans la même base de données et des syndicats. Cela peut être plus rapide dans de nombreuses situations, comme d'habitude cela dépend. Je ne comprends vraiment pas les gens qui disent que vous devriez toujours utiliser T-SQL sur SSIS ou SSIS sur T-SQL. – Rich

+0

Effectuer des jointures sur des tables très volumineuses, puis effectuer des opérations de transformation sur l'ensemble résultant est généralement plus rapide dans SSIS. La raison pour laquelle la solution TSQL obtient autant de votes est que pour un menuisier dont le seul outil est un marteau, tout ressemble à un clou. Lorsque les utilisateurs ne connaissent que SSIS à travers le GUI, ils ont peur de l'utiliser pour créer des paquets directement. –

+0

SSIS est très efficace et fait très bien les choses. Je suis d'accord avec vous sur les raisons pour lesquelles certaines personnes préfèrent le T-SQL: c'est parce que c'est ce qu'ils savent. Mais je ne suis pas sûr que vous ayez raison sur le fait que les jointures/transformations dans la base de données sont plus lentes que SSIS. Cela dépendra du cas d'utilisation. – Rich