SQL Saturday #118 — Madison WI

I’m here in balmy Madison, Wisconsin presenting today at SQL Saturday #118 presenting on High Availability and DR options in SQL Server 2012. Jes Borland (b|t) and the outstanding crew have done a fantastic job with this event.

Anyway, I wanted to slides and some resources.

Slides are here.

Books online for AlwaysOn Availability Groups are here:

MSDN.

The version of this presentation I gave at the 24 Hours of PASS is here (requires PASS login):

Videos

Windows Server 2012 Impressions, Part 2

I’ve been doing some testing with Windows 8, and after fighting with VMWare for a while yesterday, I was able to get a SQL 2012 Failover Cluster Instance up and running on two nodes. All in all, the process wasn’t that different from building a cluster in Windows 2008R2, but there are a couple of things to note.

One of which is that the new Windows file system ReFS, which Denny Cherry blogged about here, is not supported for SQL cluster disks—I had my data disk formatted using ReFS, and the SQL installer showed the dreaded red X for shared disks. When I reformatted the same disk under NTFS, everything worked fine. I’m not sure what will happen if you try to do a standalone SQL install to an ReFS disk, I’ll try that later.

The major issue I ran into was getting .net 3.5 installed, so the SQL installation could complete successfully. This has been well documented by Aaron Betrand (b|t) here and by Allan Hirt (b|t) here.

When trying to add the feature from Server Manager, the following error occurs:

“.NET Framework 3.5” feature the installation fails with the error message “The source files could not be downloaded.”

The workaround for this is to run the following command (assuming your Windows 8 media is mounted under D:\)

dism.exe /online /enable-feature /all /featurename:NetFX3 /Source:d:\sources\sxs /LimitAccess

Aside from those two minor issues, the install went pretty well, and everything worked as expected.

Windows 8 Early Impressions

Late last week, I fired up a Windows Server 8 VM—I wanted to play with it a home a bit, before setting up a large scale environment here at work. The first thing I noticed was how much the GUI has changed—there isn’t a start button, and most tasks are driven by the Server Manager utility and/or PowerShell. Since, I’m a big fan of the command line and Windows Core, I think this a good thing. Start learning PowerShell now—you will need it in the near future.

Upon further digging, I found a feature called cluster-aware updating. Further research there, took me to this Microsoft White Paper. This is a cool new feature that will allow for clusters to be updated automatically, reducing downtime and hopefully be a much more seamless process we have currently.

There are still some challenges around the GUI—this will probably be one of the biggest changes for Windows admins in a long time. DBAs—you have less to worry about, just don’t plan on physically logging onto your servers, but you’re doing that anyway, right?

 

What Version of SQL Server AM I Running?

I’m in the midst of a project using System Center Configuration Manager’s (SCCM) Desired Configuration Management (DCM) component. It has taken us some time to come up to speed on this, so our initial configuration checks were strictly against the Windows OS. Last week, we started working on the first SQL check—checking for service pack level. Initially, and for simplicity reasons, I wanted to avoid logging into to the database. So we put together the following PowerShell script.

 

 

 

 

It looked simple enough—we wrapped some version logic around it, and then tried to run it on a mass scale. It returned some of the following version numbers:

Version

—————-

10.3.5500.0

10.3.5500.0

10.50.1600.1

10.2.4000.0

10.50.1600.1

10.1.2531.0

10.50.1600.1

10.2.4000.0

10.51.2500.0

 

A few of those are actual legitimate build numbers, but most are not in the list at SQL Server Builds. This pattern is consistent in both the registry and the advanced properties of the SQL Server service in configuration manager. A connect item has been filed specifically about SP1 for 2008R2 doing this, but as the above data shows, it appears to be occur across multiple versions.

Additionally, I have a Premier support ticket open with Microsoft, but we haven’t had a solid response yet.

On Friday night after a glass of wine or two, I decided to see what would happen if I hacked the registry back to the “correct” version. I built a new VM using SQL 2008 R2 SP1—version is 10.50.2500, but shows as 10.51.2500. I did a global find and replace in the registry for 10.51 to 10.50, as well as replacing MinorVersion from 51 to 50. It worked in so far as PowerShell and SQL Config Mgr reported the proper version; however when I attempted to apply a CU to the instance, the installer broke. Don’t try this at home!

We can always log into the database and run select serverproperty(‘productversion’) and get the correct version—which SQL Server clearly isn’t getting from the operating system. This is a relatively minor issue, but I’m surprised it hasn’t risen to the surface more.

 

 

 

%d bloggers like this: