Анализ событий блокировки в DB2 для Linux, UNIX и Windows: Часть 2. Новые возможности для анализа событий тайм-аута блокировки в DB2 9.5

Познакомьтесь с новой функцией DB2 9.5, которая упрощает анализ событий тайм-аута блокировки

Для сбора информации о причине ошибки тайм-аута блокировки SQL0911N можно использовать комбинацию из инструмента db2pd и сценария db2cos, как описано в статье Анализ ситуаций ожидания блокировки в DB2 для Linux, UNIX и Windows" (developerWorks, сентябрь 2007 г.). В DB2® 9.5 возможности анализа событий тайм-аута блокировки значительно расширены, и такой анализ еще больше упростился. Настоящая статья знакомит читателей с новыми средствами анализа событий тайм-аута блокировки и с дополнительной информацией, которую можно собрать, чтобы определить причину ошибки этого типа.

Дирк Фехнер, Специалист по IT-службам, IBM Software Group

Дирк Фехнер (Dirk Fechner) работает специалистом по IT-службам в IBM Software Group. Имеет опыт администрирования и разработки приложений с использованием DB2 UDB на распределенных платформах. Он имеет пятилетний опыт работы с DB2 UDB и является сертифицированным администратором баз данных IBM и сертифицированным разработчиком приложений IBM. В настоящее время осуществляет поддержку администраторов, разработчиков и конечных пользователей в DaimlerChrysler в широком диапазоне тем, связанных с DB2: задачи администрирования, разработка приложений и определение проблем.



16.07.2010

Обзор анализа событий тайм-аута блокировки в DB2 9.1

Метод анализа событий тайм-аута блокировки с использованием инструмента db2pd и сценария db2cos состоит из следующих шагов.

  1. Специальный сценарий DB2 – db2cos – адаптируется для выполнения особого вызова db2pd всякий раз при запуске сценария db2cos. Вызов db2pd собирает информацию о блокировках, транзакциях, приложениях, а также о буфере операторов и сохраняет ее в текстовом файле для анализа.
  2. Чтобы выполнять сценарий db2cos (и, следовательно, содержащуюся в нем команду db2pd) автоматически при возникновении событий тайм-аута блокировки, такие события регистрируются с помощью команды db2pdcfg.
  3. В случае возникновения события тайм-аута блокировки администратор БД может изучить соответствующие выходные данные db2pd, собранные при автоматическом запуске сценария db2cos. Это позволяет администратору базы данных определить причину блокировки и принять меры во избежание повторения подобных событий в будущем.

Более подробное описание этих шагов с примером сценария приведено в уже упомянутой статье (см. раздел Ресурсы).

Хотя описанный метод дает много информации, которая значительно упрощала анализ состояний тайм-аута блокировки до выхода версии 9 DB2 для Linux, Unix и Windows, он все же имеет недостатки:

  • для использования этого метода требуется ручная адаптация сценария db2cos и регистрация событий тайм-аута блокировки с помощью вызова db2pdcfg. Оба шага не сложны, но могут стать препятствием для неопытных администраторов баз данных.
  • интерпретация выходных данных db2pd для определения приложений и SQL-операторов, участвующих в событии тайм-аута блокировки, не тривиальна и требует определенного опыта.
  • в тех случаях, когда ожидание блокировки вызвано транзакцией, состоящей из нескольких команд SQL, информации, собранной db2pd, может оказаться недостаточно для определения того, какой именно SQL-оператор несет ответственность за проблемную блокировку.

Новые средства составления отчетов о событиях тайм-аута блокировки в DB2 9.5

В состав средств составления отчетов о событиях тайм-аута блокировки в DB2 9.5 входит новая функция, которая превращает анализ событий тайм-аута блокировки в детскую игру. Для включения функции составления отчетов о событиях тайм-аута блокировки достаточно установить переменную реестра DB2 DB2_CAPTURE_LOCKTIMEOUT в состояние ON и перезапустить экземпляр DB2 (листинг 1).

Листинг 1. Включение функции составления отчетов о событиях тайм-аута блокировки в DB2 9.5
db2set DB2_CAPTURE_LOCKTIMEOUT=ON
db2stop
db2start

Вот и все. Когда переменная DB2_CAPTURE_LOCKTIMEOUT установлена в состояние ON, DB2 автоматически создает файл отчета для каждого события тайм-аута блокировки. Файл отчета записывается в каталог, на который указывает параметр DIAGPATH менеджера конфигурации базы данных (DBM CFG), и содержит информацию о дате и времени события тайм-аута блокировки, проблемной блокировке, процессе, вызвавшем блокировку, и владельце блокировки.

Значит, в DB2 9.5 сценарий db2cos больше не нужен? Нет, это не так. Сценарий db2cos в сочетании с инструментом db2pd имеет более широкую область применения. Это означает, что сочетание этих средств можно использовать для сбора информации не только о событиях тайм-аута блокировки, но и о любых событиях DB2, связанных с кодом SQL или внутренними кодами возврата DB2.

А теперь сосредоточимся на новой переменной реестра DB2 9.5 DB2_CAPTURE_LOCKTIMEOUT и проследим простой сценарий тайм-аута блокировки с помощью базы данных DB2 SAMPLE. Если база данных SAMPLE еще не создана, создайте ее, подав следующую команду (листинг 2).

Листинг 2. Создание базы данных SAMPLE
db2sampl

Ситуация тайм-аута блокировки возможна лишь в том случае, если параметр LOCKTIMEOUT конфигурации базы данных (DB CFG) установлен в значение, отличное от -1. Значение -1 означает, что приложение будет ожидать необходимую блокировку бесконечно. В большинстве случаев это нежелательное поведение, хотя -1 – значение для LOCKTIMEOUT по умолчанию. Для данного примера сценария предположим, что LOCKTIMEOUT изменили на 10 секунд – значение LOCKTIMEOUT устанавливается в секундах (листинг 3).

Листинг 3. Изменение значения LOCKTIMEOUT
db2 "UPDATE DB CFG FOR SAMPLE USING LOCKTIMEOUT 10"

Чтобы вызвать ошибку тайм-аута блокировки, установим первое соединение с базой данных и выполним какие-нибудь SQL-операторы, имитирующие реальную транзакцию с таблицей EMPLOYEE (листинг 4).

Листинг 4. Первая транзакция дает каждому сотруднику 2%-ную прибавку к окладу
db2 "CONNECT TO SAMPLE"
db2 +c "UPDATE EMPLOYEE SET SALARY = SALARY * 1.02"
db2 +c "SELECT LASTNAME, FIRSTNME, SALARY FROM EMPLOYEE ORDER BY LASTNAME ASC"

Пока транзакция состоит из команды UPDATE, которая дает каждому работнику 2%-ную прибавку к окладу. После этого новый оклад запрашивается оператором SELECT. Обратите внимание, что автоматическая фиксация транзакции отключена параметром +с для вызовов процессора командной строки (CLP) DB2. Оператор UPDATE приводит к исключительной (X) блокировке для каждой строки таблицы EMPLOYEE. Такие X-блокировки сохраняются до окончания транзакции оператором COMMIT или ROLLBACK.

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

Листинг 5. Вторая транзакция дает каждому менеджеру 10%-ный бонус (в зависимости от зарплаты)
db2 "CONNECT TO SAMPLE"
db2 +c "UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = 'MANAGER'"

Цель данной транзакции – предоставить каждому менеджеру 10%-й бонус в зависимости от его зарплаты. Поскольку все строки таблицы EMPLOYEE X-заблокированы первой транзакцией, второе приложение переходит в режим ожидания блокировки. Через 10 секунд (значение LOCKTIMEOUT) произойдет ожидаемое событие тайм-аута блокировки.

Пока ничего нового. Но так как переменной реестра DB2 DB2_CAPTURE_LOCKTIMEOUT присвоено значение ON, учет событий тайм-аута блокировки включен, и DB2 автоматически генерирует отчет о событиях тайм-аута блокировки в каталоге DIAGPATH. Обратите внимание, что в DB2 9.5 для Windows параметр DIAGPATH изменен по умолчанию. Если параметр DIAGPATH не установлен, DIAGPATH указывает на каталог DB2INSTPROF\DB2INSTANCE, где DB2INSTPROF – каталог экземпляра по умолчанию, а DB2INSTANCE – имя экземпляра DB2. Для определения пути, хранящегося в DB2INSTPROF, можно отобразить содержимое реестра DB2, выполнив команду db2set -all. Значением DB2INSTANCE будет DB2, если вы создали базу данных SAMPLE в экземпляре по умолчанию. Именем файла отчета будет db2locktimeout.dbpartition.agentid.timestamp, где dbpartition – всегда 0 для базы данных, состоящей из одного раздела.

Отчет о событиях тайм-аута блокировки, сгенерированный DB2, выглядит примерно так, как показано в листинге 6.

Листинг 6. Отчет о событиях тайм-аута блокировки
LOCK TIMEOUT REPORT

Date:  03/01/2008
Time:  07:34:31
Instance:  DB2
Database:  SAMPLE
Database Partition: 0
Lock Information: 

 Lock Name: 02000600040040010000000052
 Lock Type: Row
 Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000
Lock Requestor: 
 System Auth ID:  FECHNER 
 Application Handle: [0-38]
 Application ID:  *LOCAL.DB2.080103063343
 Application Name: db2bp.exe
 Requesting Agent ID: 5232
 Coordinator Agent ID: 5232
 Coordinator Partition: 0
 Lock timeout Value: 10000 milliseconds
 Lock mode requested: ..U
 Application Status: (SQLM_UOWEXEC)
 Current Operation: (SQLM_EXECUTE_IMMEDIATE)
 Lock Escalation:  No

 Context of Lock Request: 
 Identification:  UOW ID (1); Activity ID (1)
 Activity Information: 
 Package Schema:  (NULLID )
 Package Name:  (SQLC2G13NULLID )
 Package Version: ()
 Section Entry Number: 203
 SQL Type:  Dynamic
 Statement Type:  DML, Insert/Update/Delete
 Effective Isolation: Cursor Stability
 Statement Unicode Flag: No
 Statement:  UPDATE EMPLOYEE SET BONUS = SALARY * 0.1
    WHERE JOB = 'MANAGER'
Lock Owner (Representative): 
 System Auth ID:  FECHNER 
 Application Handle: [0-33]
 Application ID:  *LOCAL.DB2.080103063332
 Application Name: db2bp.exe
 Requesting Agent ID: 5488
 Coordinator Agent ID: 5488
 Coordinator Partition: 0
 Lock mode held:  ..X

 List of Active SQL Statements: Not available

 List of Inactive SQL Statements from current UOW: Not available

Отчет о событиях тайм-аута блокировки состоит из следующих четырех разделов.

  • Первый раздел содержит информацию о дате и времени события тайм-аута блокировки и о соответствующих экземпляре и базе данных.
  • Раздел Lock Information показывает причину тайм-аута блокировки. Кроме внутреннего имени блокировки отображается тип блокировки (блокировка на уровне строки или таблицы), а также сведения о таблице. Чтобы определить имя таблицы, нужно обратиться к представлению каталога SYSCAT.TABLES с указанием заданных идентификаторов табличной области и таблицы (листинг 7).
Листинг 7. Отображение идентификаторов табличной области/таблицы на имя таблицы
SELECT TABSCHEMA, TABNAME
FROM SYSCAT.TABLES
WHERE TBSPACEID = tbspaceid AND TABLEID = tableid
  • Приложения, находящиеся в состоянии тайм-аута блокировки, описаны в разделе Lock Requestor. К наиболее интересным записям в этих разделах относятся идентификатор подлинности, используемый для подключения к базе данных, имя приложения, запрашиваемый режим блокировки (и стала ли данная блокировка результатом эскалации блокировки), уровень изоляции оператора, который затребовал блокировку, и, не в последнюю очередь, собственно текст SQL-оператора.
  • Последний раздел Lock Owner (Representative) содержит приложение, в котором произошла проблемная блокировка. Как и для другого приложения, можно просмотреть информацию об идентификаторе подлинности, имени приложения и режиме блокировки. В некоторых случаях содержать (разделять) блокировку, которая блокирует запрашивающее приложение, могут несколько приложений. В этих случаях в отчете об ожидании блокировки показан только один из владельцев блокировки. Вот почему имя раздела имеет дополнение Representative.

В начале этой статьи упоминались три недостатка подхода к анализу событий тайм-аута блокировки с использованием db2cos и db2pd. Первым было неудобство использования. Подход db2cos и db2pd требует нескольких шагов для настройки мониторинга тайм-аута блокировки. Новый подход намного проще, достаточно всего лишь установить DB2_CAPTURE_LOCKTIMEOUT=ON – и все. Второй недостаток заключался в сложности, потому что требуется некоторый опыт для чтения распечатки db2pd и сопоставления различных разделов db2pd. При новом подходе DB2 генерирует файл отчета, содержащий всю необходимую информацию в одном месте. А как насчет последнего отмеченного недостатка: нехватки информации о SQL-операторах, вовлеченных в событие тайм-аута блокировки? Пока нам известен лишь SQL-оператор, заблокированный существующей блокировкой, но у нас нет никакой информации об операторе, который вызвал эту блокировку. Новый инструментарий отчетности о событиях тайм-аута блокировки приносит улучшение и в этом отношении. Посмотрим, как это работает.

Сбор информации об истории SQL-операторов

Чтобы получить информацию о SQL-операторах, выполненных приложением владельца блокировки, создадим монитор событий взаимоблокировки с параметром DETAILS HISTORY активизируем его. Например, подходящий монитор событий взаимоблокировки можно создать и активизировать следующим образом (листинг 8).

Листинг 8. Создание монитора событий взаимоблокировки с параметром DETAILS HISTORY
db2 "CREATE EVENT MONITOR evmondeadlock FOR DEADLOCKS WITH DETAILS HISTORY 
WRITE TO FILE 'path'"
db2 "SET EVENT MONITOR evmondeadlock STATE 1"

Вы можете спросить: "Зачем нужен монитор событий взаимоблокировки при мониторинге событий тайм-аута блокировки?" Ответ в том, что функция составления отчетов о событиях тайм-аута блокировки отчасти основывается на работе кода монитора событий взаимоблокировки. Когда монитор событий взаимоблокировки создается с параметром DETAILS HISTORY, DB2 отслеживает SQL-операторы, уже выполненные в ходе транзакции. В случае взаимоблокировки или тайм-аута блокировки эта информация может быть использована для представления истории SQL-операторов, которые могут быть вовлечены в событие взаимоблокировки или тайм-аута блокировки.

При активном мониторе событий взаимоблокировки еще раз рассмотрим описанный выше сценарий тайм-аута блокировки. На этот раз DB2 составляет отчет о событиях тайм-аута блокировки, как показано в листинге 9.

Листинг 9. Отчет о событиях тайм-аута блокировки с информацией об истории SQL-операторов
LOCK TIMEOUT REPORT

Date:  03/01/2008
Time:  15:10:13
Instance:  DB2
Database:  SAMPLE
Database Partition: 0
Lock Information: 

 Lock Name: 02000600040040010000000052
 Lock Type: Row
 Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000
Lock Requestor: 
 System Auth ID:  FECHNER 
 Application Handle: [0-202]
 Application ID:  *LOCAL.DB2.080103140934
 Application Name: db2bp.exe
 Requesting Agent ID: 2356
 Coordinator Agent ID: 2356
 Coordinator Partition: 0
 Lock timeout Value: 10000 milliseconds
 Lock mode requested: ..U
 Application Status: (SQLM_UOWEXEC)
 Current Operation: (SQLM_EXECUTE_IMMEDIATE)
 Lock Escalation:  No

 Context of Lock Request: 
 Identification:  UOW ID (1); Activity ID (1)
 Activity Information: 
 Package Schema:  (NULLID )
 Package Name:  (SQLC2G13NULLID )
 Package Version: ()
 Section Entry Number: 203
 SQL Type:  Dynamic
 Statement Type:  DML, Insert/Update/Delete
 Effective Isolation: Cursor Stability
 Statement Unicode Flag: No
 Statement:  UPDATE EMPLOYEE SET BONUS = SALARY * 0.1
    WHERE JOB = 'MANAGER'
Lock Owner (Representative): 
 System Auth ID:  FECHNER 
 Application Handle: [0-188]
 Application ID:  *LOCAL.DB2.080103140511
 Application Name: db2bp.exe
 Requesting Agent ID: 5488
 Coordinator Agent ID: 5488
 Coordinator Partition: 0
 Lock mode held:  ..X

 List of Active SQL Statements: Not available

 List of Inactive SQL Statements from current UOW: 

 Entry:   #1
 Identification:  UOW ID (6); Activity ID (2)
 Package Schema:  (NULLID )
 Package Name:  (SQLC2G13)
 Package Version: ()
 Section Entry Number: 201
 SQL Type:  Dynamic
 Statement Type:  DML, Select (blockable)
 Effective Isolation: Cursor Stability
 Statement Unicode Flag: No
 Statement:  SELECT LASTNAME, FIRSTNME, SALARY FROM EMPLOYEE
    ORDER BY LASTNAME ASC

 Entry:   #2
 Identification:  UOW ID (6); Activity ID (1)
 Package Schema:  (NULLID )
 Package Name:  (SQLC2G13)
 Package Version: ()
 Section Entry Number: 203
 SQL Type:  Dynamic
 Statement Type:  DML, Insert/Update/Delete
 Effective Isolation: Cursor Stability
 Statement Unicode Flag: No
 Statement:  UPDATE EMPLOYEE SET SALARY = SALARY * 1.02

Начало этого отчета о событиях тайм-аута блокировки идентично тому, что мы уже видели. Но на этот раз раздел Lock Owner содержит дополнительную полезную информацию. Под заголовком "List of Inactive SQL Statements from current UOW" (Список неактивных SQL-операторов из текущего UOW) перечислены все SQL-операторы, выполненные в ходе транзакции владельца блокировки до наступления события тайм-аута блокировки. По этому списку SQL-операторов можно определить, какой оператор (операторы) отвечает за проблемную блокировку. В данном случае это оператор UPDATE, повышающий заработную плату каждому сотруднику.

Отметим, что эта функция – одно из основных усовершенствований по сравнению с подходом db2cos и db2pd. При использовании db2cos с db2pd мы увидели бы лишь последний оператор, выполненный приложением владельца блокировки – в данном случае, запрос к таблице EMPLOYEE. Но так как проблемную X-блокировку вызывал не этот запрос, вы все равно не знали бы, какой оператор за нее отвечает. С помощью нового подхода – DB2_CAPTURE_LOCKTIMEOUT с монитором событий взаимоблокировки – мы получили историю всех SQL-операторов, выполненных в ходе транзакции владельца блокировки, что позволяет определить, что ответственным оператором был UPDATE.

Советы по использованию отчетов о событиях тайм-аута блокировки

Монитор событий взаимоблокировки с возможностями отображения истории операторов влияет на все приложения и повышает степень использования динамически распределяемой памяти монитора менеджером баз данных DB2. Так что этот монитор событий взаимоблокировки следует применять с осторожностью. Всегда начинайте только с установки DB2_CAPTURE_LOCKTIMEOUT=ON и активизируйте монитор событий взаимоблокировки с параметром DETAILS HISTORY только в случае необходимости.

Работая с функцией отчетности о событиях тайм-аута блокировки можно заметить, что число файлов отчетов о событиях тайм-аута блокировки в DIAGPATH непрерывно увеличивается. DB2 не удаляет эти файлы отчетов, так что вы, как администратор базы данных, несете ответственность за их удаление или перемещение, чтобы в файловой системе DIAGPATH всегда оставалось достаточно места.

Причину тайм-аута блокировки не всегда можно легко определить даже при наличии функциональности составления отчетов о событиях тайм-аута блокировки. Например, может быть случай, когда в событии тайм-аута блокировки участвуют внутренние блокировки статического SQL или DB2. В главе "Lock timeout reporting" документации DB2 9.5 содержится краткий перечень этих ограничений (см. раздел Ресурсы). Однако отчетность о событиях тайм-аута блокировки в DB2 9.5 – безусловно, та функциональность, которой ждали многие администраторы баз данных и которая значительно упростит анализ событий тайм-аута блокировки.

Заключение

Эта статья знакомит читателей с новыми возможностями по составлению отчетов о событиях тайм-аута блокировки DB2 9.5. Для демонстрации преимуществ этой новой функциональности DB2 9.5 она сопоставляется с подходом, описанным в статье Анализ ситуаций ожидания блокировки в DB2 для Linux, UNIX и Windows.

Ресурсы

Научиться

Получить продукты и технологии

  • Теперь DB2 можно использовать бесплатно. Загрузите DB2 Express-C, бесплатную версию DB2 Express Edition для сообщества разработчиков, которая предлагает все основные возможности работы с данными платной версии DB2 Express Edtion, что обеспечивает надежную основу для создания и размещения приложений.(EN)
  • Загрузите оценочные версии продуктов IBM и овладейте инструментами разработки приложений и связующим ПО для DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=500802
ArticleTitle=Анализ событий блокировки в DB2 для Linux, UNIX и Windows: Часть 2. Новые возможности для анализа событий тайм-аута блокировки в DB2 9.5
publish-date=07162010