Rac環境安裝完成之後，打算簡單測試一下Oracle RAC的負載均衡功能。

RAC負載均衡的簡單測試（一）：http://yangtingkun.itpub.net/post/468/279433

RAC負載均衡的簡單測試（二）：http://yangtingkun.itpub.net/post/468/279754

RAC負載均衡的簡單測試（三）：http://yangtingkun.itpub.net/post/468/280044

這篇文章繼續討論負載均衡與例項的忙閒是否有關。

寫完上一篇文章後，感謝網友zzok和wlqj的回饋，根據他們的測試以及Oracle一些文件上的描述，負載均衡的預設配置是與節點忙閒程度有關的。不過節點忙閒程度是PMON程式負責通知，而PMON程式並非事實執行，因此通知很可能有一個延遲，而上面的測試在JOB剛開始執行後不久就開始了，而這時監聽還不清楚節點2上繁忙的這個事實。

由於前一段時間這個環境有別的用處，因此一直耽擱了下來，這兩天翻BLOG的時候，看到這個問題，於是今天重新測試一次。

本地TNSNAMES的設定可以參考第一篇文章。

今天將文章三中測試重新跑了一次，發現不管後臺JOB執行多長的時間，測試結果都與（三）中的測試一致。看來可能是測試方法存在問題。

如果沒有壓力的情況下，Oracle在負載均衡的時候只考慮透過SERVICE_NAME連線的情況，那麼是否Oracle並不是關心例項所在節點的忙閒程度，而是關心透過SERVICE_NAME連線的那些會話的忙閒程度。

下面更改一下測試方式，建立一個TEST.SQL檔案，檔案中包含一個儲存過程，在客戶端上建立一個過程，如果連線到例項1，則直接退出會話，如果連線到例項2，則進行大量的計算操作：

bash-2.03$ more test.sql
declare
        v_instance number;
        v_result number;
begin
        select instance_number into v_instance from v$instance;
        insert into t_record values (v_instance);
        commit;
        if v_instance = 2 then
                for i in 1..200000 loop
                        v_result := log(i+1, i+1);
                end loop;
        end if;
end;
/
exit

建立一個shell檔案，後臺登陸資料庫並執行這個儲存過程：

bash-2.03$ more test.sh
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &

在資料庫中建立T_RECORD表：

SQL> create table t_record (instance_id number);

表已建立。

下面執行test.sh指令碼：

bash-2.03$ . test.sh

考慮PMON程式會有延遲，先後四次呼叫test.sh指令碼，每次間隔一到兩分鐘左右：

bash-2.03$ sqlplus test/test@testrac

SQL*Plus: Release 10.2.0.3.0 - Production on 星期五 4月 24 00:06:12 2009

連線到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac1

SQL> select instance_id, count(*)
2 from t_record
3 group by instance_id;

INSTANCE_ID   COUNT(*)
----------- ----------
          2         23
          1        97

這個結果已經很能說明問題了，如果在把每次呼叫的時間加上，就可以發現，越靠後的呼叫，連線分配到例項1上的越多。

那麼是否能夠說明負載均衡確實與連線到例項的會話忙閒程度有關呢，還不能。注意上面的test.sql檔案，包含了一個退出命令，這會使得例項1上的連線迅速退出，而例項2上由於一直處於處理過程，所以連線無法退出。顯然這個測試和前面第二篇文章的測試結果一樣，只能說明連線數對負載均衡的影響，不能說明節點上負載對負載均衡的影響。

下面將test.sql裡面的exit語句去掉，這樣例項1上會話只是連線上而已，什麼都不做，而例項2上的會話要進行大量的運算。

bash-2.03$ more test.sql
declare
        v_instance number;
        v_result number;
begin
        select instance_number into v_instance from v$instance;
        insert into t_record values (v_instance);
        commit;
        if v_instance = 2 then
                for i in 1..200000 loop
                        v_result := log(i+1, i+1);
                end loop;
        end if;
end;
/

再次執行test.sh指令碼，這次執行了6次，觀察得到的結果：

SQL> conn test/test
已連線。
SQL> select instance_id, count(*)
2 from test.t_record
3 group by instance_id;

INSTANCE_ID   COUNT(*)
----------- ----------
          1        100
          2         80

可以看到，這次例項1上僅比例項2上多出20個連線，差距遠遠不像第一次測試那麼明顯，而查詢GV$SESSION檢視可以看到：

SQL> select inst_id, count(*)
2 from gv$session
3 where service_name = 'testrac'
4 group by inst_id;

   INST_ID   COUNT(*)
---------- ----------
         1        100
         2        103

很好的滿足了測試二的結果。只所以例項一上比例項二多了20個連線，是因為測試開始時，例項2上的連線數比例項1上多了20個左右。

這篇測試從開始到結束執行時間超過30分鐘以上，如果這麼長時間PMON程式都無法將系統忙閒程度反饋給監聽，那麼即使存在反饋意義也不大了。

透過這個測試，再一次證明RAC的負載均衡與各個例項上的透過監聽的連線數量有關，而與各個例項的忙閒程度無關。

RAC負載均衡的簡單測試（四）

相關文章