Deploying SQL Server 2000 onto Windows 2003 clusters with more than 4 nodes
By Devin Heitmueller | June 11, 2008
So you’re deploying a clustered instance of SQL Server 2000 onto two nodes in a Windows 2003 cluster. The installer runs to completion, but all of the resources in your newly created cluster group are in the offline state, and any attempt to bring the group online results in an unknown failure.
In many cases, this is the result of some unexpected behavior in Microsoft’s license enforcement. SQL Server 2000 documentation states that it supports instances of up to four nodes. However, if you are running Windows 2003, you can have Microsoft clusters up to eight nodes.
Where the documentation becomes unclear is that the limit is not on the number of nodes the instance is deployed on, but rather on the total number of nodes in the Microsoft cluster. So if you have an eight node Microsoft cluster, with the intention of putting four 2-node instances onto it, then you will hit the above failure condition.
It would have been nice if the SQL Server 2000 installer would just tell you this is the problem when you try the above scenario. Unfortunately, it just proceeds with the install and then the instance doesn’t startup. Here at GridApp, we didn’t realize what was causing the problem until we dug through the error logs and put the following string into Google.
[clushelp.cpp:150] : 259 (0×103): No more data is available
Only then do we arrive at the Microsoft Knowledge base article describing the issue (KB811054).
— The Clarity Advantage —
GridApp Clarity has a precheck built in to automatically check how many nodes are in your cluster if you are deploying SQL Server 2000, and to show you an error message informing you of the problem before the install starts. This allows you to correct the problem (such as picking a different cluster to use or making the cluster smaller) before you deploy a broken instance and spend the time trying to figure out why it won’t startup.
Topics: SQL Server 2000 | No Comments »
Boring Jobs Dull the Mind (and Insight Failures)
By Eric Gross | June 9, 2008
Here is an interesting article:
BBC News: Dull jobs really do numb the mind
New research shows that people who are asked to perform repetitive tasks eventually go into “autopilot” mode in order to economize the work required to complete a task. I know this is true for me - ask me to create 20 databases and after the third one, I’m in drone-mode. Unfortunately, after having completed it a few times, I know I’ll eventually miss a step because I’ve pretty much stopped thinking about the procedure. Drone-mode means my mind wanders elsewhere - such as my next post to the blogosphere.
Brain scans can predict when someone has gone into this minimal thinking state. So if you want to improve the quality of your database management team you could fashion a hockey helmet with EEG electrodes, pop them on your DBAs, and start monitoring when they go into drone-mode.
Better yet, either enrich their jobs or - *gasp* - try automation!
Topics: Data Center Automation, People, Efficiency | No Comments »
Unleash Your “cognitive surplus”
By Eric Gross | June 5, 2008
A recent meme - cognitive surplus - has risen that describes the resources that have been brought to bare to accomplish a useful task once people get tired of wasting their time. The discussion started with a talk that shows how people have so much free time to work on improving the Wikipedia (the estimate is that about 100 million human-hours has gone into the project so far). Imagine if your car suddenly learned how to drive itself, leaving you to be able to do what you wish with your commute - you would suddenly have a few free hours per day for accomplishing something new - perhaps a college course, reading the paper… even putting on your make-up or chatting on the phone without fear of a ticket or accident.
Imagine then if your databases could “drive themselves”, while database vendors have been pumping out databases for decades, only recently has extensive automation been available to drastically reduce peoples’ needs to manually perform common tasks. GridApp’s automation technology reduces the human time required to do everything from provision to patch.
What could you do now with the cognitive surplus released by automating your database stack? There are plenty of tasks that DBAs can still do which are not yet fully automated such as performance tuning and planning for future growth/migrations - coincidentally, tasks which make money for the company. Or perhaps it leaves more time for applying the often-ignored security patches or testing backups and restorations.
GridApp has automated many of the common database tasks that suck up your team’s valuable time and energies; this not only improves database management efficiency, but also yields increased value from each resource because of the intrinsic standardization that comes with automation.
Never leave your potential surplus on the table!
Topics: Agile, People, Clarity, Consistency, Database Automation, Efficiency | No Comments »
Only 10% of Oracle Databases are Secure!
By Eric Gross | April 29, 2008
A recent article in eWEEK revealed alarming statistics surrounding patch and CPU application. The survey was conducted by a company that appears to benefit from the patch application process being as painful as possible (they sell a solution that attempts to mitigate security risks surrounding non-patched databases). Back to the survey, here are a few of the more disturbing stats:
- Only 10% of those surveyed, had deployed the most recent set of CPUs
- More than 65% of the DBAs surveyed said they had never applied a critical update from Oracle!!
What the survey data actually reveals is a deficiency that screams to be solved with patch automation. Automation reduces time-to-patch dramatically by separating the definition/packaging of a patch (including any pre & post scripts that may be a part of an organization’s standard for patch activity), from the actual process of installing the patch.
The benefits of this type of automation are immediate and quite clear:
- Patch definition and packaging by fewer folks = much greater standardization; increase in enforcement of standards.
- Reducing manual execution of patch application leaves less room for fatal-variances.
- Automated standards surrounding security patches make them safer and faster to deploy and would allow far more organizations to properly and promptly apply these critical patches.
Don’t get me wrong, the fault is not with the DBA. This security-catastrophe-waiting-to-happen is being caused by the delayed adoption of automated database administration practices, and this falls squarely in the lap of an organization’s decision makers.
Topics: Security, Data Center Automation, OPatch, Database Automation, Patches, Efficiency | 1 Comment »
What’s wrong with this picture?
By Devin Heitmueller | April 11, 2008
You are about to deploy SQL Server 2000 into “Group 0″ of the following cluster. Can you spot what is wrong with this cluster and why your install is going fail?
If you actually tried to deploy an instance on this cluster, you would start filling out the wizard and, after picking the nodes to deploy on, the CPU will go to 100% and the installer will hang indefinitely. Because it happens when you click “Next” after picking the nodes in the cluster, you might be tempted to think the problem had something to do with the node selection. In fact, the problem occurs because the installer is trying to build the display for the next dialog box which shows you the clustered disks to choose from.
The key to this problem is a footnote in the Microsoft knowledge base article KB293788:
This problem can also occur if the resource name for an available shared disk or the resource group name for the available shared disk has the name as the disk itself. If drive X: has a resource name of X:, or its resource group name is X:, the same symptoms will occur.
In SQL Server 2000, there is a bug that occurs if you make the name of the disk resource the same as the drive letter. Whereas a physical disk resource named “Disk G:” is valid, making the resource name “G:” will result in the installer hanging once you click “ok” on the “Failover Clustering” page in the installation wizard.
The problem is compounded by the fact that it can be **any** physical disk resource in the cluster and not just the one you are intending to deploy onto. So a manual procedure would require a user to go to the cluster administrator and look at every disk resource in every resource group in the cluster. This is fairly simple in your test environment that might have a cluster with one resource group, but a time consuming operation to make a DBA perform on a cluster with many resource groups every time he wants to deploy a new SQL Server 2000 instance.
— The Clarity Advantage —
GridApp Clarity has a precheck built-in to automatically check for physical disk resources that have names that cause the issue, and to show you an error message informing you of the problem before the install starts. This allows you to correct the problem (presumably by renaming the offending disk resource) rather than running the installer and having to figure out why it pins the CPU at 100% indefinitely.
Topics: SQL Server 2000 | No Comments »
« Previous Entries