Thank you Scott for supplying a well-written summary of SCN usage within OPS nodes.
I was interested in "If the gap in the log sequence gets to big Oracle will force the idle node to do log switches " I was not aware of that and whilst I believe you, I cannot see what the reason behind it is. Have you any thoughts on why it is set like that I suppose it is quite easy to test if you happen to have a OPS development setup handy (which I do not at the moment) John -----Original Message----- Sent: 02 July 2002 19:44 To: Multiple recipients of list ORACLE-L Fawzia, What are you querying to get the SCN information. I would also be curious where you read about the recovery issues in OPS environment? Oracle maintains what is called a snapshot SCN and global SCN. The snapshot SCN is usually maintained in the SGA and the global SCN is maintained by the DLM. All transactions committed in an OPS environment use the global SCN and that SCN is always incrementing even in if both instances are idle. In an OPS environment it is possible for multiple transactions on different nodes to commit with the same SCN but each transaction will commit with an SCN that is greater whether these transactions are on the same node or different nodes. The bottom line is that Oracle basically treats SCN's with committed transactions the same whether it is a single instance or OPS. The snapshot SCN is used for queries and the snapshot SCN could be older than current or global SCN. This SCN only effects queries not DML. The only issue here is using this snapshot SCN could give read consistency on transactions that where committed on the on the other node. an example Time 10:00:00 - Node2 issues DML and commits updates deptno from 10 to 11 committed with current SCN 1000, current SCN is now incremented to 1001 Time 10:00:01 - Node1 issues a select on deptno and sees 10 (should see 11 because the transaction was commmited) because the snapshot SCN is 998 and the transaction was committed with newer SCN we must perform a read consistent read. PMON is the process that synchs current or global SCN with the snapshot SCN and PMON usually does this every 3 seconds so if you issue the query Time 10:00:05 (5 seconds after the commit) - Node1 issues the select on deptno and now sees 11. This is because PMON sync-ed up the snapshot SCN with the current or global SCN and now my SCN for my query is newer than the SCN the transaction you committed with so there is no need to perform a CR you can just use the current version. The above issue is really only a problem is a system if you have a lot of DML on 1 node and a lot of selects on the other node. It this is an issue you can set MAX_COMMIT_PROPAGATION_DELAY=0 and this will force the queries to always use the current or global SCN and now you should see the committed data as soon as it is committed because both the DML and queries are use the current or global SCN. I find odd that you have SCN of 500 and 2000. The way Oracle maintains SCN's in an OPS environment shouldn't allow for this large of a gap in SCN's. This looks more like log sequence numbers not SCN's. If these are indeed log sequence then this gap is not an issue. Recovery is based more on SCN's not log sequence numbers. If the gap in the log sequence gets to big Oracle will force the idle node to do log switches and if you are archiving you will see archive logs 1 OS block in size. When Oracle does this you should a KK "Redo log Kick" lock being allocated. Hope this helps, Scott --- "Malik, Fawzia" <[EMAIL PROTECTED]> wrote: > > > Hi gurus, > > I have a query..Basically we have an OPS set up here > (8.0.6) and I have > noticed that the scn on node A is 500 and the scn on > node B is 2000. I am > concerned about this w.r.t recovery- surely this > would be an issue ??I > logged a call with oracle and they said it wasnt an > issue, but then I read > in a document that it WAS an issue and could > potentially lose everything > between 500 abd 2000..and that the workaround would > be to add more logs to A > or to modify the check point interval.... > > Please can you advise?? > > Rgds > > Fawzia > > > ********************************************************************** > Information in this email is confidential and may be > privileged. > It is intended for the addressee only. If you have > received it in error, > please notify the sender immediately and delete it > from your system. > You should not otherwise copy it, retransmit it or > use or disclose its > contents to anyone. > Thank you for your co-operation. > ********************************************************************** > > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.com > -- > Author: Malik, Fawzia > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: > (858) 538-5051 > San Diego, California -- Public Internet > access / Mailing Lists > -------------------------------------------------------------------- > 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). __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Scott INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
