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