容灾切换时数据库层面有哪些注意的事项?

数据库与存储间在切换的状态,有什么机制可以查看。
存储切换和数据库切换,常见的问题有哪些。

参与9

3同行回答

容灾切换时,在数据库层面主要是要保证可用性,对于核心交易系统来说对重要的是数据的一致性校验。针对容灾切换,主要有以下几个建议和经验:通常使用集中存储技术进行容灾切换时,存储层面都提供了RPO的记录,最后的更新时间。可以通过存储系统的复制管理工具和相关的API即可以实现...显示全部

容灾切换时,在数据库层面主要是要保证可用性,对于核心交易系统来说对重要的是数据的一致性校验。针对容灾切换,主要有以下几个建议和经验:

  1. 通常使用集中存储技术进行容灾切换时,存储层面都提供了RPO的记录,最后的更新时间。可以通过存储系统的复制管理工具和相关的API即可以实现;
  2. 数据库启动之后需要通过应用手段进行校验,存储切换、数据库切换、应用切换的流程建议通过自动化切换平台进行,将切换过程的日志进行详细记录并进行展示;
  3. 网络层的切换是切换经常发生问题的阶段,需要针对各种类型的接入点进行详细的切换流程的监控,判断应用启动之后的服务状态;
  4. 建议形成切换的各种操作手册,并定期进行切换演练;
收起
硬件生产 · 2021-09-28
浏览1088
explorerexplorerSE华为
OceanStor BCManager eReplication容灾产品,了解一下,支持一键式容灾保护、恢复,简化客户操作,提高操作效率。支持Oracle、DB2、SQLServer等多种应用,及VMWare、FusionCompute虚拟化平台的容灾保护恢复。产品文档:https://support.huawei.com/hedex/hdx.do?docid=EDOC110020195...显示全部

OceanStor BCManager eReplication容灾产品,了解一下,支持一键式容灾保护、恢复,简化客户操作,提高操作效率。

支持Oracle、DB2、SQLServer等多种应用,及VMWare、FusionCompute虚拟化平台的容灾保护恢复。

产品文档:

https://support.huawei.com/hedex/hdx.do?docid=EDOC1100201952&lang=zh&idPath=7919749%7C251366268%7C250389224%7C251366267%7C21597093

兼容性列表:

https://support.huawei.com/enterprise/zh/doc/EDOC1100201947?idPath=7919749%7C251366268%7C250389224%7C251366267%7C21597093

技术原理:
https://support.huawei.com/enterprise/zh/doc/EDOC1000090710?section=l004

收起
软件开发 · 2021-12-06
浏览928
1.容灾切换主要涉及到网络层、应用层和存储层的切换,切换过程中制定好完整的流程和体系可以保障切换的顺利完成。如:切换流程、切换涉及到的步骤、切换对象、容灾演练(这个环节非常重要),建议切换前进行演练。2.存储和数据库的切换,常见问题:(1)生产站点和灾备站点数据不一致:第一...显示全部

1.容灾切换主要涉及到网络层、应用层和存储层的切换,切换过程中制定好完整的流程和体系可以保障切换的顺利完成。如:切换流程、切换涉及到的步骤、切换对象、容灾演练(这个环节非常重要),建议切换前进行演练。
2.存储和数据库的切换,常见问题:
(1)生产站点和灾备站点数据不一致:

  • 第一个可能的原因是生产站点未将redo日志发送给容灾站点,l解决方案
    p登录dgmgrl,使用show database pripcc命令,排查生产站点的状态为TRANSPORT-ON,不是TRANSPORT-OFF。参考命令:EDIT DATABASE <database name> SET STATE = <state> [WITH APPLY INSTANCE = <instance name>];
    p使用show database dripcc LogShipping确认容灾站点数据库的LogShipping属性为ON
    p使用show database pripcc LogXptStatus确认redo传输服务的状态,如果状态错误,则根据错误原因和信息进行修复。
  • 第二个可能的原因是,容灾站点未apply生产站点传输过来的redo日志;l解决方案
    p确认容灾站点数据库未异常,如果异常,则查看alert日志,确认Redo应用停止的原因。
    p登录dgmgrl,使用show database dripcc命令,排查容灾站点的状态为APPLY-ON,不是APPLY-OFF。参考命令:EDIT DATABASE <database name> SET STATE = <state> [WITH APPLY INSTANCE = <instance name>];p使用show database dripcc delaymins确认该值没有设置为过大。
    (2)容灾端切换为主用端失败 ,原因是DGMGRL客户端没法自动拉起容灾端实例。解决方案:确认StaticConnectIdentifer配置正确: SHOW INSTANCE VERBOSE 'instance_name' ON DATABASE db_unique_name;
    p确认StaticConnectIdentifer对应的服务已经注册到监听器中,且是静态注册方式:lsnrctl status LISTENER
    (3)Apply停止且无法恢复 
    如果容灾端未提前创建好表空间目录,或者没有权限创建目录,则会导致容灾端没法正常应用Redo数据,最终导致Apply进程停止。可通过查看alert日志确认是否为该原因,日志中会有如下类似错误:

ORA-01186: file 5 failed verification tests

ORA-01157: cannot identify/lock data file 5 - see DBWR trace file

ORA-01111: name for data file 5 is unknown - rename to correct file

ORA-01110: data file 5: '/opt/oracle/product/11gR2/db/dbs/UNNAMED00005'

解决方案
p以sys用户登录生产端数据库,执行如下命令查看当前数据文件:select file#,name from v$datafile;
p以sys用户登录容灾端数据库,执行如下命令查看当前数据文件:select file#,name from v$datafile;
p此时容灾端将会有以UNNAMEXXX格式的数据文件,通过如下方式重新创建进行恢复。
n执行命令关闭文件自动管理功能:alter database set STANDBY_FILE_MANAGEMENT=MANUAL;
n使用如下命令依次重新创建数据文件,正确的数据文件如今参考生产端的位置:alter database create datafile '/opt/oracle/product/11gR2/db/dbs/UNNAMED00007' as '/opt/oradata/db_uidb/rdata12';
n执行命令重新开启文件自动管理功能:alter database set STANDBY_FILE_MANAGEMENT=AUTO;
n执行命令恢复容灾端数据库:recover automatic standby database;
p容灾端数据库恢复完成后,重新登录dgmgrl控制台,恢复apply状态:edit database dripcc set state = 'APPLY-ON';
注意:临时表空间文件不会自动同步,需要手工添加进行同步

收起
互联网服务 · 2021-11-17
浏览1057

提问者

shootman
解决方案架构师AIG
擅长领域: 服务器主机异地容灾

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2021-09-22
  • 关注会员:4 人
  • 问题浏览:1938
  • 最近回答:2021-12-06
  • X社区推广