dataguard角色切换后goldengate处理

让人想犯罪 __ 提交于 2020-08-07 11:34:45
   近期在一dataguard环境中遇到,主库的服务器出现异常夯机。之后手工重启服务器又能正常工作,原因未查明,售后提出针对各部件逐一替换的方式来处理。

         环境:dataguard的主库上部署有goldengate。
db version goldengate version os plant
11gr2 12.1.2.1.0 linux 64

环境:A 是主库【出现夯机后要换硬件配件】 、B 是备库

         过往的做法:每次主备库切换前停应用、停goldengate,主备角色切换后,采用的是将goldengate重新部署在DG角色切换后的主库上;且由于在切换前应用未停彻底,导致角色切换后,启用新的主库对接应用,新部署的golengate同步数据时会有掉数据。

goldengate12.1.2.1.0新特性:支持从ADG的在线日志中捕获变化
OGG Release 12.1.2.1.0 New Features for Oracle Database

Active Data Guard (ADG) - A new processing option (TRANLOGOPTIONS MINEFROMACTIVEDG) is introduced allowing you to configure Classic Extract to mine online redo logs shipped to the Oracle Active Data Guard standby system allowing real-time replication directly from ADG hosts. Oracle GoldenGate connects to the standby database to get metadata and other required data as needed. This mode is useful in load sensitive environments where ADG is already in place or can be implemented. It can also be used as cost effective method to implement high availability using the ADG Broker role planned (switchover) and failover (unplanned) changes.

只需在extract中添加:TRANLOGOPTIONS MINEFROMACTIVEDG即可实现对ADG的redo实时抽取了。

基于前述的环境switchover后,A环境上的备件换完,goldengate已运行在B环境上的情况进行swichover 操作。
A --备库

 B--主库【ogg运行】

优化后的处理方式:
1.停应用
2.A和B两库的sqlner.ora 仅允许A\B 两主机访问库
3.停部署在B上的ogg服务
4.重启B上的库(也就是对接应用的主库服务),确保已连入未停的应用与库之间连接断开。
5.开启B上的ogg,确保停B上库前的数据变动捕获到且已投递到目标端。
6.通过select username,count() from v$session group by username; 核查连入库中是否有应用程序。
7.停B上的ogg,断开此ogg与目标端的通迅。
8.进行switchover DG
A\B上都查看状态执行
SQL>select open_mode,database_role,switchover_status,protection_mode from v$database;









 开始switchover :

 **切换为standby角色--B上操作**
 第一次切换时switchover_status是 not allow.
 SQL>alter database commit to switchover to physical standby with session shutdown;

        SQL> shutdown immediate

        SQL> startup
    **切换为primary角色--A上执行**
                     SQL> alter database commit to switchover to primary with session shutdown;

        SQL> alter database open;
    然后检查AB上的状态:
 SQL> select database_role,switchover_status from v$database;

 9.为保证应用不动,现需 将A\B环境的IP对调。
 A\B上执行:
 SQL> shutdown immediate

 A与B 的IP对调。
 修改A\B上$ORACLE_HOME/network/admin/listener.ora中的IP,TNSNAMES.ora 中primary \standby 的tnsname名中IP对调。

 修改A\B上 sqlnet.ora 去掉访问库服务限制。

 10. 启动A\B上的库服务与监听。
 SQL>START UP
 $lsnrctl  status
 $lsnrctl stop
 $lsnrrctl start

 $tnsping <primary_service>
 $tnsping <standby_service>

 A\B库可用,且tnsping是通的。
 A上执行:
 SQL>alter system switch logfile

 B上alert_<dbname>上能看到有归档日志传过来,进行下一步。

 11.switchover后的备库上启用redo apply -B上操作
 SQL> alter database recover managed standby database using current logfile disconnect from session;

 12.启动goldengate 。
 在B上goldengate的抽取进程添加参数
 vi  b_e_x.prm
 添加
 TRANLOGOPTIONS MINEFROMACTIVEDG
 start b_e_x

 进程abend,查看report,有提示scn信息。。
 alter b_e_x,begin scn   XXXXXXX
 startt b_e_x
 进程启动

 vi c_r_x.prm  修改连接主库的tnsname名
 userid **@primary_service

 start *
 info all

    至此一切OK,完美收工。
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!