Re: Oracle much slower than MS SQL Server on NT?!

From: Gary England <gengland_at_hiwaay.net>
Date: 1997/09/22
Message-ID: <34264A2F.5E9C_at_hiwaay.net>#1/1


Vitaly Sikolenko wrote:
>
> The most probably you have a problem with "overlapping" checkpoints in
> Oracle when making a bulk data load. The point is that when a log file
> is filled the "log switch" occurs which triggers a checkpoint (writing
> all the "dirty" buffers to disk). In principle this doesn't slow down
> the database performance since checkpoints are astynchronous in Oracle.
> If the checkpoint doesn't finish before the next log switch occur the 2
> checkpoints "overlap". When performing a log switch Oracle must ensure
> that the checkpoint initiated with the previous filling out the log file
> which is about to be refilled is finished (otherwise it cannot guarantee
> the full data recovery after failure). If you have overlapping
> checkpoints Oracle7 cannot distinguish (Oracle8 can) the checkpoint
> initiated with "needed" log file from the checkpoints initiated by other
> log files. As a result Oracle waits for the last checkpoint to be
> completed!
> To avoid such situation increase the size of log files (by default they
> are very small) and also increase the parameter LOG_BUFFER (it's also
> very small by default). I think after that you'll have Oracle perfoming
> your data load much faster.
> And the last. You will not see any significant preformance benefits of
> Oracle when trying one-user tests. Oracle performs much better than
> others in multi-user configurations especially when several users update
> the same tables concurrently.
>
> L. Tseng wrote:
>
 [snip]
>
> --
> Vitaly Sikolenko Senior Sales Consultant
> Server & Gateways
> ORACLE C.I.S.
> Moscow Russia E-mail: vsikolen_at_ru.oracle.com
>
> The statements and opinions expressed here are my own and do not
> necessarily represent those of Oracle Corporation.

You can also add additional log file to give the cleanup program more time to archive the filled files before things wrap. Received on Mon Sep 22 1997 - 00:00:00 CEST

Original text of this message