數(shù)據(jù)庫作為生產(chǎn)系統(tǒng)的核心基礎(chǔ)，關(guān)于穩(wěn)定、可靠的要求從來都不會少，采用雙節(jié)點的高可用集群是非常普遍的解決方案，各種安裝部署的文檔也非常容易獲得。然而，實際環(huán)境的差異又帶來安裝過程中經(jīng)驗之外的各種情況，需要各個擊破。

配置環(huán)境

本例的環(huán)境兩臺雙路物理服務(wù)器，操作系統(tǒng)采用rhel6.5x64安裝在服務(wù)器本地磁盤，共享磁盤連接到FCSAN存儲，劃分了2TB數(shù)據(jù)、3個50GB仲裁、2TB歸檔共5個卷，多路徑采用系統(tǒng)自帶multipath，分別設(shè)置兩個服務(wù)器啟動iptables防火墻相互放行集群中分配的所有IP和端口。

與11g比較preinstall操作的差異

RAC集群的安裝需要Grid用戶的ssh互信，在11g時代需要手工完成，即集群節(jié)點需要分別創(chuàng)建用于ssh的rsa密鑰對，并將自己的公鑰傳遞給其他節(jié)點的authorized_keys。理解和操作雖然不難，但步驟還是相對麻煩。在12c的Grid安裝向?qū)е?，已然可以免去手工?chuàng)建，能夠在ui界面自動完成這一操作，大大方便了安裝前準備。與此同時，Oracle用戶在database安裝時也需要配置ssh互信，這是11g所不需要的，同樣在ui界面上輕松完成。

limits.conf文 件 是LinuxPAM插入式認證模塊（Pluggable Authentication Modules） 中 pam_limits.so的配置文件，它用于突破系統(tǒng)的默認限制，對系統(tǒng)訪問資源有一定保護作用，需要分別設(shè)置Oracle和Grid兩個用戶的軟硬限制，通過oracle-rdbms-server-12cR1-preinstall這 個rpm包只添加了Oracle用戶的配置項，還需要手工補充Grid用戶配置項，并且Oracle用戶的配置寫到/etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf文件，Grid安裝ui的修復(fù)選項則是將配置項添加到/etc/sysconfig/limits.conf，在檢查配置時容易造成混淆。

除此之外，12c比11g還多出memlock配置，且要根據(jù)hugememory是否開啟而不同，memlock的大小依據(jù)free -t的total*0.9而定，多配或少配都會導(dǎo)致檢查警告。12c的文檔并沒有明顯說明/dev/shm的大小，但與11g中一致，仍需要設(shè)置和物理內(nèi)存一樣大，否則Grid自檢不通過。

自檢提示device checks for asm問題

Grid安裝ui自檢遇到device checks for asm問題，搜索后確認是oracleasm configure -i初始化時沒有正確設(shè)置Grid用戶和asmdba用戶組導(dǎo)致的，而當前創(chuàng)建的asm盤都是oracle:dba的權(quán)限，需要刪除磁盤調(diào)整。然而，在第一個節(jié)點始終無法刪除已創(chuàng)建的asm盤，即使用命令service oracleasm stop停止服務(wù)也不行，不過直接用真實路徑卻能夠順利刪除。

刪除檢查兩個節(jié)點的asm共享盤均已消失，重啟asm服務(wù)后重新添加。然而grid安裝的ui自檢仍提示相同的錯誤，只是報錯內(nèi)容已變成multipath相關(guān)，系多路徑聚合后的磁盤權(quán)限問題，當前共享卷的在文件系統(tǒng)上的虛擬設(shè)備權(quán)限均為root:root，為asm能正確利用，也需要設(shè)置為grid:asmadmin權(quán)限。

先通過multipath –ll和/sbin/scsi_id -g -u /dev/sdx命令確認每個共享盤的scsi_id和/dev/sdx對應(yīng)關(guān)系，然后以udev規(guī)則設(shè)定共享卷權(quán)限：

重啟操作系統(tǒng)后，再次執(zhí)行g(shù)rid安裝不再出現(xiàn)報錯和警告。

節(jié)點二執(zhí)行root.sh失敗

Grid安裝進行到末尾，需要分別在節(jié)點上執(zhí)行腳本，11g是需要人工執(zhí)行的，而12c則可勾選自動執(zhí)行節(jié)點上的腳本，為了偷懶勾選了自動執(zhí)行。第一個節(jié)點上腳本執(zhí)行順利無誤，在第二個節(jié)點執(zhí)行時遇到報錯[INS-32148] Execution of ‘GI Install’ script failed on nodes: [rac2]。查看日志詳細信息，描述在第一個節(jié)點成功執(zhí)行完，而節(jié)點二無法在3600秒內(nèi)以root身份執(zhí)行，腳本在/u01/app/12.1.0/grid_1/crs/install/crsutils.pm的第3681行掛死掉。

上網(wǎng)搜索資料，有描述是multipath權(quán)限問題，有描述是安裝介質(zhì)存在Bug，需要在安裝過程中修補一個編號為18456643的補丁，官網(wǎng)的metalink對這一問題的解答也并不集中。由于介質(zhì)是成功安裝過rac的，故而暫時排除介質(zhì)問題，先從其他方面入手。

首先摸排腳本的執(zhí)行，通過命令/u01/app/12.1.0/grid_1/crs/install/rootcrs.pl -verbose-deconfig -force反向配置已執(zhí)行的腳本，然后重新執(zhí)行rootcrs.pl腳本。雖然順利通過了上述中斷的位置，但和心里預(yù)想的結(jié)果一樣，如果這樣能夠成功早就安裝成功了。為了排除腳本反復(fù)執(zhí)行的殘留等影響，決定先對兩個節(jié)點已安裝的Grid進行卸載。

根據(jù)官方文檔，卸載當前的Grid需要分別在兩個節(jié)點調(diào)用安裝介質(zhì)的腳本，命 令 為 ：runInstaller-deinstall -home /u01/app/12.1.0/grid_1/

兩個節(jié)點的腳本執(zhí)行都遇到無法刪除的對象，存在一些報錯，但卸載總體認為成功。重啟Linux并手工刪除/u01/app/grid/目錄下未自動清理的文件。

再次安裝Grid軟件，在自檢時又出現(xiàn)device checks for asm的 問題，這次報的還是/etc/multipath.conf權(quán)限問題。在兩個節(jié)點上都報相同的PRVG-5150錯誤代碼，描述的是“無法確定路徑/dev/oracleasm/disks/OCRVOTE1是否在所有節(jié)點上都為有效路徑”。搜索官方文檔指向該問題是一個編號為18824041的Bug造成的，官方文檔的建議是忽略即可。雖然總覺得安裝過程有任何報錯或警告都可能影響未來穩(wěn)定運行，但既然官方文檔都這么說明了，暫時放下心中的糾結(jié)。安裝進行到腳本執(zhí)行，這次手動分別在兩個節(jié)點執(zhí)行，節(jié)點一依然無任何報錯，節(jié)點二卻又在腳本的914行出現(xiàn)了報錯，主要為 CLSRSC-330、LSRSC-363、CRS-2883、CRS-4000等報錯代碼。將這些報錯代碼放到metalink檢索也未找到較為貼近的解答，只是從一個帖子的線索中觀察到當前IP地址初始化在兩個節(jié)點上有一定差異，還無法確認這個差異會產(chǎn)生什么樣的影響。

經(jīng)過了上述嘗試，問題的線索似乎越來越模糊，為避免不必要的糾纏，立即重新下載官網(wǎng)的安裝介質(zhì)，并對當前環(huán)境進行卸載。

采用新下載的Grid介質(zhì)在自檢時仍報device checks for asm警告，忽略該警告，當出現(xiàn)手工執(zhí)行腳本的提示界面時，與上一個介質(zhì)有了明顯區(qū)別，說明確實存在介質(zhì)上的差異。執(zhí)行節(jié)點二的腳本，還是出現(xiàn)了報錯，只是報錯行與第一次碰到的一樣，問題回到了原點。

仔細回憶了一遍針對此問題所搜索過的資料，基本相信并確認這一問題是Bug造成，需要打補丁。

下載完補丁18456643，直接在當前腳本執(zhí)行中斷的情況下應(yīng)用補丁，不斷遇到無法調(diào)用、無法刪除、權(quán)限不夠等報錯信息。雖然補丁最后顯示應(yīng)用成功，但卻并不能讓自己信服，于是再次卸載Grid軟件并重新安裝。

這次安裝進行到彈出腳本執(zhí)行的提示，暫不執(zhí)行腳本，而先在兩個節(jié)點分別應(yīng)用補丁，相比前面的各種問題，補丁的應(yīng)用出奇的順利，似乎看到成功的曙光。打完補丁繼續(xù)執(zhí)行腳本，然而節(jié)點二還是報錯，并且還是在前面遇到過的914行。介質(zhì)更換了，補丁也打成功了，自己也開始懷疑為何沒有突破，總是在同一個故障點繞圈圈。

針對當前的/u01/app/12.1.0/grid_1/crs/install/crsinstall.pm終止在914行的報錯，搜索的資料中再次出現(xiàn)了關(guān)于169.254.0.0的私有IP的信息，對此私有IP的獲取我是一直存疑的，按說所有物理接口都設(shè)置了靜態(tài)IP，不應(yīng)該再獲取該私有IP，同時該私有IP用于鏈路本地的端到端連接，想到這，忽然想是不是因為該私有IP參與通信，卻被防火墻攔截而導(dǎo)致問題呢？立即在兩個節(jié)點的iptables防火墻上放行這一地址段，重新執(zhí)行腳本，居然就順利執(zhí)行成功了。

為確保整個部署過程的可靠，再次卸載Grid并重裝驗證，除了忽略device checks for asm警告，其余過程終于都完美無報錯，這是為集群穩(wěn)定運行奠定了基礎(chǔ)。

經(jīng)驗總結(jié)

回顧上述處理過程，本質(zhì)問題集中在介質(zhì)和鏈路本地地址這兩個部分，都是出乎預(yù)料的，對于官網(wǎng)下載的介質(zhì)存在明顯的Bug在一開始都不太確信，對于防火墻則是一直以來的堅持，做到節(jié)點間IP相互放行，禁止其他傳入的連接則能起到較好的防護效果，也能讓管理員更清楚集群節(jié)點在網(wǎng)絡(luò)中的傳入連接。