午前中は平和に過ごしていて。 俺が今までやってきたことの一部を協力会社さんに 引き継ごうっていって資料とか作ってたんだけど。
昨日性能がでなかった機能と同じ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を検索して高さとか索引に割り当てられてるブロック数とか。
いやー、コレ。 これから勉強の毎日になりそうです。。
まぁ連休はきっちり休ませてもらいます。
