備庫密碼檔案問題一波三折的插曲

昨天下午開始給一個新環境搭備庫，本來想一兩個小時全速搞定，沒想到因為密碼檔案的問題耽擱了，整個過程也是一波三折，希望大家能夠吸取過程之中的經驗和教訓。
首先這個環境沒有安裝oracle軟體，只安裝了作業系統，所以搭建備庫先需要安裝資料庫軟體，然後開始從主庫使用duplicate的方式同步資料檔案，然後用dg broker來配置即可。
沒有安裝資料庫軟體，又沒有圖形介面，也好辦，採用克隆方式安裝
首先在主庫中發現$ORALE_HOME下有一個壓縮包，看來已經提前準備好了。
/U01/app/oracle/product]$ ll
total 2288996
drwxrwxr-x 3 oracle oinstall       4096 Mar 20  2012 11.2.3
-rw-r--r-- 1 root   root     2341630235 Aug  4 18:11 11.2.3.tgz
從檔案內容來看壓縮包實在近期壓縮的，所以還是一個比較新的包，直接複製到備庫就能用了。
$ file 11.2.3.tgz
11.2.3.tgz: gzip compressed data, from Unix, last modified: Fri Jul 31 11:48:23 2015
複製過去之後，建立使用者，使用者組，然後在備庫的$ORACLE_HOME/clone/bin下直接執行下面的指令碼就會開始克隆安裝。大概一兩分鐘資料庫軟體就安裝好了。
perl clone.pl ORACLE_BASE=/U01/app/oracle ORACLE_HOME=/U01/app/oracle/product/11.2.3/db_1  ORACLE_HOME_NAME=OraDb11g_home1
然後配置網路服務，準備就開始使用duplicate的方式同步備庫了。
但是在開始同步前發現就卡在了密碼檔案上。
因為使用tns連線的時候報了ORA錯誤。
/U01/app/oracle/product/11.2.3/db_1/dbs]$ sqlplus  sys@s2test as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 8 19:19:13 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
ERROR:
ORA-01017: invalid username/password; logon denied
透過這個錯誤可以得知應該是密碼錯誤，但是密碼檔案沒有做任何的改動也是從主庫複製過來的。
在備庫透過tns連線主庫就沒有問題。
/U01/app/oracle/product/11.2.3/db_1/network/admin]$ sqlplus sys@test as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 00:00:20 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>

這個時候因為一直堅信密碼檔案沒有做任何變動，所以注意力就集中在了其它的方面，首先是主機名上，發現主機名和主庫的uniq_name有些衝突，感覺是主機名導致的，就開始嘗試改主機名，改了之後發現錯誤果真變了。
$ sqlplus sys@s2test as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 8 19:21:18 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
ERROR:
ORA-21561: OID generation failed
這個錯誤比較熟悉，和/etc/hosts的配置相關，所以修復之後還是依舊提示備庫密碼錯誤。
這個時候進一步排查，如果密碼檔案沒有成功啟用，是不是和系統級的許可權有關，結果檢視到使用者的id,使用者組時，發現了一點問題。

備庫中的id為
$ id oracle
uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba)
主庫中的id為
$ id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)
可以看到使用者組的id還是有一些差別，所以有種強烈的感覺就是問題應該出在這個地方，對於rac中這個差別還是很嚴重的，沒想到在dataguard中也有這樣的影響。
於是開始修改使用者組。
# usermod -u 501 oracle
# id oracle
uid=501(oracle) gid=500(oinstall) groups=500(oinstall),501(dba)
發現使用者組沒有生效。但是/etc/group中已經生效了
# cat /etc/group|grep oinstall
oinstall:x:501:
繼續改動，這樣就可以了。
# usermod -g oinstall -G dba oracle
# id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)
不過使用者組修改完成，使用者下的檔案的屬主還是有問題，組名顯示成了500
/U01/app/oracle/product/11.2.3/db_1/dbs]$ ll
total 12
-rw-r--r-- 1 500 500  953 Oct  8 17:25 inittest.ora
-rw-r----- 1 500 500 1536 Jun 17  2013 orapwtest
-rw-r----- 1 500 500 2560 Oct  8 19:44 spfiletest.ora
所以最後還是重新安裝資料庫軟體了事，安裝完之後，帶著期待繼續嘗試，發現問題還是沒有解決。
$ sqlplus sys@s2test as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 00:00:13 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
ERROR:
ORA-01017: invalid username/password; logon denied
透過tns連線主庫還是正常。
然後反覆測試還發現一個更加奇怪的現象。初步感覺是許可權哪裡出了問題，於是嘗試先把密碼檔案改成777的許可權。
$ chmod 777 orapwtest
$ ll orapwtest
-rwxrwxrwx 1 oracle oinstall 1536 Jun 17  2013 orapwtest
然後繼續嘗試登入。
$ sqlplus sys@s2test as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 19:45:43 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
ERROR:
ORA-01017: invalid username/password; logon denied
拋完錯誤之後再次檢視密碼檔案，發現原有的密碼檔案的許可權又恢復成了最開始狀態。
$ ll orapwtl*
-rw-r----- 1 oracle oinstall 1536 Jun 17  2013 orapwtest
反覆嘗試都是如此，自己甚至懷疑是不是oracle的網路服務相關的軟體包出了問題，或者是什麼bug導致的。
最後看著密碼檔案，覺得還是要驗證一下，首先密碼檔案中的內容是無法讀到的，單純看朱備庫的檔案大小都是1536位元組，時間點也比較早，想必一直也沒有改動過。
最後甚至動用了strace來做診斷，結果竟然還是沒有發現任何的差別，可見系統級還是沒有什麼差別的。
那麼密碼檔案怎麼來解析看看主備庫是否一致呢。直接解析不成，我們使用strings來做。
主庫中的密碼檔案trace如下：
$ strings orapwtest
]\[Z
ORACLE Remote Password file
INTERNAL
9B811A3069EE43B6
3C0E90D8664116E3
bF(0
備庫中的密碼檔案trace如下：
$ strings orapwtest
]\[Z
ORACLE Remote Password file
INTERNAL
F309445D01B9354C
bHB!
B3EBA9B843B3A7D2

可以看出還是存在明顯的不同，再次手工複製一份密碼檔案到備庫，再做一次trace
$ strings orapwtest
]\[Z
ORACLE Remote Password file
INTERNAL
9B811A3069EE43B6
3C0E90D8664116E3
bF(0
這次就和主庫一致了，儘管時間戳不同，但是從trace來看內容是一致的了。
$ ll orapwtest
-rw-r----- 1 oracle oinstall 1536 Oct  9 19:52 orapwtest
然後再次嘗試，就正常了。
$ sqlplus sys@s2tset as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 19:53:39 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
Connected to an idle instance.

問題到此還沒有結束，自己還是對於使用者組的問題帶有疑惑，趁熱打鐵，把環境刷掉，再試一試使用者組不同的時候，是否有影響，
# groupmod -g 506 oinstall
# id oracle
uid=501(oracle) gid=501 groups=501,502(dba)
# usermod -g oinstall -G dba oracle
# id oracle
uid=501(oracle) gid=506(oinstall) groups=506(oinstall),502(dba)
然後把原來的$ORACLE_HOME刪掉重新克隆安裝一遍。重新同步密碼檔案，嘗試發現還是可以的。
$ sqlplus sys@s2test as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 20:07:05 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
Connected to an idle instance.
SQL>
所以這個時候自己基本可以論證出問題不在主機名，不在使用者組的id，而是因為密碼檔案的不同導致了這麼多的插曲，自己也嘗試了各種方法，儘管知道問題出在密碼檔案上，但是竟然沒有專門去驗證一下密碼檔案，帶著想當然的態度認為壓縮包最近更新的，所以密碼檔案應該是一樣的。這個經驗教訓很深刻，大家也需要注意一下。