身分証のない毎日にも慣れてきました、今日この頃でございます。
ただ、、、問題は、給料がおろせないことです。
まずいです。
それはそうと、客先でまたまた問題が。
条件は揃えたのに、開発環境と本番環境で動作に差異が発生してしまいました
しかもメモリ30GBつんで、プロセッサ4つもある本番機が5000倍以上遅いという
なんともよくわからん事態。。。
実行計画見比べると、
開発機→パラレル処理
本番機→通常処理
。。。ここか。
なんで？？？
同じデータ量(600000件)で、同じ定義なのに。
インデックスも同じやし。。。
SQLSERVERの並列処理の条件は
・アクティブなCPU数
・使用可能CPU数
・コストしきい値
今はこれしか処理してないので、全コア使用可能だし、
CPUは全て使えるよう設定してあるし、
しきい値もデフォルトの5のままだし。。。
なんで？？？？
本番機の方がじゃっかんコストが低いため
並列処理にしてくれない。。。
困った。。。
というわけで必殺技、クエリーヒントの出番です。
とりあえず結合アルゴリズムを明示的に指定。
おそらくオプティマイザはネストループで推奨しているっぽいが
ここはハッシュ結合をさせてみる。。。
13時間 → 5秒
はやっ。
Index SeekからIndex Scanに変わるので、コストが若干増加し
並列処理を行ってくれる。
よっしゃと思ってお客さんに相談、
だめだって。。。納得いかないとのこと。。。
いや、だって。。。実行計画一緒にならないっす。。。
どうしようもないっす。。。
もとMSの方がいらっしゃるので「並列処理は制御できる」と強く言われたものの、
「並列→通常」は確かに制御できますよ。。。
でも逆は。。。ヒント句使えって言うけど、MAXDOP句はあくまでも
CPU使用可能数の設定の上書きでしかなく、
そもそもCPU使用可能数は最初から最大値なんですって。。。
「お前がやってみろよ！」と一瞬思ってしまいました。
たしかに、ヒント句なんてある条件の時にしか絶大な効果はないですが。。。
圧倒的にパフォーマンス改善してますし(13時間→5秒)、
本々早い開発環境でも影響がないことは確認していますし、
結合アルゴリズムを変更しただけだし(しかもその中の最速ハッシュ結合)
コスト増加も劇的に増加したわけではなく、ちょびっと加算されたくらいだし。。。
これでカンベンしてください。。。orz
次の日、
SQL改善で納得していただきました。(仕様変更、13時間 → 10秒)
お読み頂き有難うございました。
