Re: Tuning Pack
There is a shitload of features in oracle. Each version brings it's own layer, and it's own bag of issues. Triggers overhead, buffer groups, result cache latches, sql plan management hidden plans (and defaults), compilation level messing error lines, hprofiler inconsistent results, FAQ (fracking advanced queuing) etc.
The cost based optimizer first aim, based on histograms, was to address skewed data. But even now it's wonky when data is extremely skewed, or when bind peeking is used. or involves date columns, or etc. It can be argued it's a design issue. As well, oracle can't seem to understand alone that data spread among blocks is critical to throughput.
And yet sqlplus still doesn't support unicode chars, there is no tool to spread a query on 10 or 100 db and aggregate the result, sql developer is a nightmare. Editions are heavy. And I forget a truck of bothering stuff, or two.
Then we can discuss spin gets counted as "on cpu" when oracle invoice their thing as "per cpu".
But the main performance issue is usage. Most databases, sadly, do both oltp and olap. The first require response time, the second throughput. And both requirements are mutually exclusive.
Funilly enough, the same debate happens at cpu level, and that's why there are things like hsa, phy, BIG.little, denver/kepler (not sure about nvidia), BOC/lic.
In the database world this result in stuff like storm/hadoop and other multi-tier db configurations. When you know what data *really* needs acid transactions, you can design a database that is *real* fast. Things like cc payments are done through a webservice, and programatically. I have yet to see dmbs_xa used for that kind of stuff, so you lose db "acidity" anyway. But even if you know the overhead of logs, locks, writes and "vertical reads" (group by), there is no way way to implement these design concepts in a traditional rdbms.
To split workloads with oracle, there is no easy solution. Read only standby database works unless you use mv or temp tables, dblinks unless you have blobs, and don't touch goldengate with a yard stick.
I didn't have the chance to play with 12c/rac yet, but my guess is that it comes with it's lot of undocumented features (looking at it's architecture chart did frighten me. As much as parallel execute explain plan).
Point is, it's doesn't work well out of the box, and even when everything is set up and monitored, it's still full of surprises. And most programmers people don't know jack about the sql world, they are lost when they have to open that box and look into it.
Alternatives don't seem mature (the full immutable/in_memory "newsql" pack) or require such paradigm change that migration (not of data, but minds) is impossible, despise the cost advantage that can soon reach millions, per year. And I'm sure traditional competitors have an even bigger sum of bodies in the closet.
/rant
Biting the hand that feeds IT
