Не могу не упомянуть о методе, позволяющем сохранять подробную информацию о случившемся дедлоке без использования профайлера. Это включение trace-флагов:

DBCC TRACEON(1204, -1)

К сожалению, документирован только один из них – 1024, как раз и обозначающий сохранение информации о дедлоке. Но нам нужен еще и -1 для того, чтобы включить отладку для всех процессов, а не только для текущего. В некоторых случаях для того, чтобы полученная подробнейшая информация о совершившемся дедлоке сохранялась в журнал SQL сервера, потребуется установить еще и флаг 3605. Эти флаги отладки общеизвестны, но не документированы. Используйте их на свой страх и риск.

Мы закончили рассмотрение методов обнаружения проблем и приступаем к обсуждению способов их устранения.

Решаем проблемы производительности

Итак, вы нашли, в какой точке возникает проблема производительности и какого она рода. Поздравляю! Вы сделали 3/4 работы. Осталось совсем немного, всего лишь исправить ситуацию.

Оптимизация индексов

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

Не забывайте об индексах!

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

Используйте составные индексы

Microsoft SQL Server 7.0 не умел использовать в одном запросе два индекса на таблицу. Версия 2000 на это способна, но скорость выполнения запроса вас вряд ли обрадует. Поэтому, если какие-то два поля таблицы участвуют в большинстве запросов, – не делайте два индекса по каждому из столбцов. Сделайте один составной! Составной индекс имеет еще и то преимущество, что если он содержит все нужные для запроса поля, то обращение к таблице не понадобится. Значит, можно избежать операции Bookmark Lookup (поиска страницы в базе по известному индексу), что позволяет увеличить скорость работы раза в два. Мне приходилось добавлять в составной индекс поля, которые в индексе, в общем-то, и не нужны, но позволяют избежать поиска по родительской таблице.