分类目录归档：Dataguard

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

发表于 2015 年 4 月 15 日 由 Lunar

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

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

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

发表于 2015 年 4 月 14 日 由 Lunar

又踩了个坑…… 今天同事告诉我前天调整一个数据库的参数，重启后，备库总报错： 初分析，这个错误有点怪异，有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的性能报告

发表于 2014 年 8 月 14 日 由 Lunar

后台执行一个脚本，模拟登录风暴 [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-安装篇和简介

发表于 2014 年 8 月 14 日 由 Lunar

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的切换）

发表于 2014 年 8 月 11 日 由 Lunar

当前环境： 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

发表于 2014 年 8 月 4 日 由 Lunar

环境介绍： 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

发表于 2013 年 10 月 18 日 由 Lunar

以下过程主要涉及如下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 | 标签为 , , , , | 留下评论