Re: Oracle Design For Performance Question

BTW, I agree about learning being the best part of the job. That and the people we get to collaborate with.

Michael

On Thu, Jan 29, 2015 at 4:03 AM, Stefan Koehler <contact_at_soocs.de> wrote:

> 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: _at_OracleSK
>
> > Michael Cunningham <napacunningham_at_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
>

-- 
Michael Cunningham

--
http://www.freelists.org/webpage/oracle-l