Lgwr and cursor

Question

please i appreciate your help for these 2 questions:
1- can i add more lgwr process like dbwr ? if yes why if no why
2- regarding cursors: when a session issues a select statement ex:
select * from hr.employees
is the employees table blocks are in the buffer cache they are used otherwise the server process copy the blocks
from the data file into the buffer cache..is that right so far ?
lets say the same session is updating the employees records , are the same blocks moved to the shared pool to satisfy sharing
the same blocks with other session, and by then only these data blocks are called a cursor and moved to the shared pool and shared
by other sessions using cursor_sharing parameter setting
please clarification is really appreciated
regards

Answer 1

Maoro wrote:
1- can i add more lgwr process like dbwr ? if yes why if no why
If I remember correctly, there is a metalink note which does talk about adding more slaves to the LGWR. Its indeed correct that you can't add more processes of LGWR to the system. Reason , IMHO,is that LGWR doesn't need to scan a lot of the data. Normally , the redo log buffer is actually having a very tiny size as compared to the other caches that are there in the SGA. In addition to that, the algorithm of log buffer is pushing the data out from this buffer much fastly as compared to other caches, 3seconds is the time out even when there is no other even triggering LGWR to write. So , there is no need actually to go for more than one LGWR. ORacle has done couple of changes in the latches though , in order to to make the working of redo buffer better.
You may be not knowing but there are other enhancements done in the redo and undo management to make its working better. There is a concept of Private Redo and In Memory Undo from 10g onwards, targeted to make the things less contending for the standard caches.
2- regarding cursors: when a session issues a select statement ex:select * from hr.employees
is the employees table blocks are in the buffer cache they are used otherwise the server process copy the blocks
from the data file into the buffer cache..is that right so far ?
lets say the same session is updating the employees records , are the same blocks moved to the shared pool to satisfy sharing
the same blocks with other session, and by then only these data blocks are called a cursor and moved to the shared pool and shared
by other sessions using cursor_sharing parameter setting
>
1s statement is correct.
Again, this is correct to say that buffer cache's data is not going to be in the shared pool and that' s how the things have been so far.I have given a link above, read that link which does show that Oracle has done some changes probably and now, they may use shared pool's buffers too for the data buffers. I haven't done the research for it but the note is from Tanel Poder and if he says something, its not just like that.
If you have some other questions about how things work, feel free to post.
HTH
Aman....