Is that true for RAC vs Redhat on cost?

Question

Hi,
see below link, video,
http://www.redhat.com/promo/streamline/HighAvailabilityDatabase/?intcmp=70160000000HUrE
So Redhat has better RAC solution.
Redhat RAC + Oracle Standard edtion, beat Oracle enterprise? performance, and cost.
Peter

Answer 1

> Is that true for RAC vs Redhat on cost?
No. The assumption from Redhat in this video is that the application and data can be neatly partitioned into customers and orders. (a shared nothing cluster approach)
If this is truly the case (which will be unusual), then there is really very little need for RAC - and many other solutions that are even better than this "offering" from Redhat. (exactly what are they trying sell here anyway?)
But as this neat and tidy border very seldom exist, how do you integrate the separated data sets? A few methods.
You can look at it from the db side. Distributed selects over database links (that can easily kill performance). Materialised views (more expensive SAN space). Etc.
You can look at it from the app side. Make the app use dual connections, one to each database. Move the joining logic and code from the database into the app. Of course, a great way to turn the app fat, make the database a bit bucket, and kick performance repeatedly in the nuts.
You can look at it from the app server side. Have the app server (with its scalability etc) access the databases, integrate the data and cache the data. Only.. isn't this exactly what a database does? And what about the cost for these app servers that needs tons of memory for caching. (Hint to Redhat: JBoss ain't that good and makes a poor database)
Is RAC expensive? That depends... If you go and buy huge SMP boxes as RAC nodes, your h/w is going to be as expensive as your s/w. If you buy MPP blades, your h/w cost will be a fraction of your s/w cost.
And that is a key point that is often missed. And one that I had all kinds of arguments with management about. There is a complexity factor in doing high availability, redundancy and scalability.
With MPP that complexity moves from the h/w into the s/w. So unlike the traditional approach (dating from buying very very expensive mainframe h/w), you buy cheap h/w. And as the complexity is in the s/w, you pay more for the s/w. Google's cluster of clusters is the prime example of this.
Thus the cost moves from the h/w to the s/w. So is RAC really that expensive? And remember that one needs to compare apples to apples here. If you price another solution to compare with RAC, that solution needs to provide the same feature set you want from RAC.
And that's where the Redhat video falls flat. They do not offer the same feature set. And if that is truly the feature set needed by the client, then RAC is the wrong architecture to use in the first place.