Expensive Administrator

On the OracleDatabase page, someone suggested that Oracle's "disadvantage" is the requirement for ExpensiveAdministrators to make sure it's tuned, runs efficiently, etc.

This makes one wonder:

Is it a disadvantage of C++, Java, etc. that it's usually best for ExpensiveProgrammers to act has an XpCoach or SoftwareArchitect?
Why do people assume that configuring and tuning large high performance & concurrent data stores should be easy? ThomasKyte likes to refer to this mentality as the eternal hunt for the "fast=true" parameter. (SetFastParameter? FastParameterPattern? Seems to be another NamelessConcept. I'm seeing them everywhere now.)

Databases are complicated products. Certainly there's a greater need for automation and smarter default settings, but they're going to remain NaturallyComplex.

The primary reason Oracle needs ExpensiveAdministrators is that there is a tremendously wide range of opportunity for monitoring and tuning. It's more instrumented than almost any software product out there. A secondary reason is the complexities associated with Oracle's MultiversionConcurrencyControl and SnapshotIsolation locking: managing rollback segments or undo tablespaces, and managing online redo logs. 9i has made great strides in this area for low-end database deployments with automatic undo management.

Contrast this to the relative ease of setup & maintenance for SQL Server. SQL Server is definitely fast and tunable, but arguably no where near as instrumented as Oracle is, limiting its use under particular scenarios (i.e. highly concurrent OLTP systems, which is Oracle's stronghold).

The alternative to paying an expensive administrator is to pick a low-paid person at random and assign the task of becoming an expert in Oracle or whatever complex technology is in question. This usually leads to one of the following results:

The expert-to-be never figures it out, and then your project fails unless you bring in an expensive administrator at huge expense to bail you out.
The expert-to-be does figure it out (after considerable expense and period of time), and then you either have to give that person a huge raise, or you watch them leave and then pick a new expert-to-be.

The point is that expertise costs money. You need to hire an expert, or grow one, and you're going to have to pay the experts what they're worth.

Personally I would like to see trial practices of dynamic databases (see MultiParadigmDatabase). Database products are often more complex than they have to be for many uses. Dynamic databases may help solve this. However, being dynamic and being scalable may be ConflictingRequirements. -- top