Re: Performance issues when running in archive redo log mode

Get a new consultant. I have run many database in 7x24 shops with Archive Logging turned on and it did not degrade performance. My guess is that the consultant who did his test, did not have things configured correctly. Ask the consultant for the Database layout that he tested his theory with. Also find out how much memory, processors and disk drives he had available. Ask him to explain what he used to measure that 30-40% slowdown, was it a reduction in transaction throughput or something else. This should give you a pretty go picture, of whether his test was valid. If the archiving log area and the online redo logs are not configured correctly, then archive logging can affect database performance. If the archive log area fills up it can even stop the database temporarily, but these are configuration issues.

  As for the replication, well this is another area that requires careful planning. Replication can work very well, or very poorly depending on how you configure it. Some things you need to take into consideration are the speed of the network between the to databases involved in Replication, how much data you intend on replication, how often is the table you want to replicate inserted and updated, etc.

In closing I would atleast ask for a detailed explanation of how archiving can cause the database to slow down 30-40%.

Mike H.

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 - 08:03:23 CST