Re: Solid State Drives
- From: John Kanagaraj <john.kanagaraj@xxxxxxxxx>
- To: tanel@xxxxxxxxxx
- Date: Sat, 2 May 2009 12:19:59 -0700
Hi Tanel and all,
~ 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 **
--
//www.freelists.org/webpage/oracle-l
Other related posts:
