Date: Thu, 29 Jan 2015 13:03:26 +0100 (CET)
From: Stefan Koehler <contact@soocs.de>
To: Michael Cunningham <napacunningham@gmail.com>
Cc: "oracle-l@freelists org" <oracle-l@freelists.org>
Message-ID: <1194683618.18641.1422533006653.JavaMail.open-xchange@app10.ox.hosteurope.de>
In-Reply-To: <CAPt39ts24QcTa-26bm2QWn2ourumkts3km_VzedEWSO4AhnQxw@mail.gmail.com>
References: <CAPt39tsDM5sEpCdr54s-sawepNSe8JpLfGMgFCL1eKNAhnNp6Q@mail.gmail.com> <1182183080.10437.1422463268921.JavaMail.open-xchange@app03.ox.hosteurope.de> <CAPt39ts24QcTa-26bm2QWn2ourumkts3km_VzedEWSO4AhnQxw@mail.gmail.com>
Subject: Re: Oracle Design For Performance Question
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: contact@soocs.de

Hi Michael,
well adding some more required meta information to the text message - the amount of redo is absolutely manageable. Assuming your expected numbers in
peak: 2.000 message (per sec) * 968 bytes (redo and undo for 500 bytes per raw message) = 1.936.000 bytes = 1.8 MB per sec

So nothing to scare about. You can scale up these numbers with your real volume later on. You can also still use private redo with that amount of redo
per transaction (=< 128KB for 64 bit as far as i can remember) and avoiding much more (latch) contention on public redo log buffers.

Oracle RAC is a whole different topic as private redo strands do not exist and you have to keep in mind / consider the used SCN generation schemes
(nowadays usually broadcast-on-commit) as well. The LGWR argument for Oracle RAC is more related to I/O or CPU bounds of a single process, but you are
far away from that with 1.8 MB per sec.

All the other main performance things are more related to data design and application implementation. Please also keep in mind that you may need to
implement things differently for single instance and RAC.

I would suggest that you get the business requirements first and then choose the architecture (RAC or SI) accordingly.

P.S.: Yes, Oracle RAC is complex and you need to (re-)learn things, but it is very interesting as well. You should not be afraid of it, learning new
things (from others) every day is the best part of our job in my opinion.

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK

> Michael Cunningham <napacunningham@gmail.com> hat am 28. Januar 2015 um 18:45 geschrieben:
> 
>  Thanks everyone for the input. Here is a little more info in case it helps.
>   
>  The text column is varchar2(4000), but the avg size is much less (not sure yet, but let's go with 250). There are no attachments in this system. 
>  I had not thought of LGWR yet so thanks for mentioning that. RAC licensing is not a problem, but the learning curve does concern me a little. I
> never thought that RAC could improve performance by scaling the LGWR to different servers.
>   
>  If you have more to say please do.
>   
>  Thanks a bunch,
>  Michael
--
http://www.freelists.org/webpage/oracle-l