OracleAcs資深顧問羅敏老羅技術(shù)核心感悟：Clusterware是成熟產(chǎn)

來源：懂視網(wǎng) 責編：小采時間：2020-11-09 13:01:17

OracleAcs資深顧問羅敏老羅技術(shù)核心感悟：Clusterware是成熟產(chǎn)

OracleAcs資深顧問羅敏老羅技術(shù)核心感悟：Clusterware是成熟產(chǎn):作者為: SHOUG成員 – ORACLE ACS高級顧問羅敏 Oracle公司自10g版本開始就推出了集群管理軟件CRS，以后又升級改造成Clusterware，到11g版本之后更是大動干戈，內(nèi)部架構(gòu)進行了大幅度改造，并與ASM技術(shù)整合在一起，稱之為GI（Grid Infrastruc

推薦度：

點擊下載本文 文檔為doc格式

導讀OracleAcs資深顧問羅敏老羅技術(shù)核心感悟：Clusterware是成熟產(chǎn):作者為: SHOUG成員 – ORACLE ACS高級顧問羅敏 Oracle公司自10g版本開始就推出了集群管理軟件CRS，以后又升級改造成Clusterware，到11g版本之后更是大動干戈，內(nèi)部架構(gòu)進行了大幅度改造，并與ASM技術(shù)整合在一起，稱之為GI（Grid Infrastruc

作者為:? SHOUG成員 – ORACLE ACS高級顧問羅敏 Oracle公司自10g版本開始就推出了集群管理軟件CRS，以后又升級改造成Clusterware，到11g版本之后更是大動干戈，內(nèi)部架構(gòu)進行了大幅度改造，并與ASM技術(shù)整合在一起，稱之為GI（Grid Infrastructure）。Clusterw

作者為:?

SHOUG成員 – ORACLE ACS高級顧問羅敏

Oracle公司自10g版本開始就推出了集群管理軟件CRS，以后又升級改造成Clusterware，到11g版本之后更是大動干戈，內(nèi)部架構(gòu)進行了大幅度改造，并與ASM技術(shù)整合在一起，稱之為GI（Grid Infrastructure）。Clusterware替代了硬件廠商和第三方廠商的集群軟件功能，也使得Oracle RAC與Clusterware集成為一體，在產(chǎn)品的整體性、服務支持一體化等方面具有顯著優(yōu)勢。

作為新產(chǎn)品、新技術(shù)，穩(wěn)定性、成熟性略差，情有可原。但到了11g仍然如此，則讓人難以理解了。

本人最近在Windows 2012平臺實施了2節(jié)點11.2.0.4 RAC，并通過增加節(jié)點方式擴展到了4節(jié)點RAC，在國內(nèi)實屬罕見案例。期間一些波折，表明 Clusterware產(chǎn)品仍然不成熟。

話說那天我在實施節(jié)點擴展操作之前，先花費了半天時間進行了新節(jié)點的環(huán)境準備之后，并通過如下命令進行了環(huán)境檢查：

cluvfy stage -pre nodeadd -n hsedb3 –verbose

… …

節(jié)點 “hsedb3″ 上的共享存儲檢查成功

硬件和操作系統(tǒng)設(shè)置的后期檢查成功。

喲，一切都“成功”，開練了！于是，我按照Oracle文檔標準流程在節(jié)點1開始運行AddNode.bat腳本了，一切“正常”！我繼續(xù)在節(jié)點3運行了gridconfig.bat等腳本。

待所有腳本順利運行完之后檢查環(huán)境時，卻發(fā)現(xiàn)節(jié)點3根本沒有加入到集群環(huán)境中，節(jié)點3上的Clusterware服務也根本沒有啟動。—– 這就是產(chǎn)品的嚴重不成熟，明明出問題了，所有腳本卻不顯示任何一條返回錯誤，顯示一切正常！更可氣的是，AddNode.bat腳本的日志文件（addNodeActions2014-09-07_04-52-22PM.log）也居然顯示一切正常，最后還來一句：

*** 安裝結(jié)束頁***

C:\app\11.2.0\grid 的添加集群節(jié)點已成功。

我知道Oracle支持在Windows平臺進行RAC加節(jié)點操作，但現(xiàn)在沒有成功，一定是我犯什么錯誤了，也肯定知道有什么錯誤信息藏在什么鳥日志文件里了。無奈天色已晚，忙乎一天了，于是先打道回府了。

隔日，待我回到現(xiàn)場仔細分析各類Clusterware日志文件信息時，首先在alerthsedb3.log文件中大海撈針般地發(fā)現(xiàn)了出錯信息：

[cssd(4484)]CRS-1649:表決文件出現(xiàn) I/O 錯誤: \\.\ORCLDISKORADG0; 詳細信息見 (:CSSNM00059:) (位于 C:\app\11.2.0\grid\log\hsedb3\cssd\ocssd.log)。

于是，按圖索驥繼續(xù)去查詢ocssd.log文件中的信息。又像偵探一樣，在ocssd.log文件8千多行的日志信息中發(fā)現(xiàn)了如下錯誤信息：

2014-09-07 17:00:06.192: [?? SKGFD][4484]ERROR: -9(Error 27070, OS Error (OSD-04016: 異步 I/O 請求排隊時出錯。

O/S-Error: (OS 19) 介質(zhì)受寫入保護。)

此時，其實本人已經(jīng)覺察出問題了：可能是節(jié)點3對存儲設(shè)備只有讀權(quán)限，連表決盤（Voting Disk）都沒有寫入功能，從而導致失敗了。為保險期間，還是根據(jù)上述出錯信息在Metalink中進行了一番搜索，果然如此！《Tablespace (Datafile) Creation On ASM Diskgroup Fails With “[ORA-15081: Failed To Submit An I/O Operation To A Disk] : [ O/S-Error: (OS 19) The media Is Write Protected]” On Windows. ( Doc ID 1551766.1 )》詳細描述了原委和解決方案。于是，按照該文檔的建議，我將節(jié)點3對所有共享存儲設(shè)備的權(quán)限從只讀狀態(tài)修改為可讀、可寫的聯(lián)機狀態(tài)。也明白一個細節(jié)：新節(jié)點對共享存儲設(shè)備的權(quán)限缺省為只讀狀態(tài)。無論如何，安裝之前沒有仔細檢查共享存儲設(shè)備的權(quán)限是我犯的一個錯誤。

接下來該是重新進行節(jié)點增加操作了。且慢！因為前面已經(jīng)錯誤地進行了節(jié)點增加操作，而且居然顯示成功了，那么運行AddNode.bat腳本的節(jié)點1肯定已經(jīng)在OCR、Voting Disk等集群文件中寫入節(jié)點3不正確的信息了。因此，需要先實施從集群中刪除節(jié)點3的操作，但是發(fā)現(xiàn)Oracle標準文檔中的刪除節(jié)點操作的如下第一條命令有錯誤！

C:\>Grid_home\perl\bin\perl -I$Grid_home\perl\lib -I$Grid_home\crs\install

Grid_home\crs\install\rootcrs.pl -deconfig -force

又是一番折騰，將上述命令修改如下：

cd \app\11.2.0\grid

C:\>perl\bin\perl -I perl\lib -I crs\install crs\install\rootcrs.pl -deconfig –force

終于順利刪除了節(jié)點3！

現(xiàn)在可以重新來一遍了。這次一馬平川地成功增加了節(jié)點3的Clusterware以及RAC，還有節(jié)點4的Clusterware和RAC。

感悟之一：明明節(jié)點3對共享存儲只有讀權(quán)限，而cluvfy卻說：節(jié)點 “hsedb3″ 上的共享存儲檢查成功！一定是cluvfy只檢查了讀權(quán)限，而沒有檢查寫權(quán)限。很可能是cluvfy的Bug!

感悟之二：明明增加節(jié)點3的操作失敗了。但不僅AddNode.bat沒有在命令行及時顯示錯誤，而且對應的日志文件還顯示“添加集群節(jié)點已成功”。極大地誤導客戶！罪不可恕！

感悟之三：診斷Clusterware問題太難了！Oracle公司沒有告訴客戶Clusterware問題的診斷思路，特別是日志文件太多了，不知道先看哪個日志文件，后看哪個日志文件。此次本人完全是憑經(jīng)驗，先看了alerthsedb3.log文件，才找到問題的蛛絲馬跡，進而逐步確認問題并加以解決。

… …

總之，Clusterware仍然是一個非常不成熟的產(chǎn)品！