—さて、先週はチューニング対象としたインデックスに対する変更を実施し、また、そのインデックスを使う検索側にもインデックス・スキップ・スキャンを使用するように対応をしました。実際のチューニングの現場では、検証期間や、そもそも検証出来る環境が確保できない場合が多く、しかし時々刻々とカットオーバーが迫ってきます。今回のように、確認できる時間と環境が確保できたことに感謝感謝です。ともに、インデックスの変更ができました。その効果の程はいかがなのもでしょうか。数値をもう一度見てましょう。0.67********************************************************当初、RAC構成にするとシングルインスタンス状態のときと比較して、0.67倍と下回ってしまいました。そこで今回のチューニングを行ったわけですが、ではその成果はと言えば、こんな感じです。1.47********************************************************いかがでしょうか。正確に言うと、同じようなインデックスがもうひとつあったので、チューニング対象のインデックスは2個ですが。これまで着目してきた統計情報にはどのような違いが出てきているのでしょうか。(以下はいずれもRACの1つのインスタンスの情報です。)まずは、オブジェクトごとのWaitに関してみてみましょう。---------------------------------------********************************************************まず、ログ系のインデックスのWaitがすっかり姿を消していることがわかります(1)(2)。Waits"がやや増えているようですが、トランザクション量自体が増えているので、それに伴って増えたと考えられます(3)(4)。waits"が発生している、ログ系のインデックスに関して「インスタンス間での競合を減らそう。」=======================================================と言う目的に対して、今回のチューニングが明らかに効果を発揮したといえるでしょう。イベント統計に関しては、どうなっているのでしょうか。..”のWAIT数もケタ違いに減少しています。sync”になりました。このイベントが発生するパターンは2通り考えられます。反対にかなり頻繁にコミットが発行されている環境で起こりえます。後者の場合、かなりの数のトランザクションをこなしているともいえますが。この統計情報を見る限りは、”buffer”の(表現を変えれば、オブジェクトの)待ちがトータルとしてもかなり減少したと判断できます。インデックスをチューニングすることで、他にしわ寄せがきて、トータルでのWaitが大きくなっていないことが確認できればOKでしょう。Sync”にしわ寄せが来てるじゃないか。いえなくもないのですが、これは、処理性能が上昇したために表面化したと言うのが実際です。今回のチューニングが間違った方向に来たわけではないので、あしからず。次のチューニングポイントが見えてきたということは、ステップがひとつ進んだと言うことです。前向きに捕らえましょう。“GCS(グローバルキャッシュサービス)がインスタンス間におけるデータの整合性を保つ役割を担っていることをお話したことがあります。~その5~>参照”これらに関する、統計情報に何か違いはあったのでしょうか。これについては、来週お話しましょう。reserved.トップページ企業概要プライバシーポリシ。