Extended Events and Profiler: XE Profiler

SQL Server 2017
There's a war on in the SQL Server world. On the one side is Profiler (although, really, everyone uses Trace Events). On the other, the "new" (they came out in 2008 with a full GUI in 2012, so...) Extended Events. Lots of people have picked sides on this, including Microsoft. New Trace Events There are none. All the new functionality of every sort from Availability Groups to Query Store to R & Python, have Extended Events created for them. Trace Events, and the technologies supporting them in the form of Profiler, are a dead end. Don't fear. While Trace is on the deprecation list, there doesn't appear to be any fear of that technology being removed completely. At least it won't be removed in the foreseeable future. A future which,…
Read More

SQL Spackle

SQL Server 2005, SQL Server 2008, SQLServerPedia Syndication, Tools, TSQL
I previously mentioned how SQL Server Central was listing ideas for articles, primarily for short, quick, pointed articles that they were terming SQL Spackle. Spackle is a term in the US that represents the filler you put into dry-wall to smooth it out or fix small holes, so SQL Spackle is meant to fix small gaps in knowledge or documentation. My first SQL Spackle article was published today. I kind of forgot it was coming. I wrote a quick and pointed outline of how to set up and schedule a server-side trace. This is something I've always advocated, and now I can point to a bit of spackle to fill in the gaps for those who don't know how to get it done.
Read More

Snags With Profiler GUI

SQL Server 2005, SQL Server 2008, SQLServerPedia Syndication, Tools, TSQL
Running the Profiler GUI against a production server is not something you should do. I've outlined my research into exactly why in the past. But I hit another little issue with the Profiler GUI as part of work I'm doing on a Microsoft PSS call (more on that in another post). We have a procedure on one of our systems that is erroring out, but only on a particular server and only when called from the application, not when it's called, on the same server, from SQL Server Management Studio. I needed to capture some trace events and do it quickly, so I decided to use the GUI, just this once. I put filters on it so that I would only collect certain data, and the database I was collecting…
Read More

Pre-Compiled Stored Procedures: Fact or Myth

SQL Server 2005, SQL Server 2008, SQLServerPedia Syndication, TSQL
There's a very common belief among DBA's: Stored procedures are pre-compiled. I had someone tell me all about it just last week. There are lots of sources that say what I'm getting ready to say, so this really shouldn't come as news to anyone,but it will. No, they're not. Stored procedures are not pre-compiled. When you create or update a stored procedure on the server, it gets a syntax check. But there is no compile process, let alone a pre-compile process. That stored procedure exists exactly as it is named, a procedure that is stored on the server. It's just a collection of TSQL code, possibly with some parameters, waiting to be called. Until it's called, it is not ready to be executed. Don't believe me? I'm not a huge…
Read More

Profiler Research

SQL Server 2005, SQL Server 2008
A question came up on SQL Server Central as to why or how Profiler could bring down the production server.  I was aware of the fact that Profiler caused problems and that's why you should always use a server-side trace on production systems. Duh! Of course.... But why? I didn't have an answer. I just "knew" what everyone told me. So I set out to do some research. Initially I hit my favorite source of information on SQL Server (and it should be yours too) the Books Online. Here is what I was reading on the architecture of Profiler. Good, but not enough. I still want more information, so I've gone out a'wanderin' through the interwebs. First, Linchi Shea has this great set of tests comparing Profiler to server side…
Read More