Re: Solid State Drives

~ 1) As far as undo is considered, it's definitely cheaper to keep it in
~ buffer cache than ping it in and back from external device (you have logical
~ IOs + physical IOs + external bus traffic versus just logical IOs in case of
~ buffer cache)

I agree with you that while it is cheaper to keep everything in buffer cache, it is costly to *optimize* access to those buffers, and *that* is the issue. There are two issues here IMHO:

1. Writing efficient applications and the underlying efficient SQL and optimizing bad SQL/bad application configuration is not cheap: Recruiting, training and retaining the right talent to architect, build and maintain such efficient applications is costly (these costs drop in a bad economic situation but soars when it becomes better, and exactly during periods when business really need this talent as they surge up in building/deploying/changing applications). That is why business find it easier to KIWI (Kill It With Hardware), and SSDs, larger cache are one more set of tools that can help hammer the nail through.
2. Oracle (and other hardware/software vendors) try and mitigate this issue using new techniques such as IMU (in memory undo), Result cache
   (client/server side, PL/SQL, etc. in 11g), SSDs (this discussion).
   Essentially, they are trying to help hide the negative effects of bad SQL under the carpet, and things go horribly wrong in the first pass
   (see number of bugs in IMU for 10.2.0.3 for e.g. - we are suffering
   from an intermittent "latch: undo global data" issue btw, and the solution is to "upgrade" :).

While KIWI and DB Software/Hardware optimizations works in many cases
(especially scaling up a good application), it doesn't work in all
cases, and it takes a while for the business to figure that out. It is usually quite late before this figuring out happens and *then* they start looking for application optimization. The opportunity cost that is lost during this process far outweighs the differential costs between the technologies that can be used to mitigate the problem
(coming to your point).

I think what I am trying to say is this: It is cheaper to do it right first time, from the ground up, and businesses need to balance the need to get to the market quickly while finding the most optimal route to get there. You cannot go to the outside with a badly performing app and neither can you wait too long to build the perfect app. Applying Cary's "optimize the top 5 business functions" is the way to go, and use KIWI as an intermediate step to get there. SSD and larger caches are way to get there quicker, but they are not the end all (which businesses they are)

Sorry - I rambled on there and took a diversion...

-- 
John Kanagaraj <><
http://www.linkedin.com/in/johnkanagaraj
http://jkanagaraj.wordpress.com (Sorry - not an Oracle blog!)
** The opinions and facts contained in this message are entirely mine
and do not reflect those of my employer or customers **
--
http://www.freelists.org/webpage/oracle-l