備庫搭建中的一波三折

這幾天一臺伺服器出了硬體問題之後，這臺伺服器上的兩個備庫都殉職了，我們真是如坐針氈，畢竟沒有了備庫感覺就是裸奔，兩個庫差不多有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造成的檔案複製低效問題，根源還是在於網路的設定上
檔案複製較快的伺服器網路卡流量如下：

而檔案複製較慢的伺服器流量情況如下，可以看到兩者是相互補充的。至於為什麼先開始檔案複製的那臺伺服器就快很多，為什麼不是平均這部分資源。自己也沒有想明白。

一臺備庫搭建完成，另外一臺備庫速度也開始提升，心情都一下子美麗起來了。
備份重於一切，沒有備庫裸奔的感覺真是不踏實。對於硬體的監控也要全面注意起來，提前發現問題，提前部署方案。唉，就會少有一些無奈的悲劇。