The Basics


One of the most important features of Integration Services is logging. Logging is one of the ways people troubleshoot their processes. You can use logging to watch the progress of packages. Logging can alert you to errors that would otherwise be hard to diagnose or locate. In many ways, logging is indispensable in the production environment, so it is important to have a powerful and flexible logging infrastructure.

Logging in Integration Services is all that and more. The package writer can configure log entries to be written to zero, one, or many different locations simultaneously. Different tasks can log to different locations and use different filters. You can log to several different formats, including text, XML, and SQL. You can also view log entries in the Designer Log Events window as you test packages.

A single log message is called a log entry. Log entries come from a variety of sources, including the SSIS infrastructure, stock tasks, and custom logging. You can set up log filters to eliminate whole or parts of log entries. Filters can be saved to a file and later reloaded in other packages, making it easy to get consistent logging across packages.

A single type of log is called a log event, which components register so that the runtime can configure and filter them. A single log entry is, therefore, an instance of a log event. Log entries are often confused with package events. This is probably because the runtime registers a log event for every package event, and creates a new log entry every time a package raises a package event. However, the two should be distinguished. Package events result from substantial occurrences inside a package and for every package event, the runtime generates a log entry. However, this is only part of what ultimately ends up in an IS log. Components can also log any useful information at any time through the IS logging infrastructure, without limitations. As you'll see later, you can also implement custom logging.

Log providers are Integration Services components that perform the actual output. There are several types of log providers, each responsible for outputting the package log entries to a specific format. For example, the XML Log Provider takes all the log entries the Integration Services runtime sends its way and writes them out to an XML file. The Text Log Provider writes all the log entries to a text file, and so forth.

Quickstart

To get started, let's do some simple logging. This will give you a good feel for where things are and a chance to try it before getting into all the details.

Default Logging

Open the designer (BIDS) and create a new Integration Services project. Before adding any tasks or modifying the package in any way, go ahead and run it. Not much happens in the package, right? The point here is that, by default, all packages log their start and finish results into the Windows Event Viewer. There's no way to turn this off.

Open up the Windows Event Viewer under Administrative Tools on the Start menu. There should be two events logged from the SQLISPackage: the package started and finished events. Figure 11.1 shows the Event Viewer on the sample machine with the two events from the package. To see the details, double-click on one of the events.

Figure 11.1. Packages automatically log start and finish events to the Windows event log


Note

In many cases, individuals do not configure any logging on their packages, but later regret it because they have no way to determine which packages are still being used in their system or even how often the packages get executed.




Microsoft SQL Server 2005 Integration Services
Microsoft SQL Server 2005 Integration Services
ISBN: 0672327813
EAN: 2147483647
Year: 2006
Pages: 200
Authors: Kirk Haselden

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net