RE: Log Switches in RAC

From: hrishy <hrishys_at_yahoo.co.uk>
Date: Fri, 13 Nov 2009 06:25:12 +0000 (GMT)
Message-ID: <119207.95733.qm_at_web23707.mail.ird.yahoo.com>

Hi Gopal
 
So a revised edition of the RAC handbook covering 11gr2 is on the cards .  
regards
Hrishy

• On Fri, 13/11/09, Rajesh Rao <Rajesh.Rao_at_jpmchase.com> wrote:

From: Rajesh Rao <Rajesh.Rao_at_jpmchase.com> Subject: RE: Log Switches in RAC
To: "K Gopalakrishnan" <kaygopal_at_yahoo.com>, "yong321_at_yahoo.com" <yong321_at_yahoo.com>, "kaygopal_at_gmail.com" <kaygopal_at_gmail.com> Cc: "oracle-l_at_freelists.org" <oracle-l_at_freelists.org> Date: Friday, 13 November, 2009, 3:42

KG

Thank You. Thank You. Thank You.

I wrote a script to get ahead of the log switches .i.e. predict which ones gonna happen next when a log switch happens on the node running the batch and perform pre-mature log switches on them. Works like a charm so far. Been running with 3 times the load, and no impact to online nodes so far.

Thanks
Raj

-----Original Message-----
From: K Gopalakrishnan [mailto:kaygopal_at_yahoo.com] Sent: Wednesday, November 11, 2009 6:18 PM To: yong321_at_yahoo.com; kaygopal_at_gmail.com; Rajesh Rao Subject: Re: Log Switches in RAC

Yong, you are correct.It is a simple watch dog mechanism to keep the  threads current. Wequery the start SCN of  all the members during the log switch and compare with archive_change# in V$database (same kccdi structure from controlfile) and force archive the threads with their start_scn <force_scn. May be I can include a brief discussion when I review my RAC book..

-Gopal

• Original Message ---- From: Yong Huang <yong321_at_yahoo.com> To: kaygopal_at_gmail.com; Rajesh.Rao_at_jpmchase.com Cc: oracle-l_at_freelists.org Sent: Wed, 11 November, 2009 5:03:42 PM Subject: Re: Log Switches in RAC

> If any of the thread is not archived for longer duration
> and if the critical changes are recorded in that thread,
> you may not be able recover the database as the physiological
> logging requires all the changes from ALL the thread to make
> the recovery  complete

There is (or was?) the concept "force archive SCN". I know of two sources where this is talked about. Rama Velpuri's "Oracle(8) Backup and Recovery Handbook" and Lawrence To's "Archiving Tips and Hints". The latter can be found at
https://support.oracle.com/cgi-bin/cr/getfile.cgi?p_attid=75071.1:219081

"Threads are kept relatively current by forcing log switches or kicking idle instances to archive. For an open and enabled thread, a lock is used to kick an idle instance. For a closed and enabled thread, the ARCH process for an active instance will log switch and archive the closed
thread. A force archive SCN is maintained in the control file to implement this feature.

"OPS: The ARCH process scans the archive link list found in the control file and archives all inactive redo logs whose SCN is less than the force archive SCN. Oracle strives to archive any log that contain less than or equal to the force archive SCN. Generally, the log with the lowest SCN is archived first."

Yong Huang

     

--
http://www.freelists.org/webpage/oracle-l 

This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.†Ûiÿü0ÁúÞzX¬¶Ê+ƒün– {ú+iÉ^


      
--
http://www.freelists.org/webpage/oracle-l

Received on Fri Nov 13 2009 - 00:25:12 CST