- - PR -
ロックリソースの［BULK-OP-DB］とは？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-08-05 10:31
おつかれさまです。 ４０Byte × ５０万でしたら，２０ＭＢ程ですか？ これでしたらさほど大きいわけでもないですね。 tempdb が悪いのだとしたら，まずは tempdb の割り当て領域と自動拡張量を確認してみてください。 ただ，さほど大きいものを入れているわけではなさそうなので， SELECT INTO が悪いとも言い切れません。 tempdb ですから，SELECT INTO した後に何か処理をしているのでしょうから， SQL プロファイラでプロセスを監視して，どの処理にどれだけ時間がかかっているか， 本当の原因はどのプロセスなのかを特定したほうがよいと思います。 あと，こちらなど参考にされてはいかがでしょうか。 http://www.microsoft.com/japan/technet/prodtechnol/sql/70/maintain/dat410ef.mspx http://www.microsoft.com/japan/technet/prodtechnol/sql/70/maintain/dat412ef.mspx ---------- TimberLandChapel http://blogs.timberlandchapel.com/ | ||||
|
投稿日時: 2005-08-05 12:36
お世話になります。
本日、ユーザー環境のデータを採取して、社内の開発環境で再現を試してみました。 結果、現象は再現しませんでした。 プロファイラで処理をトレース出来れば、何か手掛かりが掴めると思うのですが、 現象が再現しない為、難航しております。 直接の原因究明は諦めて、tempdbの使用をやめようと考えております。 特に、tempdbの一時テーブルでなくてもよい処理ですので．．． 厄介な問題ですね。 | ||||
|
投稿日時: 2005-08-05 15:09
開発環境では再現しなかったということは，やはり，
本環境下で動作しているプロセス同士の衝突によるパフォーマンスダウンですかね。 こうなってくると， クライアントにお願いして，本環境下でのプロセスの相互影響を監視するか， 自前の開発環境で本環境を再現するなどしなければならないですね。 いずれにしろ， まずはプロファイラによるログの収集が初期対応ではないでしょうか。 tempdb を使用しない書き換え，がんばってください。 _________________ | ||||
|
投稿日時: 2005-08-05 23:09
１点、質問させて下さい。
ユーザー環境の tempdb は、自動拡張が指定してあります。 自動拡張がされたか？という事はログ等で確認可能でしょうか？ | ||||
|
投稿日時: 2005-08-07 14:36
お疲れ様です。 自動拡張は ・データのふくらみが予測できない ・データのふくらみを設計時に意識しなくてすむ ように，設けられているのだと思います。 これが発生したかどうかをロギングしている箇所は無いと思います。 実際にはクエリ実行前と実行後の領域を比べればわかる話ですし。 お使いのクエリの先頭，最後に exec sp_spaceused DBCC SQLPERF(LOGSPACE) による使用サイズを記録する機能を追加して確認してはいかがですか？ | ||||
|
投稿日時: 2005-08-10 12:56
SQL プロファイラで
データベースイベントの FileAutoGroth を拾ったほうが簡単でしたね。 _________________ | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。