某项目一个11g的老库集群3节点已运行多年，目前有一个adg备库用于读写分离。由于使用的老存储已无法扩容，主磁盘组空间捉襟见肘，不得已借用多次FRA的空间用于扩容表空间。
为临时解决空间不足的现状，临时申请1台物理主机新构建adg用于替换原有adg备库，释放存储给主集群。
新申请的主机测试不充分，后期发现与主集群之间带宽仅有50-60MB/s，为后期实施带来了困难，同时新主机未能提供同版本的CentOS6.5，而是7.4，也为后续实施造成了麻烦，尽管解决掉了问题，但是不得不说，这些时间浪费成本也不低。
本次采用duplicate的方式在线创建备库，所以不需停止主库集群，拷贝的是物理文件，理论上只会对主库集群的存储的整体io性能形成一定影响，正常是可以忽略不计的，但是如果原存储整体io负荷已经较高，那么会对某些大io的应用造成一定的影响。
但是同步期间白天一直在观察主集群，主库集群的性能并没有问题，监控显示应用一切正常，夜间并没有观察性能情况，但是项目反馈有晚间的后台接口数据汇总等应用变慢，因此怀疑存储整体io等待已经比较高，这个可以通过awr报告进行确认。
以下是具体的实施步骤概要，记录于此，以供参考。
一、修改主备机的/etc/hosts文件
二、定义主备库
包括db_unique_name、db_name、instance_name、service_name
我的实施习惯是，为简单、易于理解计，只db_unique_name设置为唯一，其他几个值主备库保持一致即可
三、确认主库的归档模式
select LOG_MODE,OPEN_MODE,FORCE_LOGGING from v$database;
确认主库处于归档模式，且强制归档。
四、在主库创建备库参数文件并拷贝到备库
此处由于已有备库，则直接把已有备库的配置文件简单修改即可
同时配置里面的相关路径，需要事先建好，尤其是11g，需要事先建好datafile/tempfile/onlinelog/controlfile等相关目录，否则会遭遇ORA-17628错误！
五、备库启动到nomount状态
六、主库密码文件拷贝到备库
七、配置主库及备库的tnsnames.ora
由于备库日志应用是基于tnsnames连接，所以需确保tnsping那几个service可用
【注：即使是RAC环境，也只需配置oracle用户的tnsnames.ora】
配置adg节点时，为使nomount的数据库可以远程连接，10G之前只能使用静态注册，10G之后除了使用静态注册之外，还有个更简单的方法，就是在TNS配置中加入UR=A选项即可，即使服务状态是BLOCKED。这对于连接到Auxilary instance的时候非常有用，否则只能采用OS认证方式。如下所示
JKDBADG2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.209.xx.xx)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = jkdb)
(UR=A)
)
)
用这个方法以后，即无需专门配置静态监听了，用系统默认的监听配置即可!
八、测试主机连通性
主备库都要执行，确认均可以免密登录成功
sqlplus sys/passwd@JKDB as sysdba
sqlplus sys/passwd@JKDB1 as sysdba
sqlplus sys/passwd@JKDB2 as sysdba
sqlplus sys/passwd@JKDB3 as sysdba
sqlplus sys/passwd@JKDBADG as sysdba
sqlplus sys/passwd@JKDBADG2 as sysdba
九、修改主库
此处只需修改3个参数即可，无需重启数据库
alter system set log_archive_config='DG_CONFIG=(jkdb,jkdbadg,jkdbadg2)' scope=both sid='*'; alter system set log_archive_dest_3='service=jkdbadg2 lgwr sync valid_for=(online_logfiles,primary_role) db_unique_name=jkdbadg2' scope=both sid='*'; alter system set log_archive_dest_state_3=defer scope=both sid='*'; --alter system set log_archive_dest_state_3=enable scope=both sid='*';
十、备库恢复
2T多的数据库，这一步耗时11小时，由于主库空间受限，归档日志保留时间受限，所以同时将恢复期间的归档另存下来，以备后续可能使用，由于期间涉及的归档达到800多个，只能在删除前迅速保存在一个可用位置，并及时另存，以免同时被清理掉。这800多个归档的保存脚本，花费好几个小时！还好我用比较易用的文本编辑工具，给我省了不少时间。
恢复完毕以后的日志同步、apply又执行了6、7个小时才达到了realtime apply状态。
在此也吐槽一下oracle的这个同步过程不够合理，在duplicate时并未同步传输归档，只在duplicate完毕才开始同步duplicate开始时就拉下的归档！如果在duplicate一开始就同步传输归档，会省却这个手动备份脚本的编写和执行过程。
后附，新备库jkadg2初始化同步期间的网络流量、磁盘流量统计情况
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 0 100 0 0 0| 0 24k| 56M 769k| 0 0 | 28k 29k 0 0 100 0 0 0| 0 0 | 57M 774k| 0 0 | 27k 29k 0 0 100 0 0 0| 0 16k| 56M 647k| 0 0 | 20k 24k 0 0 100 0 0 0| 0 0 | 55M 681k| 0 0 | 22k 25k 0 0 100 0 0 0| 0 0 | 56M 663k| 0 0 | 21k 24k 0 0 100 0 0 0| 0 16k| 56M 686k| 0 0 | 23k 25k 0 0 100 0 0 0| 0 0 | 56M 739k| 0 0 | 26k 29k 0 0 100 0 0 0| 0 581k| 56M 621k| 0 0 | 19k 23k 0 0 100 0 0 0| 0 16k| 55M 670k| 0 0 | 22k 25k 0 0 100 0 0 0| 0 0 | 56M 655k| 0 0 | 21k 24k 0 0 100 0 0 0| 0 0 | 54M 678k| 0 0 | 23k 26k 0 0 100 0 0 0| 0 16k| 51M 729k| 0 0 | 27k 29k 0 0 100 0 0 0| 0 0 | 52M 787k| 0 0 | 30k 32k 0 0 100 0 0 0| 0 0 | 50M 654k| 0 0 | 21k 26k 0 0 100 0 0 0| 0 16k| 55M 712k| 0 0 | 24k 27k 0 0 100 0 0 0| 0 0 | 56M 715k| 0 0 | 24k 27k 0 0 100 0 0 0| 0 0 | 56M 760k| 0 0 | 27k 30k 0 1 99 1 0 0| 0 1210M| 56M 703k| 0 0 | 25k 27k 0 0 100 0 0 0| 0 0 | 55M 737k| 0 0 | 25k 28k 0 0 100 0 0 0| 0 0 | 56M 760k| 0 0 | 26k 29k 0 0 100 0 0 0| 0 16k| 55M 869k| 0 0 | 30k 32k 0 0 100 0 0 0| 0 0 | 55M 731k| 0 0 | 26k 29k 0 0 100 0 0 0| 0 0 | 55M 706k| 0 0 | 25k 29k 0 0 100 0 0 0| 0 40k| 55M 719k| 0 0 | 23k 27k 0 0 100 0 0 0| 0 0 | 56M 837k| 0 0 | 32k 34k 0 0 100 0 0 0| 0 0 | 52M 769k| 0 0 | 29k 32k 0 0 100 0 0 0| 0 16k| 49M 685k| 0 0 | 24k 28k 0 0 100 0 0 0| 0 230M| 51M 667k| 0 0 | 23k 26k 0 0 100 0 0 0| 0 168M| 53M 740k| 0 0 | 26k 30k
文章评论