Development team, Product Support, Marketing, and anything else that originates from
The only thing more controversial than new Federal Tax plans is new Licensing plans from Microsoft. In both cases, everyone calculates several numbers.
First, will I pay more or less under this plan?
Second, will my competition pay more or less than now?
Third, will <insert interesting person/company here> pay more or less?
Not that items 2 and 3 are meaningful, that is just how people think.
Much like tax plans, the devil is in the details, so lets see how this looks. Microsoft shows it here: http://www.microsoft.com/sqlserver/en/us/future-editions/sql2012-licensing.aspx
OK, this is really the first thing “I” hate about SQL Denali, but I bet a fair number of you will hate this too. Once again, Microsoft has enforced the dictum that everyone must be either a Developer or an IT Pro. As Data Professionals, many of us have suffered as our employers can’t figure out where to hang us in the company Organization Chart, usually sticking us between Dev and Ops and letting the managers (and us) sort it out. This time, Microsoft has decided we are “Developers” and we shall get our help via the Web. Admittedly, Google...
Now we get to the meat of the matter. You want a virtual cluster, the first thing you have to do is create your own portable domain. Start with a plain vanilla install of Windows 2003 R2 Standard on a semi-default VM. (1 GB RAM, 2 cores, 2 NICs, 128GB dynamically expanding VHD file). I chose this because it had the smallest disk and memory footprint of any current supported Microsoft Server product. I created the VM with a single dynamically expanding VHD, one fixed 16 GB VHD, and two NICs. One NIC is connected to the outside world...
Part 2 - Where I plan my Cluster.
Microsoft has successfully migrated its SQL Server support forums to a platform guaranteed to eliminate an estimated 20-30% of all corporate users. By including the word "social" in the URL, most corporate firewalls will block access automatically. Congratulations go to Microsoft for moving people off of their lowest cost support platform.
Ready, Fire, Aim.
No wait, that’s kickboxing. PowerShell is the something of the future. The management interface, the uber-scripting language, the what???
PowerShell, and its SQL-targeted implementation shipped with SQL Server 2008, brings to mind Michael Faraday’s response when asked “What use is electricity?” He replied “What use is a newborn baby?” PowerShell is somewhat of a newborn baby, much like the very early versions of SQL-based databases were. We see how those databases have grown and transformed IT and business in ways we never thought of. Maybe the future of PowerShell is just as bright?
Enough philosophy, let’s see if we can put this...
Fast on the heels of SQL 2008 is the Feature Pack for SQL 2008. Cool goodies include stand-alone installers for SQLCMD and the SQL Native Client, SQL 2008 Server Management Objects, SQL 2008 pre-defined Policies, and lots more.
You can find it here.
It looks like SQL 2008 may have a slight dependency issue. If you have already installed Visual Studio 2008, you will be blocked from installing SQL 2008 until you install Visual Studio SP1. The problem is that Visual Studio SP1 is not released yet. Our guys came in ahead of schedule and they still get no respect.
Not to worry, Visual Studio 2008 SP1 should be out very soon (think days, not weeks) and this problem goes away.
Microsoft actually documented this issue here:
Visual Studio 2008 SP1 may be required for SQL 2008 Installations
UPDATE: It's Here
SQL 2008 is finished. MSDN has all the bits downloadable now. Expect retail versions shortly.
Microsoft does not have a complete resolution for this problem yet, but they have found some more details. Evidently the problem with SQL Agent failure only occurs on systems using a domain admin account for the SQL Agent Service account. Microsoft is not 100% sure yet, so this is just a preliminary finding. However, it does match my own personal experiences. Worst Practices always has a cost. Several DBAs just found that out the hard way. Just as a reminder, this problem only occurs on x64 clusters using SQL Server 2005 build 3186 and higher.
SQL 2005 Build 3186 has a major negative side effect on x64 clusters. Installing it pretty much kills the SQL Agent.. The workaround is to enable unconstrained delegation for the machine and the service accounts. Not exactly a best practices security setting, but necessary. For now, if you are on an x64 cluster and don't have a compelling reason to install this hotfix, you may want to wait until this issue gets resolved.
Here is the MSDN thread discussing the problem and the workaround:
UPDATE: Build 3200 (Cumulative Update 4) has the same issue. Evidently this bug is due to a complex interaction...
Hopefully, I won't need a CATCH Block.
In case that opening sentence didn't give you a hint, I am a bit of a tech geek. Bill Graziano talked me into joining this merry band while at the PASS summit last week. While I enjoy answering questions on newsgroups, this will give me a way to initiate conversations. I looked around and decided SQLTeam would be a good place to stand and pontificate.
And now for some real SQL content. Sort of.
Based on a lot of presentations by Microsoft on proposed features and bug fixes, I have to conclude that Connect really matters. ...