• [原]Oracle Data Guard 折腾记(二)


          前文再续,书接上一回,这次折腾Data Guard的一个重要目的是利用switchover实现机器的升级,怎么switchover呢?按照我的理解,Data Guard的角色切换是这样一个过程:

          (1)让primary节点变为standby节点。

          (2)让其中一个standby节点变为primary节点

          这里比较有意思是“其中一个”,也就是说节点A原来是primary转成standby后,突然我后悔了,还是可以马上让他变回primary节点的,具体看操作:

          此时 test02 是primary 节点,test03是standby节点,由于test03缺少一个参数,一点test03变为primary,归档不会自动发到test02,于是第一步要补全这个参数:

    ##### test03 target priamry, standby now #####
    alter system set log_archive_dest_2='service=mydb_test02';

          让test02由primary变为standby:

    ##### test02, target standby, primary now #####
    alter database commit to switchover to physical standby ;

          以上语句有可能会遇到如下错误:

    alter database commit to switchover to physical standby
    *
    ERROR at line 1:
    ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

          这是由于一些连接还没有释放所致的,将前端应用关闭后如果还出现这种情况,可以用以下语句确认一下有哪些连接:

    ##### test02, target standby, primary now #####
    SELECT SID, PROCESS, PROGRAM FROM V$SESSION   
    WHERE TYPE = 'USER'
    AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);

          如果是Oracle内部进程的连接就不用管他了,执行如下语句就可以了:

    ##### test02, target standby, priamry now #####
    alter database commit to 
      switchover to physical standby 
      with session shutdown

          将test03也就是原来是standby的节点转为primary:

    ##### test03, target primary, standby now #####
    alter database commit to switchover to primary;
    ##### test03, target primary, primary now #####

          打开primary节点的数据库,使其可对外服务:

    ##### test03, target primary, primary now #####
    shutdown immediate;
    startup;

          启动standby的归档恢复进程:

    ##### test02, target standby, standby now #####
    alter database recover managed standby database disconnect from session;

          此时已经完成了Data Guard 主备切换了,可以监控住standby的alert文件,在primay中做一次日志切换,看看是否有归档日志传送过来并且恢复。

          如果监控时间比较长的(超过5分钟)会看到如下错误:

    ##### primary alert #####
    Fri Dec 17 14:04:46 2010
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[10]: Assigned to RFS process 12079
    RFS[10]: Database mount ID mismatch [0x9e217391:0x9e217bca]
    RFS[10]: Client instance is standby database instead of primary
    RFS[10]: Not using real application clusters
    Fri Dec 17 14:04:46 2010
    Errors in file /u01/app/admin/mydb/udump/mydb_rfs_12079.trc:
    ORA-16009: remote archive log destination must be a STANDBY database
      
    ##### standby alert #####
    Fri Dec 17 14:04:54 2010
    Errors in file /u01/app/admin/mydb/bdump/mydb_arc1_6821.trc:
    ORA-16009: remote archive log destination must be a STANDBY database
    Fri Dec 17 14:04:54 2010
    PING[ARC1]: Heartbeat failed to connect to standby 'mydb_test02'. Error is 16009.

          虽然不影响 Data Guard 的功能和使用,但如何解决呢?其实这是归档进程ARCHn进程在作怪,想办法屏蔽就可以,一个比较土的方法就是将备节点的log_archive_dest_2设为空,也就是回到上一篇中提到那种配置上,另外一种聪明点的做法就是引入valid_for参数:

    ##### test02 #####
    alter system set log_archive_dest_2='service=mydb_test03 valid_for=(online_logfiles,primary_role)';
    
    ##### test03 #####
    alter system set log_archive_dest_2='service=mydb_test02 valid_for=(online_logfiles,primary_role)';

          alert文件中再也看不到这两个错误了。

  • 相关阅读:
    20165326 Linux系统安装及学习
    20165326 学习基础和c语言基础调查
    20165326 我期望的师生关系
    2017-2018-2 20165325 实验四《Android程序设计》实验报告
    20165325《Java程序设计》第九周学习总结
    2017-2018-2 20165325 实验三《Java面向对象程序设计》实验报告
    20165325 2017-2018-2 《Java程序设计》结对编程_第二周:四则运算
    20165325 2017-2018-2 《Java程序设计》 第八周学习总结
    20165325 2017-2018-2 《Java程序设计》结对编程_第一周:四则运算
    20165325 2017-2018-2 《Java程序设计》第七周学习总结
  • 原文地址:https://www.cnblogs.com/killkill/p/1911172.html
Copyright © 2020-2023  润新知