By: Allan Hirt on August 23, 2012 in Administration, Advice, AlwaysOn, Database Mirroring, Failover Clustering, Log Shipping, PowerShell, SQL Server, SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012
Twitter conversations can sometimes lead to interesting things. Jonathan Kehayias (Blog | Twitter) and I were going back and forth about something, and in some cases, how we differ on how we teach (some of that was based on teaching or not teaching a deprecated feature). It was a very healthy discussion if you ask me. I really respect Jon and he’s one of the smartest folks on the planet when it comes to SQL Server in nearly every respect. I don’t say that lightly. Paul, Kim, and the rest of the crew over at SQLskills are very lucky to have him on their team.
Be it Windows, SQL, SharePoint, whatever – all of these products at some point release a new version and as part of the lifecycle of that product, some features are deprecated. A good example is that database mirroring has been deprecated as of SQL Server 2012. It’s still in the product, but its development is over and it will disappear from the product in a few versions. Another easy example for me to mention (and what sparked the debate between Jon and I) was the use of the aforementioned cluster.exe in Windows, which was deprecated in Windows Server 2008 R2 and is technically gone in Windows Server 2012 (disclaimer: you can add it back by enabling a certain feature, but it hasn’t seen any improvement or development since Windows Server 2008; more on cluster.exe in a bit). In the immortal words of Hall and Oates, “She’s Gone” (following the Daryl Hall theme from my last post; I was challenged to use “Rich Girl”, but this was more of a natural fit – sorry Rick!).
That begs the question: when do you stop actively using/teaching/recommending/etc. a certain feature you either know has been deprecated or will be going away (but may not be public knowledge although you have good NDA information which you really can’t share)? The answer, not surprisingly, is “it depends”.
Let’s take the case of my good friend cluster.exe who I’ve lived with for the better part of 10+ years. At this point, I’m not seeing any new deployments of SQL Server 2008 (RTM branch or R2) on the original Windows Server 2008 (no R2); it’s all basically Windows Server 2008 R2 with SP1. W2K8 R2 introduced the first round of PowerShell cmdlets for Windows Server failover clustering (WSFC). When I wrote my SQL Server 2008 book, W2K8 R2 was just being wrapped up so I documented both. As time has marched on since 2008/9, not only have I personally used cluster.exe less, when I teach my classes or do presentations, I don’t even bother showing it anymore. Why? In 2012, to me it makes no sense to show something that is deprecated and outdated, and is gone in Windows Server 2012. If you’re using Windows Server 2008 R2, you really should be using PowerShell to administer your clusters (one man’s opinion, of course; feel free to disagree). However, there are still exceptions to that rule. For one specific thing in Windows Server 2008 R2, there is no PowerShell equivalent (it’s basically related to availability groups in SQL Server 2012). This is fixed in Windows Server 2012. Similarly, some things that have a PowerShell cmdlet (Test-Cluster), have no cluster.exe equivalent. The pros outweigh the cons for me of not showing or teaching cluster.exe these days. Would I if someone asked? Sure. I’m not so stuck on not showing it; I just think it’s better to learn the stuff you can use now AND in the future when you want to go to Windows Server 2012.
The story is not so cut and dry with a feature like database mirroring. Unlike Windows which really makes it clear cut you need to move on – and quickly, SQL Server keeps a feature around and intact for at least two versions before it goes away (another really good example was DB-Lib). That could possibly translate into almost 6 – 10 years of shelf life, giving you a false sense of security. Sometimes there’s a clear cut feature that replaces it. In the case of database mirroring, a lot of people use it now. That’s one factor, so it makes the announcement that much harder. But the real crux of the problem as I see it is a case of the haves and have-nots. If you are using Standard Edition of SQL Server, Microsoft is recommending log shipping as your replacement. For Enterprise (now Datacenter) Edition, it’s availability groups. AGs are a great evolution of what was started with DBM, but with the new dependence on WSFC for deploying AGs, it may be a non-starter for some. But people who want to upgrade to SQL Server 2012 or whatever vNext (or vNextNext) may be, they need to start planning a roadmap otherwise it makes it that eventual upgrade harder because your back will be up against the proverbial wall. There’s no easy answer here, but it’s a conversation I’m having with a lot of my customers.
When it comes to having NDA information on something to be announced in the future, I can never spill the beans. Sorry. If I do, that puts me at risk with whoever I have the NDA in place with (and that comes with all kinds of legal problems for me if I do). I love my customers, but it’s not worth putting me out of business by letting something slip. That said, I can still steer customers in the right direction without them even getting a hint that there may be an underlying and different reason I am doing so.
I’ll leave you with this one final thought: as much as deprecated features are important to consider in your planning efforts, don’t let it become an obsession, either. DBM is a great example – it’s not going away tomorrow. If you’re using it now, that’s OK. A deprecation announcement didn’t mean to stop using it this very minute; just don’t get complacent about making a decision, either. A few years goes by in the blink of an eye when it comes to IT (just look at the people still running SQL Server 2000 for whatever valid reason and are stuck supporting it). Don’t be that guy or gal keeping the lights on for the few instances requiring DBM for the next 15 years. Be smart, make the right choices, and stay on a supportability path.