Monday, June 22, 2009

Simplicity is Crucial in Database Deployment

While visiting the homepage of our beloved vendor, I came across this link to "Gartner".

Gartner Research is among the most used and cited in the IT industry, so I was curious to see what was there. The title was promising:

Oracle RAC Moved to Mainstream Use

I had a good read and the one thing that struck me was the number of mentions (warnings) of "complexity" and "need for training". There is also the "confusion between ASM and CFS" to notice.

Of course, I only read what I want to read, and conclude what I want to conclude, but I will stay firmly on my view "Simplicity is King" (but complexity sells better).


Martin said...

An interesting Article, Piet, and I can see what you mean about the repeated references to needing training and strong skills to live with RAC. But then, that is reasonable, as RAC is for use with larger, more complex systems. Or at least it should be! Anyone implementing RAC because they want a pool of homogenous instance servers they can throw their oracle database on and apps against is almost certainly going to get very, very unstuck.

I think Gartner is being too generous in it's representation here, it does not mention that many applications simply will not scale against RAC and that going beyond two nodes gives more headache for less gain. It is nice that they mention one of the major drawbacks of ASM, in that it moves storage from one team to another and can have large political ramifications. It does not mention one of the main benefits, which is that it usually gives very predicatable (actually that should be stable) performance.

I think you have to have a good reason to go for the complexity of RAC and, if you do have that reason, the complexity is not something you should fear unduly. A car is far more complex than a bike, but I know which one I want to travel the length of the country using :-)

PdV said...

Thanks Martin. Lots of items you mention there.

Scalability on RAC, and the magnifying glass effect: every scalability-issue just gets bigger (worse) on RAC. That actually keeps me in a job: good old physical datamodel and proper application (logic) design are becoming Increasingly Important again.

ASM and storage politics are another of my pet peeves. And putting the "storage" back in the hands of the DBA is an advantage of ASM, but not its main raison d'etre.

As for transportation: I prefer the trains for longer distances and to avoid traffic jams (provided I can sit in First).


This is the footer...and this should be small text for disclaimers and the like. and some small stuff

Locations of visitors to this page And this text is placed next to the map. we could possibly hide some stuff here too for the benefit of the search-engines and if it is at color ffffff cam we put all sort of rubbish that we do not want readers to see. travel itinirary reservation ticket agent flight plane boarding attendant train connection rail ticket wait time booking flight boardingtime taxi ramp luggage suitcase trolley wheely laptop bagpack corpaorate wifi connection oracle. it will also be interesting to see what happens when this wrap around. or even if we put in spherus and worwood as additional word.