People, Process, and Technology to keep your systems running.
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.
This past Saturday I enjoyed the hospitality of the Tampa SQLSaturday (#32) team. My presentation was “Clustering for Mere Mortals”. Unlike many clustering presentations, I had demonstration content. This resulted in the most asked question being “Do you have instructions on how you built that?” This is the first part of those instructions.
Here is what the cluster consists of (Virtually):
One Windows 2003 R2 (x64) Server acting as Domain Controller, DNS Server, DHCP Server, File Server and iSCSI Target Server
Two Windows 2008 R2 Servers as cluster Nodes.
All this runs on a Lenovo W500 laptop with an Intel Core 2 Duo T9600...
I just got this question from a blog reader:
We have a SQL 2005 cluster active/passive. Under my understanding, it would be neccesary to apply patches into a Testing environment, if working fine, proceed to the production environment... but, is it recommended to patch both nodes the same day? or instead it would be better to patch Node1 (active) and wait some days before patching Node2 (passive)?
I would like to know your opinion on this matter !
Thanks a lot for your support.
The answer is you always must patch all nodes at once using SQL 2005. Rolling upgrades/patches was introduced in SQL...
Looks like the Great Zune Massacre of 2008 was a day 366 issue. Again, someone forgot to throw out the code from the lowest ten percent of the Stack-Rank system. Sorry to sound harsh, but this is type of thing will flunk you out of Programming 101. I don't even want to get started on the QA failure, but it is even worse.
Semi-Kudos to the Zune Team. There was a notice on the support page shortly after the original post acknowledging the problem and indicating they were working on it. Microsoft also got word out through its MSNBC subsidiary as...
Yes, I own a 30 GB Zune. Yes, it crashed today. Yes, I am unhappy.
Having worked in the computer industry for many years now, I watched many companies deal with failed products. Such is inevitable in an industry that gives the biggest rewards to the first implementation that is “good enough”. More importantly, I have seen companies deal with failures in various ways. Some handled things well and some no longer exist or have lost market dominance due to poor reactions to failures. Here are a few observations that I am sure Microsoft will ignore, partly because you have to...
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.
For the past several editions, SQL Books On-Line (BOL) has helpfully included a script to rebuild or defragment (since 2000) an index. Being Microsoft, this script is NOT located under the reindex or defragmentation topic, it is included in the fragmentation analysis section. For SQL 2000, this is DBCC SHOWCONTIG. For SQL 2005, they rewrote it to use the new system views and stashed it under sys.dm_db_physical_stats. It also uses the new ALTER INDEX command rather than the older DBCC DBREINDEX or DBCC INDEXDEFRAG command. However, this script does not allow you to take advantage of online indexing
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...
Well, yes. Actually you do. Patching a SQL Server cluster sounds like a complex endeavor, but it is really a lot simpler than people think. Much of the confusion is due to SQL 2000 and SQL 2005 having slightly different behaviors when it comes to patching. Also, with Clustering now available in Standard Edition, more DBAs find themselves caring for the first cluster in their organization. “Learn as you go” is not nearly as fun as it sounds.
The first rule of patching is to test. Make sure the patches work in a test environment, both with patches for the OS and for SQL. Given the history of...
Full High Availability Archive