SQL Serverのスケジュールされたストアドプロシージャが機能していましたが、現在は非常に遅く実行されています

Question

妥当な時間枠内で動作していましたが、何が原因であれ、それはまた、私たちの全体のシステムを低迷させているようだ。コンピュータを再起動しようとしましたが、問題は解決しませんでした。

ストアドプロシージャは、あるデータベースから別のデータベースにデータをインポートして更新を行うETLとして機能します。仕事から呼び出されたとき、それは1時間以内に実行されていましたが、約7日前に実行に10〜15時間かかり始めました。その後、最後の3日間は完全に失敗しました。今日は10時間走らせてからキャンセルしました。

失敗した実行のエラーメッセージは、ログファイルの領域が不足しているために失敗していることがわかりました。そこで以下のコードを使用してログファイルを縮小しようとしました。それはうまくいったが、ファイルサイズはまったく減少しなかった。コードは動作しませんでしたので、私はSSMSを使用して縮小してみましたが、それはエラーのために失敗しました：私は（私はないDBA開発者です）確かに知らなくても、sp_who2を走り、

Lock request time out period exceeded

、見つかりました関連思え以下：

SPID: 63, Status: Suspended, Command: Delete, CPU Time: 1142382, DiskIO: 1254258

は私がKill 63を使用してそのトランザクションを終了しようとしたので、それが問題になると考えていました。私はsp_who2を実行した場合しかし、それは動作しませんでしたこと表示されますので、それは今

SPID: 63, Status: Suspended, Command: Killed/Rollback, CPU Time: 1142803, DiskIO: 1261601

を読み、問題を解決するために、任意の助けいただければ幸いです！具体的には：

1. 突然すべての悪いパフォーマンスを引き起こす可能性があるアイデアはありますか？

2. ログファイルを縮小するにはどうすればよいですか？それは悪いパフォーマンスを引き起こす可能性がありますか？

ここで私が試したコードは次のとおりです。

USE MyDatabase; 
GO 

ALTER DATABASE MyDatabase 
SET RECOVERY SIMPLE; 
GO 

DBCC SHRINKFILE (MyDatabase_log, 1); 
GO 

ALTER DATABASE MyDatabase 
SET RECOVERY FULL; 
GO 

Answer 1

これは、ハードディスク上の問題になってしまいました。最初はハードウェアチームはそうではないと主張しましたが、それ以降のテストやレビューの後、実際には不良ディスクでした。