Dan Jones just blogged about the proposed upgrade paths and supported platforms for Denali. I’m glad they are publishing this information long before a new CTP is released. In that blog post, Dan encourages you to reach out to them via Connect (linked in his blog post) and I would say the same: if you have any issues or concerns, or agree with what I’m going to post here, let ‘em know! Speak now or forever hold your peace.

Here’s my take on what Microsoft is proposing. You may disagree and I would love to hear your comments.

Windows Server 2003 Is Dead
If you haven’t gotten the hint, Microsoft has released two OSes (Windows Server 2008 and Windows Server 2008 R2) since Windows Server 2003/R2. Yet, I still know many customers (talk to them often) that still only support Windows Server 2003. I’ll just say this: if you haven’t started looking at, evaluating, certifying, deploying, etc. Windows Server 2008 (and at this point, it should be Windows Server 2008 R2) in your IT organization, start now. That should be a huge priority.

Supporting Windows Server 2008 with Service Pack 2 Is A Mistake
I’m focusing mainly on the server side. I know Windows Server 2008 (no R2) is Vista server. I’m in full agreement that Vista the desktop OS should be supported. Supporting Windows Server 2008 with Service Pack 2 is a huge problem for me. Why? Let me state my case.

1. Windows Server 2008 mainstream support ends in 2013.
   Check the Microsoft lifecycle site for your country if you don’t believe me – it’s slated to end mainstream support in July, of 2013. We do not know any RTM dates, but it’s fair to assume most of you at the earliest won’t even think about Denali until sometime in 2012, if not later. Do you want to deploy on an OS that is already out of mainstream support and you can’t get hotfixes for? Yeah, I didn’t think so. This also plays into the whitepaper I wrote about supportability and staying ahead of the curve.
2. From an AlwaysOn standpoint, Windows Server 2008 R2 SP1 brings much more to the table.
   Windows failover clustering, which both the SQL Server failover clustering feature as well as the new availability groups feature rely upon, has been further enhanced in Windows Server 2008 R2. The biggest improvement is PowerShell integration.
3. Windows vNext is around the corner.
   Again, we don’t know release dates but Microsoft recently unveiled the first looks at Windows 8 the client OS, which means its server counterpart is also in the works. If Denali ships with Windows Server 2008 SP2 support, that means their support needs to worry about Denali on three different OS platforms with their own quirks. That’s not a scenario I would want if I was Microsoft.
4. [EDIT - Added] Server Core and failover clustering.
   I’m not giving away any trade secrets, but you may have heard that Denali will be supported on the Server Core variation of Windows (i.e. no GUI). Server Core is part of both Windows Server 2008 and Windows Server 2008 R2. However, if you want to do something like failover clustering, cluster validation (the Windows process) only has a PowerShell cmdlet (not a cluster.exe implementation), and that would require Windows Server 2008 R2.
5. 32-bit is dead. Long live 64-bit.
   Windows Server 2008 (no R2) does have a 32-bit flavor. That means Denali would have to ship a 32-bit server (which may be the main reason behind the decision to support that OS). However, let’s face it: 32-bit is a dying breed in most environments. Truth be told, I haven’t implemented anything but an x64-based SQL Server (even under virtual machines) in my test environments as well as at all of my customers for at least 3 or 4 years going back to Windows Server 2003. I would argue most of you who need 32-bit need legacy support in some way, and that is done via some old platform. Your new apps are probably moving on, even if you are using Windows Server 2003 64-bit and not Windows Server 2008/R2.Windows has killed 32-bit. I believe Exchange has. Why not SQL? I don’t understand the wishy-washy reluctance to not embrace 64-bit fully and kick 32-bit to the curb. It’s time to move on. 32-bit has been a great platform, but let’s retire it with dignity.This does not mean that Microsoft shouldn’t support 32-bit on the desktop … I’m purely talking about deploying it in a production capacity.There’s another big reason I would recommend this: make the testing matrix smaller. Removing 32-bit as a server platform allows MS to have better testing coverage for everything else. The more platforms, the more testing, the bigger the matricies. Having done QA in the past, I know this is huge.

What About SQL Server 2000 Upgrades?
It’s clear by the list you won’t be able to go directly from SQL Server 2000 to Denali. Hopefully by now most of you know that SQL Server 2000 is not supported on any version or variation of Windows Server 2008. While Windows Server 2003 supports SQL Server 2000, 2005, and 2008, it’s gone. Kaput. Forget about it. In that context, it makes sense that upgrading in-place would not be possible to Denali. This is much like the SQL Server 7.0 upgrade scenario where in some cases with later versions of SQL Server you need to do a “double hop” (i.e. get it to 2000, and then upgrade to a later version). In this case, you’d have to do an intermediate step to 2005 or 2008. If you’re going to have to go from 2000 to Denali, start thinking about that and come up with a short term plan so you can minimize your downtime in the Denali upgrade.

I know that the decision here will not make some of you happy, but it does make sense at this point to cut the 2000 lifeline directly. I know customers out there are still using it. You have options, but you need to just figure out what you want and need to do.

What Version of SQL Server 2005, 2008, or 2008 R2 Are You On?
So the published list of minimum upgradeable SQL Server versions (meaning you can be at that version or greater) is 2005 SP4, 2008 SP2, or 2008 R2 SP1. If you’re not at any of those, as with what I said about 2000, start planning to get there now. It’ll save you a lot of grief and aggrivation in the long term.

Meme Monday, started by Thomas LaRock (Twitter | Blog), is an interesting and fun thing. This month, the topic is dumb SQL Server questions. There are a ton, but this week I’m going to focus on three I hear all the time.

Question 1: My Windows/backup guys make a full backup of the system with SQL Server. Isn’t that the same as making a SQL Server backup of the databases?
In most cases, the answer is no. SQL Server is NOT a flat file-based database. While a Windows-level backup of a SQL Server database can be done properly if it interfaces with VDI/VSS, chances are most backup programs won’t handle that or may skip the SQL files since they are in use. Plus, at that point, you would most likely have to attach files – it’s probably not a backup you could use in the traditional RESTORE sense or use transaction log backups with. Some software may do proper SQL Server backups, but you have to ask. Some hardware-based solutions do properly interface with SQL Server, so while out of control of the DBA, can make valid backups that are logged in SQL Server. You would need to check with your vendor.

At the end of the day, as a DBA, you’re responsible for your SLAs, RTOs, and RPOs. A big part of that is ensuring the right backup strategy. Leaving it to your Windows or backup guys could be a potenital excellent career limiting move.

Question 2: Isn’t SQL Server failvoer clustering the same as Oracle RAC?
No, no, a thousand times no. While maybe not a dumb question, it’s the one I hear the most in clustering discussions/talks and it’s clear people don’t do their homework and are making some pretty big assumptions. SQL Server’s failover clustering is built on top of Windows failover clustering. A single server (node) can own a given clustered instance’s resources at a single time. Shared disk is the single point of failure. Scale up is how you would get scalability.

RAC allows you to scale processing, but you still have one copy of the data on disk – single point of failure, and if you have an underpowered storage solution, I don’t care how many processing servers you have – you’re not going to scale if your I/O sucks. Plus, while I know it works, the lock manager Oracle has coded is a complex piece of technology.

Both solutions are not going to necessarily be straightforward to implement. Microsoft has made clustering a lot easier over the years.

At the end of the day – both are valid approaches and are proven technologies.

Question 3: Can’t SQL Server have zero downtime and no data loss?
To achieve zero downtime, if you never patch SQL Server or any other components (including Windows) and never have anything unexpected happen, sure – you can have no interruption in service. Outside of that, no way. Someone recently tweeted they need a maximum of 8 seconds of downtime. That is darn near, if not, impossible. You have to be realistic about your tolerances and what is actually achievable. With the best processes and technologies, you’re looking at anywhere from 30 seconds to a few minutes in a best case scenario.

As for data loss, it’s going to be an “it depends”. If you’re using some kind of synchronous method (i.e. high safety database mirroring), you won’t have data loss for that database since it must be on the mirror as well. But there are complexities – how in your application can you tell where you are at data wise? What happens if your application uses multiple databases – how will you keep them in sync and then tell where they are at data wise?

Failover clustering will always be consistent to the point of failover because the stop and the start means that anything that is incomplete won’t be written will be rolled back due to the recovery process, but you need to account for figuring this out in your application.

Jen McCown (Twitter | Blog) is our host for Un-SQL Friday #4: Speaker Lessons Learned. This particular topic is one I could go in a lot of directions with – what are my tips for success? My biggest blunders? Best experience? First, let me direct you to two different posts I’ve done chronicling my experiences based on my scores at PASS Summit 2010 and at SQLbits 8. Since I’ve done those posts already, let me address a different aspect of speaking: etiquette.

I’m not talking Miss Manners’ version of etiquette. Speaking in front of an audience at a conference or user group has its own dynamic, and I find each time is different. I think there are some basic rules that speakers should adhere to or at least take into consideration to create a more pleasant experience for you, the audience, and that you, the audience, should follow for us.

Speaker

1. Watch what you say.
   At a technical conference, your first goal is to be on point and accurate – that’s a given. It’s when you veer off into trying to be entertaining that you can step into trouble. Your jokes may go over huge or they could fall flat and die on the spot. Some people can get away with, shall we say, more “blue”, risque, or “borderline” humor. Me? I’m no wallflower, but the last thing I would want to do is potentially offend someone.Call me conservative, but I realize that audiences are made up of all types of people each with a different background. Anyone who knows me knows I have a good sense of humor and it would take a lot to offend me. I would definitely say I do not have deliciate sensibilities. I can also swear like a sailor, but in my mind, onstage is NOT the place for that 9 out of 10 times. Sean McCown did a session at SQL Saturday #63 on how to curse in an interview, but in general, avoid.
2. Death by PowerPoint = Fail
   If you’ve got N minutes, don’t have N or N+i slides (or even N-1; you might as well have N or N+i at that point!). You’re most likely not going to do a slide a minute PLUS Q&A. Good luck with that. These days, I try to do a healthy mix of content and demo to reinforce the content. Sometimes demos are not possible given certain subject matter. As a speaker put yourself in the audience’s shoes. Would YOU attend your session the way you put it together? Be honest with yourself.
3. Do not read your slides verbatim.
   I used to do this 10 years ago. A trained monkey if it could speak could do that, and it’s an insult to the audience on so many levels. If they can read it, why would they bother sitting through the rest of it? I use my slides and  the text as talking points more often than not. Part of keeping an audience engaged is giving them something to listen to.
4. A little pacing goes a long way.
   One of the ways to be successful – much like a good meal with multiple courses, song, TV show, play, musical, or movie – is to have ebb and tide in your talk. If you’re at a rock show, sometimes you want your face ripped off, but after a bit of that, you may want to slow the pace down to give the audience a bit of a breather. Part of this skill is knowing how to read your audience and react. Be a jazz musician – improvise and go with the flow sometimes. If you know your subject matter, you should be able to riff on something if the audience is digging what you’re covering at that moment. So what if you planned to talk about it for 2 minutes only?
5. To allow or not allow questions mid-session: that is the question.
   As can be seen in my SQLbits 8 post, I got a comment around that. Having done both smaller, more informal sessions as well as rooms packed with 200 people (or more) at PASS (and let me say this – I am VERY thankful that you guys out there think highly enough of me to show up in those numbers). Here’s one where the etiquette is a big, fat, murky swamp. You could argue that both ways are appropriate and correct. However, don’t sacrifice your talk and go off on a tangent 10 minutes in based on questions. If you can field a few short questions, great. If not, save it until the end. Your call, but you run the risk of losing your audience by allowing a free-for-all.Questions mid-session are easier to handle (at least in my experience) with a small amount of people. In a room full at PASS with like 200 people, not so much. It tends to snowball.
6. Keep your ego in check.
   Speaking is a lot of fun and nerve wracking atthe same time. I’d be lying if I said it wasn’t a bit of self promotion on some level. But realize that as a speaker, it’s not about stroking your ego or coming off like a pompous, know-it-all ass (and I’m sure I have at times been guilty of that; I apologize if I did). The audience wants to get something out of the session, not see you do N minutes of mental masturbation on your part.
7. Make the best of the environment you’re given.
   When you get in the room, assess the situation and adjust accordingly. I can’t control the environment, but I sure as heck will get dinged for it. Room too cold? My fault. Screens illegible? My fault. Room not set up properly or crappy logistics? My fault. It’s part of what you will have to deal with and accept as a speaker. This is why on some of your numbers for sessions while it counts towards an overall average of your session, you may have to throw it out and do your own. As an audience member, be understanding that we don’t have anything to do with your experience other than the content.
8. Repeat the audience’s questions.
   I know I’m guilty of not doing this every single time, but especially if there’s no microphone and someone blurts out a question, it’s really helpful to everyone else not in earshot to repeat the question before giving an answer. This is especially important if the session is being recorded. The folks at home won’t have any context.
9. Remember to turn off e-mail notifications, IMs, etc.
   I know some folks who live Twitter during a session and it’s entertaining (hard to pull off, too, if you’re not someone like Buck Woody). That’s a special skill. but do you want a confidential title or bit of e-mail popping up or your significant other/”friend” sending something inappropriate in the middle of a session? NO. It seems obvious, but you do need to remember to close all that stuff down.
10. Acknowledge the audience.
    This one is obvious, and very difficult to do. Connect with your audience – make eye contact. Look at them. Don’t look at the floor. Don’t stare at the ceiling. Don’t stare at some random point on a wall. You may have the best content ever, but remember you’re putting on a show, too. They need to be engaged. If you do a poll, repeat the results. Draw them in and don’t let them go.
11. You have one chance to make the impression you want to visually.
    Showing up in shorts, sandals, and a Hawaiian shirt may not be the most appropriate thing for your talk. Maybe it is. I couldn’t say, but don’t embarass yourself. People will judge you before you even open your mouth. I had someone in my SQLbits comments make one around me not wearing any socks (I rarely do) and they only realized it quite frankly because I was sitting down (see that post – I really wasn’t well that week). I’m OK with that, but at the same time, I could see why they were not thrilled with that. It’s the first time in 10+ years of doing this anyone had a negative comment around something like that. The look, such as a Hawaiian shirt, may have something to do with a theme in your talk but make sure you incorporate it well. There’s a fine line between tasteful and tasteless.

Audience

1. Read the session title and description carefully before you choose to attend.
   I’ve written wrong ones and taken the appropriate knock, but I can remember one time at TechEd (2003 maybe) where I wrote the title and description to match for a talk on SQL Server and SAN. Unfortunately, it got lost in translation somwhere. By the time it was published, it lost, someone in charge of the database track took SQL Server out of the title and I got people looking for generic SAN advice. You would think that the three letter designation for the session (DAT) would have given people a clue, but no. Boy did I take a hit on the comments and score for that session.
2. If you are going to attend a session, and you find it’s not your cup of tea after the first few minutes:
   a) Leave as quietly as possible.
   If you’re not going to sit through the whole thing, leave with dignity. Luckily I’ve never had major disruptions, but loud slamming of doors, etc. is distracting to those who really want to be there. And by the way, a speaker will notice you walking out. For me, one of the things I try to gauge in seeing if I’ve lost you as an audience or not is if most of the people who started the session are there for most or all of the time.
   b) Don’t ding the speaker if you are only driving by and crusing past the taco stand. 
   A speaker can’t prevent you from giving all low scores because you did show up even if it was for 5 minutes. However, if you  were just auditing for a few minutes to see if you would be interested in sitting through the whole thing, why would you even bother giving a low score to a speaker? If you went because you were looking forward to it and were genuinely interested but the speaker missed the mark or was horrid, it’s fair to give low scores.
   c) Cliche, but set your phones to silent/vibrate.
   Nothing can kill flow or distract if all of a sudden someone’s phone goes off. Also, if you have to take a call in the middle of a session, don’t speak loudly if you are walking out to take it. Be respectful of everyone including the speaker. I’m sure it is an important work or personal call, but just as a speaker needs to be considerate of his or her audience, be considerate of your fellow attendees and the speaker.
3. Don’t expect 60/75/90 minute cures.
   I realize when you come to a user group, SQLbits, PASS Summit, TechEd, etc., it may be your one opportunity for training so you want to get as much knowledge in your head as possible. I think we all get that. However, some topics are too broad to cover in a short amount of time so we distill it down and hopefully give you the best context to go use the information. There’s a difference between, say, the pre-con (such as the one I’ll be doing this year at PASS Summit) where I have 7 hours to stretch and a 75 or 90 minute session during the conference where it will either be a focused topic or have a clear agenda of things to cover since the topic could go very long and very wide. Clearly when I have 7 hours I can do a much better job of going deep, whereas in a shorter session, I need to really pop out the few things I think you need to take away and clearly let you know what I’m not covering so you can go do that research on your own. Let’s face it – during a day or two of pre-cons and three days of sessions at something like PASS Summit, at some point your brain is going to scream “Uncle!” and shut down anyway. That’s why as a speaker, it’s my job to give you a few key takeaways even if you forget the rest. Sure, you can buy the DVD and rewatch later, but I still want you to remember something.
4. Don’t be THAT guy or gal.
   You know who I mean. Some people show up to a session ready for a fight or to be contrarian. I’m not talking about showing up to a friend’s session and some good natured heckling (although be careful not to impact their session). Here’s what I mean: maybe they read a blog post or book and disagree with you. Maybe they hate the feature you’re talking about and can’t wait to vent about it. Maybe they think they’re better than the speaker. Wonderful. Just don’t do something to derail the talk at the expense of everyone else. Take the speaker aside after and have a civil conversation with them. Grab them at another point in the conference. You only make yourself look stupid by being argumentative. Also know who is speaking. For example, if it’s a non-Microsoft speaker, it’s pointless to complain about a feature. The person on the podium most likely didn’t code it. Direct your anger to the right audience.
5. Give better, more constructive feedback.
   I know you’re not getting paid to do so (although there are incentives like giveaways), but sometimes giving just a number isn’t helpful. If it’s all high numbers, that’s fine no speaker needs the extra praise (but heck, a “You changed my life” is always nice to hear). But if you decide to give a lower number, have the cojones to tell the speaker why. Constructive and honest criticism only makes us better. It’s incredibly frustrating to get all 4s and 5s, but you get a handful of 3s, 2s, and 1s with no explanation.
6. If you know some (or all) of what’s in the session, be respectful in your comments.
   You attend a 300 level session by someone. You get a few tips, but you wind up knowing a lot of what else was presented. Guess what? You’re ahead of the curve. It doesn’t mean it’s not 300 level content. As a speaker, there will be people who are in that session who see that 300 level content as 400 or 500 because they are at a 100 level. A majority will find it 300 and find it at the appropriate level. Others who are familiar think it’s 200 and too basic. It’s an impossible position to be in sometimes. I’ve had quite a few rude comments over the years along the lines of, “I knew that info already and you suck.” Great! But most of the audience probably didn’t. If you feel it wasn’t <insert level here content> tell me what you would have loved to have seen and why you were disappointed in a constructive manner.

You are under attack. No, I don’t mean some foreign country is going to invade your city. Your job as a DBA or IT admin is. Why do I say that? Well, you’ve got lots of threats depending on your environment: the cloud, virtualization, skill sets, budget, new technology, etc. There’s a lot you have to do on a daily basis to make sure you still have a job tomorrow and the next day. Fall too far behind and you become irrelevant. New releases keep coming, so you have to keep up even if your company is not using them or will get them in production any time soon to stay relevant. Ignore trends like virtualization and the cloud (and where you will fit into those pictures), and you will be left behind.

This blog post was inspired by a con call I had today. Some people on that call – all very smart and very good DBAs - did what a lot of DBAs I know do, and basically said, “I don’t want to be a Windows failover clustering expert.” Fair enough, but do you have any prayer of being successful with things like failover clustering (or the upcoming AlwaysOn availability groups feature in Denali) if you don’t undertstand the underlying platform which it is built upon? In some ways, you should be smarter than your Windows, networking, security, and storage guys as it relates to your implementations around this stuff because they probably don’t know SQL Server and what you don’t know about their shortcomings will hurt you long term. You must articulate what you need to be successful. I’m not just singling out failover clustering. This would hold true even if you are not using clusters or even a DBA and are just a plain ol’ IT admin. The only way to understand what you’re doing is to know how things work underneath the covers to a point you’re at least comfortable with it. By no means am I telling you to become a Cluster MVP.

If you’ve seen any of my talks, you know I’m a big supporter of PowerShell. Heck, way back in 2009, I wrote a blog post entitled “The Incredible Shrinking DBA Skillset Rant #1 – Scripting” and said this:
“I can’t say it enough at this point: learn PowerShell. And if you didn’t understand me, this should clear it up for you: L E A R N P O W E R S H E L L. You’d be foolish not to. Microsoft has often (and sometimes rightly so) been criticized for not standardizing toolsets between products. PowerShell is becoming that unifier, and you WILL be left behind as an administrator if you don’t learn it.”

On that call today, not only did the DBAs basically say “we don’t do that” with regards to PowerShell in general and for administering Windows failover clusters (do you ever patch your instances of SQL Server 2008/R2?), but one of them said even their Windows guys do not either. I was on a con call recently with another customer who said that where they use Windows Server Core (not for SQL Server – just qualifying), they have some issues with administering it because their guys are not command line or PowerShell knowledgable. So they generally don’t use Server Core because of the skills of their admins and their reliance on a GUI – it wasn’t a Windows issue. That floors me.

Look, I know we’ve all gotten used to some of the GUIs Microsoft and other vendors provide, but you may not get all options in a GUI. Some advanced things may only exist in PowerShell or some command prompt version of the GUI. Do not be scared of the keyboard. Maybe it’s because when I came up in the industry, I had to know command line for OSes like Solaris, HP-UX, Novell, and VAX/VMS (and no, I’m not 60!), but I can’t fathom NOT doing some command line stuff. Command line is sometimes faster, and to be dead honest with you, scripting is the only way to truly manage large environments for tasks to be repeatable. Running Maintenance Plan Wizards for 1000s of databases doesn’t really scale despite what you may believe.

I know not everyone out there is resisting scripting or burying their heads in the sand saying things like, “Dealing with the Windows cluster stuff isn’t my concern.” Kudos if you’re not that person. If you are – even a little – go ahead, continue to think that. You might as well shoot yourselves in the foot, too. If you are a masochist, you’ll be in your element. If you want to have an easier time, wake the heck up and grab a (proverbial) strong cup of coffee. Don’t hit snooze on the alarm.

Consider this your second tough love wakeup call. 2009 wasn’t enough with regards to scripting, but this “It’s not my problem” attitude has to go away. If you don’t understand the basics, how can you do anything advanced? I don’t think asking folks to know a bit of hardware and OS stuff is unreasonable for a DBA.