Re: Very high 'log file sync' wait time with no 'log file parallel write' wait time

mccmx_at_hotmail.com wrote:
> > "For tables containing LOBs or LONG, BFILE, REF, ROWID,UROWID, or
> > TIMESTAMP columns, rows are inserted individually. The size of the
> > buffer must be large enough to contain the entire row, except for LOB
> > and LONG columns. If the buffer cannot hold the longest row in a table,
> > Import attempts to allocate a larger buffer."
> >
> > Does your table have any of these datatypes?
>
> No,
>
> SQL> select distinct data_type from user_tab_columns where table_name =
>
> 'PS_TL_RPTD_TIME';
>
> DATA_TYPE
> --------------------------------------------------------------------------------
>
> NUMBER
> DATE
> VARCHAR2
There is also some datatype missing from the docs, but none of those (unless some new silly bug confuses date with timestamp...).

>From metalink Note:223117.1:

"If 'log file parallel write' is significantly different i.e smaller,   then the delay is caused by the other parts of the Redo Logging mechanism
  that occur during a COMMIT/ROLLBACK (and are not I/O-related).   Sometimes there will be latch contention on redo latches, evidenced by
  'latch free' or 'LGWR wait for redo copy' wait events. "

Have you tried taking out the commit parameter? If there's something screwy about the array processing that would make a noticeable difference.

Also, from Note:125269.1:

"Over time (since database startup), if you see increasing values for:

     select * from v$sysstat where name like 'redo%space%';

   your redo log buffer is too small."

In other words, you probably don't have an I/O problem, but some sort of memory or latch contention from all the commits.

jg

-- 
@home.com is bogus.
http://www.spamhaus.org/news.lasso?article=161