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).
2 comments:
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 :-)
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).
Post a Comment