Проблема с производительностью 8 вложенных хранимых процедур

Question

У меня проблема с производительностью
Мне нужно запустить хранимую процедуру из .Net 1.1.Эта хранимая процедура вызывает 8 хранимых процедур.Каждый из них обрабатывает информацию, чтобы бросить сравнительный анализ между старой и новой информацией, которая влияет на физическую таблицу в базе данных.

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

Я работаю в среде разработки, поэтому проблем не возникает, но я не могу загрузить это в рабочую среду.

Я думал об использовании процедур только для сравнения и никогда не влиял на физические данные.Извлеките информацию из них во временных таблицах основной процедуры, а затем откройте мои блоки транзакций try-catch и begin-end и воздействуйте на базу данных в моей основной записи, хранящуюся с информацией в временных таблицах.

Мой основной сохраненный внешний вид выглядит следующим образом:Это лучший способ, которым я могу сделать это?

create proc spTest
as
/*Some processes here, temporary tables, etc...*/
begin try
begin distributed transaction
sp_nested1
sp_nested2
sp_nested3
sp_nested4
sp_nested5
sp_nested6
sp_nested7
sp_nested8
/*more processes here, updates, deletes, extra inserts, etc...*/
commit transaction
end try
begin catch
rollback transaction
DECLARE @ERROR VARCHAR(3000)
SELECT @ERROR = CONVERT(VARCHAR(3000),ERROR_MESSAGE())
RAISERROR(@ERROR,16,32)
RETURN
end catch

Базовая структураиз каждого вложенного хранимого процесса похож, но не вызывает другого процесса, только у каждого есть свои блоки try и catch.

Буду признателен за любую помощь ... Используемая мной версия - SQL Server 2005

Заранее всем спасибо ....

Answer 1

Во-первых, когда дела идут медленно, вероятно, проблема в том, что вы написали. Первое, что нужно посмотреть - это план выполнения каждого сохраненного процесса. У вас есть сканы таблицы?

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

Обрабатываете ли вы данные построчно с помощью курсора или цикла, или скалярной пользовательской функции или коррелированного подзапроса? Это может сильно повлиять на скорость. У вас есть правильная индексация? Ваши операторы запросов саркастичны? Я вижу, у вас есть распределенная транзакция, вы уверены, что пользователь, запускающий процесс, имеет правильные права на других серверах? А что за серверы существуют и работают? Вам не хватает места в temp db? Вам нужно запускать это в пакетном режиме, а не пытаться обновить миллионы записей на нескольких серверах?

Не видя этого беспорядка, трудно определить, что может вызвать его замедление.

Но я поделюсь, как я работаю с длинными сложными процессами. Сначала у них у всех есть тестовая переменная, которую я использую для отката транзакций в конце, пока я не буду уверен, что получаются правильные действия. Я также возвращаю результаты того, что я вставил перед выполнением отката. Теперь это изначально не поможет решить проблему со скоростью. Но настройте его в любом случае, потому что, если вы не можете понять, в чем заключается проблема, из плана выполнения, то, вероятно, вам нужно закомментировать все, кроме первого шага, и запустить процесс в тестовом режиме (и откат), затем продолжайте добавлять шаги, пока не увидите тот, на котором он застревает. Конечно, это может быть больше, чем один.