2006年05月02日

午前中は平和に過ごしていて。
俺が今までやってきたことの一部を協力会社さんに
引き継ごうっていって資料とか作ってたんだけど。

昨日性能がでなかった機能と同じDBのテーブルを
使う機能が動く〜なんて言うので、今日もセンターに入ることにした。

センターに行ってみてみたら、、、。
今日は早い・・・。

何が原因で昨日が遅かったのか全然わからなくて。
昨日はRAC構成の両ノードから
合計16多重で処理を流してたけど、
今日は片ノードから多重度1。

うーん、でも、、昨日もみてたけど、
I/Oのwaitやビジーも大した事なかったし。
CPUが100パーセントふりきってるわけでもなかったんだよなぁ。

全く同じSQLが流れてて。
SQLトレース上だと、cpu時間もelapsed時間も昨日の1/3くらい。

“来月の月次処理まで様子みるしかないっすね〜”なんていって。

体調悪いからそのまま家帰ろうかなぁとか思ったんだけど、
オフィスに戻って、待機イベントについて調べる。
SET_EVでEVENT 10046のレベルを8にセットする。
db file sequential readとか。

んでもってインデックスの高さなんてのも視野にいれてみる。
OracleのB*Tree索引ってのは、その名の通り、木構造になってる。
ルート、ブランチ、リーフでその木をあらわす。

じゃんじゃんデータ追加されたらどんどん形がくずれてく。
リーフ分割っていう言葉もはじめてしった。

ってか会社入ってから、情報処理の勉強以外に木構造なんてはじめて意識した。

当然せっかく索引があるのに、
パフォーマンス的にネックになってしまったりする。

インデックスにアナライズをかけてから、
INDEX_STATSを検索して高さとか索引に割り当てられてるブロック数とか。

いやー、コレ。
これから勉強の毎日になりそうです。。

まぁ連休はきっちり休ませてもらいます。

コメント

タイトルとURLをコピーしました