Quelle est la taille de la taille d'un package SSIS?

Question

Quelle est la taille maximale d'un package SQL Server 2005 SSIS définition avant l'impact de la conception ou de l'exécution? Je ne parle pas de la taille des ensembles de données transmis, ni même du nombre de colonnes renvoyées. Je parle juste du nombre de séquences, de tâches, de tâches de flux de données et de variables utilisées dans le paquet. J'ai un paquet que je suis à mi-chemin avec l'implémentation, et j'ai un total de 20 séquences (certaines imbriquées), 16 tâches de flux de données, et 28 tâches de flux non-données (la plupart du temps exécuter des tâches SQL et Script) . Le fichier .dtsx lui-même est 4MB jusqu'à présent. Au moment où j'ai terminé, je pouvais voir le packge facilement doubler ou même tripler sa taille actuelle. Je n'ai encore vu aucun problème de performance, mais je veux savoir si je vais en rencontrer. Quelqu'un d'autre a-t-il rencontré des problèmes de performance au moment de la conception ou de l'exécution avec des définitions de paquets volumineuses? Existe-t-il une meilleure pratique pour les limitations de taille d'emballage?

Answer 1

Il semble qu'il est temps pour vous de décomposer ce package en packages distincts et d'utiliser la tâche Exécuter le package pour les exécuter. C'est beaucoup trop grand.

Answer 2

Deux problèmes découlent de gros colis. Le premier comme @Andrew mentionné est dans la maintenance d'un grand paquet indépendamment des problèmes de performance. En particulier si vous travaillez dans un environnement d'équipe, si vous avez extrait un grand paquet, vous devrez faire attention à fusionner les modifications, etc. Le deuxième problème, que j'ai vu dans SQL 2005, est lié au fait que le runtime pour SSIS dans BIDS est un processus 32 bits. Avec des paquets aussi grands que ceux que vous avez mentionnés, il est très probable que vous rencontrerez bientôt des problèmes de mémoire en essayant d'exécuter ce paquet dans votre environnement de développement. La plupart des gens recommandent de diviser les paquets en unités beaucoup plus petites pour simplifier le développement de l'équipe et les tests unitaires.

Voici une recommandation spécifique d'un article de base de connaissances http://support.microsoft.com/kb/952110/en-us
qui mentionne 7mb comme une taille .dtsx qui peut commencer à causer des problèmes. Comme mentionné ci-dessus, la cause première est que le runtime pour SSIS/BIDS (DevEnv.exe) est un processus 32 bits et de nombreux sous-systèmes dans cet exe créent leurs propres tas privés qui ne libèrent pas de mémoire (xml, oledb , etc.) Voir cette réponse à une question similaire:
http://social.msdn.microsoft.com/forums/en-US/sqlintegrationservices/thread/7ead0bee-6f04-4778-83b7-0fd666833113/

Answer 3

Je ne sais pas ce qui est trop grand, mais pour moi, le problème de Hériter avec ce type d'outils est vous vous retrouvez avec un désordre d'images graphiques avec des dialogues intégrés et des propriétés faisant un cauchemar pressé. Rien ne vaut le code brut si vous me demandez. Ce que vous voyez est ce que vous obtenez. Cependant, faites ce que l'on ferait avec du code brut, faites de petits morceaux digestes et rassemblez-les de la manière la plus logique possible pour que vous puissiez envelopper votre esprit autour d'eux. Beaucoup plus facile à faire avec du code que SSIS, mais vous pouvez toujours essayer pour ce type de conception. Donc, en résumé, si le paquet est devenu si grand et si complexe que vous ne pouvez pas l'entourer, c'est trop gros.