文件內容

適用於:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 12.1.0.1 [發行版 10.1 到 12.1]
Oracle Database - Standard Edition - 版本 11.2.0.4 到 11.2.0.4 [發行版 11.2]
Generic Linux
Generic UNIX

用途

Cluster Verification Utility（簡稱 CVU，命令式 runcluvfy.sh 或者 cluvfy）是個非常實用的檢查網路和域名解析的工具，但是它也可能無法捕獲到所有的問題。如果網路和域名解析在安裝之前沒有正常的配置，通常直接導致安裝的失敗。如果網路或者域名解析出現故障，通常會導致 clusterware 或者 RAC 會出現錯誤。本文的目的在於列出一些和網路以及域名相關的檢查專案來檢驗網路和域名解析對 Grid Infrastructure（clusterware）和 RAC 的配置是否是正確的。

適用範圍

本文提供給 Oracle Clusterware/RAC 資料庫管理員和 Oracle 的技術支援工程師參考。

詳細資訊

A. 必要條件

無論是公網或者私網，透過 network ping 的方式透過網路卡傳輸 MTU 大小的資料包能夠正常工作。並且ping的時間非常短。

IP 地址 127.0.0.1 需要對映到 localhost 或者 localhost.localdomain 上。

不要把任何網路卡的地址配置成 127.*.*.*。

公網網路卡的名稱在所有節點上都必須是相同的。

私網網路卡的名稱在 11gR2 的版本上，推薦使用相同的，在 11.2 之前的版本必須是相同的。

無論是公網還是私網，都不能使用本地的子網（169.254.*.*），公網和私網應該分佈在不同的子網中。

MTU 的設定在所有的節點的網路配置中都應該是相同的。

Network size 的配置在所有的節點的網路配置中也都應該是相同的。

由於私有網路連線的實效性，traceroute 需要能夠在網路卡的 MTU 設定上沒有碎片的傳輸或者在所有節點的路由表中透過一“跳”完成。

私網之間的防火牆必須是關閉的狀態。

對於 10.1 到 11.1 的版本，域名解析需要對公共名稱（public name），私有名稱（private name），虛擬名稱（virtual name）都生效。

對於 11.2 的版本，如果沒有 Grid Naming Service (簡稱 NS)，域名解析需要對公共名稱（public name），私有名稱（private name），虛擬名稱（virtual name），SCAN 名稱都生效。而且如果 SCAN 是透過 DNS 配置的，那麼 scan name 就不能包含在本地的 host 檔案中。

對於 11.2.0.2 以及以上的版本，多播群 230.0.1.0 需要能夠在私網的網路配置中工作；如果打了補丁 9974223 230.0.1.0 和 224.0.0.251 是都支援的。如果打了補丁 10411721 （問題在 11.2.0.3 的版本上做了修復），廣播會被支援。詳細請參考 Multicast/Broadcast 的驗證部分。

對於 11.2.0.1 到 11.2.0.3 的版本，安裝的過程中，如果您沒有配置正確 pubic IP, node VIP, and SCAN VIP ，OUI 安裝的過程中會提示 warning。這個 bug9574976 在版本 11.2.0.4 中做了修復，warning 的資訊將不再提示。

11.2.0.2 之前，Oracle 推薦您使用 OS 級別的網路卡繫結功能，根據作業系統平臺的不同，您可以能佈置不同的繫結方式，如：Etherchannel, IPMP, MultiPrivNIC 等等，您需要諮詢 OS 的管理員來做網路卡的繫結功能。從 11.2.0.2 之後，私網冗餘和 HAIP 被引入來支援本地的多個私網網路卡的冗餘功能，詳細資訊，請檢視考文件 note 1210883.1。

如果您的網路中啟用了 jumbo frames，您也可以透過命令來進行檢查，關於 jumbo frames 的詳細資訊，請參考文件 note 341788.1。

B. 正常配置的案例

以下例子中是驗證網路配置的過程中我們期望看到的正常的結果。由於 11.2 和 11.1 之前的版本，在網路配置上稍有不同，我們這裡提供了兩個例子。11gR1 中或以下 11gR2 中之間的區別是 11gR1 中，我們需要公共的名稱，VIP 的名稱，私有的名稱，我們依賴於私有的名稱來找出叢集的私網的 IP 地址。從 11.2 開始我們將不再依賴於私網，當叢集啟動時私網的配置將建立在 GPNP profile 上。假設我們有一個 3 個節點的叢集，我們看到的資訊是如下顯示：

11gR1 or below cluster:

Nodename |Public IP |VIP name |VIP        |Private |private IP1 |private IP2

         |NIC/MTU   |         |           |Name1   |NIC/MTU     |

---------|----------|---------|-----------|--------|----------------------

rac1     |120.0.0.1 |rac1v    |120.0.0.11 |rac1p   |10.0.0.1    |

         |eth0/1500 |         |           |        |eth1/1500   |

---------|----------|---------|-----------|--------|----------------------

rac2     |120.0.0.2 |rac2v    |120.0.0.12 |rac2p   |10.0.0.2    |

         |eth0/1500 |         |           |        |eth1/1500   |

---------|----------|---------|-----------|--------|----------------------

rac3     |120.0.0.3 |rac3v    |120.0.0.13 |rac3p   |10.0.0.3    |

         |eth0/1500 |         |           |        |eth1/1500   |

---------|----------|---------|-----------|--------|----------------------

11gR2 cluster

Nodename |Public IP |VIP name |VIP        |private IP1 |

         |NIC/MTU   |         |           |NIC/MTU     |

---------|----------|---------|-----------|------------|----------

rac1     |120.0.0.1 |rac1v    |120.0.0.11 |10.0.0.1    |

         |eth0/1500 |         |           |eth1/1500   |

---------|----------|---------|-----------|------------|----------

rac2     |120.0.0.2 |rac2v    |120.0.0.12 |10.0.0.2    |

         |eth0/1500 |         |           |eth1/1500   |

---------|----------|---------|-----------|------------|----------

rac3     |120.0.0.3 |rac3v    |120.0.0.13 |10.0.0.3    |

         |eth0/1500 |         |           |eth1/1500   |

---------|----------|---------|-----------|------------|----------

SCAN name |SCAN IP1   |SCAN IP2   |SCAN IP3

----------|-----------|-----------|--------------------

scancl1   |120.0.0.21 |120.0.0.22 |120.0.0.23

----------|-----------|-----------|--------------------

以下是每個節點上都應該驗證的，我們給出的例子是 Linux 平臺的示例：

1. 找到 MTU 設定：
/bin/netstat -in
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500   0   203273      0      0      0     2727      0      0      0 BMRU

# 以上示例中 MTU 的設定是 eth0 設定的是 1500

2. 找到 IP 地址和子網，比對所有節點上的 broadcast 和 netmask 的資訊：
/sbin/ifconfig
eth0      Link encap:Ethernet HWaddr 00:16:3E:11:11:11
          inet addr:120.0.0.1 Bcast:120.0.0.127 Mask:255.255.255.128
          inet6 addr: fe80::216:3eff:fe11:1111/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:203245 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2681 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:63889908 (60.9 MiB) TX bytes:319837 (312.3 KiB)
..

在以上示例中，eth0 的 IP 地址配置是 120.0.0.1，broadcast 是 120.0.0.127，子網掩碼是 255.255.255.128，它的子網是 120.0.0.0，這裡最多可以配置 126 個 IP 地址。更多詳細資訊，請參考“子網的基礎資訊”部分。

注意：每一個被啟用的網路卡必須具備“UP”和“RUNNING”的標識。在Solaris平臺，"PHYSRUNNING"表示物理網路卡是否執行。

3. 透過執行兩次 ping 的命令來確保和以下結果是一致的：

以下是 ping 的例子（從節點 1 public name 到節點 2 的 public name）。

PING rac2 (120.0.0.2) from 120.0.0.1 : 1500(1528) bytes of data.
1508 bytes from rac1 (120.0.0.2): icmp_seq=1 ttl=64 time=0.742 ms
1508 bytes from rac1 (120.0.0.2): icmp_seq=2 ttl=64 time=0.415 ms

--- rac2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.415/0.578/0.742/0.165 ms

請注意丟包和時間。如何丟包不是0%，或者不是sub-second，那說明網路有問題，請聯絡網路管理員檢查。

3.1 在本地透過 public 的 ip 地址，來 ping 所有節點的 public node names，同時使用 MTU 大小的包，來確保網路的連通性。
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac2
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac2
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac3
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 rac3

3.2.1 透過本地的私網 IP 地址，使用 MTU 大小的包，檢查所有節點的私網連通性
# 適合 11gR2 的案例，私網名稱是可選的
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 10.0.0.1
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 10.0.0.1
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 10.0.0.2
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 10.0.0.2
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 10.0.0.3
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 10.0.0.3

3.2.2 透過本地的私網名稱，使用 MTU 大小的包，檢查所有節點的私網IP的連通性
# 適用於 11gR1 和之前的版本。
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 rac1p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 rac1p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 rac2p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 rac2p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 rac3p
/bin/ping -s <MTU> -c 2 -I 10.0.0.1 rac3p

4. Traceroute 私有網路

以下例子，演示了透過 traceroute 從節點 1 的私網 IP 到節點 2 的私有名稱的過程。

# MTU包大小 - 在Linux平臺包長度需要減去28位元組，否則出錯：Message too long is reported.
# 例如，MTU值是1500，那麼我們應該使用1472：

traceroute to rac2p (10.0.0.2), 30 hops max, 1472 byte packets
1 rac2p (10.0.0.2) 0.626 ms 0.567 ms 0.529 ms

MTU 大小的包，透過1跳完成，沒有透過路由表，輸出中沒有出現故障資訊，如："*" or "!H" 的存在表示有故障。

注意：traceroute 中的選項”-F” 在RHEL3/4 OEL4 的版本上由於 OS 的 bug 是不支援的，詳細資訊，請參考 note: 752844.1 。

4.1 透過本地的私網 IP 地址，traceroute 所有節點的私網 IP 地址
# 11gR2 版本及更高版
/bin/traceroute -s 10.0.0.1 -r -F 10.0.0.1 <MTU-28>
/bin/traceroute -s 10.0.0.1 -r -F 10.0.0.2 <MTU-28>
/bin/traceroute -s 10.0.0.1 -r -F 10.0.0.3 <MTU-28>

如果 "-F" 選項不能工作，那麼不使用"-F" 選項，但是包大小設定為3倍MTU值

/bin/traceroute -s 10.0.0.1 -r 10.0.0.1 <3 x MTU>

4.2 透過本地的私網 IP 地址，traceroute 所有節點的私網 IP 地址
# 11gR1 和之前的版本
/bin/traceroute -s 10.0.0.1 -r -F rac1p <MTU-28>
/bin/traceroute -s 10.0.0.1 -r -F rac2p <MTU-28>
/bin/traceroute -s 10.0.0.1 -r -F rac3p <MTU-28>

5. Ping VIP hostname
# Ping 所有 VIP nodename 確保可以解析成正確而的 ip 地址。
# 在 clusterware 之前，ping 的命令需要可以解析所有的 VIP 的節點名字，但是 vip 的地址會失敗，因為 vip 是由 clusterware 來管理的。
# Clusterware 啟動之後，ping 的命令應該會成功：
/bin/ping -c 2 rac1v
/bin/ping -c 2 rac1v
/bin/ping -c 2 rac2v
/bin/ping -c 2 rac2v
/bin/ping -c 2 rac3v
/bin/ping -c 2 rac3v

6. Ping SCAN name
# 1gR2 版本
# Ping SCAN name 應該可以解析到正確的 IP 地址
# 和 VIP 一樣，當在 clusterware 安裝之前，ping 的命令僅僅能夠解析出來 SCAN name，但是會失敗。但是當 clusterware 啟動後，ping 的命令式能夠正常解析並執行的：
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 scancl1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 scancl1
/bin/ping -s <MTU> -c 2 -I 120.0.0.1 scancl1

7. Nslookup VIP hostname 和 SCAN name
# 11gR2 版本：
# 檢查 VIP 的 nodename 和 SCAN name 是否正常的在 DNS 中進行了配置。
/usr/bin/nslookup rac1v
/usr/bin/nslookup rac2v
/usr/bin/nslookup rac3v
/usr/bin/nslookup scancl1

8. 檢查域名解析的順序：
# Linux，Solaris 和 HP-UX，請檢查 /etc/nsswitch.conf，Aix，請檢查 /etc/netsvc.conf
/bin/grep ^hosts /etc/nsswitch.conf
hosts:      dns files

9. 檢查本地的 host 檔案配置
# 如果本地的域名解析是配置在交換機上（nsswitch.conf），請確保解析檔案中沒有任何筆誤或者錯誤的配置資訊，透過 grep 檢查所有的 hostname 和 IP 地址。
# 127.0.0.1 的地址不能對應到 SCAN，public，private 或者是 VIP 的名稱中。

/bin/grep rac1       /etc/hosts
/bin/grep rac2       /etc/hosts
/bin/grep rac3       /etc/hosts
/bin/grep rac1v      /etc/hosts
/bin/grep rac2v      /etc/hosts
/bin/grep rac3v      /etc/hosts
/bin/grep 120.0.0.1 /etc/hosts
/bin/grep 120.0.0.2 /etc/hosts
/bin/grep 120.0.0.3 /etc/hosts
/bin/grep 120.0.0.11 /etc/hosts
/bin/grep 120.0.0.12 /etc/hosts
/bin/grep 120.0.0.13 /etc/hosts

# 11gR2 版本例子
/bin/grep 10.0.0.1   /etc/hosts
/bin/grep 10.0.0.2   /etc/hosts
/bin/grep 10.0.0.3   /etc/hosts
/bin/grep 10.0.0.11 /etc/hosts
/bin/grep 10.0.0.12 /etc/hosts
/bin/grep 10.0.0.13 /etc/hosts

# 11gR1 和之前的版本例子：
/bin/grep rac1p      /etc/hosts
/bin/grep rac2p      /etc/hosts
/bin/grep rac3p      /etc/hosts
/bin/grep 10.0.0.1   /etc/hosts
/bin/grep 10.0.0.2   /etc/hosts
/bin/grep 10.0.0.3   /etc/hosts

# 11gR2 版本的例子
# 如果 SCAN 名稱是透過 DNS 解析的，那麼他們不能出現在本地的 host 檔案中。
/bin/grep scancl1      /etc/hosts
/bin/grep 120.0.0.21 /etc/hosts
/bin/grep 120.0.0.22 /etc/hosts
/bin/grep 120.0.0.23 /etc/hosts

C. 語法介紹

對於不同的平臺上，由於語法的不同，這裡給出一些示例：

Linux:
    /bin/netstat -in
    /sbin/ifconfig
    /bin/ping -s <MTU> -c 2 -I source_IP nodename
    /bin/traceroute -s source_IP -r -F nodename-priv <MTU-28>
    /usr/bin/nslookup

Solaris:
    /bin/netstat -in
    /usr/sbin/ifconfig -a
    /usr/sbin/ping -i source_IP -s nodename <MTU> 2
    /usr/sbin/traceroute -s source_IP -r -F nodename-priv <MTU>
    /usr/sbin/nslookup

HP-UX:
    /usr/bin/netstat -in
/usr/sbin/ifconfig NIC
    /usr/sbin/ping -i source_IP nodename <MTU> -n 2
    /usr/contrib/bin/traceroute -s source_IP -r -F nodename-priv <MTU>
    /bin/nslookup

AIX:
    /bin/netstat -in
    /usr/sbin/ifconfig -a
    /usr/sbin/ping -S source_IP -s <MTU> -c 2 nodename
    /bin/traceroute -s source_IP -r nodename-priv <MTU>
    /bin/nslookup

Windows:
    MTU:
      Windows XP:          netsh interface ip show interface
      Windows Vista/7:    netsh interface ipv4 show subinterfaces
    ipconfig /all
    ping -n 2 -l <MTU-28> -f nodename
    tracert
    nslookup

D. 多播（Multicast）

從版本 11.2.0.2 開始，在引導啟動的過程中，多播組 230.0.1.0 需要能夠正常工作。中介紹了關於另外一個支援的多播組 224.0.0.251。

參考 note 1212703.1 來檢查多播是否正常工作。

由於 11.2.0.3 的版本中包含了的修復，在啟動的過程中會嘗試 230.0.1.0 和 224.0.0.251 中的任何一個組進行多播傳輸，如果任何一個是成功的，GI 就能夠正常啟動。

在 HP-ux 的平臺上，如果使用 10GB 的網路卡作為私網網路卡，如果沒有 B.11.31.1011 版本以上的驅動或者 10GigEthr-02 版本或以上的 software bundle，多播可能無法正常工作。請執行
"swlist 10GigEthr-02"命令來檢查當前的驅動版本。

E. 執行過程中的網路問題

OSWatcher 或者可以用來捕獲執行過程中出現的網路問題。

F. 網路故障的現象

ping 地址無法正常工作

traceroute 無法正常工作

域名解析也無法正常工作。

1 racnode1 (192.168.30.2) 0.223 ms !X 0.201 ms !X 0.193 ms !X

2010-11-21 13:00:44.455: [ GIPCNET][1252870464]gipcmodNetworkProcessConnect: [network] failed connect attempt endp 0xc7c5590 [0000000000000356] { gipcEndpoint : localAddr 'gipc://racnode3:08b1-c475-a88e-8387#10.10.10.23#27573', remoteAddr 'gipc://racnode2:nm_rac-cluster#192.168.0.22#26869', numPend 0, numReady 1, numDone 0, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 0, flags 0x80612, usrFlags 0x0 }, req 0xc7c5310 [000000000000035f] { gipcConnectRequest : addr 'gipc://racnode2:nm_rac-cluster#192.168.0.22#26869', parentEn
2010-11-21 13:00:44.455: [ GIPCNET][1252870464]gipcmodNetworkProcessConnect: slos op : sgipcnTcpConnect
2010-11-21 13:00:44.455: [ GIPCNET][1252870464]gipcmodNetworkProcessConnect: slos dep : No route to host (113)

2010-11-29 10:52:38.603: [GIPCHALO][2314] gipchaLowerProcessNode: no valid interfaces found to node for 2614824036 ms, node 111ea99b0 { host 'aixprimusrefdb1', haName '1e0b-174e-37bc-a515', srcLuid 2612fa8e-3db4fcb7, dstLuid 00000000-00000000 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [55 : 55], createTime 2614768983, flags 0x4 }
2010-11-29 10:52:42.299: [ CRSMAIN][515] Policy Engine is not initialized yet!
2010-11-29 10:52:43.554: [ OCRMAS][3342]proath_connect_master:1: could not yet connect to master retval1 = 203, retval2 = 203
2010-11-29 10:52:43.554: [ OCRMAS][3342]th_master:110': Could not yet connect to new master [1]

2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos op : sgipcnUdpSend
2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos dep : Message too long (59)
2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos loc : sendto
2010-11-04 12:33:22.133: [ GIPCNET][2314] gipcmodNetworkProcessSend: slos info : dwRet 4294967295, addr '19

2010-02-03 23:26:25.804: [GIPCXCPT][1206540320]gipcmodGipcPassInitializeNetwork: failed to find any interfaces in clsinet, ret gipcretFail (1)
2010-02-03 23:26:25.804: [GIPCGMOD][1206540320]gipcmodGipcPassInitializeNetwork: EXCEPTION[ ret gipcretFail (1) ] failed to determine host from clsinet, using default
..
2010-02-03 23:26:25.810: [    CSSD][1206540320]clsssclsnrsetup: gipcEndpoint failed, rc 39
2010-02-03 23:26:25.811: [    CSSD][1206540320]clssnmOpenGIPCEndp: failed to listen on gipc addr gipc://rac1:nm_eotcs- ret 39
2010-02-03 23:26:25.811: [    CSSD][1206540320]clssscmain: failed to open gipc endp

2010-09-20 11:52:54.014: [    CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 453, LATS 328297844, lastSeqNo 452, uniqueness 1284979488, timestamp 1284979973/329344894
2010-09-20 11:52:54.016: [    CSSD][1078421824]clssgmWaitOnEventValue: after CmInfo State val 3, eval 1 waited 0
.. >>>> after a long delay
2010-09-20 12:02:39.578: [    CSSD][1103055168]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 180441784, wrtcnt, 1037, LATS 328883434, lastSeqNo 1036, uniqueness 1284979488, timestamp 1284980558/329930254
2010-09-20 12:02:39.895: [    CSSD][1107286336]clssgmExecuteClientRequest: MAINT recvd from proc 2 (0xe1ad870)

2009-12-10 06:28:31.974: [ OCRMAS][20]proath_connect_master:1: could not connect to master clsc_ret1 = 9, clsc_ret2 = 9
2009-12-10 06:28:31.974: [ OCRMAS][20]th_master:11: Could not connect to the new master
2009-12-10 06:29:01.450: [ CRSMAIN][2] Policy Engine is not initialized yet!
2009-12-10 06:29:31.489: [ CRSMAIN][2] Policy Engine is not initialized yet!

2009-12-31 00:42:08.110: [ COMMCRS][10]clsc_receive: (102b03250) Error receiving, ns (12535, 12560), transport (505, 145, 0)

2011-04-16 02:59:46.943: [    CTSS][1]clsu_get_private_ip_addresses: clsinet_GetNetData failed (). Return [7]

[    CTSS][1](:ctss_init6:): Failed to call clsu_get_private_ip_addr [7]

gipcmodGipcPassInitializeNetwork: failed to find any interfaces in clsinet, ret gipcretFail (1)

gipcmodGipcPassInitializeNetwork: EXCEPTION[ ret gipcretFail (1) ] failed to determine host from clsinet, using default

[ CRSCCL][2570585920]No private IP addresses found.

(:CSSNM00008:)clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 1 nodes with leader 2, dc4sftestdb02, is smaller than cohort of 1 nodes led by node 1, dc4sftestdb01, based on map type 2

G. 關於子網的資訊

請參考 note 1386709.1 獲取更多關於子網的資訊。

參考

NOTE:1386709.1 - The Basics of IPv4 Subnet and Oracle Clusterware
NOTE:1507482.1 - Oracle Clusterware Cannot Start on all Nodes: Network communication with node missing for 90% of timeout interval

NOTE:1056322.1 - Troubleshoot Grid Infrastructure/RAC Database installer/runInstaller Issues
NOTE:1210883.1 - Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip
NOTE:1212703.1 - Grid Infrastructure Startup During Patching, Install or Upgrade May Fail Due to Multicasting Requirement

NOTE:301137.1 - OSWatcher (Includes: [Video])
NOTE:752844.1 - RHEL3, RHEL4, OEL4: traceroute Fails with -F (do not fragment bit) Argument
NOTE:341788.1 - Recommendation for the Real Application Cluster Interconnect and Jumbo Frames

Clusterware 和 RAC 中的域名解析的配置校驗和檢查 (文件 ID 1945838.1)