Don't expect any activity here for at least a couple of weeks as we're leaving today for a long-overdue dive trip (on the Belize Aggressor) - our first diving for almost 18 months. I'll post lots of photos in December...

In the meantime, please go run the index survey code from my last post - the more data the better!

Cheers

Jonathan Kehayias is such a nice guy. After our recent perf tuning Immersion Event in Chicago last month he had an idea for each of us to pick someone who's attended a SQLskills class and offer general mentoring (career, technical, professional development - whatever) to them for a few hours a month for six months. After six months we each pick someone else. His thinking was that this would be a cool way for SQLskills to give back to the community outside of the purely company-related things we do like blogging and twitter.

I think this is a really great idea. Back when I was at Microsoft I did a lot of mentoring when I managed teams there, plus in the company-wide mentoring program between senior and junior people in different groups. It's very rewarding to provide completely altruistic advice to someone and watch them grow.

Furthermore, we all have had people help us with our careers so it's important to pay that help forward.

So we're doing it, starting today with me, Joe, and Jonathan (Kimberly will join in before the end of the year as well).

Joe is going to mentor Luke Jian, who's attended our IE1 and IE2 classes in Chicago this year:

Luke Jian is a well-versed IT professional with over 15 years of experience in the development and implementation of pharmaceutical and healthcare systems, demand driven supply chain management, ERP systems and technical infrastructure design.

Luke's current role is Sr. Solutions Architect with Physicians Interactive a leading resource for healthcare information, medication samples and medical decision support tools. Luke's experience include managing the IT Operations of over 50 clinics,  Oracle DBA for a supply chain software company, Teaching Assistant and Trainer.

Luke holds a Masters degree in software engineering from “Politehnica” University  of Timisoara, Romania with concentration on relational databases and  is fluent in English, Romanian, French and German. He became a US citizen in June 2011, the same week as his first public speaking engagement at SQL Saturday #82 in Indianapolis.

Luke writes at http://blog.sqlpositive.com  and he can be reached at sensware@gmail.com or on Twitter as @sensware.

Jonathan is going to mentor Steven Ormrod, who's attended our IE1, IE2, IE3, and IE4 classes in Dallas, Chicago, and Bellevue this year:

Steven Ormrod has been working as a Database Administrator for an international purveyor of natural and organic foods for the past several years.  Recently, Steven accepted a position with a global provider of orthotics and prosthetics.  His environment contains hundreds of servers spread across three different countries.  Clustering and consolidation projects have been his primary focus.

He has an MCITP for SQL Server 2008 in Database Administration and Development.

Prior to working as a DBA he has been a software developer, system administrator, and a teacher.  He also spent a summer bartending and hitchhiking across Europe.

When he is not tinkering with technology, he enjoys cooking, traveling, and snorkeling. He blogs at http://sqlavenger.wordpress.com/ and is on Twitter as @sqlavenger.

I'm going to mentor Brad Hoff, who's attended our IE1 and IE2 classes in Chicago this year:

Brad is originally from WA and is working in TX as a Lead SQL and Oracle DBA for an international power development company and energy marketer.

Brad has a degree is in Electronic Engineering and his background includes Development, Network/Systems/SAN admin, and WAN/T-Comm.

When Brad's not working with SQL server, he enjoys philosophy, debate, brain-teasers, learning, anything that challenges his mind. He has a beautiful wife and an awesome 17-month-old son. He blogs at http://www.sqlphilosopher.com/wp/ and is on Twitter as @sqlphilosopher.

I'd like to congratulate these three guys and look forward to us helping them out over the next six months!

Days like this don’t come around very often for us here at SQLskills.com – we’re expanding again! It’s been seven months since Jonathan Kehayias came on board and we’ve had a huge amount of fun together. Now business has expanded to the point where we need to grow again so it’s time to hire the next member of our close-knit, expert team.

Specifically, we’ve asked Joseph Sack to join us and we’re extremely pleased that he accepted our offer. He’ll become employee #4 when he starts with us on Monday, October 3rd.

Joe has worked in the SQL Server space since 1997, and we first met him back in 2006 when he was a Premier Field Engineer at Microsoft and he was in one of the early SQL Server 2005 Microsoft Certified Master (MCM) rotations – which he passed! He then went on to get the SQL 2008 MCM certification and finally took over responsibility for the whole SQL Server MCM program within Microsoft from 2009 to 2011.

It was while Joe was running the SQL MCM program that we got to know Joe really well and gain an appreciation for his extensive SQL Server knowledge and enterprise consulting expertise, as well as his passion for developing content and helping people learn – whether as a consultant or as a teacher.

In fact we respect Joe so much that recently we asked if he’d like to get back into the wild and varied consulting life by leaving Microsoft to join us. We feel honored that he agreed. He brings a wealth of performance troubleshooting, development, scalability and architecture expertise to the team and maintains the high bar we have of all team members either having MCM certification or being MCM instructors (or both!).

With our increased full-time consulting team we’re now able to meet the burgeoning demand for our services, including our new Remote DBA Service that we announced earlier this week. Joe will be blogging on SQLskills.com and hanging out on Twitter (@JosephSack) and in the community with the rest of us.

As you can tell, we’re very excited to have Joe join our team!

Thanks as always,

Paul and Kimberly

Cue spooky music... I used to love the X-Files, where one of the catch-phrases was Trust No One.

Their other major catch-phrase was The Truth Is Out There.

Yes, it is - but you're likely going to come up against all kinds of obstacles to finding it, just like Agent Mulder did.

Now, searching for true answers to your SQL Server conundrums is unlikely to make you the assassination target of shadowy government agencies or lead to you or your family being abducted by aliens - although the list of undocumented trace flags is a very closely guarded secret...

The problem is that there's so much crap out there on the internet. And I'm not being dramatic here - there really is some *utter rubbish* being written about SQL Server that only serves to confuse and mislead people.

But how do you know who to trust?

What about Microsoft? You'd think that Microsoft itself is trustworthy all the time, right? Wrong.

Case in point: the Microsoft whitepaper that was published in May about performing SQL Server maintenance for SharePoint 2010. It was full of all kinds of nonsense such as:

• Run CHECKDB, and if it shows problems, run repair to fix them (without any mention whatsoever of backups or the problems repair can cause).
• After shrinking a database, grow it again and then rebuild all the indexes.

I couldn't believe it when it was published! I offered to rewrite it and it's since been republished with correct info in it.

Anyone inside Microsoft can publish a blog on MSDN or a whitepaper without any kind of peer review by the SQL team and then it becomes the Microsoft official word on the subject. This has caused no end of problems for DBAs, consultants and others who have to work really hard to correct ingrained misinformation from well-meaning Microsoft people.

Don't get me wrong, Microsoft is great - but being The Source itself, it's deemed inherently trustworthy, so how do you tell whether the blog or whitepaper you're reading is written by someone qualified to disseminate information/guidance to a wide audience? Stick to those whitepapers and blogs published by (or through) the SQL Server team, the SQL CAT team, and to the information in Books Online (which is improving in leaps and bounds). Take anything else with a pinch of salt. Even from the excellent CAT team, for instance, some of their advice is based on them dealing with very large enterprise customers running SQL Server on honking big hardware - and doesn't translate well down to smaller SQL Servers with lower workloads.

Also consider the publication date of a whitepaper/blog post, and which version of SQL Server the whitepaper/blog post is referencing - behavior may have changed drastically since then.

What about 3rd-party tools? You have to be very careful with these too. Look at the problems you can have if you create all the indexes DTA advises. Read my rant against one of the tools that was recommending dropping indexes because it wasn't considering INCLUDEd columns in the index definitions. Tools and their recommendations are only as good as the people who write them - if *they* are incorrect in their knowledge or assumptions, so will the tool be.

What about blogs? There are a *ton* of people blogging about SQL Server, across all levels of knowledge and experience. You have to be careful. Everyone starts with zero knowledge and experience about SQL Server, and no-one is an expert in all areas of SQL Server. For instance, I only blog about the areas I consider myself an expert in - and I only ever blog about things I'm 100% certain of, or I blog about how I'm finding things out, like in my benchmarking series. But nobody's perfect - I've made mistakes in the past and posted corrections, as have many people I consider experts. Look for blogs that are referenced a lot by people you've heard of in the community, and then still check what you're reading if you can. There are lots of people blogging and writing articles that contain poor advice, perpetuate myths and misconceptions, and are just plain wrong.

Enthusiasm about SQL Server is great, but accuracy of the information being presented is paramount.

What about forums? These are the most dangerous areas of the Internet for getting poor or incorrect advice about SQL Server. Even on the most reputable of forum sites (e.g. MSDN or SQL Server Central), anyone can join and anyone can reply to forum threads. And it doesn't matter how many experience points a person has either - I know people with lots of points but often post misleading or incorrect replies. But saying that, there are many, many people who give good advice - just take it with a pinch of salt again.

Here's a classic example from the MSDN forums back in 2008. I just *love* the retort about autoshrink that "Nevertheless all high-priced SQL server expert consultants warn against using it.'

What about twitter? Very interestingly I find that the advice on twitter on the #sqlhelp alias is some of the best I've seen - a sort of collaborative, real-time debugging forum. I'm not sure why that is - maybe because there are so many well-informed people in the SQL twitter community.

What about training classes? This is a hard one for me to comment on as I don't want this to seem a plug for our classes. Anyone can set themselves up as a trainer and claim to be a SQL Server expert. I've heard horror stories of trainers reading slides, having demos that don't work and they don't know what to do, parroting marketing info or Books Online, and class attendees having to correct inaccuracies in material. I've also heard of instructors that cannot answer anything but the most basic questions about the material being taught. Before signing up for a class, do some research about the company and the instructors - look for good and bad reviews. Looks for their blogs and how well they're known in the community. There's good stuff out there, and there's also poor quality stuff too.

Summary

I'm sure some people will take this post as some sort of self-aggrandizement - that's not my aim in any way.

I'm just fed up of seeing people posting garbage and of having to defend the truth in the face of misleading misinformation.

Remember - The Truth Is Out There. Just be careful who you trust.

There are several reasons why I've drastically cut back on the amount of time I spend in the various online SQL Server forums, including:

1. People continuing to argue that the advice given to them is wrong (and I mean arguing even after me giving references suppporting the advice and explaining why my advice is correct)
2. People asking questions that they could have found the answer to in Books Online or by Googling (yes, I prefer Google to Bing) a few keywords

#2 is mostly sheer laziness IMHO.

When Kimberly was on the SQL team at Microsoft many moons ago, she was famous for replying on a 2000-person internal alias (paraphrasing) "If it takes you more time to type this email and send it to the alias than it would to look up the answer in Books Online, you're wasting 2000 people's time". She got 17 responses, 15 of which commended her. She has of course mellowed a little in her old age :-)

When one of my daughters comes to me saying they don't understand how to do a math problem, I always ask them if they have read the instructions at the top of the page in their math workbook. Usually the answer is no, in which case I refuse to help until they've read the instructions, tried the problem again, and can explain what they think they're supposed to do with the problem. The real world doesn't have a friendly Dad there all the time to explain how to solve a problem.

There are good reasons why products come with manuals, including:

• So that a company's product support is not inundated with simple questions, saving the company money
• So that people can easily figure out how to use the product's functions without bashing their head against a wall in frustration
• So that a company doesn't get sued by failed Darwin Award candidates
  • E.g. "Do not operate the TreeMasher X3000 chainsaw with the diamond-tipped CutThroughAnything (TM) blade while drunk"
  • E.g. "Do not attempt to unclog your new in-sink Eviscerator (TM) waste disposal unit using your hands while it is running"
  • E.g. "Consuming excessive Jägermeister in Seattle will result in uncontrolled karaoke singing"

However, sometimes reading the manual does no good whatsoever. For example, on our recent European trip, we rented a BMW in Frankfurt for a couple of weeks of touring around. For the life of me I couldn't figure out how to start the damn car. I tried looking in the manual, but it was in German, which neither of us understands. Eventually (after 15mins of increasing frustration) I figured out you have to press the start button while pressing the brake pedal. But that was my fault, not BMW's - the manual did say how to do it, but I just couldn't understand the manual.

Most of the time though, you can get a good idea of what you're supposed to do by reading the manual. We're currently writing the Denali JumpStart training material for Microsoft (like we've done since 2005 - see here for a description of the 2008 work). When we got hold of CTP-3 in early July we didn't install the VMs we'd been given and then start randomly playing with stuff. We read BOL for the features we're covering, and then started playing around. Why? So we didn't waste time.

Books Online is pretty comprehensive in terms of syntax and in the last year or two their guidance and background explanations have improved and expanded immensely - kudos to the BOL team! So at least have a look in there first.

There's a good reason why the website Let Me Google That For You exists - because people get annoyed when others ask questions for which the answer can easily be found. The LMGTFY tag line is "For all those people who find it more convenient to bother you with their question rather than google it for themselves."

Don't get me wrong, I really like helping people out on twitter, forums, and over email (to a point) - but I get really terse really quickly if someone sends me a question for which the answer is in BOL or shows up near the top of a simple Google search (e.g. a recent email I got was "where can I get a description of the what the input parameters to sys.dm_db_index_physical_stats are?"). You'll know if you've offended if my reply just contains a URL.

Bottom line: Don't waste everyone's time, including your own. Read The F-ing Manual. Search online. Do some due diligence. And then feel free to ask all the questions you want - we'd all love to help you. But only after you've invested a little time trying to help yourself first.

A couple of weeks back I kicked off an off-topic survey about which internet browsers and email clients people use. Here are the results:

The "Other" results are:

• 2 x "Chrome, FF4, IE789"
• 2 x "Firefox 5"
• 1 x "Avant"
• 1 x "Dragon and IE9 for flash content"
• 1 x "Home Firefox 5.0.1 and Safari (iPad) / Work IE 7"
• 1 x "Iron"

The "Other" results are:

• 12 x "Home gmail / work Outlook"
• 4 x "Gmail for private / Outlook 2010 for work"
• 2 x "Work - groupwise / home - gmail"
• 2 X "Zimbra"
• 1 x "GroupWise for work"
• 1 x "Groupwise for work / yahoo mail for personal"
• 1 x "Home Thunderbird / work Outlook 2010"

Summary

Personally I use IE8 on my laptop (don't use any other computers at home or work), plus Safari on my iPhone and iPad2. For email I use Thunderbird because I can't stand Outlook and wanted something like Outlook Express (in fact the only reason I agreed to upgrade to Windows 7 last year was because I found Thunderbird).

Interesting results. Outlook is definitely the most common email client and I'm surprised that Gmail is so far ahead of the other free email providers. The browser results are really split three ways (as the total number of IE users is 35%) between IE, Chrome, and Firefox - I wonder how many of the non-IE users are because Chrome/Firefox is better, or they just don't want to use IE on principal.

Hopefully these results will give some of you insight into where to focus blog/app compatibility.

This survey is off-topic and was suggested by Justin Dearing (blog|twitter) and I'm curious about the results too so I agreed to run it.

We're interested to see what internet browsers are most commonly used my members of the database community, along with which email clients. People are often fanatic about one browser/client or another and vehemently opposed to using others (I detest Outlook, for instance, and was overjoyed to be freed from it when I left Microsoft 4 years ago). Consider whatever is your primary machine and answer for that. If you want to answer multiple times, you'll need to do so from different machines so the survey site doesn't recognize you.

I'll report on the results in a couple of weeks or so.

Thanks!

PS No, I'm not changing which survey provider I use, and if you don't like the choices in the survey, that's unfortunate :-)

This is almost our catch phrase. In every class we teach Kimberly and I always say that the answer to every question about SQL Server *starts* with "It depends" - except one: "should auto-shrink be enabled?" :-)

Seriously though, there's a bit of an unnecessary backlash against the phrase "it depends" and I'd like to clarify why we think it's a totally valid way to start an answer.

I think the backlash stems from consultants and trainers using it as the answer to any question they don't know the answer to and then not expounding any further. That's a crappy way to answer a question as "it depends" on it's own doesn't really provide anything useful and I can totally understand people getting frustrated by that. I think that people would be much better answering "I don't know" rather than trying to cover up lack of knowledge by simply saying "it depends" - there's no shame in admitting you don't know something - nobody knows everything about SQL Server.

I find the denigration of the phrase annoying though, as nearly all the answers really do start with "it depends". I don't want this to turn into one of those marketing-ish 'hire-us' blog posts, but one of the reasons Kimberly and I are so well-known for saying "it depends" is because we spend so much time in our classes explaining *why* it depends, *what* it depends on, and *when* it depends. Occasionally I can even say *who* made it depend too :-) We even have "It depends" emblazoned on the back of our SQLskills instructor t-shirts.

Almost as bad as saying "it depends" without the follow-on explanation is saying the answer is *always* such-and-such. That can be really damaging as nothing is black-and-white (except not using auto-shrink! :-) but teaching that it is can lead to propagation of misleading information out into the community.

My challenge to you: next time you hear someone say "it depends", ask them to explain. You'll get a really good feeling for their depth of knowledge and honesty if they can explain to your satisfaction, as otherwise "it depends" is really saying "I don't know".

And don't be scared to say "I don't know" - you'll get way more respect than trying to BS an answer.

About a month ago I kicked off a survey around regularly rebooting SQL Server (see here). There is much debate about rebooting SQL Server (or Windows Server hosting SQL Server), regularly or even at all so I've been looking forward to the results.

My view is that there are circumstances where rebooting, even regularly, is acceptable - but you have to have a good reason to do it because of the downsides of restarting the SQL Server process. These downsides include:

• The buffer pool goes completely cold. Warming up again requires reading (potentially a lot of) data back into memory, after allocating that memory from Windows.
• All query plans are lost and will need to be compiled again.
• All information about the state of SQL Server, used to give DMV output, is lost.

In other words, the steady-state for the production workload is lost and has to be attained again.

As you'll see from the results, the most common reason for a regular reboot is part of the Windows/SQL patching process, but there are plenty of reasons cited that are NOT valid in my opinion, and some others that are.

The "Other" responses are:

• 101 x (paraphrasing) "After windows/SQL/firmware updates that require a reboot."
• 30 X (paraphrasing) "Quarterly."
• 10 x "Only if any problems occur or any maintenance activity scheduled in off hours."
• 5 x "Only if I've observed some resource contention after some time. Usually a result of not being able to implement the solution and having to work around the problem."
• 4 x "Every two months."
• 1 x "I normally go 360+ days between reboots. And then it's just for giggles. No indication it is needed or required."
• 1 x "I would like to do it monthly but my boss doesn't support it."
• 1 x "Yes, every two weeks."
• 1 x "Yes, twice a week."

The "Other" responses are (I've commented on those in bold):

• 74 x (paraphrasing) "MS security patches - manually installed after testing them on duplicate system."
• 67 x (paraphrasing) "As part of the monthly MS patching."
• 17 x (paraphrasing) "No regular reboots."
• 9 x "We reboot our SQL servers about twice a year average for updates or other issues."
• 6 x "As required for patching activities and only after ensuring that the potential for patching has been reduced by eliminating non-required components and programs."
• 4 x "After patch installation or maintenance such as password updates to test cluster failover."
• 3 x "Process unkilled and some memory problems."
• 2 x (paraphrasing) "Because the business demands it, for no valid reason."
  • You need to work out why that process was put in place. My guess is that it's based on historical requirements to do so on older operating systems, or because of bugs, and it's just stuck. Very likely the process can be removed if the reboot schedule is very frequent (e.g. daily or weekly).
• 1 x "I have issues with a CLR process."
  • Then try to fix that process/code rather than resorting to a reboot.
• 1 x "I've been told that certain errors won't be reported by Windows without a reboot."
• 1 x "Last rebooted about 50 days ago - only reboot when necessary (patches)."
• 1 x "Microsoft Insists."
  • I don't buy this one, unless it's to work around a specific bug that will be patched at some point.
• 1 x "Nightly reboots of a specific SQL Server are required by the vendor whose app it supports."
  • This is badly messed up and you need to push back on the vendor. My guess here is that they have a leaky application (i.e. memory leaks) and this is their solution.
• 1 x "Non Windows app memory leaks."
  • Again, try to fix the memory leaks rather than resorting to rebooting.
• 1 x "Our application becomes unstable otherwise."
  • Fix the application...
• 1 x "Regular test of clusters AND SQL Server performance degrades without restart."
• 1 x "Save power, turn it off at night."
  • This is interesting and one I haven't considered before. Are you sure the gain in power saving is worth the downsides I mention at the start of the post?
• 1 x "SQL Server connection time out error."
• 1 x "VMware Snapshot."
  • This I don't know about (that's why I employ Jonathan :-), but I'd be surprised if this process requires the server to be rebooted.
• 1 x "We do full server backups weekly. we briefly shut SQL, copy c drive where OS and SQL software live - paging file etc. then bring SQL up and finish server full backup. This takes approx 5 min per week."
  • This is messed up. SQL Server and Windows can both be backed up without having to be shut down.
• 1 x "We have a weekly Maintenance window and it keeps the event logs manageable."
  • This is messed up. Windows and SQL logs can be cycled without rebooting.

Quite interesting results.

There have been many problems of the years which have required regular reboots to clear, but these are *mostly* gone with the advent of Windows Server 2008/2008 R2. I think there are three main reasons which still are valid for rebooting regularly:

1. As part of Windows/SQL/firmware patch installs.
2. To test failover procedures.
3. To work around a Windows or SQL bug.

As an example of #3, there's a problem still in Windows Server 2008 with the file cache taking up all the memory, depending on which APIs are used to call it (see KB 976618). And what about the various SQL Server memory leak bugs over the years (e.g. KB 959007).

There are plenty of other symptoms that can be "fixed" with a server reboot. A great example of this is plan cache bloat from lots of plans for ad-hoc SQL queries. This can eat away at the memory available for the buffer pool to store data and cause the server performance to grind down (see Kimberly's post Plan cache, adhoc workloads and clearing the single-use plan cache bloat). And what about buffer pool memory being wasted by massive index fragmentation, resulting in poor performance (see my post Performance issues from wasted buffer pool memory). Or any of the reasons in bold above that mention and application instability, memory leak, or issue?

For these problems, rebooting the server is addressing the symptom of the problem, not the root-cause. We've had several clients in the last month where massive performance problems were being "solved" by failing over to the other cluster node, and they turned out to be caused from not having Lock Pages In Memory set (see KB 918483, and take care to note all the Windows bugs it explains that can cause working set trimming too). They were addressing the symptom without researching the cause.

Bottom line: if you're regularly rebooting Windows/SQL Server, make sure it's for a good reason and not just because someone thinks it's a good thing to do or it's the chosen way to fix a problem that should be fixed in some other way.

And don't immediately assume that someone who does reboot Windows/SQL Server regularly is an idiot - they may have a very good reason, or may just be ignorant... (see Ignorance is not stupidity).

Thoughts?

You're ignorant. About lots of things. Yes, you are.

Feel offended? We're all ignorant about lots and lots of things.

Last week I wrote a non-technical blog post The Golden Rule - maybe just optional now? about the growing lack of civility in the world at large. That elicited almost 40 responses (thanks!) so I'm going to intersperse more non-technical posts in with the technical ones - as I have a lot of views to express :-)

This one is about ignorance. In my opinion many people don't understand ignorance and take offense if you say they are ignorant about such and such. In fact being ignorant just means that you don't know something - it's not derogatory or a statement of blame.

And it definitely does not mean that someone is stupid. However, time and again I see ignorance equated with stupidity. This is very common to see on internet forums where question posters can be heavily railed on by more experienced people for not knowing X or Y about SQL Server. And do you think that's going to make them come back to ask more questions to learn about SQL Server? No.

[Edit: I'm not saying that people use the word 'ignorant' all the time, but the implication is there.]

An example: yesterday on a distribution list I'm on, someone asked what to tell a DBA who insists on rebooting SQL Server regularly. The first knee-jerk reply to the alias was unfortunately "You're fired!"

Wrong answer.

So often I see knee-jerk responses to problems and questions - and they're usually wrong - as in this case. Jumping to conclusions quickly can be damaging - something I used to do a long time ago when I first started my career and I was slowly trained out of it (thankfully).

The correct response to the original question would be to ask the DBA *why* the server is being rebooted and the rationale behind rebooting being the preferred fix for the problem. And then educate.

Here's something you may not have thought about: every single person in the world starts out with absolutely zero knowledge about SQL Server.

When I joined the SQL Server team on February 1st 1999, I knew zip about SQL Server. Now I know lots about many aspects of it, and still zip about many other aspects of it. The same goes for Kimberly. And Kalen. And Itzik. And many others that the community considers an expert in SQL Server. Nobody knows everything about everything, and everyone starts from scratch at some point in their careers.

Today there is a growing proliferation of involuntary DBAs who have to deal with the big, complex beast we know of as SQL Server. You can't expect people to know everything straight away. You can't expect people to necessarily know what they *should* know, that comes with experience. And even experienced DBAs who've learned that SQL Server does X sometimes don't know that the behavior changed and now it does Y instead. Sometimes people aren't given time to learn by their employers, and non-work commitments stop them spending hours of their own time learning.

So next time you see someone asking a question that you think is so simple that they should know the answer, or that *everyone* knows you shouldn't do X or Y, cut them some slack and educate them nicely. Empathize. Don't belittle them. Don't rail on them.

And don't equate ignorance with stupidity.

We've been off-line the last couple of weeks while we've been traveling around Europe and now I've got a bunch of blog posts to catch up on (plus a whole lot of photos of cool things to show you). But first, a rant that's been brewing for a while... something that really, really, really irritates me. And I'm sure it does for many of you too.

The more I've traveled around the world in recent years, the more I've become dismayed by how people treat each other.

There's an age-old maxim called The Golden Rule which basically states that you should behave towards other people in the way you'd like them to behave towards you. All major religions have famous sayings that encapsulate this ethic of reciprocity, and it's mentioned as early as 1800BC in a set of rules from ancient Babylon, so the idea pre-dates most major religions too. You can read more about it in this wikipedia link. It all really boils down to: be nice to people.

I've watched civility steadily being eroded over the last few years until now it's at the point where people are often pointedly rude to absolute strangers. How can this be? Maybe I'm old fashioned or in a minority and I'm not moving with the times, but I'm sure the times should not be moving towards a society where people don't abide by the basic rules of civility: say please and thank-you and consider other people around you. I guess it's a product of everyone being in a rush, feeling more important than others, and feeling somehow entitled to service or response without having to be civil to the one they expect service or a response from.

Some examples:

• At breakfast this morning in the hotel, I stood waiting while the chef cooked my eggs, and everyone who walked up while I was waiting neither said please nor thank-you to the chef, and some almost demanded what they wanted.
• Again this morning, an elevator opened on the ground floor, full of people, with a woman standing in front of the door with a suitcase. One businessman behind her pushed passed her to get out of the elevator first.
• At Heathrow on the way over from Germany, we came down an elevator and people pushed onto the elevator while we were still trying to come out with bags (this is *so* common while traveling).
• On the flight from Germany to Heathrow at the weekend, a small child was sitting behind Kimberly, kicking her chair and then reaching through between the seats and grabbing Kimberly. When Kimberly turned around to politely ask the child not to do that, the mother became indignant and said Kimberly must not have kids because that's just the way 3-year olds behave.
• On an overnight flight from the US to Europe a few months ago, a child was allowed to run around the cabin, shout and generally behave obnoxiously, with no intervention from the mother.

The list goes on and on. The last two are particularly indicative in my mind of part of the problem these days - lack of instilling the notions of civility and acceptable behavior in children as they grow up, and the belief that everyone should tolerate children's inconsiderate behavior because they're just children. Adult behavior is very much a product of upbringing IMHO.

And of course it spills over into work life too. How many of you have had to deal with belligerent or rude co-workers, managers, or clients? Why should you have to?

Email is the worst though - it's so easy to omit civilities. It's become so prevalent now that if I get a random request for help in email that doesn't say please or thanks, I just delete it right away... no civility, no help.

Take a look around you next time you travel, or take notice during your work day - you'll be amazed at how uncivil we've become as a society.

But please make sure you're not part of the problem. Thank you.

</rant>

I think many people imagine that technical acumen and razor-sharp problem solving skills are the most important skills to be a successful consultant. I would strongly disagree. While these two skills are *absolutely* essential for success, I think they are less important than the ability to effectively communicate with your clients.

Effective communication is a skill that doesn't come naturally to most people - it has to be nurtured, practiced, and perfected. I could break down "communication" into a variety of sub-classes:

• Presenting to a large audience
  • E.g. a conference session, or a large group of IT staff
• Presenting to a small audience
  • E.g. a class, or a targeted set of IT staff
• 1-<5 discussions with technologists (devs, DBAs, IT directors/managers)
• 1-<5 discussions with executives (VPs, CXOs)
• 1-1 discussions with technologists
• 1-1 discussions with executives
• Whitepapers
• Design, analysis, or strategy reports
• Status emails or general email conversation
• Business solicitations

Each of these requires a different approach. Before any kind of client presentation, meeting, or phone call, or when crafting a report or email, I ask myself the following questions:

• Who is my audience?
• What am I trying to convey to them?
• Is my message appropriate for the audience? (e.g. I wouldn't necessarily be discussing business implications of growth choices for the entire company's data tier with a developer, nor would I necessarily be discussing index tuning strategies for specific tables with a CIO.)
• What politics and inter-personal/departmental relationships do I need to be aware of?
• What would the ramifications be if my presentation/call/report/email was described or forwarded to another person/part of the company? (e.g. am I being asked to deliver some metrics/advice that would be unwelcome - but needed - in another department?)
• Is my communication in the overall client's best interests?
• Am I sure I have all the pertinent facts and details to be able to give my opinion credibly and correctly?
• Am I 100% sure of the technical content of my communication?
• Is my tone correct? (e.g. sometimes one needs to take the tone that 'you hired me because of my experience and knowledge, and in this case, respectfully, person X is incorrect' - but it needs to be done professionally.)

And of course everything needs to be concise, bullet-points instead of waffle-y paragraphs where needed, spel chcked, also grammer must be write actually two.

There's no excuse for incorrectness in written communications - many people have the opinion that sloppy communications indicates a predilection for sloppiness in other areas. I also subscribe to this view. Don't get me wrong - it's fine to have mistakes in tweets and the odd email - but consistent errors in emails, blogs and other professional communications doesn't look good. Seeing these things makes me cringe.

But so far I've only mentioned the consultant communicating with the client. The client's communication with the consultant is way more important. You have to be an 'active listener', where you're not just passively listening to the client but you're taking it in, processing it, making sure it makes sense, asking questions for clarification and so on. If you can't work out what you're being asked to do for the client then you're in trouble. It could be that the client isn't very good at explaining, in which case you need to restate what you think you've been asked to do so everyone's on the same page. Every few new clients we find we're following other consultants who didn't do what the client wanted because of communications issues, not necessarily technical deficiencies.

I am overwhelmingly pleased that I grew up into a manager and senior contributor in a fast-moving product group at Microsoft - there was no choice there but to communicate effectively (in all the various forms I listed in the first set of bullets above) - or be left behind - it was that simple. Trial-by-fire is a great way to learn.

If you don't have an opportunity like that, there are plenty of ways to practice - user groups, blogging, and whitepapers - and just making yourself be a better communicator wherever you work. And you might consider having a partner or colleague review certain key communications - Kimberly and I do that for each other all the time (like this blog post, for example).

Effective communication is an indispensable skill that I don't think enough emphasis is placed on in the tech community.

What do you think?

I was searching around in the US Patent Office database this evening to find my patent for consistency checking of a backup without restoring the backup, for a Twitter conversation I was having, when I discovered that another one I filed before leaving Microsoft was granted in late 2009.

The new one was part of the old WinFS system - it deals with doing consistency checks on partial user-defined complex data structures as they're being read from a streaming data source so that inconsistencies can be discovered as soon as possible. Unlike the backup one, I actually wrote the code to implement this one (although it never shipped when WinFS was canned).

You can read about the patent (if you have insomnia) here.

I always wondered if that patent was dropped on the floor - now I know I've got two software patents :-)

Cheers!

(Used with permission from Dilbert.com)

It's an interesting marketplace for DBAs right now. Depending on who you speak to, and what your view into the DBA world is, a few data points are evident:

• There's a view that all the good people already have jobs
• There's a view that it's pretty hard right now to hire good people
• There's a view that some companies are looking for unreasonable amounts of experience for new DBA hires
• There's a view that some companies are looking to give new DBAs way too much responsibililty

So this is all a bit of a problem. How can someone find a new job if many of the jobs are overly-demanding or look to be a recipe for over-stress? And how can companies expect to tempt people away from their jobs if the overall package isn't better?

Smart people working for good companies are going to realize that the grass isn't greener somewhere else, so will be making themselves more attractive to be retained by their present employers. And smart companies with good people are going to realize that they need to make sure they up the ante to prevent people looking for greener grass.

With all this in mind, I thought it would be interesting to conduct a survey to find out what companies are doing, if anything, to retain their talented DBAs, and what talented DBAs are doing, if anything, to show their companies that they're valuable employees. The original survey is here and this post is about the results.

It's worth reading the "Other" answers for each survey as they paint an interesting picture - with some lucky folks in dream jobs and some being treated very badly by their employers.

The "Other" responses are:

• 6 x Not replacing employee's that leave, increasing my work load. yes this is sarcasm...
• 5 x The company already is excellent for most of the above.
• 4 x I just joined the company after years at another company that did none of the above.
• 3 x Increased responsibility/visibility/opportunity.
• 2 x Company is offshoring to China putting me out of a job later this year.
• 2 x Company is providing me oppurtunity to work in the direction of making a change in existing working & make it more beneficial & efficient.
• 2 x I am the company - but trying to increase my rates.
• 2 x Increased compensation after I told them I was going to leave.
• Exposing me to new SQL Server Tech that I have not had in other positions.
• Flexible hours, health plan, trainings.
• I left my previous higher paying gig to focus on what I wanted to do to build up my skillset.
• I left the company as a result of salary. They hired someone new and less capable for more than I asked to stay.
• I love this new job. Running my own SQL practice, autonomy, trust, decision making control, helping great clients. Don't tell 'em but they could withhold raises for a year or two and I'd still stay :-) First time I can ever say that about a job.
• I'm leaving.
• Increased compensation, increased training budget, new laptop.
• Opposite of all: Decrease bene, no comp inc, decrease tellcom, 0 budget for training or hardware, no promo, increased expectations.
• Outsourcing to India and making me redundant.
• Paying for PASS Summit.
• Retaining high quality people to work with.
• The companys noble vision and mission.
• Wait until the buy-out - salaries/bonuses may go up/be paid.

I'm very surprised that half the employers out there are doing nothing to retain their staff given how hard it can be to hire new, capable people. That's pretty depressing to see. Of course, we don't know the reasons why - could be the company is strapped for cash because of the economy or just that they employ Catbert as their HR Director. And you should see some of the private emails I've had from people about how companies are truly screwing the people that work for them.

On the flip-side, 40% of companies are increasing pay, flexible working, or training budgets - that's pretty cool. Savvy companies know they have to invest in their people to stay successful.

For those in the first 50%, I'd seriously think about why the company doesn't seem to value it's employees and whether it's time to consider moving somewhere that does. One of the cool things about the online SQL community is that there's a lot of empathy for people looking to change jobs and twitter can be a very powerful way to get the word out that you're available. Even if it's not the right time to be able to make a move, I'd still start racking up learning experiences (either at work or on your own time) to make yourself a more attractive hire when you are able to make a move.

The "Other" responses are:

• 8 x Increasing work hours, increasing responsibility, learning on my own time, saving company money.
• 4 x Many of the above. More for job satisfaction than for the company.
• 3 x Fixing all the stuff that was bad before i joined such as no database backups (despite multiple on staff dbas).
• 3 x I am the company - keeping my skills relevant via out of hours training.
• 3 x Not what I am doing but what has happen is increasing work hours, increasing responsibility, on-cal, process efficiency and keeping it all together with bubble gum and duct tape.
• 2 x All of the doing, none of the nothing and actively lookin.
• 2 x Increasing responsibility, Learning on your own time, acting as unoffical community rep for company.
• All top seven items.
• Anything and everything a business owner does.
• Building up to become the tech face of the company. New position.
• Conducting SQL trainings.
• Constantly developing relevant new skills.
• I resigned weeks ago but I'm still hanging around & helping them.
• I was a Systems Analyst which was part travel and working from home.
• Increased work load.
• Increasing work hours, increasing responsibility, learning on my own time, on-call biweekly, supporting new gloabl regions, improving proccesses, etc.
• Marketing, Bringing in clients, training others, setting up best practices and processes to have more help in the SQL space.
• Serial consulting...fixing everyone's problems then having the contract-to-hire not hire.

Wow - almost 90% of people who responded are doing something to make themselves more valuable to their employers. These are smart people. If you're stagnating in your job, there's no impetus for the company to value you and so you bubble up the 'next out the door' list. However, it needs to go both ways - the company has to realize that you're increasing your worth and that over time they need to recognize that increase by giving something more to you. As the economy starts to pull itself together there's going to be a point where you should call it quits and move on if the company isn't valuing your extra efforts - there's only so long you can increase your working hours or your stress from increased responsibility until it begins to affect your home life detrimentally.

Summary

When I used to manage teams at Microsoft I was very much a believer in recognizing good people and giving back to them (I was sometimes hobbled by Microsoft's nasty stack-ranking review process though) and I still do that today with the people that work for us here at SQLskills.com (Jonathan's eligible for a bonus of at least two vouchers for McDonalds Happpy Meals every month, and our assistant gets to spend the night in her own home once a week instead of sleeping in the cot under her desk - which is more than fair :-). A company cannot expect to attract and retain good people with a so-so benefits package and work environment that tolerates mediocrity and doesn't encourage people to excel.

But an employee cannot expect to be valued unless they show value. It can be a delicate balancing act, with some folks doing just the minimum to get by and others pushing themselves hard to be the shining example to the rest of the team. I've always been in the latter group, but I know *lots* of people in the former group who would whine and complain when they didn't get the pay rise or bonus they expected.

But this isn't about me, it's about you. IT budgets are increasing this year for sure, and you only have one life to live. Take a good hard look at where you are in your career, and how the company treats you. No one deserves to be treated badly or be unhappy in their job - and only you can do something about it. Back at Microsoft, I helped many people with their careers and my biggest message to them was that no-one is going to manage your career except you. Everyone's too busy with their own lives and careers to stop and push you to manage yours. Even as a manager, I would dedicate time to those that wanted to progress their career instead of those that didn't.

To close, I want to share with you my mantra for life: "There's no fate but what we make for ourselves" (from the movie Terminator 2). It's cliched I know, but when it comes down to it, you need to make sure you're getting the deal you want - life, job, partner, house, hobbies, respect... no-one else is going to do it for you.

After a discussion on Twitter this morning, my good friend Steve Jones (blog|twitter) said it would be great to have a survey polling people on how their companies are retaining them this year, and vice-versa - so here it is!

The survey is completely anonymous, so don't be afraid to answer. Also, if you'd like to post a comment, feel free too, anonymously or not.

Please vote multiple times - the free survey site does not allow multiple selections, but does allow multiple votes.

The first survey is what is the company doing for you.

The second survey is what are you doing for the company.

I'll report on the results in a couple of weeks - see if you can publicize this survey - the more responses there are, the better it will be for anyone wanting evidence to show their management.

Thanks!

I came across an excellent blog post on twitter today: 10 ways you know you’re with smart people.

Go read it. If the top-10 describes you then you should be proud IMHO.

Kimberly recently spent a bunch of time redesigning our popular laptop stickers (those old black and white ones are now the "classic" stickers - look for them on eBay :-)

We have *lots* of them and they're all for you. We'll be handing these out at events (e.g. SQL Connections, SQL Saturday #67 Chicago, SQL Saturday #73 San Diego, Orlando Code Camp), giving them to your user group leaders to hand out, and sending them in the post to anyone who wants one.

If you want one, just head over to our website and join our Insider community (where you'll get our bi-weekly exclusive demo videos and content and access to all previous stuff too). If you include your mailing address we'll send you a postcard with the peel-off laptop sticker on - doesn't matter where you are in the world. And then we'll throw away your mailing address. And if you're a user group leader, let me know and we'll send a swag pack to you with cups and pens too (they're shipping in the next two weeks).

It's that simple.

Enjoy!

PS If you're already an Insider, just shoot me an email with your mailing address and we'll send you a sticker.

Back at the end of January I kicked off a survey about the relationship between your DBA and dev teams. See here for the survey.

Here are the results:

The 22 Other values are:

• 5 x The devs are great - it's the apps and the process that suck.
• 4 x It depends on the development team.
• 3 x I'm the team lead and the DBA.
• 2 x It's fine with the internal developers, but the consultants... not so much.
• 2 x It's non-existent. Management does not have the DBA and dev team work together until there is an issue.
• 1 x Essentially non-existant, between all groups: Infrastructure, DEV, DBA. Management has no interest in fixing it. Total crap gets moved to prod all the time, DBA's are the bad guys cause I've stopped the practice of moving db side "things" into prod without testing.
• 1 x It is spread out across country, DEV team think they are gods, what's a DBA?
• 1 x The DBA/Dev relationship is good, it's the DBA/Vendor relationship that sucks because vendor apps suck!
• 1 x The dev team have no clue what Data Architecture is all about 1The dev team is learning. Getting better all the time.
• 1 x We are a small Admin team supporting scores of development teams. The teams are very segregated so relationships are very weak.

A very interesting variety of situations and views. Good to see that the majority of people are experiencing good relations between teams (answers 1 + 2 + 7 + 8 = 59%).

Here's a comment from the original post that sums up what I see a lot of the time when first working with clients:

The developers think the DBAs are a bunch of idle boneheads, and the DBAs think the developers are a bunch of cowboys with little regard for the availability of the live servers.

Strong words, which demonstrate a fundamental lack of understanding about what the various teams do. That is very often the root cause of all the animosity between teams - not understanding the goals and motivations of the other team. For instance, a dev team is often under a lot of pressure to get the next release finished and put into production. A DBA team needs to preserve the availability and performance characteristics of the production system. These two goals are often at odds as the dev team wants to throw code over the wall and get it deployed, whereas the DBA team wants the code to be tested to ensure it will not compromise the production system in any way.

There's also the case of those who answered #6 - one guy who's the problem between the teams. This could be someone in an architect or lead developer role, who has a lot of experience, but maybe some misconceptions, who has a domineering personality and is always right - no matter who is trying to show them that they are in fact incorrect. We've never come across this person during our consulting work, oh no. :-)

How do you work towards solving these problems?

Education.

It's no good just complaining and blaming each other when things don't go well. You need to have the other team understand *why* your team does what it does, *why* it's concerned about certain things, and *why* it operates under the pressures it does. I have a lot of experience managing development and program management teams and managing the relationships between the dev teams and the test teams, the dev teams and the build teams, the dev teams and the program management teams - so I'm speaking from experience here.

Last year in London we did a 1-day workshop where the focus was bridging the gap between development and production. We highlighted a bunch of problems we've seen over the years and how some education could have helped. Here are some of the takeaways people had from the day:

• Avoiding known design anti-patterns - don't repeat mistakes that others have made. Once you find a performance problem, give feedback on the design anti-pattern that caused it to everyone involved. A great example of this is thinking that single-column non-clustered indexes on every table column will be useful. There are some great posts and books about SQL anti-patterns, such as this one.
• Prototype and test design strategies - it's imperative that the developers have a test system that reproduces production workloads to the extent that proper scalability and load testing can be performed; otherwise it's not going to work in production. I see this over and over. It's also very important that developers and architects understand the ramifications of data type and schema design choices on the operational aspects of SQL Server (for instance, a LOB column in a table prevents online index operations on the clustered index).
• Workload analysis and performance base-lining – nothing allows you to identify that a new set of code has a problem faster than having a performance baseline, and monitoring so you can easily identify that the latest code change caused a performance change.
• Troubleshooting to identify problems rather than throwing hardware at the problem - it's always better to find the root cause of a problem rather than trying to work around it with bigger iron or faster disks. You'll eventually run into the problem again. A good example is writing a query that is non-SARGable and requires an index or table scan. I blogged about this recently here and many others have too. Implicit conversions are another great example - Jonathan has a great blog post about finding them here.
• Build trust and partnership between teams – success is not one-sided and both teams look bad when an application/project fails. A company with teams at odds will suffer.
• Consistent post-mortems and “lessons-learned” from problems and mistakes rather than laying blame - being able to say mea culpa and proposing changes will elevate you above your peers whether you're a dev or a DBA. Just remember that if it's someone else's fault, constructive criticism needs to be well-phrased to be well-received. Don't make it personal.

And the one we stressed the most was:

• Work to cross-train and educate both teams for best practices

This is the most powerful way to foster relationships between teams in my experience - offering to educate the other team on, say, one issue a week. This will show them that you're willing to put skin in the game (and hopefully they'll reciprocate) and in the long-term it will save you time. And it's a great way to show initiative and that you're a team player  and motivator to your management. Some ideas for you on this:

• After a post-mortem, put together a list of links to blog posts and articles that explain facets of the problem and how to identify and or avoid it
• Organize a weekly self-study group that involves both teams. Use online material like our MCM prep videos as a base. Management will love this, and people will almost feel compelled to be part of it, rather than showing management that they don't care about working better together. Even the nay-sayers will eventually see the benefit and come around. Persevere!
• Get the team leads together to voice concerns and clear the air in a pre-agreed no-offense-will-be-taken closed-door meeting. You may be surprised at what lingering misconceptions, grudges, and misunderstandings can be cleared up by letting people vent and clearing the air.
• Bring in an outside consultant who knows what they're talking about to be an independent voice of reason with no political baggage for either team. We get asked to do this every so often - it can be challenging but very effective, especially for the "there's this one guy" problems where no-one can convince them, or wants to publicly stand up to them. Often helping the person see the light and think they've made the leap themselves is the best way forward - which can be hard to do from within the team, but a lot easier as an outsider, where we don't care about a position in the company pecking-order.
• Send one dev and one DBA to a training class where they can both learn and bring back the learning to the teams with the two perspectives. Of all the classes we teach, the Internals and Performance class is the best for this.

To summarize, a bad working environment is toxic. You can fix it. It'll take some effort on your part but the pay-off is really worthwhile. And there are lots of resources out there to help you out.

What are you waiting for?

Today is a very exciting day for us here at SQLskills.com as we take the first step at growing as a company instead of solely partnering with other consultants with their own companies. While we value our partnerships and plan to continue many, we also value the benefits brought by having a small and dedicated team of highly technical and skilled employees.

Specifically, we’ve asked Jonathan Kehayias to become employee #3 (with Kimberly being #1 and me being #2) and we’re extremely pleased that he accepted our offer.

We first met Jonathan four years ago when we crossed paths on the MSDN forums where he is a prolific provider of answers (actually the top answerer on the Database Engine forum) and we’ve been casually discussing eventually hooking up at some point for well over a year. This year the stars aligned and Jonathan is making the move, starting with us mid-March.

Jonathan is the world authority on Extended Events in SQL Server 2008—he wrote the definitive whitepaper on Extended Events for Microsoft and he authored the Extended Events Manager SSMS add-in, which won the PASS 2008 SQL Hero contest. He has a thirst for knowledge and digging into the guts of SQL Server that’s truly inspiring, and he constantly impresses us with how much he knows.

[Edit 02/24/11: Jonathan just passed the MCM certification - congratulations!!!]

Jonathan is a performance tuning expert, both SQL Server and hardware, and has architected complex systems as a developer, business analyst, and DBA. This breadth of role experience, along with extensive development (T-SQL, C#, and ASP.Net), hardware and virtualization design expertise, and Windows, Active Directory, IIS, and other component knowledge makes Jonathan an incredible addition to our team. He has also presented at multiple conferences including PASS, SQLBits, and VMware Open Forum, and will be presenting at PASS SQL Rally and SQL Connections this Spring.

Jonathan is also a Drill Sergeant in the U.S. Army Reserves, and did a tour of duty in Iraq in 2004. He’s married with two small children and describes himself as a ‘general goofball’—he’s going to fit right in :-) In all seriousness though, his dedication to his family, his country and his work is without doubt extraordinary.

You can follow Jonathan on twitter and he'll be moving his blog over to SQLskills.com very soon.

One of the most interesting aspects about Jonathan being a real employee rather than a partner consultant is that we’re not limited to only working on client projects. We’re going to be working on research, benchmarks, tools, and other really useful things for the SQL community, our classes, and our clients. We’re already planning resources that will be available exclusively to our SQLskills.com community. Join now!

As you can tell, we’re really looking forward to Jonathan starting to work at SQLskills.com and we’re planning great things to come plus more additions to the team. Watch this space…

Thanks as always,

Paul and Kimberly

Last Friday our great friends Richard Campbell (who MC'd our wedding) and Greg Hughes invited us to record their 200th RunAs Radio podcast with them - a signal honor for which we thank them deeply!

We've both been on RunAs Radio (and .Net Rocks!) before but this show was meant to be a fun tour around a whole variety of topics. If nothing else, you have to listen in to hear what I was wearing in tribute to the 200th show.... listeners beware!

Congratulations Greg and Richard - keep up the great work!

You can get to the show here.

Enjoy!

Back when I was at Microsoft, I witnessed Steve Balmer doing his mad "Developers, developers, developers, developers!" mantra a few times. (Checkout this video of him doing it here.)

Here at SQLskills.com, our mantra is "Community, community, community, community!".

You guys out there recognized that and voted us the #2 SQL company that's "doing it right" in Jen McCown's (blog|twitter) recent poll - results were just published.

We're very happy with that, and with the #1 company SQL Sentry who narrowly beat us for the top spot. They produce the excellent free Plan Explorer tool and are the exclusive sponsors of our first two public classes this year (read all about the cool free evening events in Dallas here).

We have a lot of stuff out there for you guys for free:

• The PDF of myths and misconceptions
• Our blogs
• The MCM prep videos
• Our version of the MCM pre-reading list
• User group presentations, like the PASS Virtual Chapter on Performance I did in January on fragmentation (recording is here)
• And a whole host of other resources including helping out on Twitter, SQL Server Central, and many more

If you want to join OUR community here at SQLskills.com, we're starting a monthly newsletter where we'll have exclusive content, advance notice of classes, plus discount codes for training and consulting. Sign-up by clicking here.

Community, community, community, community!!!!

I'm going to do two surveys this week. In this one I want to know what the relationship is like between the DBA team and the dev team wherever you work (or whatever comes closest team-wise). Remember the survey is completely anonymous. If you want to, feel free to add an anonymous or otherwise comment below too.

I'll present the results during the second week of February.

Thanks!

Anywhere in the world? If you do and you'd like a SQLskills swag-pack (cups, pens, laptop stickers), drop me an email (paul@sqlskills.com) and let me know your average attendance and your address and we'll get some stuff in the post for you.

Cheers

Just before Christmas last year I created a survey to ask you what your job title is and additionally, if you wanted, what you actually did in your job. See here for the original post.

Here are the results of the survey:

I think that clearly shows the type of people reading my blog - more than 60% are a DBA of some kind - and I'm not surprised, given what I blog about.

The "Other" values were:

• 11 x Consultant
• 7 x Database Engineer
• 6 x Data Architect
• 5 x Database Analyst
• 4 x Database Solution Architect
• 4 x Subject Matter Expert
• 2 x Data Analyst
• 2 x Database Architect
• 2 x Emerging Technology Expert
• 1 each for Chief Data Architect, Data Administrator, Database and BI Developer, Database Delivery Architect, Database Systems Coordinator, DBA for Reporting and BI, Default Blame Acceptor, Enterprise Architect, Enterprise Data Architect, Lead DBA, Network Administrator, Operations Engineer, Product Manager, Production DBA, Programmer/Analyst, Project Manager, SAP Admin DBA, Senior DBA, Solution Architect, Solutions Designer, Senior Director, System Analyst, System Engineer, System Engineer for MS Project Server, Virtual World Database Administrator

WOW!! That's a lot of different titles for people who all need to understand some facets of how SQL Server works, behaves, and can be tuned.

Here are some of the 40 comments that people left on the original post describing what they do (with names where people put their names for all to see, but I didn't bother with blog/twitter links this time):

• David Maxwell: 'My official title is DBA. (Which is what I voted.) My official duties are mostly production support, a little bit of assistance with stored procs and such, mostly performance related. Oh, that and, "if anyone screws up entering data, fix that too..."'
• Rob Sullivan: 'My title is DBA. That means anything dealing with databases (performance, design, ha/dr, dev), applications or the network usually ends up at my feet. From troubleshooting firewall issues (so users can get to the db) to helping the AppDevs use their ORM's correctly (very rarely do they take the time to learn to use them correctly on their own), I need to be on top of it. It is a large hat for sure, but I have a huge head so bring it on.'
• Adrian Hills: 'Developer: Strong focus on backend development (SQL Server & .NET) including database design, development, query optimisation and performance testing. Also work on maintenance-related scripts such as manual archiving/partitioning of data (no Enterprise Edition here!). Heavy focus in my role on the performance/scalability side of things so SQL Profiler/execution plans etc are not things to shy away from - some people feel that's crossing more into DBA territory but I personally think it's a very key part of being a developer.'
• Gail Shaw: 'Consultant: Meaning: If it's even tangentially associated with SQL Server, I'm generally expected to be able to do it.
  Seriously, these days it's mostly a mix of database design, database development, query optimisation and SSIS development with occasional forays into admin (backups and configuration)'
• Michael J Swart: 'My title is "Database Developer." My company sells enterprise solutions to colleges. Other coworkers take care of the hardware, clustering and security. Here's an (incomplete) list of what I do.
  * I'm an in-house consultant for a number of products.
  * I'm responsible for the performance and scalability of the database.
  * Day to day, I often audit sql scripts and schema changes.
  * DB design.
  * Troubleshoot when our support team determines a problem is database-side, but not hardware.
  * Give lunch-and-learns for .net developers on best practices and standards.'
• Matt Velic: 'I wrote in "Data Administrator." While there is an actual DA position, and it has to do with metadata management, my position is far beyond that. When I was given the title, it was explained to me that it was so they could give me any and all data related tasks from SQL Server administration, helping out with reports, to data entry and cleanup. It's quite the cluster...'
• Michelle Ufford: 'I'm currently a Developer DBA. What that means, at least in my current environment, is that I primarily focus on new database development. And by that, I mean I primarily create new schema and stored procedures, with some SSIS packages when necessary. I'm a Developer DBA and not a Database Developer because I'm also responsible for things like maintenance, ad hocs, query optimization, and troubleshooting. However, backups, security, replication, etc. all fall under a different group's responsibilities.'
• Jonathan Allen: 'I get to be a Database systems Coordinator. Not "Administrator" as that applies to a role that is lower in the Co. hierarchy than a "Coordinator". Roles that I fulfill Systems Analysis, Requirements Analysis, Project Management, Application Development (web and .exe), Database Admin (checking backups, security, config etc), Database Development (new databases, changes to existing), Performance Tuning/Code checking other BI users, Capacity Planning and Upgrades (hard/soft ware), Liaison between ICT and MI teams, HA/DR.'
• Kelly Martinez: 'Official title is programmer/analyst. Work takes the analyst part to the max and I find myself doing everything from system administration to database development to web. The key phrase in my job description is "...and additional duties as assigned".'
• Emil Fridriksson: 'My job title is "Senior virtual world database administrator" and I have a hard time translating it to Icelandic. I'm the senior DBA over the team that manages the massively multiplayer online game EVE Online and other projects CCP Games is working on. My duties are maintenance and monitoring of the production and test database servers for EVE Online, consultation with developers about database issues, hardware scoping for database servers, resolving customer support issues escalated from the customer support department, development of maintenance scripts, maintaining PCI compliance, mentoring the other DBAs in the team, SAN configuration, maintenance and monitoring as well as some operations of the application servers that run Eve Online. All the regular DBA things and a few that would go under developer, SAN admin or IT admin. I'm probably forgetting something '
• Robert Miller: 'Enterprise DBA, Architect, and Developer responsible for Development, QA, and Production environments of a 24x7 Social-Site Aggregator.
  
  Responsibilities include:
  1) Design and implement an environment able to maintain 100% up-time (2 years and running -- ignoring the painful speed-bump called Database Mirroring). This includes propping new hardware, O/S, Clustering, SAN-management, and ongoing maintenance while balancing needs with budgetary constraints.
  2) Participate in all database related changes.
  3) Participate in application architecture, design and implementation as DBA and Developer (T-SQL and Application code).
  4) Responsible for BI-related development and support
  5) Responsible for Data-Warehouse activity
  6) Involved in all Release Pushes from Development to QA to Production
  7) Responsible for performance issues in Production and communicating any needed changes to the development team or implementing them myself.
  8) Responsible for providing a recovery mechanism if everything fails -- Having valid backups helps.
  9) Always on-call. If not able to be near a system, then able to coordinate activity until I am able to be in-front of a system.
  10) I am certain I missed something and simply tossing in the anything a DBA, DB-Developer, BI-Developer would do or be responsible for should cover it.
  
  I would like to include a serious jealousy of "Emil Fridriksson's" job at CCP -- See his comment above.'
• John Pertell: 'My title is DBA but like most other commenters here I wear multiple hats. I'm the senior DBA in our company only because I have the most knowledge and I'm responsible for the day-to-day management of 10 servers plus dev and testing. Because of that I'm usually brought in when other servers have issues. I do some database development work and some BI tasks. I'm probably not an Enterprise DBA since most decisions about SQL architecture (server configuration, SAN configuration, HA/DR, etc.) are made by other non-DBA managers.'

This is some really interesting reading - thanks to everyone who shared a comment on the original post.

It's very clear that a job title in our portion of the IT industry doesn't always equate to the actual job duties performed, and nearly always does not imply a strict boundary limit of responsibilities. There are just too many facets of the SQL Server environment and data-tier linked application lifecycle to neatly compartmentalize someone's responsibilities and provide clear boundaries. I know the demarcation lines have been further blurred over the last few years during the general recession where companies have laid off part of the IT staff and the remaining employees have had no choice but to pick up the extra duties their previous colleagues took care of. I know there are lots of over-worked and stressed-out DBAs/whatevers out there because I deal with some of them at clients I work with. Sometimes that's a sucky situation to be in, sometimes it makes someone thrive.

But I didn't want this to devolve into a rant about companies over-working people. I wanted to illustrate with the survey and its results that lines are blurred.

For instance, whose responsibility is it to troubleshoot badly performing code on a production SQL Server? The DBA or the developer who wrote the code? I'd say that I hear most of the time that it's the DBA, but is that right? Shouldn't the developer who wrote the code have tested it under load and scale to ensure it performed well? I'd say yes. But what if they don't know what to look for, or how to stress test it? I'd say it's the DBA's responsibility to help educate the developer so the developer knows how to properly QA the code before handing it to production.

To take the example a little further, what if the badly performing code is because of a design decision that a business analyst/architect made around table structures. Who's responsibility is it to fix the code? I'd argue that the business analyst/architect should be aware of the ramifications of design choices on how SQL Server will operate and perform. Which comes down to education again.

Very often I see serious enmity between developers and DBAs because of ill-defined or implied responsibilities - or lack thereof - and people lose site of the fact that they're playing on the same team - the company they work for.

I could boil all of this down to say that anyone involved in dealing with SQL Server needs some education so they can make informed design choices, perform proper testing, perform efficient troubleshooting, and on and on and on... regardless of your job title.

And there's really no excuse for ignorance these days, with so much information freely available and easily searchable.

Hope you found this an interesting read!

I've noticed a few new SQL blogs spring up over the last month or so and someone asked me on Facebook this morning about linking etiquette so I thought I'd lay out a few quick thoughts I have on the subject - some "dos", mostly "don'ts" - as general advice for successfully blogging in the SQL community.

Don'ts 

• If you're starting a new blog, how are you going to get readers to follow what you write? By writing about something interesting to them. One mistake I see a lot of people making is starting a series that simply rehashes material that's been out there for ages. For example, do we need another series on how SQL Server data structures are put together? Do we need another series on choosing the right non-clustered indexes? And so on. Unless you're putting a different spin on the topic, or introducing new material, it's been done before. Blog about stuff you've discovered that other people *haven't* blogged about ten times before. I know I'm kind of breaking this rule with this post because I'm sure others have written similar posts before, but an advice post is different from a technical post, and this is my spin on it.
  • Steve Jones (blog|twitter) makes a good point in a comment below - paraphrase "if you're using your blog to show-off your professional skills, blogging about something that isn't new can be worth it." I'd still say that there should be a new twist to the material, throw in some anecdotes, and link to some prior art too.
• Don't be scared to start blogging. You may not be the best writer, but "if you build it, they will come" - popular misquote from the movie Field of Dreams. It can take practice, but it's really satisfying to see people reading and commenting on your stuff.
• Don't use four-letter words in your posts. Or racism or anything else that's guaranteed to put people off. I swear like a truck-driver, but I don't like reading it in blog posts. You need to be able to express yourself without swearing.
• Don't plagiarize. Plagiarism means copying other people's work and passing it off as your own (through deliberate or accidental lack of attribution). It's also a violation of copyright - copying work without asking. You're not allowed to do this by law, and it's very, very bad manners. The SQL community at large is vehemently against plagiarism. If you want to quote a paragraph of material, copy a list, or re-use an image, ask the person first. Most likely they'll say yes (I always do if asked first).
• Don't tweet about your blog post using the #sqlhelp hash tag. That's not what it's for and you'll annoy people.
• Don't tweet about your blog post multiple times in quick succession, or at high frequency (e.g. hourly). You'll annoy people.
• Don't copy chunks from Books Online or whitepapers. Reference them with a link.
• If you're correcting some misinformation that you've seen on the Internet, don't link back directly to the post you're correcting. That makes it personal. Others may disagree on this, but I do it this way.
  • Gail Shaw (blog|twitter) makes a good point - link back to the original misinformation if it's in Books Online or a whitepaper - agreed.
• Don't be scared of doing short posts announcing something, or a really long post that goes into depth on a topic. For a long post, I like to put headings every so often and a summary at the bottom.
• Don't get fixated on page view numbers. If you blog good stuff, you'll get a following. I track the numbers for the various SQLskills.com blogs through Google for a couple of reasons: various Microsoft programs (e.g. MVP and Regional Director) like to know what kind of community reach the blogs have, and I like to see what topics people are most interested in.
• Don't post NDA information. If you're in doubt, ask first. There's no such thing as asking for forgiveness afterwards when it comes to NDA material.

Dos

• Make it entertaining and let some of your personality shine through. People love to be entertained while they learn. 
• Use a spell-checker. I always take the blog posts and stick it in Word to check spelling and grammar - it found 4 spelling mistakes in this post. I crnge when I reed things that ara spelt wrongly. Beware of apostrophe usage especially. (Did you notice the typos in the middle sentence?)
• Put in links to people and their posts. I like to do links like this: And Brent Ozar (blog|twitter) wrote a similar article about snow-blindness in cats here. That's actually a quote from the excellent movie Talladega Nights. People like to have their stuff linked to, and then you'll see people linking back to you.
• Tweet about your blog post using the hash tags #sql and #sqlserver, and anything else that's *relevant*.
• Split your prose up into digestible chunks. If I see a page-long paragraph, I move on. I like to use bullet points too (you may have noticed :-)
• Use the same nomenclature for describing features, algorithms, internals as everyone else does.
• Make sure what you're posting is accurate, and clearly explained. 
• If you use someone's name, make really, really sure you spell it correctly. I see Randall very often because people don't bother to check. I'm used to it, but it still rankles.
• Same thing for company names. I see SQL skills, SQLSkills, SQL Skills. None of which are correct (it's SQLskills) - do the due diligence.
• Use catchy, descriptive blog post titles. If people are skimming RSS feeds, you want your post to stand out.
• Invite feedback through comments, and make sure you respond to comments when appropriate. If someone takes the time to ask you a question after they've read through your post, give them the courtesy of some of your time to respond. Then they'll continue to read your blog.
• Remember that everything you post on your blog will be preserved for all time by Google and Bing. This means prospective employers, spouses/partners, children, parents can and will see what you're posting.
• Check with your employer whether you need to put a disclaimer on your blog and whether you can make (even oblique) references to anything at your work.
• Be careful if you're a consultant and you blog about something you did for a customer. Make sure they're not going to be annoyed with you.

These things work for me - I have a successful blog (you're reading it aren't you? :-) - and many others too.

The final "don't": don't take personal affront if you're doing one of my "don'ts" - think about whether you should change for the better.

And the final "do": do let your knowledge and passion for SQL Server shine through your blog posts! Enjoy yourself!

PS A lot of the tips in my long post Public Speaking: A Primer also apply to writing good blog posts too.

We'd like to thank you all for reading all our stuff all year, for coming to our classes and conference sessions, and for being our friends.

So to say thank you (and to torture you!) I wrote some SQL - Christmas carols and persuaded Kimberly to join me in the fun.

And so we present A SQLskill Christmas Medley - one minute of our dreadful singing to you all. The sound quality isn't fabulous as it was spur-of-the-moment in the kitchen on a laptop rather than on our recording gear, but I like that.

Download it by clicking HERE (2.5MB WAV, 1 minute)

Merry Christmas and our very best wishes for a healthy and prosperous New Year!

PS This is why our company name is not SingingSkills... if you listen carefully you can hear Kimberly starting to laugh as I start my solo rendition of Silent Night :-)

There's been a lot of discussion on the MVP distribution list about various certifications and what SQL Server roles they cater to. Furthermore, there's a lot of disagreement on what the multitude of job titles mean. In this survey I'd like to find out what you think your primary job role is, and if you're up for it, add a comment or send email about what you job role is, what you're expected to do under that job role, and what you're not expected to do.

[Edit: The survey is closed. You can read the results HERE.]

Note: I don't imply anything by the order of job roles in the survey.

I'll report on the results during the first week of January.

Thanks!

Last Tuesday I hosted T-SQL Tuesday #012 (see here for the call for participation) and posed the question "why are DBA skills necessary?" This month broke the participation record with 46 people contributing posts - fabulous! Lots of people contributed for the first time too. And what I think is also really cool is that 45 out of these 46 are on Twitter too.

The downside of so many people participating is that it's taken me quite a while to read through all the posts to compile this summary - maybe I should have picked something obscure and boring instead! One of the most interesting things about doing this wrap-up was experiencing a huge variety of blog themes and fonts - a few of which actually made my eyes hurt!

A HUGE thank you to everyone that participated, T-SQL Tuesday doesn't work without you. I really enjoyed reading through everyone's posts and seeing the passion out there for the DBA role. As I've summarized the posts I've added my own comments too.

Here are the posts from all the participants in the order in which their links appeared in my blog post comments (or I dug out additional posts using Google).

Matt Whitfield (blog | @atlantis_uk): T-SQL Tuesday #12 - Why are DBA skills necessary?

Matt tells the story of himself as a database designer making a plethora of hard-to-remedy mistakes 9 years ago before he had DBA skills that would have helped him not make those mistakes. His take is that it's essential to have someone with DBA skills involved in system design as newbie DBAs or developers don't know the impact of design choices on SQL Server. I love this line from his post: "There is a whole world of epic-database-fail out there, and that world needs us."

Noel McKinney (blog | @NoelMcKinney): T-SQL Tuesday #012 – DBA Skill or Nil?

Noel takes a look at different RDBMS platforms and how the need for DBA skills could change - from Oracle to MySQL to the cloud to NoSQL. Even with automated solutions, he still thinks you wouldn't want to just apply all the default policies and walk away. I'd have to agree. 

Pinal Dave (blog | @PinalDave): SQL SERVER – Are you a Database Administrator or a Database Developer?

Pinal's short post focuses on how the line is often blurred between being a database administrator and a database developer. He has a survey in the post which is currently showing 60% of respondents believe they're more a dev than a DBA.

Audrey Hammonds (blog | @Datachix2): T-SQL Tuesday: Why are DBA Skills Necessary? – A Datachix Perspective

Audrey's post is about how some of the knowledge a DBA has is essential for a database developer to have too - but does that make you a DBA? No. I love her medical analogy: "See, asking me, a non-DBA, to attempt to be a DBA is like asking a psychiatrist to perform heart surgery". DBAs are essential to look after SQL Server.

Erik Bitemo (blog): T-SQL Tuesday #12 – Why are DBA skills necessary?

Erik's post explains some of the knowledge DBAs should have as a way of illustrating the problems that can occur if they don't. He also reminds us that one of the major causes of SQL Server being regarded as not requiring a DBA was the marketing around the 7.0/2000 time-frame that proclaimed how easy SQL Server was to use. IMHO that really hurt the image of SQL Server and SQL Server DBAs.

Rob Farley (blog | @rob_farley): Why bother with database professionals?

Rob's argument is that you don't necessarily need DBA skills - you need people who can apply the right paradigm to their work. For database work that paradigm is set based.

Aaron Bertrand (blog | @AaronBertrand): T-SQL Tuesday : Are hotshot DBA skills necessary?

Aaron (one of my favorite MVP friends) makes a great point that many small business *don't* need a full-time rockstar DBA and that many of the defaults will allow them to continue along happily. But at some point as the business grows and the data/transaction volume grows with it, you cross a line and then a DBA really *is* necessary. I totally agree. When I'm teaching about index fragmentation I always say that at the low end, rebuilding all your indexes every night is probably fine, but as things get larger and downtime becomes important, DBA skills are needed to take a more analytical approach.

Robert Hartskeerl (blog | @rhartskeerl): T-SQL Tuesday #12–Why are DBA skills necessary?

Robert explains how even though there are tools to assist with managing SQL Server, someone has to interpret what the tool is saying and no how to fix the problem. And the tools can be wrong - like the RESTORE bug in SSMS in SQL 20008. Robert also used my favorite phrase... "it depends!"

Erin Stellato (blog | @erinstellato): TSQL Tuesday #012: Why are DBA Skills Necessary?

Erin (my favorite stalker :) recounts some of the problems she's helped with on customer systems that affected business continuity. Her take is that if the data is really important, you need a DBA to make sure it doeesn't get irretrievably damaged or destroyed.

Grant Fritchey (blog | @GFritchey): TSQL Tuesday: Why Are DBA Skills Necessary

Grant (who scares me sometimes) tells some good stories and preaches the same mantra: at some point you need a DBA who knows how to protect and recover data, perform tuning etc. Even with NoSQL - you're still storing data and you still need to be able to restore it, get at it quickly, etc. Hear, hear.

Steve Jones (blog | @way0utwest): T-SQL Tuesday #12 – Why Do You Need a DBA?

Steve (who scares me most of the time with his pink cowboy hat) joins the chorus that DBAs aren't always required, but when they are they can save a company a lot of time and money and hence can be a really worthwhile investment.

Jes Borland (blog | @grrl_geek): T-SQL Tuesday #012: Why Are DBA Skills Necessary?

Jes explains why DBAs should market their skills as a problem-solvers and money-savers, and that a DBA isn't an IT function, it's a business need. Oh yes, and she says that we should all wear super-hero capes!

Bob Pusateri (blog | @SQLBob): T-SQL Tuesday #12: DBA Skills

Bob tells some stories from his DBA past but says that one of the most important DBA skills is to know when to ask others for help. He goes on to say that "presence of DBA skills can make a big difference between just getting something done, and doing something exceptionally well."

Mike Reigler (blog | @RMikeReigler): TSQL Tuesday #12 – I’m not a DBA, But I Got DBA Skills

Mike lists a bunch of SQL knowledge that most developers wouldn't know or care about, but makes the point that *someone* has to know and care about it, or people are going to get annoyed when performance tanks. He also explains how knowing some DBA skills sets him apart from other developers.

Mark Blakey (blog | @Blakmk): T-SQL Tuesday #12 – Why are DBA skills necessary?

Mark's the first poster to bring up the fact that developers and DBAs often have different priorities - with devs churning out code quickly while DBAs are trying to preserve resources.

Oscar Zamora (blog | @ZamoraO): Who needs DBA Skills? [#TSQL2sDay]

Oscar (who I just met at SQL PASS on Monday) lists 14 reasons why DBA skills are necessary and throws down the gauntlet by stating he thinks "most developers have no business in the DB world".

Tamera Clark (blog | @tameraclark): TSQL Tuesday – Why are DBA skills necessary?

Tamera explains how some DBA skills can help write better T-SQL as you'll know more about how SQL Server is handling the T-SQL you casually throw at it.

Jeremy Carter (blog): TSQL Tuesday – Why are dba skills necessary?

Jeremy explains that even with small databases, sometimes a DBA needs to be involved from the get-go, before the hardware is even provisioned.

Kerry Tyler (blog | @AirborneGeek): T-SQL Tuesday #12: Why are DBA Skills Necessary?

Kerry explains that databases are hard, and that it takes many different roles to look after a corporations data properly - the DBA being just one of them.

Andy Lohn (blog | @SQLQuill): T-SQL Tuesday #012 – Smart, Technologically Up-to-date, Well-Meaning Application Developers

Andy explains how he picked up DBA skills when he became a database developer and how useful they've been for his company.

Ricardo Leka (blog | @BigLeka): Por que habilidades de DBA são necessárias?

Portuguese? Google Translate to the rescue! Hmm - Google Translate didn't do such a good job, but I think the gist of Ricardo's post is that too many companies that think that SQL Server doesn't need a DBA.

Andrew Vogel (blog | @sqlreader): T-SQL Tuesday: Why Are DBA Skills Necessary?

Andrew makes a very interesting point that consultants know what's best about a product, but only you know what's best for your environment. Totally true - so many clients expect us (consultants) to provide the best answer for them straight away.

Wendy Pastrick (blog | @wendy_dance): Who Needs DBA Skillz?

Wendy (who I just met at SQL PASS on Monday) says anyone who works with a database needs some DBA skills. And if you don't have anyone with DBA skills, check out the #sqlhelp tag on Twitter. Hear hear!

Pat Wright (blog | @SqlAsylum): T-SQL Tuesday, Why are DBA skills necessary?

Pat (who I just met at SQL PASS on Monday) introduces me to an expansion of the DBA TLA I've never heard before: Default Blame Acceptor. While I've never heard it, I totally get it. DBAs are the unsung heroes of countless nasty situations caused by others.

Cade Roux (blog | @caderoux): T-SQL Tuesday: Why are DBA skills necessary? I pick the most important one...

Cade focuses on the skills a DBA has and explains why he thinks troubleshooting is the number-one skill he looks for in a DBA.

Tim Ford (blog | @sqlagentman): T-SQL Tuesday – Sometimes DBAs Are Required – Even for the Amish

Tim (who looks great in a Utilikilt) manages to unite Amish people and brothels in the same post. That takes a different kind of skill.

Geoff Hiten (blog | @SQLCraftsman): Why DBA skills are important (T-SQL Tuesday)

Geoff's short post tells the tale of someone attempting to use replication as a DR solution without understanding what replication does and does not provide. And that person was a 'DBA', but without DBA skills.

Jason Strate (blog | @StrateSQL): Why are DBA skills necessary? #TSQL2sDay

Jason gives some examples of why "what you don't know can hurt you" and then explains three critical things you should know if you're a DBA.

Jason Brimhall (blog | @sqlrnnr): T-SQL Tuesday #012 – Skills

Jason departs from the norm and discusses the NON-technical skills that a successful DBA needs to have. I particularly like the emphasis on a sense of community. I'm a huge community guy and I really like to see those that benefit from the SQL community eventually starting to give back in the form of things like blog posts, tweets, and user group presentations. People really ARE interested in what you've experienced as that will help them when they have the same problem.

Gill Rowley (blog | @SQLGill): T-SQL Tuesday #012: Why Are DBA Skills Necessary?

Gill tells a story of trying to get an IT department out of the dark ages and under control using his DBA skills.

Brent Ozar (blog | @BrentO): T-SQL Tuesday: Why Do You Need DBA Skills?

Brent (our very own Mr Wonderful) talks about when saying 'whoops' isn't code for "oh no, I dropped the database" and how real DBAs need to know enough to fix the junior DBA's "fixes"...

Matt Velic (blog | @mvelic): November’s T-SQL Tuesday: Importance of DBA Skills

Matt went as far as recording his T-SQL Tuesday message, describing how valuable DBA skills are.

Gethyn Ellis (blog | @SQLGRE): TSQL2SDAY #12 - Why are DBA Skills Necessary?

Gethyn explains some of the problems that can cause business continuity to suffer, all of which could be solved with backups, being taked by someone with DBA skills.

Jack Corbett (blog | @unclebiguns): T-SQL Tuesday–Why are DBA Skills Necessary?

Jack (whose Twitter alias I've been afraid to ask about...) tells a story if disaster and data loss that would have been prevented had someone with DBA skills been involved.

Chris Shaw (blog | @SQLShaw): T-SQL Tuesday

Chris gives some examples of why companies need databases today to stay competitive, and hence need DBAs to keep those databases healthy.

Sal Young (blog | @EmpiricalDataMa): We don’t need no stinking DBAs! (T-SQL Tuesday #12)

Sal describes some of the different DBA specialties there are, and how you need to be prepared to be dealt a hard knock by clueless executives bent on saving company money by laying off employees.

Robert L Davis (blog | @SQLSoldier): T-SQL Tuesday #012 – the DBA as a Modern-day Specialist

Robert (DBM book writer extraordinaire) tells a *really* interesting story of a high-school injury that nearly left him paralyzed because it was mis-diagnosed by GPs rather than a specialist - and draws the analogy to under-qualified people trying to diagnose problems affecting an important database.

Kimberly L Tripp (blog | @KimberlyLTripp): TSQL Tuesday - Why DBA skills are important

Kimberly (lovely wife) highlights a couple of areas where you can get bitten without DBA skills, and explains why *someone* in the organization has to have DBA skills because SQL Server is a *general purpose* RDBMS, and so it needs to be tweaked to work best for your environment.

Kendra Little (blog | @Kendra_Little): TSQL Tuesday #12: Why Are DBA Skills Necessary? Fido, Please Turn Your Head And Cough.

Kendra draws a very clever analogy between DBAs and veterinarians, saying that both look after birth, death, growth, prevention of illness, and so on.

Jeremiah Peschka (blog | @PeschkaJ): T-SQL Tuesday – Why Are DBA Skills Necessary?

Jeremiah (who has quite amazing tattoos) says that DBA skills aren't necessary, but instead the ability to learn is what sets the successful apart from the unsuccessful.

Josh Feierman (blog | @awanderingmind): Who needs a DBA? – TSqlTuesday #12

Josh recalls how he started out as an involuntary DBA, and thinks about all the mistakes he made that a real DBA would have picked up on. One thing I think we sometimes lose sight of is that *everyone* started with zero SQL Server knowledge...

Josef Richberg (blog | @sqlrunner): T-SQL Tuesday 12: Why are DBA skills necessary?

Josef laments that developers are seen as THE all-knowing entities, which can lead unsuitable designs making it into production and causing problems - which then leads to angst about the database platform which fuels the NoSQL movement.

Jonathan Kehayias (blog | @SQLSarg): T-SQL Tuesday #12 - Why are DBA skills necessary?

Jonathan (extended events expert) uses some examples from his work to illustrate some of the problems facing companies without DBAs, and explains how it can take time for a new DBA to earn the respect of the incumbent IT staff.

Cameron Mergel (blog | @CameronMergel): T-SQL Tuesday – Why Are DBA Skills Necessary?

Cameron reiterates that as the operations you want to do on your database become more advanced, you need someone with higher skills - just like there's a point at which you stop doing maintenance on your car yourself and trust it to a mechanic.

Kelly Martinez (blog | @GreeleyGeek): Why are DBA skills necessary? #TSQL2sDay

Kelly talks about some of the things a DBA should know, but the most interesting point in his post is about how some vendors seem to have no clue about the database they're running on.

Sean Gallardy (blog | @SeanGallardy): T-SQL Tuesday – Why are DBA skills necessary?

Last but not least, Sean makes the very good point that DBA skills are really necessary when searching for problem solutions on the Internet. Without DBA skills, how do you tell if the advice/solution you're reading is correct and appropriate?

In November we're doing T-SQL Tuesday a week early (Tuesday November 2nd) so that it doesn't clash with PASS and I'll be your host!

What is T-SQL Tuesday?

If you haven't seen it yet, T-SQL Tuesday is the brain-child of fellow-MVP Adam Machanic (blog|twitter). It happens once a month on the 2nd Tuesday (different this month) and is hosted by a different person in the SQL community each time. The idea is that it's kind of a rallying point to get a bunch of people to blog about a particular topic on the same day, giving a wide and varied set of opinions and interpretations of that month's topic. The hoster then posts a wrap-up commenting on all the contributions. I think it's a great idea and I contribute whenever I have time.

What is the topic for November?

This month I'd like to step back from the deep technical stuff and ask "why are DBA skills necessary?"

I don't want to color people's opinions by giving my own yet, but some things to consider are:

• What problems have you seen in your career that could have been avoided with some DBA skills?
• At what point does a SQL Server installation need a real DBA to look after it?
• How could DBA input help prevent design problems in data applications?
• Should there be cross-over been developer skills and DBA skills? What about architects? Storage admins?
• How can business continuity be affected by lack of DBA skills?
• How much can we rely on auto-tuning to ensure performant work loads?
• Is Microsoft doing enough to foster DBA skills as a point of excellence?
• What about on other RDBMS platforms? What about no-SQL?

I could go on for hours... I'm really looking forward to seeing where you take this topic and I'm expecting some great posts.

What are the rules?

As with any organized event, there are inevitably some rules that help make things run smoothly.

• You most post your contribution between Tuesday November 2nd 00:00:00 GMT and Wednesday November 3rd 00:00:00 GMT (i.e. Monday 8pm-Tuesday 8pm EST, Monday 5pm- Tuesday 5pm PST, etc)
• Note: there was a daylight-savings change on October 31st in Europe. I will accept posts from 4pm PST Monday to 5pm PST Tuesday as even I made that mistake :-)
• Your post has to link back to the hosting blog, and the link must be anchored from the logo (found above) which must also appear at the top of the post.
• Leave a comment here (below) or I won’t be able to find your post. I expect trackbacks work properly, but if they don’t check back here just in case and leave a comment if necessary.

Sample HTML to include the logo and link-back is:

<a href="http://www.sqlskills.com/BLOGS/PAUL/post/Invitation-to-participate-in-T-SQL-Tuesday-12-e28093-Why-are-DBA-skills-necessary.aspx"><img src="http://www.SQLskills.com/BLOGS/PAUL/image.axd?picture=2010%2f7%2fTSQL2sDay150x150.jpg" border="0" alt="" width="150" height="150" /></a>

NOTE: THIS DOES NOT DO A 'TRACKBACK' - YOU WILL NEED TO ADD A LINK IN A COMMENT ON THIS POST.

It would also be really nice if you...

• Include a reference to T-SQL Tuesday in the title of your post. (The more we bloggers advertise T-SQL Tuesday, the more we bloggers get T-SQL tuesday readers)
• Tweet using the hash tag #TSQL2sDay to follow links and other relevant conversations.
• Consider hosting T-SQL Tuesday yourself. If you’re interested let Adam Machanic Know. If you’ve participated in two T-SQL Tuesdays previously and you don’t let your blog go stale (blog once a month for the last six months) then he’ll put you in the rotation.

Summary

Don't fret about the rules, it's nothing too complex. If you're having trouble linking properly on the day, drop me an email (paul@SQLskills.com) or tweet (@PaulRandal) and I'll help you out - I'll be watching things all day.

As I said, I'm really looking forward to seeing a really diverse set of posts and I'll very quickly post a long summary with lots of editorial commentary and opinions too.

Have fun!

A quickie... this morning I've been writing a bunch of T-SQL code (yes, occasionally I'm allowed to do that :-) and I needed to programmatically check whether backup compression is enabled on a SQL Server 2008 instance. I futzed about for a few minutes with sp_configure and I was starting to think of a temp table plus INSERT/EXEC when I thought there has to be a better way.

I turned to my trusted friend Books Online (I'm constantly amazed at some of the questions people ask in forums and on Twitter than can easily be answered by looking in Books Online...) to help out and of course was reminded straight away of the companion view to sp_configure: sys.configurations (see Books Online here).

Here's a quick example:

IF (SELECT [value_in_use] FROM sys.configurations
    WHERE [name] = 'backup compression default') = 1
SET @BackupCompress = 1;
GO

It's always amazing how much you forget and how much there is to know - enjoy!

Every month there's a flurry of blog posts around the same topic - it's called T-SQL Tuesday and is a neat concept. This month it's being driven by Robert Davis (blog|twitter), who I had the pleasure of teaching in the March rotation of the Microsoft Certified Master - SQL class (he passed first time) and previously in internal Microsoft classes. The topic is about how to teach and learn, so I want to twist it around a little and talk about things from an instructor's perspective.

Kimberly and I teach a *huge* amount - classes, workshops, conferences, private clients - and we've seen the whole gamut of student types and classroom antics. In this post I'd like to lay out what I consider to be the things most likely to annoy your fellow students, annoy the instructor, and/or prevent you from getting the most from your class. Think of it as a not-too-subtle rant at a few bad apples out there. Either read along and feel guilty that you've done some of these, or read along and tut-tut that you've seen someone do this and it sucked.

These are in loose order, with #1 being the worst mistake to make. Some of these are controversial, but I'm an honest kind of guy, and people like how I run my classroom, so I want to get them out there. Here you go:

10 Take a phone call during class

If you take a phone call during class, I'll ask you to leave the room. At the start of the class I always ask for phones to be on vibrate and to step out if you have a call. I don't mind people walking in and out a few times to take calls - it's very hard to put me off when I'm teaching. But talking on a phone in class (apart from saying 'hold on a sec while I go outside') is just antisocial and inconsiderate. Don't do it.

If a phone rings during class, I'll start to dance. Everyone laughs. I'm letting you know that we all realize you totally ignored the instructions about phones that everyone else adhered to.

And if you *make* a call during class, expect no mercy. I've had this happen once. After he came back in from making the call, and at the next break, I went over and explained how incredibly rude that was and he could choose to stay in the class without his phone or leave. He stayed.

9 Sit at the back and do email/surf and then ask questions

There's one person in every class like this - who surfaces every so often and asks questions about stuff we just covered. My response is usually something like "we just covered that ten minutes ago, read the slides and let me know if you have questions". If you can't get it together to pay attention, at least check where we are in class before asking questions that tell everyone else you've been doing something else and are now wasting their time.

8 Persist with a tangential rat-hole

While laying out the ground-rules of the class at the start, I talk about how questions are excellent, the whole point is that you're here to learn, but that long discussions about your particular situation will have to go to the break, lunch, or after class. And I mean it. Classes are carefully planned to have a certain percentage of question and discussion time (some more than others) and so if you're going on and on about something that's not relevant for the rest of the class, you'll need to wait to monopolize the instructor's time when it's not everyone else's time too. I've actually had to say "ok - stop talking about that now, we have to move on with the class". Most often these people are really trying to do #1 below.

7 Bring your smelly lunch into the classroom

Everyone will hate you.

6 Come to a class where you don't understand the language it's being taught in

I struggled over whether to include this one, but it has to be said. Don't come to a class where you can't understand the language it's being taught in. I speak English, reasonably well :-), and I make a point of speaking clearly and explain things in a concise, unambiguous way. If I'm teaching a class in the US, the UK, or any other English-is-the-first-language country, I expect that students in a deep technical class about an engineering topic, with lots of arcane terms and the need for precision in explanations, are able to understand the language. I know there are a lot of ESL (English-as-a-Second-Language) folks in these countries, but if you come to a class with a bunch of other people and ask me at lunch on the first day to speak a lot slower and with smaller words because you don't understand English very well, the answer has to be no. I'm not being inconsiderate, you are. On the other hand, if I'm teaching in China, for instance, I'll seriously go out of my way to speak slowly and avoid language complexities and colloquialisms as that's the totally different audience.

The MCM has a prerequisite that you have to understand English really well before being accepted on the course, as it's fast-paced and deeply technical. A couple of ESL folks have fudged that requirement, come on the course, and failed because they couldn't keep up. It's really not fair to everyone else to have to slow right down for one person in a face-to-face class.

That's the most controversial of the mistakes I wanted to list, but I stand by what I've said. I'm not against ESL students in any way - many of the people I teach inside Microsoft are ESL - but you have to have a certain level of proficiency in the language the class is being taught in to be able to keep up. I've had people in classes that knew so little English they couldn't even ask a question I could understand - and I'm very patient and usually able to understand most people.

5 Come to a class without the required experience and knowledge

Most classes list the detailed agenda and the prerequisite knowledge, if applicable. This is so that you can gauge whether you're qualified to take the class. Don't come to an advanced class on disaster recovery and ask how to take backups using SSMS, or come to a workshop on performance tuning using wait stats and ask what an index is. You wouldn't send someone who can't swim to a class on cave diving, or send a freshman medical student to a symposium on endovascular aneurysm repair techniques, would you? So don't take a SQL class that you're not qualified to understand. You will end up a) not being able to follow the class and getting frustrated b) asking really basic questions that annoy the rest of the class and the instructor.

Oh, and by the way, reading a book about SQL Server doesn't remotely equal having experience as a DBA - so if you simply read a book to pass a qualification, you're doing yourself and whoever employs you a disservice.

4 Don't take notes

If you really want to learn, take notes about what gets drawn on the whiteboard and salient points of what gets discussed. That's why we give you a printout of the slides - so you can take notes on them. This may be more necessary with some instructors than with others - our slides are pretty dense so you can follow the story when reading them later (but that's a whole other discussion...) If you don't take notes, you'll forget things. And if you ask the same thing several times because you didn't note down the answer the first time, you'll really piss off the instructor. I had a class earlier this year where someone asked me the same thing 4 times over the course of 3 days. I was not happy, and I made sure it showed the last time by starting with "you've already asked me that three times..." as it was beyond ridiculous.

3 Ask questions to try to make it look like you know more than the instructor

You don't look cool. You look like a fool. Everyone is rolling their eyes at you, but you just can't see it. Yes, really.

Every so often I'll have someone in a class who wants to prove to everyone that they're very clever and know more than everyone else, and really doesn't need to be in the class because they're so smart. 100% of the time it's a man. There's nothing to be gained from trying to one-up the instructor. If you succeed, you may sit back all smug, but everyone else is thinking 'jerk' (or worse). These kinds of questions are usually about really narrow scenarios, or deep internals, that are beyond the scope of the class and most often the tactic fails, which makes the questioner more frustrated and ask more questions...

Invariably this leads to #2...

2 Argue that the instructor is wrong

Cardinal sin. If you think the instructor is wrong there are two correct ways to express that opinion: 1) say something along the lines of seeing different behavior in some circumstances, which leads to a nice discussion where everyone can agree and the instructor can explain he can't remember everything with a smile 2) come up to the instructor at the break to discuss it. Never accuse the instructor of being downright wrong in front of everyone. If you do, you'd better be 100%-absolutely-sure-beyond-a-shadow-of-a-doubt because one of two things is going to happen: 1) you'll be proved right and everyone will think 'jerk' (or worse). Or, and this is much, much, much more likely, 2) you'll be proved wrong, become embarrassed, frustrated, and angry and everyone will think 'jerk' (or worse).

Arguing obnoxiously is not the way to win friends and influence people, or to endear you to the class and the instructor. Most often the instructor is there because he or she knows way more than anyone in the class about the topic at hand - which is the whole point, so it's unlikely that they're wrong. It does happen, people are not infallible, but point it out nicely. And be really, really sure you know who you're arguing with before you start - pay attention to the two minute bio at the start of the class, because that's the explanation of why the instructor is qualified to teach the class, and what their expertise is. Every few classes I find myself arguing with someone about how DBCC works, or what allows the log to clear, or this or that and very occasionally I have to resort to one of the trump cards, which I hate doing, by saying "I'm sorry, you are wrong - I wrote that code", or "I'm sorry, you are wrong, I designed that feature". That sucks because I feel like I'm being arrogant. Sigh.

1 Come to class looking for "the answer"

There's one of these people in every class, who simply wants to know "how to index for *this* query" or "the *best* backup strategy". I like to joke that the answer to every question about SQL Server is "it depends!", with one exception: "should auto-shrink be enabled?". That's because there are no hard and fast answers - the answer really does depend on the circumstances. A good instructor does not teach answers, but instead teaches methodologies, theory, and background information, along with real-life examples of applying all of those so that you can find the answer for yourself, and even pass along the knowledge to your team/company. There's no point just teaching the answer, because what happens next week when you have another question? If you don't understand how the first answer was derived, you'll be stuck again and no better off for attending the class.

I see this over and over and it's depressing.

Summary

Ah - that's better. If you avoid doing all these things then you'll have a great learning experience and the atmosphere in the classroom will be conducive to being a sponge to the fire-hose of information. If not, then now you know why the instructor is looking at you disdainfully...

This turned out to be a lot longer than I expected. Now, don't take this the wrong way - I *really* love teaching, which is why I do it so much, so I'm not being a jerk saying all of this - I expect that when you come into a class, you come to learn. I don't expect you to disrupt things for the other students, and disrespect me as the instructor. I guarantee you that everyone reading this who's ever been an instructor has agreed with everything I've written above.

Don't be that person.

This evening I was reading an article in The Washington Post called Twelve Things The World Should Toss Out and it inspired me to start a new blog chain about the top-5 things in SQL Server we all wish would just be removed from the product once and for all.

Here are mine in order of evil-ness:

1. Auto-shrink. Grrr. See Why you should not shrink your data files for why shrink is bad. Auto-shrink is even worse. I tried to have it removed durign SQL 2005 and SQL 2008 development, but to no avail. It needed to stay for backwards compatibility...
2. The FULL recovery model being the default. I would guess that this is responsible for the majority of cases of transaction logs growing out of control. See Importance of proper transaction log size management.
3. RECOVERY being the default RESTORE option. The default should be NORECOVERY to stop people screwing up their restore sequences. I hope you can hear the exasparation from wherever you are!
4. GUIDs being able to be a clustered index key. I shouldn't even have to explain this one. SQL Server should warn you that a PK is by default a clustered index, and that GUID clustered PKs just suck.
5. The default data and log file growth rates of 1-MB and 10% respectively. Seriously, why did they change to 1-MB for the default auto-growth rate? However, the problem is - what should the defaults be? Answers on a postcard please...

These are my top-5. I hereby tag 5 my good friends (in no particular order):

• Brent Ozar (blog | twitter)
• Buck Woody (blog | twitter)
• Jen McCown (blog | twitter)
• Tom LaRock (blog | twitter)
• Aaron Bertrand (blog | twitter)

Please link back here so I see when you blog.

Thanks!

So what's important? A year ago I thought about all the involuntary DBAs out there who are getting to grips with SQL Server, and all the DBAs who are getting online into the SQL community looking for better operational practices, and more importantly, explanations they can use as justifications they can use for making an operational or architectural change. I started to think of questions that would make good editorial posts to explain the answers to help these people out - and we did a bunch of them together using surveys.

Over the last month or so I've found myself handing out links to many of these posts to answer Twitter or blog questions - so I want to pull together a list of links to these editorial style posts that talk about what I consider to be really important things for DBAs to consider. These aren't 400-500 level internals posts, they're easily understandable with links to deeper information.

I hope you find the information useful!

General

Becoming an involuntary DBA - you're not alone This post talks about the mindset you need to get into as you start on your DBA adventure. Accepting that there's lots you don't know and figuring out how to find information.

Importance of having a manageable environment This post presents a big list of things that I think you can do to make an environment with many databases and servers more easily manageable.

Architecture

Importance of choosing the right architecture and SQL Server Edition This post discusses 32-bit vs. 64 bit and Enterprise vs. Standard. Just because Enterprise is there, you might not need it. We actually just saved a client $250k by showing them they didn't need to use Enterprise Edition for what they wanted to do over the next few years.

Physical database layout vs. database size This post talks about some of the reasons to split a user database (i.e. not tempdb) into multiple files and filegroups, based on more than 1000 survey responses from blog readers.

Importance of choosing the right LOB storage technique This post discusses the pros and cons of all the methods of storing LOB (Large OBject - a.k.a. BLOB) data from a performance perspective.

Database Maintenance

Importance of data file size management This post is basically explaining why you should have auto-grow turned on, how to set it, and why you shouldn't rely on it.

Importance of proper transaction log size management This post explains that there are two valid ways to manage your transaction log - using transaction log backups, or using the SIMPLE recovery model.

Importance of index maintenance This post explores the pros and cons of the various methods of performing regular index maintenance - which you should absolutely be doing.

Importance of running regular consistency checks You cannot avoid running regular consistency checks - as DBCC CHECKDB (or equivalent) is the only thing that can find all the problems that can occur. This post shows you why.

Importance of how you run consistency checks This post explains some of the ways people consider adequate for performing consistency checks, but actually aren't.

Performance

Important considerations when performance tuning What do you look at when performance tuning? This post lists 10 main areas to think about and why.

High Availability and Disaster Recovery

Importance of defining and measuring SLAs You cannot put together a meaningful high-availability strategy and disaster recovery plan without knowing the downtime and data-loss Service Level Agreements that your business requires. This post explains why.

Importance of having a good disaster recovery plan This post explains why a disaster recovery plan needs to be comprehensive.

Importance of testing your disaster recovery plan And this one explains why there's no point having a DR plan if you don't ever test - there's bound to be something you've forgotten.

Importance of having the right backups You're not going to be able to meet your downtime and data-loss SLAs if you don't have the right backups to be able to do the restores you need to. This post explains a few backup plans and why they're good or bad. You should also read my TechNet Magazine articles Understanding SQL Server Backups and Recovering from Disasters Using Backups.

Importance of validating backups This post explains why there's no point having backups if you find that they're corrupt when you're recovering from a disaster.

Adding geo-redundancy to failover clustering Failover clustering is cool, but doesn't provide any redundancy outside of the cluster, or of the data itself. This post explains the various combinations of technologies you might consider.

Earlier today there was a thread on Twitter asking about what degrees and academic background people have who work on SQL Server. I volunteered to put together a reading list for those wanting to know more of the theory behind a relational database management system, rather than just how to use one.

Here I present a reading list that will take you from how to program well up to how to architect multi-threaded database servers. I've read all of these at some point between finishing my CS/EE degree in Edinburgh in 1994 and stopping dev work in 2005, and they're sitting on my bookshelf as I type this. They're all the best books I could find on the subject at the time, and they're all absolutely excellent. I've included Amazon.com links to the most up-to-date editions (because I'm nice like that ).

Programming

• The Art of Computer Programming, Volume 1: Fundamental Algorithms (Knuth, 672pp)
• The Art of Computer Programming, Volume 2: Seminumerical Algorithms (Knuth, 784pp)
• The Art of Computer Programming, Volume 3: Sorting and Searching (Knuth, 800pp)
• Algorithms in C++, Parts 1-4 (Sedgewick, 752pp)
• The C++ Programming Language: Special Edition (Stroustrup, 1030pp)
• The Design and Analysis of Computer Algorithms (Aho/Hopcroft/Ullman, 470pp)
• Design Patterns: Elements of Reusable Object-Oriented Software (Gamma/Helm/Johnson/Vlissides, 416pp)
• How to Solve It: Modern Heuristics (Michalewicz/Fogel, 554pp)

Underneath the RDBMS

• Computer Networks (Tanenbaum, 912pp)
• Modern Operating Systems (Tanenbaum, 1104pp)
• Distributed Systems: Principles and Paradigms (Tanenbaum, 704pp)
• Computer Architecture and Organization (Hayes, 624pp)
• Computer Architecture: A Quantative Approach (Hennessy/Patterson, 704pp)
• Cryptography and Network Security (Stallings, 744pp)

Concepts

• Parallel Processing and Parallel Algorithms: Theory and Computation (Roosta, 566pp)
• Decision Support Systems and Intelligent Systems (Turban/Aronson/Liang/Sharda, 850pp)

  Distributed Algorithms (Lynch, 904pp)
• Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery (Weikum/Vossen, 852pp)
• Transaction Processing: Concepts and Techniques (Gray/Reuter, 1070pp)

RDBMS architecture

• Database Management Systems (Ramakrishnan/Gehrke, 936pp)
• Introduction to Database Systems (Date, 1024pp)
• Database: Principles, Programming, and Performance (O'Neil/O'Neil, 870pp)
• Readings in Database Systems (Stonebraker/Hellerstein, 877pp)

You should also checkout the ACM Special Interest Group on Management of Data (SIGMOD), and the VLDB Conference - these are the premier academic conferences to do with database management systems.

This should keep you busy.. happy reading!

Over the last 18 months a group of SQL Server MVPs, led by Paul Nielsen and including Kimberly and I as editors, have been working on a book, responding to a challenge from Microsoft CEO Steve Balmer for MVPs to give something to the wider community than just our technical one. Now the book is available to purchase, with all profits (minus minimal expenses of the publishers) going to War Child International.

Buy the book, increase your knowledge, and help the children.

Rather than come up with my own blurb about the book's contents, I'm re-using the excellent write-up from the MVP blog, with their permission.  

With contributions from 53 SQL Server MVPs, SQL Server MVP Deep Dives, is organised in 5 parts: Design and Architecture, Development, Administration, Performance Tuning and Optimisation, and Business Intelligence. Within each part, you'll find a collection of concise and focused chapters that take on key topics like mobile data strategies, Dynamic Management Views, or query performance. The range of subjects covered is comprehensive, from database design tips to data profiling strategies for BI. The book features:

• Nearly 60 chapters focused on topics crucial for any SQL Server professional
• Edited by MVP Paul Nielsen, MVP Kalen Delaney, MVP Greg Low, MVP Adam Machanic, MVP Paul S. Randal, and MVP Kimberly L. Tripp
• Appropriate for SQL Server professionals of all levels
• Coverage of new features in SQL Server 2008

Whether you're just getting started with SQL Server or you're an old dog looking for a few new tricks, SQL Server MVP Deep Dives belongs on your bookshelf.

The authors of this book have generously donated 100% of their royalties to support War Child International. War Child International is a network of independent organizations, working across the world to help children affected by war. War Child was founded upon a fundamental goal: to advance the cause of peace through investing hope in the lives of children caught up in the horrors of war. War Child works in many different conflict areas around the world, helping hundreds of thousands of children every year. Visit www.warchild.org for more information.

You can purchase the book by clicking here.

(Be sure to join our community to get our monthly newsletter with exclusive content, advance notice of classes with discount codes, and other SQL Server goodies!)  

SQL Server 2008 R2 has been out for a while now (see http://www.microsoft.com/sqlserver/2008/en/us/R2.aspx) and many people are trying it out.

One word of caution: any database attached to a 2008 R2 server will have the database physical version number increased to 661. The database version number for 2008 RTM and SP1 is 655. This means that you won't be able to take that 2008 R2 database and attach it back (or backup/restore it back) to 2008 RTM, SP1, or SP2.

I don't mean this as a reason to not play around with R2, just be careful you don't inadvertently upgrade a database that you still need to run on 2008 RTM, SP1, or SP2.

For more info on database version number and how previous versions are not forward-version compatible, see these blog posts:

• Search Engine Q&A #13: Difference between database version and database compatibility level
• TechNet Magazine August 2008 SQL Q&A column which discusses physical version changes during upgrades
• Msg 602, Level 21, State 50, Line 1 on errors you'll see trying to attach or restore an uplevel database on a downlevel version

Hope this helps!

Several times this week I've been asked about how to become an MVP. A few people have posted on this, but here's my take. 

I think basically what it comes down to is that if you aspire to become something you're not already, you usually need to make changes in your life. Sometimes significant changes. But it's quite easy to prioritize the wrong thing by accident. Becoming an MVP doesn't mean compulsively answering every question on the SQL Server forums, or blogging huge amounts of stuff that others have already covered - but it doesn mean you have to get out there and interact with the community - it's all about the community. Here's what I recommend:

• Starting answering forum questions, but make *really* sure the answer is correct. Make sure you help out on the MSDN forums too, as these are one of the first places the MVP team looks, and aim to become a moderator if you can. This can really become an obsession - you have to ensure you're adding value rather than just answering for the sake of getting your score/reputation/ranking higher.
• Start a blog with regular interesting and informative posts about SQL Server (or whatever you're trying to become an MVP in). But again, don't be obsessive. It's easy to fall into the trap of posting stuff to try to get more people to read or become higher up a list. Check out this blog post I wrote: Are we too obsessed with rankings? And try to make your blog interesting with some entertaining stuff thrown in, for example Just how long should you make character fields? What's the longest word?
• Get on Twitter and join in the community. Get on Facebook or LinkedIn - somewhere that people can see something behind the professional persona. IMHO community isn't just about always providing answers - it's about knowing some of the people there too. Another blog post with more info: How Twitter and social networking changed my life...
• Start presenting. In the beginning this always sucks - it's hard to present when you've never done it before and most people find it terrifying. However, I'd say it's the #1 way to get involved in the community and get noticed. Don't aim for major conferences right away - it won't happen. Start with local user groups, SQL Saturdays, maybe do a podcast. In February I made my traditional Valentine's Day blog post to Kimberly a long description of how to speak in public, as a tribute to her helping me - see Public Speaking: A Primer.
• Find a mentor who's already an MVP to help you out. This is pretty crucial - you need someone who will tell you if you need to change the way you're doing something, maybe obsessing, maybe goals are a little off. I had Kimberly as my mentor, and she didn't hold back on the advice and constructive criticism.
• Be nice. No-one likes a smart-ass know-it-all who puts people down. This is a balancing act - don't be too humble either.
• Make friends with other MVPs. It's a community, right? Get out there and talk to them.

Lastly, take a step back and consider why you aspire to become an MVP. Do you just want the badge so you can show off? Is it something you want to tick off a list of achievements? Do you want to increase your professional standing? Do you think it will make you more attractive as an employee or consultant? Do you want to become a leader in the community?

Not all of these are valid reasons IMHO - I'll let you think which are and which aren't.

PS Great point from @sqlagentman - an MVP isn't something you're awarded, it's something you're formally recognized as already being.

Thanks to the attention of some scurrilous parasites, all comments will now be moderated. And to said parasites, please be aware that there's no point spamming my blog with comments linking to your websites as no-one will ever see them now. And I've contacted your hosting companies with your IP addresses, and a copy of each of your hundreds of spams.

Sorry folks - until the spam stops, comments are moderated. If it continues or gets worse, comments will be disabled.

Thanks

There's another DBA 'chain-blog' going around, this time started by Tim Ford, and I was tagged by Tom LaRock. The idea is that you're stuck on a desert island for six months with WiFi and you have to spend it doing something related to work. What would you spend the six months doing? If I break the chain then I won't get enough birthday cards to get in the Guinness Book of Records, or something else depressing, so I'd better join in.

At the moment, I'd probably say continue losing my life to Twitter, SQL forums, and blogging - but then I'd be blogging about blogging and there's the risk I'd get sucked into an infinitely-recursive blog post and I wouldn't get anything done. And Kimberly already thinks I blog too much, so I'd steer clear of that. I'd really prefer to spend the six months diving in the reefs around the island and checking out the stars in a sky with no light pollution, but I think it would be hard to make either scuba gear or a telescope from just coconut shells and sand, and I'm pretty certain that even if I could, the coconut-shell based air compressor for filling the scuba tanks wouldn't hold together when I powered it on either. But hey, where would the power come from? But if there's no power, how would the WiFi work? Hmm - the scenario's falling apart quickly - best cut to the chase.

I spent 15 minutes looking for a clean desert island joke to include here, then gave up, sat watching a heron fly past the deck and then figured out what I'd do. Now, you all know that I'm not a DBA, so I wouldn't have anything to do on a set of systems, but I do have a lot of things I'd like to do around SQL Server but have never had the time. Here are my top four:

Tool to explain corruption messages. The expert system of how to analyze all the corrution error messages that CHECKDB produces to find out what exactly it's telling you, and what may be deleted by repair, basically resides in my head. There's another copy that resides in Ryan Stonecipher's head (the guy that took over DBCC from me), but he's even less likely to have time to do this since he still works at MS. I'd love to program that expert system and make it available. Just like I'd like to put together the 'what exactly does each error message mean' PDF. I did it for 2000 and 2005 while at MS, and it took me 3 weeks. I have all that in my head too. I thought that writing the 2008 Internals book with Kalen would allow by in-head lazywriter to clean out some buffers, but it's all still there.

Write the book on maintenance and DR for involuntary DBAs. I keep getting asked what the good info is out there, and there's no one good place to go. The closest I've come to doing this is the first article I wrote for TechNet Magazine back in August 2008 - Top Tips for Effective Database Maintenance. There's a big need for a book aimed at non-SQL professionals as I see the same mistakes being made over and over in forums. This is another thing where I've got all the details in my head and spread through my blog and Kimberlys blog, but just need time to pull it together into a coherent story.

Write a script that will figure out the size of the next log backup. This is on my list of cool tools to write and give away on my blog. I've already done the how big will the next differential backup be, and the how much data will the next log backup include, but this one is a *lot* harder. I have a good idea how to do it, but I need a bunch of time to sit down and figure it all out in a solid script. And then test it lots.

Write a script that will produce a page checksum on every page. This has been on my list even longer. I know several ways to do this, but they all have undesirable side-effects, except one, which I haven't tried yet. This will be useful because once you enable page checksums after upgrading - nothing happens. A page doesn't get a page checksum until it's read into the buffer pool, altered, and then written out again. And there's no 'touch every page' tool.

Get hold of the SQL source code and add the following: online index rebuild of a partition, diff-based mirroring of FILESTREAM data, proper page-split monitoring, a new shrink algorithm that doesn't cause fragmentation, CHECKDB of a database within a backup without restoring the backup (my patent).

Ok - I guess I should tag some people too otherwise the chain will break and our house will be devoured by giant military squirrels... or something equally unlikely but tangibly scary. I choose my good friends Ward Pond, Greg Linwood, and Adam Machanic.

PS The title is a play on the BBC Radio 4 show 'Desert Island Discs'. It's supposed to be a geeky play on words. Well, I though it was funny and Tom had already used the 'Lovely Bunch of Coconuts' line. Thanks Tom.

Quick blog post to celebrate a bit of a milestone and round out the month of May - no blogging tomorrow.

Earlier today I was making a backup of all the content on my blog because I want to make sure I have a secure copy of it if multiple failures happen with site hoster etc. Look, come-on, this is me, I'm about the most paranoid person on the planet in terms of backups, corruption, HA, etc.

Anyway, as I was doing it, I thought it would be neat to count up the number of posts since I started this blog September 1st 2007 after leaving Microsoft the day before to join Kimberly. This is blog post #350 on this blog!

And as I was backing everything up in Word docs, one per month, I counted up the number of pages of 10-point font content on the blog. With the last few blogs posts, there's over 630 Word pages of content. Several book's worth. Which made me realize that I really really like writing and sharing information.

So - thanks for reading, commenting, cajoling, and asking questions. Keep it up and I'll keep it up too.

Vive la communite!

Last week's survey was another two-fold one - when you buy new servers, what architecture to you predominantly buy, and why?; when you buy new servers, which Edition of SQL Server do you predominantly buy, and why? Here are the results as of 5/17/2009.

For the first survey, the 'other' values were basically that 64-bit is purchased only if required. For the second survey, nine of the 'other' values were basically that Enterprise Edition is purchased only if required, one person uses Web Edition, and one person uses Developer Edition as they're just a developer.

I don't have a huge amount to say about these two surveys, I really just wanted to confirm my gut feel (and give you all a view of what's happening out there in the field).

For the architecture survey, I was entirely unsurprised to see that almost 80% of respondents are using 64-bit. It's widely known that 64-bit can give you better performance through the availability of more memory for SQL Server to use. Although you can use more than 4GB using AWE on 32-bit, that extra memory is only available for the buffer pool to use - not for general query processing - and AWE access does incur a little overhead. Much has been written about this and I'm not going to duplicate it here. A selection of articles can easily be found at http://www.google.com/search?hl=en&q=sql+server+64+bit+vs+32+bit&aq=1&oq=sql+server+64  More interesting is the small number of respondents who are not able to use 64-bit, either because their corporate policy is 32-bit (maybe because of cost?), they have software that doesn't run on 64-bit systems, or specifically because 64-bit is too expensive.

A few people only use 64-bit if required, and (I imagine) prefer to save money if it not by sticking with 32-bit. I wonder how long it will be until 32-bit servers are not available at all? Certainly future versions of Microsoft server software are starting to become 64-bit only - for instance Exchange 2010 (see here) and SharePoint Server 2010 (see here), will the next version of SQL Server be 64-bit only?

For the Edition survey, again, unsurprising results. 55% use Enterprise Edition for one or a combination of the various "-abilities" (if you make performancability a new word), with almost 10% more having the option to use it if required, and 16% having to stay with Standard because of budgetary constraints. What you may be surprised to see (but I wasn't from my time working side-by-side with the SQL marketing team) is that 20% of respondents don't need Enterprise Edition. There were a lot of improvements to the database engine in SQL Server 2000 and SQL Server 2005 that meant that for intermediate workloads (hmm - just made that up, but you know what I'm trying to say), Enterprise Edition isn't needed. And with synchronous database mirroring available in Standard Edition, you can implement a great, low-cost high-availability plan without paying for Enterprise. As you can see, I don't get any kickbacks from the SQL team for selling Enterprise Edition  Saying that, however, there are a lot of very cool features in Enterprise Edition in the various versions - but if you don't *need* them, why pay for the higher Edition just for the sake of it?

One thing I will say to summarize, it's important to look at your requirements in terms of performance, availability, etc to make the right choice of server architecture and SQL Server Edition. If you make the wrong choice, do you think your company will pay to rectify your mistake before the next round of capital-expenditure? Probably not - but you'll definitely pay for the wrong choice with several years worth of hassle trying to make the system be more performant and easily recoverable than your choices allow.

As always, thanks for participating in the surveys - I've had a bunch of mail from people who like to see what other people are doing.

Next up - this week's survey!

Go to www.wordle.net/create and enter a URL. Here's what it thinks of my current blog homepage:

Cool!

A sad, tear-jerky story about how a socially-inept, stay-at-home shut-in, SQL expert gets a new lease of life and finds he really does have friends out in the big world after all. LOL. Not. I'm definitely not socially-inept - managed to persuade Kimberly to marry me, right? Well, that was really down to the classic pick-up line "Hey baby, wanna hear about some undocumented DBCC commands?"

Ok, enough nonsense. I wanted to make some comments about Twitter and Facebook and how they're actually really useful to me.

I must admit, I was a vociferous opponent of Facebook until the start of April. Kimberly caved first under peer-pressure, then I ridiculed her for several days before succumbing to temptation myself. I've heard Facebook called the 'adult MySpace', and I have to agree. Why did I take the plunge? First off I was curious, and went through the phase of trying to read everything and post contrived funny stuff, but then sanity took over (and I had to do some work) and I realized that Facebook is a very useful tool for staying social while not physically seeing anyone.

As anyone who knows me knows, I *hate* telephones with huge passion. I mean, I really really dislike talking on the phone. I only turn on the ringer on my cell phone when Kimberly and I are apart, and that's not very often. Even when I'm abroad, I'll use Skype to talk to people. Really, phones are evil. They interrupt your life when someone *else* wants to talk to you. There's a reason we have a PBX in the house - so that it answers the phone and sends us email with the voicemail in (very handy for travelling as much as we do too). If I ever have to talk on the phone I like to schedule it. Now all this is quite weird, because in person I'm chatty and sociable. I just hate phones.

I digress. My point with the phone rant? I don't stay in touch with people over the phone, and most of the people I know are spread around the world, and socializing over email just sucks and isn't practical either. How do you keep up with hundreds of people on email? Most people struggle to get through just the work email they get every day, especially all the tech-folks that I'm friends with. Facebook solves that problem. None of the people I'm friends with on Facebook are the kind that have verbal diarrhea and update their status every time they sneeze or drink a glass of water. However, people post photos of places they've been, their kids, gardens; links to their blog posts, and other people's interesting blog posts; and generally stuff that their friends might find interesting. And the best thing is that it's like a blog - I don't have to read it if I don't want to, and nothing clutters up my inbox. And I post stuff they might find interesting. People I know only through work get to know the non-work side of me better without all the tedious small talk. It's like getting to know someone from a distance. Kind of weird I suppose. Best of all, I don't have to talk on the phone.

Now, Twitter. When I got on Facebook I saw all these status updates with #s and @s and thought what the hell is all that nonsense? Why would people type to each other with a 140 character limit? No way I'm getting involved in that. Then some people started badgering me to get on it (I-won't-name-names-Jason Massie-you-know-who-you-are, oops), and others warned me my productive life would end and we'd end up living in a trailer park eating baked-beans. So, of course my curious, addictive personality got the better of me and I joined. And yet we're still here in our house in Redmond and I still don't like baked-beans.

After the initial spend-all-waking-moments-reading-everything phase, things have settled down and I now believe that Twitter is very, very useful. It's a different crowd from Facebook (although there's some obvious cross-over) - and it's kind of like instant messenger with lurkers. I hate instant messenger. Just as bad as phones. As soon as Kimberly or I log in to IM, we're inundated with people wanting to talk to us. So we don't - ever. We actually have private IM names that no-one knows apart from us that we use when one of us is travelling alone (not since last December) just so we can IM without people butting in.

I digress again. So why is Twitter useful to me? Everyone on Twitter (in my circle) does something to do with SQL Server - so it's a kind of SQL-late-night-party-line (but not the kind you see advertized if you ever turn on TV at 3am). I'm able to keep in touch with other MVPs, people I know from conferences, and people I've never met - and learn about problems, ask questions, answer questions, and generally be active and social in the community - more than I would be able to do without Twitter. Without Twitter, I'd be limited to forums, classes, and conferences - none of which make for really being long-term *social* in the community, just active in it. And, to be honest, there's the real work aspect of it too. If more people know who I am, more people are likely to want to attend a conference session, workshop, or class that I'm teaching (the trick though, is that I have to be interesting or funny or both - not marketing crap). The more people I know in the SQL world, the more I find out about issues that I can use for blog posts and in magazine articles. It works both ways, as Kimberly has her blog title - "Improving my SQL skills through your questions!" - people get lots of info from me, I get info from them, and we all have a nice, happy, shiny community.

So yes, I was a serious detracter of both of these tools, but now I'm a serious proponent of them. If you use them the right way, not trying to read everything the 500 people you're following say, or tweet every time your dog barks or your wife is sick (like I did today), then they can be really useful. And I think people like to see something more personal than "conference Paul".

Brent Ozar (who has the distinction of being the first person I followed) has some great posts on Twitter on his blog and everything he says is true. I won't follow someone unless it looks like they're saying interesting/funny things. I don't care how many people follow me and I don't try to post stuff to get more people to follow me - I have plenty. If you don't like what I post, don't follow me, I'm not changing.

This has been a bit of a ramble, but I wanted to get a bunch of stuff off my chest. Has Twitter and social networking really changed my life? Honestly? Yes. In a big way? No, but in a way I wasn't expecting.

It's actually made me more social.

PS If you too want to risk living in a trailer and eating baked-beans, I'm on Facebook (search for paul@sqlskills.com) and Twitter at http://Twitter.com/paulrandal. Kimberly's also there on Facebook (search for kimberly@sqlskills.com) and Twitter at http://Twitter.com/kimberlyltripp.

5/11/09: Little bit of a rewrite today as it seems some people are taking what I'm saying the wrong way.

Over on Ed Bott's blog, last week he showed some inside info about the notorious "SQL Server problem" that caused the Windows 7 RC downloads to be so slow. The reason given was that SQL Server fragmentation caused the server to spike CPU and an index rebuild fixed the problem. Then the SQL CAT team posted that the problem was (paraphrasing) that the download team had only planned for a 100% jump in traffic, and got a 500% jump. The server (me: for a so-far undisclosed reason) couldn't handle the load, so a new server was dropped in and (me: this is interesting) operational practices were changed. Today (5/11/09) I find out that there's an ongoing investigation into just why the server couldn't handle the load. Notice I'm not saying the SQL Server was deficient in any way, but that the server as a whole couldn't handle the load.

Based on the initial information, and the CAT team not stating what the actual problem was, plus they had to change an operational practice (e.g. more frequent index rebuilds to remove fragmentation), we (Kimberly and I) came up with a hypothesis as to what might have happened. Remember that saying that the server wasn't setup for a 500% jump in load could mean a very large number of things. It could mean that the raw number of inserts overloaded the hardware on the server. It could mean that the application logic didn't scale to the extra workload. It could mean that the database schema didn't scale to the extra workload. The latter is the one that we're hypothesizing.

Whatever the actual technical issue was, there are two real problems: 1) the lack of planning, whether it was in terms of hardware capacity, application logic, schema design - whatever 2) the way the problem was handled by the MS PR folks, which not only made out that it was a SQL problem, but made people like me think that of-course-it-wasn't-a-SQL-problem, but it must have been a design/schema problem.

I discussed this with Kimberly and here's what we think happened (from her initial idea). There's been some discussion on how simply downloading a package could cause fragmentation - it's just a SELECT right? Wrong. If you look at what happens when you download, there's a GUID (Globally Unique IDentifier) that gets generated for your download, and there must be a table that tracks downloads, so the GUID is entered into a table. The table most likely has a clustered index, with the random GUID value as the primary key (or the high-order key in a composite key).

Every download thus produces an insert into the clustered index at a random location in the index. As the index pages get full, they eventually need to split, so more inserts can occur in the index at points defined by the random key. These 'page splits' are very expensive, causing lots of IO, log record generation, and fragmentation (both logical fragmentation that interrupts range scan performance and reducing page density from pages becoming less full). All of this takes CPU, which explains some of the spiked CPU from all the downloads. If there are queries that are scanning this data too, the fragmentation would cause terrible performance issues, resulting in more, smaller IOs - and also adding to the CPU load. Rebuilding the index (as was explained in the original blog post) would remove the existing fragmentation, increasing performance again, but wouldn't remove the page-split issue - which is why (apparently) they're going to rebuild that index every night now.

(This is the 100-level explanation for non-SQL geeks, a more in-depth explanation can be found on Kimberly's blog at GUIDs as PRIMARY KEYs and/or the clustering key.)

One of the comments below from Andrew Kelly suggests it could also be an ad-hoc plan problem - again, not a SQL Server issue, but a problem with the application. That could equally be explained by unplanned workload blowing capacity.

So was this a SQL Server issue? No. SQL Server did exactly as it was told, and has no choice where in the index to insert the new records - the GUIDs provide the insertion point. The problem was in the developer who created that schema without testing it with a very high workload - and the lack of a database maintenance plan to pro-actively find and resolve fragmentation issues, etc, etc. 

Now, this is pure conjecture, based on the facts that have come out so far. However, nothing that's been said since the issue (by the SQL team or anyone else) has made me question the hypothesis that some design/app issue led to the problem. As I said, capacity planning can mean a huge number of things - but saying that it's a capacity issue certainly doesn't mean it's NOT a schema design/app logic issue.

Once we hear what the root cause of the capacity overload problem was, I'll post more details. In the meantime, of course I'm not making out that it's a SQL Server problem - if you tell SQL Server to (for instance) use random GUIDs a the clustered, primary key - under high load it's not going to perform well. Inherent SQL Server problem? No. Human problem? Yes.

I hope this rewritten version is clearer now.

I was in a discussion earlier today, and it's one I've had lots of times in the past - both inside and outside Microsoft and the SQL team: why doesn't SQL Server do automatic <defrag, index creation, refactoring, de/normalization, backups, CHECKDBs, etc>?

Some of these were considered while I was still on the team, and I was *very* cautious about them. Here's why, taking automatic table de/normalization as an example (this morning's discussion). Assuming the logic to do the de/normalization based on usage patterns can be worked out, here's why I don't think it will ever happen (just off the top of my head):

• If it's wrong even once, no-one will ever use it again.
• When should SQL Server change the table definitions? What time of day is best?
• Where should the new table be placed? In which filegroup?
• What if there's no space to do it - should the database autogrow because of an automatic process? And then should it shrink afterwards?
• How far should the change plan parallelize?
• Who manages the transaction log size if the table is really large? Automatically take log backups? What if there's no space for the log backups? What about space on the log shipping secondaries? And the time required to roll-forward the log on the log-shipping secondaries?
• What about the impact of extra transaction log on database mirroring? Both in terms of the huge SEND queue preventing log truncation, and the huge REDO queue preventing the mirror coming online quickly?
• What if a cluster failover occurs during the operation and the rollback prevents the database coming online within the company's RTO?
• What if there are an replication topologies setup? How do they get quiesced for the schema change?
• How does the app get changed to handle the different schema, or do views get created automatically? Indexed views or not?
• What if Change Data Capture is running? Should it automatically create a new capture instance? What if both are already in use?
• How do SPs get updated to the new schema? Build in the datadude engine as part of SQL Server?

My point: it's a lot harder than you think to just put some automatic behavior into SQL Server. 

Now, saying that, I hope that some of the others do happen at some point, but with lots of config parameters so I can control them.

After being mercilessly pressurized by many people (and I blame Jason Massie the most), I've joined Twitter and I'll be commenting lots on it. Why did I finally cave? Well, I've been seeing lots of little things in forums and newsgroups that don't merit a full blog post but are worth letting people know about. So - feel free to follow along. My username is 'PaulRandal' - original, huh? I'm sure I'll get just as sucked into Twitter as I have to FaceBook - luckily I can type fast :-)

Enjoy!

PS You might not find me in Twitter search until I've posted a few times - try http://search.twitter.com/

This feels like a bit of a strange post for me to make, but I want to make it anyway, and don't take it the wrong way...

I've recently started following SQLBatman's blog and I was astounded that he had to post a follow-up to his list of SQL blogger rankings (disclaimer: including ours - thanks!) because he'd been getting emails from people who obviously weren't as high in his list as they thought they should be, even though they were *his* rankings of their blogs. It struck me that with the amazingly connected society we live in now, and the ubiquitousness of things like blogs, Facebook (to which we're unfortunately addicted), and Twitter (which we're sternly resisting so far) - maybe we're becoming a little too focused on how popular our blogs are or how many people are following our Twitter feeds?

I used to be like that. When I first started blogging about 3 years ago on the Storage Engine blog at Microsoft, and then when I left and switched to this one a year later, I was pretty obsessed with how many people were reading the blog posts. Was I posting interesting info? Could I get away with jokes? Would my opinions offend someone? Was anyone linking to me? Why aren't I in XYZ's blog-roll?

Then I realized that, to be honest, the obsessing was taking the fun out of blogging and now I don't pay that much attention to the stats and just post stuff I think is interesting. I wanted to do this blog post to give a piece of advice to new bloggers and those who thought they should be higher up in, or just in, SQLBatman's (or anyone else's) rankings: don't get wrapped up in the numbers and rankings, and don't complain when someone doesn't rank your blog as highly as you think they should, or list it in their blog-roll. It's very easy to get bitter when a post doesn't get the numbers you think, or no-one links to it, and then start thinking along the lines of "why am I spending all this time doing this when no-one's watching?"

People are watching - there are thousands of 'lurkers' our there who you'll never see and never hear from, but they're watching and learning from what you post. Just focus on the content and if it's good you'll be discovered and/or ranked higher. Don't think about what to post that will make your ranking higher, think about what to post that's unique, interesting. and useful to people in the community. You can't really control what people think of what you post. I'm sure some people won't like this post, but I'm going to post it anyway.

From Field of Dreams 2: "If you build it, they will come".

Not an April Fool (although SQL Server Central has a great one) - Kimberly and I were both re-awarded MVP status for another year - cool! Don't expect any blog posts this week from either of us - we're on vacation with the kids down on St. Pete beach in Florida. Back to work next week. Have a great week!

Just noticed this come up on my Facebook news feed - how to code assignment statements when programming (not in T-SQL):

1. if (foo == 4) then ...
2. if (4 == foo) then ...

#1 is the most natural way to write the conditional expression, but has a *massive* potential for introducing bugs that are very, very hard to find. If the second '=' is omitted, the conditional expression suddenly becomes an assignment statement and evaluates to true. Nasty.

#2 is the best way to avoid such problems, even though it seems unnatural. If the second '=' is omitted, it becomes an assignment statement but the compiler will barf, because you can't assign a value to a constant. (Some languages and data types may be immune to this - so this isn't a blanket statement - it's certainly a problem in C++.)

#1 was the cause of several bugs that took me a while to find while working on the Storage Engine code - all C++. I always use #2.

PS if (foo = 4) won't compile in C# if foo is an int, but you can come up with weird cases that do compile and break. Who uses managed code anyway?!? ;-) (ok, no hate mail please)

I'm very pleased, and deeply honored, to announce that I've been made a Microsoft Regional Director. This is one of a very small group of people (about 120 worldwide) who Microsoft sees as influencers of, and liaisons between, the Microsoft community at large. Apart from me, the other SQL MVPs who are also RDs are Kimberly and Greg Low.

I looked around for a good description of what RDs do and what the RD program is all about and found two blog posts:

• Microsoft Regional Directors don't work for Microsoft
• Who are the Microsoft Regional Directors?

And you can get the complete list of RDs (I'm not listed there yet) at the RD site The Region.

Time for a few drinks tonight!

There's a long-running discussion with people tagging each other to post advice for people new to SQL Server, about what they know now and wished they'd known ealier in their lives/careers - lot's of SQL MVPs and other luminaries have been doing it and I've been tagged now by my good friend Ward Pond - here's his entry.

The idea is to give two pieces of advice to help people out. My two came to mind almost instantly.

The first is a tenet I live by - there's no fate but what you make. It's actually a quote from the Terminator 2 movie and it basically means that nothing happens to you unless you make it, and you're responsible for your own life. This applies equally to life and to your career.

If you're not in an optimal place in your life for whatever reason (happiness, job, city, partner), then it's up to you to change it. And you should have the confidence to try. Sometimes you might try and fail, but at least you can say to yourself that you've tried. I've changed jobs, cities, and partners a few times each and (luckily for me) it always worked out. Sometimes the change was hard to make, sometimes it wasn't. But I knew it was up to me if I wanted a change so I had no choice but to make it happen or adapt to the current situation.

For your career, and this is where I'm touching on SQL Server, there are some situations that you may get into that are entirely of your own creation. Someone breaks into your server because you didn't check security. The company goes under because the sales database was lost and you didn't provision backups. You get a bonus because you tuned the indexing strategy so performance could handle the big sales weekend. Whatever. I believe that everything that happens to you is from your own making (apart from 'random' things like car accidents). You may say that something happened in your job that you had no control over - but you took that job... It's an interesting way to look at life, but that's what I know now.

The second thing is purely about SQL Server. If you're a DBA, some day in your career you will encounter database corruption and you will be responsible for clearing it up. Don't stick your head in the sand and fool yourself that it won't happen to you. It will. Be prepared. Take backups. Check your backups. Come up with an HA strategy. Practice restoring. And so on. I've been involved in hundreds, maybe more than a thousand, of corruption cases while at Microsoft and beyond. The over-riding take-away for me from that (ongoing) experience? People are unprepared and don't know what to do. That's what I know now.

I hope these are helpful and I've fulfilled my obligation.

I hereby tag: Greg Linwood, Jason Massie, and Bob Beauchemin.

PS Kimberly was tagged - her post is here.

There's been an interesting discussion on SQLServerCentral about whether this question is valid for a DBA interview: what's the name of the executable that runs SQL Server?

My view is that it's a perfectly valid question, based on the cliched premise that the more you know, the further you go. I've conducted hundreds of interviews for positions at DEC and Microsoft and I've always been more impressed with people that knew more stuff (and why that stuff was useful to know - rather than just knowing weird facts by rote) than people who said they could look it up. To me, if someone knows things like the name of the SQL Server executable, it says to me that they've had more experience dealing with interesting situations (like having to start the server in single-user mode, or divide up resources on a multi-instance server using WSRM). And for that, they'd go higher up my 'hire' list than someone who would have to look it up. Of course, that's just one out of a large number of traits and characteristics that I'd be looking for.

So, my question to you is, do you think that's a good interview question (coupled with something to weed out those who don't know why it would be useful)? Vote in the survey below, and reply with any questions you think really are invalid for a DBA interview.

Thanks

PS And don't worry, it's not all going to be surveys from now on - I'm just having fun with a new toy. Some good internals posts coming up next week! 

One of the opinions that was expressed yesterday by our developer friends (a bunch of Regional Directors - and look, Kimberly's the featured RD today on http://theregion.com/) is that SQL Server is just plumbing. Consider the developers (or app architects) as plumbers. They see SQL Server as a few pieces of copper pipe joining a few parts of the app together, with maybe some flow control in there somewhere, like below. (You might need to right-click and select 'show picture' - I don't know why - I just do databases :-))

There shouldn't be anything in a piece of simple copper pipe that impedes the water flow, right? That's what you'd think. The problem is that mental model of a simplistic data store is wildly inaccurate. What they think of as a bunch of simple copper pipe and some taps is a really a very complicated machine, like below.

There should really be another step in the software development lifecycle - during the design phase, there should be a question that says 'are you doing anything with SQL Server? (Y/N)'. If the answer is 'no', the lifecycle model continues. If the answer is 'yes', then STOP and consult a DBA or database-savvy developer. Just like working on a house, most people will call a plumber rather than mess around with pipe-work themselves.

Kimberly's going to pick this topic up big-time on her blog - keep watching there!

Today we've spent a lot of the day in discussions with some folks about developers vs. DBAs, and how it's often the case that the two don't work together. Developers need to know the effect of their design choices on the database, and DBAs need to educate the developers. There should be a close working partnership between the two but bad communication and ignorance often get in the way - the DBAs don't know what the app devs want from them, and the app devs don't understand *why* the DBAs are so protective of the data tier. Neither side understands the day-to-day challenges of the other. Misunderstanding breeds conflict breeds animosity breeds intransigence and uncooperativeness. One of the eye-opening things sometimes is teaching DBA stuff to developers and vice-versa so they see the challenges and technology choice implications both ways.

We were pointed to this spoof video about a DBA-dev confrontation - http://www.benhblog.com/2009/03/linq-dba-vs-developer.html - pretty funny.

If you're new to the blog then you may not have seen my Search Engine Q&A series (or seen it and not realized what it is). It started out that I was watching the incoming search engine queries that hit the blog and worked out what common questions people were searching for, but then I turned it into a 'what are common problems on the forums that I see'. Anyway, there are a bunch of questions that I've answered that make some interesting reading and touch on some pretty diverse topics. Here they are in chronological order, with links. Don't forget that I fastidiously categorize all posts and you can use the category links on the left hand side of the blog.

1. Running out of transaction log space - how to tell why your log is growing and two common cases - no log backups and a long-running transaction
2. How to move a database while database mirroring is running
3. Mirroring - how long does it really take to detect a failure with database mirroring and how to combine mirroring and clustering
4. EMERGENCY mode - how to access a RECOVERY_PENDING or SUSPECT database
5. Multi-core vs. single-core CPU performance
6. Using the undocumented fn_dblog log analysis tool - how to see whether a transaction is contained in a backup
7. Multi-file backups - how to restore from a backup file containing multiple backups
8. How index maintenance can break mirroring
9. Updating constraints - how to update the constraints in the partitioning sliding-window scenario
10. Combining index and statistics maintenance
11. Designing a global-ready database
12. Multi-file databases to avoid contention - for tempdb and for user databases - should you? And the follow-on about the dangers of sweeping generalizations
13. Difference between database version and database compatibility level
14. How 3rd-party drivers can break DBCC CHECKDB
15. Using mirrored backups
16. Concurrent log and full backups
17. Backing up a VLDB - whether to split the VLDB into filegroups or smaller databases
18. Determining the uptime of SQL Server
19. Myths and misconceptions around index rebuilds
20. Database 'boot page' and boot page corruption
21. 'File header' pages and file header page corruption
22. Which pages cannot be single-page restored?
23. How to recover from a full transaction log
24. Why the transaction log can't be instant initialized
25. Why log backups aren't always the same size as the log itself
26. Myths around what can and cannot cause corruption
27. How does the storage engine find variable-length columns?

 Enjoy!

As you may have been seeing over the last few weeks, there are intermittent errors in some parts of mine and Kimberly's blogs. Our hosting site and our blog guy have figured out that there's an ASP version mismatch which is causing the problems - and they're going to fix it this week.

So - apologies for the problems - they've been bugging us too. If you hit an error, refreshing a few times should clear it.

[Edit: 03/08/09 - looks like everything's working now!]

It's become something of a tradition for me to do a Valentine's Day blog post (the 2008 one about SQL Server blogs is at Wow - so many blogs!) as we don't do anything special otherwise - I don't need a "Hallmark Holiday" to tell Kimberly I love her .

Ahem - well this year I'm choosing a topic where I owe a lot of my success to Kimberly - public speaking. Kimberly is renowned as a world-class presenter on SQL Server and I flatter myself that my reputation is getting up there too - with a *lot* of help from Kimberly over the years. In a recent blog post over on SQLServerCentral.com, Andy Warren kicked off a lively debate on speaker skills and how to improve - a general sentiment was that new speakers are often afraid to ask for help from more seasoned speakers, so in this post I'm going to brain-dump as much advice as I can for all the upcoming speakers out there.

Public speaking is something of an art and a science - there's no totally right or wrong way to do it and you have to find the style that works. One of the top speaker trainers that Microsoft uses (and a friend of ours), Richard Klees, says that slides should have a minimal number of words and you should speak slowly. If you've ever seen Kimberly or I present, you'll know that we do the opposite - speak fast and have packed slides - but it works for us. Since my first terrifying conference session at TechEd US in June 2006, I've presented countless chalk-talks, sessions, workshops, and multi-day classes around the world and I'm continually honing my skills. In no particular order, here are a bunch of things to consider that I've learned along the way - I'm going to be very honest with my thoughts, I'll probably forget some stuff, and I may wander a little...

• Choosing a subject. This may seem pretty obvious, but only speak about things you know. I'd never try to do a session on using the CLR, or writing stored procs - even though I know a few things, I can't speak authoritatively and confidently about them. The best sessions are those on subjects that you know really well. Don't try to cover too much in a single session - have a balance of depth and breadth. Be aware of the level (depth) of your session and only go to the level that you know about the subject. Different conferences use different levels, but here's one I put together for the MVPs working on the MVP book, based on DBCC:
  • 100 - Beginner (e.g. what does 'corruption' mean?)
  • 200 - Intermediate (e.g. what do I do when corruption is detected?)
  • 300 - Advanced (e.g. how do I do take advantage of partial database availability and online piecemeal restore?)
  •  400 - Master (e.g. how can I fix broken system tables using the DAC and server single-user mode?)
  • 500 - SQL Server Internals (e.g. how does the read-ahead in DBCC CHECKDB differ from regular adaptive range-scan read-ahead?)
• Know the audience. This plays into choosing a subject - I wouldn't present on corruption survival techniques to a bunch of hard-core developers, nor would I present the internals of CHECKDB to a group of involuntary DBAs. Make sure that what you're talking about and how you talk about it is appropriate to the audience otherwise they'll feel frustrated and things won't go well.
• Demos. People like to see things in action - so most technical presentations include demos. A good presenter is equally comfortable talking off slides or talking through a demo. Demos need to be appropriate but are hard to get just right. People need to be able to follow what you're doing - if you're flying between windows and never explaining what you're doing, that's not really a demo. If you have a demo where something takes a minute to run, fill the gap by explaining about what's happening. Protracted silence is not good in a presentation. Make sure your demos work - broken demos will happen to everyone (the joke is that there are 'demo gods' and some days they just don't smile on you) but that should not be the norm. Make sure your demos are predictable and you know how to recover if something goes wrong. Run through your demos on the machine you're going to do them on - I remember writing a corruption recovery demo and being startled in the live presentation when a database I'd corrupted at home behaved differently on SQL 2008 than SQL 2005. Don't have over-complicated demos - they will break. Most importantly - a demo should show something you've talked about in action. If not, why are you doing it?
• Nervousness. Everyone gets nervous - no matter how many times you present. The only thing that improves is how well you deal with it and how quickly it goes away. Well, I guess you also get less nervous as time goes on, but there's always that little buzz of concern whenever I'm going to present. I think that's a good thing though - if you get too complacent, you won't do as good a job of preparing and making sure everything goes smoothly. Even for my corruption decks, I still spend 5 minutes skipping through the slides before the session to remind myself of the order of things and to get comfortable that I haven't forgotten that I'm doing a particular demo, for instance. Once you start speaking, the nervousness should go away pretty soon as you get into the swing of things. One trick I taught myself when I was in China in 2006 presenting other people's decks was to practice the first two minutes of the session until I knew what I was going to say off by heart. By the time I'd gotten through the prepared opening, I was comfortable and in the zone. Mental preparedness is a big part of not being nervous - I call it being in the zone - you've got your head ordered with what you're going to say, your demos are all prepped, you've got everything setup and you're just waiting for the green light. Kimberly and I both have our little routines that we go through to get in the zone.
• Putting together a slide deck. This is the meat of the whole thing - your slides are what will guide you through your presentation. They need to tell a story, with a beginning, a middle, and an end and then need to flow well rather than jumping around between topics. I like to have the end of one slide lead into the next one. Writing good slides takes time to learn  - I'm constantly tweaking slide decks to make them better. There's lots of stuff written about writing slides so I won't go into much detail - the number one thing I'd say is to use a readable font and project in 1024x768. Don't pack your slides full (even though we do sometimes) and don't write down everything you're going to say. A slide should really summarize a couple of minutes of speaking. Don't feel like you have to say everything that's on the slides. Make sure that someone reading the slides offline can also get the idea of what you want to say.
• Powerpoint. Much has been written about what to do and not to do when using Powerpoint. I could spend a whole other blog post on it, but this one's long enough. Just go watch this funny 4-minute video - http://www.youtube.com/watch?v=cagxPlVqrtM (there are a ton of videos out there - use "bad public speaking videos" in Google - but the link I gave is one of the best-known). Enough said. One thing I will say though is the old "a picture speaks a thousand words" - I could spend 5 minutes describing a data record structure to a room full of people and none of them will have the whole picture in their head. Instead I have a slide with a picture of a record structure on it with annotations. Oh yes, and animations - they're great but they don't work very well on a printed copy of the slides...
• Using humor. Making the audience laugh is a good way to get yourself and them audience relaxed (yes, the audience needs to relax too so they can absorb what you're saying). I don't like to tell jokes when I present, but I can usually recall appropriate Dilbert cartoons - and when Kimberly and I co-present, we make fun of each other, which most people find makes the atmosphere really genial.
• Co-presenting. Only ever do this if you're *very* comfortable with your co-presenter, otherwise it can be disastrous. Kimberly and I will only ever co-present with each other now (although Kimberly's done it before with a few others) as we're fine with interrupting each other and complement each other well. However, we had some issues when we first started doing that and we had to learn to tone down the "cuteness" of being co-presenters and husband-and-wife - and we have to be careful with what we say to each other depending on the feel of the audience - jokes about being her being blonde, or me being Scottish might not go over well. Co-presenters need to be matched in terms of ability, style, confidence, etc.
• Why are you there? Give the audience some indication of why *you* are the one standing up there presenting to them. At the start of each slide-deck I present, I have a bio slide, but I only point out the relevant stuff. In fact, this last year in the corruption sessions I've taken to saying "here's a whole slide of stuff about me, but all that's really important today is that I wrote CHECKDB and repair, so that's what we're going to talk about". The audience can read all the other stuff later if they want - the odds are they already know about you anyway.
• Self-promotion. Be very careful. By all means have a slide with some of your qualifications, books, etc on it, but don't labor the point. People aren't there to hear about how wonderful you are. Don't blatantly plug your services, books, etc within your slides. We got dinged by someone at TechEd US in 2008 because they thought when we mentioned our blogs we were trying to get people to visit our website to sell them stuff. We now make a point of saying that our website has no advertizing on it - just free info and all the blog links in the slides are more free info. On the other hand, public speaking is a good way for you to advertize yourself and become well-known. The golden rule here is that if you present really well and come over as authoritative on the subject, people will naturally remember you and contact you if they're interested in working with you.
• Projection. You need to make sure the audience can hear you. That doesn't mean you have to shout, but your normal speaking voice is usually not loud enough to carry across a room. Don't talk down to the floor and if in doubt, use a microphone. At any conference, you *will* be forced to wear a wireless mic so try one out if you get the chance. Make sure you speak clearly and have good pronunciation. This is especially important if you're presenting in a country where the language you speak is not the first-language of the audience (e.g. when I present at TechEds outside the US, or if you're presenting in English but that's not your first language - quite common in the US).
• Tech check. Make sure that your laptop is compatible with the presenting equipment. Nothing says 'amateur' more than turning up to your session 5 minutes before it's due to start and finding that your laptop doesn't display properly. On the other hand - beware of over-zealous technicians that can really interrupt you getting 'into the zone' before your session starts. However, *always* be nice to the technicians otherwise you'll get a bad reputation at conferences - I've heard of this happening. Make sure you're really familiar with your laptop and how it displays.
• Dress code. This depends on where you're presenting. At TechEd, it's brown or khaki slacks plus a TechEd speaker shirt. When I teach anywhere else, even user groups, I wear jeans, shoes and a dress-shirt. Dressing smartly makes me feel more professional and comfortable. Really the bottom line here is that you should be appropriately dressed - a 3-piece suit for a user-group is over-kill, but be careful not to under-dress too.
• Practice. As with most things, the number one way to get better with public speaking is to practice. There's a good reason why conference organizers (ourselves included) want to know your speaking experience - proof that you've had lots of practice and won't tank in front of an audience. Try giving your presentation to an empty room, or to a friend or colleague. Best thing is to have a mentor that'll help you.
• Getting a mentor. Try to find someone who is a good speaker and that you trust. Have them watch your presentations and give you frank feedback. You'll improve in leaps and bounds by having someone point out where you're going wrong.
• Feedback. If someone's nice enough to give you constructive feedback on your presentation technique, take it as such. Don't bristle or be offended - they're trying to help you. Be open to criticism (self- or from others) - it's the only way you'll get better. If you're giving feedback, think about who the person is that you're giving feedback to and how they're going to take what you have to say. Managing teams of people from diverse cultures at Microsoft helped me immensely here - feedback is hard to give and receive.
• Take-aways. While you're writing your presentation, think about what you want the audience to take home with them. I like to have a slide at the end that spells out what I think the take-aways are. Don't ever end on a negative point though otherwise that's what people will remember the most. You want to make sure that people don't leave the room wondering what the message of your presentation was.
• Writing an abstract. You need to make sure that there's enough info in the abstract to make it compelling for people to want to attend the presentation - or not. Nothing annoys an audience more than an abstract that gives a false impression of what's in your presentation - that means that people are wasting time watching something they weren't expecting. The title of your presentation also has to reflect the content for the same reasons. Here's one I've used for the last year that I think is a good example:
  • Corruption Survival Techniques
  • Your database is corrupt - what do you do? Well, it depends! How critical is the data? Do you know what's really wrong with the database? What does all that DBCC CHECKDB output mean? Should you restore or repair? It’s all about limiting downtime and data-loss when a corruption occurs - from knowing the tools to understanding the implications of choices you make. In this demo-heavy session Paul and Kimberly will give you insight into how to recover from corruption without making things worse. Most importantly you'll get step-by-step instructions for dealing with the more common scenarios.
• Tangents. Don't be afraid to take tangents, but make sure it doesn't screw up your timing and that you get back on-topic. I keep a LIFO stack in my head to make sure I get back to where I started and will often say out-loud "Popping the stack back to...". It shows that you're flexible and able to wander away from the main stream of the presentation but that you care that the audience gets to hear everything you were orginally planning to say.
• Whiteboarding. Once you're really comfortable presenting, you should be able to switch back and forth between using your slides, and doing ad-hoc stuff with a whiteboard - or even doing a whole chalk-talk without any slides. Whiteboarding takes some getting used to - write legibly and big enough so everyone can see. Be aware of where you're standing in front of the whiteboard and who can't see because you're blocking them - so move around. Write in black or blue - red and green can't be seen very well from a distance. For extensive whiteboarding, the marker will start to run dry because of the angle you're holding it at - so make sure you have a few spares. We love whiteboarding - and in fact our first "date" was two hours whiteboarding partitioning schemes right after we met for the first time at TechEd. Sweet memories... 
• Props. I find that I'm much more relaxed if I have something in my hand to play with - like a paper clip or a water bottle cap - something small that won't distract the audience.
• Clickers. If you're serious about presenting, buy a wireless clicker so you don't have to walk back to your laptop to change every slide - it looks really bad and says that you're an amateur. The one Kimberly and I use is at LaserMouse.com. Make sure you have spare batteries with you too - but don't go too extreme - we travel with 5 laptops between us - long story - see here...
• Movement. This really comes down to personal preference - but I don't like to stand in one place. If you walk around a bit it gives the audience's eyes something to follow and can be more engaging that just standing still. But don't wildly gesticulate too much - both Kimberly and I do this sometimes when we get carried away. If you have a podium, don't get into the habit of hiding behind it and using it as a barrier between yourself and the audience - come out from behind it and get used to feeling exposed. You'll get used to it and will become a much more confident speaker. If you don't, odds are that one day you won't have a podium and then you'll feel and look uncomfortable.
• Dealing with questions. This is another personal preference and depends on your comfort level with what you're presenting - questions can be very off-putting. No-one likes to be caught out but if you are, never make something up or try to weasel out of answering. A really powerful statement is to say "I don't know the answer, but I'll find out - come up and see me at the end". People like to see that you're confident enough to admit you don't know everything. Don't fall into the trap of letting people's questions take over the session - know when its time to move on and politely say something like "we need to move on to get everything covered but I'll stick around for questions at the end". Don't take too long answering a single question, and don't let someone waffle on with their question either. Oh, most importantly - repeat the question for the audience - either explicitly, or say that you'll repeat the question as part of the answer. Think about what questions people might ask and try to forestall them by answering them as part of the presentation - sometimes I'll have a a Frequently Asked Questions slide that I'll run through so everyone gets answers.
• Timing. It's really important that you don't run over your allotted time. The audience needs a break, the next speaker needs to setup - it's just impolite. On the flip-side, you don't want to finish 15 minutes early in a one-hour session otherwise people think they've been short-changed. Getting the timing right is very difficult to do when you're first starting out - you need to take into account demos, questions, problems but above all else, you need to keep track of the time while you're presenting. Don't look at your watch every five minutes though - have an easily readable clock on the presenting desk or better yet, a clock on the wall at the back of the room.
• Eye contact. As you're speaking, move you eyes around the room and look at people - it makes a connection and shows you're confident. It also lets you see people's reactions to what you're saying. This is hard to do at first but if you force yourself it'll become second-nature pretty quickly. Don't go too fast though and you don't have to hit everyone in the room. In a large auditorium with lights shining in your face, it's impossible to see the audience, so just go through the motions as if you can see them anyway - it'll look much more natural. 
• Thinking of a word. My brain has this weird thing that it does - every so often I'll be in mid-speech and the multi-syllable word I really want to use next just won't come. This can be really off-putting and worrying the first time it happens but I've learned to recognize when I'm not going to be able to think of the word and to describe my way around it, sometimes even saying "I can't think of the right word". I know this happens to other people too - just don't spend 20 seconds standing there trying to rack your brain when it does - accept it as sign of fallibility in your aging brain and move on.
• Hesitation. There's a natural tendency for you to stop every so often while you're brain processes what to say next. At these points, the best practice is that no sound comes out of your mouth. You want to avoid repeated sounds like "erm", "ok", "so...". It's incredibly hard to stop yourself doing this but if you can vastly reduce how often you do it, your presentation will look a lot more polished and you'll seem more confident. My commute used to be about an hour each way into Microsoft, and I trained myself to not make noise when hesitating by spending a week trying to give a 5 minute speech on CHECKDB while driving without saying "erm". It took a while and you'd be surprised how difficult it can be to work up the courage to start giving a speech to yourself in the car. Recently I was using Camtasia to record about 8 hours of presentations for Microsoft and I had the same problem getting started - mouse pointer hovering over the Start Recording button - you just have to go for it.
• Confidence. Passion. Enthusiasm. If you can exude these three things when you present then you'll go a long way. Nobody wants to sit and watch someone who doesn't sound like they believe what they're saying, or drones on in a monotone voice. When it comes down to it, what Kimberly and I present is really dry, technical information - how to recover from corruption, how to tune your indexing strategy, etc - but we're *really* into what we're talking about and that shows in how we present. If you're not interested in what you're presenting, you're going to find it hard to present it with any energy and convince your audience that what you're saying is worthwhile. A good way to feel confident is to tell yourself that you know more about your topic than most people in the room and that's why they're hear to listen to you - but don't get freaked out if you see someone in the room who you *know* knows more than you. They're still there because they're interested in what you have to say.
• Honesty. There's no better way to bring the audience onto your side than to be honest with them about some feature or behavior that doesn't work. Don't try to give the marketing spin on a feature or avoid the difficult question because the answer isn't what people want to hear. But on the other hand, don't be downright negative either. Present a balanced view and give an objective opinion. If you think what you're saying is going to disappoint people (like whenever I present about the new setup method for failover clustering in SQL 2008), add something funny like "I know, it's pretty sucky, but I'm just the messenger!"
• Arrogance. In no way do you want to have the audience think that you're better than them - it really turns people off to be talked down-to. In some of my earlier sessions I would sometimes come across as arrogant when I was trying to express incredulity and you have to try hard to say things the right way. For instance, in TechEd US 2007 I presented a talk on database corruption and was listing some of the worst things that people do to corrupt databases. When I mentioned restarting SQL Server, I said something like (paraphrasing) "wow, what do these people know that I don't? Restarting SQL Server isn't going to magically fix the corruption". Yuk. Although I was trying to express disbelief, that first sentence just screamed arrogance, and I got dinged for it in some people's session ratings and comments (and Kimberly shouted at me!). Now I'm very careful to always word things to avoid coming across the wrong way.
• Empathy. One of the best ways to ingratiate yourself with the audience is to empathize with them. Make the audience feel like you've been in the same situations they have, you've had to deal with the same problems they're seeing, you've felt the same frustrations with SQL Server that they do. Your talk should let them know you feel their pain and that you're going to help them with some of the info you'll present. If the audience feels like you're speaking from experience they're more likely to want to hear what you have to say. But be careful not to take this too far or it can feel contrived and dishonest.
• Total no-nos. There are some cardinal sins which almost guarantee you'll irritate and annoy people (at best) or get thrown out of a conference (at worst - I've seen this happen at TechEd). In today's age of (almost extreme) political correctness, you need to be careful that you don't overstep any lines of good behavior or start talking about inflammatory topics - but don't be scared to be a little controversial. I'll happily call bad design decisions in SQL Server "daft", and I did while still at Microsoft too, but I'd never use words like "stupid" or "idiot". Don't tell dirty jokes. Don't ever discuss politics - you're guaranteed to annoy at least one person in the room and you're not there to discuss that. Same goes for anything to do with nationalism, sexism, racism, parochialism, xenophobia, etc - these are all very, very thin ice and you'll get into trouble quickly. Never use a four-letter word while you're presenting - you may not find them offensive but many people do. In fact don't swear at all - if you can't express yourself while presenting without resorting to swearing for emphasis then you shouldn't be presenting. All these things can make people feel very uncomfortable when they hear them in a session. One cliche to consider is - would you be happy playing a recording of your session to your grandmother?

As you've no doubt gathered from much of the above, public speaking involves a lot of psychology and it can be really fun tweaking sessions repeatedly to see how the audience reaction changes. I really hope that all of this will prove helpful to some of you and I'd love to hear about experiences and things you've learned that I may have missed. This turned out *much* longer than I thought (a 5000-word essay), but luckily I'm badly jet-lagged from being in Asia for 3 weeks and I woke up at 3.30am.

To round out I want to leave you with a quote from one of my top-5 favorite, utterly stunning movies - Gladiator. In one scene, the old ex-gladiator Proximo (played by the late, master orator Oliver Reed) is telling the fallen Roman general Maximus (played by the excellent Russell Crowe) how to succeed: "Listen to me. Learn from me. I was not the best because I killed quickly. I was the best because the crowd loved me. Win the crowd and you will win your freedom." Now, I'm not trying to say with this that public speaking is like gladiatorial combat, but that success comes solely from pleasing the crowd. If your talk ends with the audience thinking they've just been entertained, learned something useful, and not wasted their time then you've succeeded and can feel profoundly satisfied as the applause rings around the room.

And with that it just remains for me to wish my wonderful wife Kimberly Happy Valentine's Day!

Thanks for your patience while our blog engine back-end was updated. You should find that the response time is much better now. You'll notice that all the blog post URLs have changed - we have a conversion layer in place so all prior blog posts will be seamlessly accessible through their new and old URLs. There are a few kinks being ironed out still - the Recent Posts pane on the left will be replaced with an On This Page pane, so that Category-based browsing (which I really need for classes!) works again.

If you see anything that looks broken, please let me know.

Thanks!

Thanks!

Ok - this post is a little strange and fun. I was thinking about word length and how it relates to designing software/schemas to support multiple-languages. How far do you have to go in your research to figure out the maximum string length to support? So I started digging about and found some interesting things about words. Here are some examples.

• If you're putting together a schema to support hospital patient records, you might have a field for disease name. In that case, you'd have to allow for pnuemonoultramicroscopicsilicovolcanoconiosis which has 45 letters (caused by breathing in siliceous volcanic dust). A field for surgical procedure would have to support hepaticocholangiocholecystenterostomies which has 37 letters (creating a connection between the gall bladder and the hepatic duct). What about a field for how a measurement was obtained - electroencephalographically with 27 letters (using an electroencephalograph).
• A schema to support chemical names could really be unlimited given the nature of systematic names for chemicals. The longest one in the dictionary is an acid called tetramethyldiaminobenzhydrylphosphinous with 39 letters (and given a few minutes I could probably draw its chemical structure by following the systematic method I learned at school :-)). The longest published chemical name is a kind of tobacco mosaic virus - ACETYLACETYL-SERYL-TYROSYL-SERYL-ISO-LEUCYL-THREONYL-SERYL-PROLYL-SERYL-GLUTAMINYL-PHENYL-ALANYL-VALYL-PHENYL-ALANYL-LEUCYL-SERYL-SERYL-VALYL-TRYPTOPHYL-ALANYL-ASPARTYL-PROLYL-ISOLEUCYL-GLUTAMYL-LEUCYL-LEUCYL-ASPARAGINYL-VALYL-CYSTEINYL-THREONYL-SERYL-SERYL-LEUCYL-GLYCYL-ASPARAGINYL-GLUTAMINYL-PHENYL-ALANYL-GLUTAMINYL-THREONYL-GLUTAMINYL-GLUTAMINYL-ALANYL-ARGINYL-THREONYL-THREONYL-GLUTAMINYL-VALYL-GLUTAMINYL-GLUTAMINYL-PHENYL-ALANYL-SERYL-GLUTAMINYL-VALYL-TRYPTOPHYL-LYSYL-PROLYL-PHENYL-ALANYL-PROLYL-GLUTAMINYL-SERYL-THREONYL-VALYL-ARGINYL-PHENYL-ALANYL-PROLYL-GLYCYL-ASPARTYL-VALYL-TYROSYL-LYSYL-VALYL-TYROSYL-ARGINYL-TYROSYL-ASPARAGINYL-ALANYL-VALYL-LEUCYL-ASPARTYL-PROLYL-LEUCYL-ISOLEUCYL-THREONYL-ALANYL-LEUCYL-LEUCYL-GLYCYL-THREONYL-PHENYL-ALANYL-ASPARTYL-THREONYL-ARGINYL-ASPARAGINYL-ARGINYL-ISOLEUCYL-ISOLEUCYL-GLUTAMYL-VALYL-GLUTAMYL-ASPARAGINYL-GLUTAMINYL-GLUTAMINYL-SERYL-PROLYL-THREONYL-THREONYL-ALANYL-GLUTAMYL-THREONYL-LEUCYL-ASPARTYL-ALANYL-THREONYL-ARGINYL-ARGINYL-VALYL-ASPARTYL-ASPARTYL-ALANYL-THREONYL-VALYL-ALANYL-ISOLEUCYL-ARGINYL-SERYL-ALANYL-ASPARAGINYL-ISOLEUCYL-ASPARAGINYL-LEUCYL-VALYL-ASPARAGINYL-GLUTAMYL-LEUCYL-VALYL-ARGINYL-GLYCYL-THREONYL-GLYCYL-LEUCYL-TYROSYL-ASPARAGINYL-GLUTAMINYL-ASPARAGINYL-THREONYL-PHENYL-ALANYL-GLUTAMYL-SERYL-METHIONYL-SERYL-GLYCYL-LEUCYL-VALYL-TRYPTOPHYL-THREONYL-SERYL-ALANYL-PROLYL-ALANYL-SERINE - with 1185 letters.
• Probably the one that's going to catch most people out is place names. The bank Kimberly and I use won't allow a town/city name of more than 30 characters. That's fine for the USA, where the longest place name has 24 letters (Winchester-on-the-Severn in Maryland or Washington-on-the-Brazos in Texas). However, if the back-end database is coded to only support 30 characters, that wouldn't work around the world:
  • In Wales, there are two longest names are Llanfairpwllgwyngyllgogerychwyrndrobwyllllantysiliogogogoch with 58 letters and Gorsafawddachaidraigodanheddogleddolonpenrhynareurdraethceredigion wth 66 letters.
  • In New Zealand, there's a hill called Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu - 85 letters and that name used to be in general use.

Pretty interesting - or as my kids like to say supercalafragalisticexpialidocious! (34 letters :-))

I'd be interested to hear of longest words in other languages apart from English - please leave a comment. Thanks

Well, now I'm no longer a 'Softie'. It feels a little strange after having been on the SQL team for 8.5 years but I'm really jazzed about all the stuff we'll be doing over the next year and more here at SQLskills. We're taking a small vacation before diving in - first thing I'll be doing when I return is revamping and updating all of my content from the SQL Server Storage Engine blog and reposting the updates here. After that I'll be posting a bunch on Katmai and working through my backlog of blog topics. I can't wait to get started - stay tuned...

Cheers