分类目录归档:Dataguard

ADG备库由于控制文件,归档损坏等原因,不能switchover,failover和active standby database时

昨天损坏的备库,今天准备激活,然后做升级测试。 备库由于归档损坏,已经不能用常规手段switchover和failover,甚至直接激活也不能: 重启数据库后,重建控制文件,然后open resetlogs: 激活数据库: 最后在备库添加temp文件:

发表在 backup&recovery, Dataguard | 标签为 , , | 留下评论

OEL6.2 EXT4 filesystemio_options=SETALL造成archivelog坏块

又踩了个坑…… 今天同事告诉我前天调整一个数据库的参数,重启后,备库总报错: 初分析,这个错误有点怪异,有redo 头损坏,有“Possible network disconnect with primary database” 尝试clear online redo log和standby redo log,没用 尝试在主库重建控制文件,然后再直接重启备库,还是上面的错误。 冷静下来,感觉不对劲,检查主库和备库,发现主库归档日志是按照sequence顺序生成 备库则是断断续续的,有的可以从主库传过来,有的传不过来 手工传过来,APPLY还是报错: 感觉是arch异常了,而且貌似所有报错的,都是没有从主库传过来的 而所有没传过来的,都是损坏的,因此手工传过来也没用,因此抽取一个arch进行校验: 结果显示,确实arch损坏了。 . 根据问题发生的时间,想起来那天调整数据库参数的时候,有一个filesystemio_options=SETALL 也就是调整文件系统AIO方式的,去年在公司还给大家发邮件说起来“ext4上不要使用 filesystemio_options=SETALL” 否则会造成数据库坏块,没想到今年自己被坑了……(哇哇大哭啊……) 具体可以参见Oracle 文档: ORA-1578 ORA-353 ORA-19599 Corrupt blocks with zeros when filesystemio_options=SETALL on ext4 … 继续阅读

发表在 backup&recovery, Dataguard | 标签为 , , | 留下评论

使用statspack监控Active Dataguard的性能—2-创建ADG的性能报告

后台执行一个脚本,模拟登录风暴 [oracle@lunar ~]$ nohup ./login.sh & [1] 27907 [oracle@lunar ~]$ nohup: appending output to `nohup.out’ [oracle@lunar ~]$ jobs [1]+ Running nohup ./login.sh & [oracle@lunar ~]$ jobs [1]+ Running nohup ./login.sh & [oracle@lunar ~]$ jobs [1]+ Running nohup ./login.sh & [oracle@lunar … 继续阅读

发表在 Dataguard | 一条评论

使用statspack监控Active Dataguard的性能—1-安装篇和简介

Statspack的功能早在Oracle 8.1.6就可以使用(Oracle 8.1.7正式随产品发布),这里不再赘述,baidu google上大把大把的…… 从Oracle 10.1开始,Oracle引入了AWR(Automatic Workload Repository),其功能较之statspack不是强大了一星半点(AWR,ASH,ADDM,SPA,SPM……),statspack一度在10g后被搁置了…… 随着Oracle 11.1 ADG的出现,Statspack有了新的用途……我们都知道ADG是只读打开的,其awr跟主库的是一致的,监控ADG上的查询业务的功能,又变成了使用脚本和crontab等的手工作坊式管理……Oracle为此给statspack增加了新的功能: @?/rdbms/admin/sb* 在statspack目录下($ORACLE_HOME/rdbms/admin/),有两类statsapck相关的文件: 前面的sp开头的应该都不陌生,跟9i和8i的都一样的: 后面sb开头的是ADG中在备库上使用的一套脚本(sb,也就是standby): 具体的安装过程,参加下面的附件sbcreate 如果ADG是RAC,那么需要使用sbaddins.sql将其余的节点加入到statspack中。

发表在 Dataguard, Performence Tuning | 标签为 , , , | 一条评论

Cascade Standby切换测试(级联ADG的切换)

当前环境: A: 当前是Primary ,Oracle 11.2.0.3,本次切换后为Physical Standby B: 当前是Physical Standby,本次切换后为Cascade Standby(因为这个库是11.2.0.4,版本不一致,因此只能做standby,不能open) C:当前是Cascade Standby,Oracle 11.2.0.3,本次切换后为Primary ============================================================================================================ 1,级联环境下,如果到Cascade的路径是enable,则在做switchover时,主库上查询会报:“RESOLVABLE GAP” 解决方法是将主库到cascade的归档路径设置为defer ; ============================================================================================================ ============================================================================================================ 2,如果主库到备库的归档路径(A到B的)是defer,那么switchover时,检查主库状态会是“NOT ALLOWED”: 解决方法是: 将A到B的路径设置为enable ============================================================================================================ ============================================================================================================ 将A库切换为Standby: ============================================================================================================ ============================================================================================================ 3,同理,Cascade不能切换为Primary,也需要enable C库到A库的归档路径: ============================================================================================================ ============================================================================================================ 4,还需要B库到C库的归档路径: ============================================================================================================ ============================================================================================================ 将C切换为primary: ============================================================================================================ 检查C库: ============================================================================================================ … 继续阅读

发表在 Dataguard | 标签为 , , | 留下评论

配置Cascade Standby

环境介绍: 1,VM1: OEL5.8+Oracle 11.2.0.3,考虑到笔记本的性能不行,因此最初考虑的是这个VM兼顾了Physical Primary 和Casecade Standby的重任。数据库是文件系统 2,VM2: OEL5.10+11.2.0.4,数据库是ASM的环境(Oracle Restart),作为Physical Standby。 考虑到版本兼容的问题,下一篇我讲切换他们的角色; 1,让VM2做为Cascade Standby的角色(因为不同版本,不能使用正常的open,只能open upgrade,因此,如果作为Physical Standby的话,不能放倒Open read only上)。 2,让VM1上的2个11.2.0.3的库分别作为Primary和Physical standby角色 创建standby controlfile和pfile: 创建需要的目录: 使用备份进行恢复: 使用screen在后台传输rman备份集: 安装cascade的screen(这个步骤跟本次操作没有关系,不过是临时遇到了,顺手做了一下): 配置主库的参数: Physical Standby的参数文件: Cascade Standby的参数: 其余的过程就简单了,跟普通的ADG没什么分别: 1,分别在physical standby和cascade standby上做恢复standby controlfile和restore database。 2,使用alter database recover … 继续阅读

发表在 Dataguard | 标签为 , , | 留下评论

基于scn恢复ADG和ASM在rman备份恢复过程中的tuning

以下过程主要涉及如下3个问题: 1,根据SCN号“重做”ADG 2,主库是ASM数据库,使用了一半自动命名文件名的文件,和一部分手工指定文件名(别名)的文件: ——————————————————————————– 针对OMF的数据文件使用下面命令: catalog start with ‘+DATA1/MUM/DATAFILE/’; 针对非OFM的数据文件使用下面命令: catalog datafilecopy ‘<File-Specification>’; ——————————————————————————– 3,优化ASM的IO效率 源库: 备库: 查看主库force logging: 查看有哪些文件含有force logging操作,以及他们的scn(下次执行,应该带上orderby,这样更清晰): 备库: 生成批量的backup命令,进行基于scn的恢复(含有force logging的都需要) 主库,备份可以有两个方法: 1,根据上述备份命令写备份脚本 2,从最早的一个scn开始备份也可以 restore 数据文件: 总共新增加了3个文件,重新备份这3个文件即可: 现有ASM的文件信息如下: 有两个错误,这个是因为上面操作时没有注意到数据库中有2个offline的数据文件,下次操作记得备份时把offline的文件不要备份就好了。。。。。。 <bold>开始recover database,这个过程非常慢长,主要原因: 1,存储着实太差了。。。。。。 2,网络速度太差了(这个是NFS的空间) 3,ASM在recover 时需要tuning </bold> 监控rman恢复进度: … 继续阅读

发表在 ASM, backup&recovery, Dataguard | 标签为 , , , , | 留下评论