SSIS Logging dans SQL 2012

Dans la version 2008R2, j'utilisais la journalisation SSIS vers une table sysssislog dans une database définie. 2012 apporte maintenant le concept des catalogues Integration Services qui ont leur propre database SSISDB. Est-il encore nécessaire d'utiliser la journalisation dans les tables sysssisslog ou est l'information qui se termine là quelque part dans SSIS DB (ce que je m'attendrais, puisque tous les rapports pour l'exécution de SSIS sont également basés sur cette database).

La journalisation que vous connaissez est toujours disponible avec la version 2012 de SQL Server. Cela dit, la journalisation de la database ne doit plus être explicitement définie dans votre package si vous utilisez le model SSISDB (Project Deployment Model).

Dès la sortie de la boîte, vous obtiendrez le niveau de journalisation de base lorsque vous exécutez un package. Les autres options sont none, performance et verbsose. En savoir plus sur la façon de définir ces parameters et d'autres parameters d'exécution via MVP Phil Brammer. Matt Masson, de l'équipe SSIS actuelle, indique à quels events correspondent ces niveaux dans son message sur les events inclus dans les niveaux de journaux du catalogue SSIS .

Enfin, SSIS Reporting Pack est un projet open source de MVP Jamie Thomson qui fournit des informations différentes sur datatables de base capturées dans le nouveau catalogue de services d'intégration.

Mes pensées: nécessaire non. Mais si vous disposez déjà d'un framework compilant des données de ce journal (nous l'utilisons pour un système d'alerte), vous êtes soutenu pour continuer à l'utiliser. Si vous exécutez des packages de services d'intégration à partir de plusieurs servers, il n'existe aucune fonctionnalité permettant de combiner la journalisation de tous ces catalogues SSISDB disparates pour fournir un aperçu de votre univers entier. Vous pouvez get cela si tous les packages se connectent à un server centralisé en utilisant la technique classique.