RE: Slightly-OT: Throw HW at a SW/DB problem
Date: Tue, 19 Jul 2011 16:12:23 -0500
Message-ID: <F077F09A0E11504D9E720358BEE994D10835EEC9_at_APSW0553EVS.ms.ds.uhc.com>
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of David Roberts
Sent: Tuesday, July 19, 2011 3:54 PM
To: ora_kclosson_at_yahoo.com
Cc: dbvision_at_iinet.net.au; oracle-l_at_freelists.org
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_at_yahoo.com> wrote:
yep...I was.
From: Nuno Souto <dbvision_at_iinet.net.au>
To: oracle-l_at_freelists.org
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 subjectof 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, themerrier!
- Cheers Nuno Souto in wet Sydney, Australia dbvision_at_iinet.net.au -- http://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.
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Jul 19 2011 - 16:12:23 CDT