Помимо регламентных заданий, есть еще несколько трюков. Один из них заключается в создании индекса, использовании анализа встроенной статистики запросов и определение тяжелых (кривых) запросов, вызывающих тормоза или блокировки. О видах блокировок написано очень много, я думаю нет смысла их описывать, а вот средства борьбы с каждым из типов — очень даже важная часть. Как определить запрос, который вызвал блокировку, какой индекс может существенно ускорить выполнение запроса, что можно предпринять для снятия нагрузки или устранения блокировок. Обо всем этом чуть ниже. Для работы нам понадобится администратор базы данных — один, администратор сервера — один, сетевой администратор — одни — а скорее всего это один и тот же человек ))) и программист 1С. Если вы морально устойчивый и грамотный специалист, то программистов лучше больше одного, они сами в коллизию войдут и решение будет более изящным. Поехали
Сборник рецептов собран в небольшом количестве тут
SQL скрипт, позволяющий оценить необходимость создание индекса
Cкрипт определения запроса, вызвавшего ожидание, но с большей детализацией
Определяем запрос, вызвавший ожидание на SQL сервере
Активные, готовые к выполнению и ожидающие запросы, а также те, что явно блокируют другие сеансы
По собранным статистикам можно получить самые тяжелые запросы
Но для того чтобы их применять, необходимо понимать, что же они делают. Невозможно попросту взять и налепить индексов в базе. Нужно выполнить оценку целесообразности создания того или иного индекса. В принятии решения помогает не только встроенный механизм MSSQL, Ваш личный опыт, но и программист! Да, администратор, без программиста можно наломать дров. Я понимаю, что это вечное соперничество между программистом и администратором, но до тех пор, пока программист не сможет аргументировать, что сервер неверно настроен и тормоза возникают не из-за кода, все в наших руках! Я не прошу вас мирится с программистом, а призываю найти общий язык и выявить проблему совместно. Бывают моменты, когда один из специалистов немного не понимает, что от него нужно или не хочет. Этот вариант будем считать исключением и рассмотрим идеальную ситуацию, когда все хотят решать проблему.
Полученными дынными необходимо пользоваться осторожно и принимать действия все взвесив и оценив. Критерии необходимости внесения изменений, я постараюсь кратко сформулировать далее.
Допустим вы получили следующую рекомендацию
Очевидно что нет необходимости в данном индексе, так как вставка идет во временную таблицу. Но бывают ситуации, когда индекс реально необходим. И вот теперь на пару с программистом вы должны принять решение о его создании.
Выглядит рекомендация как
1 2 3 4 5 6 7 8 9 10 11 12 13 |
/* Отсутствуют сведения об индексе из ExecutionPlan1.sqlplan Обработчик запросов считает, что реализация следующего индекса может сократить стоимость запроса на 68.0514%. */ USE [DB] GO CREATE NONCLUSTERED INDEX [IX_Document145_VT14742_Fld14747RRef] ON [dbo].[_Document145_VT14742] ([_Fld14747RRef]) INCLUDE ([_Document145_IDRRef]) GO |
Статья о блокировках
Часть первая
Часть вторая