SQL Server Integration Services - Hors d'exception mémoire

Question

J'ai créé un ETL qui a grandi pour remplir environ 250 tables (tableaux, Tableaux Mise en scène Dimension et des tables de faits). J'ai obtenu le modèle de conception ETL de Stacia Meisner, son modèle de conception ETL était basé sur la création d'un package de modèle pour charger une table de transfert, charger une table de dimension puis charger une table de faits. L'idée est d'utiliser des variables que vous définissez dans un package spécifique qui appellent alors les procédures stockées appropriées, créer la lignée et les données d'audit, remplir les tables correctes etc en utilisant des expressions, de sorte que vous venez de copier et coller le package de modèle dans votre solution, modifier la variable et aussi longtemps que vous avez les procédures stockées en place pour la source des données et les noms de tables correctes, tout fonctionne parfaitement.

qui est ... jusqu'à ce que j'atteint 250 tables. Quand je lance l'ETL dans BIDS, il consomme de la RAM comme un fou. Lorsque je déploie l'ETL et l'exécute en SQL, ce n'est pas le cas. Un ETL Run sur mon ordinateur portable va probablement consommer environ 3 à 4 gigaoctets de RAM car il ouvre chaque paquet enfant de la mine d'un paquet parent. Il y a maintenant 250 paquets dans ma solution. Je peux stocker la RAM dans mon ordinateur portable (actuellement installé à 8 Go ou en RAM), mais il y a certainement des alarmes d'avertissement dans ma tête qui me font penser que 250 tâches de flux de données auraient peut-être été mieux choisies.

Comprendre la faille dans ce modèle de conception maintenant, je suppose alors mes questions sont les suivantes

1. était-BIDS jamais censé avoir tant de paquets d'exécution au sein d'un ETL?
2. Est-il possible que je peux réduire la consommation de mémoire vive quand je lance l'ETL au sein de l'IDE?
3. est la consommation de RAM à attendre, et si oui, comment les développeurs ne traitent normalement avec elle. Je pourrais facilement contourner en jamais l'exécution de l'ETL entier dans mon IDE, mais le tester dans ses parties, puis le déployer dans son intégralité
4. Dois-je pas loin de l'emballage 1 par modèle de conception de table et mettre en œuvre des tâches de flux de données 3 paquets (1 pour le chargement des tables de transfert, 1 pour le chargement des dimensions et 1 pour le chargement de mes tables de faits)

Merci pour votre temps, j'apprécierais votre contribution.

Cordialement,

Jesse

Answer 1

Stepping loin de la question de la RAM pendant un certain temps, je garderais le modèle de conception. Il est extrêmement utile lorsque vous vous trouvez dans une situation où vous devez exécuter le post-déploiement ETL d'une seule table. Avec 2012+, il vous fournit également des informations de journalisation beaucoup plus utiles, car en utilisant des packages parents, tout est considéré comme faisant partie d'une seule exécution, ce qui vous permet de créer un suivi/reporting utile à partir des données stockées dans SSISDB. Toutes les autres raisons que vous avez énumérées pour adopter ce modèle en premier lieu sont également valides; le motif favorise la réutilisation & normalisation, et réduit le temps de développement. Il est également très facile pour un autre développeur de prendre la solution, de la contourner, de la prendre en charge, de la modifier, etc.

Pour en revenir à la RAM: 8 concerts ne sont pas vraiment énormes pour une machine de développement SSIS dans un environnement où votre solution ETL est si grande - si vous avez la possibilité de mettre à niveau, je pense que ce serait une bonne idée. Je n'ai pas rencontré le problème que vous décrivez en dépit du fait de travailler avec de très grandes solutions ETL, mais mes deux précédentes machines de développement avaient 32 Go et 16 Go de RAM.L'IDE SSIS est loin d'être parfait et je peux entièrement croire que ce que vous décrivez soit un problème.

Il faut aussi noter que je ne lance pas souvent une solution ETL entière au sein de l'IDE. Je travaille plus souvent sur des pièces indépendantes au fur et à mesure que je travaille dessus, puis dès que je sais que cette partie fonctionne, je la déploie dans un environnement de développement (installation locale ou serveur) et fais tout mon tour via l'agent . Étant donné les différences dans la façon dont les choses fonctionnent par l'intermédiaire de l'agent par rapport à l'intérieur de l'EDI, je trouve qu'il est utile de déployer tôt. J'apprécie également les informations de journalisation que l'exécution via l'agent me donne - cela peut m'aider à suivre si les changements que je fais ont affecté la performance. Avec le modèle de déploiement 2012+, il n'est pas trop long de travailler de cette manière. En fin de compte je pense que ce serait une erreur de s'éloigner d'un modèle solide avec de nombreux avantages plutôt que de changer la façon dont vous travaillez légèrement afin de faire face aux imperfections de l'IDE. Une note finale: Si vous avez un DB de développement local sur votre ordinateur portable (plutôt que d'exécuter uniquement SSIS localement, et que la DB se trouve sur un serveur), faites Assurez-vous que vous disposez d'un paramètre de RAM maximum assez faible pour votre instance SQL Server locale. Si vous ne le faites pas, il utilisera toute votre RAM pour mettre en cache les choses, puis SQL Server et SSIS finiront par se battre pour la RAM. J'ai vu cela causer des erreurs de mémoire dans l'IDE SSIS. Je ne pense pas que c'est ce que vous décrivez ici, mais je le mentionne juste au cas où cela vous aiderait, ou quelqu'un d'autre qui trouve ce Q & A.