Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
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. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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).
Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
Well, some disk writes need to wait for the LGWR to flush the corresponding redo to disk. So now you can have a situation that the blocks that are dirty are on disk (without a commited transaction) but the redo is not yet. So if you crash in that period, you can't recover. Anjo. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 20, 2003 2:59 PM parallel 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. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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).
Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
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).
Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
The message I posted a minute ago may be wrong in one aspect. 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. Looks like it doesn't change the LGWR notification behavior. It just suppresses foreground processes' waiting for LGWR to write redo records. Yong Huang __ 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).
Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
I think my understanding was wrong. _wait_for_sync actually only changes the behavior of foreground processes. When set to false, they don't wait for LGWR to write redo records to disk; instead they continue to do their work as if log file sync already finished. It *does not* change any behavior of LGWR, notification or not. Correct me if I'm wrong again. I'm still interested in Tanel's benchmark, though. Only that is scientific. Yong Huang --- Yong Huang [EMAIL PROTECTED], i.e. myself, wrote a few minutes ago: 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. __ 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).
Re: Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
:) I admit, that I don't know either, which processes are affected by this parameter. If foreground ones are, that should mean that after posting lgwr, they won't wait on semaphore and continue their work. If it affects lgwr, it means that lgwr posts the waiting processes immediately back before writing to disk. I'm too lazy now, but it can probably be figured out by tracing semop() syscalls... or maybe Steve Adams happens to read this post :) About scientific test results, the results I posted earlier, they were done exactly on same hardware, with same dataset and from same starting point. Enough scientific for me. Tanel. I think my understanding was wrong. _wait_for_sync actually only changes the behavior of foreground processes. When set to false, they don't wait for LGWR to write redo records to disk; instead they continue to do their work as if log file sync already finished. It *does not* change any behavior of LGWR, notification or not. Correct me if I'm wrong again. I'm still interested in Tanel's benchmark, though. Only that is scientific. Yong Huang --- Yong Huang [EMAIL PROTECTED], i.e. myself, wrote a few minutes ago: 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. __ 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).
Re: Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
Hi! Yup, I was bold enough to use this parameter during production upgrade only because it worked well in several tests and simulations. Cheers, Tanel. Well, some disk writes need to wait for the LGWR to flush the corresponding redo to disk. So now you can have a situation that the blocks that are dirty are on disk (without a commited transaction) but the redo is not yet. So if you crash in that period, you can't recover. Anjo. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 20, 2003 2:59 PM parallel 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. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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).
Re: Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
Tanel, Did you observe better performance? By how much? Do please let us know! Oracle Apps upgrade between major releases involves running hundreds of thousands scripts in bigger cases. Some of there scripts execute bigger transactions, but majority execute lots of small transactions and DDLs (even commenting on tables). And their script template has an additional commit in end of every script (in later db versions it is not that big problem in IO sense, because no commit really executed if no transactions are started in session). So, when I ran about 3 scripts in 8 hours before disabling wait for sync, then after setting it, the scripts ran in about 3-4 hours . I started searching for this kind of parameter when saw a lot of log file sync waits during upgrading. And all of this was even before than I discovered _disable_logging ;) 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. As you just wrote - this parameter affects (changes behaviour) of LGWR, other processes work as usual, they wake up when theyre posted. Tanel. 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).
Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
The infamous event log file syncwill basically disapear. So you can see what this does to the system, by looking v$system_event to see how much log file sync there is. Anjo. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 20, 2003 4:10 PM parallel I think my understanding was wrong. _wait_for_sync actually only changes the behavior of foreground processes. When set to false, they don't wait for LGWR to write redo records to disk; instead they continue to do their work as if log file sync already finished. It *does not* change any behavior of LGWR, notification or not. Correct me if I'm wrong again. I'm still interested in Tanel's benchmark, though. Only that is scientific. Yong Huang --- Yong Huang [EMAIL PROTECTED], i.e. myself, wrote a few minutes ago: 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. __ 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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).
Re: Re: Re: _wait_for_sync , dirty buffer flushing and direct reads in parallel
The foreground process is affected. Instead of waiting for the LGWR, it will return right away. Anjo. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 20, 2003 4:24 PM in parallel :) I admit, that I don't know either, which processes are affected by this parameter. If foreground ones are, that should mean that after posting lgwr, they won't wait on semaphore and continue their work. If it affects lgwr, it means that lgwr posts the waiting processes immediately back before writing to disk. I'm too lazy now, but it can probably be figured out by tracing semop() syscalls... or maybe Steve Adams happens to read this post :) About scientific test results, the results I posted earlier, they were done exactly on same hardware, with same dataset and from same starting point. Enough scientific for me. Tanel. I think my understanding was wrong. _wait_for_sync actually only changes the behavior of foreground processes. When set to false, they don't wait for LGWR to write redo records to disk; instead they continue to do their work as if log file sync already finished. It *does not* change any behavior of LGWR, notification or not. Correct me if I'm wrong again. I'm still interested in Tanel's benchmark, though. Only that is scientific. Yong Huang --- Yong Huang [EMAIL PROTECTED], i.e. myself, wrote a few minutes ago: 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. __ 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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).
