First off a few pieces of news…
SQL Server CTP3 – Well in case you have not heard yet, the third CTP is out as a download from Microsoft. The product otherwise known as Denali is a much anticipated release. I cannot wait to get my hands on it.
Congrats – First and foremost I want to pass along a congratulations to a friend of mine. TSQLprincess (Blog) just published her first article on SSWUG. I can’t tell you how happy I am to hear that she keeps on working with SQL Server. TSQLPrincess or “T” as I call her has worked really hard not only at her job, but also with the local SQL Server Group. It takes a lot of support from your friends and family to be able to do something like this. Most of all it takes a lot of dedication and the willingness to put yourself out there. Believe it or not, this can be very difficult for some people.
SSWUG Article – Last week I had an article published on SSWUG. The drive for me doing that one was the fact that I have been asked the interview question on the differences between a Delete and a Truncate. Way too often I have heard all about the logged and not logged answer. Besides that fact that this is not necessarily true, there is so much more to it.
Simple Talk Article – In addition to the SSWUG Article I also had an article printed on the Simple-Talk website. I have never done anything for Simple-Talk before, and with this being a new posting I am really happy with the number of views it has already. This article is setting the ground work for the completion of my book.
On a second note – I wanted to pass along a troubleshooting skill that I have to continue to remind myself about; it is so easy to go down the rabbit hole. To say it another way, past experiences with a database can sometimes lead you in a direction when you are trying to find the cause of an issue that may not be the exact cause. Let me explain… I have a number of databases that I work on. Some of these databases see performance problems on occasion, and most of the time I know what is causing the performance issues. Logically it makes sense to look at issues that return time and time again. First, it saves you time and most likely you already know how to correct it. But what happens when a problem presents itself in a fashion that is very similar to common issues that you are working on?
The first step to troubleshooting needs to be reviewing if the alerted or reported problem is really a problem. Is this an actual issue or is this a perceived issue of some sort? Granted the database often gets the blame when other items may be the root cause. Think of times before you understood database, think of topics that you may not be an expert in. For example, my nose is running over the last couple of days. It is natural that I think that I may be close to getting sick. It’s far from reality (knock on wood) it really is just my allergies from some cottonwood trees we have around here. But on the surface when my wife hears my nose running and I am walking around all day whining about my sinus headache she thinks that I am sick. Her perception of my health is her reality. If the department at my office cannot get to the data, the impression may be the database is down. The reality is it could be the network, or the client machine or countless other items, but as far as they are concerned it is either up or its down.