Windows-OracleDatabaseがリニアにスローダウンする件
2008年の終わりにリリースしたとあるBIシステム
事象
これは、バッチ(ETL)の11ヶ月間の処理時間統計だ。
線形回帰の近似曲線からも分かるように遅延傾向は二次関数的。
この11ヶ月区間だと傾きは37秒だが、1月-5月の傾きは10秒、6月-10月の傾きは1分20秒にもなってた...
前提条件
- バッチは約100のSQLスクリプト
- SQLはすべてDML/DCLでストアド系の手続き処理はない
- SQLはすべて実行計画がレビュー済みで実行計画も固定済み(統計情報のロック)
- 再編成(ALTER TABLE...MOVE)を週1で全テーブルを対象に実行するようにしている
- 集計元データは増分は年約10%の単調増加
先のグラフから、処理時間の増加は10ヶ月で200%なので、データ量増加への相関は弱いと思う。
処理量の変化
通常運用中から、SET AUTOTRACE ON STATISTICSで実行統計をログに出力しているので分析してみた。
特に遅延傾向の高いSQLについて、10ヶ月前から部分的に確認。
最近の統計
統計
----------------------------------------------------------
3092 recursive calls
1616 db block gets
752 consistent gets
5 physical reads
273004 redo size
658 bytes sent via SQL*Net to client
5288 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
81 sorts (memory)
0 sorts (disk)
6848874 rows processed
physical reads, sorts (disk)など、処理時間に相関の強い値はほとんど変わっていないってまで分かった。
これは、処理時間遅延の原因が、Oracle内の処理量ではなく、内部の"待ち"時間の問題である疑いが...
# 待ち系は、SQL Traceを仕掛けなきゃわかんない；
