Every once in a while I’ll get inquires on a paper I wrote in 2004 about the ETW trace providers for ADO.NET (named “Tracing Data Access”). I got an inquiry today, and since I’d recently installed Visual Studio 2008 SP1 Beta, I thought I’d try it out on a LINQ to SQL program and an Entity Framework program.
If you haven’t read the paper, the original is still available on MSDN, but an embellished version (including SNAC tracing in addition to ADO.NET) was released in 2006. I’m also doing a talk at TechEd on “End-to-End tracing in ADO.NET and SQL Server 2008”. If you’re at all interested in client tracing or SQL Server 2008 Extended Events, it will be worth your while to attend.
Unless the LINQ to SQL program has its own ETW provider that I missed, I got no LINQ to SQL specific trace events. Since LINQ to SQL is a thin layer over System.Data.SqlClient, I do get the events for SqlClient however.
Entity Framework however, is another matter. I not only get EF-specific trace events, but there appears to be some new trace namespace abbreviations for EF as well. These are the ones I’ve seen while going through one trace of one simple EF program. I may have missed some.
dobj = System.Data.Objects
ec = System.Data.EntityClient
cqt = System.Data.Common.CommandTrees
pc = System.Data.Query.PlanCompiler
There’s quite a bit of trace information for some parts of EF, like the CommandTree portion. But after a whole half-hour and a few traces, it appears that not all items in EF are as thoroughly instrumented with trace events as, say, SqlClient. On the other hand, EF provider for SQL Server will show lots of SqlClient-specific and System.Data.Common events, as does LINQ to SQL.