РЕДАКТИРОВАТЬ: Оказывается, проблема была с параметром ввода.Очевидно, что если у вас есть входной параметр типа INT со значением по умолчанию NULL (т. Е. @MaxSeqKey int = NULL), и вы используете этот параметр в предложении WHERE, он может ИНОГДА вызвать проблему «зависания».Что действительно странно, так это то, что он работал нормально в течение нескольких месяцев и неожиданно сломался, когда был применен SP3.Поскольку это часть пакетного задания, мы не запускали его в тестовом режиме, так как оно было перенесено в prod.Наш тестовый сервер также имеет SP3, поэтому я запустил его в тестовом режиме после того, как опубликовал этот вопрос.Вот!Он отлично работает в тесте.Пойди разберись.Работа с нашими администраторами баз данных заключалась в том, чтобы объявить внутреннюю переменную INT в proc и установить внутреннюю переменную, равную parm.Еще раз, пойди разберись.Без разницы.Он работает, поэтому я хотел поделиться им с сообществом.
SQL 10.0.5500 (2008 SP3, НЕ 2008R2)
У нас есть пакетное задание, которое запускает сохраненный процесс.Хранимый процесс имеет следующий TSQL.
BEGIN TRANSACTION
UPDATE h
SET h.PreviousHash = h.CurrentHash
,h.CurrentHash = HASHBYTES('SHA1', ISNULL(m.[Name],'') + ISNULL(m.[Address],'') + ISNULL(m.[City],'') + ISNULL(m.[State],'') + ISNULL(m.[Zip],'') )
FROM [Hash] h
INNER JOIN m WITH(NOLOCK) ON m.SequenceKey = h.SequenceKey
WHERE h.SequenceKey <= @MaxSeqKey
INSERT INTO [Hash] (SequenceKey, CurrentHash, PreviousHash, Name, [Address], City, Zip)
SELECT m.SequenceKey
,HASHBYTES('SHA1', ISNULL(m.[Name],'') + ISNULL(m.[Address],'') + ISNULL(m.[City],'') + ISNULL(m.[State],'') + ISNULL(m.[Zip],'') )
,NULL --PreviousHash - this indicates a "new" record
,m.Name
,m.[Address]
,m.City
,m.Zip
FROM Merchants m WITH(NOLOCK)
LEFT JOIN [Hash] h ON h.SequenceKey = m.SequenceKey
WHERE h.SequenceKey IS NULL
AND m.SequenceKey <= @MaxSeqKey
COMMIT TRANSACTION
Это первая часть процесса.Это работало нормально каждую ночь, пока они не установили SQL 2008 SP3 в прошлые выходные.Сначала мы думали, что UPDATE, за которым следует INSERT для той же таблицы, были проблемой, но мы закомментировали оператор UPDATE, и он все еще зависал (он не падает, он просто зависает). Мы запустили оператор INSERT иработает нормально.Кажется, это проблема только при запуске в хранимой процедуре.Так как в нашей системе есть другие подобные операторы в хранимых процессах, которые просто не используют функцию HASHBYTES, мы можем только предположить, что это проблема.Я был бы признателен, если бы кто-нибудь там нашел время, чтобы посмотреть, смогут ли они повторить это.