More information about the session can be found on the presentation’s web page, including:

• The session’s abstract and goals
• The current release of the session materials, along with all past versions
• A list of past deliveries of the presentation

See you this afternoon!

This year, the session selection committee is trying something new and has requested input on the submitted abstracts. I strongly encourage you to take a few minutes and vote for abstracts that appeal to you in the PASS Summit 2011 Session Preference Survey. You can vote even if you might not be able to attend the conference… all that you need is an account on the SQLPASS.org web site. If you don’t already have one, registration is easy and free.

If you have attended any of my presentations and enjoyed them/learned from them, I would greatly appreciate the support of voting for some of my sessions. I submitted the maximum of four abstracts, but I would prefer to deliver either of my “cookbook” presentations:

• A PowerShell Cookbook for DBAs
  • I have been delivering this presentation since SQLSaturday #22 on 2010-06-05
  • As a production/escalation DBA, I use PowerShell more than any other single program, especially when interacting with SQL Server
  • My goal is to convince fellow DBAs to try PowerShell by showing a variety of ways that PowerShell makes our jobs easier and by providing attendees with a collection of ready-to-use scripts for getting started
• An XQuery Cookbook for DBAs
  • This is a new presentation that is under development. I will probably deliver it for the first time at the July meeting of the Fort Worth SQL Server Users Group
  • A lot of valuable diagnostic data is exposed as XML these days
  • I have written many T-SQL/XQuery scripts to analyze and manipulate the data, but I would not describe the experience as being pleasant
  • I would like to give other DBAs these scripts, along with a little bit of background understanding, so that they can access this very powerful meta data without the many hours of frustration in developing the scripts
  • Some of the “recipes” included in the presentation will work with the following data sets:
    • DDL trigger event data
    • Deadlock graphs
    • Extended Events payloads
    • Output from the Performance Analysis of Logs (PAL) Tool
    • The [sys].[dm_os_ring_buffers] DMV’s contents
    • Windows event logs
    • XML statistics profiles (query plans)

Note: The deadline for voting is tomorrow, so please do so as soon as possible!

I’m a big proponent of using server-side traces for troubleshooting deadlocks. During my deadlocks presentation, I show how to manually extract XML deadlock graphs using SQL Server Profiler:

That works, but it’s a manual process, which is anathema to us automation adherents.

When processing XML deadlock graphs, I tend to:

1. query the trace data, via the [sys].[fn_trace_gettable] system function,
2. cast the [TextData] value to the XML data type, then
3. analyze the deadlocks with XQuery.

I can see the benefit of having a few loose *.XDL files, so I spent a little time writing a PowerShell script that will automatically extract the XML deadlock graphs and save them as files. This zip archive contains the script and sample trace files.

Here is an example of using the script (assuming that you extracted the files to the “C:\Temp\” directory):

[String]$ScriptUtilityPath = 'C:\Temp\Export-XDLFromTraceFile.ps1';
[String]$OutputDirectoryPath = 'C:\Temp\';
[String]$SourceServerName = 'T-SQL001';
[String]$TraceFilePath = 'C:\Temp\DeadlockTrace_20100522T113514.trc';
& $ScriptUtilityPath -TraceFilePath $TraceFilePath -OutputDirectoryPath $OutputDirectoryPath -SourceServerName $SourceServerName -FormatXML | Out-Null;

Here’s another example that leverages PowerShell’s composable nature:

[String]$ScriptUtilityPath = 'C:\Temp\Export-XDLFromTraceFile.ps1';
[String]$OutputDirectoryPath = 'C:\Temp\';
[System.IO.FileInfo[]]$OutputFiles = @();
[String]$SourceDirectoryPath = 'C:\Temp\';
[String]$SourceServerName = 'T-SQL001';
[String]$TraceFilePath = '';
Get-ChildItem -LiteralPath $SourceDirectoryPath -Filter '*.trc' | ForEach-Object {
    $TraceFilePath = $_.FullName;
    $OutputFiles += @(& $ScriptUtilityPath -TraceFilePath $TraceFilePath -OutputDirectoryPath $OutputDirectoryPath -SourceServerName $SourceServerName -FormatXML);
}
$OutputFiles | Select-Object -Property Name, @{Name='Size_bytes'; Expression={'{0:N0}' -f $_.Length}} | Format-Table -AutoSize;

Let me know if this is useful to you, or if you have any suggestions to make it better.

NOTE: I haven’t had a chance to test the script with the SQL Server 2005 SQL Server Management Objects (SMO) assemblies. I suspect one or both of the following issues:

• Classes may reside in different assemblies—SMO has a less than stellar history of backward compatibility
• The sample trace files were created on a SQL Server 2008 R2 instance, so they probably cannot be opened by the 9.0 tools

The download contains the slide deck, a handout full of links to resources, demonstration code, and a few sample files. I plan to upload some revisions as soon as I get home from the Summit (this weekend).

See you in an hour!

• Deadlock Detection, Troubleshooting, and Prevention
• Leveraging SQLDiag for Efficient Troubleshooting

As I’ve mentioned, a goal for the year has been to begin participating in technical forums, answering questions for other IT professionals and developers. I set up a few accounts/profiles last weekend and resolved to answer at least one thread over the course of the week. It was a busy week!

Well, last night Tim (blog, Twitter) and I left the SQLSaturday #25 afterparty some time between 7:30 and 8:00 p.m. We were having a great time, but the weariness from traveling and the lack of sleep was catching up with me.

We got back to the hotel, relaxed briefly, then broke out the laptops. Tim planned to download videos about the Tableau product suite, a very impressive "visual analysis and data visualization" tool that had been demonstrated during the conference, for the flight home. I planned to continue working on my SQLDiag presentation and hopefully compose a blog post or two as well.

Instead, we got caught up in discussion, visiting such varied topics as: SQLSaturday #25, SQLSaturday #17, the North Texas SQLSaturday (that is being planned), the NTSSUG leadership, presentation styles, career goals, marriage, books, friendships, our jobs, the folly of youth (specifically not applying ourselves in school), and our mutual admiration for Tim Mitchell (blog, Twitter). It was a lot of fun!

A little after 11:00 p.m. (I think), I suddenly remembered my forum-post-for-the-week-of-October-4th goal, which hadn’t been achieved. I decided not to let it slip, so I took action.

First, I needed to find a good thread to which I could contribute. I brought up the ServerFault, SQL Server Central, and TechNet forums in different browser windows and began searching. I wasn’t quite sure the best way to conduct the search, so I started by only including threads that hadn’t been answered yet. I skimmed through the remaining post titles and saw a few about deadlocks. I quickly latched onto that topic and refined my search. Moments later, I found my target: "how to analyse deadlock graph and deadlock xml ?" [sic].

One of the suggestions in my deadlocks presentation is to sanitize the deadlock graph and then reach out to the SQL Server community (by way of forum of newsgroup) or send the graph to a colleague for help (at least until attaining proficiency with deadlock troubleshooting), so this was a great fit.

I copied the deadlock graph’s XML content from the forum post into a text file and then changed the extension of the file from "txt" to "XDL." Doing so made it so that SQL Server Management Studio would automatically open the deadlock graph and render a diagram of the deadlock. I also reformatted the XML contents so that it was easier to read.

I figured out the reason for the deadlock (as much as one can without access to the system and/or schema) pretty quickly, but the write-up took quite a while. I wanted to include enough information and references that the poster would learn from the answer, and not just take it and be no better off in the future.

Unfortunately it was past midnight by the time that I posted the answer, which meant that I hadn’t technically met my goal of posting an answer during the week of October 4th. However, I have rationalized that I did reach my goal, as it was still before midnight in the Central Time Zone (in which the goal has been set). Cheap? Yes… but I’m still happy with it!

I plan to answer at least two forum questions this week.

Now for the punch line: The thread that I answered was posted on January 23rd*, so my effort probably has little-to-no value for Anjali Vishwakarma! I’ll chalk that up to being a forum newbie. Tim tells me that this behavior has its own, very fitting and humorous term on ServerFault/StackOverflow. Hopefully the answer will be useful to somebody else, in the future, when they are researching deadlocks.

* I noticed the dates in the deadlock graph, thought that it was strange that the poster needed help with a deadlock from so long ago, but failed to make the connection that I was dealing with a long-forgotten thread. Remember that I said I was sleep deprived.

1. Deadlock Detection, Troubleshooting, & Prevention at 8:30 a.m.
2. Leveraging SQLDiag for Efficient Troubleshooting at 11:00 a.m.

The latter will be my first public delivery of that presentation, the same one that I will be giving in less than a month at the PASS Community Summit 2009! I hope to get a lot of good feedback so that I can continue to refine it.

As before, with SQLSaturday #17, a secondary reason for attending is to gain greater insight into the workings of a SQLSaturday event, in order to apply the experience to the North Texas SQLSaturday event that we are planning. I learned a great deal from a great blog post by Stuart Ainsworth (blog, Twitter), so it will be great to see him in action (he’s also the event coordinator of SQLSaturday #25).

I’m fortunate to get to travel with another friend from the user group, Tim Costello (blog, Twitter). This is going to be a fun trip!

After having learned about the SQLSaturday concept a year or two ago, I’ve wanted to attend one. Unfortunately, there haven’t been any in Texas*, despite our thriving SQL Server community.

This probably seems obvious, but it never occurred to me to travel to one. It wasn’t until I heard that Tim Mitchell (blog, Twitter), a friend from our user group, was doing just that, presenting to (at least) two SQLSaturday events in Florida recently. What a great idea&em;SQLSaturday is certainly worth some traveling! My wife agreed, and we began budgeting for such a trip.

Tim let me know that he was presenting at SQLSaturday #17 and invited me along. I decided to join him, based largely on the following reasons: my long-standing desire to attend a SQLSaturday, my goal to practice delivering technical presentations as much as possible before my PASS Summit session, and the change to observe the organizing/running of a SQLSaturday (to serve as a model for our own*). I submitted an abstract to the call for speakers and delighted that it was accepted. I will be delivering my Deadlocks: Detection, Troubleshooting, and Prevention presentation that I’ve already given to both local user groups. The presentation details were truncated by the SQLSaturday web site, so I’ll post the complete details here:

I’m really looking forward to it! I’m sharing a rental car and hotel with Time, so I’m glad that I’ll get the chance to know him better too.

If all goes well, I’ll try to attend SQLSaturday #21 or #25 in October, presenting my Leveraging PSSDiag/SQLDiag for Efficient Troubleshooting topic. Stuart Ainsworth (blog, Twitter) is courting me for SQLSaturday #25, so that one is in the lead right now. Another friend from NTSSUG, Tim Costello (blog, Twitter) is also planning to attend SQLSaturday #25, so that is an additional reason to go.

* I’m part of a team (the NTSSUG board plus Tim Mitchell) working on bringing the SQLSaturday experience to North Texas. We had a great conference call with Andy Warren (blog, Twitter), a founder of SQLSaturday, and plans are starting to come together. More details will follow in the coming weeks.