Archive for January, 2012

Over the last 6 months or so I have spent more time trying to find the cause of a problem more than anything else.  The results are interesting, and I am starting to see a pattern that is proving to be successful.  It doesn’t matter if I am working on a performance issue, or just trying to figure out why something is not working.  The most common problem that I see time and time again is performance. For the most part as soon as you get the system up and running or features configured, they pretty much stay that way.  However, with performance it changes. It changes when the data changes; new releases can be one cause; another common cause is business.  When I say business, I am referring to growing your data, or the changes in services your company is offering (say for example your company has decided to see to a new market share, and the sales doubled). The short of it is when a business is not growing and it is just staying static there isn’t much long term hope for it.  Stock prices alone take drastic up turns and down turns just based on growth percentages. 

So you have been presented with a problem, let’s say it is a performance problem and you are hearing about it from someone at the help desk.  The complaint in the ticket says that the database is not performing like it should.  The rest of the information you receive from the ticket is not very helpful.  You have not been given the complete picture, you don’t even know what part of the database is slow, so how do you treat it as professional you are?  I have a few tips for you that I hope will help.  I have developed these tips over years of learning the things the hard way.

  1. Always get the description of the problem from the source.   Skip the help desk and the ticket system. If you can, go sit down with the person who is reporting the problem.  Let them show you where they see the performance problem. Let them show you how this problem creates problems in their life. A query that takes 3 seconds to return to a customer service person may not be considered a big deal.  But wait until you are on the phone with a customer screaming their head off wanting to know why they were charged an extra $3.00.  The 3 seconds is pure hell for the person answering the phone.  If you can make this a lot faster, then you can make the job a bit easier. By learning what else can be done, and then fixing these problems you are now the hero.
  2. I think it was 6th or 7th grade where I learned all about the scientific process, the part where you hypothesize, then run your tests, document your results, and then draw your conclusion.  I remember when I was learning about this, thinking when the heck I am going to use this.  I had no plans on being a scientist, so I just didn’t see where this was relevant.  Now, my work does not include cutting up frogs, but I have found a way to use those old science class skills.  When you are troubleshooting a problem make sure that you know what you are testing, what you want to test, run your test, measure your test and then record it.  Once you are done document your results and determine if you were right or wrong.  If you’re wrong, start again.  But make sure that you are only testing one thing at a time.
  3. Remove many potential issues in a test as quickly as you can.  Let’s reflect back to poor performance –  you need to determine as quickly as you can if it is the database. If it is, then where is that problem in the database?  One of the first places that you are going to want to look is your wait times.  Run a query against the sys.dm_os_wait_stats DMV.  If you can isolate a process like returning a client, and you can isolate that on a specific server,  stop all the other traffic , measure the wait stats, record them, run your process and then run them again.  The delta between the two runs will give you a good head start on where you should look

One thing to keep in mind, when you use this method to eliminate many potential problems, or even identify problems, be sure that you understand the complete problem.  Let’s say you have a high number of disk waits. These could be caused by many reasons.  Many DBA’s may start to point at the storage as part of the problem; however you may be setting yourself up to fail.  A lot of disk reads could indicate poor indexing, or poorly written queries. 

The way that you trouble shoot problems is going to say a lot about you.  If you keep calm and document well developed thoughts, I think your problem will be behind you in no time!  But if you sit around pointing fingers at everyone else and then freaking out when it might be a database issue, then you are going to have a stress filled day.  If you don’t change your process, it will be filled with a lot of stress for your career.  I would love to hear what trouble shooting technics you use, drop one of two in the comments section for me.

SQL Saturday #104

Posted: January 12, 2012 in Events, SQLServerPedia Syndication

It was September or October and the board members from the Colorado Springs SQL Server Users Group was sitting around at Starbucks talking about potentially following up SQL Saturday 66. We didn’t know what our theme was going to be, and we didn’t know when the date was going to be. But, we were determined that we were going to do it again. We talked and talked about it and picked out some pretty lofty goals or at least that is what we thought. We set a goal to double the registrations but we were going to stick to the same amount of sessions that we had for SQL Sat 66. We agreed and we set out on our mission. Within just a couple weeks we had more speakers then we had room for, a couple weeks after that we determined we could add two more tracks. But we had to stop accepting sessions for speakers. Before we knew it we had 36 speakers on their way to Colorado Springs.

Before too long SSWUG and Solid Q contacted us about hosting a Pre-Conference day, soon after Conifo joined in and we were well on our way.

If you are looking for more Photos you can check them out here with a HD Video.


The End Result?

Well on January 7th, 2012 we had SQL Saturday 2012. The event had so many people involved that I know if I were to sit down and try to list them all that I would forget many of them. If I tried to tell you all the stories I would miss some of the best ones. So, I want to ask… no, I want to formally request that those who were at the event, to send along a blog post, or a paragraph or two (If you post a blog, please link back to this so I can make sure that I get each of these shared). I will put these here on this blog post for everyone to see. Tell me what you liked; tell me what you didn’t like. After a week or two I will share with you some of the statistics and do one final wrap up. I can tell you that we tripled our in person attendance numbers. We had more people come from outside Colorado Springs to the event than we did people from Colorado Springs. We had lots of friends, lots of hugs an even a tear or two. But I think you will see if anyone sends me anything that I think everyone got something out of the event.

We are working on a site where we can post up all the pictures. That link will also be included in my final wrap up post, but if you really want a little taste, take a look at the bottom of this post, this is just a taste of what’s to come.

Blogs about the event:

http://diditsave.wordpress.com/2012/01/09/sql-saturday-104-recap/

http://www.real-sql-guy.com/2012/01/i-was-high-all-weekend.html

http://tjaybelt.blogspot.com/2012/01/sql-saturday-colorado-springs-104.html

So what are you waiting for? Let me know what you thought.



My New Title :O)

Posted: January 10, 2012 in SQLServerPedia Syndication

This last couple weeks things have been moving non-stop for me. Between hosting SQL Saturday 104 and keeping up with work I have barley been able to keep my eyes open. In the next day or two I will post a message all about SQL Saturday, but today I want to talk about my new position with PASS. I have been appointed a RM in the South East United States. I am one of 3 RM’s for this area, and I am really excited about it. The guys I work with I have known for a couple years, and I know that with the group of us we can really make an impact to the chapters there.

There are a number of tasks and responsibilities that come with the position, in addition to those I want to do what I can to bring SQL Saturday events to cities that have not had them. I believe that these are some of the best events around and the value is priceless. In addition to that I would love to see each major city in our area to have a PASS Chapter. So if you are a chapter leader in the South East area, I would love to hear how I can help you or your user group.

I did want to make one last note about the warm welcome and the long list of congratulations that I have received. The well wishes were very warm and very much appreciated. I can tell you that all these messages have been very humbling. When it was announced at SQL Sat 104, I almost got a bit choked up. I have to tell you that it is very touching to me to see such a warm welcome. I hope I don’t disappoint anyone.