Tanel,

Did you observe better performance? By how much? Do please let us know!

>From what I read, _wait_for_sync when set to false means LGWR immediately
notifies user (foreground) processes that redo record writes are done (even
though they're not). When you say the parameter only affects LGWR, you need to
clarify what you mean by "affect"; it changes the notification (posting)
behavior of LGWR therefore changes the behavior of waiting processes (*when*
they stop waiting). Just semantics.

Yong Huang

--- Tanel Poder <[EMAIL PROTECTED]> wrote:
> Anjo,
> 
> I also thought it affects only lgwr sync, but Jonathan Lewis once told that
> it affects any disk writes...
> 
> If it affects only lgwr, then great, I can make Apps upgrades, which do
> really lots of DDLs and small transactions, quite much faster that way...
> 
> Thank you,
> Tanel.
> 
> 
> > _wait_for_sync basically meant that a session is waiting for the sync
> > of the
> > redo by the lgwr. Normally the redo log writer writes to disk and then
> > notifies the session that the transaction is completed. By setting
> > this to
> > false, you no longer wait for the redo to go to disk.
> > 
> > That has no impact on your situation.
> > 
> > Anjo.
> > 
> > ----- Original Message -----
> > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> > Sent: Wednesday, November 19, 2003 11:20 PM
> > query
> > 
> > 
> > > Hi!
> > >
> > > I've sometimes used setting _wait_for_syncúlse during Apps upgrade
> > > projects, to upgrade performance. (As long as your database doesn't
> > crash
> > > during the parameter is set to false, no problems should occur).
> > >
> > > I just started wondering, what would be the case if a parallel query
> > starts
> > > during someone is modifying data...
> > >
> > > As I understand, when doing parallel query:
> > > 1) the dirty blocks which are supposed to be read by PQ in direct
> > mode,
> > are
> > > flushed to disk
> > > 2) PQ reads the blocks in direct mode
> > >
> > > But when _wait_for_sync is set, the writes get acknowledged
> > immediately
> > (or
> > > acknowledgement is not waited for). Could this result in the
> > unlikely
> > > situation, that PQ issues the flush command to dirty buffers and
> > starts to
> > > read them, but actually reads the old images of the blocks, since it
> > thinks
> > > the write has already occurred?
> > >
> > > (actually, this doesn't touch only PQ, it's possible to have direct
> > reads
> > to
> > > PGA in serial mode too...)
> > >
> > > Tanel

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Yong Huang
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to