DTLoggedExec

The DTLoggedExec was desiged to a tool that allows you to run a Sql Server Integration Services (SSIS) Package producing a full and detailed logging informations of execution status and package runtime data, including dataflow profiling information. In brief it allows to fully log and instrument package execution.

If you're using Sql Server 2005/2008 Integration Services, you should know that the packages you've created can be launched via DTExec or SQL Server Agent. In both cases you'll find that, though an extensive logging infrastucture seems to be present, logged information doesn't really help you to understand why and how a package that has always run correctly someday decides to go wrong.

In addition to this big limitation you may also have already discovered that logging can't just be switch on or off right from the execution tool. Though it seems possibile, if you want to log on a text file your package MUST contain a connection manager that points to the file you want, otherwise logging cannot be used. This means that you should engineer your packages so that they support the logging infrastructure, BEFORE you need it. This also means that you have to take care of preparing the way for logging in ALL of your packages.

This is really not how logging should work for me. I need something that can be switched on or off as I desire, without having me to do anything during package development; in addition I need ALL the data and the information I can have, since when I have to understand why a package didn't run succesfully in a production enviroment, well, I can't run the package in debug mode from Visual Studio right from the production server (otherwise I'll be doing debugging on production machines, not an healthy way of working from my point of view)!

Another missing feature that I really missed a lot is the ability to profile dataflow tasks. To do a proper profiling you should add "Row Count" wherever you need to know how many rows has been processed, take the start and the end time of each transformation and put everything in a database for later analysis. This is a highly time consuming way to work IMHO, since package instrumentation should be something provided right from the execution tool, and not by who creates the pakages. Also, putting the instrumentation logic within the package make it more complex and long to develop.