администрирование ным образом уменьшить время выполнения запроса и облегчить работу серверу целиком.
Как лечить блокировки Лечение блокировок очень часто делается командой kill. Что может быть проще: уничтожил головной процесс – и всё заработало! Но у этого подхода есть и отрицательные моменты. Первый – распределённые блокировки склонны повторяться. Так что не исключено, что через некоторое время вы будете дежурить в офисе весь день и всю ночь и держать палец над кнопкой kill. Второй – убивая головной процесс, мы теряем всю информацию о распределённой блокировке. Впоследствии мы можем так никогда и не узнать, что же на самом деле произошло, и не сможем принять меры к тому, чтобы ситуация больше не повторялась. Третья причина – далеко не всегда уничтожение головного процесса приведёт просто к перезапуску клиентского приложения. Иногда ценой вопроса является несколько дней работы целого подразделения. Более правильным вариантом работы является продуманная стратегия блокировок. Но её нельзя делать без хорошего представления о конкретной системе и предметной области. Нужно знать, для каких запросов сгодятся «грязные данные» и какого рода неточности тут могут возникнуть. Некоторые проблемы можно лечить расстановкой подсказки nolock или переводом целых процессов на низший уровень изоляции транзакций. В других ситуациях может потребоваться исправление существенных ошибок проектирования. Например, представьте, что в одной таблице оказались данные справочного типа, запрашиваемые постоянно множеством процессов и активно изменяемые, и важные поля. Эта ситуация будет приводить к постоянным блокировкам – читающие процессы будут мешать изменяющим, и наоборот. Одно из решений – выполнять чтение справочных данных с флагом nolock. Но если это почему-то неприемлемо, то можно воспользоваться другим способом. А именно: разделить эту таблицы на две, с созданием на месте старой таблицы представления (view) с «instead of» триггерами. При этом процессы, запрашивающие
№6, июнь 2005
справочную информацию, будут блокировать одну таблицу, а изменения с помощью триггеров будут выполняться на другой. Повысить или понизить уровень гранулярности блокировок на какомлибо индексе или таблице можно с помощью процедуры sp_indexoption. И всё-таки выработка стратегии блокировок – задача скорее разработчика, чем администратора. Для программиста огромным подспорьем будет уже картина блокировок, полученная вами на этапе поиска проблемы.
Снимаем дедлоки Как уже говорилось, дедлоки, завязанные на несколько объектов, снимаются довольно легко. Ведь такой дедлок означает, что к одним и тем же объектам базы данных разные транзакции обращаются в разном порядке. Достаточно установить один какой-то порядок и проследить, чтобы он везде выполнялся. Если вы решили везде обращаться сначала к А, и только потом к Б, а необходимо сделать наоборот, то надо просто установить сначала блокировку на А, а потом можно работать с Б и снова с А в своё удовольствие. Например, это можно сделать так: declare @l tinyint select @l = 1 ↵ from A with (tablockx) ↵ where 1 = 2
Менее понятно, что делать с дедлоками в рамках одной таблицы. Часто они решаются четким указанием режима уровня блокировок (pagelock, например). Тогда сервер не будет повышать эту блокировку до табличного уровня без крайней необходимости. Возможно, что придётся поработать с индексами и планами запросов, приводящих к взаимной блокировке. Ну и наконец, самый надёжный способ борьбы с дедлоками на уровне таблицы – это подсказка with (tablock) или изменение режима блокировок с помощью sp_indexoption. Конечно, производительность в этой ситуации может пострадать (а может и нет, зависит от конкретной БД). Но зато дедлоков не будет наверняка.
Проблемы на аппаратном уровне Как уже говорилось, решать эту проблему должен не администратор базы
данных. Тут на его долю остаётся только контроль и забота о файлах базы данных – наблюдение за фрагментацией таблиц с помощью dbcc showcontig, регулярная проверка физической целостности и перестройка индексов. Но даже эти простые процедуры могут дать очень большой прирост производительности, особенно если вы давно этим не занимались.
Заключение Описанные сценарии не претендуют на полноту или оптимальность, но они работают, и я использую их ежедневно. Надеюсь, что набор приёмов и рекомендаций пригодится вам при решении проблем производительности MS SQL Server.
Литература и ссылки: 1. Дэн Тоу. Настройка SQL для профессионалов (O’REILLY, «Питер», – 2004 г.). См. обзор в рубрике «Книжная полка» в журнале «Системный администратор», №3, 2005 г. Книга нравится мне тем, что представляет собой не перечень разных правил с неясными граничными условиями применения, а содержит очень чёткие алгоритмы. 2. Блокировки SQL Server 7.0/2000 – теория и практика устранения проблем (По материалам статьи KB224453 Understanding and Resolving SQL Server 7.0 or 2000 Blocking Problems): http://www.sql.ru /articles / mssql/2004/04112301ResolvingBlockingProblems.shtml. 3. Иван Бодягин. Deadlocks. Что такое взаимоблокировки и как с ними бороться (http://www.rsdn.ru/article/db/ deadlocks.xml) – подробный анализ причин возникновения дедлоков, методы диагностики и разрешения. 4. Полезные флаги трассировки SQL Server 7.0 и 2000 (по материалам статьи Randy Dyess «Documented and Undocumented Trace Flags for SQL Server 2000 and 7.0»): http:// www.sql.ru/articles/mssql/02080603 DocumentedAndUndocumentedTraceFlagsForSQLServer.shtml. 5. Рассылка «MS SQL Server – дело тонкое...» – http://subscribe.ru/catalog/comp.soft.winsoft.sqlhelpyouself. 6. Форум на сайте SQL.ru: http:// w w w.sql.ru / forum /ac tualtopic s. aspx?bid=1.
47