Re: benchmark to disprove myths

Ed Stevens wrote:
>
> My partner and I are still disagreeing on two prime issues covered in this
> summer's famous "Oracle Myths" discussion. We're also disagreeing on the value
> of separating redo logs, archive log files, and other data. All of this has to
> do with placement of different files on available disk arrays and how to best
> configure the disks in a new server.
>
> I am proposing a simple benchmark test.
>
> Have a PL/SQL to implement this pseudo-code:
>
> Create table my_test
> (empno number,
> last_name char(10)
> first_name char(10)
> street char(10)
> city char(10)
> state char(2)
> zip char(5)
>
>
> for x = 1 to 100,000
> insert row using x as the empno value
> commit
> next x
>
> for x = 1 to 100,000
> update my_test
> set last_name = 'xxxxxx',
> first_name = 'xxxxx'
> street = 'xxxxxx'
> city = 'xxxxxxx'
> state = 'xx'
> zip = 'xxxxx'
> where empno = x
> commit
> next x
>
> what I propose is running this with various placements of data, index, redo,
> rbs, and archive logs. What I hope to demonstrate is the value (or lack
> thereof) of
>
> 1 - separating index and data
> 2 - giving redo its own raid set
> 3 - giving archive logs their own set
>
> Does this sound like a resonable means of proving/disproving long held
> assumptions and the assurances of our hardware guys who insist that drives are
> now so fast that we can ignore these kinds of considerations?
>
> --
> Ed Stevens
> (Opinions expressed do not necessarily represent those of my employer.)

plsql may not be a good one to use for the test because commit are not really commits so you get an artificial redo rate.

also, its probably more important to check the wait times then total execution times - because one particular io configuration may cause some unrelated side-effect

hth
connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."