Процедура SQL SERVER Несогласованная производительность - PullRequest
0 голосов
/ 05 октября 2009

Я работаю над заданием SQL, которое включает в себя 5 процедур, несколько циклов while и множество вставок и обновлений.

Эта работа обрабатывает около 75000 записей.

Теперь работа отлично работает для 10000/20000 записей со скоростью около 500 / мин. После примерно 20000 записей исполнение просто умирает. Он загружает около 3000 записей каждые 30 минут и работает с той же скоростью.

Я подозревал сеть, но точно не знаю. Подобные запросы сложно анализировать с помощью монитора производительности SQL. Не очень уверен, с чего начать.

Кроме того, в одном из процедур есть один курсор, который выполняется для очень небольшого количества записей.

Любые предложения о том, как ускорить этот процесс для полноразмерного набора данных?

Ответы [ 3 ]

2 голосов
/ 05 октября 2009

Я бы проверил, находятся ли ваши обновления в транзакции. Если это так, это может объяснить, почему он умирает после определенного количества «модифицированных» данных. Вы можете проверить, насколько большой ваш «tempdb» становится индикатором.

Также я видел случаи, когда во время длительных транзакций база данных умирала, когда в то же время были другие «использования», опять же из-за используемых транзакций и неправильных уровней изоляции.

Если вы можете разбить свою работу на независимые непересекающиеся порции, вы можете захотеть сделать это: например, выполнить работу порциями по датам, диапазонам идентификаторов «корневых» объектов и т. Д.

1 голос
/ 06 октября 2009

Я подозреваю, что весь ваш процесс несовершенен. Я импортирую файл данных, который содержит 20 000 000 записей и попал в гораздо большее число таблиц и выполняет очень сложную обработку за меньшее время, чем вы описываете для 75 000 записей. Помните, что зацикливание так же плохо, как использование курсоров.

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

Учитывая текущую настройку, подумайте, не хватает ли вам места во временной базе данных или, возможно, она пытается расти и не может расти достаточно быстро. Также подумайте, если во время замедления начинается какая-то другая работа, которая может вызывать блокировку? Также избавьтесь от циклов и обрабатывайте вещи на основе набора.

0 голосов
/ 06 октября 2009

Хорошо ... вот что я делаю по шагам:

  1. Загрузка файла в таблицу TEMP, просто посредник.
  2. Выполнить некоторые проверки всех записей с использованием транзакций на основе SET.
  3. Фактическая обработка начинается СЕЙЧАС.

СДЕЛКА НАЧИНАЕТСЯ ЗДЕСЬ ......

ПЕТЛЯ НАЧИНАЕТСЯ ЗДЕСЬ

a. Pick Records based in TEMP tables PK (say customer A).

b. Retrieve data from existing tables (e.g. employer information)

c. Validate information received/retrieved.

d. Check if record already exists - UPDATE. else INSERT. (THIS HAPPENS IN SEPARATE PROCEDURE)

e. Find ALL Customer A family members (PROCESS ALL IN ANOTHER **LOOP** - SEPARATE PROC)

f. Update status for CUstomer A and his family members.

КОНЕЦ ПЕТЛИ ЗДЕСЬ

КОНЕЦ СДЕЛКИ ЗДЕСЬ

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...