Why SQLbility.com?

Many of us have heard of several rules of thumbs how to use a SQL Server correctly. To do this, to avoid that. Over the years, I have started to proof these given rules. As I expected, there was a big "it depends!" in most of them.

My mantra is that I will only belive in facts I can measure.

As some of you may know, I'm originally a developer. And one of my primary patterns is to automate as many activities as possible when analyzing and optimizing a complex SQL Server environment. And this quest allowed me to develop a lot of interesting tools.

And, on my journey, I found many new facts (and, of course, rules) I have never expected.

Why not a blog?

My first thought to share my experiences was to post them in a blog. But then I realized that I need a media to improve each of the tests and articles over time. Using a blog could confuse readers when I often update a published post or post frequently additional insights into a given topic. I want to deliver a smooth reading & learning experience to get the most out of the facts.

What means SQLbility?

In my experience, a solid knowledge of the SQL Server internals combined with real experience makes sense for any developer and, of course, administrator.

I like to call it SQLbility.

And this website is intended to be a shortcut not to have to make all the experiences and mistakes by yourself.

I want to help you to increase your SQLbility!

What will we cover here?

First at all, there are many myths and rules about the correct usage of indexes. So, we will take a very close look at many of them.

• How many indexes should my table have?
• How many indexes are too many indexes?
• Are indexes will always decrease my writing performance dramatically?
• Can I avoid indexes if I write my queries in a better way?
• How bad is this index fragmentation thing?
• Why should I care about indexes? Our tables are quite small! And we have more than enough RAM for our SQL Server instance. So, most of our data are in 'cache'.
• Will optimistic concurrency harm my writing workload? How bad is it?

And to make things even more complicated, we also look at query plans.

• Why everybody makes such a big noise about lookups in query plans?
• Why could nested loops be so dangerous? They look very efficient, don't they?

Finally, you will be faced with really nitty-gritty details of the SQL Server engine.

• What is this Latch thing? Can we measure it?