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.
Here are some key features of "DTLoggedExec":
· Enable / Disable logging on the fly for any package, just right from the command line
· Log Variables value
· Log Values of Properties bound to Expressions
· In case of error, log all properties along with related connection properties of the erroneous task. This is IDEAL for post-mortem debugging
· Fully pluggable architecture: decide where to log informations (natively supported: No Log, Console; CSV coming soon) Add your own log providers to customize logging
· Choose which event you want to log
· DTExec parameters emulation (not yet 100% finished)
· Compiled to support 32bit and 64bit platforms (32bit and 64bit executables are available in the zipped file)
· Support for Integration Services 2005 or 2008 through assembly binding
· DataFlow Profiling: log DataFlow performance data, how many rows each component has processed in how much time.
Requirements:
· Sql Server
What's New in This Release: [ read full changelog ]
· Updated the CSV Log Provider in order to write the status of the log file in the header.
· An OPEN status means that the log file is being written.
· A CLOSED status means that the log files has been written correctly.
· A file can be loaded into the database log only if is in the CLOSED state.
· CSV Log files have 2 additional rows in the header: one for the FileStatus and one for the ExecutionLabel values.
· File format has been update to 4 from 3. (Only the header section of the file has been changed).
· CSV Log Provider will now display EndTime value to the Console
· Updated the import-log-data.sql to correctly load file with format 3 (the old one) and 4 (the new one).
· Updated database schema to version 19 in order to store the new ExecutionLabel value
· Update samples in order to show how to use the new ExecuteLabel option
Find us on Google+
