Based on the great feedback that I received from my several public presentations and rehearsals, I made major changes to the talk over the last few days. I removed most of the material from the introduction and troubleshooting methodology sections, so that I could get to the demonstrations (and eye-candy) as quickly as possible. The edits made a big difference; I didn’t bore or overwhelm the audience with too much conceptual material, plus I didn’t have to race through the case study and demonstrations.

Here are a few highlights or observations:

• Prior to the start of the session, my friend Tim Mitchell (blog, Twitter) made a special point to come encourage me and offer any assistance that might be needed… even though he had another session to attend!
• I also appreciated the support of my friend Patrick LeBlanc (blog, Twitter), who was in the audience
• There was a very good turnout, far larger than I expected. I printed out fifty copies of each handout but there were not enough to go around. I didn’t have a chance to get an exact count, but I would estimate that about seventy-five people were present!
• I had a problem with one of the demonstrations (creating a SQL Server Agent alert for launching SQLDiag). I developed it against a default instance but was demonstrating it against a named instance, so the performance object name was wrong. Fortunately the audience was helpful in fixing the problem
• I was actually working on addressing this problem on the flights to Seattle (by retrieving the appropriate name from the [sys].[dm_os_performance_counters] DMV), but I neglected to finish it after getting here. It will be fixed before I post the code
• My other gaffe was that, early on, I decided to walk down and in front of the dais to be closer to the audience. I got over to the stairs before realizing that this just wasn’t a good idea and turned back. I’m sure that it looked awkward (and amusing)
• Because of the restructuring, I was able to stop and solicit questions at several key points, which helped to draw the audience into the talk
• I got to use "it depends" to answer one of the questions!
• Tim Mitchell also slipped in at one point to snap a picture of me talking. I brought my camera to the session, but forgot to ask for a volunteer to use it, so I was pleasantly surprised by his thoughtfulness
• I didn’t end up having time to cover the "’Strategies’ to Avoid" slide. I’ll write a blog post that explains the terms
• I only had time to cover a fraction of the original material… I could teach a full-day on this topic! It’s going to be important to publish quite a few blog posts to supplement the material
• Still, my main goal was realized: I managed to introduce many people to these invaluable, free tools that Microsoft’s engineers have developed (specifically PSSDiag, SQLDiag, PAL, SQL Nexus, and the RML Utilities)
• I hope to hear from many audience members as they have a chance to start experimenting with these tools and leveraging them at work
• There was a really good group that stayed around after the talk to ask questions
• While answering those questions, the lamp in the projector blew out. I was very fortunate that it waited until after my presentation ended!
• Tim Benninghoff (blog, Twitter) came up and introduced himself. We have interacted a bit on Twitter and I helped him with a PowerShell script back in May. This was great, since he was on my list of people that I was hoping to meet at the PASS conference!
• Only one person was playing #SQLBingo, which was a little disappointing!
• I have spoken to both Colin Stasiuk (blog, Twitter) and Greg Larsen (blog, Twitter) about delivering the talk as a webcast for their user groups (the Edmonton and Database Administration virtual chapters, respectively)

]]> http://sqlserversleuth.com/2009/11/05/looking-back-on-my-pass-presentation/feed/ 4 tnbarkhouse http://sqlserversleuth.com/2009/10/12/my-first-forum-contribution/ http://sqlserversleuth.com/2009/10/12/my-first-forum-contribution/#comments Tue, 13 Oct 2009 00:26:07 +0000 tnbarkhouse http://sqlserversleuth.com/?p=131 Continue reading →]]> NOTE: This post was composed on an airplane on 2009-10-11.

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.


]]> http://sqlserversleuth.com/2009/10/12/my-first-forum-contribution/feed/ 1 tnbarkhouse http://sqlserversleuth.com/2009/04/13/a-solution-of-my-very-own/ http://sqlserversleuth.com/2009/04/13/a-solution-of-my-very-own/#comments Mon, 13 Apr 2009 21:20:31 +0000 tnbarkhouse http://tnbarkhouse.wordpress.com/?p=13 Continue reading →]]> Typically, when I’m faced with a SQL Server problem, I perform research until I discover a solution. I have many sources for research… here are a few (and the order that I typically follow) for troubleshooting specific error codes and messages:
1. [master].[dbo].[sysmessages] (SQL Server 2000) or [master].[sys].[messages] (SQL Server 2005 and later)
2. The Microsoft Knowledge Base
3. Books Online: SQL Server 2000, SQL Server 2005, or SQL Server 2008
4. Search engine
5. Newsgroups and forums
6. Any of several colleagues

Regardless of the source, I submit query after query and constantly refine my search terms. After sifting through enough results I will have the answer. Sometimes it’s presented to me in complete form, other times I must synthesize the solution from several partial answers. I have been remarkably successful as a DBA just from honing my research skills.

As my knowledge of SQL Server deepens, there have been those rare occasions in which I come up with an answer of my own. An escalation call on Saturday led to such an occurrence.

NOTE: This escalation call dealt with a SQL Server 2000 instance, so that is the version that I’ll be targeting with the various links.

A customer had rebuilt all of the indexes in a ~300 gigabyte database and then they were surprised when the data files grew. One of the data files had doubled in size but was only using half of the space. This was leading to free space alerts on the volume hosting a few data files (the alert threshold was 15% and the growth resulted in only 8% free space on the drive). The customer requested that we shrink the files.

I’m not going to get into the many reasons that free space in a data file is beneficial or the many issues with shrinking data files.

I decided to start by running DBCC SHRINKFILE with the TRUNCATEONLY argument. I received error 3140: “Could not adjust the space allocation for file ‘%ls’.”

As usual, I began to research the error message using the above-mentioned resources. I found many people asking about the issue, but the best answer applied only to SQL Server 7.0.

I’m not sure why, but I decided to stop researching and try to figure it out myself. Since the error message relates to space allocation, I decided to run DBCC CHECKALLOC. The command finished quite quickly with “CHECKALLOC found 0 allocation errors and 0 consistency errors in database ‘RedactedDatabaseName’.” at the end of the output. I considered running the full-blown DBCC CHECKDB when I had an idea… what if the problem was a variation on the SQL Server 7.0 bug that was still present in SQL Server 2000? Since the known bug related to index allocation discrepancies, I wondered if running DBCC UPDATEUSAGE would help. Other than the somewhat trivial server resources that it would take to report and correct inaccuracies in the [master].[dbo].[sysindexes] table, it couldn’t hurt, right? So I gave it a try. DBCC UPDATEUSAGE took eight minutes and twenty-one seconds to run and made 238 corrections. A subsequent execution of the DBCC SHRINKFILE command (with the TRUNCATEONLY argument) finished in six seconds and returned 5.72 gigabytes to the file system. My hunch paid off.

It was my own understanding of indexes and experience with the DBCC UPDATEUSAGE command that ultimately provided the solution to this problem! It’s so gratifying when answers come as much from me as any other source–a situation that grows more common all the time.

As far as the escalation call, I wrote an email to the customer and laid out five reasons not to shrink the file any further. The customer agreed and the disk space threshold is being changed from 15% down to 10% (which is perfectly reasonable in this case).

Finally, two PSAs:

• Please consult an experienced database professional before implementing widespread index maintenance. Index maintenance is very important but it is also costly and can lead to disk space issues (data file and transaction log growth). Improper fill factor values for your workload may actually make performance worse.
• Please consult an experienced database professional for database file capacity planning. In a well designed/managed system autogrow should not occur (being a fail-safe mechanism only) and files should not be shrunk.

]]> http://sqlserversleuth.com/2009/04/13/a-solution-of-my-very-own/feed/ 0 tnbarkhouse