Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Opinions on SAME?

Re: Opinions on SAME?

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Sat, 28 Apr 2001 10:52:22 +0100
Message-ID: <988451375.9683.1.nnrp-08.9e984b29@news.demon.co.uk>

Thanassis,

I don't think that there really is a general answer to this question. It depends so much on the transaction rate and the volume of lookup and reporting, and how much you can reduce physical reads by using memory well for db_block_buffers.

For example - if you calculate that your data files will need to do 180 I/Os per second, and the log files 60 I/Os per second, then you may well be better with full striping to avoid contention on the database activity.

If you decide that the figures are the other way round, you would probably favour an
8+2 (or possibly 6+4) approach, because
the database will survive on fewer discs and you don't want anything to impede the redo log writes.

Glad you liked the book.

--
Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

Practical Oracle 8i:  Building Efficient Databases
Publishers:  Addison-Wesley

Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html



Thanassis Stathopoulos wrote in message <9bujup$sq0$1_at_usenet.otenet.gr>...

>Jonathan,
>
>Is there a relatively-safe rule of thumb as to what's the *minimum* disk
>count where the redo logs should get their own disk pair?
>I'm thinking in terms of OLTP-centric systems with 8 to 10 disk drives,
>offering twice the expected database space, a dual-channel controller
>with mirrors split across the channels and battery-backed up controller
>RAM.
>Should this be 6+2, 8+2 or is it that at these counts the striping benefits
>still outweigh the separate redo log benefits?
>
>By the way, great book.
>
>Thanks,
>Thanassis
>
>
>
>
>
>
Received on Sat Apr 28 2001 - 04:52:22 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US