最適化してくれないDB2の最適化処理
最適化してくれないDB2の最適化処理（2007年9月20日）のエントリに対してコメント(2008年03月28日)をいただきました。
うーん、ヘボいプログラムは遅いですよね。
SYSSTATスキーマのテーブル操作は裏技ですけど、VOLATILE属性はあなたのおっしゃるヒントでもありますよね。
まあ今の時代はなんでもやってくれるやつのほうが重宝されるかもしれませんが。
とても独断的だったのでウケました。
べつにDB2かばうつもり無いけど、
DB2で管理者やってて開発者が音を上げるのって、
プログラムがヘボいことばかりでした。
組みなおせよ、みたいな。
お互い、経験談だから、自分は偶然そうだっただけという話ですが。
要はDB2を使いこなせていないのはDB2以外のユーザから見たらDB2の特殊性の部分を使いこなせていない開発側が悪いだろうという主張をしたいようですね。
でも、WHERE句にPKだけ指定して１件だけとれてくるSQL文すらまともに主キーつかった検索できないとすれば、いったいプログラム側でどんな工夫が可能なのか、具体的にその方法を提示して頂きたかったなーというのが本音です。
最適化してくれないDB2の最適化処理(解決編)
最適化してくれないDB2の最適化処理(解決編)(2008年3月31日)のエントリに対してコメント(2008年08月22日)をいただきました。
主キーの列順を入れ替えた→結果的に索引の列順が入れ替わった
と読み取りましたが、要は索引の作り方の問題なのでは無いかと思いました。
DB2はV8からは相当Optimizerも賢くきちんと設計して統計情報を取得すれば、
よほどのことが無い限り変なアクセスパスを選択することは無いです。
今後同じようなことが起きた場合、一度以下のものを使ってみる事をオススメします。
指定したSQLを実行するにあたりこんな索引を作ると良いよ、とアドバイスしてくれます。
統計情報に基づきアドバイスしてくれるので、きちんと本番時を模擬したデータを入れて
RUNSTATSをかけた状態で使ってみてください。
【設計アドバイザー】
http://www-06.ibm.com/jp/software/data/developer/library/techdoc/kantandb2.html
最初のエントリのコメントとは異なり、だいぶ具体的な情報適用をいただきました。ただ、残念なことにやっぱり主張は「要は索引の作り方の問題」という視点からは離れていただけていないというところです。
データベースにおいて業務を分析して、正規化手法に基づき正規化した主キーをWHERE句に指定したSQL文で主キーが使われない、主キーのカーディナルを考えて順番を入れかえると使われるというのは、どう考えてもOptimizerが賢いともきちんとしているとも言えないと思います。
私は別にDB2が嫌いで書いているのではなく、教科書で主キーを使うための例として出てくるようなテーブル定義とSQL文を書くだけでは主キーが使われず、いろいろと工夫しなければならないなんて、DB2という看板にふさわしくない、もっと、すごい製品なはずじゃないのかという期待にこたえて欲しいという思いからエントリをあげています。
ちなみに、最初のエントリのコメントで追記したように、DB2側の仕様によるものとの回答をIBMから正式に頂く過程で、ご提示いただいている設計アドバイザーなども使用していましたがどうにもならなかったですね。