
パーティション化による遅延障害
少し前に、サーバ機のリプレースをしたのですが、それに合わせて既存のテーブルをパーティション化しました。
ところが、こいつが思ったように動かない(--;)
性能向上どころか、遅延障害を量産する結果になってしまいました。
※ 今回の記事は、ただの愚痴で中身はありません。
パーティション化するテーブル
分割したテーブルは、月ごとにデータを蓄積していきます。
そして、このテーブルを使用する処理のほとんどは、年度の単位でデータを抽出する性質があります。
例えば、2012年4月~2013年3月とか、2011年4月~2011年8月とかって感じです。
つまり、抽出開始は常に4月になり、抽出終了は最大で翌年度の3月になります。
なので、年度(4月~翌3月)でパーティション化してやれば「対象年度にのみアクセスされるようになって性能が向上する」という見込みだったのです。
統計情報は再取得しない
ちなみに、統計情報の再取得はしていません。
ものの本とかでは、定期的に統計情報を取得することを進めているのですが、実際には統計情報を再取得することで、安定していた処理で遅延が発生する障害が頻発したので、基本的には再取得はしないようにしています。
Oracleのバージョンアップ(9→11) → 遅延障害が頻発 → SQLチューニング → 遅延解消 → 統計情報の取得 → 遅延障害が頻発 → SQLチューニング → 遅延解消 → 統計情報の取得 → 遅延障害が頻発 ....
これでは、やってられません。
ちなみに、SQLチューニングはヒント句の追加による実行計画の固定です。
運用開始、そして遅延頻発
運用を開始して、暫くは順調に動いていたのですが、新年度になって新しい年度のパーティションを追加したところ、遅延障害が頻発するようになりました。
実行計画を確認したところ、新しい年度(パーティション表)に対してアクセスするSQLの実行計画が、ことごとく変になっている(フルテーブルスキャン、想定外のインデックスの使用など)。
ちなみに、抽出条件を過去の年度にしてみると、あからさまに実行計画が変わります。
統計情報の考察
遅延障害が発生するまで意識してなかったのですが、もしかしてOracleの統計情報はパーティション表のそれぞれに対して情報を取得しているのではないだろうか?
とすると、追加した新年度のパーティション表の情報が統計情報に存在しない(統計情報の再取得はしていないので)。
その結果、コストが正しく算出できなくなり、妙な実行計画の作成に繋がったということなのか?
結局どうした?
最初は、統計情報を再取得しようとも思ったのですが、結局は遅延が発生した処理(SQL)を虱潰しにしてヒント句を追加していくことにしました。
というのも、新年度のパーティション表のデータ件数が少ない状態で統計情報を取り直した時に、Oracleが私の思っている実行計画を作成してくれるか分らなかったからです。
それに、来年度もパーティション表を追加するわけですから、同じ障害を起こしたくなかったんです。
よく「大規模テーブルではパーティションを使うと性能向上する」という話を見たり聞いたりしますが、現実には難しいですね。
もちろん、上手く使えれば有効な機能なんでしょうけど、中途半端な知識を元に「よし、パーティションだ!」とかやると、大参事になるというわけです。
...手間暇かけてパーティション化したのに、メリットをデメリットが上回るのでは意味が無いですよね。
やれやれです。
スポンサードリンク


