精华内容
下载资源
问答
  • POINT Guard IO Safety Modules
  • Guard

    2017-10-30 23:03:13
    A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • BPDU Guard:防止将交换设备意外连接到启用PortFast的端口。 将交换机连接到启用了PortFast的端口可能会导致第2层环路或拓扑更改。 BPDU filtering:限制交换机向Access端口发送不必要的BPDU。 Root Guard: 防止连接在...

    BPDU Guard:防止将交换设备意外连接到启用PortFast的端口。 将交换机连接到启用了PortFast的端口可能会导致第2层环路或拓扑更改。

    BPDU filtering:限制交换机向Access端口发送不必要的BPDU。

    Root Guard: 防止连接在配置为Access端口上的交换机成为根交换机。

    Loop Guard:Loop Guard STP功能通过防止桥接环路来提高第2层网络的稳定性。

    UDLD: UDLD检测并禁用单向l链路。

    1、BPDU防护(BPDU Guard)
    当配置为STP PortFast的接口收到BPDU时,BPDU Guard会将其为置于err-disable状态。 BPDU Guard禁用接口作为预防步骤,以避免潜在的危险桥接环。 BPDU保护功能用于保护生成树域免受外部影响。 BPDU Guard默认情况下处于禁用状态,但建议已启用portfast功能的所有端口使用BPDU Guard。这样可以防止将错误信息注入禁用了生成树的端口上的生成树域中。

    当端口仅连接了主机设备时,我们将启用portfast,这将加快端口初始化过程并使端口立即进入转发状态。如果没有绕过STP并且端口进入了侦听和学习状态,这可以消除30秒钟的延迟。因为主机是工作站,所以它不发送BPDU,因此在这样的端口上禁用生成树不是问题。

    如果我们删除了此端口的此终端主机并连接了交换机。这个新的交换机将开始生成BPDU,并且可以像网络的根网桥一样接管,或者如果它的另一条链路连接到网络的另一部分,则可能在我们的网络中引起环路。

    因此,BPDU Guard将提供对无效配置或未经授权的交换机到我们的网络的安全响应,因为管理员必须在修复无效的配置或从网络中删除未经授权的交换机后手动重新启用禁用了错误的接口。还可以设置超时间隔,在此间隔之后,交换机将自动尝试重新启用接口。但是,如果无效的配置或交换机仍然存在,则交换机会再次错误禁用接口。

     

     

     开启和关闭BPDU Guard使用如下命令:

    switch(config-if)#spanning-tree bpduguard enable
    switch(config)#[no] spanning-tree portfast edge bpduguard default

    确认是否开启:

    switch#show spanning-tree summary totals                                                                         
    Root bridge for: none. PortFast BPDU Guard is enabled UplinkFast is disabled BackboneFast is disabled Default pathcost method used is short

    2、BPDU Filter

    在端口上启用PortFast时,该端口将发出BPDU,并将接受并处理收到的BPDU。 BPDU Guard 功能可防止端口接收任何BPDU,但不会阻止其发送它们。如果收到任何BPDU,则该端口将被禁用。 BPDU Filter功能通过阻止选定端口发送或接收任何BPDU来有效地禁用其上的STP。

    BPDU Filter支持阻止交换机在启用PortFast的接口上发送BPDU的功能。为PortFast功能配置的端口通常连接到主机设备。主机不参与STP,因此会丢弃收到的BPDU。结果,BPDU Filter防止不必要的BPDU被发送到主机设备。

    全局启用BPDU过滤会产生以下影响;

    • 它会影响在所有PortFast的端口。
    • 如果接口收到BPDU,则该端口将失去其PortFast状态,禁用BPDU Filter,并且STP会在该端口上发送和接收BPDU,就像在交换机上的任何其他STP端口一样。
    • 启动后,端口将传输十个BPDU。如果此端口在此期间收到任何BPDU,则禁用PortFast和PortFast BPDU Filter。

    在单个端口上启用BPDU过滤后,会产生以下影响:

    • 它忽略所有收到的BPDU。
    • 它不发送BPDU。

    如果在与BPDU Filter相同的接口上启用BPDU Guard,则BPDU Guard无效,因为BPDU Filter优先于BPDU Guard。

     

     

     如何配置开启BPDU Filter,全局和接口下

    switch(config)#spanning-tree portfast bpdufilter default
    switch(config-if)#spanning-tree bpdufilter enable

    如何查看BPDU Filter是开启:

    switch#show spanning-tree summary
    Switch is in pvst mode
    Root bridge for: none
    Extended system ID is enabled
    Portfast Default is disabled
    PortFast BPDU Guard Default is disabled
    Portfast BPDU Filter Default is enabled
    switch# show spanning-tree interface fastEthernet 0/1 detail
    Port 196 (FastEthernet0/1) of VLAN0010 is forwarding
    Port path cost 1000, Port priority 160, Port Identifier
    160.196.
    Designated root has priority 32768, address 00d0.00b8.140a
    Designated bridge has priority 32768, address 00d0.00b8.140a
    Designated port id is 160.196, designated path cost 0
    Timers:message age 0, forward delay 0, hold 0
    Number of transitions to forwarding state:1
    The port is in the portfast mode by portfast trunk
    configuration
    Link type is point-to-point by default
    Bpdu filter is enabled
    BPDU:sent 0, received 0

    3、Root Guard

    Root Guard在避免网络异常期间的第2层环路方面很有用。根防护功能强制接口成为指定端口,以防止周围的交换机成为根交换机。换句话说,Root Guard提供了一种在网络中强制根桥放置的方法。根防护功能可防止指定端口成为根端口。如果Root Guard功能的端口接收到更高优先级的BPDU,会将其变换为到root-inconsistent状态(实际上等于侦听listening 状态),从而保持当前的根网桥状态。

    switch(config-if)#spanning-tree guard root
    
    switch# show spanning-tree inconsistentports
    Name Interface Inconsistency
    ——————– ———————- ——————
    VLAN0001 FastEthernet0/1 Port Type Inconsistent
    VLAN0001 FastEthernet0/2 Port Type Inconsistent
    VLAN0002 FastEthernet0/1 Port Type Inconsistent
    VLAN0002 FastEthernet0/2 Port Type Inconsistent

     

    根防护功能可防止端口成为根端口,从而确保该端口始终是指定端口。与其他STP增强功能(也可以在全局范围内启用)不同,必须在不应出现根网桥的所有端口上手动启用Root Guard。因此,在LAN中设计和实现STP时,保证确定性的拓扑非常重要。在端口上启用Root Guard功能后,交换机不会使该端口成为STP根端口。该端口保留为STP指定的端口。此外,如果在端口上收到更好的BPDU,则Root Guard会禁用(err-disable)端口,而不是处理BPDU。如果未经授权的设备开始发送具有更好网桥ID的BPDU,则正常的STP进程会将新交换机选为根交换机。如此通过禁用端口,可以保护网络拓扑。

    当前的设计建议是在所有Access端口上启用Root Guard,以便不通过这些端口建立根网桥。端口停止接收上级BPDU后,该端口将再次解除阻塞,并经历listening 和learning的常规STP过渡,并最终进入forwarding 状态。恢复是自动的;无需干预。

     

     

     开启Root Guard:

    switch(config-if)#spanning-tree guard root
    
    switch# show spanning-tree inconsistentports
    Name Interface Inconsistency
    ——————– ———————- ——————
    VLAN0001 FastEthernet0/1 Port Type Inconsistent
    VLAN0001 FastEthernet0/2 Port Type Inconsistent
    VLAN0002 FastEthernet0/1 Port Type Inconsistent
    VLAN0002 FastEthernet0/2 Port Type Inconsistent

    4、Loop Guard

    Loop Guard提供了针对第2层转发环路(STP环路)的附加保护。当冗余拓扑中的STP阻塞端口错误地转换为转发状态时,就会发生桥接环路。这通常是由于物理冗余拓扑的端口之一(不一定是STP阻止端口)已停止接收STP BPDU所致。在STP中,取决于端口角色,交换机依赖于BPDU的连续接收或传输。 (指定端口发送BPDU,而非指定端口接收BPDU。)
    如果交换机链路已建立并且未收到BPDU(由于单向链路),则交换机将认为可以安全地建立此链路,并且端口将转换为转发状态,并开始中继已接收的BPUD。如果将交换机连接到链路的另一端,则会有效地产生生成树环路。

    借助Loop Guard功能,交换机在过渡到STP转发状态之前会进行其他检查。如果启用了Loop Guard功能的交换机停止在非指定端口上接收BPDU,则交换机会将端口置于STP loop-inconsistent的阻塞状态,而不是通过侦听,学习和转发状态。如果交换机在STP loop-inconsistent的状态下在端口上收到BPDU,则端口会根据收到的BPDU在STP状态下进行转换。结果,恢复是自动的,不需要手动干预。

    实施Loop Guard时,应了解以下实施准则;

    • 无法在启用了Root Guard的交换机上启用Loop Guard
    • Loop Guard不会影响Uplink Fast或Backbone Fast操作
    • 必须仅在点对点链接上启用Loop Guard
    • 生成树计时器不影响Loop Guard操作
    • Loop Guard实际上无法检测到单向链接
    • 无法在Portfast或动态VLAN端口上启用Loop Guar

       

    您可以按端口配置Loop Guard功能,尽管该功能可以按VLAN阻止不一致的端口。 例如,在中继端口上,如果仅针对一个特定的VLAN未收到BPDU,则交换机仅阻止该VLAN(即,将该VLAN的端口移至环路不一致的STP状态)。 对于以太通道接口,对于不接收BPDU的特定VLAN,属于该通道组的所有端口的通道状态将进入不一致状态。 在所有非指定的端口上启用环路保护功能,而不仅仅是阻止端口。 更准确地说,对于活动拓扑的所有可能组合,应在根端口和备用端口上启用Loop Guard。 但是,在启用Loop Guard之前,请考虑所有可能的故障转移方案。

     

     

    配置Loop Guard

    全局开启:

     

    Switch(config)# spanning-tree loopguard default
    Switch(config)# end 
    Switch# show spanning tree interface 4/4 detail
    
    
    Switch# show spanning-tree interface fastethernet 4/4 detail 
     Port 196 (FastEthernet4/4) of VLAN0010 is forwarding 
       Port path cost 1000, Port priority 160, Port Identifier 160.196.
       Designated root has priority 32768, address 00d0.00b8.140a
       Designated bridge has priority 32768, address 00d0.00b8.140a
       Designated port id is 160.196, designated path cost 0
       Timers:message age 0, forward delay 0, hold 0
       Number of transitions to forwarding state:1
       The port is in the portfast mode by portfast trunk configuration
       Link type is point-to-point by default
       Bpdu filter is enabled
       Loop guard is enabled by default on the port
       BPDU:sent 0, received 0

     

    接口下配置:

    Switch(config)# interface fastEthernet 4/4
    Switch(config-if)# spanning-tree guard loop
    Switch(config-if)# ^Z
    
    Switch# show spanning-tree interface fastEthernet 4/4 detail 
     Port 196 (FastEthernet4/4) of VLAN0010 is forwarding 
       Port path cost 1000, Port priority 160, Port Identifier 160.196.
       Designated root has priority 32768, address 00d0.00b8.140a
       Designated bridge has priority 32768, address 00d0.00b8.140a
       Designated port id is 160.196, designated path cost 0
       Timers:message age 0, forward delay 0, hold 0
       Number of transitions to forwarding state:1
       The port is in the portfast mode by portfast trunk configuration
       Link type is point-to-point by default
       Bpdu filter is enabled
       Loop guard is enabled on the port
       BPDU:sent 0, received 0
    Switch#

     

     

     4、UDLD

    当仅在一个方向上在邻居之间传输流量时,会发生单向链接。单向链路检测是第2层协议。 UDLD执行第1层机制无法执行的任务,例如自动协商。启用UDLD和自动协商后,第1层和第2层检测将一起工作,以防止物理和逻辑单向连接以及其他协议的故障。单向链接可能会导致生成树拓扑循环。 UDLD使设备能够检测到何时存在单向链路并关闭受影响的接口。 UDLD在光纤端口上很有用,可防止网络问题导致配线架接线错误,从而导致链路处于启动/启动状态,但BPDU丢失。

    启用UDLD后,交换机会定期向其邻居发送UDLD协议数据包,并期望在预定计时器到期之前回送这些数据包。如果计时器到期,则交换机确定链路是单向的,并关闭端口。如果在超时间隔(45秒)内未收到消息,则端口被禁用。每隔默认时间间隔(15秒)发送一次消息。

    检测单向链路和禁用端口所需的45秒时间少于STP将端口转换为转发状态所花费的50秒时间,该时间基于最大年龄的20秒+听力和学习的30秒。这样可以避免由于缺少接收到的BPDU而导致STP将端口转换为转发状态而导致的环路。

    UDLD是在相邻交换机之间启用的第2层协议。它使用MAC 01-00-0c-cc-cc-cc和子网类型为0x0111的子网访问协议(SNAP)高级数据链路控制(HDLC)协议。 UDLD数据包包含有关发送端口的设备ID和端口ID以及邻居的设备ID和端口ID的信息。启用了UDLD的邻居设备会发送相同的Hello消息。如果双方的设备都收到彼此的UDLD数据包,则该链接为双向。如果端口在特定的持续时间(超时间隔)内未在传入的UDLD数据包中看到其自己的设备和端口ID,则该链接被视为单向且被禁用。

    由于以下原因,此UDLD echo算法允许单向链路检测:

    • 当链接两端都连接好时; 但是,数据包仅由一侧接收
    • 当接收和发送光纤未连接到远程侧的同一端口时

    UDLD框架由以下字段组成:

    • Device ID – This field contains the MAC address of the sending device.
    • Port ID – This field contains the module and port number of the sending device.
    • Echo – This field contains the module and port pair known by the sending device.
    • Message Interval – This field contains the transmit interval of the sending device.
    • Timeout Interval – This field contains the timeout interval of the sending device.
    • Device Name – This field contains the CDP Device ID string of the sending device.
    • Sequence Number – This field contains the number used to validate discovery packets.
    • Reserved – These fields are reserved for future use.

    一旦UDLD检测到单向链路,相应的端口将被禁用并保持禁用状态,直到手动重新启用它,或直到errdisable超时到期(如果已配置)为止。 UDLD可以在normal or aggressive下运行。

    在normal模式下,如果UDLD停止从其直接连接的邻居接收UDLD消息,则仅将启用UDLD的端口更改为undetermined 状态。 aggressive模式UDLD是UDLD的一种变体,当端口停止接收UDLD数据包时,UDLD会尝试与邻居重新建立连接。 重试八次失败后,端口状态将变为err-disable状态,从而有效地禁用了端口。

    在UDLD normal模式下,当检测到单向链接条件时,允许端口继续工作。 UDLD仅将端口标记为不确定状态并生成系统日志消息。 换句话说,在正常模式下,UDLD不会采取任何操作,并且允许端口根据其生成树状态继续运行。

    在点对点链接上配置了UDLD aggressive模式。 在UDLD邻居停止从其相邻对等方接收UDLD更新之后,此模式开始起作用。 在主动模式下,本地设备将尝试重新建立UDLD连接八次。 如果交换机无法在此时间内重新建立连接,它将禁用端口。

    aggressive模式是配置UDLD的首选方法。 通过阻止这种单向通信,UDLD在生成树网络中很有用。 当由于硬件故障导致单向通信而应关闭链接时,请使用UDLD。 在EtherChannel捆绑软件中,UDLD仅关闭发生故障的物理链路。 当端口卡住(一侧既不发送也不接收;但是,链路在两端都up)或链路在一侧up而在另一侧down 时,UDLD主动模式增加了额外的检测。 仅在光纤连接上使用,因为铜缆端口通常不易受到此类问题的影响,因为铜缆端口使用以太网链路脉冲来监视链路。

    要在将端口置于错误禁用状态后将其up起来,在错误纠正之后,shu/no shu该受影响的接口即可。

     

    针对全局或单个接口开启UDLD

    针对接口:

    Switch(config-if)# udld enable [aggressive]

    全局(为所有接口开启):

    Switch(config)# udld { enable | aggressive }

    查看:

    SwitchA#show udld gigabitEthernet 0/1
    Interface Gi0/1
    —
    Port enable administrative configuration setting: Enabled / in aggressive mode
    Port enable operational state: Enabled / in aggressive mode
    Current bidirectional state: Bidirectional
    Current operational state: Advertisement – Single neighbor detected
    Message interval: 15
    Time out interval: 5
    Entry 1
    —
    Expiration time: 38
    Device ID: 1
    Current neighbor state: Bidirectional
    Device name: FOX01590RW1
    Port ID: Gi1/1
    Neighbor echo 1 device: FOX0872A001
    Neighbor echo 1 port: Gi0/1
    Message interval: 15
    Time out interval: 5
    CDP Device name: SwitchB

    比较Aggressive Mode UDLD和Loop Guard。

    Loop Guard和主动模式UDLD的功能重叠,因为它们都可以防止由单向链接引起的STP故障。 但是,这两个功能在解决问题的方法和功能上是不同的。

     

     主动模式UDLD与Loop Guard之间最明显的区别在于STP。主动模式UDLD无法检测到由未发送BPDU的指定交换机中的软件问题引起的故障。攻击性模式UDLD在检测EtherChannel上的单向链路方面具有更强大的功能。 Loop Guard通过将EtherChannel设置为VLAN或所有VLAN的环路不一致状态来阻止EtherChannel的所有接口发生故障,而激进模式UDLD会禁用出现问题的单个端口。此外,主动模式UDLD不依赖于STP,因此它也支持第3层链接。 Loop Guard不支持在交换机启动时单向的共享链接或接口。如果端口在交换机启动时是单向的,则该端口将永远不会接收BPDU并成为指定端口。 Loop Guard不支持此方案,因为该行为与正常的STP操作无法区分。积极模式UDLD确实提供了针对此类故障情况的保护。

    同时启用主动模式UDLD和Loop Guard,可提供最高级别的保护,以防止多层交换网络中的桥接环路和黑洞。

    Refer to:http://ericleahy.com/index.php/bpdu-guard-bpdu-filter-root-guard-loop-guard-udld/

    展开全文
  • guard let anyObjectType: AnyClass = NSClassFromString(namespace + "." + "\(string)") else { return nil } let vcType = anyObjectType as! UIViewController.Type let ...
  • Guard 的写法

    2020-02-07 21:49:11
    A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • ACE守卫Guard类属

    千次阅读 2014-03-21 17:19:08
    ACE中的守卫类是一种模板,它通过所需锁定机制的类型来参数化。  守卫类的对象定义一个代码块,在其上获取一个锁,... ACE_Guard,ACE_Read_Guard,ACE_Write_Guard。 #include "ace/Synch.h" ///sleep #include "a

           ACE中的守卫类是一种模板,它通过所需锁定机制的类型来参数化。

           守卫类的对象定义一个代码块,在其上获取一个锁,在退出次代码块时,锁被自动释放(对象的构造器获取锁,析构器释放锁)。

           ACE_Guard,ACE_Read_Guard,ACE_Write_Guard。

    #include "ace/Synch.h"         ///sleep
    #include "ace/Thread.h"
    #include "ace/Guard_T.h"
    #include "ace/Log_Msg.h"    
    #include "ace/OS_NS_stdio.h"   ///ACE_OS::printf  
    
    int number=10;
    
    class args
    {
    public:
    	args():mutex_() {}
    	ACE_Thread_Mutex mutex_;
    };
    
    static void* worker(void *arguments)
    {
    	args *arg=(args*)arguments;
    	//ACE_Thread_Mutex mutex_=*((ACE_Thread_Mutex*)arguments);  error
    
    	for(;;)
    	{
    		ACE_Guard<ACE_Thread_Mutex> guard(arg->mutex_);
    		//{
    			//this is our critical section
    			if(number>0)
    			{
    				ACE_OS::sleep(1);
    				number--;
    				ACE_OS::printf("Number: %d \n",number); 
    			}
    			else
    				break;
    		//}  //end critical section
    	}
    	return 0;
    }
    
    int main(int argc, char *argv[])
    {
    	if(argc<2)  
    	{  
    		ACE_OS::printf("Usage: %s <number_of_threads> <num_of_iterations>\n",argv[0]);  
    		ACE_OS::exit(1);  
    	}  
      
    	args arg;  
    	//setup the arguments  
    	int n_threads= ACE_OS::atoi(argv[1]);  
    
    	ACE_thread_t *threadID=new ACE_thread_t[n_threads+1];          ///DWORD  
    	ACE_hthread_t *threadHandles=new ACE_hthread_t[n_threads+1];   ///HANDLE  
    	if(ACE_Thread::spawn_n(threadID,    id's for each of the threads  
    		n_threads,   number of threads to spawn  
    		(ACE_THR_FUNC)worker, ///entry point for new thread  
    		&arg,        args to worker  
    		THR_JOINABLE | THR_NEW_LWP,  //flags  
    		ACE_DEFAULT_THREAD_PRIORITY,  
    		0,0,threadHandles)==-1)  
    	{  
    		ACE_DEBUG((LM_DEBUG,"Error in spawning thread\n"));  
    	}  
    	for(int i=0; i<n_threads; i++)  
    		ACE_Thread::join(threadHandles[i]); 
    	return 0;
    }


    展开全文
  • Guard 的设计的问题

    2020-01-07 00:55:26
    A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • Guard 的计算和实现

    2019-12-27 22:36:18
    A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • Guard 程序怎么编的

    2019-11-19 17:38:11
    A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • <div><p>When using Shoelace with React I am getting an error where the popover is undefined at the point that it is being destroyed. <p>This PR adds a guard to prevent this error. <p>Stack trace for ...
  • 10.2 Data Guard Physical Standby Switchover [ID 751600.1] 修改时间 15-DEC-2009 类型 REFERENCE 状态 PUBLISHED In t...
    10.2 Data Guard Physical Standby Switchover [ID 751600.1]

    修改时间 15-DEC-2009 类型 REFERENCE 状态 PUBLISHED

    In this Document
    Purpose
    10.2 Data Guard Physical Standby Switchover
    1.0 Prerequisites / Preparation
    2.0 Pre-Switchover Checks
    3.0 Switchover
    4.0 Post-Switchover Steps
    5.0 Create a Guaranteed Restore Point on Each Switchover Database
    6. References


    Applies to:

    Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4
    Information in this document applies to any platform.

    Purpose

    This note is intended as an accessory to the following resources:

    The goal of this document is be used as a basis to in developing your own robust switchover procedure.

    Oracle strongly recommends you apply the latest patchset/bundle patch for your version prior to proceeding.

    10.2 Data Guard Physical Standby Switchover

    1.0 Prerequisites / Preparation

    These are items that should only have to be done once during configuration and setup.

    1.1. Apply Latest Patch Bundle

    • Review the Document 466181.1 "10g Upgrade Companion", and make sure to check the “Patches Recommended” tab.
    • See Document 756671.1 for the latest available patches or patchset updates.
    1.2. Setup Service Relocation for a Local Standby (optional)

    See Data Guard Switchover and Failover MAA paper.

    1.3. Review the MAA Best Practice Papers

    See the References section.

    1.4. Review MAA Data Guard Best Practices

    In the 10g High Availability Best Practices 10g Release 2 (10.2) guide see 2.4 Configuring Oracle Database 10g with Data Guard

    1.5. Verify the Setup
    1.5.1. With Broker

    1. Review Prerequisites for First Use
    2. Enable Broker to restart instances

    To enable DGMGRL to restart instances during the course of broker operations, a service with a specific name must be statically registered with the listener of each instance. The value for the GLOBAL_DBNAME attribute must be set to a concatenation of db_unique_name_DGMGRL.db_domain. For example, in the LISTENER.ORA file:
    LISTENER = (DESCRIPTION =
    (ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=)
    (PORT=))))
    SID_LIST_LISTENER=(SID_LIST=(SID_DESC=
    (SID_NAME=)
    (GLOBAL_DBNAME=_DGMGRL.db_domain)
    (ORACLE_HOME=)))

    1.5.2. Without Broker

    Follow the steps at Verify the Physical Standby Database Is Performing Properly
    1.6. Understand and test fallback options

    See 11.1 guide, Failed Switchovers to Physical Standby Databases. Still applies to 10.2 as well.

    Check DG Admin troubleshooting guide, Problems Switching Over to a Standby Database.

    2.0 Pre-Switchover Checks

    These steps should be completed before the switchover planned maintenance window begins. Recommendation is that these are done a couple days in advance.

    2.1. Verify Configuration Health
    2.1.1 With Broker
    2.1.1.1 Verify Data Guard Environment Health

    CLI - see Monitoring a Data Guard Configuration

    GUI - see " Verifying a Broker Configuration" The broker health check performs the following:

    Shows the current data protection mode setting, including the current redo transport service settings for each database and whether or not the standby redo log files are configured properly. If standby redo log files are needed for any database, the Verify results will allow you to automatically configure them.
    • Validates each database for the current status.
    • Performs a log switch on the primary database and then verifies that the log file was applied on each standby database.
    • Shows the results of the Verify operation, including errors, if any. The Verify operation completes successfully if there are no errors and an online redo log file was successfully applied to at least one standby database.
    • Shows any databases or RAC instances that are not discovered. Undiscovered databases and instances could prevent a failover or switchover from completing successfully.
    • Detects inconsistencies between database properties and their corresponding values in the database itself. It also provides a mechanism for resolving these inconsistencies.
    2.1.1.2. Cancel apply delay for the target standby using CLI or GUI

    Note: if flashback database is not enabled as part of normal operations then canceling any apply delay should be done just prior to a switchover to maintain standby delay protection for any possible primary database issues.

    On the standby Capture the current value

    DGMGRL> SHOW DATABASE DELAYMINS;

    On the standby turn off any delay

    CLI – DGMGRL> EDIT DATABASE ‘’ SET PROPERTY 'DELAYMINS'='0';

    GUI – See Changing the Properties of a Database
    2.1.2. Without Broker
    2.1.2.1. Verify Managed Recovery is Running (non-broker) on the standby

    SQL> SELECT PROCESS
    FROM V$MANAGED_STANDBY
    WHERE PROCESS LIKE 'MRP%';

    2.1.2.2. Cancel apply delay for the target standby using SQL

    On the target physical standby database capture the current delay value

    SQL> SELECT DELAY_MINS
    FROM V$MANAGED_STANDBY
    WHERE PROCESS = 'MRP0';

    On the target physical standby database turn off delay if > 0

    SQL> RECOVER MANAGED STANDBY DATABASE CANCEL

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY USING CURRENT LOGFILE DISCONNECT FROM SESSION;
    2.2. Ensure Online Redo Log Files on the Target Physical Standby have been cleared

    Online redo logs on the target physical standby need to be cleared before that standby database can become a primary database. Although this will automatically happen as part of the SWITCHOVER TO PRIMARY command, it is recommended that the logs are cleared prior to the switchover. If you have set the LOG_FILE_NAME_CONVERT parameter in the spfile, online redo logs will be automatically cleared the first time managed recovery is started on the standby.

    Oracle recommends setting LOG_FILE_NAME_CONVERT to automatically clear online redo logs on the physical standby database. In the event the primary database and the physical standby database have the exact same directory path to the online redo logs, it is acceptable to set LOG_FILE_NAME_CONVERT such that the entry pairs have the same value.

    As an example, if the online redo logs are stored in /oradata/order_db/redo for both the primary and physical standby databases on their respective servers, you can set the parameter value as

    LOG_FILE_NAME_CONVERT=’/oradata/order_db/redo/’,’/oradata/order_db/redo/’

    This will initiate automatic clearing of the online redo logs on the physical standby database when managed recovery is started.

    Clearing online redo logs as part of the SWITCHOVER TO PRIMARY command can make the switchover command susceptible to termination by another process that is waiting on access to the CONTROLFILE. The CONTROLFILE waiter will attempt to kill the switchover after a timeout is 15 minutes.

    If you have not set your environment to automatically clear the online redo logs you should manually clear them at some point prior to the switchover. This can be done at any time.

    On the target physical standby run the following query to determine if the online redo logs have not been cleared:

    SQL> SELECT DISTINCT L.GROUP#
    FROM V$LOG L, V$LOGFILE LF
    WHERE L.GROUP# = LF.GROUP#
    AND L.STATUS NOT IN (‘UNUSED’, ‘CLEARING’,’CLEARING_CURRENT’);

    If the above query returns rows, on the target physical standby issue the following statement for each GROUP# returned:

    SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

    If the switchover is performed using SQL*Plus is terminated by a CONTROLFILE waiter timeout, just re-issue the SWITCHOVER TO PRIMARY command until it completes successfully. If you encounter the timeout while attempting a switchover using Data Guard Broker, you must go into SQL*Plus, attaching to the target physical standby database and re-issue the SWITCHOVER TO PRIMARY command until it completes successfully. You must then drop and recreate your Broker configuration.

    In both cases, you should monitor your alert log to ensure your online redo logs are being cleared and you are not experiencing some other issue.

    2.3. Check for Previously Disabled Redo Threads

    This check is to evaluate if you are vulnerable to Bug 6266023 (fixed in 10.2.0.4.2 patchset) which will cause a switchover to fail..

    To determine if this situation exists, on your primary database, first run the following query to determine if there are any threads with a SEQUENCE# greater than 0:

    SQL> SELECT THREAD#
    FROM V$THREAD
    WHERE SEQUENCE# > 0;

    On the primary database, determine the current database redo branch:

    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#)
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    Any of the threads identified by the first query are disabled provided there are no archive log or log history records in the control file of the target physical standby database on the current branch of redo on the primary.

    To determine this, substitute the resetlogs_change# from the primary database (found in the second query) into the query below and execute it on the target physical standby database for each thread reported from the first query above.

    SQL> SELECT ‘CONDITION MET’
    FROM SYS.DUAL
    WHERE NOT EXISTS (SELECT 1
    FROM V$ARCHIVED_LOG
    WHERE THREAD# =
    AND RESETLOGS_CHANGE# = )
    AND NOT EXISTS (SELECT 1
    FROM V$LOG_HISTORY
    WHERE THREAD# =
    AND RESETLOGS_CHANGE# = );

    If this query returns a row for any of the threads, you have a disabled thread with a non-zero SEQUENCE# that can prevent a switchover from the primary database to the physical standby database. In this case, you must apply the latest patchset or use one of the following workarounds:

    Workaround 1 – Does not require primary database downtime

    Briefly enable the previously disabled thread(s) and switch logs on the primary database to send logs and populate entries into V$ARCHIVED_LOG and V$LOG_HISTORY on the physical standby database. This workaround does not require downtime on the primary database, but it is not a permanent workaround. Until either the 10.2.0.4.2 or higher patchset is applied or the second workaround listed is performed, you would need to perform these steps prior to every switchover. Log shipping and managed recovery should remain on during this process.

    1. At primary enable the disabled threads and switch logs. The multiple disable/enable and switch logfile commands are required to ensure all manner of disabled threads (internally disabled and externally disabled) are handled correctly.

    On the primary database, enable each of the disabled threads;
    SQL> ALTER DATABASE DISABLE THREAD ;
    SQL> ALTER DATABASE ENABLE THREAD ;
    SQL> ALTER DATABASE DISABLE THREAD ;
    SQL> ALTER DATABASE ENABLE THREAD ;

    Perform the following 4 times on the primary database:

    SQL> ALTER SYSTEM SWITCH LOGFILE;

    Do the following 1 time on the primary database:

    SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

    2. Verify that the primary has archived a log for the thread(s);

    On the primary database issue the following;
    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE# =
    (SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’)
    GROUP BY THREAD#;

    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$ARCHIVED_LOG
    WHERE RESETLOGS_CHANGE# =
    (SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’)
    GROUP BY THREAD#;

    3. Ensure that redo apply has progressed through the enabled thread logs:

    Connect to the primary database and issue;
    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#)
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    Connect to target physical standby database and issue;
    SQL> SELECT THREAD#,MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE# =
    GROUP BY THREAD#;

    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$ARCHIVED_LOG
    WHERE RESETLOGS_CHANGE# =
    GROUP BY THREAD#;

    NOTE: Both these queries should return values for the threads enabled in step 1.

    4. On the primary database, disable the threads enabled in step 1 (run the DISABLE for each thread);
    SQL> ALTER DATABASE DISABLE THREAD ;

    SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

    5. Verify, by repeating step 2, the primary has archived the logs of the disabled thread(s). The last query may need to be run a few times to give time for the final archival to complete. The output from the two queries should match once the archiving is caught up.

    6. Repeat step 3 to ensure that the standby has received and applied through all the logs from the disabled threads.

    7. Repeat Section 2.1, "Verify Configuration Health" and proceed to Section 2.4, "Check if the standby has ever been open read-only"

    Workaround 2 – Requires primary database downtime

    Reset the SEQUENCE# to 0 for the disabled threads by opening the primary database with the RESETLOGS option. This workaround is a permanent fix, however it requires downtime on the primary database. Log shipping should remain on during this process.
    1. If using the Data Guard Broker, use dgmgrl to connect to the primary database and disable the configuration
      DGMGRL> DISABLE CONFIGURATION;
    2. At each physical standby database, stop the managed recovery process
      SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

      Ensure managed recovery has been stopped.
      SQL> SELECT *
      FROM GV$MANAGED_STANDBY
      WHERE PROCESS = ‘MRP0’;
    3. At the primary database, switch logfiles 2 times to ensure the primary database has advanced beyond the point managed recovery has recovered to on the physical standby database(s).
      SQL> ALTER SYSTEM SWITCH LOGFILE;
      SQL> ALTER SYSTEM SWITCH LOGFILE;
    4. This process requires a clean shutdown of the primary database.
      Shutdown each instance of the primary database normal
      SQL> SHUTDOWN IMMEDIATE
    5. Start one instance of the primary database in mount mode
      SQL> STARTUP MOUNT
    6. Start recovery on this primary database instance. No actual recovery will be performed, this is to prepare for opening the database with RESETLOGS.
      SQL> RECOVER DATABASE UNTIL CANCEL;

      Media recovery complete.
    7. Open the primary database with RESETLOGS option.
      SQL> ALTER DATABASE OPEN RESETLOGS;
    8. Generate an archive log file from the primary database:
      SQL> ALTER DATABASE ARCHIVE LOG CURRENT;
    When the standby database recognizes the new redo branch, media recovery will return an ORA-19906 error, this is expected. The alert log for the standby database will show something similar to:

    MRP0: Incarnation has changed! Retry recovery...
    Wed Dec 2 06:47:52 2009
    Errors in file /ade/mgirkar_103/oracle/rdbms/log/x1032_mrp0_13389.trc:
    ORA-19906: recovery target incarnation changed during recovery

    Managed Standby Recovery not using Real Time Apply
    Recovery interrupted!
    Wed Dec 2 06:47:54 2009
    Errors in file /ade/mgirkar_103/oracle/rdbms/log/x1032_mrp0_13389.trc:
    ORA-19906: recovery target incarnation changed during recovery

    Wed Dec 2 06:48:14 2009
    Managed Standby Recovery starting Real Time Apply
    Media Recovery apply resetlogs offline range for datafile 1, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 2, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 3, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 4, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 5, incarnation : 0
    parallel recovery started with 2 processes
    Media Recovery Log /ade/mgirkar_103/oracle/work/arc_save/db2r_602567e5_1_1_704530059.arc
    Media Recovery Waiting for thread 1 sequence 2 (in transit)
    9. Ensure both the primary and the physical standby database are on the same redo branch.
    On both the primary and physical standby database, issue the following query:

    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#), RESETLOGS_TIME
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    The new branch of redo should be clearly identified by the RESETLOGS_TIME. If the new branch does not appear on the physical standby, do not continue, instead investigate why the new redo branch has not registered at the physical standby database.

    NOTE: It may take a few moments for the physical standby to receive the logs from the primary database and recognize the change in branch.
    10. Restart the managed recovery process.
    a. If using Data Guard Broker, use dgmgrl to connect to the primary database and re-enable the configuration disabled as part of the first step of this workaround. Enabling the configuration will also start the managed recovery process.
    DGMGRL> ENABLE CONFIGURATION;
    a. If managing the configuration using SQL*Plus, connect to the physical standby database(s) and restart the managed recovery process.
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY USING CURRENT LOGFILE DISCONNECT FROM SESSION;
    11. Repeat Section 2.1, "Verify Configuration Health" and proceed to Section 2.4, "Check if the standby has ever been open read-only"

    2.4. Check if the standby has ever been open read-only

    On the target physical standby database run this query:

    SQL> SELECT VALUE
    FROM V$DATAGUARD_STATS
    WHERE NAME='standby has been open';

    If the target physical standby was open read-only then restart the standby

    SQL> SHUTDOWN IMMEDIATE

    SQL> STARTUP MOUNT

    2.5. Verify there are no large GAPS.

    Identify the current sequence number for each thread on the primary database

    SQL> SELECT THREAD#, SEQUENCE#

    FROM V$THREAD;

    Verify the target physical standby database has applied up to, but not including the logs from the primary query. On the standby the following query should be no more than 1-2 less than the primary query result.

    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$ARCHIVED_LOG
    WHERE APPLIED = 'YES'
    AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’)
    GROUP BY THREAD#;

    If large gaps exist (more than 3 logs) then consult the Oracle® Data Guard Concepts and Administration, 10g Release 2 (10.2) guide: Section 5.8 Section 12.11 “Resolving Archive Gaps Manually”. If the gap is not resolved by Data Guard automatically then consult, “ Manually Determining and Resolving Archive Gaps”.

    If a large redo apply lag (greater than 2 logs) persists then review the MAA best practice paper, “ Data Guard Redo Apply & Media Recovery” and also consult the Oracle® Data Guard Concepts and Administration 11g Release 1 (11.1) guide to monitor in more detail, 9.5 Monitoring Primary, Physical Standby.

    2.6. Use “THROUGH ALL SWITCHOVER” on Bystander Standbys

    Redo apply should be started with the “THROUGH ALL SWITCHOVER ” clause at each standby database in the configuration. The Broker starts managed recovery with the “THROUGH ALL SWITCHOVER” clause.
    See Managing Data Guard Configurations Having Multiple Standby Databases - Best Practices for details.

    2.7. Verify Primary and Standby TEMP Files Match

    On the standby for each temporary tablespace, verify that temporary files associated with that tablespace on the primary database also exist on the standby database. Temp files added after initial standby creation are not propagated to the standby. Run this query on both the primary and target physical standby databases and verify that they match.

    SQL> SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE
    FROM V$TEMPFILE TMP, V$TABLESPACE TS
    WHERE TMP.TS#=TS.TS#;

    If the queries do not match then you can correct the mismatch now or immediately after the open of the new primary.

    To correct now: add or delete a tempfile now requires managed recovery to be stopped and the standby to be open read only. Opening the standby read-only will require a database close and open before becoming the new primary, see “Open the new primary database”.

    To correct post-primary-open: see “Correct any tempfile mismatch” step of Switchover

    2.8. Verify that there is no issue with V$LOG_HISTORY on the Standby

    ( Bug 6010833, 10.2.0.3 patch available on Linux 32-bit, this is included in the 6081547 patch bundle ( Document 6081547.8) listed above under “Apply Latest Patch Bundle”. It is assumed any potential issues with “Check for Previously Disabled Redo Threads” have already been resolved.)

    Determine threads that have been active at some point on the primary database:

    SQL> SELECT THREAD#, SEQUENCE#
    FROM V$THREAD
    WHERE SEQUENCE# > 0;

    Get the RESETLOGS_CHANGE# from the primary database:
    SQL> SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    On the target physical standby database, get the maximum sequence numbers for each thread from V$LOG_HISTORY:
    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE#=< resetlogs_change# from the primary V$DATABASE_INCARNATION.RESETLOGS_CHANGE# >
    GROUP BY THREAD#;

    The last SEQUENCE# for each THREAD# from V$LOG_HISTORY on the target physical standby database should be close (the difference in log sequences < 3) to the SEQUENCE# for each THREAD# from V$THREAD on the primary database. If the difference in log sequences is greater than 3 or no row is returned for the thread, you have encountered this problem and should recreate the standby controlfile. See Note 459411.1. If backups are being done on the standby without an RMAN Catalog then backup history will be lost. It is highly recommended to use an RMAN Catalog for all backups.

    2.9.Verify no old partial Standby Redo Logs on the Standby

    ( Bug 7159505, fixed in 10.2.0.5 and 11.1.0.7; 10.2.0.3 patch available on Solaris Sparc64 and can be requested for other platforms. This patch conflicts with the 6081547 patch bundle ( Document 6081547.8) and would require a patch merge request if you want to apply this on top of the 6081547 patch bundle ( Document 6081547.8) .)

    Get the RESETLOGS_CHANGE# from the primary database:
    SQL> SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    On the target physical standby database, identify any active standby redo logs (SRL’s)
    SQL> SELECT GROUP#, THREAD#, SEQUENCE#
    FROM V$STANDBY_LOG
    WHERE STATUS = 'ACTIVE'
    ORDER BY THREAD#,SEQUENCE#;

    On the target physical standby database, identify maximum applied sequence number(s).
    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE#=< resetlogs_change# from the primary V$DATABASE_INCARNATION.RESETLOGS_CHANGE# >
    GROUP BY THREAD#;

    If there are any active SRL's that have a thread#/sequence# less than the thread#/sequence# returned from the V$LOG_HISTORY (meaning the recovery has progressed beyond the active SRL) query, clear them on the target physical standby.

    SQL> RECOVER MANAGED STANDBY DATABASE CANCEL

    SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

    3.0 Switchover

    3.1. Clear Potential Blocking Parameters & Jobs

    Capture current job state on the primary

    SQL> SELECT *
    FROM DBA_JOBS_RUNNING; [depending on what the running job is, be ready to terminate]

    SQL> SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED
    FROM DBA_SCHEDULER_JOBS
    WHERE ENABLED=’TRUE’
    AND OWNER <> ‘SYS”;

    SQL> SHOW PARAMETER job_queue_processes

    Note: cron job candidates to be disabled among others: oracle text sync and optimizer, RMAN backups, application garbage collectors, application background agents.

    Block further job submission

    SQL> ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH SID=’*’;

    SQL> EXECUTE DBMS_SCHEDULER.DISABLE( );

    Disable any cron jobs that may interfere.

    3.2. Shutdown all mid-tiers (optional)

    This can be done in parallel to the switchover.

    $ opmnctl stopall

    Note: If using a local standby with an application that is following the “ Client Failover in Data Guard Configurations for Highly Available Oracle Databases” paper recommendations to utilize a database startup trigger that ensures the application database service is only active on the primary, this step can be skipped.

    3.3. Monitor Switchover
    3.3.1. With Broker
    3.3.1.1. Turn on Data Guard tracing on primary and standby

    Capture the current value for each instance

    DGMGRL> SHOW INSTANCE LogArchiveTrace;

    Set Data Guard trace level to 8191 for each instance

    DGMGRL> EDIT INSTANCE SET PROPERTY LogArchiveTrace=8191;

    Trace output will appear under the destination pointed to by the database parameter BACKGROUND_DUMP_DEST with “mrp” in the file name.

    3.3.1.2. Tail Broker Logs (optional) on all instances

    Locate Broker logs by showing database parameter background_dump_dest

    SQL> SHOW PARAMETER background_dump_dest

    Tail the broker logs

    > tail –f /dr*
    3.3.2. Without Broker
    3.3.2.1. Turn on Data Guard tracing on primary and standby

    Tracing is turned on to have diagnostic information available in case any issues arise. Turning on tracing does not have any noticeable impact on switchover time but does require space for the trace output.

    Capture the current value on both the primary and the target physical standby databases

    SQL> SHOW PARAMETER log_archive_trace

    Set Data Guard trace level to 8191 on both the primary and the target physical standby databases

    SQL> ALTER SYSTEM SET log_archive_trace=8191;

    Trace output will appear under the destination pointed to by the database parameter BACKGROUND_DUMP_DEST with “mrp” in the file name.
    3.3.3. Tail Primary and Standby alert logs on all instances

    Locate alert logs by showing database parameter background_dump_dest on both the primary and the target physical standby databases

    SQL> SHOW PARAMETER background_dump_dest

    Tail the alert log on both the primary and the target physical standby databases

    > tail –f /al*
    3.4. Create Guaranteed Restore Points (optional)

    The standard switchover fallback options should suffice for successfully backing out of a switchover. However, if you want an additional fallback option then you can create a guaranteed restore point on the primary and standby database participating in the switchover. If you want to do this see “ Create a Guaranteed Restore Point on Each Switchover Database” for details. If a guaranteed restore point is created, make sure it is dropped post-switchover.

    3.5. Switchover
    3.5.1. With Broker
    3.5.1.1. Data Guard Broker command line utility

    See Performing a Switchover Operation

    Connect to the primary database using the DGMGRL command line utility as sys using the same password as the sys user on the primary and standby databases

    Issue the switchover to command:

    DGMGRL> SWITCHOVER TO ;

    3.5.1.2. EM switchover

    To start a switchover using Enterprise Manager, select the standby database that you want to change to the primary role and click Switchover.

    Note: Following the open of the new primary there will be an increase in I/O while the new primary’s standby redo logs are cleared.
    3.5.2. Without Broker
    3.5.2.0. Verify that the primary database can be switched to the standby role

    Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database. For example:
    SQL> SELECT SWITCHOVER_STATUS
    FROM V$DATABASE;

    SWITCHOVER_STATUS
    -----------------
    TO STANDBY

    A value of TO STANDBY or SESSIONS ACTIVE (requires the WITH SESSION SHUTDOWN clause on the switchover command) indicates that the primary database can be switched to the standby role. If neither of these values is returned, a switchover is not possible because redo transport is either mis-configured or is not functioning properly. See Chapter 5 of the " Oracle® Data Guard Concepts and Administration, 10g Release 1 (10.2)" guide for information about configuring and monitoring redo transport.

    3.5.2.1. If RAC, then shutdown all secondary primary instances

    A normal shutdown can be done, but to expedite the shutdown issue a SHUTDOWN ABORT on secondary RAC instances on the primary only

    3.5.2.2. Switchover the primary to a standby database

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;

    If an ORA-16139 is encountered, as long as V$DATABASE.DATABASE_ROLE=’PHYSICAL STANDBY’, then you can proceed. A common case where this can occur is when there are a large number of data files, greater than 1,000, the apply of the EOR log will timeout.. Once managed recovery is started on the new standby it will recover.

    If the role was not changed then you need to cancel the switchover and review the alert logs and trace files further.

    3.5.2.3. Verify the standby has received the end-of-redo (EOR) log(s)

    In the primary alert log you should see messages like this:

    Mon Nov 3 06:53:13 2008
    ARCH: Noswitch archival of thread 1, sequence 21
    ARCH: End-Of-Redo Branch archival of thread 1 sequence 21
    ARCH: Archiving is disabled due to current logfile archival
    Clearing standby activation ID 2821924805 (0xa83327c5)
    The primary database controlfile was created using the
    'MAXLOGFILES 192' clause.
    There is space for up to 188 standby redo logfiles
    Use the following SQL commands on the standby database to create
    standby redo logfiles that match the primary database:
    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 524288000;

    Archivelog for thread 1 sequence 21 required for standby recovery
    Switchover: Primary controlfile converted to standby controlfile succesfully.
    MRP0 started with pid=18, OS id=32583
    Mon Nov 3 06:53:15 2008
    MRP0: Background Managed Standby Recovery process started (sfs_stby1)
    Mon Nov 3 06:53:20 2008
    Managed Standby Recovery not using Real Time Apply
    Mon Nov 3 06:53:20 2008
    parallel recovery started with 3 processes
    Online logfile pre-clearing operation disabled by switchover
    Media Recovery Log +REGR/sfs_stby/archivelog/2008_11_03/thread_1_seq_21.258.669
    97593
    Identified End-Of-Redo for thread 1 sequence 21
    Mon Nov 3 06:53:21 2008
    Media Recovery End-Of-Redo indicator encountered
    Mon Nov 3 06:53:21 2008
    Media Recovery Applied until change 8338654
    Mon Nov 3 06:53:21 2008
    MRP0: Media Recovery Complete: End-Of-REDO (sfs_stby1)
    Resetting standby activation ID 2821924805 (0xa83327c5)
    Mon Nov 3 06:53:21 2008
    MRP0: Background Media Recovery process shutdown (sfs_stby1)
    Mon Nov 3 06:53:22 2008
    SUCCESS: diskgroup REGR was dismounted
    Mon Nov 3 06:53:22 2008
    Switchover: Complete - Database shutdown required (sfs_stby1)
    Mon Nov 3 06:53:22 2008
    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN

    And correspondingly in the standby alert log file you should see messages like this:

    Mon Nov 3 06:53:17 2008
    Media Recovery Log +REGR2/sfs/archivelog/2008_11_03/thread_1_seq_21.3819.669797593
    Identified End-Of-Redo for thread 1 sequence 21
    Mon Nov 3 06:53:17 2008
    Media Recovery End-Of-Redo indicator encountered
    Mon Nov 3 06:53:17 2008
    Media Recovery Applied until change 8338654
    Mon Nov 3 06:53:17 2008
    MRP0: Media Recovery Complete: End-Of-REDO (sfs1)
    Resetting standby activation ID 2821924805 (0xa83327c5)
    Mon Nov 3 06:53:19 2008
    MRP0: Background Media Recovery process shutdown (sfs1)

    3.5.2.4. If the standby is a RAC configuration, then shutdown all secondary standby instances

    A normal shutdown can be done, but to expedite this operation, issue a SHUTDOWN ABORT on the secondary non-apply RAC instances.

    3.5.2.5. Verify that the standby database can be switched to the primary role

    Query the SWITCHOVER_STATUS column of the V$DATABASE view on the standby database. For example:
    SQL> SELECT SWITCHOVER_STATUS
    FROM V$DATABASE;

    SWITCHOVER_STATUS
    -----------------
    TO PRIMARY

    A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role. If neither of these values is returned, verify that redo apply is active and that redo transport is configured and working properly. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE.

    3.5.2.6. Check if the standby has ever been open read-only

    If the target physical standby has been open read-only (found in Pre-Switchover check 2.5) and you have not bounced the target physical standby, do so now.

    3.5.2.7. Switchover the standby database to a primary

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

    3.5.2.8. Open the new primary database:

    SQL> ALTER DATABASE OPEN;

    Note: Beginning with Oracle Database 10g Release 2, you can open the new production database directly from the mount state if the standby database was not opened read-only since the last time the database was started. If the database has been opened read-only, it will need to be restarted.

    Note: There will be an increase in I/O while the new primary’s standby redo logs are cleared.

    3.5.2.9. Correct any tempfile mismatch

    If there was a tempfile mismatch in Pre-switchover check, “Verify Primary and Standby TEMP Files Match” that was not corrected then correct it now on the new primary.

    3.5.2.10. Restart the new standby

    On the the new standby database (old production database), bring it to the mount state and start managed recovery. This can be done in parallel to the new primary open.

    SQL> SHUTDOWN IMMEDIATE;

    SQL> STARTUP MOUNT;

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

    3.5.2.11. If the production and standby databases are configured in a RAC, then start all instances on primary and standby
    3.6. Contingency or Fallback

    See 11.1 guide, Failed Switchovers to Physical Standby Databases. Still applies to 10.2 as well.

    Check DG Admin troubleshooting guide, Problems Switching Over to a Standby Database

    4.0 Post-Switchover Steps

    4.1. Set Trace to Prior Value
    4.1.1. With Broker

    For every instance: DGMGRL> EDIT INSTANCE SET PROPERTY LogArchiveTrace=3.3.1.1>;

    4.1.2. Without Broker

    For each database:

    SQL> ALTER SYSTEM SET log_archive_trace=;
    4.2. Reset Jobs

    SQL> ALTER SYSTEM SET job_queue_processes= scope=both sid=’*’

    SQL> EXECUTE DBMS_SCHEDULER.ENABLE();

    Enable any cron jobs that were diabled in 3.1

    4.3. Schedule and conduct the incremental backup, roll-forward, and tape backups for 10.2

    Retain/move backup schedule to the standby

    4.4. Reset apply delay for the target standby

    Reverse steps in 2.1.1.2 or 2.1.2.2

    4.5. Drop any Switchover Guaranteed Restore Points

    SQL> DROP RESTORE POINT SWITCHOVER_START_GRP ;

    5.0 Create a Guaranteed Restore Point on Each Switchover Database

    5.1. Review Prerequisites & Best Practices
    About Flashback Database
    Guaranteed Restore Points and Flash Recovery Area Space Usage
    Logging for Flashback Database With Guaranteed Restore Points Defined
    Flashback Database Best Practices & Performance Document 565535.1.
    5.2. Create a guaranteed restore point on the primary
    5.2.1. Verify if flashback database is on or a guaranteed restore point already exists

    SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

    If this query returns “YES” (flashback database is on) or “RESTORE POINT ONLY” (Flashback is on but one can only flashback to an existing guaranteed restore point) then proceed to creating the guaranteed restore point.

    NOTE: Unless you have a backport for Bug 7568556, “ACTIVE APPLY RATE SEEN FROM 63MB/S TO 544KB/S AFTER RESTORE POINT ENABLED”, you should not have just a guaranteed restore point only (V$DATABASE.FLASHBACK_ON=”RESTORE POINT ONLY”) and ensure that flashback database is also on (V$DATABASE.FLASHBACK_ON=”YES”) when creating a guaranteed restore point.

    If this query returns “NO” then you need to turn on flashback database before creating the guaranteed restore point. This requires the database to be mounted.

    See Enabling Logging for Flashback Database for those steps.

    5.2.2. Create the guaranteed restore point

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
    5.3. Create a guaranteed restore point on the standby
    5.3.1. Verify if flashback database is on or a guaranteed restore point already exists

    SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

    If this query returns “YES” (flashback database is on) or “RESTORE POINT ONLY” (Flashback is on but one can only flashback to an existing guaranteed restore point) then proceed to creating the guaranteed restore point.

    If this query returns “NO” then you need to turn on flashback database before creating the guaranteed restore point. This requires being in the MOUNT state.

    See Enabling Logging for Flashback Database for those steps.

    5.3.2. Create the guaranteed restore point

    SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;
    [@more@]

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9225895/viewspace-1030926/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/9225895/viewspace-1030926/

    展开全文
  • <p>"the procedure entry point zend_new_interned_string could not be located in the dynamic link library E:\xampp\ZendGuardLoader\php-5.4.x\ZendLoader.dll"</p> <p>When I tried to search on internet ...
  • Notes from Data Guard

    千次阅读 2014-06-21 20:17:48
    1,You can use a logical standby for real-time reporting and the physical standby database for point-in-time reporting. 2,Logical standby database is open and ready for reporting at all times. ...

    There are two types of Standby databases:
    1, Physical standby database
    block-for-block basis
    the physically identical with the primary database
    user recovery technology
    2, Logical  standby database
    shares the same schema definition withe the primary database
    executing sql statements on the standby database
    use logMiner technology

    There are three types of services provided with Data Guard:
    1, redo transport services
    2, log apply service: including redo apply and SQL apply
    3, Role-management services

    Oracle Data Guard supports two role-transition operations:
    1, Switchover
    2, Failover

    Oracle Data Guard Data Protection Modes:
    1,Maximum Protection
    2,Maximum Availability
    3,Maximum Performance

    Benefits of Implementing Oracle Data Guard:
    1,You can use a logical standby for real-time reporting and the physical standby database for point-in-time reporting.
    2,Logical standby database is open and ready for reporting at all times.


    Note:Standby database can use a different directory structure from the primary database.


    On the primary database,Data Guard redo transport services use the following processes:
    1,Log Writer(LGWR) process
    2,Archiver(ARCn) Process
    3,Fetch archive log(FAL)

    Note:You can configure a primary database to ship redo information to a single standby database by using either LGWR or ARCn,but not both.


    On the standby database,Data Guard log apply services use the following processes:
    1,Remote file server(RFS) process
    2,Archiver(ARCn) process
    3,Managed recovery process(MRP)
    4,Logical standby process(LSP) 

    Standby Redo Logs:
    A standby redo log is required to implement:
    1, The maximum protection and maximum availability levels of data protection.
    2,Real-time apply
    3,Cascaded redo log destinations

    Standby redo logs are recommended for maximum performance data protection mode
    Unless you are using the real-time apply feature,standby redo logs must be archived before the data can be applied to the standby database.
    The standby archival operation occurs automatically.

    The Data Guard physical standby Redo Apply architecture consists of:
    A production(primary) database,which is linked to one or more standby databases(up to nine) that are identical copies of the production database.
    --The limit of nine standby databases is imposed by the LOG_ARCHIVE_DEST_n parameter.In Oracle Database 10g,the maximum number of destinations is   10. One is used as the local archive destination,leaving the other nine for uses such as the standby database.
    Note: You can use the Cascaded Redo Log Destination feature to incorporate more than nine standby databases in your configuration.
    --The primary database is open and active.The standby databases are either in recovery mode or open in read-only mode,but not both.
    --Redo is applied to each standby database by using standard Oracle recovery techniques.


    Logical Standby Database: SQL Apply Architecture
    Instead of using media recovery to apply changes(as in the physical standby database configuration),archived redo log information is transformed
    into equivalent SQL statements by using LogMiner technology.These SQL statements are then applied to the logical standby database.The logical
    standby database is open in read/write mode and is available for reporting capabilities.

    The RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view contains the value MANAGED REAL TIME APPLY when log apply services are running in
    real-time mode.
    For physical standby database,the managed recovery process(MRP) applies the redo from the standby redo log files after the remote file server(RFS) process finishes writing.To start real-time apply for a physical standby database,issue the following command:
    alter database recover managed standby database using current logfile;
    For logical standby database,the logical standby process(MRP) applies the redo from the standby redo log files after the remote file server(RFS) process finishes writing.To start real-time apply for a logical standby database,issue the following command:
    alter database start logical standby apply immediate;


    VALID_FOR : ALL_LOGFILES,ALL_ROLES is not recommended setting for a logical standby for any destination.Because a logical standby is an open
    database that is creating its own redo, there is a real possibility of having the log files overwrite each other.This gives you a system that is
    unrecoverabl and/or unable to keep synchronized with the primary database.

    There is only one invalid combination: STANDBY_LOGFILE,PRIMARY_ROLE.
    SELECT dest_id,valid_type,valid_role,valid_now from v$archive_dest;

    select * from v$standby_log;
    select * from v$logfile where type='STANDBY';


    Although standby redo logs are used only when the database is operating in the standby role,you should create standby redo logs on the primary
    database so that switching roles does not require additional DBA intervention.


    You can maintain the standby database in one of the following modes:
    For physical standby databases
    1,Redo Apply
    2,Open read-only mode
    For Logical standby databases
    Open read/write mode


    Data Guard Broker:Requirments
    1,Enterprise Edition of Oracle Databae 10g
    2,LOCAL_LISTERNER on each instance must resolve to an address that is reachable by all members
    3,GLOABL_DBNAME attribute must be set to a concatenation of: db_unique_name_DGMGRL.db_domain

    The Data Guard monitor comprises two components: the DMON process and the configuration file.
    Data Guard configuration file:
    1,default names are dr1<db_unique_name>.dat and dr2<db_unique_name>.dat
    2,default location for unix and linux:$ORACLE_HOME/dbs. for windows:ORACLE_HOME\database

    startup mount;
    alter database force logging; The default value is No.


    ARCHIVE_LAG_TARGET: It defines the mean time to failover in the event your primary database fails and you must fail over to the standby.
    It likes the parameter of "fast_start_mttr_target"  mttr:mean time to recovery target


    The standby_archive_dest initialization parameter overrides the directory locaition that is specified with the LOG_ARCHVIE_DEST_n parameter
    if both the parameters are specified. So you should set standby_archive_dest to the same location as the local archvive destination for the
    physical standby database so that all necessary archvied redo log files for the standby database are in the same location.

    Defining the Redo Transport Mode
    Use the attributes of LOG_ARCHIVE_DEST_n
    1,ARCH and LGWR
    2,SYNC and ASYNC(LGWR only)
    3,AFFIRM and NOAFFIRM
    (primary)(修改成MAXIMUM PROTECTION)
    SQL> alter system set log_archive_dest_2='SERVICE=orcldg LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcldg NODELAY MAX_CONNECTIONS=2 REOPEN=300 NOMAX_FAILURE';


    (standby)
    SQL> alter system set log_archive_dest_2='SERVICE=orclpri LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl NODELAY MAX_CONNECTIONS=2 REOPEN=300 NOMAX_FAILURE';


    Redo Transport Mode: ARCH|SYNC|ASYNC
    ARCH: You do not need standby redo log files for this mode. This mode enables the lowest grade of protection to the primary database as well as
    the lowest performance impact.
    ASYNC: (LGWR,ASYNC,NOAFFIRM) This mode,along with standby redo log files,enables a moderate grade of protection to the primary database and incurs a lower performance impact.
    SYNC:(LGWR,SYNC,AFFIRM) This mode, along with standby redo log files,is required for the maximum protection or maximum availability protection
    modes.This redo transport mode enables the highest grade of data protection to the primary database,but it also incurs the highest performance
    impact.

    Data Protection Mode:
    1,Maximum protection
    2,Maximum availability
    3,Maximum performance

     


    Logical Standby Database features:
    alter database guard all|standby|none; The default value is all,which means only the SYS can modify the data.

    Preparing to create a logical standby database:
    1,check for unsupported data types
    2,Be aware of unspported DDL commands
    3,Ensure row uniqueness
    4,Verify that the primary database is configured for archivelog mode
    5,Enable supplemental logging

     

    Unsupported objects:
    1,Tables and sequences in the SYS schema
    2,Tables using table compression
    3,Tables used to support materialized views
    4,Global temporary tables
    5,Tables with unsupported data types(BFILE,ROWID and UROWID,User-defiened types,object types REFs,Varrays,Nested tables,XMLtype)

    Query DBA_LOGSTDBY_UNSUPPORTED on the primary database for tables with unsupported data types:
    Query DBA_LOGSTDB_NOT_UNIQUE on the primary database to find tables without a unique identifier.
    Add a primary key or unique index to ensure that SQL apply can efficiently apply data updates.

    Preparing to create a logical standby database.Be sure to check that the initialization parameters have the following values:
    PARALLEL_MAX_SERVERS>5
    LOG_PARALLELISM=1
    SHARED_POOL_SIZE:160M or higher(recommended)


    Creating a logical Standby database:
    1,create a physical standby database
    2,stop redo apply on the physical standby database
    3,prepare the primary database to support a logical standby database
    4,Build a logMiner Dictionary in the redo data
    5,convert to a logical standby database
    6,open the logical standby database
    7,Verify that the logical standby database is performing properly.

    Fast-start failover can be enabled for automatic failover

    select thread#,low_sequence#,high_sequence# from v$archive_gap;
    alter database register physical logfile 'filespec1';

    展开全文
  • 资安业者Check Point最近发现,小米手机中所预装、理应用来保护手机免受恶意软件攻击的安全程序Guard Provider竟然含有安全漏洞,允许与手机用户位于同一Wi-Fi网络的黑客执行中间人(Man-in-the-Middle,MiTM)攻击...
  • PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3September, 2007Skywing skywing@valhallalegends.comhttp://www.nynaeve.net/ Abstract: Since the publication of previous by
  • A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • 这是HTB的Starting Point实验室中第八台靶机,主要根据官方提供的...Guard靶机IP地址:10.10.10.50;(VIP可用) 网络连接,按照说明连接到Starting Point实验室。 二、开始渗透 1. 信息收集 使用nmap扫描,发现
  • patchGuard v2

    千次阅读 2012-07-25 01:19:02
    list entries should be valid, and point to other seemingly valid KTIMER objects (or the list head), and that the type field of the KTIMER is consistent with a timer object. 2. The timer ...
  • c++11的mutex unique_lock和lock_guard区别

    千次阅读 2017-09-22 15:24:00
    C++11中有一个区域锁lock_guard,还有第二个区域锁unique_lock。  区域锁lock_guard使用起来比较简单,除了构造函数外没有其他member function,在整个区域都有效。  区域锁unique_guard除了lock_guard的功能外...
  • <p>However, the jasmine-rails /specs mountpoint does appear to be fully functional at the url shown in the debugging output, and is a-ok when I view it from a web browser. Adjusting the timeout and ...
  • Data guard 应用 笔记

    2007-05-01 11:05:44
    Data guard 应用 笔记,最近几天学习的结果,也不知道对了多少?[@more@]If you do not use the Data Guard broker, you must definethe LOG_ARCHIV...
  • Data Guard Physical Standby Switchover 一、确保主库相关参数文件,设置正确如下为主数据库相关参数DB_NAME=pridbDB_UNIQUE_NAME=pridbLOG_ARCHIVE_CONFIG='DG_CONFIG=(pridb,stdb)'CONTROL_FILES='/arch1/chicago...
  • A guard at an intersection point of several corridors can see and therefore guard the items on each of the corridors. If Bluewater were contracted to supply 3 guards, they might choose to post them ...
  • 1. Oracle Data Guard: OverviewTypes of Standby DatabasesPhysical standby database block-for-block, redo...
  • Data Guard 9i Configuring Transparent Application Failover in a Data Guard Environment [ID 205637.1] Modified19-OCT-2010TypeBULLETINStatusPUBLISHED PURPOSE --...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,385
精华内容 3,354
关键字:

guardpoint