Запланированная хранимая процедура SQL Server работала, но теперь работает очень медленно

Question

У нас есть хранимая процедура, которая вызывается ежедневным расписанием работы, которое использовалось для работы в разумные сроки, но в настоящее время выполняется очень плохо и неудачно. Какая бы ни была причина, это, похоже, также увядает всю нашу систему. Мы попытались перезагрузить компьютер, но проблема не исчезла.

Хранимая процедура действует как ETL для импорта данных из одной базы данных в другую и внесения некоторых обновлений. При вызове с работы он работал в течение часа, но примерно 7 дней назад он начал принимать 10-15 часов для запуска. Затем за последние 3 дня он полностью потерпел неудачу. Сегодня я позволил ему работать в течение 10 часов, а затем отменил его.

Сообщение об ошибке для неудачных прогонов показало, что он не работает, потому что файл журнала находится вне места. Поэтому я попытался сжать файл журнала, используя приведенный ниже код. Он работал, но не уменьшил размер файла вообще. Поскольку код не работал, я пытался усадка с помощью SSMS, но это не удалось из-за ошибки:

Lock request time out period exceeded

я побежал sp_who2 и, не зная наверняка (я разработчик не DBA), найдено следующее, которое, казалось уместным:

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

Это закончилось тем, что проблема жесткого диска. Первоначально аппаратная команда настаивала, что это не так, но после дальнейших испытаний и обзоров на самом деле это был плохой диск.