【RAC】Oracle RAC上線測試場景介紹

1

計劃內重啟單個節點

逐個啟動例項所在的節點

對於AIX、HPUX、Windows：“shutdown –r”；

對於Linux: “shutdown –r now”；

對於Solaris: “reboot”。

1 、在該節點上執行的例項和其他 Clusterware 資源離線（crsctl   stat res -t 輸出的'SERVER'欄位沒有數值

2 、該節點的VIP故障轉移到其中一個倖存的節點上，並顯示狀態為   "INTERMEDIATE"，"state_details "為 "FAILED_OVER"

3 、在重新啟動的節點上執行的SCAN VIP將故障轉移到倖存的節點上。

4 、執行在該節點上的SCAN監聽器將故障轉移到倖存的節點上。

5 、例項恢復由另一個例項執行。

6 、如果停機的例項被指定為首選例項，服務將被轉移到可用的例項上。

7 、客戶端連線被轉移/重新連線到倖存的例項（程式和時間取決於客戶端型別和配置）。在配置了TAF的情況下，選擇語句應該繼續。活動的DML將被中止。

8 、在資料庫重新配置後，倖存的例項繼續處理它們的工作負荷。

1. 檢測節點或例項故障的時間；

2. 完成例項恢復的時間，

檢查執行恢復的例項的警報日誌；

3. 將客戶端活動恢復到相同級別的時間（假設剩餘節點有足夠的容量執行工作負載）；

4. 資料庫重新配置的持續時間；

5.Clusterware 自動重新啟動失敗例項並接受新連線之前的時間；

6.SCAN VIP 和SCAN偵聽器的成功故障切換。

7. 檢測業務是否受影響，影響的範圍

2

重啟當機節點

滾動拔掉伺服器電源

1. 在具有3個或更少節點的叢集上，當Oracle   Clusterware啟動時，其中一個SCAN VIP和偵聽器將重新定位到重新啟動的節點；

2.VIP 將遷移回重新啟動的節點；

3. 由於節點故障而發生故障切換的服務不會自動重新定位；

4. 失敗的資源（asm、偵聽器、例項等）將由Clusterware重新啟動。

1. 所有資源再次可用的時間，

檢查“crsctl   stat res–t”

2. 檢測業務是否受影響，影響的範圍

3

同時重啟所有節點

同時在所有節點上重新啟動。

對於AIX、HPUX、Windows：“shutdown –r”；

對於Linux: “shutdown –r now”；

對於Solaris: “reboot”。

1. 重新啟動所有節點、例項和資源時不會出現問題。

1. 所有資源再次可用的時間，

檢查“crsctl   stat res–t”

2. 檢測業務是否受影響，影響的範圍

4

例項意外故障

1. 啟動客戶端工作負載

2. 找到具有大多客戶端連線的例項，異常終止該例項

對於AIX、HPUX、Linux、Solaris：

獲得pmon程式的程式號，終止該程式；

# ps –ef | grep pmon

# kill –9 <pmon pid>

對於Windows:

獲得pmon執行緒的執行緒id，殺死該執行緒；

SQL> select b.name, p.spid from v$bgprocess b, v$process p   where b.paddr=p.addr and b.name=’PMON’;

cmd> orakill <SID> <Thread ID>

1. 其他例項中的一個執行例項恢復

2. 如果一個首選的例項發生故障，服務將被轉移到可用的例項上

3. 客戶端連線被轉移/重新連線到倖存的例項（程式和時間取決於客戶端型別和配置 ）

4. 短暫凍結後，倖存的例項繼續處理工作負載

5. 失敗的例項將由Oracle叢集軟體重新啟動，除非該功能已被禁用。

1. 檢測例項故障的時間

2. 完成例項恢復的時間。檢查恢復例項的警報日誌

3. 將客戶活動恢復到相同水平的時間（假設剩餘節點有足夠的能力來執行工作負載 ）

4. 故障切換期間資料庫凍結的時間。

5. 在失敗的例項被Oracle Clusterware自動重啟並接受新連線之前的時間

6. 檢測業務是否受影響，影響的範圍

5

重啟故障例項

1. 如果是不受控制的故障，則由Oracle Clusterware自動重新啟動；

2. 如果發出“關機”命令，則需要手動重啟；

3. 當相關例項的“自動啟動”選項被禁用時，手動重新啟動。

1. 例項在沒有任何問題的情況下重新加入RAC叢集（檢視警報日誌等）；

2. 客戶端連線和工作負載將在新例項中進行負載平衡（如果長時間執行/永久連線，則可能需要手動過程來重新分配工作負載）。

1. 跨所有例項重新平衡服務和工作負載之前的時間（包括任何手動步驟）。

6

單個節點公網故障

1. 拔下公用網路的所有網線；

注意：使用NIS的配置也必須實現NSCD，以便此測試成功，並獲得預期結果。

注意：建議不要使用ifconfig來關閉介面，這可能會導致地址仍然被連線到介面上，從而產生意外的結果。

1. 檢查“crsctl stat res –t”

節點的ora.*.network和listener資源將離線。

SCAN VIP 和在節點上執行的偵聽器將故障轉移到倖存的節點。

節點的VIP將故障轉移到倖存節點。

2. 資料庫例項將保持執行，但將在遠端偵聽器中登出。

3. 資料庫服務將故障轉移到其他可用節點之一。

4. 如果配置了TAF，客戶端應故障轉移到可用的例項。

1. 檢測網路故障和重新定位資源的時間。

2. 檢測業務是否受影響，影響的範圍

7

心跳網路故障

1. 拔下心跳網路的所有網線

注意：建議不要使用ifconfig來關閉介面，這可能會導致地址仍然被連線到介面上，從而產生意外的結果

1. 對於11g，11.2.0.2及以上版本：

CSSD 將檢測腦裂情況並執行以下操作之一：

1.1 在兩節點叢集中，節點數最低的節點將繼續存在；

1.2 在多節點叢集中，最大的子叢集繼續存在。

2. 對於12c，12.1.0.2開始，監測腦裂時，權重高的節點將繼續存在；

3. 在被逐出的節點上，將嘗試正常關閉Oracle Clusterware。

2.1 將終止所有具有I/O功能的客戶端程式，並清理所有資源。如果程式終止和/或資源清理未成功完成，則將重新啟動節點。

2.2 假設上述工作已成功完成，

OHASD 將嘗試重新啟動堆疊。在這種情況下堆疊的網路連線完成後將重新啟動已恢復專用網際網路絡。

3. 檢視以下日誌：

$GI_HOME/log/<nodename>/alert<nodename>.log

$GI_HOME/log/<nodename>/cssd/ocssd.log

1. 檢測業務是否受影響，影響的範圍

8

心跳交換機故障（冗餘交換機配置）

1. 在冗餘網路交換機配置中，關閉一個交換機的電源

網路流量應故障轉移到其他交換機，而不影響互連流量或例項。

1. 故障轉移到其他網路卡的時間。如果配置了bonding/teaming/11.2冗餘互連，則應小於100ms。

2. 檢測業務是否受影響，影響的範圍

9

節點無法訪問磁碟子系統的單一路徑（OCR、Voting Device、資料庫檔案）

1. 拔一根儲存連線線路

1. 如果啟用了多路徑，則多路徑配置應提供故障透明性；

2. 對資料庫例項沒有影響。

1. 監視資料庫在負載下的狀態，以確保不發生服務中斷；

2. 路徑故障轉移應該在作業系統日誌檔案中可見。

3. 檢測業務是否受影響，影響的範圍

10

ASM 磁碟丟失

1. 假設ASM正常冗餘；

2. 關閉/拉出/離線（取決於配置）一個ASM磁碟。

1. 對資料庫例項沒有影響；

2.ASM 開始重新平衡（檢視ASM警報日誌）。

1.Monitor progress: select * from v$asm_operation

2. 檢測業務是否受影響，影響的範圍

11

監聽故障

1. 對於AIX、HPUX、Linux、Solaris：

獲得監聽程式的程式號，終止該程式；

# ps –ef | grep tnslsnr

# kill –9 <listener pid>

2. 對於Windows：

找到tnslistener.exe程式，右鍵終止程式

1. 對連線的資料庫會話沒有影響；

2. 新連線重定向到其他節點上的監聽器（取決於客戶端配置）；

3. 如果使用共享伺服器，本地資料庫例項將接收新連線。如果使用專用伺服器，本地資料庫例項將不會接收新連線；

4. 監聽器故障由ORAAGENT檢測並自動重新啟動；

檢視以下日誌：

$GI_HOME/log/<nodename>/crsd/crsd.log

$GI_HOME/log/<nodename>/agent/crs/oraagent _<gi_owner>/oraagent_<gi_owner>.log

1.Clusterware 檢測失敗並重新啟動偵聽器的時間。

2. 檢測業務是否受影響，影響的範圍

12

Scan 監聽失敗

對於AIX、HPUX、Linux和Solaris：

獲取掃描偵聽器程式的PID：

#ps–ef | grep tnslsnr

終止偵聽器程式：

#kill –9 <listener pid>

•對於Windows：

使用Process Explorer來標識

掃描偵聽器的tnslistener.exe程式。可以透過工作管理員kill程式。

1. 對連線的資料庫會話沒有影響。

2. 新連線被重定向到其他節點上的偵聽器

（取決於客戶端配置）

3.CRSD ORAAGENT 檢測到偵聽器故障，並且

自動重新啟動。檢視以下日誌：

4.$GI_HOME/log/<nodename>/crsd/crsd.log

5. $GI_HOME/log/<nodename>/agent/crsd/

oraagent_<GI_owner>/oraagent_<GI_owner>.log

1. 檢測應用連線配置情況

2. 分析scan 監聽失敗原因

3. 檢測業務影響程度和範圍