Re: benchmark to disprove myths

Hi Ed,

I think your test scenario is far too small.

• There's no index on the table (separate data & index TBS)
• 100.000 rows of (estimated) 100 byte = 10MB usually fits in buffer cache
• the amount in total and per time will be too small to give reliable results.

Separating data from redo is done for security reasons and for speeding up in high loaded system with Megabytes of redo per second. In such a szenario, sequential writing of redo data on dedicated disks will provide a benefit.

Stephan

"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message news:3dee8a26.83981499_at_ausnews.austin.ibm.com...
> 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.)
Received on Thu Dec 05 2002 - 02:33:59 CST