转载

备库搭建中的一波三折

这几天一台服务器出了硬件问题之后，这台服务器上的两个备库都殉职了，我们真是如坐针毡，毕竟没有了备库感觉就是裸奔，两个库差不多有10T，搭一套备库也是颇有波折。
当服务器到了我手里之后，首先就开始准备安装数据库软件，安装前的基本检查很快做完了，需要预先安装的依赖包我看使用yum源已经识别了，我也标示了yes，然后开始克隆安装。
奇怪的是克隆安装显示成功，竟然sqlplus不可用。
$ sqlplus -v
sqlplus: error while loading shared libraries: libsqlplus.so: cannot open shared object file: No such file or directory
这个问题还比较简单，一般就是LD_LIBRARY_PATH没有设置
但是设置之后，重新relink发现报错信息变成了下面的样子。
$ sqlplus -v
sqlplus: error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory
查看这个链接文件，还确实是有问题。
$ ll libclnt*
lrwxrwxrwx. 1 oracle oinstall 59 Nov 17 05:45 libclntsh.so -> /U01/app/oracle/product/11.2.0.2/db_1/lib/libclntsh.so.11.1
lrwxrwxrwx. 1 oracle oinstall 54 Nov 17 05:45 libclntsh.so.10.1 -> /U01/app/oracle/product/11.2.0.2/db_1/lib/libclntsh.so
-rw-r--r--. 1 oracle oinstall 0 Sep 17 2011 libclntst11.a
最后发现是静默安装的时候把ORACLE_HOME写错了。ORACLE_HOME应该为11.2.3 结果自己在使用命令
perl clone.pl ORACLE_BASE=/U01/app/oracle ORACLE_HOME=/U01/app/oracle/product/11.2.0.2/db_1 ORACLE_HOME_NAME=OraDb10g_home1
不小心给标记成了11.2.0.2这样链接库文件在relink的时候就会错误链接
修改后又继续开始克隆安装，这次的错误更奇怪了。
$ sqlplus -v
sqlplus: error while loading shared libraries: /U01/app/oracle/product/11.2.0.2/db_1/lib/libclntsh.so.11.1: file too short
可以从下面看到两个链接文件都是空的。看来还是在relink的时候什么丢了，但是安装包都预安装了，怎么就不行啊。
$ ll libcln*
lrwxrwxrwx. 1 oracle oinstall 59 Nov 17 06:09 libclntsh.so -> /U01/app/oracle/product/11.2.0.2/db_1/lib/libclntsh.so.11.1
lrwxrwxrwx. 1 oracle oinstall 54 Nov 17 06:09 libclntsh.so.10.1 -> /U01/app/oracle/product/11.2.0.2/db_1/lib/libclntsh.so
-rw-r--r--. 1 oracle oinstall 0 Nov 17 06:10 libclntsh.so.11.1
-rw-r--r--. 1 oracle oinstall 0 Sep 17 2011 libclntst11.a
这个问题纠结了好一会，甚至怀疑是不是新机器出现了什么不兼容的地方，因为是比较新的920机器，最后查看了一下操作日志，发现原来原装yum源的时候就出了问题。
比如yum install xxxx的时候，有下面的日志，我选择yes
Install 5 Package(s)
Total download size: 15 M
Installed size: 33 M
Is this ok [y/N]: y
Downloading Packages:
Error Downloading Packages:
mpfr-2.4.1-6.el6.x86_64: failure: Packages/mpfr-2.4.1-6.el6.x86_64.rpm from base: [Errno 256] No more mirrors to try.
cloog-ppl-0.15.7-1.2.el6.x86_64: failure: Packages/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm from base: [Errno 256] No more mirrors to try.
结果最后显示都是Errno 256
最后简单配置yum源，mount /home/xxxxx /media/xxxx -o loop就搞定了
看来操作日志也是非常重要，要不到时候出了问题都没有依据。而且步骤的检查还是要仔细，老是返工也是费时费力。
好了，数据库软件安装不是一件难事，很快搞定，现在就开始使用duplicate的方式来同步文件了。
发现11g里面的rman同步着实很全面，如果上次同步中断取消，下次重新duplicate还可以做断点续传。
再次duplicate会有下面的日志信息
sql statement: alter database mount standby database
Using previous duplicated file /U01/app/oracle/oradata/xxx/xxx_data280.dbf for datafile 187 with checkpoint SCN of 220705796796
Using previous duplicated file /U01/app/oracle/oradata/xxx/xxx_data2.277.dbf for datafile 213 with checkpoint SCN of 220705796789
然后就是漫长的等待了，不过还有一个非常重要的地方需要注意就是主库的归档一定要保留好，如果定时删除，不小心多删了的话，那么长时间的等待就白费了。
所以也是一边关注主库的磁盘空间，一边关注文件复制的进度。
早上看了下，两个几乎同时开始复制的备库，早上醒来查看一个已经完成了2T,另外一个竟然还只完成了600G，差别也着实太大了。
目前知道唯一的差别就是2T的机器主库是raid5,600G的机器主库是raid10
当时差点得出了一个错误的结论，就是raid5比较挫。性能也差。
下午的时候，有一件事情特别纠结，有一个备库已经复制完成了近90%，但是主库的归档区域已经快满了，使用的是ASM,想临时压缩一下归档都没办法。删除归档吧，那备库就白搭了，不删除吧，主库的归档已经满了，新归档也会有影响。
就在这种纠结中，最后还是硬着头皮拖了一下，幸亏当时系统负载不算太大，所以这部分归档的影响还比较小，等备库一同步完，就开始开启RFS接收归档，然后马上释放主库的空间。
整个过程也是有条不紊的在进行。总算把这个问题缓冲了下来。
等到晚上6点多的时候，发现另外一台备库的文件复制速度开始大幅度提升，查看网卡的流量情况如下。
通过这个图可以看出其实不是raid5和raid10造成的文件复制低效问题，根源还是在于网络的设置上
文件复制较快的服务器网卡流量如下：
备库搭建中的一波三折