Many people, including myself, spend our own time answering questions on things like the #sqlhelp hash tag on Twitter and on various forums (TechNet/MSDN, SQL Server Central, etc.). This even happens during talks in Q&A sessions. Most people are nice and gracious, but every now and then, you have someone who just keeps chipping away at the stone to hopefully get the answer they really want to hear (even though it’s not possible). 10 observations:

1. One thing I see quite often is the lashback when a correct answer is provided but yet the arguments still continue. Here’s the deal: some technologies – clusters are a good example – work the way they work. I didn’t design the feature. For example, the requirement for shared storage for a clustered instance of SQL Server up through SQL Server 2008 R2 (this changes a little in 2012, but only in certain scenarios). You can’t get a Windows failover cluster or a SQL Server clustered instance to work any other way potentially without either unsupported (by MS) hacks or not clustering at all. Don’t hate us if you may have not thought out all aspects of your design, have run into an issue, and don’t like what we have to say. We’re really not trying to egg you on or irk you – we’re just giving facts.
2. Don’t expect us to design your massively complex solution for you for free based on 140 characters or a blog post in a free forum. That’s consulting and what most of us do for our day jobs. We’ve got bills to pay. We can point you in the right direction, but hopefully you’re going to base your design on more than a few line response. Those of us who answer questions love to give back, but realize that there’s always going to be some caveats to what you get for free in a smaller response.
3. We can’t make you experts in 140 characters or a series of replies. Hopefully you’re not expecting that.
4. Help us help you. This can’t be said enough. The more and accurate info we have, the better. I go through this with my clients all the time – it’s hard to make decisions about tomorrow when you don’t know what is going on today, what happened last week, or even last year. You need historical data to be able to make informed decisions.
5. You’re probably wasting your time if you ask something like “I need more disk performancebut I’ve got no budget. Will 5 SATA disks work?” You pretty much have already answered your own question. You can do things right, you can do things fast, or you can do things cheap. Those three things generally don’t all work together. Sometimes you can do them right and fast, but never cheap. Fast and cheap are often lumped together, but often leads to never being right. I think you get the point. There’s a tradeoff somewhere.
6. Capacity is not just size (memory, storage, etc.). There’s a whole performance aspect you need to consider. That’s why we ask questions like “How many I/Ops do you need?”
7. Your workload matters. Know what it is and be able to hopefully articulate that. What advice works for one implementation may be totally wrong for another.
8. RT(F)M. Before asking us a question, do some simple homework first. A simple BinGoogle search may yield your answer or point you to a BOL topic to allow you to ask a more directed question. That’s where we’ll provide you with (hopefully) some value.
9. Do NOT post any confidential info about your company, app, or data. This may include things like schema, object names, etc. Common sense, but is it really? Find a way to express your question while still keeping sensitive things under wraps. Easier said than done, of course. This is why I put NDAs in place with my customers when we work together. It allows me to do work and protects both them and me.
10. I subscribe to the motto that there are no stupid questions, and I truly believe that. Heck, we all started somewhere. It’s one reason I give back to the community. I didn’t get here on sheer will alone - I’ve had help along the way. But really look at #8 above – many questions can be answered that way. What is not easy, though, is trusting the information source it may come from. I’ve seen some sketchy advice put out there (no, I won’t say where), and it’s a free Internet. People can post what they want based on their experiences – just doesn’t make it technically sound advice. OK, I lied – one example which involves shrinking. We all know how shrinking is not a normal best practice. Don’t believe me? Just read some of Paul Randal’s thoughts. Point is, that first linked post gave OK technical instructions, but not necessarily the most sound advice. Learn to differentiate the two. In the case of that original link, I bet the DBA smartly sized the DB for longer term growth. We’ll never know.

Sorry if this sounds cranky, but I see this stuff over and over. We really do want to help you. Just don’t shoot the messenger if you don’t like the message.

Can you believe it’s February already? 2012 is flying by! I’m thankful that I’m crazy busy, and the partnership with Ben is going well (knock on wood). I’m really looking forward to the training class in March and psyched to have another Training Day at SQLBits X (have you registered yet? No? Go do it!). It’s been a fun travel year already. With one trip to Seattle and California under my belt already, I’ve got quite a few trips between now and April (including across the Atlantic to SQLBits in March) with a few more pending.At this rate, I’ll hit 50,000 miles in the air by mid-year. I know, first world problems – cry your crocodile tears for me.

Quite frankly, since late August when my friend Mike passed away (see Life Is Fragile and Fitting Tribute to a Hero for more info), things have been a blur. Last week (January 25 to be exact) would have been his 40th birthday. No wonder it’s been a somewhat “meh” couple of weeks for me. Considering I just had my 40th at the end of November, it’s all still very visceral for me. Little things remind me of him and probably always will. Rest in peace, my friend.

I also blogged a little about my substandard PASS scores. And no, they were not in the 2s, but certainly poor. To be perfectly honest, since I briefly looked at them back in December, I can’t bring myself to really look at them again. I remember some of the comments. Some were spot on. Looking back at the possible reasons for failure (at least in my eyes), like I said in that blog post – any problems fall squarely on my shoulders. I can’t blame anyone else, but I could certainly use some excuses such as:

• I used a build that was not very old and I had just gotten clearance a few days before to use – and right before the holidays so I didn’t have much time to work with it. I knew the risk, and I bit the dirt on that one.
• In retrospect, the death of my friend really impacted me more than I could have ever imagined. Even with killer material and solid demos, I probably still would have had a sub-par PASS by any stretch of the imagination. Again, not an excuse, but looking back I can see where that really weighed on me.
• I was a bit far ahead of the curve. Since it’s not a stretch to say that SQL Server 2012 will RTM soon now that we’re at the Release Candidate and full adoption for many customers is months, if not a year or more away, doing all SQL Server 2012 material that early was a big risk.

So I went big, took risks, and failed. That’s OK – it’s a good learning exercise and I’d probably do it again. Why? Well, I didn’t get where I am today without taking some big leaps of faith in myself (and sometimes those around me) along with some risks along the way. Sometimes you win, sometimes you lose. You can learn from both. If you never experience failure or disappointment (real disappointment, not the “Mommy didn’t buy me the stuffed animal at the toy store” kind), I’m not sure you can ever understand what success looks like. At least that’s how I feel on the matter.

Despite the fact I have done this for years, my PASS scores showed I may need to brush up on presenting, so I’m actually looking to improve my presentation skills. I’ve done a few things already (including getting a few books) that I hope will show some positive results.  Last week at the SQL Bare Metal training in Redmond, I got up and did an impromptu 20 minute presentation that felt really good. No deck, just demos; and no preparation. That was a tough audience – all MCMs, MVPs, and other really smart folks who know SQL well. Easy to bomb there. I didn’t. Maybe it is working. You can let me know when you see me present at SQL Saturday in Mountain View or at SQLBits, and even the training class in March.

To be honest, even if I never score in the top 5 or 10 at a conference, I get more satisfaction from people that come up to me – be it 1 day or 2 years later – saying they took something from a talk I did and it helped them. Those are measurable results numbers won’t ever show.

The journey matters, not just the destination. A score is just a number. Having a positive impact on someone is much better than a score in the long term.

It’s common to hear on the news “A source close to <insert government body or celebrity here> has informed us that …” – basically they’re leaking information they probably shouldn’t and may even legally be bound not to talk about. Sometimes there’s no fallout, other times it’s pretty bad. Well, the same thing happens in our world of computers. One example is a major event like CES (which happens to be this week, actually) – you see some leaks of products before any official announcements. We all love the super-secret spy shots of some as-yet-to-be-announced gadget. We then speculate what the buttons do. That’s no better or worse, but a lot of fun. Sites like Engadget are often about that type of speculation. Companies try to keep things under wraps as to keep some sort of competitive advantage – seems like that’s almost impossible.

Recently there was a discussion some of us were having around things like build numbers for SQL Server and release dates. Let’s face it, if you enter a bug in Connect for SQL Server, you see a bunch of releases both old and new in the dropdown to match up with the version that you had the problem with. Some of those builds or versions you may have never seen or heard of, so the fact there are interim builds you don’t have access to is one of the worst open secrets out there. For example, in the case of SQL Server 2012, a build number may be later than CTP3 but before RC0. That build is most likely associated with a one-off for a specific, small set of customers. An example of that is, say, an early adopter program (commonly known as TAP). These builds are not for general consumption and you hopefully won’t find people blogging or talking about them. Why? They’re under pretty strict NDA agreements not to talk about this stuff in any kind of public way, and there are consequences for spilling any beans.

TAP is not the same as MVP and covered by different NDAs as well as other rules. As someone who is in the MVP program and has been in various TAPs over the years, you have to be careful about who you speak to about what. Some folks are in that intersection where you are in both programs, some just in the TAP, and some MVP. Where’s a venn diagram when you need one? You can’t assume that what one knows the other does as well, or that you can share just because it’s Microsoft and maybe even the same product. There’s something to be said for personal accountability. You shouldn’t even need the threat of possible legal actions (covered by the NDA) to keep what you shouldn’t be talking about quiet. Common sense has to prevail.

While it’s true there are folks outside of the proverbial four Microsoft walls that may know what’s coming (be it 1 week or 1 year from now), no one who is privy to such information should be leaking it. Getting into the MVP or a TAP is a privilege, not a right. It can be ripped out from you. So if you know people who are participating, you shouldn’t be getting any information from them that they’re bound not to talk about. It’s not meant to slight anyone. I’m sure you can think of times in your own lives – be it personal or professional – you didn’t want certain people to know things. For example, if you’re looking for a job, do you really want your current employer to know? Probably not, although I do know some people who would be open about that. The majority of us keep that on the down low until your two week notice is given.

If for some reason you do somehow get access to such data or information or someone opens their big mouth, think before you go mentioning it to the world at large. There are ripple effects. In the immortal words of Sgt. Schultz from Hogan’s Heroes …

Happy 2012, everyone! I figured I might as well kick of the new year by beating a dead horse (not literally – don’t call PETA; I’m not an animal abuser). If you’ve ever heard me speak, read my books or whitepapers, seen a tweet, a blog post, or heck, know of me, you know there’s nothing more that gets my dander up than the use of active/passive (A/P) and active/active (A/A) as it relates to SQL Server failover clusters. This will not be my first time ranting, nor will it be my last. I ranted in this forum post over at SQL Server Central last May as part of a response to something I felt added to the confusion of why people still cling to this silly terminology today. Expect yet another diatribe in my upcoming SQL Server 2012 book, too (although if I like what I write here, I’ll just link this blog post). Anyway …

You may be asking yourself, “Why does he care?” The answer is not as simple as just using wrong terminology.

A Bit of History

Let’s take a way back machine for a moment. July of this year will mark 10 years since the publication of the SQL Server 2000 failover clustering whitepaper I wrote while at Microsoft. That paper has a lot to do with my career today, and I am forever indebted to MS for publishing it. That paper also features the first use of non-A/P and A/A terminology. The terminology is really simple and SQL Server specific. That was a main driver in doing it. You’ll see why as you read on.

SQL Server 2000 marked the biggest change in concepts with failover clustering with the introduction of instances. I think we take it for granted now, but 10+ years ago, it was a pretty big deal to have more than one SQL on a single box or a cluster. There were very practical issues which made having multiple instances of SQL Server 2000 difficult, namely how scalable both Windows and its underlying hardware were. Single core processors, poor hyperthreading support, not much memory (8GB was a luxury for most), needing AWE to go beyond 4GB of memory, 32-bit (discounting the very limited Itanium variant which was released near the end of its lifecycle), DAS, no mount points – shall I go on?

Now let’s back up to the previous release – SQL Server 7.0. SQL Server 7.0 allowed you to cluster up to 2 separate installations (not instances) on two nodes of a Windows failover cluster (I won’t touch that terminology in this post … people still uses MSCS which is wrong, too). Very few of you reading this post may have ever used SQL Server 7.0, let alone clustered it, but let me tell you it was a miserable experience and anyone complaining about things today (and even I do) should put things in perspective. Yes, failover clustering today still has a few things I’d love to see addressed (mainly in Setup), but I’ll take what we have now any day of the week that was the misery known as SQL Server 7.0. Why?

1. SQL Server 7.0 forced you to put the binaries for SQL Server on the shared disk – meaning you only had one copy and you could only run the management tools from the node which did the installation.
2. To apply a SQL Server service pack, you had to uncluster the SQL Server installation, run the update (such as SP2), and then re-cluster the install. Let’s just say that didn’t always work.
3. The clustering implementation was a bit of a hack prior to 2000. As part of the clustering process for SQL, MS replaced some DLLs to get SQL to work in a cluster. This is why specific versions of MDAC and such were required, and if you updated them on your own, you had the potential to break your cluster with 7.0. Fun stuff that I’m glad went away with the rearchitecture of failover clustering in SQL Server 2000. The MDAC issue had a lot to do with bad perceptions of SQL Server (in general – not just clustering) as well. Those issues were fixed a long time ago – notice you never hear about MDAC and issues related to it much, if at all, any more

So you can see why the ability to easily have more than one clustered installation of SQL Server on the same Windows failover cluster was so appealing when Microsoft fixed this in SQL Server 2000. SQL Server 7.0′s failover clustering implementation burned a lot of people, and unfortunately helped create part of the perception that failover clustering is bad. I know a lot of folks had a hand in that, including Richard Waymire (Blog | Twitter)  who was the PM for the feature at the time.

SQL Server 2000 didn’t do clustering any favors in helping out in the perception department, either if I want to be a bit honest all these years on. With the aforementioned limitations (especially memory), you were really limited as to how many instances you could configure on a single Windows failover cluster. People had some really bad experiences with failovers. That’s why to this day I believe you still see a lot of single instance deployments on two-node Windows failover clusters – somewhere along the line they had something bad happen when more than one instance tried to run on a single node. This leaves us in a fun conundrum with other wrong perceptions, such as so-called “wasted resources” but that’s a topic for another time, too. The failover condition wasn’t the only thing that contributed to the poor perception of clustering with 2000 (the other bigger issue tended to be around the occasional file not being laid down during an update or on a remote install – not all customers encountered it which was what made it frustrating), but the entire experience was greatly improved.

In a long-winded way, this is how both “single instance (SQL Server) failover cluster” or “multiple instance (SQL Server) failover cluster” came about. This is more important than ever since Windows Server 2008 and beyond also uses the terminology failover cluster, which used to be a SQL Server only one.

Looking back at SQL Server 7.0, A/P and A/A made sense – even I’ll admit that. You could only have up to two nodes with Windows NT 4.0 Server (the predominant OS used around that time; SQL 7.0 was not developed with Windows 2000 Server in mind), and up to two installations. One instance? A/P, two instances? A/A. In that context, I have no real issue. But once the concept of instances was introduced with SQL Server 2000, all of that should have gone out the window. Now, sure, technically you could have two nodes with two instances and have it “technically” meet the A/P and A/A criteria. I get it. But it’s wrong now, and has been for 10+ years. I can’t be any more clear on this.

Let’s look at scenarios to drive the point home further.

Two Instances, Two Nodes

OK, so this is the “classic”. In a perfect world, you’ve got two nodes, each with its own instance. Since both nodes are running an instance, they are both actively hosting a SQL Server instance. In that case, it’s easy to buy into A/A if you wanted to. What happens – assuming capacity is not an issue – if there is a failover? Technically you are no longer in an A/A configuration. One node is hosting both instances. The other is down or not running any SQL Server instances. Is that now AA/P? No. This where using the right terminology – a multiple instance SQL Server failover cluster – is much more descriptive and actually makes sense.

Three Instances, Two Nodes

This one is a riff on the previous scenario. This one is a simple math problem: is it AA/A? A/AA? AAA/P? It certainly isn’t A/A/A, nor A/A/A/P. Again, the multiple instance SQL Server failover cluster terminology works shockingly well here. (“I’ve got a three instance SQL Server failover cluster.”)

Three Instances, Three Nodes

This one is similar to the Two Instances, Two Nodes scenario. If you have one instance (perfect world: no failovers) per cluster node, to some that would be A/A/A. But how many slashes do you get before things get out of control? And then what happens if failover happens (see previous scenarios for how that will go).

Two Instances, Three Nodes

Here’s another one that I see wrong, so I can kill two birds with one stone here. When Windows gained the ability to have more than two nodes in a failover cluster, the idea of a dedicated failover node – especially when you had multiple instances – was introduced. Because the limitation was at most four nodes with the  of Windows 2000 Server Datacenter edition, this was often known as the N+1 scenario. When you really could have more than four nodes and more than one dedicated failover (not getting into specific configurations and things like preferred or possible owners in this post, either), this is N+i, where i would be the number of nodes that are failover ones.

From a SQL Server point of view, how would you denote the N+1 scenario? A/A/P? That’s just silly. Again, saying something like “I have a two instance SQL Server failover cluster with a dedicated failover node” makes a whole lot more sense.

Many Instances, More Than Two Nodes

Here’s where I throw up my hands and if I could curse, I probably would. If you plan on having, say, six instances on however many nodes (let’s pick four for the sake of argument), A/A/A/A/A/A (denoting the number of instances), nor is it really A/A/A/A (denoting the number of nodes). It sure as heck isn’t A/P or A/A. Capiche?

Doesn’t Microsoft Use Both the A/P and A/A Terms Still?

Unfortunately, they have and some still do to this day. I’ve seen it in more current documentation and blog posts from them. Sigh. It doesn’t mean they are right, though. We tried with the release of SQL Server 2000 and all of the corresponding documentation (including my SQL Server 2000 High Availability book) to make things consistent. The same could be said for 2005. But A/P and A/A seem to be sticking around like a cockroach will long after humans after a nuclear blast. Not everyone studies their history, so I guess we’re doomed to repeat it.

In Conclusion

Stop the insanity!

OK, maybe that’s a bit overblown but I wanted to work that reference/kitsch in somewhere. Who wasn’t entertained by that infomercial back in the day?

Like I said in the forum post I link above, I won’t publicly shame anyone for using A/P or A/A, and I may not even correct or embarass you (I may … my apologies if I do), but I hope I’ve explained to you why they’re wrong. Honestly, I don’t get why people are not embracing the right terminology as they accurately describe the configuration. I would even venture to guess that there would be less confusion around more complex clustered SQL Server configurations if people talked about them properly.

Last week, I wrote a blog post entitled “It’s Just Setup – Who Cares?”. What I didn’t do was go into the other side of that equation: uninstalling/removing an application. As bad as some software installers can be, trying to remove that software can sometimes be 100x more painful. I’m sure you’ve experienced this either on your own personal machines (regardless of OS) or your enterprise servers at some point in your lifetime.

To be honest, this annoys me much more than a bad installation process. In my mind, any piece of software that gets put onto your computer should be able to be removed completely with none of its traces or hooks still around. I think that’s not an unreasonable expectation … or is it? I mean, I’ve seen numerous times where the odd folder/directory, configuration file, or set of registry entries is still hanging around like that bad party guest who doesn’t want to leave at the end of the end of the night.

Oh, and don’t get me started on programs that will require a reboot to complete the software removal. I have never seen an uninstaller tell me that little fact when the process begins, and I love one of these two situations more:

1. At the end, a dialog pops up and says something like “Your computer must be rebooted to complete this process” with an OK button. You click, computer reboots.
2. No dialog, just reboot with no care as to what else may be going on. Working on a document you haven’t saved? Too bad, so sad.

Do you want either of these situations on your computer – especially a mission critical server? Heck no! If whatever you’re trying to eradicate from your computer or server does require a reboot, at least give me the option of when I choose to do the reboot. Again, I don’t think this is a completely unreasonable request of any software vendor. I am not thrilled I’m left in a pending state, but at least I control my own destiny.

Both of these blog posts underscore one thing that holds true: pick your software carefully and test things like install and uninstall before you go live. Knowing is better than flying blind, especially in a production environment that has very tight SLAs for uptime. That 128GB server isn’t coming back online in 30 seconds after a reboot.

It’s amazing how far we’ve come in the near 20 years I’ve been working with some form or another of SQL Server or another RDBMS. But I’ve seen one constant: bad configurations – especially Setup or the underlying OS – can lead to big problems. Think about it for a moment. Your journey on your platform of choice does not begin when it goes live in production. It begins from day one of the decision, and follows through to when the hardware comes in. You get the idea. Skip a step along the way, make a shortcut here or there, and you may wind up with some expensive downtime in the future.

Having said that, the focus in this blog post is really going to be on the software installation process. Sometimes the problems associated with such deployments are purely human error, poor planning, or both. Both of those scenarios are, for the most part, preventable. There’s no excuse to have a poorly planned implementation these days or a way to test things out since virtualization has become cheap and easy. My ire is going to focus on something that users and implementers alike can’t control: crappy installation/setup code. It’s not rocket science to have a decent Setup UI as well as scripted implementation for setup … or is it?

The installer is one of the most important pieces of the software experience. A good one leaves a positive impression, a bad one leaves a horrible taste in your mouth. Some can be overly complex, others too simple. There’s a happy medium.However, the end result should be a fully installed, stable application. Sometimes this is not the case. Being an availability guy, you can see where this causes some issues for me. The reason this happens is poor code, or worse, poorly tested code. There’s NO excuse for an installer not working right. But I believe that in most companies (not pointing any fingers), the focus is on features and functions – not such a seemingly simple, yet important, piece of the puzzle. I bet Setup is often an afterthought. I have no proof of that, but it’s a strong hunch. Much like what I do, Setup isn’t sexy. It doesn’t sell product. Features do. Planning and availability don’t have instant gratification like taking a query from 20 minutes to 2 seconds, but boy, not having that stuff or doing it right will bite you later when you are in a fix.

With customer environments being increasingly complex, I’ve seen some stupid things over the years. For example, assuming everything will go on a C drive or have “cluster support” that really isn’t any kind of support – installing on each node as if your product is standalone is NOT really what I’m looking for.  I shouldn’t have different installation experiences via command line, say, via Server Core or the “regular” version of Windows. Don’t run stupid checks and tests that don’t matter, yet consume large amounts of time. Yet I see these types of things all the time.

Patching processes are just as important. I should hopefully be able to patch your software with minimal to no downtime. Do NOT reboot my box without me allowing it or choosing when it happens since you may not be the only thing running. Patching is an extension of your Setup processes, and MORE important when it comes to availability since systems are already in production. Some of us are trying to maintain SLAs that will be blown by your automatic rebooting.

So to all you vendors providing software: wise up. Be more flexible. Understand that one size does not always fit all. TEST YOUR STUFF. Don’t increase my downtime – especially via unprompted (and unexpected reboots). And for heaven’s sake, be transparent. Don’t do things behind the scenes that will only be discovered later by reading logs or finding files in places that are not expected.

Hello everyone! I’m waiting for my flight home after my vacation in Japan. It was exactly the break I hoped it would be. I was also glad I got to catch up with a good friend who has been living in Japan for awhile. It’s the little moments in life that make it all worth living. I spent the entire time in Tokyo and got to cross a few things off the proverbial bucket list. It was funny getting off the plane here at O’Hare. The USA has a different vibe – that’s the only way I can describe it. The people talking loudly on cel phones, not caring who hears you … those kinds of things. When you go abroad you get a different perspective on things. I love living here, but I wish a bit more civility would sometimes creep in back on these shores.

Believe it or not, I really didn’t work on vacation. Well, that’s not 100% true – I did answer a handful of e-mails, but that was it. And I looked at my scores from my two PASS sessions. I will just say I was disappointed in myself and leave it at that. It was definitely an off year. The last time I had an off year I believe was when PASS was at the Gaylord in Fort Worth, TX. I could sit and make excuses – like literally having less than a week (more like a few days) to get the demos up since I was using a later build and that the Jewish holiday was right in the middle of that – but I’m not. Any problems fall squarely on my own two feet, and I already know what I’d change in retrospect. All this proves is that no matter how long you’ve been doing it, you can take a lump.The only real comment that surprised me was one basically wondering why I was showing how to set up Windows Server Core when someone else would do it. That’s why many DBAs have issues – they have SQL blinders on. But that’s besides the point.

The question then becomes: how do you deal with that? For me, I’m going to just get over it and move on. No need to dwell on it. Take your knocks, read the feedback, and improve. Next year will be better, and I’m actually excited about a lot of stuff coming up in 2012. More on that in a few days.

In the meantime, I’m going to readjust to the time zone here and get back to work. Hope to see everyone on the Quest webcast this upcoming Thursday.

[Before anyone e-mails or corrects me: there's a display issue with the blog. The apostrophe for I'm in the title for some reason isn't displaying.]

Can you believe it’s December already? Where has this year gone? I’ve certainly had the extremes – from the excitement and honor of pre-conference sessions at SQLBits 9 and PASS as well as taking on a business partner in Ben DeBow, to the lowest of lows with the death of my friend Mike Kenwood. Honestly, I don’t have much to kvetch about either in my personal or professional life. Heck, in 2011, I’ve also been able to cross a few major bucket list items off this year. I visited the Porsche Museum and got a factory tour (highly recommended), I auditioned for Roger Taylor of Queen, attended an Eagles game at Lincoln Financial Field, and after next week, I can finally say I saw a concert at Budokan in Tokyo. Not too shabby.

Anyway, while I took a vacation to California back in late August for a week or so, it really didn’t feel like I took one at all. Everything changed after I found out my friend Mike had passed away. It’s amazing how one event can totally change everything. I know I said my batteries were recharged after that CA vacation, but I’m going to take my own advice in that blog post and manage myself by taking a vacation to one of my favorite places on the planet, Tokyo. I know going there is on Mr. Ozar’s “to do” list for 2012. (Oh, and thanks for the shout out here, Brent – not so sure I’m cool, though.)

Don’t get me wrong – I know that going on vacation is a “first world” problem to have, but as thankful as I am that I’ve been nose-to-the-grindstone busy (a heartfelt thank you to all of my customers and anyone else I’ve worked with or trained), a major life event such as what I’ve been through via Mike has to affect you in some way. I also turned 40 this week (new decade – yikes!), and I’m definitely not getting any younger. With all the heaviness and heads down after August, it’s time to pop up and smell the roses and appreciate life and not worry about SQL Server for a brief moment. I also want to celebrate the spirit and zest Mike had for living. He always loved hearing about my adventures and I’ll miss sharing them with him, so in a way, this jaunt will also a bit of a tribute to him. I haven’t been back to Tokyo since this time in 2009 when I stopped there on my way to do some training in Singapore.

Don’t worry, I’ve got some exciting SQL Server stuff planned for 2012 – some of which will be announced soon, others which you already know about (like my new mission critical book). I’ve even got one more trick up my sleeve in a few weeks, so I’m not done with 2011 yet. I’ll post a link to that once I have it.

[EDIT: So it looks like Quest put a link up to my 12/15 webcast and didn't tell me it went live - that's the 2011 thing I'm referring to. I saw Jen McCown post it on Twitter right after I published this blog post, and it's now up on the Events so go and register!]

If you contact me while I’m away, I’ll get back to you mid-December when I return Stateside. Cheers!

Tom LaRock’s (blog | Twitter) topic for November’s Meme Monday is Write about what #sqlfamily means to you”.

It’s no secret that the SQL Server community is unique in many ways. We are a very visible and vocal bunch. We’re a lot of fun. We will rally around each other in good times and bad. Most of us will help one another be it 2PM or 2AM. Name me many other technical disciplines that have Twitter hash tags, numerous web sites and forums, a ton of bloggers, etc. that genuinely want to help and not want to charge you $200/hr for answering a simple question – you probably can’t. In fact, I see a lot of other folks who are, say, Oracle or Exchange admins wondering where they can get the same level of interaction we have as SQL Server folks.

Kalen Delaney wrote this in her 2011 PASS Summit wrapup:
A couple of them also mentioned how amazed they were that all the “big names” they met were so open and friendly, and it was easy to be included in whatever group activities were taking place. They said they felt no sense of any kind of cliques or exclusive groups among the speakers, non-speakers, and first timers. In other words, it felt like a real community! In reality, there are some cliques and some of the “big names” don’t even get along well with each other, but isn’t that true in any community?

I honestly couldn’t say it better myself. We may be a community, but don’t let that lull you into a false sense of security. Kalen’s last sentence is all too true: we’re not all bestest (sic) buddies – but that’s OK. We’re as functional/dysfunctional as any “normal” family can be, too. Some recent Twitter threads really prove this … but I digress.

Being part of a family is both good and bad. We all have different comfort levels and interactions. I’ll be honest: I’m still reluctantly on Twitter (despite how active I may seem), and I would never be on it if I didn’t feel I needed to be. The SQL Server community is very visible on it, so it makes sense to be on Twitter; it’s almost stupid not to be at this point if you’re involved with SQL. It’s worth it just for #sqlhelp alone. But I still don’t own a smartphone and don’t plan on it.

Despite the amount of public speaking I may do or how out there I may be by my various community activities and interactions, I am a very private person. I absolutely believe in a proverbial separation of church and state – that is, my private and professional life. That’s not to say I don’t consider many in the SQL community friends; I do. But I also think  there’s a fine line of people you work with knowing too much about you, too. Everyone has their own comfort level with things like that and may not agree with me, but that’s just the way it is.

Despite me being a bit more laid back and not as out there socially as others, I’m glad the SQL Server community has always welcomed me with open arms and is a large part of why I’m able to do what I do day-to-day. In many ways, I owe a lot of my success to the SQL Server community. I don’t feel like Steve Perry (formerly of the rock band Journey) who famously said in an episode of Behind the Music “I never felt like I was really part of the band” (see about 1:05). Far from it – I’m glad I’m in the band. And oh, I’ll be the bass player

People know when you’re genuine or full of horse manure. I try to do the best job possible, be it on a client site, blog post, training class, or speaking engagement. It’s always humbling to have someone come up to you at a conference or in a break at a session thanking you for a book, blog, or session from years ago that they were able to use and find helpful. THAT’S why I do what I do, and it’s what makes the SQL Server community great and unique. For the most part, we all try to give back in one way or another within our means. For example, I’m not funded for SQL Saturdays – that all comes out of my own pocket. I pick and choose based on my schedule and cost, but I participate because I want to. That’s what a community, or on this case, #SQLfamily does for each other. And I don’t think those of us that care would want it any other way.

It was hard to miss the licensing and edition announcements for SQL Server 2012 yesterday. This post won’t touch on those too much. Others (such as Denny Cherry’s blog post or Geoff Hiten’s blog post as examples) cover that pretty well. I will say these three things, though:

• Anyone who is surprised by the license by core and not socket should not be. It’s been a long time coming. Am I shilling for MS here? Not at all. I’m shocked MS hadn’t changed it years ago based on the way the industry itself has been going. I will still argue that if you do the math, in most (if not all) scenarios you’ll still be cheaper than competitor solutions. SQL Server does give you really good bang for the proverbial buck with a lot of features “in the box” no matter what edition you choose.
• In terms of cores, understand this and you’ll be in better shape to understand cost: there is a minimum of 4 cores to purchase for each individual processor.  What that means is that if you have dual core processors (i.e. a physical processor with 2 cores), you are still paying what you would pay today. 4 cores in SQL Server 2012 is the equivalent of a single processor in SQL Server 2008 R2 and earlier. After 4 cores, you buy licensing in 2-core “packs”, so if your intended server has processors with 6 cores, it winds up being 1.5x what you pay today.
• I know some folks liked all the different variations of SQL Server. I mean, who wasn’t looking forward to SQL Server 2012 Titanium Edition (available only for a limited time)? All kidding aside, Microsoft isn’t a camera manufacturer that can just change its shell to another color or textile and charge you more as much as some camera companies (*cough* Leica *cough*) do. I think simplifying down to three editions (Standard, Business Intelligence, and Enterprise) keeps things much, much cleaner and easy to understand. Enterprise vs. Datacenter did confuse some, so I’ll say this one is a big net positive.

The one thing which some may have noticed is the line on the bottom of the chart linked above for editions: Enterprise has “Advanced” for high availability and the other two have “Basic”. What exactly does that mean? Thanks to MS for helping me to clarify. The list below is as things are today. Things may or may not change between now and whenever SQL Server 2012 RTMs.

Basic

• Synchronous database mirroring (same as it is now in current Standard)
• 2-node failover cluster support for an instance (same as it is now in current Standard)
• Log shipping (same as it is now in current Standard)
• Replication (same as it is now in current Standard)
• Mobility limitations removed for Standard/BI, so Live Migration now really a good option for VMs if you have Software Assurance (so not new, but kinda new)
• Support for Server Core deployments (new to SQL Server 2012) – both clustered and standalone

Advanced (which includes everything you get in Standard/BI plus …)

• AlwaysOn availability groups and everything that comes with it like readable replicas, backups from replicas, PowerShell cmdlets, etc. (new feature in SQL Server 2012)
• Faster failover for clustered instances (new to SQL Server 2012 – talked about this in my PASS Summit preconference)
• Peer to Peer replication (same as it is now in Enterprise and Datacenter)
• > 2 node failover clustering (same as it is now in Enterprise and Datacenter)
• All modes of database mirroring with automatic page repair (same as it is now in Enterprise and Datacenter)
• The various online operations such as index rebuilds (same as it is now in Enterprise and Datacenter)

In essence, outside of the new AlwaysOn availability groups feature exclusively in Enterprise, the split is pretty much what you get now: a more feature rich high availability set in the top edition, and less in the others. Don’t let the names Advanced and Basic fool you – it’s just marketing terminology (much like AlwaysOn [with no space] is a branding thing).

The only slight bit of disappointment I have to be honest is twofold:

1. While I thought availability groups would be Enterprise only, I was hoping they would do something akin to what they did with database mirroring and put a more limited form in Standard and everything in EE. That didn’t happen. Let’s hope in a future version after 2012 it will.
2. Along the same lines, if availability groups were going to be EE only, I hoped that Standard would get the full database mirroring implementation. There’s precedent for that (see: log shipping [EE only in 2000, all in 2005] and backup compression [EE only for backups in 2008, all in 2008 R2]) as newer features get introduced or times go on. That also didn’t happen here. That’s more of a disappointment to me than AGs not being in Standard/BI.

These are not things to start a letter writing campaign to Microsoft. I’m just expressing my own personal opinion as someone who is obviously close to the HA feature set. I still think SQL Server 2012 has a compelling offering for most that if you are starting to consider upgrades or new implementations, seriously start evaluating it in its current form (CTP3).

Do I Need the Enterprise (or Datacenter) Edition of Windows for SQL Server 2012?
The answer to this one is “it depends”. If you plan on deploying AlwaysOn availability groups or failover clustering, yes. I know I haven’t talked about availability groups much but I’ve been working with them for awhile and some of what I know is still under NDA and I’d rather be able to tell everything. Anyway, availability groups require that the OS is clustered but SQL Server does not need to be (but you can cluster it if you want). Based on what I said above for Basic vs. Advanced, if you are not using SQL Server Enterprise, you won’t need to worry about choosing EE or DC for Windows anyway since you won’t be getting the availability groups feature.

The need for at least Windows EE has been a bit of a controversy for some as they want to, say, do clustering with SQL Server Standard but need a higher edition of Windows since Windows Standard does not support failover clustering – it’s not a 1:1 ratio (so-to-speak). Is there a cost difference? Absolutely. However if you look at the cost of the Standard vs. Enterprise editions of Windows, it’s not the same difference at all as it is with SQL Server in terms of price. I know that even a minor difference in the amount could be a huge one for some companies; I’m not blind to economics. But if you plan on implementing SQL Server 2012 EE, it would be almost silly not to deploy at least the equivalent edition of Windows since you wouldn’t be able to take advantage of a great new feature like availability groups.

Supported Platforms
Now is as good a time as any to remind you about the blog post I wrote back in June which talks about the intended platforms you can deploy on. My thoughts there haven’t changed either, especially around supporting (or not) 32-bit.

That’s it for now … hope everyone has a great weekend!