Взаимоблокировка - это неразрешимый конфликт блокировок, возникающий при работе двух или более сессий 1С:Предприятия.

На основе статьи Анализ событий блокировки в DB2 для Linux, UNIX и Windows : Часть 3. Использование монитора событий блокировки для решения проблем параллелизма в DB2 9.7

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

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

Первым делом нам необходимо подготовить базу DB2 для сохранения событий взаимоблокировок и таймаутов в отдельной таблице. Лучше всего войти на сервер под учетной записью db2admin, тогда не будет проблем с правами доступа при выполнении каких-либо операций.

Открываем консоль администратора DB2 и выполняем последовательно следующие операции:

подключение к базе данных
db2 "CONNECT TO <Имя базы>"
создание отдельного табличного пространства для монитора событий
db2 "CREATE TABLESPACE TBSPACE_LOCKING"
создание самого монитора событий
db2 "CREATE EVENT MONITOR EVMON_LOCKING FOR LOCKING WRITE TO UNFORMATTED EVENT TABLE (TABLE EMDATA.TAB_LOCKING IN TBSPACE_LOCKING)"
запуск монитора событий
db2 "UPDATE DB CFG USING MON_DEADLOCK HISTORY IMMEDIATE"
db2 "SET EVENT MONITOR EVMON_LOCKING STATE 1"
отключение от базы
db2 CONNECT RESET

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

Следует учесть, что при большой интенсивности взаимоблокировок и таймаутов, монитор событий может записать значительный объем информации, поэтому желательно отслеживать динамику роста базы и своевременно отключать монитор, либо чистить таблицу с логами.

Чтобы проверить наличие зафиксированных событий можно воспользоваться следующим запросом:
SELECT Count(*) FROM TABLE ( EVMON_FORMAT_UE_TO_XML( 'LOG_TO_FILE',FOR EACH ROW OF ( SELECT * FROM emdata.tab_locking)))

Для очистки истории событий необходимо выполнить вот этот запрос:
DELETE FROM EMDATA."TAB_LOCKING"

Для отключения монитора событий:
db2 "CONNECT TO <Имя базы>"
db2 "SET EVENT MONITOR EVMON_LOCKING STATE 0"
db2 CONNECT RESET

После сбора некоторого объем событий приступаем к извлечению этой информации.

Перед этим необходимо выполнить подготовку инструмента, который позволит преобразовать имеющиеся события в читабельный формат. Для этого:
1) просто для удобства создайте отдельный каталог, например, c:\deadlock
2) скопируйте в него 2 файла из основного каталога IBM DB2. Если ставили по-умолчанию, то эти файлы здесь:
"C:\Program Files\IBM\SQLLIB\samples\java\jdbc\db2evmonfmt.java"
"C:\Program Files\IBM\SQLLIB\samples\java\jdbc\DB2EvmonLocking.xsl"
3) открываем командную строку, заходим в каталог c:\deadlock\ и указываем системе путь к java:
set PATH=C:\Program Files\IBM\SQLLIB\java\jdk\bin;%PATH%
4) компилируем утилиту
javac db2evmonfmt.java

Инструмент готов, теперь непосредственно выполняем извлечение событий в XML-формат:

java db2evmonfmt -d <Имя базы> -ue emdata.tab_locking -type deadlock -fxml -u db2admin -p Password >deadlock.txt

где,
-type deadlock - фильтр на тип выгружаемых событий, можно не указывать, тогда система выгрузит и таймауты, и взаимоблокировки
-u db2admin -p Password - параметры авторизации, если работаете уже под db2admin, то можно не указывать.
deadlock.txt - путь к результирующему файлу

Об этих и остальных параметрах можно почитать в справке, просто вызвав java db2evmonfmt

После вызова указанной команды система сформирует файл deadlock.txt, в который будут помещены события в формате XML. Браузером сразу открывать не пытайтесь, т.к. в этом файле скомпонованы тексты XML cо служебными вставками, поэтому для полноценного просмотра этот файл нужно еще нарезать. А можно и так просматривать с помощью вот этой классной бесплатной программы - Notepad++.

Чтобы разбить общий файл на отдельный события и заменить служебные имена таблиц на привычные имена метаданных 1С можно воспользоваться вложенной обработкой.

Структура полученных XML-файла достаточно простая. 
Для таймаутов указывается по 1 запросу из участвующих сессий - 1 запрос из сессии, которая захватила и длительное время удерживает ресурс, и 1 запрос из сессии(-й), которая стала жертвой и завершила свое выполнение аварийно.
Для взаимоблокировок указывается похожая информация, но для сессий отображаются ВСЕ выполненные запросы с начала транзакции.

Пример типичной взаимоблокировки:

А вот дальше уже надо включать голову и искать участки кода, которые привели к этим ошибкам. В принципе, параллельно с фиксацией событий средствами DB, можно включить формирование Технологического журнала 1С, а затем сопоставить каким-то образом эту информацию, но, по утвержданию разработчиков ЦУПа, для выполнения этой операции пока недостаточно данных.

Если нужно о чем-то написать подробнее - укажите в комментариях, и я попробую это сделать.
Заранее признателен за замечания по существу.

Автор: © Алексей Бочков

(Информация с ресурса http://infostart.ru)