Oracle Real Application Clusterの検証　その１

＜Oracle Real Application Clusterの検証　～その１～＞
ペンネーム　ダーリン

今週からは、Real Application Cluster(以下、RAC)に関する検証を行って
いきます。
しかし、RACの検証と一言でいってもあまりにも漠然としているので、少し
整理してみます。

<>
まず、システムを新規に立ち上げる、もしくは、既存のシステムを移行する
場合に、RAC環境で構築するメリットはどこにあるのでしょうか。

一般に、RAC環境では、以下の点にメリットがあるといわれています。

１．高可用性(High Availability)
    障害発生時にHOT/COLDスタンバイ構成のクラスタシステムでは、障害発
    生時等のサービス切り替え時に、一旦サービスの停止が必要であるが、
    RACの場合、サービスの停止は発生しない。

２．スケーラビリティ（Scalability）
    RACを構成するノードを追加することで、データベース全体の処理性能を
    スケーラブル（正比例）に増加することが出来る。Oracle Parallel
    Server (OPS)との大きな違いは、Inter Connectを利用することで実現
    されている。

つまりRAC環境では、システム障害に伴うサービス停止の回避と、ユーザ数
増加などとともに必要になる処理性能の増加を比較的簡単に実現できるソ
リューションといったところでしょうか。

ちなみに、この「スケーラブルな処理性能」というのは「言うはやすし、、」
です。先週のめるまがでも触れましたが、システム移行などで既存のアプリ
ケーションをシングルインスタンス環境からそのままRAC環境へ移行すると、
スケーラビリティが”1″を下回ること請け合いです。
※スケーラビリティ=”1″は、1ノードでの処理性能と同等の性能を現します。
※つまり、スケーラビリティ=”2″は1ノードの時と比較して、2倍の処理性能の意。
※”1″を下回るということは、シングルインスタンスの時より性能が下回ると
※いうこと。

というわけで、今回の検証では、単純には増加してくれないスケーラビリティ
に目をつけ、RAC環境でスケーラビリティを左右する要因を捜して見ることに
します。
検証に使用する環境は、極力シンプルな構成で行うためLinuxの2ノード構成の
環境を主に利用します。

では、当検証環境での処理性能の様子を見てみましょう。私もどのくらいの
性能が出るのか興味深々です。

まず、検証テーブルを作成します。

SQL> CREATE TABLE TEST01
     ( C1 NUMBER
      ,C2 VARCHAR2(100));

SQL> CREATE INDEX IDX_TEST01
     ON TEST01(C1);

このテーブルを対象にデータ作成、更新、検索の各処理を実行し、その際の
EPS値を取得することにします。
※EPS値・・・Execution Per Secondの略称で、単位時間（秒）あたりのSQL実
行数を現します。処理性能の相対評価の指針として使用してい
ます。

次に、評価の基準となる、数値を取得してみます。
取り敢えず、1ノード・1SESSIONでINSERT/UPDATE/SELECTを実行して見ること
にします。(SCRIPTは末尾の例を参照してください。)

その際のEPS値は、以下のとおりでした。

******************************************

NODE1               EPS
---------------------------------------
INSERT処理             274
UPDATE処理             260
SELECT処理             239

******************************************

次に、1ノードで2SESSIONから同時に実行してEPS値を取得します。
結果は以下のとおりです。

******************************************

NODE1 / NODE1           EPS
---------------------------------------
INSERT/INSERT処理         350
UPDATE/UPDATE処理         590
SELECT/SELECT処理         242

******************************************

仮に、1SESSIONの処理性能と比較すると詳細な検討は必要ですが、各処理性能
は上昇しています。UPDATE処理に関しては、DISKのI/Oの影響があったため、
1SESSIONで実行したときの数値が小さく出ています。またの機会に取り直して
みます。

では、2ノードから、各ノード1SESSIONずつ同時に実行してみましょう。

******************************************

NODE1 / NODE2         EPS(NODE1) EPS(NODE2)
-------------------------------------------
INSERT/INSERT処理      95～208    92～211（安定しない）
UPDATE/UPDATE処理      17～160    11～164（徐々に低下）
SELECT/SELECT処理          238        239

NODE1 / NODE2         EPS(TOTAL)
-------------------------------------------
INSERT/INSERT処理      187～419
UPDATE/UPDATE処理       28～324
SELECT/SELECT処理           477

******************************************

さてどうでしょうか。

SELECT処理に関しては、かなりの性能が出ているようです。（ほぼ2倍）
一方、INSERT/UPDATEの処理では、幾分不安定でかならずしも元のEPS値を上
回るわけではないようです。

さてさて、次回からもう少し腰を落ち着けてRACの世界をのぞいてみましょう。

参照(以下はSELECT処理の例です。)

//=============================
require 'dboralib.slb'
global i
global csr={''}
connect darling/darling
if DBERR != 0
        print('connect error=[${DBERR}]',stdout)
        exit
endif

print('start=[${TIME}]',stdout)
loop i=0;i<50000;i++
        if i%100 == 0
                print("select count=[${i}]",stdout)
        endif
        sql select c1 ,c2 from test01 where c1 = :i;
        if DBERR != 0
                print("select error=[${DBERR}]",stdout)
                exit
        endif
        csr = fetch(0)
endloop
print("end=[${TIME}]",stdout)
exit
//=============================

テニスの季節だ！！　　　　　　　　　　茅ヶ崎にて

Oracle Real Application Clusterの検証 その１

Oracle Real Application Clusterの検証　その１