環境によっては、テーブルが報告されることもあります。このような環境ではどうしたらよいのでしょうか。インデックスは関係ないので、今回の手順とはまったく異なります。ローカル管理表領域のテーブルであれば、自動セグメント領域管理がつかえます。一応Oracleの推奨です。lists”や、”freelistgroups”を定義することで、データブロックの競合を回避することが出来るでしょう。データのインサート時の競合です。busywaits”の発生しているオブジェクト」として報告されることがあります。この場合には、そもそもその全件検索が必要かどうかを見極める必要があります。必要ないのであれば、RACとしてと言うよりは、むしろ、通常のアプリケーションとしての見直しが必要になります。この時点で、スケーラビリティ≒”1.4′′までたどり着きました。実は、この環境ではさらにチューニングを続けて、最終的には、1.9程度まで持っていくことができました。お分かりとおもいますが、アプリケーションのチューニングなしでは、難しいのが現状ではないでしょうか。いま、RACで稼動している環境をお持ちの皆さんは、いまどのくらいのスケーラビリティでそのシステムが稼動しているかご存知ですか?おそらく、問題なく業務をこなしておられるでしょうから、ことさら騒ぐことではないでしょう。スケーラビリティよりなにより、通常の業務を問題なくこなすことのほうが重要ですから。(そういう意味ではダウンタイムがほとんど無い”高可用性”の方がメリットとして大きいでしょう。)でも、もしかしたら、スケーラビリティーが”1′′を下回っているかもしれません。インスタンス障害が発生した時のほうが処理性能が上がるなんてあまり笑えない状況になっていないでしょうか?実稼動が始まると、スケーラビリティーなど、あまり意味の無いことかもしれません。リソースを有効活用したいのは世の常です。同じ処理をこなすなら、速いに越したことはありませんから。CPUの使用率が下がれば、電気消費量も抑えられることでしょう。今年の夏は、特に電気メータの回転率も監視項目に入れたほうがよいかもしれません。RACのチューニングに関しては、これから、もっともっと突き詰めて行きたいとおもっています。今回は取り上げなかった高可用性を実現するためのノウハウなどもいずれご紹介できればとおもっています。するとこちらの方に興味があるかたがたも多いかもしれませんね。今回のシリーズは今週で終わりますが、来週は読者よりいくつかいただいた「RAC環境でのインデックスチューニングの検証」を行います。お楽しみにしてください。reserved.トップページ企業概要プライバシーポリシ。