Re: Performance issues when running in archive redo log mode

Hi Birsan,

    I suspect that your "Consultant" belongs to the P.T. Barnum school of consulting -- "There is a sucker born every minute!". Either that or your consultant was talking about your specific configuration.

    If your archives are on a different disk drive (better yet a different controller) than your redo logs you shouldn't see much of a performance hit if your system is well tuned. So, before you start testing for yourself (as suggested in another posting) optimize file placement on your disk drives, make sure that you have enough redo logs specified to prevent waiting while they are being archived, and make them big enough to handle 15 to 20 minutes of transactions at normal volumes (this is one point where there will probably be some disagreement, but it is a good starting point).

    hth
jerry gitomer

Birsan wrote in message ...
>One of the consultants that we are working with claims that
their tests have
>consistently shown that there is a significant performance hit
when ORACLE 7
>(running on UNIX, different flavors, one of them being NCR
UNIX), is set to
>operate in archive redo log, as oposed to non archive redo log,
mode (the
>performance hit is said to be 30-40%). This confuses me, because
I had the
>obvious misconception that the only difference (as long as you
do not
>actually issue "alter tablespace begin backup") is that you do
not re-use
>the redo logs, but "archive" them, so that they can be used
later in the
>recovery process. I certainly did not expect such a big hit,
which basically
>stops us from using normal on-line backup procedures, even
though
>availability has to be 7x24. For performance reasons as well,
the consultant
>recommends not using replication either, which leaves us with
the only
>choice of a proprietary application replication scheme, in order
to provide
>high availability and database maintenance capabilities
(provided by the
>consultant). Can anyone confirm that these claims make sense?
>Thank you for your response!
>
>
Received on Wed Nov 03 1999 - 06:14:08 CST