11g备库搭建碰到自己给自己埋的坑(r7笔记第63天)

记得之前在《一半技术一半生活》中分享过一个设计,因为业务的需求,为了提高业务的处理效率,采用了根据业务的拆库拆表的方式,类似下面的图示。

开发团队也很给力,帮我们协调了好的机器,加了内存,也在新业务2的环境上同步了表结构,抽取了部分数据,然后业务2就开始了紧张的测试, 通过这几天的测试,发现系统的性能逐步稳定下来。忙完了这茬,赶紧来考虑搭建备库。 自己也算是搭建过很多dataguard环境了,一般的环境中检测dataguard搭建成功与否的一种方式就是使用dg broker来验证,一条简单的show configuration命令如果显示SUCCESS则基本意味着备库搭建成功。所以新申请的机器也没有做过多的改动,感觉都是现成的了。 这个环境有一些特殊,特殊之处就是主库为ASM存储,备库为普通文件系统,所以主要的工作就是设置两个convert参数了。使用dg broker能够给予我们非常多的便利。这也是越来越依赖dg broker的原因,搭建备库还是采用最经典的active dupliate方式。 > rman target sys@testbi auxiliary sys@stestbi nocatalog >duplicate target database for standby from active database nofilenamecheck; 同步很快就完成了,然后我就开始设置dg broker的配置。 create configuration dg_testbi as primary database is testbi connect identifier is testbi; add database stestbi as connect identifier is stestbi maintained as physical; 设置完毕,手工检查show configuartion为success DGMGRL> enable configuration; Enabled. DGMGRL> show configuration; Configuration - dg_testbi Protection Mode: MaxPerformance Databases: testbi - Primary database stestbi - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS 看起来一切都在计划和控制之中。准备手工,但是发现一个比较奇怪的问题,就是备库是11gR2的,但是无法启动到open阶段。 手工尝试启动直接报错。 SQL> alter database open; alter database open * ERROR at line 1: ORA-10458: standby database requires recovery ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/home/U01/app/oracle/oradata/testbi/datafile/system.407.899224793' 看这个情况是备份集出现了问题。 这个时候再次查看dg broker的状态就会有错误 Error: ORA-16724: cannot resolve gap for one or more standby databases DGMGRL> show configuration; Configuration - dg_testbi Protection Mode: MaxPerformance Databases: testbi - Primary database Error: ORA-16724: cannot resolve gap for one or more standby databases stestbi - Physical standby database Fast-Start Failover: DISABLED Configuration Status: ERROR 如此一来这个备库还是有一些问题,尝试查看fal_client,fal_servre的设置也没有发现任何问题。但是侥幸重新设置配置,竟然又成功了。 DGMGRL> remove configuration; Removed configuration DGMGRL> create configuration dg_testbi as primary database is testbi connect identifier is testbi; Configuration "dg_testbi" created with primary database "testbi" DGMGRL> add database stestbi as connect identifier is stestbi maintained as physical; Database "stestbi" added DGMGRL> enable configuration; Enabled. DGMGRL> show configuration; Configuration - dg_testbi Protection Mode: MaxPerformance Databases: testbi - Primary database stestbi - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS 然后再次open,问题依旧,这可是11gR2的库,ADG也要求不高,问题依旧是 Error: ORA-16724: cannot resolve gap for one or more standby databases 当然设置显示为SUCCESS,我使用verbose的方式查看备库的情况,发现已经有了近4个半小时的延时。 DGMGRL> show database stestbi; Database - stestbi Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: (unknown) Apply Lag: 4 hours 29 minutes 48 seconds Real Time Query: OFF Instance(s): testbi Database Status: SUCCESS DGMGRL> DGMGRL> exit 这部分日志就是不应用,从后台日志也可以看出,只用RFS工作,查看MRP也没有抛出什么错误来。 当然这个问题看起来蛮奇怪,还是需要反复验证,尝试取消日志应用,然后把备库开启到read only状态,11gR2默认会把它再设置为real time apply的方式,从日志里也可以看出。 备库中的alert日志内容如下: Managed Standby Recovery starting Real Time Apply Media Recovery Waiting for thread 1 sequence 101 Wed Dec 30 23:00:34 2015 Standby crash recovery need archive log for thread 1 sequence 101 to continue. Please verify that primary database is transporting redo logs to the standby database. Wait timeout: thread 1 sequence 101 Standby crash recovery aborted due to error 16016. Errors in file /home/U01/app/oracle/diag/rdbms/stestbi/testbi/trace/testbi_ora_3241.trc: ORA-16016: archived log for thread 1 sequence# 101 unavailable Recovery interrupted! Completed standby crash recovery. Signalling error 1152 for datafile 1! Errors in file /home/U01/app/oracle/diag/rdbms/stestbi/testbi/trace/testbi_ora_3241.trc: ORA-10458: standby database requires recovery ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/home/U01/app/oracle/oradata/testbi/datafile/system.407.899224793' ORA-10458 signalled during: alter database open... 可以发现原来备库中已经接收不到序列号为101的归档了。 在备库中查看,确实只有102开头的归档了,那么101的归档呢。 这个时候回过头来再看,发现主库竟然默默在运行着一个crontab 任务。而且触发频率较高。 0,15,30,45 * * * * $HOME/dbadmin/scripts/rm_archive.sh 查看这个脚本的内容,已经让我心灰意冷。这个脚本本身还是存在一些问题,算是直接删除归档的节奏。也没有判断是否应用到备库。 #!/bin/bash . ~oracle/.bash_profile rman target / < CONFIGURE ARCHIVELOG DELETION POLICY TO none; crosscheck archivelog all; delete noprompt expired archivelog all; delete noprompt archivelog until time "sysdate-1/12"; exit EOF 当然我们需要修改一下。 至少得让归档应用到备库去。 CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; crosscheck archivelog all; delete noprompt expired archivelog all; delete noprompt archivelog until time "sysdate-1"; 看来自己真是给自己埋了一个坑,自己也毫不犹豫就跳了进去,等回过头来,发现又是一场白忙活,因为库不是很大,如果统计库几个T,几十个T,那就绝对会被耗掉意志。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-12-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏芋道源码1024

IntelliJ IDEA 内存优化最佳实践

【编者按】本文作者在和同事的一次讨论中发现,对 IntelliJ IDEA 内存采用不同的设置方案,会对 IDE 的速度和响应能力产生不同的影响。

48170
来自专栏phodal

使用 OpenWhisk 自建 Serverless 服务

在尝试了使用 AWS 开发 Serverless 应用之后,我便想尝试使用 OpenWhisk 框架来搭建自己的 Serverless 服务。 Apache O...

51550
来自专栏魏琼东

AgileEAS.NET SOA 中间件平台5.2版本下载、配置学习(一):下载平台并基于直连环境运行

一、前言      AgileEAS.NET SOA 中间件平台是一款基于基于敏捷并行开发思想和Microsoft .Net构件(组件)开发技术而构建的一个快速...

27870
来自专栏张善友的专栏

REST In WCF4.0

REST软件架构是由Roy Thomas Fielding博士2000年在他的论文《Architectural Styles and the Design o...

200100
来自专栏张善友的专栏

开源数据库PostgreSQL发布了v9.2版

PostgreSQL是一种著名的开源数据库。最近PostgreSQL全球开发小组发布了最新的9.2版本,对性能做出了极大提升,并增加了对JSON的内建支持。 早...

19750
来自专栏Java进阶架构师

IntelliJ IDEA 内存优化最佳实践

原文链接::http://blog.oneapm.com/apm-tech/426.html

9020
来自专栏陈树义

你绝不能错过的效率神器 —— Alfred

? Alfred 是 Mac 系统上一款专注于效率提升的著名应用,它能帮你快速打开网页、快速进行自定义搜索、查看剪贴板历史、快速查询单词等等。Alfred 提...

1.2K70
来自专栏Linyb极客之路

Spring Boot十种安全措施

10710
来自专栏FreeBuf

现代版荆轲刺秦王:Struts2 REST插件漏洞分析

战国末期,大秦实力强盛,大有横扫六合之势,在灭了韩、赵两国后,下一个目标就是燕国。

11120
来自专栏java一日一条

服务熔断、降级、限流、异步RPC -- HyStrix

在今天,基于SOA的架构已经大行其道。伴随着架构的SOA化,相关联的服务熔断、降级、限流等思想,也在各种技术讲座中频繁出现。本文将结合Netflix开源的Hys...

46930

扫码关注云+社区

领取腾讯云代金券