ダメダメSQL文をいつ見つけるべきか

SoftwareTest

ある研修の講師をされている方から、ある会社の事例として次のような話を聞き、結論に？？？となったのでメモ。

システムの運用が開始されてしばらくしてから、夜間バッチの性能が想定よりも低いことが分かった。ついに、規定の処理時間内にバッチ実行が終わなくなってしまい、昼間の業務処理に影響を及ぼす事態になった。

このようなことが起きた直接的な理由は、インデックスの張り忘れだった。間接的な理由は、理由は、性能テスト時に見積もった将来のデータ量が、実際よりも少なかったためである。問題になった実際のデータ量よりも、少ないデータ量で性能テストを行ったために、問題が顕在化せず、見過ごしてしまった。

とはいえ、ツールの機能を利用すれば、各処理で実行されるSQL文の詳細を知ることができる。性能テスト時にそこまで調べて、問題のあるSQL文を修正しておくべきだった。

途中までは同意。性能テストに使うデータ量が、業務を想定したものになっていなかった、と。でも、そこから先が、どうもムズカシイ。最後の結論に疑問がある。

というのも、発行されるSQLの妥当性なんて、システムテストの工程で見るかな？という疑問がある。性能テストをした結果、当初の目標値を満たしていたら、「問題なし」とみなしてドリルダウンしないのは、ムリもないと（自分は）思う。それとも皆、そこまでやってるんだろうか・・・。

現実的には、

  • ダメダメなSQLは、結合テストまでに検出することを前提とする
    • ツールを使ったテストができなくても、レビューはできるハズ
  • データ量の増え方を見積もるときは、業務に詳しい人の意見を聞くこと
  • 運用を開始した後、データの増分が予想どおりかチェックすること
    • 違った場合、nヶ月後、m年後のデータ量を見積もり直し、必要に応じて性能テストを実施する

とかかなぁ、と思った。どうなんだろ。