4.18.Работа с ЦУП. Разбор взаимоблокировки

Чтобы смоделировать взаимоблокировку, возьмем базу «Бухгалтерии предприятия КОРП» и в процедуру Обработка проведения документа Требование-накладная добавим следующий код:

Выполнять его будем так: запустим «1С» в двух сеансах, перепроведем два разных документа Требование-накладная, сначала дойдем в обоих сеансах до останова с помощью модального окна «Подождите1», а потом попытаемся продолжить и дойти до модального окна «Подождите2». В одном из сеансов этого не получится сделать, возникнет взаимоблокировка.

Чтобы разобрать взаимоблокировку с помощью ЦУП, надо сделать следующее:

1. Запустить ЦУП, подключиться к базе в режиме мониторинга и добавить аналитический показатель «Анализ взаимоблокировок СУБД»; либо воспользоваться настроенным (см. раздел 4.17) сценарием «Мониторинг настроенный». В нем можно включить запись всех показателей (см. рис. 4.18.1).

Рис. 4.18.1. Взаимоблокировка MS SQL Server и настройки для ее записи и анализа

• Подождать 1 минуту, выполнить действие. Убедиться, что взаимоблокировка произошла (см. рис. выше).
• После возникновения взаимоблокировки подождать еще 1 минуту (при настройках по умолчанию можно просто дождаться, пока он уйдет с экрана, это несколько дольше 1 минуты).
• Снять флажки, выйти из режима мониторинга кнопкой Стоп.
• Подключиться к базе в режиме просмотра, нажать Авто в мониторе анализа (см. рис. 4.18.2) или Анализ (на рисунке не видна). Иногда при работе на высоконагруженных стендах, где высока вероятность аварийного завершения процессов, есть смысл не нажимать эти кнопки до тех пор, пока состояние анализа в мониторе не станет зафиксированным («Получение исходных данных» изменится на «Исходные данные получены», и появятся зеленые галочки).

Рис. 4.18.2. Взаимоблокировка MS SQL и подготовка данных для анализа в режиме просмотра

• Далее пройдет процесс анализа, по его окончании появится таблица с проблемами (см. рис. 4.18.3 и 4.18.4).

Рис. 4.18.3. Проблемные запросы

Рис. 4.18.4. Проблемные таблицы

• Двойным щелчком по полю с надписью «Взаимоблокировки» перейти в расшифровку взаимоблокировки (см. рис. 4.18.5).

Рис. 4.18.5. Расшифровка взаимоблокировки, аналог ее графа

• Проанализировав таблицу визуально, можно убедиться, что сработал именно наш код, и именно так как было задумано: после записи отдельных областей данных была сделана попытка в тех же транзакциях прочитать общую для них область.
• Нужно убедиться, что речь не идет о записи одного объекта (это актуально для больших нагрузочных тестов), расшифровав запросы из обоих процессов двойным щелчком и посмотрев поле Параметры запроса на закладке Запрос (см. рис. 4.18.6).

Рис. 4.18.6. Параметры запроса. Второй параметр различается

1. Также в расшифровке запроса на закладке Блокировки нужно проверить, не было ли, например, эскалации блокировок (если она была, то в поле Гранулярность будет Таблица), а также какой вообще была гранулярность блокировки.

При блокировке строк или диапазонов ключей индекса компонент Database Engine помещает блокировку намерений (см. раздел ) на страницы, содержащие эти строки или ключи. Это мы видим по полю Режим: запросом на запись строки заблокированы в режиме X, а на уровне страниц стоит блокировка намерений IX (см. рис. 4.18.7), которая остается до конца транзакции.

Рис. 4.18.7. Блокировка намерений на уровне страниц, установленная запросом на запись

Запросом на чтение на том же уровне (т. е. на уровне страниц) делается попытка установить блокировку в режиме S (см. рис. 4.18.8). Это уже не блокировка намерений, а «обычная» блокировка, и в общем-то понятно, почему она такая, исходя из написанного запроса.

Рис. 4.18.8. Блокировка на уровне страниц, устанавливаемая запросом на чтение

Если не включено удаление трассировок, то граф взаимоблокировки можно посмотреть, открыв с помощью SQL Profiler соответствующий файл в каталоге трассировки на сервере СУБД. Иногда это бывает полезно. На файлы трассировки может не хватать прав на открытие. Чтобы это обойти, их можно скопировать в том же каталоге (Ctrl + C, Ctrl + V) и открывать копию файла.

Если при анализе встретилась ошибка «Ошибка при вызове метода контекста (РазделитьФайл)», это означает, что файл logcfg.xml остался в состоянии продолжения сбора данных для ЦУП. Обычно остается сбор ТЖ по одному из аналитических показателей. Для обхода ошибки можно переименовать файл logcfg.xml вручную и повторить попытку анализа, а уже потом разобраться с причинами, вызвавшими эту ошибку.

Следует иметь в виду еще одну вещь: взаимоблокировки и таймауты, которые показывает ЦУП, могут происходить не обязательно в рабочей базе, они могут возникать на самом деле в других базах, а не в исследуемой. Это связано с методикой их получения, которая не дает информации о том, в какой из баз на сервере СУБД произошла ошибка блокировок. Поэтому вместе с аналитическими показателями нужно записывать статистику по запросам: ошибок блокировок без запросов не бывает.

Отправить