Oracle Real Application Clusterの検証 その６
＜Oracle Real Application Clusterの検証 ～その６～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
先週までは、RAC環境においてスケーラビリティがよくない（”1″を下回るよ
うな）場合、Oracleの統計情報でどのような変化が現れているかを見てきま
した。
これまででわかったことを整理してみると、、、
今回のRAC環境では、
<>
**********************************************************
1.”enqueue”イベントで待ちが多い。
2.”buffer busy waits”イベントで待ちが多い。
3.”buffer busy global cache”イベントで待ちが多い。
4.”enqueue”の中でも、”TX”エンキュー待ちが多い。
5.”buffer busy waits”の大半は、ログ系のインデックス。
6.ログ系のインデックスでは”ITL waits”も発生している。
7.”global cache convert”に関する処理時間が長い。
8.”global lock get”に関する処理時間が長い。
**********************************************************
と、言うことがわかりました。
差し当たってのチューニングポイントとしては、
“buffer busy waits”が発生している、ログ系のインデックスに関して
「インスタンス間での競合を減らそう。」
と言う点になります。
では、テーブル構成、インデックス構成がどのようになっているかと言うと、
SQL> desc logtbl1 名前 NULL? 型 -------------------- -------- ---------------------------- INS_DATE NOT NULL TIMESTAMP(6) CONNECT_ID NOT NULL CHAR(64) ACTION_CD NUMBER(1) USER_ID CHAR(50) NOTE VARCHAR2(200)
SQL> select INDEX_NAME,TABLE_NAME,COLUMN_NAME,COLUMN_POSITION 2 from user_ind_columns where table_name = 'LOGTBL1'; INDEX_NAME TABLE_NAME COLUMN_NAME COLUMN_POSITION ------------ ------------ ------------ --------------- IDX_LOGTBL1 LOGTBL1 INS_DATE 1
大体、こんな感じです。
登録日(INS_DATE)のカラムにインデックスがついていますね。
さー、取り掛かりましょうか。
問題は 「インスタンス間での競合を減らそう。」でした。
どうすれば、インスタンス間での競合を減らすことが出来るでしょうか。
まずは、インデックスの基本的な動作を考えてみましょう。昇順インデック
スは、シーケンシャルな値をインサートするともっとも大きな値が含まれて
いるリーフブロックに次々とインサートされてます。
大量トランザクションが行われる環境では、かなりブロックの競合が発生し
ているはずです。この様子は、”ITL waits”で確認できます。しかし、今回
のシングルインスタンス環境においては、このブロックの競合自体は問題ない
レベルであることが確認できています。
（＜Oracle Real Application Clusterの検証 ～その３～＞参照のこと）
さて、このインデックスがRAC環境で、各インスタンスを飛び交わないように
する必要があるのですが、皆さん何か思いつく方法はありますか？
このときは、○○○を、△△△する方法と、□□□を、◎◎◎する方法、が
対策案としてあがりました。
で、採用した方法は・・・・ ねたは来週お話しましょう。
皆さんからのアイデアをお待ちしています。出来れば、そのアイデアを使っ
てこちらでどのくらい違いがあるか検証してみたいですね。
(出来るだけ、がんばって検証してみますので、ご意見ください。)
実は、この対応だけでも、スケーラビリティーが1.4程度まで改善しました。
統計情報でも、いくつか明らかに違いが見られたので、これについてもお話
したいとおもいます。
今週はちと短いですが、この辺で失礼します。又来週。
一年ぶりに洗車した車のはじく水玉が気持ちいい。 茅ヶ崎にて