RE: Slightly-OT: Throw HW at a SW/DB problem

From: "Lange, Kevin G" <kevin.lange@xxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Date: Tue, 19 Jul 2011 16:12:23 -0500
Dave ==> We as Oracle DBAs do not live in a Star Trek universe and
should be hesitent to so obviously critisise that that we don't truly
understand!
 
 
You spelled Criticize wrong     
 
:)
 
Kevin
 
Sorry, could not pass that one up.

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of David Roberts
Sent: Tuesday, July 19, 2011 3:54 PM
To: ora_kclosson@xxxxxxxxx
Cc: dbvision@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Slightly-OT: Throw HW at a SW/DB problem


OK, I apologise for coming late to the ball!
 
For context I will repeat the gist of a conversation I had with a friend
more than 10 years ago.
 
I expressed my astonishment that while Star Trek (TNG) would always
arrange 2 part episodes so that they were split over 2 VHS tapes, B5
(Babylon 5) would do 2 part episodes on a single tape.

My friends response: Ao not attempt to apply a Star Trek solution to a
Babylon 5 Problem!
 
 
Every one of the posters to this thread has missed the fact that this is
an Oracle group discussing an SQL*Server article!
 
 
Oracle can run a database used both for reporting and OLTP processing
along with a web server and some custom client code on a single server
successfully.
 
It is the scale up model.
 
Obviously,  I'm sure that the first step when encountering the above
environment would be to suggest that the DBMS be on a separate server! 
 
 
SQL*Server, because of historical limitations with the software has
tended to be used in scale out architectures, where you may have
multiple OLTP databases, performing separate tasks, a Data Warehouse and
separate reporting server(s?) even before the middle tier is reached.
 
In that scenario, it is substantially more difficult to actually come up
with a scientific guarantee that making a specific software change will
result in a specified expected change in performance.
 
 
So, with an Oracle database, doubling the memory and increasing the sort
area size will result in?
 
On a batch system, an increase in performance.
On an interactive system, possibly negligible difference.
On a mixed system, a significant change in bias from interactive
processes to batch processes and a substantive perceived reduction in
performance.
 
 
In a 'scale outs' world, doubling the memory on the data warehouse might
not have any significant beneficial effect, but by it's distributed
nature the negative aspect is also limited.
 
 
So in the Microsoft world, the risks of throwing hardware at the problem
are reduced, because network bandwidth will throttle some of the worst
detrimental performance impacts and if you throw hardware at several
multiple points of a complex architecture, the chances are that at least
one of them will work and the other hardware changes can be written off
as contribution to the area of successful performance improvement.
 
 
A second aspect is that while SSDs are not the performance tuning
panacea that some claim, their performance profile is 'simpler' then
that of spinning disks and their throughput is going to scale in a more
logical manner!
 
 
There is a simple case that, in the SQL*Server world, tuning by hardware
may yield better results than in the Oracle world, and in the
commoditised hardware future, this approach may become relatively more
effective.
 
 
Ultimately, like the articles' author, I see a world with a smaller
number of more specialised tuning DBAs very credible!
 
 
We as Oracle DBAs do not live in a Star Trek universe and should be
hesitent to so obviously critisise that that we don't truly understand!
 
 
Dave
 
On Mon, Jul 11, 2011 at 9:02 PM, Kevin Closson <ora_kclosson@xxxxxxxxx>
wrote:


        yep...I was.
        

        
________________________________

        From: Nuno Souto <dbvision@xxxxxxxxxxxx> 

        To: oracle-l@xxxxxxxxxxxxx
        
        Sent: Wed, June 29, 2011 2:50:25 AM 

        Subject: Re: Slightly-OT: Throw HW at a SW/DB problem
        

        Tim Hall wrote,on my timestamp of 29/06/2011 7:02 PM:
        
        > how many units you sell. History is written by the winners. :)
        
        or alternatively, history is ignored:
        
        http://dbasrus.blogspot.com/2007_01_01_archive.html
        
        (scroll down to the 2 "no moore" posts.
        Written and published *long* before Exadata was announced.
        Mind you: Kevin and I were blogging a lot on the whole subject
of I/O and its limits with current technology. I think he might have
actually hinted at what was coming. Interesting times, back then.)
        
        BTW: will you be able to visit our SydneyOracle meetup group in
August during your stay for the Insync gig?  This time we promise to not
lock away the projector *just before* you walk in!...
        ;-)
        Trying to get Tom Kyte as well, if he's available. The more, the
merrier!
        
        
        -- Cheers
        Nuno Souto
        in wet Sydney, Australia
        dbvision@xxxxxxxxxxxx
        --
        //www.freelists.org/webpage/oracle-l
        
        
        



This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
References:
- Re: Slightly-OT: Throw HW at a SW/DB problem
  - From: Kevin Closson
- Re: Slightly-OT: Throw HW at a SW/DB problem
  - From: David Roberts
RE: Slightly-OT: Throw HW at a SW/DB problem

Other related posts:
