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 »
SQL Server Common Issues
By Devin Heitmueller | April 2, 2008
Hello there, my name is Devin Heitmueller and I am one of the developers responsible for automating Microsoft SQL Server using GridApp Clarity. Large portions of my day are spent digging through the Microsoft knowledge base, debugging various configurations SQL Server can be deployed in, or identifying and addressing undocumented behavior in the SQL Server 2000 and 2005 installation processes. Over my next few blog posts, I will discuss some of the common problems people run into when attempting to deploy SQL Server in an enterprise environment, both through manual and unattended installation methods.
The goal is not so much to highlight all of the bugs in Microsoft’s products as it is to inform the community of some of the more common issues they will likely run into, providing solutions or workarounds. We will also help users gain an understanding as to how deploying SQL Server is not as simple as just “filling out a text file and launching the installer”.
It’s the research, analysis, and resulting workarounds built into Clarity that distinguish it from other more general automation products that claim, “yes, we can deploy SQL Server too”.
So let’s get started…
The SQL Server 2005 “Task Scheduler” error is one of the more common problems people run into when installing clustered instances of SQL Server. They will launch setup.exe, go through the System Configuration Check (SCC), provide all the parameters for the new instance, and then when hitting “Finish”, they see the following dialog:
Hmmm…. So they use the Task Scheduler to run setup on the other nodes? You jump over to the RDP window you have open on the other server in your cluster, and you can see quite clearly that the Task Scheduler Service is running.
Well, it turns out that in SQL Server 2005, there is a known issue where you cannot be logged into any of the other servers in your cluster while you are running setup on the active node. This is documented in Microsoft knowledge base article KB910851. I could explain what is going on under the hood that results in this behavior (it has to do with a conflict between the interactive session logon SID and the SID associated with job scheduled via Task Scheduler), but since there’s no real workaround the information probably isn’t very useful beyond academic curiosity.
Note that the problem applies to both local logons and RDP (Remote Desktop Protocol) logons. It also applies to RDP logons that are in the “disconnected” state. So, it’s entirely possible that the last time someone was logged on via RDP, if they just closed the window instead of logging out then the user’s session is still running.
To terminate logon sessions, you have to logon to the box and run the Terminal Services Manager (Start->Administrative Tools->Terminal Server Manager). Then click on the server and in the right panel you will see all the RDP sessions in progress. Look for any sessions in the “running” or “disconnected” state, right click on the session and click “disconnect”. If you did this over an an RDP session, be sure not to disconnect your own session, and be sure to logout instead of just closing the RDP session window.
— The Clarity Advantage —
Provisioning through GridApp Clarity automatically checks if there are any logon sessions on any of the servers and informs you if there are sessions, eliminating the need to logon to each server manually and check for sessions in progress. It does this as a precheck, so you find out about the issue before any operations are actually performed on any of the servers. So you don’t get into a state where your prescript has already run and the process bails out when the installer is launched.
Topics: SQL Server 2000, SQL Server 2005, Database Automation | No Comments »
GridApp expands platform support for Clarity Agent
By Devin Heitmueller | April 1, 2008
In the interest of supporting as many platforms as possible, GridApp Systems has expanded support for its Clarity Enterprise Agent to run on the following platforms:
- Microsoft Xenix
- AT&T 3B2 System V, Version 3
- Microsoft MS-DOS 6.22
- Debian Linux
- Tandy Corporation TRS-80
At the same time GridApp will add support for the following database platforms:
- E. F. Codd’s proof of concept
- Ingres version 1.0
- Oracle Parallel Server
- FileMaker Pro
According to Matt Zito, GridApp’s Chief Scientist:
We really did want to be able to say that our agent runs on everything under the sun. How many times do you walk into an organization and they say, “We’ll buy it, but only if you support platform X.” Well, now we can finally say that we do.
Devin Heitmueller, the lead developer for expanding OS architecture support states:
You know, we thought the small thread stacks found under the PA-RISC version of HP-UX 11.11 were a problem. That was nothing compared to getting the code to run on the TRS-80, a system that only has 32 KB of RAM and no network capability. I lost the first version of the port because my sister tripped over the power cord before I had a chance to backup the code using my cassette tape drive.
GridApp will be releasing the agents in the second quarter of 2008.
Topics: Clarity | 1 Comment »
« Previous Entries Next Entries »