- 大話Oracle Grid：云時代的RAC
- 張曉明
- 2221字
- 2019-01-02 08:20:35
第2章 安裝引發的思考
在第1章中，我們裝了Oracle Grid、Oracle Database、創建數據庫，搞定了Oracle RAC 11.2的部署。對于有10.2 RAC經驗的朋友來說，一定能對11.2的諸多變化有所感觸。因此，我們先不急著深入到Grid的內部，我們先把在安裝過程中遇到的這些變化梳理一下，對11.2的Grid有個直觀的認識。
2.1 怎么有這么多用戶和用戶組
在Oracle 10.2 RAC的部署中，我們只需要一個用戶（oracle）和一個用戶組（dba），不管是Clusterware還是Database，都是用oracle安裝的，只是在最后執行root.sh腳本時才切換到root用戶。
在部署Oracle 11.2的過程中，我們創建了兩個用戶（oracle、grid）和5個用戶組（oinstall、dba、asmadmin、asmdba和asmoper，一共可以用到6個用戶組，其中oper和asmoper兩個組是可選的）。Grid是用grid用戶安裝的，Database是oracle用戶安裝的。
繼續閱讀之前，考慮下面這幾個問題。
Oracle搞出這么多花樣目的何在？是別有用心，還是另有隱情？
是誰在管理ASM？
是誰在管理數據庫？和ASM是一個人嗎？如果不是，這兩個人是如何交叉的？
這兩個用戶的主組都是oinstall，你認為權限和這個有關系嗎？
如果讀者對這些問題都似是而非，那么就繼續閱讀下面的內容。先來看一看單實例環境下（不使用ASM存儲的單實例）的用戶和用戶組。
2.1.1 老朋友
單實例（single-instance）環境中常用的3個操作用戶組分別是oinstall、dba、oper。
1．oinstall
這個組也叫Oracle產品清單組，代表Oracle軟件的“所有者”。怎么會有這么個組呢？ Oracle公司現在是個巨無霸，它有好多的軟件，光數據庫就有Oracle Database、TimesTen、Berkeley DB、MySQL幾個不同的產品線，還有中間件（Weblogic、Tuxedo），有BI系統，還有很多我根本不知道干什么的系統。這些軟件都可以從 OTN 上免費下載使用，所以我們的機器上很可能會裝了一堆的Oracle軟件，或者裝了一個Oracle軟件的好幾個版本。
Oracle會記錄機器上都裝了哪些軟件及哪個版本。這份記錄就是Oracle的產品清單，Oracle的大部分產品都會支持產品清單，而且是共用一份產品清單。
Oinstall這個組的成員就擁有對“Oracle 產品清單”（oraInventory）的寫權限。
在一個系統上首次安裝Oracle的軟件時（不必是Oracle數據庫，可以是任何一款產品），Oracle的安裝程序OUI都會創建一個/etc/oraInst.loc文件（AIX或者Linux）。如果是Sun平臺，則是/var/opt/oracle/oraInst.loc這個文件。這個文件的內容一般是這樣的：
inventory_loc=/u01/app/oracle/oraInventory
inst_group=oinstall
這個文件還不是“Oracle 產品清單”。這個文件只是記錄了“Oracle 產品清單組”的組名以及“Oracle產品清單”文件的位置。就這個文件而言，我們可以得到這樣的信息：
（1）Oracle產品清單組的組名是oinstall；
（2）Oracle產品清單記錄在/u01/app/oracle/oraInventory這個目錄中。
真正的清單文件是這個 ContentsXML 目錄下的 inventory.xml 文件，這個文件中記錄了機器上安裝的各種產品，下面就是一個例子。
[oracle@dbp ContentsXML]$ more inventory.xml
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 2005 Oracle Corporation.All rights Reserved -->
<!-- Do not modify the contents of this file by hand.-->
<INVENTORY>
<VERSION_INFO>
<SAVED_WITH>10.2.0.1.0</SAVED_WITH>
<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraDb10g_home1" LOC="/oracle/product/10G" TYPE="O" IDX="2"/>
<HOME NAME="agent10g" LOC="/oracle/product/grid/agent10g" TYPE="O" IDX="5"/>
<HOME NAME="CRS_HOME" LOC="/oracle/product/oem/crs" TYPE="O" IDX="1" CRS="true">
<NODE_LIST>
<NODE NAME="dbs"/>
<NODE NAME="dbp"/>
</NODE_LIST>
</HOME>
<HOME NAME="ORACLE_HOME" LOC="/oracle/product/oem/database" TYPE="O" IDX="6">
<NODE_LIST>
<NODE NAME="dbs"/>
<NODE NAME="dbp"/>
</NODE_LIST>
</HOME>
<HOME NAME="agent10g1" LOC="/oracle/product/agent10g" TYPE="O" IDX="7"/>
<HOME NAME="AgentHome" LOC="/oracle/product/oem10.204/agent10g" TYPE="O" IDX="8"/>
<HOME NAME="10GAGENT" LOC="/oracle/product/10goem/agent10g" TYPE="O" IDX="9"/>
<HOME NAME="ORACLE_HOME_10203" LOC="/oracle/product/10.2.0.3" TYPE="O" IDX="10"/>
<HOME NAME="OraDb10g_home2" LOC="/wxxrdata/oracle10.2.0.3" TYPE="O" IDX="11"/>
<HOME NAME="OraDb10g_home3" LOC="/wxxrdata/temp/tmp" TYPE="O" IDX="12"/>
<HOME NAME="db10g" LOC="/oracle/oem/db10g" TYPE="O" IDX="3" REMOVED="T"/>
<HOME NAME="oms10g" LOC="/oracle/oem/oms10g" TYPE="O" IDX="4" REMOVED="T"/>
</HOME_LIST>
</INVENTORY>
Oracle軟件的安裝、卸載功能都會依賴并維護這個文件。對一個新環境，我們可以通過這個文件來了解它上面軟件的安裝情況。有些時候，這個文件還能解決一些怪異的問題。后面的2.2小節就使用這個文件解決了一個實際問題。
在RAC環境下創建oinstall用戶組時，要保證各節點上用戶組的gid一致，保險的做法是在創建用戶組時明確指定組的ID，避免用系統自動生成組ID時可能造成的不一致。
如果沒有oinstall組，Oracle也要找個組來充當“Oracle產品清單”的角色。默認情況下，安裝程序會把Grid安裝者所在的主組當作“Oracle產品清單組”。因此一定要保證所有規劃的Oracle軟件安裝用戶都把這個組當作自己的主組。也就是說，我們計劃安裝Grid、Database這兩個軟件，而它們各自的安裝用戶分別是grid和oracle，我們就必須將grid和oracle用戶的主組設置為oinstall，這也是為什么在創建用戶時會使用-g這個參數。
#/usr/sbin/groupadd -g 505 oinstall
這個組很關鍵，我們必須要重視這個組。Oracle 11gR2 的 RAC 的安裝和 10g 很不一樣，在Oracle 10g中，Clusterware和Database兩個軟件的安裝用戶都是oracle，所以不會有訪問權限的問題。而到了Oracle 11gR2時，原來的Clusterware換成了Grid，又多了一個grid用戶。必須保證oracle、grid這兩個用戶都屬于oinstall，這樣才能保證在兩個軟件的安裝過程都有權限訪問“產品清單”，否則安裝過程中會遇到“oraInventory無法訪問”的權限錯誤。
2．dba組（OSDBA用戶組）
OSDBA是我們必須要創建的一個系統級的用戶組（習慣叫dba），如果沒有這個用戶組，我們就無法安裝數據庫軟件和進行后續的數據庫管理任務。
設置OSDBA組是和Oracle的操作系統身份驗證有關的。屬于這個組的用戶，可以在通過操作系統身份驗證后，通過SQL*Plus以SYSDBA身份連接到Oracle數據庫實例。這個組的成員有權執行一些關鍵的、也是危險的管理任務，比如創建數據庫、啟動和關閉數據庫。這個組的默認名稱就為dba。SYSDBA系統權限甚至允許在數據庫還沒打開時訪問數據庫實例。對此權限的控制完全超出了數據庫本身的范圍。
不要混淆SYSDBA系統權限與數據庫角色DBA。DBA角色不包括SYSDBA或SYSOPER系統權限。也就是說，即使DBA組成員，也要明確指明要以SYSDBA的權限登錄，才能得到SYSDBA的權限。像這樣：
oracle> sqlplus ‘ / as sysdba’
3．oper組（OSOPER用戶組）
OSOPER組是一個可選的組。這個組也是和Oracle操作系統身份認證功能有關的，屬于這個組的成員可通過操作系統身份驗證使用SQL*Plus以SYSOPER身份連接到Oracle實例。這個可選組的成員擁有一組有限的數據庫管理權限，比如可以做備份。這個組的默認組名就是oper。要使用該組，在安裝Oracle數據庫軟件的過程中要選擇“Advanced安裝類型”進行安裝。
既然是可選的，那我們既可以創建也可以不創建這個用戶組，創建這個用戶組的目的是讓一些操作系統的用戶也能夠行使某些數據庫的管理權限（包括 SYSOPER 角色權限）。注意SYSOPER的權限包括startup和shutdown，所以要小心為該用戶組添加成員。
創建OSOPER用戶組的方法：
# /usr/sbin/groupadd oper
綜上所述，在單實例環境（single-instance）中，Oracle Database軟件的安裝者也是所有者通常都是oracle這個操作系統用戶，oracle用戶同時也是oinstall、dba、oper用戶組的成員。同時oracle用戶的主組必須是oinstall。也就是創建oracle用戶是這樣創建的：
useradd –g oinstall –G dba,oper oracle
在數據庫軟件的安裝過程中，需要指定操作系統用戶組，界面如圖2-1所示。
圖2-1 選擇Privileged Operating System用戶
這個界面中有兩個下拉列表框，這兩個列表框就是用來選擇之前說的OSDBA和OSOPER兩個組對應的操作系統的用戶組組名。這里的選擇，會影響到$ORACLE_HOME/rdbms/lib/config.c這個文件，這個文件中定義了SS_DBA_GRP和SS_OPER_GRP兩個宏：
/* Refer to the Installation and User's Guide for further information.*/
/* IMPORTANT: this file needs to be in sync with
rdbms/src/server/osds/config.c, specifically regarding the
number of elements in the ss_dba_grp array.
*/
#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "oper"
#define SS_ASM_GRP ""
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
2.1.2 集群環境的用戶組
在Oracle 10g中，Clusterware和Database都是由DBA一個角色進行管理的。在Oracle 11gR2的RAC中，Oracle開始主張把集群環境和數據庫的管理拆開。其實這也是Oracle的策略使然，Oracle由原來唱衰“云”變成了積極的“云”推動者，顯然它看到了“云”市場的巨大商機。
而Oracle的各條產品線中，也只有Grid（Clusterware）最有可能扛起“Oracle云”的大旗。因此，Oracle非常迫切地要給這個產品去掉數據庫的烙印。Oracle現在格外強調它的GI（Grid Infrastructure）是一個基礎架構，而RAC數據庫只是這個環境中一個普通的資源而已，對它的管理，普通的 DBA稍加培訓就可以了。相反，對于架構環境本身的管理，反而需要一個更獨立、更專業的角色來進行。這也是它在強調的。
它這種觀點不僅僅是想想而已，也已經落實到產品上了。在Oracle的Grid環境中，出現專門管理Grid的用戶、用戶組以及管理數據庫的用戶、用戶組就是極好的佐證。
于是在Oracle 11.2的Grid中，又多了3個專門管理ASM的用戶組。
1．asmadmin（OSASM）用戶組
要在 Oracle 11.2 環境中使用 ASM，必須創建 asmadmin（OSASM）用戶組，這個用戶組也是一個必需的組。這么做也是為了讓Oracle ASM管理員和Oracle Database管理員分屬不同的管理權限組。
OSASM 組的成員可通過操作系統身份驗證使用 SQL*Plus 以 SYSASM 身份連接到一個 Oracle ASM 的實例。SYSASM 是在 Oracle 11G R1 版中出現的權限，到了 Oracle 11gR2，這個權限已經從SYSDBA中完全分離出來了。SYSASM權限不再有對RDBMS實例的訪問權限。
用SYSASM取代SYSDBA主要是為了把存儲層的系統權限剝離出來，這樣對ASM的管理和數據庫管理之間有了清晰的責任劃分，有助于防止使用相同存儲的不同數據庫無意間覆蓋其他數據庫的文件。
OSASM組的成員會被賦予SYSASM權限，SYSASM權限可以執行掛載和卸載磁盤組及其他的存儲管理任務。因為對Grid的管理很大程度上就是對ASM的管理，所以這個組的成員可以同時管理Oracle Clusterware和Oracle ASM，因為Clusterware+ASM=Grid。
（1）SYSASM權限。
在Oracle 10.2中，ASM實例的啟動和RDBMS數據庫一樣，都需要管理員以sysdba的身份登錄后執行startup命令。
到了Oracle 11.2時，管理員就不能再以sysdba的身份啟動ASM數據庫了，必須以sysasm角色連接后才能進行操作。
如果以sysdba身份執行啟動或者關閉ASM實例的命令，Oracle會提示權限不夠。下面就是關閉ASM實例的示例：
[root@searchdb2 ～]# sqlplus "sys/ *** as sysdba"
SQL*Plus: Release 11.2.0.1.0 Production on Thu Sep 1 10:18:14 2011
Copyright (c) 1982, 2009, Oracle.All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
SQL> shutdown immediate;
ORA-01031: insufficient privileges
我們需要退出來后，以sysasm的身份重新連接到實例后，命令才能得以執行：
[grid@indexserver4 ～]$ sqlplus " / as sysasm"
SQL*Plus: Release 11.2.0.2.0 Production on Wed Jun 13 15:56:44 2012
Copyright (c) 1982, 2010, Oracle.All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
SQL> shutdown immediate;
ASM diskgroups volume disabled
ASM diskgroups dismounted
ASM instance shutdown
SQL> exit
（2）如何正確關閉ASM實例。
如果你恰好在一個Oracle 11.2 RAC上執行了上面的shutdown命令時，就可能會出現無法關閉的情況，比如：
[grid@indexserver1 ～]$ export ORACLE_SID=+ASM1
[grid@indexserver1 ～]$ sqlplus " / as sysasm"
SQL*Plus: Release 11.2.0.2.0 Production on Thu Jun 14 16:05:08 2012
Copyright (c) 1982, 2010, Oracle.All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
SQL> shutdown;
ORA-15097: cannot SHUTDOWN ASM instance with connected client (process 22989)
使用shutdown immediate命令也不行：
SQL> shutdown immediate;
ORA-15097: cannot SHUTDOWN ASM instance with connected client (process 22989)
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options。
即使關閉了數據庫后，再執行上面的命令，得到的結果也是一樣的。這是因為在Oracle 11.2 RAC環境中，CRS和ASM的關系發生了變化。
在 Oracle 10g 中，ASM 里只能放 Oracle 數據庫文件，所有 ASM 只有一種客戶端，就是Oracle 數據庫。因此，在Oracle 10g 的環境下，我們關閉RAC 的順序是這樣的：關閉數據庫?關閉ASM?關閉CRS。
但是在Oracle 11gR2下，如果是用OUI來安裝，除了數據庫的數據文件之外，集群自己的OCR和Voting File也是放在ASM里的。
所以這里就遇到了問題。因為集群文件也是放在 ASM 里的，這樣 CRSD 也成為了 ASM的客戶端。如果像Oracle 10g中那樣直接關閉ASM，就會因為還有客戶端連接到ASM實例而拋出上面的錯誤。所以，在Oracle 11gR2下面，要停ASM實例，只能和CRS一起停掉才行。因此正確的關閉方法是關閉CRS。
在root用戶下這么做：
[root@indexserver1 ～]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on'indexserver1'
CRS-2673: Attempting to stop 'ora.crsd' on 'indexserver1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'indexserver1'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.registry.acfs' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.DATA.dg' on 'indexserver1'
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.indexserver1.vip' on 'indexserver1'
CRS-2677: Stop of 'ora.indexserver1.vip' on 'indexserver1' succeeded
CRS-2672: Attempting to start 'ora.indexserver1.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.registry.acfs' on 'indexserver1' succeeded
CRS-2676: Start of 'ora.indexserver1.vip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.DATA.dg' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'indexserver1'
CRS-2677: Stop of 'ora.asm' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'indexserver1'
CRS-2677: Stop of 'ora.ons' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'indexserver1'
CRS-2677: Stop of 'ora.net1.network' on 'indexserver1' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'indexserver1' has completed
CRS-2677: Stop of 'ora.crsd' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.ctssd' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.evmd' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.asm' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'indexserver1'
CRS-2677: Stop of 'ora.asm' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'indexserver1'
CRS-2677: Stop of 'ora.drivers.acfs' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.evmd' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'indexserver1'
CRS-2677: Stop of 'ora.cssd' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'indexserver1'
CRS-2673: Attempting to stop 'ora.crf' on 'indexserver1'
CRS-2677: Stop of 'ora.crf' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'indexserver1'
CRS-2677: Stop of 'ora.diskmon' on 'indexserver1' succeeded
CRS-2677: Stop of 'ora.gipcd' on 'indexserver1' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'indexserver1'
CRS-2677: Stop of 'ora.gpnpd' on 'indexserver1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'indexserver1' has completed
CRS-4133: Oracle High Availability Services has been stopped.
注意：不要直接kill掉ASM 進程或者用shutdown abort來關閉ASM實例，這樣CRS也會掛掉。
2．asmdba（OSDBA for ASM group）用戶組
ASM數據庫管理員組（OSDBA for ASM）的成員是SYSASM權限的一個子集，這個組被賦予了對Oracle ASM所管理的文件的讀寫權限。
Grid軟件的安裝者、所有者（一般都是grid）以及Oracle Database軟件的所有者（一般是oracle）必須是該組的成員，而那些需要訪問由ASM管理的文件并且屬于OSDBA組（dba組）的用戶也必須是ASM的OSDBA組的成員。
因此，grid用戶和oracle用戶都需要屬于這個組。
3．asmoper（OSOPER for ASM）用戶組
這個組也是個可選組。如果需要單獨設置一個對 ASM 實例有部分管理權限（ ASM 的SYSOPER權限，包括啟動和停止Oracle ASM實例的權限）的操作系統用戶，那么我們就可以創建這個組。在默認情況下，OSASM組的成員將擁有ASM的SYSOPER權限所授予的所有權限。
要想使用ASM操作員組，在安裝Grid軟件時必須選擇Advanced安裝類型。這時OUI會指定該組的名稱。
如果要擁有一個OSOPER for ASM組，則Grid軟件所有者（grid）也必須是這個組的一個成員。
在Grid安裝過程中，遇到得如圖2-2所示的這個界面，就是針對這3個用戶組的。
圖2-2 Grid安裝中遇到的ASM用戶組
現在再回顧一下之前看到的表1-2，希望你現在已經對它深入了解了。
2.1.3 GI owner 和 DB owner 是否有必要分開
現在我們再對這個問題做一個深入的探討。
首先，Oracle Clusterware或者Oracle Grid本身只是Oracle RAC環境中的一個軟件，因此自然而然地看起來是應該交給DBA管理的。不過，許多Clusterware的管理任務都需要以root的身份運行，這些又超出了DBA本身的一畝三分地。所以說把Clusterware交給系統管理員來維護也不是沒有道理的，而且ASM提供的是存儲管理（盡管是用Oracle軟件實現的軟存儲管理），按理也應該是交給系統管理員或者存儲管理員（如果有的話）來維護。
在Oracle 10g中，我們可以把CRS和RDBMS分開用兩個用戶安裝（盡管實際上沒有人這么做），從而實現一定程度的管理功能分隔。不過，Oracle 10g的ASM還是在RDBMS中的，而且10g 中的ASM 很多任務還是通過SQL 指令完成的，因此，Oracle 10g 中對ASM 的管理還主要是DBA的任務。
Oracle 11g提出了Role-separated Management的思想。把ASM和Clusterware集成為一體，進而可以用不同的操作系統用戶組把DBA和ASM管理員隔離開。另外，Oracle 11g提供了新的ASM配置助手（ASMCA）、命令行工具asmcnd，現在都可以完全地分配給存儲和系統管理員來完成了。
正是因為ASM和Clusterware的集成，因此，即使你不打算使用Role-separated Management，我也建議你給Grid home和RDBMS home不同的owner。這樣如果以后想把任務分離出去，也提前預留出了操作空間。
2.2 DBCA不識別集群環境的解決辦法
這個問題是之前所講的“Oracle產品清單”的一個真實案例。
如果讀者按照之前的步驟完成了集群的部署，你不妨在每一個節點上都運行一下DBCA，看看是看到如圖2-3所示的這個界面呢？還是看到如圖2-4所示的這個界面？通常來說，在一個集群環境中，執行 runInstaller 的那個節點上的 DBCA 都能夠識別出集群環境，并給出正確的界面（如圖2-3所示），也就是Oracle RAC的歡迎頁面。
圖2-3 能夠識別集群環境的DBCA
圖2-4 沒有識別出集群環境的DBCA界面
而其他節點上的DBCA界面可能如圖2-4所示，這就是因為DBCA不能識別集群環境所引起的問題
。如果單擊【Next】按鈕，就會發現全是單實例的內容。
這是因為什么呢？主要是產品清單的問題，我們分別對比兩個節點的內容。
以下是能夠出現Oracle RAC Welcome page節點的內容：
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2010, Oracle.All rights reserved.-->
<!-- Do not modify the contents of this file by hand.-->
<INVENTORY>
<VERSION_INFO>
<SAVED_WITH>11.2.0.2.0</SAVED_WITH>
<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="Ora11g_gridinfrahome1" LOC="/u01/app/11.2.0.2/grid" TYPE="O" IDX="1" CRS="true">
<NODE_LIST>
<NODE NAME="indexserver1"/>
<NODE NAME="indexserver2"/>
<NODE NAME="indexserver3"/>
<NODE NAME="indexserver4"/>
</NODE_LIST>
</HOME>
<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/11.2.0.2/database" TYPE="O" IDX="2">
<NODE_LIST>
<NODE NAME="indexserver1"/>
<NODE NAME="indexserver2"/>
<NODE NAME="indexserver3"/>
<NODE NAME="indexserver4"/>
</NODE_LIST>
</HOME>
</HOME_LIST>
</INVENTORY>
而以下是不能識別集群環境的節點的內容：
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2010, Oracle.All rights reserved.-->
<!-- Do not modify the contents of this file by hand.-->
<INVENTORY>
<VERSION_INFO>
<SAVED_WITH>11.2.0.2.0</SAVED_WITH>
<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/11.2.0.2/database/griddatabase" TYPE="O" IDX="2">
<NODE_LIST>
<NODE NAME="indexserver1"/>
<NODE NAME="indexserver2"/>
<NODE NAME="indexserver3"/>
<NODE NAME="indexserver4"/>
</NODE_LIST>
</HOME>
<HOME NAME="Ora11g_gridinfrahome1" LOC="/u01/app/11.2.0.2/grid" TYPE="O" IDX="1" CRS="true">
<NODE_LIST>
<NODE NAME="indexserver1"/>
<NODE NAME="indexserver2"/>
<NODE NAME="indexserver3"/>
<NODE NAME="indexserver4"/>
</NODE_LIST>
</HOME>
</HOME_LIST>
</INVENTORY>
看出問題了嗎？在出現問題的節點上，GRID_HOME，即IDX=1的項目被放在最后了。把順序調整過來就可以了。
2.3 為什么不配時間服務了
集群環境中對節點時間一致的要求非常嚴格。Oracle 是用 SCN 來記錄數據庫的事務操作的，SCN基本上就是時間戳。想象一下，如果兩個節點時間有差別，很有可能出現明明節點1上的事務先執行，節點2的事務后執行，而從SCN上反映出來的卻是相反的。這會造成數據嚴重不一致。
因此，在集群環境中，如果出現節點時間上的不一致，就會導致集群的重構，也就是某個節點會被重啟。這是由集群判斷節點掛起的方式決定的，一個大幅度的時間跳躍會讓集群錯誤的認為發生了嚴重的節點掛起，從而觸發節點隔離（fencing）。使用類似NTP這種時間同步方法，又沒有進行精細的配置的話，是很容易造成這種大幅度的時間跳躍的。Oracle 10.2中有幾個有名的bug就是因為時間同步而造成節點重啟的。
所以，在11.2 RAC 中，時間服務仍然是需要的，也是必需的。但是我們上一章在做前期準備時，并沒有做任何時間服務的配置。這是為何呢？因為Oracle 11.2引入了CTSS服務，這個服務會替我們考慮這些問題。
在Oracle 11.2中，Oracle為了簡化RAC的部署，做了大量的優化，其中就包括對時間服務的簡化。在 Oracle 11.2 中，我們有兩個時間同步機制可以選擇，可以使用操作系統提供的NTP服務，也可以使用Grid自帶的時間同步服務（CTSS，Cluster Time Synchronization Server Daemon）。
2.3.1 使用 NTP 服務
如果要使用操作系統自帶的NTP服務，需要修改NTP參數文件，在其中設置-x標志，這樣可避免向前調整時間。完成配置的修改后，重啟NTP服務即可。
編輯/etc/sysconfig/ntpd文件：
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no
# Additional options for ntpdate
NTPDATE_OPTIONS=""
重啟NTP服務：
[root@indexserver3 grid_data]# service ntpd status
ntpd (pid 4250) is running...
[root@indexserver3 grid_data]# service ntpd stop
Shutting down ntpd: [ OK ]
[root@indexserver3 grid_data]# service ntpd start
ntpd: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]
[root@indexserver3 grid_data]# ps -ef|grep ntpd
Ntp 22244 1 0 17:25 ? 00:00:00 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid
Root 22250 15074 0 17:25 pts/0 00:00:00 grep ntpd
2.3.2 使用 CTSS 服務
如果想使用Grid提供的集群時間同步服務，就需要卸載操作系統提供的NTP服務，或者干脆禁用它，后者需要進行如下操作：
要禁用NTP服務，必須停止當前的NTPD服務；
從初始化序列中禁用該服務；
刪除ntp.conf文件。
[root@searchdb1 ～]# service ntpd status
ntpd (pid 7447) is running...
[root@searchdb1 ～]# service ntpd stop
Shutting down ntpd: [ OK ]
[root@searchdb1 ～]# chkconfig ntpd
[root@searchdb1 ～]# chkconfig ntpd off
[root@searchdb1 ～]# mv /etc/ntp.conf /etc/ntp.conf.bak
2.3.3 CTSS 和 NTP 的關系
如果CTSS發現集群中所有節點上已經配置或者運行了NTP服務，則CTSS會以一種觀察員模式（Observer Mode）運行，這種模式下 CTSS 只會在集群的alert 日志中記錄時間不一致的信息，但不會去調整。
如果CTSS發現集群中并不是所有節點都配置或者運行了NTP服務，CTSS就會以一種主動模式（Active Mode）運行，和主節點同步系統時鐘。這種同步又分兩種方式。
當一個節點加入到集群時，如果這個節點存在時間差異，但是這個差異在某個界限之內，就會用一種步進的方式進行同步，也就是每次調整很小的一個幅度。如果時間差異超過了這個限，就不允許這個節點加入到集群，并在集群的alert日志中記錄一個消息。
在運行過程中，如果節點和主節點時間發生了差異，會把系統時鐘加快或者減慢已達到重新的同步。這也叫做clock slewing。
說明：CTSS永遠不會把系統時鐘向前調整。Oracle 10.2 RAC 中就有因為始終向前調整引起節點重啟的bug。
要想把 CTSS 從觀察者模式轉變成主動模式，只需要去掉所有節點上的 NTP 服務即可，CTSS會發現這個變化，并改變模式。反過來也是一樣，也就是如果啟動所有節點上的NTP服務，會導致CTSS轉換成觀察者模式。
可以使用以下方式來查看CTSS是運行在什么模式下的：
[grid@indexserver4 ～]$ crsctl check ctss
CRS-4700: The Cluster Time Synchronization Service is in Observer mode.
這說明CTSS是以觀察者模式運行的。
2.4 IPMI是什么
IPMI即Integrating Intelligent Platform Management Interface，如何理解呢？
我們在《大話Oracle RAC》中談到過IO Fencing，或者踢出節點（evict node），也就是當集群中的某個節點失去了響應──沒有了磁盤心跳、對ping也沒有響應，可能這個節點已經關閉了，也可能負載太高、運行緩慢，也有可能完全掛起了（hung）。這時，集群需要進行重構，也就是要把這個節點踢出集群環境，由剩下的節點重新組建新的集群。這樣做是為了解決腦裂風暴。
而踢出一個節點其實就是要讓這個節點重啟，重啟有兩種做法，一種是suicide，另一種是STONITH（Shoot The Other Node In The Head）。
Oracle 11.2之前采用的是第一種方法，不過，發現一個節點該重啟和這個節點確實能夠重啟是兩回事。這個節點如果已經完全掛起了，它其實是沒有辦法自己解決這個問題的，這就是IPMI發揮作用的地方了。而IPMI采用的就是后一種辦法。
IPMI是一個工業標準。如果集群要使用IPMI，那么這個集群中的每個節點都要有一個BMC （Baseboard Management Controller），這個卡的Firmware要支持IPMI的1.5版，這個版本支持局域網內的 IPMI。換句話說，如果其他健康節點發現這個節點因為某種原因沒反應了，必然會通過局域網通知這個BMC卡重啟這個節點，最簡單的方式就是暫時斷電再通電。不過，通過 IPMI 來重啟節點，是各種努力都嘗試過后的最后一擊，當然目的也是為了保護數據的一致性。如果機器配有BMC設備的話，可以配置IPMI。
2.5 ORACLE_BASE和ORACLE_HOME的區別
ORACLE_HOME我們都非常熟悉，ORACLE_BASE是Oracle 11.2部署時一個需要的變量。要理解這兩個目錄的關系，就需要理解Oracle的Optimal Flexible Architecture（OFA）標準。這是一個保證一致的目錄結構和文件命名的標準。我之前并不遵循 OFA 標準，而是采用自己的一套。不過從Oracle 11.2以來，我開始有意識地理解OFA，發現真的不錯，所以推薦給讀者。
2.5.1 OFA 和軟件安裝
許多環境和資料都采用了OFA標準，理解這個標準很重要。圖2-5就是標準OFA的目錄結構和文件名字規范。當然這張圖中并沒有顯示所有的目錄和文件，不過關鍵的常用目錄和文件還是顯示出來了。
圖2-5 OFA標準目錄結構
OFA中有幾個關鍵目錄需要知道，包括：
Oracle inventory目錄；
Oracle Base目錄（ORACLE_BASE）；
Oracle Home 目錄（ORACLE_HOME）；
Oracle Network目錄（TNS_ADMIN）；
Automatic Diagnostic Repository（ADR_HOME）。
1．Oracle Inventory目錄
注意這個目錄和下一個Oracle Base目錄的關系。
當我初次接觸到 ORACLE_BASE 這個概念時，有了一個想當然的判斷。以為這是一個樹根，而所有Oracle有關的東西，都是放在這個樹根下的。如果你的想法和我一樣，那就要注意了，這個目錄不屬于ORACLE_BASE。它是和ORACLE_BASE同級的一個目錄。
這個目錄用來保存本機上所安裝的 Oracle 軟件的目錄清單，本機上安裝的所有 Oracle 軟件都需要并且共享使用這個目錄，當我們第一次安裝Oracle軟件時，Oracle使用下面的幾條規則來尋找這個目錄。
（1）是否有OFA-兼容的目錄結構，所謂OFA兼容就是指這個目錄符合/u[01-09]/app這樣的命名規范。如果有，安裝程序就會在這個目錄下創建，比如/u01/app/oraInventory。
（2）如果oracle用戶的環境變量中定義了ORACLE_BASE變量，則安裝程序會在下面這個位置創建這個目錄：ORACLE_BASE/../oraInventory ，中間的兩個原點“..”代表的是ORACLE_BASE的上層目錄，也就是說，oraInventory目錄是和ORACLE_BASE目錄在同一個層次。比如，如果ORACLE_BASE定義為/ora/app/oracle，則這個目錄就是/ora/app/oraInventory。
（3）如果安裝程序沒有找到OFA兼容的目錄結構，也沒有發現ORACLE_BASE變量，則安裝器會在Oracle用戶的HOME目錄下創建這個目錄，也就是/home/oracle/oraInventory目錄。
2．Oracle Base目錄
Oracle Base目錄是Oracle軟件安裝的最頂層目錄。這個目錄下可以安裝多個版本的Oracle軟件，OFA標準里的Oracle Base目錄是這樣的：
/<mount_point>/app/<software_owner>
掛載點通常是像/u01、/ora01、/oracle這樣的名字。用戶可以根據自己的環境標準命名這個掛載點。
軟件擁有者通常都是oracle，這是你用來安裝Oracle軟件的操作系統用戶。因為，一個完整的Oracle Base目錄可能是這樣的：
/ora01/app/oracle
3．Oracle Home目錄
Oracle Home 目錄定義了每個特定軟件，比如Oracle Database 11g、Oracle Database 10g的安裝目錄。每個不同的產品或者同一產品的不同版本必須放在單獨目錄下。符合 OFA 標準的Oracle Home 目錄是這樣的：
ORACLE_BASE/product/<version>/<install_name>
在我們的環境中，版本可能是11.2.0.1、11.2.0.2、10.2.0.1，install_name可以是db_1、devdb。比如下面就是一個版本為11.2.0.1的數據庫：
/ora01/app/oracle/product/11.2.0.1/db_1
許多DBA，包括我自己都不喜歡ORACLE_HOME下的目錄db_1，也看不出它有什么用處。其實 db_1 這種結構是讓我們可以有多個單獨的二進制：一個開發環境、一個測試環境、一個生產環境，如果確定沒有必要使用這么多安裝，也可以去掉這個目錄。
4．GRID的Oracle Base和Oracle Home
不過Grid的ORACLE_BASE和ORACLE_HOME有所不同，Grid的ORACLE_HOME不能是ORACLE_BASE的子目錄，如果這么定義：
ORACLE_BASE=/u01/app/grid
ORACLE_HOME=/u01/app/grid/11.2.0.2
安裝會報錯，如圖2-6和圖2-7所示。
圖2-6 指定安裝位置
圖2-7 安裝報錯
Oracle的官方文檔是這樣解釋的：Even if you do not use the same software owner to install Grid Infrastructure (Oracle Clusterware and Oracle ASM) and Oracle Database, be aware that running the root.sh script during the Oracle Grid Infrastructure installation changes ownership of the home directory where clusterware binaries are placed toroot, and all ancestor directories to the root level (/) are also changed to root.For this reason, the Oracle Grid Infrastructure for a cluster home cannot be in the same location as other Oracle software.
也就是說，在Grid安裝過程的root.sh會把Grid所在目錄的屬主改成root，而且會一直修改到頂層目錄，這樣一來就會影響到其他的Oracle軟件，所以，不能把Grid的ORACLE_HOME放到ORACLE_BASE的子目錄中。
所以，對于Grid用戶來說，這兩個目錄應該是平行的。
5．Oracle Network 目錄
一些Oracle工具使用TNS_ADMIN定位網絡配置文件，這個目錄位于ORACLE_HOME/network/admin，這個目錄中會包括sqlnet.ora、tnsnames.ora和listener.ora文件。
6．ADR目錄
ADR 目錄（Automatic Diagnostic Repository）是從 Oracle 11g 開始出現的，這個目錄里的文件對于解決Oracle數據庫問題很關鍵，這個目錄定義是ORACLE_BASE/diag/rdbms/<dbname>/<instancename>，其中 dbname 是數據庫的名字，instancename 是實例的名字。在單實例數據庫環境中，數據庫名字和實例名字是相同的，不過數據庫名字是小寫的，實例名字是大寫的。比如，下面這個testdb：
/ora01/app/oracle/diag/rdbms/testdb/TESTDB
7．ORACLE_BASE、ORACLE_HOME環境變量
現在我們已經理解了 OFA 標準了，因此，在安裝之前，需要在安裝用戶的環境中指定ORACLE_BASE、ORACLE_HOME 兩個環境變量。Grid、Oracle 兩個用戶各自的設置是不同的。
Grid用戶的環境變量設置：
export ORACLE_BASE=/u01/app/grid
export ORACLE_HOME=/u01/app/11.2.0/grid
PATH=$ORACLE_HOME/bin:$PATH:$HOME/bin
Oracle用戶的環境變量設置：
export ORACLE_BASE=/u01/app/database
export ORACLE_HOME=$ORACLE_BASE/11.2.0.2
PATH=$ORACLE_HOME/bin:$PATH:$HOME/bin
2.5.2 ORACLE_HOME 是共享還是本地
在 RAC 集群中，每個節點上的 Oracle 軟件都要訪問 RAC 數據庫。這就會引發一個問題——Oracle 軟件本身是放在一個共享存儲上（共享 ORACLE_HOME）或者放在每個節點的本地（本地ORACLE_HOME）。
使用共享ORACLE_HOME當然有些好處，比如配置、空間需求、升級。不過，每次升級都必須要有完全的停機才行。而且，因為只有一份 ORACLE_HOME，這很明顯是一個單點故障，這個共享空間的任何問題都會導致數據庫的掛掉。
因此，對于ORACLE_HOME的建議還是使用本地ORACLE_HOME。千萬不要舍不得那一點點空間浪費，也不要害怕準備環境的麻煩。
2.6 SCAN
在安裝Grid的過程中，需要填寫一個叫做SCAN的項目（如圖1-9所示），SCAN即Single Client Access Name的縮寫。關于SCAN，我會專門用單獨的一章來討論，本節只是先簡單介紹一下。
來看一下Oracle 10.2 RAC的客戶端是如何訪問數據庫的，這些客戶端的TNSNAMES.ORA應該是這樣的：
Testdb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = center-rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = center-rac2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME =testdb)
)
)
客戶端的這個文件中會記錄RAC環境中每個節點的VIP地址，也就是說客戶端必須要知道整個集群環境的拓撲結構。一旦集群的拓撲發生了改變，比如加入新的節點或者去掉某個節點，所有客戶端的TNSNAMES.ORA文件必須做修改，否則就可能無法繼續訪問數據庫了。
也就是說，Oracle RAC環境不能做到對用戶完全透明，這是一個問題。SCAN就是用來解決這個問題的。
SCAN本身是一個QFDN的域名，就像熟悉的網站一樣，我們訪問谷歌是通過www.google.com訪問的，谷歌其實有上百上千臺服務器提供WWW服務，我們根本不知道連的是哪一臺，也不需要關心，反正只要能打開網頁，后面的服務器怎么變化都跟我們無關。也就是說谷歌的服務器對于客戶是透明的。
SCAN的效果也是一樣的，使用SCAN后，客戶端的TNSNAMES.ORA是這樣的：
Testdb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = indexgrid.wxxr.com.cn)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = testdb)——
)
)
現在，客戶端所需要知道的就是一個SCAN──indexgrid.wxxr.com.cn，可以叫它域名，你不需要知道任何RAC環境內部的信息，RAC內部再有什么變化，客戶端不需要知道。RAC對客戶完全透明了。
要實現這個目的，其實后面有一系列的技術支持，包括 DNS、GNS、SCAN VIP、SCANListener、Listener，這些內容都會在后面的章節中展開。
2.7 HAIP（替代雙網卡綁定）
眾所皆知，RAC環境中有個私有網絡，這個網絡上跑的是心跳信息和Cache Fusion數據，私有網絡對于 RAC 的穩定性、性能有著重要的意義。因此，我們會建議采用多塊網卡綁定的方式來搭建這個網絡。在不同的操作系統中，網卡綁定的名稱也不一樣，有的叫 bonding，有的叫 teaming 或 trunking。不管叫什么，其目的都是一樣的，都是通過冗余提供分散負載、故障切換的能力。
Oracle Grid從版本11.2.0.2開始內置了一個私有網卡的HA技術，就是HAIP。它和我們熟悉的多網卡綁定有所差異，采用的是一個multiport-listening-endpoint的架構，每個私有網卡都會被分配一個HAIP地址，這個IP地址不需要提前定義，它是自動生成的。最多支持4個私有網卡。
在默認情況下，Oracle RAC會使用所有這些HAIP作為私有網絡的通信協議，提供負載均衡。如果一個私有網卡掛了，Oracle會自動地把其HAIP切換到其他的網卡上去。
在 RAC 中，Oracle ASM（ASM 集群）以及其他的集群組件，比如 CSS、CRS、CTSS、EVM等都可以利用HAIP。
當有多個私有網卡時，安裝過程如圖2-8所示。
圖2-8 有多塊網卡時的配置界面
說明：HAIP 是Oracle Grid 11.2.0.2之后才有的，11.2.0.1是看不到的。
可以用操作系統的ip命令來查看這個HAIP。
節點1：
[grid@indexserver1 ～]$ /sbin/ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:43:c5:0d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.70/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.80/24 brd 192.168.1.255 scope global secondary eth0:1
inet 192.168.1.86/24 brd 192.168.1.255 scope global secondary eth0:2
inet6 fe80::7a2b:cbff:fe43:c50d/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:43:c5:0f brd ff:ff:ff:ff:ff:ff
inet 10.0.0.70/8 brd 10.255.255.255 scope global eth1
inet 169.254.177.128/16 brd 169.254.255.255 scope global eth1:1
inet6 fe80::7a2b:cbff:fe43:c50f/64 scope link
valid_lft forever preferred_lft forever
節點2：
[root@indexserver2 11.2.0.2]# ip ad sh
……
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:43:5c:0c brd ff:ff:ff:ff:ff:ff
inet 10.0.0.71/8 brd 10.255.255.255 scope global eth1
inet 169.254.127.239/16 brd 169.254.255.255 scope global eth1:1
inet6 fe80::7a2b:cbff:fe43:5c0c/64 scope link
valid_lft forever preferred_lft forever
……
節點3：
[root@indexserver3 11.2.0.2]# ip ad sh
……
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:43:76:26 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.72/8 brd 10.255.255.255 scope global eth1
inet 169.254.59.18/16 brd 169.254.255.255 scope global eth1:1
inet6 fe80::7a2b:cbff:fe43:7626/64 scope link
valid_lft forever preferred_lft forever
……
節點4：
[root@indexserver4 11.2.0.2]# ip ad sh
……
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:42:79:37 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.73/8 brd 10.255.255.255 scope global eth1
inet 169.254.162.84/16 brd 169.254.255.255 scope global eth1:1
inet6 fe80::7a2b:cbff:fe42:7937/64 scope link
valid_lft forever preferred_lft forever
……
在這個 4 節點的 RAC 中，網卡 eth1 用作私有網卡，這塊網卡上除了我們定義的私有 IP10.0.0.*之外，還有一個169.*.*.*的地址，這就是HAIP。
以上是只有一塊網卡做私有網卡的情況，下面是在Oracle 11.2.0.3中，有多塊網卡做私有網卡的情況。
第一個節點：
[root@promotiondbp ～]# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:a3:46 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.33/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.40/24 brd 192.168.1.255 scope global secondary eth0:1
inet 192.168.1.39/24 brd 192.168.1.255 scope global secondary eth0:3
inet 192.168.1.37/24 brd 192.168.1.255 scope global secondary eth0:4
inet6 fe80::7a2b:cbff:fe44:a346/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:a3:48 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.10/8 brd 10.255.255.255 scope global eth1
inet 169.254.8.96/18 brd 169.254.63.255 scope global eth1:1
inet 169.254.242.150/18 brd 169.254.255.255 scope global eth1:2
inet6 fe80::7a2b:cbff:fe44:a348/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:a3:4a brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/8 brd 10.255.255.255 scope global eth2
inet 169.254.111.15/18 brd 169.254.127.255 scope global eth2:1
inet6 fe80::7a2b:cbff:fe44:a34a/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:a3:4c brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/8 brd 10.255.255.255 scope global eth3
inet 169.254.167.173/18 brd 169.254.191.255 scope global eth3:1
inet6 fe80::7a2b:cbff:fe44:a34c/64 scope link
valid_lft forever preferred_lft forever
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:10:18:9f:6f:c8 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.3/8 brd 10.255.255.255 scope global eth4
7: eth5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:10:18:9f:6f:ca brd ff:ff:ff:ff:ff:ff
inet 10.0.0.4/8 brd 10.255.255.255 scope global eth5
8: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
第二個節點：
[root@promotiondbs grid]# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:8d:72 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.34/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.38/24 brd 192.168.1.255 scope global secondary eth0:1
inet 192.168.1.41/24 brd 192.168.1.255 scope global secondary eth0:2
inet6 fe80::7a2b:cbff:fe44:8d72/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:8d:74 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.5/8 brd 10.255.255.255 scope global eth1
inet 169.254.43.98/18 brd 169.254.63.255 scope global eth1:1
inet 169.254.207.131/18 brd 169.254.255.255 scope global eth1:2
inet6 fe80::7a2b:cbff:fe44:8d74/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:8d:76 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.6/8 brd 10.255.255.255 scope global eth2
inet 169.254.126.213/18 brd 169.254.127.255 scope global eth2:1
inet6 fe80::7a2b:cbff:fe44:8d76/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 78:2b:cb:44:8d:78 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.7/8 brd 10.255.255.255 scope global eth3
inet 169.254.155.59/18 brd 169.254.191.255 scope global eth3:1
inet6 fe80::7a2b:cbff:fe44:8d78/64 scope link
valid_lft forever preferred_lft forever
6: eth4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:10:18:9f:70:48 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.8/8 brd 10.255.255.255 scope global eth4
7: eth5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:10:18:9f:70:4a brd ff:ff:ff:ff:ff:ff
inet 10.0.0.9/8 brd 10.255.255.255 scope global eth5
8: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
[root@promotiondbs grid]#
2.7.1 用 oficfg 無法得到 HAIP 的信息
注意，oficfg 命令雖然可以查看集群環境中各個網卡的用途，但是看不到 HAIP 的信息。比如：
[grid@indexserver1 ～]$ oifcfg getif
eth0 192.168.1.0 global public
eth1 10.0.0.0 global cluster_interconnect
[grid@indexserver1 ～]$ oifcfg iflist -p -n
eth0 192.168.1.0 PRIVATE 255.255.255.0
eth1 10.0.0.0 PRIVATE 255.0.0.0
eth1 169.254.0.0 UNKNOWN 255.255.0.0
2.7.2 確認 ASM 使用了 HAIP
要確認 ASM 使用了 HAIP ，可以從 ASM 的啟動日志中看到，以 grid 用戶進入$ORACLE_BASE下的目錄：
[grid@indexserver1 trace]$ cd /u01/app/grid/diag/asm/+asm/+ASM4/trace
[grid@indexserver1 trace]$ more alert_+ASM4.log
Thu Jul 05 13:07:52 2012
* instance_number obtained from CSS = 4, checking for the existence of node 0...
* node 0 does not exist.instance_number = 4
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Private Interface 'eth1:1' configured from GPnP for use as a private interconnect.
[name='eth1:1', type=1, ip=169.254.177.128, mac=78-2b-cb-43-c5-0f, net=169.254.0.0/16, mask=255.255.0.0, use=haip:cluster_intercon
nect/62]
Public Interface 'eth0' configured from GPnP for use as a public interface.
[name='eth0', type=1, ip=192.168.1.70, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as /u01/app/11.2.0.2/grid/dbs/arch
Autotune of undo retention is turned on.
LICENSE_MAX_USERS = 0
SYS auditing is disabled
NOTE: Volume support enabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options.
Usingparametersettingsinserver-sidespfile+DATA/indexgrid/asmparameterfile/registry.253.787835657
System parameters with non-default values:
large_pool_size = 12M
instance_type = "asm"
remote_login_passwordfile = "EXCLUSIVE"
asm_diskstring = "ORCL:*"
asm_power_limit = 1
diagnostic_dest = "/u01/app/grid"
Cluster communication is configured to use the following interface(s) for this instance
169.254.177.128
cluster interconnect IPC version:Oracle UDP/IP (generic)
……
也可以通過視圖確認：
[grid@indexserver1 trace]$ export ORACLE_SID=+ASM4
[grid@indexserver1 trace]$ sqlplus " / as sysdba"
SQL*Plus: Release 11.2.0.2.0 Production on Thu Jul 5 18:22:30 2012
Copyright (c) 1982, 2010, Oracle.All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options
SQL> select name,ip_address from v$cluster_interconnects;
NAME IP_ADDRESS
--------------- ----------------
eth1:1 169.254.177.128
2.7.3 確認 RDBMS 數據庫使用 HAIP
同樣從數據庫的啟動日志或者視圖中，也可以找到使用HAIP的證據。
來看一下數據庫的啟動日志：
[oracle@indexserver1 ～]$ cd $ORACLE_BASE/diag /rdbms/wxxrdb/wxxrdb3/trace/
[oracle@indexserver1 trace]$ more alert_wxxrdb3.log
Thu Jul 05 16:50:30 2012
Adjusting the default value of parameter parallel_max_servers
from 640 to 135 due to the value of parameter processes (150)
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Private Interface 'eth1:1' configured from GPnP for use as a private interconnect.
[name='eth1:1', type=1, ip=169.254.177.128, mac=78-2b-cb-43-c5-0f, net=169.254.0.0/16,mask=255.255.0.0, use=haip:cluster_intercon
nect/62]
Public Interface 'eth0' configured from GPnP for use as a public interface.
[name='eth0', type=1, ip=192.168.1.70, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth0:1' configured from GPnP for use as a public interface.
[name='eth0:1', type=1, ip=192.168.1.80, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth0:2' configured from GPnP for use as a public interface.
[name='eth0:2', type=1, ip=192.168.1.86, mac=78-2b-cb-43-c5-0d, net=192.168.1.0/24, mask=255.255.255.0, use=public/1]
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as /u01/app/oracle/11.2.0.2/database/dbs/arch
Autotune of undo retention is turned on.
IMODE=BR
ILAT =28
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Oracle Label Security and Real Application Testing options.
Using parameter settings in client-side pfile /u01/app/oracle/cfgtoollogs/dbca/wxxrdb/ initwxxrdbTempOMF.ora on machine indexserver1
System parameters with non-default values:
Processes= 150
memory_target= 4800M
control_files= "/u01/app/oracle/cfgtoollogs/dbca/wxxrdb/tempControl.ctl"
db_block_size= 8192
compatible= "11.2.0.0.0"
db_create_file_dest= "+DATA"
undo_tablespace= "UNDOTBS1"
instance_number= 3
remote_login_passwordfile = "EXCLUSIVE"
db_domain= ""
dispatchers= "(PROTOCOL=TCP) (SERVICE=wxxrdbXDB)"
remote_listener= "indexgrid.wxxr.com.cn:1521"
audit_file_dest= "/u01/app/oracle/admin/wxxrdb/adump"
audit_trail= "DB"
db_name= "seeddata"
db_unique_name= "wxxrdb"
open_cursors= 300
diagnostic_dest= "/u01/app/oracle"
Cluster communication is configured to use the following interface(s) for this instance
169.254.177.128
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2
通過視圖：
SQL> select name,ip_address from v$cluster_interconnects;
NAME IP_ADDRESS
--------------- ----------------
eth1:1 169.254.177.128
2.8 減少機器重啟——IO Fencing功能的增強
我們都知道Oracle會通過重啟故障節點的方式實現IO Fencing，解決腦裂風暴。不過，每次重啟故障節點都會伴隨著集群的重構動作，集群重構時會對數據庫進行凍結（Freezing），凍結期間數據庫是無法接受連接、也無法完成外部請求的，客戶端會表現得掛住了。因此，不管是哪種規模的 RAC 環境，都應該盡量減少機器的重啟。或者說，應該采用更加優雅的解決方式。
但是，如何區分一個機器確實是因為故障而失去響應，還是因為負載太重暫時無法響應確實比較困難。Oracle具體是什么樣的算法我無從得知，但是Oracle 11.2 RAC中對于踢出節點的處理比之前溫柔了。
如果某個節點掛起了，對心跳沒有了響應，那么Oracle會先嘗試著殺掉那些參與IO操作的進程（也就是可能會造成數據破壞的進程），比如DBWR、LGWR，如果Oracle不能干掉這些進程，那么Grid就會重啟整個機器。
如果Oracle成功地干掉了這些新進程，那么Oracle就會關閉Grid自己，然后再重啟Grid，而這個重啟是由ohasd控制的，或者說由Grid的控制文件/etc/oracle/scls_scr/<hostname>/root/ohasdrun控制的。
總之，Oracle 11.2 Grid對于節點的重啟不再像以前那么粗暴和絕對了，一定程度上減少了機器重啟的數量。
到目前為止，安裝過程中所涉及的新概念基本都涵蓋了，接下來我們就要開始深入到Grid的內部了。不過，我個人建議，為了加深對這一章內容的把握，你最好把之前裝的Oracle Grid全部刪掉，靠自己的掌握重新裝一遍，這樣印象會很深刻。
那我們就看看該如何干凈地刪除一個Grid。
2.9 Grid的卸載
Oracle 并沒有提供一個圖形化的卸載工具，或許以后的版本會有。要想干凈地卸載，我們也不能簡單地把Oracle目錄刪除了事。在Grid安裝目錄下有一個deinstall目錄，這里的deinstall腳本用于卸載Grid。當我們要對整個集群環境進行重構或者刪除掉RAC時，我們會用到它。
刪除 Grid 的操作步驟很簡單直觀，我們下面刪除一個 4 節點組成的集群，每個節點都有自己的Grid HOME和Oracle Database HOME。正確的卸載順序應該是這樣的。
2.9.1 關閉數據庫和資源
首先，關閉集群各個節點上的所有數據庫以及其他資源。這一步需要以root身份在每一個節點上進行：
[root@indexserver1 ～]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on'indexserver2'
CRS-2673: Attempting to stop 'ora.crsd' on 'indexserver2'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'indexserver2'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.cvu' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.indexserver3.vip' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN2.lsnr' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.registry.acfs' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.DATA.dg' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'indexserver2'
CRS-2677: Stop of 'ora.indexserver3.vip' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.indexserver2.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.indexserver2.vip' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.indexserver4.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.indexserver4.vip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.cvu' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.LISTENER_SCAN3.lsnr' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.scan3.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.LISTENER_SCAN2.lsnr' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.scan2.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.scan3.vip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.indexserver1.vip' on 'indexserver2'
CRS-2677: Stop of 'ora.scan1.vip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.scan2.vip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.indexserver1.vip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.registry.acfs' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.DATA.dg' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'
CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'indexserver2'
CRS-2677: Stop of 'ora.ons' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'indexserver2'
CRS-2677: Stop of 'ora.net1.network' on 'indexserver2' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'indexserver2' has completed
CRS-2677: Stop of 'ora.crsd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.crf' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.ctssd' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.evmd' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.asm' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'indexserver2'
CRS-2677: Stop of 'ora.asm' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'indexserver2'
CRS-2677: Stop of 'ora.crf' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.evmd' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.drivers.acfs' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'indexserver2'
CRS-2677: Stop of 'ora.cssd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'indexserver2'
CRS-2673: Attempting to stop 'ora.diskmon' on 'indexserver2'
CRS-2677: Stop of 'ora.gipcd' on 'indexserver2' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'indexserver2'
CRS-2677: Stop of 'ora.diskmon' on 'indexserver2' succeeded
CRS-2677: Stop of 'ora.gpnpd' on 'indexserver2' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'indexserver2' has completed
CRS-4133: Oracle High Availability Services has been stopped.
在每個節點上都要執行這個腳本，然后開始執行deinstall。
2.9.2 用 deinstall 卸載
接下來，在安裝Grid的第一個節點上，以grid身份運行這個deinstall腳本，這個腳本會運行一系列的檢查，同時會提出一系列問題請你確認，最后才會真正地開始卸載工作。
[grid@indexserver1 ～]$ cd /u01/app/11.2.0/grid/deinstall/
[grid@indexserver1 deinstall]$ ./deinstall
Checking for required files and bootstrapping ...
Please wait ...
Location of logs /u01/app/oraInventory/logs/
############ ORACLE DEINSTALL & DECONFIG TOOL START ############
######################### CHECK OPERATION START #########################
Install check configuration START
Checking for existence of the Oracle home location /u01/app/11.2.0.2/grid
Oracle Home type selected for de-install is: CRS
Oracle Base selected for de-install is: /u01/app/grid
Checking for existence of central inventory location /u01/app/oraInventory
Checking for existence of the Oracle Grid Infrastructure home /u01/app/11.2.0.2/grid
The following nodes are part of this cluster: indexserver1,indexserver2,indexserver3,indexserver4
Install check configuration END
Skipping Windows and .NET products configuration check
Checking Windows and .NET products configuration END
Traces log file: /u01/app/oraInventory/logs//crsdc.log
Enter an address or the name of the virtual IP used on node "indexserver1"[null]
>
indexserver1-vip
The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver1"
繼續輸入其他節點的VIP名字。
Enter the IP netmask of Virtual IP "192.168.123.210" on node "indexserver1"[255.255.255.0]
>
Enter the network interface name on which the virtual IP address "192.168.123.210" is active
>
eth0
Enter an address or the name of the virtual IP used on node "indexserver2"[192.168.123.210]
>
indexserver2-vip
The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver2"
Enter the IP netmask of Virtual IP "192.168.123.211" on node "indexserver2"[255.255.255.0]
>
Enter the network interface name on which the virtual IP address "192.168.123.211" is active[eth0]
>
Enter an address or the name of the virtual IP used on node "indexserver3"[192.168.123.211]
>
indexserver3-vip
The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver3"
Enter the IP netmask of Virtual IP "192.168.123.212" on node "indexserver3"[255.255.255.0]
>
Enter the network interface name on which the virtual IP address "192.168.123.212" is active[eth0]
>
Enter an address or the name of the virtual IP used on node "indexserver4"[192.168.123.212]
>
indexserver4-vip
The following information can be collected by running "/sbin/ifconfig -a" on node"indexserver4"
Enter the IP netmask of Virtual IP "192.168.123.213" on node "indexserver4"[255.255.255.0]
>
Enter the network interface name on which the virtual IP address "192.168.123.213" is active[eth0]
>
Enter an address or the name of the virtual IP[]
>
Network Configuration check config START
Network de-configuration trace file location: /u01/app/oraInventory/logs/netdc_check2012-06-20_05-50-01-PM.log
Specify all RAC listeners (do not include SCAN listener) that are to be de-configured[LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1]:
Network Configuration check config END
Asm Check Configuration START
ASM de-configuration trace file location: /u01/app/oraInventory/logs/asmcadc_check2012-06-20_05-50-05-PM.log
ASM configuration was not detected in this Oracle home.Was ASM configured in this Oracle home (y|n) [n]: y
Specify the ASM Diagnostic Destination [ ]:
Specify the diskstring []: ORCL:*
Specify the diskgroups that are managed by this ASM instance []: DATA
De-configuring ASM will drop the diskgroups at cleanup time.Do you want deconfig tool to drop the diskgroups y|n [y]:
######################### CHECK OPERATION END #########################
####################### CHECK OPERATION SUMMARY #######################
Oracle Grid Infrastructure Home is: /u01/app/11.2.0.2/grid
The cluster node(s) on which the Oracle home de-installation will be performed are:indexserver1,indexserver2,indexserver3,indexserver4
Oracle Home selected for de-install is: /u01/app/11.2.0.2/grid
Inventory Location where the Oracle home registered is: /u01/app/oraInventory
Skipping Windows and .NET products configuration check
Following RAC listener(s) will be de-configured: LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1
ASM instance will be de-configured from this Oracle home
Do you want to continue (y - yes, n - no)? [n]: y
A log of this session will be written to: '/u01/app/oraInventory/logs/deinstall_deconfig2012-06-20_05-48-53-PM.out'
Any error messages from this session will be written to: '/u01/app/oraInventory/logs/deinstall_deconfig2012-06-20_05-48-53-PM.err'
######################## CLEAN OPERATION START ########################
ASM de-configuration trace file location: /u01/app/oraInventory/logs/asmcadc_clean2012-06-20_05-50-53-PM.log
ASM Clean Configuration START
ASM Clean Configuration END
Network Configuration clean config START
Network de-configuration trace file location: /u01/app/oraInventory/logs/netdc_clean2012-06-20_05-50-55-PM.log
De-configuring RAC listener(s): LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1
De-configuring listener: LISTENER
Stopping listener: LISTENER
Listener stopped successfully.
Listener de-configured successfully.
De-configuring listener: LISTENER_SCAN3
Stopping listener: LISTENER_SCAN3
Listener stopped successfully.
Listener de-configured successfully.
De-configuring listener: LISTENER_SCAN2
Stopping listener: LISTENER_SCAN2
Listener stopped successfully.
Listener de-configured successfully.
De-configuring listener: LISTENER_SCAN1
Stopping listener: LISTENER_SCAN1
Listener stopped successfully.
Listener de-configured successfully.
De-configuring Naming Methods configuration file on all nodes...
Naming Methods configuration file de-configured successfully.
De-configuring Local Net Service Names configuration file on all nodes...
Local Net Service Names configuration file de-configured successfully.
De-configuring Directory Usage configuration file on all nodes...
Directory Usage configuration file de-configured successfully.
De-configuring backup files on all nodes...
Backup files de-configured successfully.
The network configuration has been cleaned up successfully.
Network Configuration clean config END
---------------------------------------->
The deconfig command below can be executed in parallel on all the remote nodes.Execute the command on the local node after the execution completes on all the remote nodes.
Run the following command as the root user or the administrator on node "indexserver3".
/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48-48 PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"
Run the following command as the root user or the administrator on node "indexserver2".
/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48- 48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_ 05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"
Run the following command as the root user or the administrator on node "indexserver4".
/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48- 48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_ 05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"
Run the following command as the root user or the administrator on node "indexserver1".
/tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall2012-06-20_05-48- 48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/deinstall2012-06-20_ 05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_ 05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp" -lastnode
Press Enter after you finish running the above commands
<----------------------------------------
這里給出的提示的意思是：在每個節點上運行這些腳本，然后再回到這個界面中按下回車鍵繼續。這幾個腳本都是一樣的，只是在最后一個節點上多了一個-lastnode參數。
下面就在每個節點上以root身份執行這些腳本，這些腳本的輸出比較長，這里就不列出了。在前3個節點上執行這個：
[root@indexserver3 ～]# /tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinstall 2012-06-20_05-48-48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/ deinstall2012-06-20_05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp"
最后一個節點多了一個lastnode，其他都一樣：
[root@indexserver1 ～]# /tmp/deinstall2012-06-20_05-48-48PM/perl/bin/perl -I/tmp/deinsta ll2012-06-20_05-48-48PM/perl/lib -I/tmp/deinstall2012-06-20_05-48-48PM/crs/install /tmp/ deinstall2012-06-20_05-48-48PM/crs/install/rootcrs.pl -force -deconfig -paramfile "/tmp/ deinstall2012-06-20_05-48-48PM/response/deinstall_Ora11g_gridinfrahome1.rsp" –lastnode
4個節點上都執行完之后，再返回到之前執行deinstall的窗口，按下回車鍵，繼續后續的卸載，這次就要開始刪除目錄了：
Removing Windows and .NET products configuration END
Oracle Universal Installer clean START
Detach Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the local node :Done
Delete directory '/u01/app/11.2.0.2/grid' on the local node : Done
Delete directory '/u01/app/grid' on the local node : Done
Detach Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the remote nodes 'indexserver2,indexserver3,indexserver4' : Done
Delete directory '/u01/app/11.2.0.2/grid' on the remote nodes 'indexserver2,indexserver3, indexserver4' : Done
Delete directory '/u01/app/grid' on the remote nodes 'indexserver2' : Done
Delete directory '/u01/app/grid' on the remote nodes 'indexserver3' : Done
Delete directory '/u01/app/grid' on the remote nodes 'indexserver4' : Done
Oracle Universal Installer cleanup was successful.
Oracle Universal Installer clean END
Oracle install clean START
Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver1'
Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver2'
Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver3'
Clean install operation removing temporary directory '/tmp/deinstall2012-06-20_05-48- 48PM' on node 'indexserver4'
Oracle install clean END
######################### CLEAN OPERATION END #########################
####################### CLEAN OPERATION SUMMARY #######################
ASM instance was de-configured successfully from the Oracle home
Following RAC listener(s) were de-configured successfully: LISTENER,LISTENER_SCAN3,LISTENER_SCAN2,LISTENER_SCAN1
Oracle Clusterware is stopped and successfully de-configured on node "indexserver3"
Oracle Clusterware is stopped and successfully de-configured on node "indexserver2"
Oracle Clusterware is stopped and successfully de-configured on node "indexserver1"
Oracle Clusterware is stopped and successfully de-configured on node "indexserver4"
Oracle Clusterware is stopped and de-configured successfully.
Skipping Windows and .NET products configuration clean
Successfully detached Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the local node.
Successfully deleted directory '/u01/app/11.2.0.2/grid' on the local node.
Successfully deleted directory '/u01/app/grid' on the local node.
Successfully detached Oracle home '/u01/app/11.2.0.2/grid' from the central inventory on the remote nodes 'indexserver2,indexserver3,indexserver4'.
Successfully deleted directory '/u01/app/11.2.0.2/grid' on the remote nodes 'indexserver2,indexserver3,indexserver4'.
Successfully deleted directory '/u01/app/grid' on the remote nodes 'indexserver2'.
Successfully deleted directory '/u01/app/grid' on the remote nodes 'indexserver3'.
Successfully deleted directory '/u01/app/grid' on the remote nodes 'indexserver4'.
Oracle Universal Installer cleanup was successful.
Oracle deinstall tool successfully cleaned up temporary directories.
#######################################################################
############# ORACLE DEINSTALL & DECONFIG TOOL END #############
2.9.3 卸載后的檢查確認
Deinstall腳本執行完后，Grid的卸載就算完成了。接下來要做一些檢查，確保卸載沒有問題。我們從以下幾個方面進行檢查。
（1）首先，檢查 4 個節點運行上面這些命令時屏幕上輸出的日志內容，確保沒有重要的錯誤。
（2）其次，檢查集群各節點的/etc/inittab文件，ohasd的內容應該被刪除了，也就是不應該有類似下面的內容：
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
（3）每個節點都不應該有ora或者d.bin的進程運行，否則應該用kill -9干掉它。
[root@indexserver3 ～]# ps -edf|grep ora
root 21238 17607 0 10:25 pts/0 00:00:00 grep ora
[root@indexserver3 ～]# ps -edf|grep d.bin
root 21240 17607 0 10:25 pts/0 00:00:00 grep d.bin
（4）看一下/etc/oracle這個目錄，這個目錄下的那些.loc文件已經被重命名為.orig。
[root@indexserver3 ～]# cd /etc/oracle/
[root@indexserver3 oracle]# ls
ocr.loc.orig olr.loc.orig
2.9.4 刪除目錄
如果上面的這些檢查都沒問題，現在就可以刪除$GRID_HOME 下的所有內容了。不過這個目錄應該已經被清空了。我們也可以繼續清空$ORACLE_HOME目錄的內容。
2.9.5 刪除 ASM 磁盤
現在ASM磁盤還在，那么應該也把它們刪除，從而開始一個全新的、干凈的安裝。這里需要在4個節點上以root身份運行以下命令：
[root@indexserver1 ～]# ls /dev/oracleasm/disks/
WXXRINDEX1
[root@indexserver1 ～]# oracleasm listdisks
WXXRINDEX1
[root@indexserver1 ～]# oracleasm deletedisk wxxrindex1
Clearing disk header: done
Dropping disk: done
[root@indexserver1 ～]# oracleasm listdisks
[root@indexserver1 ～]#
最后，再來個dd：
dd if=/dev/zero of=/dev/emcpowere1 bs=1024 count=1000000
好了，到這里Grid的卸載就全部做完了，接下來重新部署一個Grid吧。
2.10 小結
本章是上一章的內容延續，本來這兩章是合并在一起的。但是一章 80 頁之巨的安裝手冊顯然會給讀者帶來太大的壓力，用做產品的話說就是“用戶體驗很差”。所以我把那些外延性的介紹抽了出來，獨立成一章。
這一章是圍繞著安裝中遇到的那些新界面、新名詞展開的。Oracle 11gR2的安裝界面變化很大，當然最大的變化是配色風格，雖然不太好看，但也不能否定它在我心中“一個偉大產品”的定位。
于是在這一章中，我們談到了“角色分離”的管理思想，也就不詫異為什么Oracle 11gR2中有那么多用戶和用戶組。接著我們討論了SSH用戶等價、NTP時間同步、HAIP多網卡綁定，這些都是Oracle為了“降低部署難度”而做出的種種整合措施，很是符合Oracle“開箱見云”的宣傳口號。但就個人而言，這些“簡化”對于 DBA新人來說并不是好事，因為他們會錯過很多長進的機會，也許這就是進步的代價。
安裝過程還沒有完，還差最后一步——徹底檢查，要確保我們之前的努力沒有白費，能夠放心地把它丟到生產線上去發光散熱。這就是下一章的內容。