Oracle-RAC-高可用測試報告

1、高可用技 術(shù) 文 件 技術(shù)文件名稱：Oracle RAC 測試報告 技術(shù)文件編號： 版 本：V1.0 共 20 頁 (包括封面) 擬 制 邵 金 龍 審 核 會 簽 標(biāo)準(zhǔn)化 批 準(zhǔn) 深圳市中興通訊股份有限公司 目目 錄錄 1測試目的.2 2術(shù)語、定義和縮略語.2 2.1術(shù)語、定義.2 2.2縮略語.2 3測試環(huán)境描述.2 4測試過程描述.3 4.1性能測試.3 4.1.1兩臺 B80 組成的單、雙節(jié)點 RAC 性能測試 .3 4.1.2兩臺 P630 組成的單、雙節(jié)點 RAC 性能測試.3 4.1.3兩臺 B80 和一臺 P630 組成的三節(jié)點 RAC 性能測試.3 4.2功能測試.4 4.2

2、.1RMAN 備份和恢復(fù)測試.4 4.2.2exp 備份和 imp 恢復(fù)測試.4 4.2.3正常呼叫時，smap 界面對數(shù)據(jù)的大批量查詢和修改。.4 4.2.4正常呼叫時，后臺 cron 任務(wù)對數(shù)據(jù)的大批量查詢和修改。.5 4.2.5大事務(wù)測試 .5 4.2.6load balance 測試 .5 4.2.7connetc-time failover 的測試.6 4.2.8TAF 測試.6 4.3穩(wěn)定性測試.7 4.3.1模擬呼叫，保持 24 小時 .7 4.3.2網(wǎng)線異常對實例的影響 .7 4.4第二節(jié)點對第一實例的影響.10 4.4.1第二實例啟動對第一實例的影響 .10 4.4.2第二實

3、例正常關(guān)閉對第一實例的影響 .11 4.4.3第二實例異常關(guān)閉對第一實例的影響 .11 4.4.4第二實例所在機器異常關(guān)閉對第一實例的影響 .15 5測試總結(jié).17 5.1測試中發(fā)現(xiàn)問題的說明.17 6獲得的技術(shù)支持.18 第一篇 概 述.3 1范圍.3 2設(shè)計依據(jù).3 3術(shù)語定義.3 第二篇 方案比較.4 4備選方案說明.4 5方案選擇.4 第三篇 系統(tǒng)總體設(shè)計.5 6系統(tǒng)體系結(jié)構(gòu).5 7體系結(jié)構(gòu)概述.5 8子系統(tǒng)和模塊的命名規(guī)則.5 9標(biāo)準(zhǔn)化設(shè)計.5 9.1模塊標(biāo)準(zhǔn)化設(shè)計.5 9.2接口標(biāo)準(zhǔn)化設(shè)計.5 10系統(tǒng)版本規(guī)劃.5 11系統(tǒng)處理流程.5 12子系統(tǒng)說明.6 12.111.1 子系統(tǒng)

4、 1（名稱）.6 12.211.2 子系統(tǒng) 2（名稱）.6 13模塊說明.6 13.1模塊 1（名稱）.6 13.1.1輸入 .6 13.1.2輸出 .6 13.2模塊 2（名稱）.6 14開發(fā)和運行環(huán)境.6 14.1硬件環(huán)境.6 14.2軟件環(huán)境.6 15可靠性設(shè)計.6 16可測試性設(shè)計.6 17安全性設(shè)計.7 第四篇 關(guān)鍵技術(shù)問題說明.8 18關(guān)鍵技術(shù)問題說明.8 第五篇 系統(tǒng)運行說明.9 19配置說明.9 20系統(tǒng)應(yīng)用方式.9 1測試目的測試目的 測試目的，在于驗證多節(jié)點 RAC 的可用性、穩(wěn)定性,以及多節(jié)點 RAC 相對于普通的 Oracle 環(huán)境性能的提升情況 2術(shù)語、定義和縮略語術(shù)

5、語、定義和縮略語 2.1術(shù)語、定義術(shù)語、定義 無。 2.2縮略語縮略語 本文件應(yīng)用了以下縮略語： RACReal Application ClusterOracle 公司數(shù)據(jù)庫集群軟件 CapsCall per Second 智能網(wǎng)名詞，指每秒處理的呼叫數(shù) 3測試環(huán)境描述測試環(huán)境描述 本次測試，由 4 臺 IBM 小型機（2 臺 B80、2 臺 P630）搭建了一個內(nèi)部網(wǎng)絡(luò)，組成 4 節(jié) 點的 RAC 環(huán)境，網(wǎng)絡(luò)內(nèi)的各個節(jié)點通過 10/100M 網(wǎng)卡相互訪問，包括 RAC 節(jié)點間的 heart beat 信息；RAC 數(shù)據(jù)庫以裸設(shè)備方式建在共享磁陣上，各節(jié)點通過光纖交換機訪問磁陣； 呼叫測試時

6、，各節(jié)點上的智能網(wǎng)應(yīng)用，則通過光纖交換機與模擬呼叫儀進行通訊。 硬件信息： 小型機：IBM B80 2 臺，每臺 2 顆 450M 主頻的 POWER3 CPU 和 1G 內(nèi)存 小型機：IBM P630 2 臺，每臺 2 顆 1.2G 主頻的 POWER4 CPU；2G 內(nèi)存 存儲：StorageTek 的 D240 磁陣，6 塊 72G 的硬盤，其中 4 塊做 RAID 0+1，2 塊為 HOT SPARE 光纖交換機：2 臺，型號為 IBM 3534-F08 模擬呼叫儀：INET、MGTS 軟件信息： 操作系統(tǒng)：IBM AIX 5.2 補丁級別 02 雙機軟件：IBM HACMP V5.1

7、 補丁級別 04 RAC 版本：Oracle 9.2.0.5.0 智能網(wǎng)平臺版本：V3.50.05.06_0_2004/08/23 業(yè)務(wù)版本：IIN- GSM_PPSV2.01.01V3.50 4測試過程描述測試過程描述 本次 RAC 的測試，主要是分成三個階段，第一是 RAC 的性能測試，第二個階段，則 主要是針對在性能測試中發(fā)現(xiàn)問題的處理，第三個階段是 RAC 的功能測試、穩(wěn)定性測試。 4.1性能測試性能測試 由于受到模擬呼叫儀處理能力的限制，在性能測試過程中，4 節(jié)點的 RAC 中并沒有所 有節(jié)點都同時使用的情況，大部分情況是啟動其中的 2 個 instance，相當(dāng)于兩節(jié)點的 RAC。

8、測試前提： 1 智能網(wǎng)應(yīng)用與 Oracle 的 instance 同時在同一臺主機上運行 2 智能網(wǎng)的數(shù)據(jù)庫連接為指定連到本機的 instance，沒有做 load balance 和 failover 3 測試時業(yè)務(wù)表 s1cardinf 的記錄數(shù)為 32 萬 4 雙節(jié)點時測試時，每個節(jié)點上的應(yīng)用分別處理不同的號段，無交叉現(xiàn)象 4.1.1兩臺兩臺 B80 組成的單、雙節(jié)點組成的單、雙節(jié)點 RAC 性能測試性能測試 測試目的： 測試在 B80 上，兩節(jié)點的 RAC 相對于單機方式的性能提高情況 測試步驟： 1 啟動一臺機器上的 oracle instance 和智能網(wǎng)應(yīng)用 2 根據(jù)應(yīng)用的處理情

9、況逐步提供呼叫儀的呼叫數(shù)，直到應(yīng)用無法及時處理 3 同時啟動兩臺機器上的 oracle instance 和智能網(wǎng)應(yīng)用 4 根據(jù)應(yīng)用的處理情況逐步提供呼叫儀的呼叫數(shù)，直到應(yīng)用無法及時處理 測試結(jié)果： 單實例方式下，應(yīng)用的最大呼叫處理能力可達到 140caps，此時 CPU 達到 100， 而應(yīng)用出現(xiàn)消息積壓的情況；雙節(jié)點方式下，每個節(jié)點應(yīng)用的最大處理能力為 140caps。 4.1.2兩臺兩臺 P630 組成的單、雙節(jié)點組成的單、雙節(jié)點 RAC 性能測試性能測試 測試目的： 測試在 P630 上，兩節(jié)點的 RAC 相對于單機方式的性能提高情況 測試步驟： 1 動一臺機器上的 oracle in

10、stance 和智能網(wǎng)應(yīng)用 2 根據(jù)應(yīng)用的處理情況逐步提供呼叫儀的呼叫數(shù)，直到應(yīng)用無法及時處理 3 同時啟動兩臺機器上的 oracle instance 和智能網(wǎng)應(yīng)用 4 根據(jù)應(yīng)用的處理情況逐步提供呼叫儀的呼叫數(shù)，直到應(yīng)用無法及時處理 測試結(jié)果： 單實例方式下，應(yīng)用的最大呼叫處理能力可達到 210caps，此時 CPU 達到 100， 而應(yīng)用出現(xiàn)消息積壓的情況；雙節(jié)點方式下，每個節(jié)點應(yīng)用的最大處理能力為 210caps。 4.1.3兩臺兩臺 B80 和一臺和一臺 P630 組成的三節(jié)點組成的三節(jié)點 RAC 性能測試性能測試 測試目的： 測試三節(jié)點的 RAC 的性能情況 測試步驟： 1 同時啟動

11、兩臺 B90 和一臺 P630 上的 oracle instance 和智能網(wǎng)應(yīng)用 2 根據(jù)應(yīng)用的處理情況逐步提供呼叫儀的呼叫數(shù)，直到應(yīng)用無法及時處理 測試結(jié)果： 最終的處理結(jié)果是兩臺 B80 上的最大呼叫能力為 140caps，當(dāng)時 CPU 為 100， 出 現(xiàn)消息積壓情況；而受制于呼叫儀的處理能力，P630 上達到 160caps，而 cpu 占有率 為 81，消息處理正常。 4.2功能測試功能測試 4.2.1RMAN 備份和恢復(fù)測試備份和恢復(fù)測試 測試目的： 測試 RMAN 的備份 測試步驟： 1 使用 rman，執(zhí)行語句，進行整個數(shù)據(jù)庫的備份 2 使用 rman，執(zhí)行語句，備份歸檔日志

12、 測試結(jié)果： 按照預(yù)期的結(jié)果，生成了備份文件。 測試目的： 測試 RMAN 的恢復(fù) 測試步驟： 1 使用 dd 破壞控制文件的設(shè)備/dev/rrcontrol1，使用 RMAN 恢復(fù) 2 刪除表空間 zxin_data，利用之前的備份，使用 RMAN 恢復(fù) 測試結(jié)果： 對于刪除 control file 的測試，恢復(fù)失敗，因為使用的是 rman nocatalog 進行的備 份，在 nocatalog 方式下，備份信息是存放在 control file 中的，現(xiàn)在 control file 損壞，無法 通過 rman 進行恢復(fù)；oracle 建議在使用 nocatalog 方式備份時需將 co

13、ntrol file 和 spfile 單獨 使用操作系統(tǒng)命令進行備份。后者的表空間恢復(fù)正常。 4.2.2exp 備份和備份和 imp 恢復(fù)測試恢復(fù)測試 測試目的： 驗證 exp/imp 進行數(shù)據(jù)庫的備份和恢復(fù) 測試步驟： 1 使用 exp 進行整庫備份 2 刪除用戶 zxin，使用 imp 恢復(fù) 3 刪除表空間 zxin_data，使用 imp 恢復(fù) 測試結(jié)果： exp 備份正常，恢復(fù)測試同樣沒有問題。 4.2.3正常呼叫時，正常呼叫時，smap 界面對數(shù)據(jù)的大批量查詢和修改。界面對數(shù)據(jù)的大批量查詢和修改。 測試前提： 節(jié)點 zxin1 和 zxin2 上正常處理呼叫，呼叫量均為 100ca

14、ps 測試步驟： 1 查詢某卡號段的信息 2 另外同時通過 sqlplus，按照卡號段查詢 s1cardinf 信息 測試結(jié)果： 由于只使用了一個 smap 界面程序操作，因此看不出影響。 4.2.4正常呼叫時，后臺正常呼叫時，后臺 cron 任務(wù)對數(shù)據(jù)的大批量查詢和修改。任務(wù)對數(shù)據(jù)的大批量查詢和修改。 測試前提： 節(jié)點 zxin1 和 zxin2 上正常處理呼叫，呼叫量均為 100caps 測試步驟： 1 利用 shell 通過 sqlplus，按照卡號段循環(huán)查詢 s1cardinf 信息 2 通過 sqlplus 修改 s1cardinf 信息，按照卡號段循環(huán) update s1cardi

15、nf 信息 測試結(jié)果： 后臺對同一個表的連續(xù)的大數(shù)據(jù)查詢、修改，對呼叫影響很大，查詢時 cpu 占有 率上升了 5，如有多個同時運行的話，消息處理積壓的現(xiàn)象將會非常明顯。 4.2.5大事務(wù)測試大事務(wù)測試 測試目的： 測試在異常情況下數(shù)據(jù)的一致性、完整性 測試步驟： 在節(jié)點 zxin1 和 zxin2 上同時運行同一事務(wù)批量修改數(shù)據(jù)，數(shù)據(jù)有交叉 測試結(jié)果： 多次測試，數(shù)據(jù)更新正常。 測試步驟： 1 在節(jié)點 zxin1 和 zxin2 上同時運行同一事務(wù)，在 zxin2 回滾事務(wù) 2 在節(jié)點 zxin1 和 zxin2 上同時運行同一事務(wù)，在 zxin2 kill 該 session 測試結(jié)果：

16、測試結(jié)果正常，未見數(shù)據(jù)異常。 測試步驟： 在節(jié)點 zxin1 和 zxin2 上同時運行模擬程序，通過 sqlplus 連到數(shù)據(jù)庫，批量更新 數(shù)據(jù)，然后退出重連；此過程循環(huán)一晚 測試結(jié)果： 根據(jù)處理的日志看，操作正常。 4.2.6load balance 測試測試 測試目的： 驗證 oracle 的負載均衡功能 測試前提： 1 在 zxin1、zxin2 上啟動實例 2 修改 zxin2 上 tnsnames.ora，啟用 load balance 測試步驟： 1 在 zxin2 上運行 zxstart，建立 SDF 連接 2 利用測試程序，每隔幾秒通過 sqlplus 建立 10 個連接 測

17、試結(jié)果： zxstart 多次測試的結(jié)果，12 個 SDF 連接基本是平均分布，有時則是 5 個在 zxin1 上，7 個在 zxin2 上；而手工建立的 sqlplus 連接，則是完全平均分布的。 4.2.7connetc-time failover 的測試的測試 測試目的： 驗證在客戶端連接時的 failover 功能 測試前提： 1 啟動 zxin1、zxin2 上的實例 2 關(guān)閉 zxin2 的 listener，zxin1 機器上的 listener 正常 3 實例 zxin2 上的 tnsnames.ora 中配置 Address List= (ADDRESS = (PROTOCO

18、L = TCP)(HOST = zxin2)(PORT = 1521) (ADDRESS = (PROTOCOL = TCP)(HOST = zxin1)(PORT = 1521) 測試步驟： 1 在 zxin2 上啟動 zxstart 2 利用測試程序，在 zxin2 上每隔幾秒通過 sqlplus 建立 10 個連接 測試結(jié)果： 兩種方式下，數(shù)據(jù)庫連接都在 zxin1 實例上 4.2.8TAF 測試測試 測試目的： 驗證 Transparent Application Failover 功能及切換時間 測試前提： 1 實例 zxin1、zxin2 正常運行，listener 正常 2 實例

19、 zxin2 啟用 Failover 功能 3 主機 zxin1、zxin2 上的時間一致 測試步驟： 1 Zxin2 上運行 zxstart，啟動平臺程序 2 啟動模擬程序，不停通過 sqlplus 連接 zxin2，記錄無法連接 zxin2 實例的時間 3 通過正常、異常關(guān)閉 zxin2 實例，異常關(guān)閉 zxin2 主機進行測試 4 在 zxin1 上查看 v$session 中各 SDF 連接及 logon_time 測試結(jié)果： zxin2 實例在正常、異常關(guān)閉或者 zxin2 主機被異常關(guān)閉之后，所有連到實例 zxin2 的數(shù)據(jù)庫連接自動切換到了 zxin1，但是數(shù)據(jù)庫連接的切換時間每

20、次都不太一樣，從 8 秒到 59 秒不等，維持在 1 分鐘之內(nèi)。 測試目的： 測試正常呼叫情況下 TAF 的切換時間 測試前提： 1 實例 zxin1、zxin2 正常運行，listener 正常 2 實例 zxin2 啟用 Failover 功能 3 主機 zxin1、zxin2 上的時間一致 測試步驟： 1 zxin2 上運行 zxstart，啟動平臺程序，有 100caps 的呼叫處理 2 啟動模擬程序，不停通過 sqlplus 連接 zxin2，記錄無法連接 zxin2 實例的時間 3 通過正常、異常關(guān)閉 zxin2 實例，異常關(guān)閉 zxin2 主機進行測試 4 在 zxin1 上查看

21、 v$session 中各 SDF 連接及 logon_time 測試結(jié)果： zxin2 實例在正常、異常關(guān)閉或者 zxin2 主機被異常關(guān)閉之后，所有連到實例 zxin2 的數(shù)據(jù)庫連接自動切換到了 zxin1，而且切換時間非?？欤芏嗲闆r下都在 12 秒左 右，沒有超過 10 秒的，可能跟呼叫有關(guān)，在有操作的情況下，zxin1 實例能夠更快的獲取 zxin2 實例 down 的情況，從而更快的切換。 4.3穩(wěn)定性測試穩(wěn)定性測試 4.3.1模擬呼叫，保持模擬呼叫，保持 24 小時小時 測試目的： 測試 RAC 在長時間的呼叫處理下是否正常 測試步驟： 1 在節(jié)點 zxin1、zxin2 上啟動

22、數(shù)據(jù)庫 2 在節(jié)點 zxin1、zxin2 上分別啟動平臺程序，接受呼叫 3 模擬呼叫儀接入，模擬 100caps 的呼叫量，連續(xù)呼叫 24 小時 測試結(jié)果： 系統(tǒng)運行正常，數(shù)據(jù)庫訪問正常，業(yè)務(wù)處理正常。 4.3.2網(wǎng)線異常對實例的影響網(wǎng)線異常對實例的影響 測試目的： 測試公網(wǎng) ip 異常對 RAC 的影響 測試步驟： 1 實例 zxin1、zxin2 啟動，在 zxin2 上啟動平臺程序 2 使用 ifconfig en1 192.1.1.102 delete 刪除 public ip 3 拔掉 zxin2 上 public 網(wǎng)線 測試結(jié)果： zxin2 上建立的到數(shù)據(jù)庫實例 zxin2 的

23、 SDF 連接，進行 failover，切換到 zxin1 上， 客戶端無法以 zx192_1_1_102 這個 connect string 連到實例 zxin2。待到重新加入 ip 或者插 上網(wǎng)線之后，恢復(fù)正常。 測試步驟： 測試私網(wǎng) ip 異常對 RAC 的影響 測試步驟： 1 實例 zxin1、zxin2 啟動，在 zxin2 上啟動平臺程序 2 使用 ifconfig en0 10.1.1.102 delete 刪除 private ip 3 拔掉 zxin2 上用于 RAC 節(jié)點間通訊的 private 網(wǎng)線 測試結(jié)果： 無論是刪除 ip 還是拔掉網(wǎng)線，對于 Oracle 來說，效

24、果一樣。以其中一次測試的過 程為例：大概在 11：03 拔掉網(wǎng)線，然后在 oracle 日志顯示，在實例 zxin1、zxin2 分別在 11：09 和 11：08：45 進行 Communication recofiguration，zxin1 等待 split-brain resolution；10 分鐘之后，11：19 分，實例 zxin2 down 下來，zxin1 實例恢復(fù)正常。在多次 測試的結(jié)果中，發(fā)現(xiàn)在拔掉網(wǎng)線到實例進行 communication 重組之間、和實例等待 split- brain resolution 的過程中，除了有一次能夠通過訪問 zxin1 而不能訪問 zx

25、in2 外，其他幾次 都無法通過 sqlplus 訪問 zxin1、zxin2，而且這兩個階段的時間都固定為 5 分鐘跟 10 分鐘。 后來，發(fā)現(xiàn)第二個階段等待 split-brain 的時間跟數(shù)據(jù)庫中參數(shù)的設(shè)置有關(guān)，修改 參數(shù)_imr_splitbrain_res_wait 為 60 秒后，等待時間由 10 分鐘縮短為 1 分鐘；但是， comminucation 重組之前的超時判斷無法縮短，可能跟 tcp 有關(guān)，修改了 rto_high 等幾個參 數(shù)設(shè)置后，時間依然為 5 分鐘左右，沒有改變。下附 oracle 日志 alert_zxin1.log： Fri Nov 19 11:09:00

26、 2004 Communications reconfiguration: instance 1 Waiting for clusterware split-brain resolution Fri Nov 19 11:09:30 2004 Trace dumping is performing id= Fri Nov 19 11:19:02 2004 Evicting instance 2 from cluster Fri Nov 19 11:19:06 2004 Reconfiguration started List of nodes: 0, Fri Nov 19 11:19:06 20

27、04 Reconfiguration started List of nodes: 0, Nested/batched reconfiguration detected. Global Resource Directory frozen one node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resour

28、ces remastered 732 861 GCS shadows traversed, 0 cancelled, 0 closed 418 GCS resources traversed, 0 cancelled set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 861 GCS shadows traversed, 0 replayed, 0

29、unopened Submitted all GCS remote-cache requests 0 write requests issued in 861 GCS resources 0 PIs marked suspect, 0 flush PI msgs Fri Nov 19 11:19:07 2004 Reconfiguration complete Post SMON to start 1st pass IR Fri Nov 19 11:19:07 2004 Instance recovery: looking for dead threads Fri Nov 19 11:19:0

30、7 2004 Beginning instance recovery of 1 threads Fri Nov 19 11:19:07 2004 Started redo scan Fri Nov 19 11:19:07 2004 Completed redo scan 246 redo blocks read, 42 data blocks need recovery Fri Nov 19 11:19:07 2004 Started recovery at Thread 2: logseq 1032, block 3, scn 0.0 Recovery of Online Redo Log:

31、 Thread 2 Group 4 Seq 1032 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_2 Fri Nov 19 11:19:07 2004 Completed redo application Fri Nov 19 11:19:07 2004 Ended recovery at Thread 2: logseq 1032, block 249, scn 0. 13 data blocks read, 42 data blocks written, 246 redo blocks read Ending instance recovery

32、of 1 threads SMON: about to recover undo segment 11 SMON: mark undo segment 11 as available SMON: about to recover undo segment 12 SMON: mark undo segment 12 as available SMON: about to recover undo segment 13 SMON: mark undo segment 13 as available SMON: about to recover undo segment 14 SMON: mark

33、undo segment 14 as available SMON: about to recover undo segment 15 SMON: mark undo segment 15 as available SMON: about to recover undo segment 16 SMON: mark undo segment 16 as available SMON: about to recover undo segment 17 SMON: mark undo segment 17 as available SMON: about to recover undo segmen

34、t 18 SMON: mark undo segment 18 as available SMON: about to recover undo segment 19 SMON: mark undo segment 19 as available SMON: about to recover undo segment 20 SMON: mark undo segment 20 as available alert_zxin2.log Fri Nov 19 11:08:45 2004 Communications reconfiguration: instance 0 Fri Nov 19 11

35、:09:02 2004 Waiting for clusterware split-brain resolution Fri Nov 19 11:09:15 2004 Trace dumping is performing id= Fri Nov 19 11:19:02 2004 Errors in file /oracle/admin/zxin/bdump/zxin2_lmon_.trc: ORA-29740: evicted by member 1, group incarnation 3 Fri Nov 19 11:19:02 2004 LMON: terminating instanc

36、e due to error 29740 Instance terminated by LMON, pid = 4.4第二節(jié)點對第一實例的影響第二節(jié)點對第一實例的影響 4.4.1第二實例啟動對第一實例的影響第二實例啟動對第一實例的影響 測試前提： zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接入 測試步驟： 正常啟動 zxin2 上的實例（startup） 測試結(jié)果： 第二實例的啟動，對于第一實例的影響僅在重組的時候，重組時間基本上在 1 秒 之內(nèi)；智能網(wǎng)應(yīng)用日志 zxcom.log 內(nèi)，未發(fā)現(xiàn) sdf 異常記錄。日志如 alert_zxin1.log 所 示： Fri Nov

37、 11 19:24:09 2004 Reconfiguration started List of nodes: 0,1, Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 942 1394 GCS shadows travers

38、ed, 0 cancelled, 58 closed 1336 GCS resources traversed, 0 cancelled 39342 GCS resources on freelist, 39981 on array, 39981 allocated set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 1394 GCS shadows

39、 traversed, 697 replayed, 58 unopened Submitted all GCS remote-cache requests 0 write requests issued in 639 GCS resources 0 PIs marked suspect, 0 flush PI msgs Fri Nov 11 19:24:10 2004 Reconfiguration complete Post SMON to start 1st pass IR Fri Nov 11 19:24:10 2004 Instance recovery: looking for de

40、ad threads Instance recovery: lock domain invalid but no dead threads 測試前提： zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，正常呼叫，100caps 測試步驟： 啟動 zxin2 上的 oracle 實例（startup） 測試結(jié)果： 在 zxin1 進行呼叫處理的情況下，zxin2 實例的啟動，對于實例 zxin1 沒有太大影 響，重組時間 1 秒內(nèi)完成，從呼叫儀那邊看，在重組的過程中，有從 10 到 80 不等的 呼叫斷開，受到影響 4.4.2第二實例正常關(guān)閉對第一實例的影響第二實例正常關(guān)閉對第一實例的影響

41、測試前提： 1 zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接入 2 zxin2 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接入 測試步驟： 正常關(guān)閉 zxin2 上的實例（shutdown immediate） 測試結(jié)果： 第二實例的正常關(guān)閉，對于第一實例的影響僅在重組的時候，時間在 1 秒之內(nèi) 測試前提： 1 zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，正常呼叫，100caps 2 zxin2 上 oracle 實例已啟動 測試步驟： 正常關(guān)閉 zxin2 上的實例（shutdown immediate） 測試結(jié)果： 在 zxin1 進行呼叫處理的情況下，z

42、xin2 實例的正常關(guān)閉，對于實例 zxin1 沒有太 大影響，重組時間 1 秒內(nèi)完成，從呼叫儀那邊看，有 80 以內(nèi)的呼叫斷開，受到影響 4.4.3第二實例異常關(guān)閉對第一實例的影響第二實例異常關(guān)閉對第一實例的影響 測試前提： 1 zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接入 2 zxin2 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接入 測試步驟： 異常關(guān)閉 zxin2 上的實例（shutdown abort） 測試結(jié)果： 第二實例的異常關(guān)閉后，第一實例進行資源重組和實例恢復(fù)，總時間在 1 秒左右 日志如 alert_zxin1.log 所示： Thu Nov 11

43、 19:42:26 2004 Reconfiguration started List of nodes: 0, Global Resource Directory frozen one node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 917 1215 GCS s

44、hadows traversed, 0 cancelled, 53 closed 609 GCS resources traversed, 0 cancelled 39406 GCS resources on freelist, 39981 on array, 39981 allocated set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 121

45、5 GCS shadows traversed, 0 replayed, 53 unopened Submitted all GCS remote-cache requests 0 write requests issued in 1162 GCS resources 0 PIs marked suspect, 0 flush PI msgs Thu Nov 11 19:42:26 2004 Reconfiguration complete Post SMON to start 1st pass IR Thu Nov 11 19:42:26 2004 Instance recovery: lo

46、oking for dead threads Thu Nov 11 19:42:26 2004 Beginning instance recovery of 1 threads Thu Nov 11 19:42:26 2004 Started redo scan Thu Nov 11 19:42:26 2004 Completed redo scan 114 redo blocks read, 51 data blocks need recovery Thu Nov 11 19:42:26 2004 Started recovery at Thread 2: logseq 961, block

47、 528, scn 0. Recovery of Online Redo Log: Thread 2 Group 3 Seq 961 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_1 Thu Nov 11 19:42:26 2004 Completed redo application Thu Nov 11 19:42:26 2004 Ended recovery at Thread 2: logseq 961, block 642, scn 0. 51 data blocks read, 51 data blocks written, 114 red

48、o blocks read Ending instance recovery of 1 threads SMON: about to recover undo segment 11 SMON: mark undo segment 11 as available SMON: about to recover undo segment 12 SMON: mark undo segment 12 as available SMON: about to recover undo segment 13 SMON: mark undo segment 13 as available SMON: about

49、 to recover undo segment 14 SMON: mark undo segment 14 as available SMON: about to recover undo segment 15 SMON: mark undo segment 15 as available SMON: about to recover undo segment 16 SMON: mark undo segment 16 as available SMON: about to recover undo segment 17 SMON: mark undo segment 17 as avail

50、able SMON: about to recover undo segment 18 SMON: mark undo segment 18 as available SMON: about to recover undo segment 19 SMON: mark undo segment 19 as available SMON: about to recover undo segment 20 SMON: mark undo segment 20 as available 測試前提： 1 zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，正常呼叫，100caps 2 zxin2 上

51、oracle 實例已啟動，無呼叫接入 測試步驟： 異常關(guān)閉 zxin2 上的實例（shutdown abort） 測試結(jié)果： zxin2 實例異常關(guān)閉后，zxin1 實例進行資源重組（Reconfiguration）和實例恢復(fù) （Instance Recovery） ，總時間在 5 秒左右，從呼叫儀看受到影響的現(xiàn)有呼叫在 100 個 左右（同時有可能導(dǎo)致的呼叫無法接入的情況，在呼叫儀無法統(tǒng)計得到） ，附 alert_zxin1.log Wed Nov 17 19:03:16 2004 Reconfiguration started List of nodes: 0, Global Resour

52、ce Directory frozen one node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 3331 22065 GCS shadows traversed, 0 cancelled, 1203 closed 10217 GCS resources trave

53、rsed, 0 cancelled 29798 GCS resources on freelist, 39981 on array, 39981 allocated set master node info Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 22065 GCS shadows traversed, 0 replayed, 1203 unopened Submitted al

54、l GCS remote-cache requests 0 write requests issued in 20862 GCS resources 1 PIs marked suspect, 0 flush PI msgs Wed Nov 17 19:03:17 2004 Reconfiguration complete Post SMON to start 1st pass IR Wed Nov 17 19:03:17 2004 Instance recovery: looking for dead threads Wed Nov 17 19:03:17 2004 Beginning in

55、stance recovery of 1 threads Wed Nov 17 19:03:17 2004 Started redo scan Wed Nov 17 19:03:19 2004 Completed redo scan 90 redo blocks read, 44 data blocks need recovery Wed Nov 17 19:03:21 2004 Started recovery at Thread 2: logseq 981, block 209, scn 0. Recovery of Online Redo Log: Thread 2 Group 3 Se

56、q 981 Reading mem 0 Mem# 0 errs 0: /dev/rredolog2_1 Wed Nov 17 19:03:21 2004 Completed redo application Wed Nov 17 19:03:21 2004 Ended recovery at Thread 2: logseq 981, block 299, scn 0. 44 data blocks read, 50 data blocks written, 90 redo blocks read Ending instance recovery of 1 threads SMON: abou

57、t to recover undo segment 11 SMON: mark undo segment 11 as available SMON: about to recover undo segment 12 SMON: mark undo segment 12 as available SMON: about to recover undo segment 13 SMON: mark undo segment 13 as available SMON: about to recover undo segment 14 SMON: mark undo segment 14 as avai

58、lable SMON: about to recover undo segment 15 SMON: mark undo segment 15 as available SMON: about to recover undo segment 16 SMON: mark undo segment 16 as available SMON: about to recover undo segment 17 SMON: mark undo segment 17 as available SMON: about to recover undo segment 18 SMON: mark undo se

59、gment 18 as available SMON: about to recover undo segment 19 SMON: mark undo segment 19 as available SMON: about to recover undo segment 20 SMON: mark undo segment 20 as available 4.4.4第二實例所在機器異常關(guān)閉對第一實例的影響第二實例所在機器異常關(guān)閉對第一實例的影響 測試前提： 1 zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接入 2 zxin2 上 oracle 實例和平臺程序已經(jīng)啟動，無呼叫接

60、入 測試步驟： 重啟機器 zxin2（shutdown Fr） 測試結(jié)果： 主機 zxin2 重啟，同實例 zxin2 的 shutdown abort 類似，實例 zxin1 進行資源重組 和實例恢復(fù)，總時間在 1 秒左右 測試前提： 1 zxin1 上 oracle 實例和平臺程序已經(jīng)啟動，正常呼叫，100caps 2 zxin2 上 oracle 實例已經(jīng)啟動 測試步驟： 重啟機器 zxin2（shutdown Fr） 測試結(jié)果： 主機 zxin2 重啟，實例 zxin1 進行資源重組和實例恢復(fù)，總時間在 2 秒左右，受到 影響的呼叫數(shù)目為 50 個左右。附 alert_zxin1.lo