No, you need raw log files (or Quick I/O) to get true asynchronous I/O for LGWR.
Are not your present statistics ample evidence that the default simulated file
system based asynchronous I/O is (worse than) useless?!


-----Original Message-----
Sent: Friday, 1 September 2000 3:53


Is that async IO for LGWR and whole Sun Solaris IO behaviour set by default?
I have disk_asynch_io=TRUE in init.ora.


-----Original Message-----


No, those latches are not related. However, now that I see that there is some
contention for the 'redo writing' latch, I can say fairly confidently that your
redo log sync cost ratio "problem" is just intensive redo generation and a very
high commit rate coupled with the fact that your LGWR is not capable of
asynchronous I/O. You may want to consider getting asynchronous I/O for LGWR,
and a larger log buffer of say 512K would actually help in this situation.
However, your library cache latch contention is a much bigger problem much more
worthy of your attention.


-----Original Message-----
Sent: Friday, 1 September 2000 0:47


Could it be the case that library cache latch causes waits for redo allocation.
There's yet another your script which shows latch impact and here it's top
10 lines:

latch_sleeps:

NAME                            IMPACT        RATE    WHL             LEV
library cache                   4508426.09   0.11%    2193094         5
cache buffers chains            32259.81     0.00%    36729           1
session allocation              10408.03     0.02%    32814           5
shared pool                     7811.42      0.01%    68227           7
Checkpoint queue latch          3938.01      0.00%    18370           7
row cache objects               2440.01      0.00%    1080307         4
redo writing                    1793.16      0.00%    355834          5
messages                        845.49       0.00%    99480           8
sequence cache                  531.07       0.00%    7244            8
enqueue hash chains             369.98       0.00%    12951           4

We don't use dbms_shared_pool.keep for some reasons not dependent on me.


-----Original Message-----
Sent: Wednesday, August 30, 2000 9:17 PM


There are some major performance problems with this instance, and it is probable
that your very poor log sync cost ratio is a secondary problem. For example, if
part of that 'latch free' wait time is due to contention for the redo allocation
latch, then that alone could explain the poor log sync cost ratio.


-----Original Message-----
Sent: Thursday, 31 August 2000 1:21


In my case log sync cost is pretty poor : near 9. That is, avg "log file sync"
time is much bigger than "log file parallel write". What would be your
suggestions of what to optimize or pay attention to. Oracle 8.1.6 under Sun
Solaris 2.6

log_buffer= 102400
db_block_buffers=25000
db_block_size=16384

Non-routine waits (from your script).
Don't pay attention to enqueue - it's not common situation.

enqueue                         60208791        11191.2250929368
latch free                      17156299        59.4967314821558
buffer busy waits               10260185        23.5222299405536
log buffer space                5290777         3508.47281167109
non-routine log file syncs      1362396         5.00663810938021
library cache pin               213185          737.664359861592
log file switch completion      42809           62.4948905109489
library cache load lock         836             24.5882352941176
library cache lock              478             36.7692307692308
row cache lock                  114             0.65142857142857