SQL Server Developer Center: Tracing Data Access - A Gentle Introduction to ADO.NET 2.0 Trace Facilities

SQL Server Developer Center: Tracing Data Access

"Tracing Data Access
A Gentle Introduction to ADO.NET 2.0 Trace Facilities.

Bob Beauchemin
DevelopMentor

November 2004

Applies to:
Microsoft ADO.NET 2.0
Microsoft .NET Framework 2.0
Microsoft SQL Server

Learn how to apply the tracing functionality in ADO.NET 2.0 to track down bugs and bottlenecks in your applications. (13 printed pages)

I've been missing a good generalized built-in trace facility for data access since the days of ODBC Trace. OLE DB had many of different types of tracing; two that come to mind are the Visual Studio Analyzer-compatible instrumentation and ATLTRACE (a trace macro for ATL OLE DB templates). The issue with OLE DB and MDAC was not that there was no trace, but that there were too many separate kinds of tracing, each tied to a different evaluation mechanism. It was difficult if not impossible to trace down into various layers of the data access stack and get one trace output.

ADO.NET 2.0 and SQL Native Client (a new OLE DB/ODBC/network library feature) contain a flexible, rich, built-in data trace facility. Microsoft has instrumented all four of its .NET data providers (SqlClient, OracleClient, OleDb bridge, and Odbc bridge), the ADO.NET DataSet and friends, SQL Native client OLE DB and ODBC provider/driver, and to top it off, the SQL Server 2005 network libraries. The information in this article is meant to get you up and tracing quickly, show you how to do some cursory trace file analysis, and look at simple trace use-cases. At the end of the article, I'll talk about how the tracing layer is architected to be extendible to different trace technologies, and suggest more ways in which to use it.

Trace points are already programmed in to the .NET and SQL native client libraries. Using an IL disassembler like Reflector, you may already have noticed them. The first step is configuring things to allow you to get basic output.

The basic steps for using tracing are:

Set up the data tracing DLL registry entry, ETW providers, and WMI schemas.
Configure and run the trace itself.
Harvest the trace results as a comma-separated value file.
Don't worry if some of the acronyms like ETW and WMI are unfamiliar to you for now. Let's go over the steps one-by-one and then go back to a discussion of how they work.

..."

When you need data tracing you really need it...

(via Christa Carpentiere - Tracing in ADO.NET 2.0)