Анализ ситуаций ожидания блокировок в DB2 для Linux, UNIX и Windows

Выявление причин проблем, , связанных с параллельным выполнением транзакций, при помощи инструмента db2pd

Если несколько пользователей DB2®одновременно подключаются к базе данных, ожидание блокировки может привести к значительному увеличению времени отклика. Ожидание блокировок по своей сущности является кратковременным событием, которое достаточно сложно зафиксировать. Тем не менее при возникновении ситуаций ожидания блокировки администратор баз данных обязан выявить причину. В этой статье на примере показано, как выполнить такую задачу при помощи инструментов db2pd и db2pdcfg для DB2 для Linux®, UNIX®и Windows®.

Дирк Фенчер, специалист по информационным технологиям, IBM Software Group

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



14.09.2007

Возможности db2pd для мониторинга блокировки

db2pd представляет собой утилиту для мониторинга и разрешения проблем, возникающих в процессе эксплуатации баз данных DB2. Это самостоятельная программа, входящая в комплект поставки механизма DB2, начиная с версии DB2 V8.2. Программа разработана в соответствии с функциями и принципом работы инструмента onstat пакета Informix. db2pd выполняется из командной строки, есть возможность использовать дополнительный интерактивный режим. Программа отличается высоким быстродействием, поскольку не использует блокировок или регистров-защелок и выполняется вне ресурсов ядра базы данных (то есть программа работает даже в ситуациях, когда ядро зависает). Большинство данных, предоставляемых программой db2pd, можно получить с помощью мониторинга мгновенных состояний, но выходные форматы db2pd и мониторинга мгновенных состояний значительно различаются. Это позволяет администратору баз данных выбрать более подходящий способ контроля. В этой статье описаны параметры программы db2pd для контроля блокировок. На сайте developerWorks имеется статья Сема Пуна (Sam Poon) (см. раздел Ресурсы) с более подробным описанием функций мониторинга программы db2pd.

На следующем рисунке показаны параметры db2pd для контроля блокировок:

Рисунок 1. Параметры db2pd для контроля блокировок
параметры блокировки db2pd
  • TranHdl: указатель дексриптора транзакции, позволяющий контролировать блокировки только для определенной транзакции;
  • showlocks: вспомогательный параметр для замены имени блокировки на более осмысленное. Для блокировки строк отображаются следующие сведения: идентификатор табличного пространства, идентификатор таблицы, идентификатор раздела, страница и слот. Идентификатор табличного пространства и таблицы можно легко сопоставить с соответствующим именем таблицы при помощи запроса к представлению каталога SYSCAT.TABLES:
    Листинг 1. Сопоставление идентификаторов табличного пространства и таблицы со схемой таблиц и именем таблицы
    SELECT TABSCHEMA, TABNAME
    FROM SYSCAT.TABLES
    WHERE TBSPACEID = tbspaceid AND TABLEID = tableid
  • wait: при помощи дополнительного параметра wait программа db2pd предоставляет сведения только о блокировках, для которых в данный момент имеются ожидающие транзакции, а также о блокировках, ответственных за возникновение ожидания. Этот параметр позволяет значительно упростить блокировки, так как выводит информацию только о блокировках, участвующих в ожидании;
  • Параметры db2pd database и file не связаны с контролем блокировки, но применяются практически ко всем вызовам db2pd. Параметр database служит для ограничения данных, возвращаемых db2pd, в соответствии с определенной базой данных. Параметр file позволяет определить файл для вывода данных db2pd.

Сценарий анализа ожидания блокировки

Далее приступим к анализу примера ожидания блокировки при помощи представленных параметров программы db2pd. Для этого создайте базу данных the DB2 SAMPLE:

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

Пользователь А выполняет транзакцию A для предоставления всем менеджерам бонуса 10% в зависимости от заработной платы менеджера:

Листинг 3. Операция обновления, выполняемая транзакцией A
UPDATE EMPLOYEE
SET BONUS = SALARY * 0.1
WHERE JOB = 'MANAGER'

Пока выполняется транзакция A (поскольку пользователь A не завершил транзакцию с помощью команды COMMIT или ROLLBACK), пользователь B выполняет транзакцию B для предоставления всем сотрудникам 2% надбавки к заработной плате:

Листинг 4. Операция обновления, выполняемая транзакцией B
UPDATE EMPLOYEE
SET SALARY = SALARY * 0.02

Так как транзакция B не завершается, для выявления причин проблемы пользователь B обращается к администратору базы данных. В свою очередь, администратор базы данных для выявления возможной ситуации ожидания блокировки запускает программу db2pd:

Листинг 5. Проверка ожидания блокировки
db2pd -db sample -locks wait showlocks

Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:33:05

Locks:
Address    TranHdl    Lockname                   Type       Mode Sts Owner      Dur 
0x050A0240 6          02000600050040010000000052 Row        ..X  W   2          1   
0x050A0DB0 2          02000600050040010000000052 Row        ..X  G   2          1   

HoldCount  Att  ReleaseFlg
0          0x00 0x40000000   TbspaceID 2  TableID 6  PartitionID 0 Page 320 Slot 5
0          0x00 0x40000000   TbspaceID 2  TableID 6  PartitionID 0 Page 320 Slot 5

db2pd сообщает об ожидании блокировки строки в таблице с идентификатором 6 в табличном пространстве с идентификатором 2. При помощи запроса SYSCAT.TABLES администратор баз данных определяет, что в таблице EMPLOYEE на самом деле возникла ситуация ожидания блокировки.

Листинг 6. Выявление таблицы с ожиданием блокировки
SELECT TABSCHEMA, TABNAME
FROM SYSCAT.TABLES
WHERE TBSPACEID = 2 AND TABLEID = 6

TABSCHEMA                               TABNAME
--------------------------------------------------------------------------------
FECHNER                                 EMPLOYEE

  1 record(s) selected.

В столбце состояния (Sts) отчета о выполнении команды db2pd -locks (Sts) для транзакции 2 (столбец TranHdl) указано значение "G". G соответствует "предоставлено" и означает, что блокировка строки относится к транзакции с дескриптором транзакций 2. Кроме того, столбец Mode указывает на то, что эта блокировка имеет тип X. Ожидающей транзакцией (состояние W = "ожидание" в столбце Sts) является транзакция с дескриптором 6. Эта транзакция запрашивает блокировку X для той же строки, что и транзакция 2. Это можно увидеть в столбце Owner (транзакция 2 показана как владелец блокировки) и сравнив значения столбца Lockname (одинаково для обоих элементов в разделе db2pd -locks).

Далее администратор баз данных сопоставляет дескрипторы транзакций с приложениями. Это выполняется с помощью параметра db2pd:-transactions:

Листинг 7. Сопоставление дескрипторов транзакций с приложениями
db2pd -db sample -transactions

Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:34:47

Transactions:
Address    AppHandl [nod-index] TranHdl    Locks      State   Tflag      Tflag2
0x05141880 30       [000-00030] 2          9          WRITE   0x00000000 0x00000
0x05144880 34       [000-00034] 6          5          WRITE   0x00000000 0x00000

Результат данного вызова db2pd показывает, что транзакция 2 (столбец TranHdl) выполняется приложением 30 (столбец AppHandl), а транзакция 6, соответственно, приложением 34. Обе транзакции находятся в процессе записи изменений в базу данных (столбец State = WRITE). Поэтому администратору баз данных ясно, что приложение 30 удерживает блокировку, которую ожидает приложение 34.

Для получения дополнительной информации о приложениях, участвующих в ожидании блокировки, программа db2pd вызывается с параметром -agents. Этот параметр служит для вывода информации об агентах, действующих от имени приложений. Обратите внимание, что -agents является параметром уровня экземпляра, то указание есть базы данных для него не является обязательным (если определена база данных, db2pd выводит предупреждение и игнорирует параметр базы данных).

Листинг 8. Получение информации о приложениях и соответствующих агентах
db2pd -agents

Database Partition 0 -- Active -- Up 3 days 08:35:42

Agents:
Current agents:      2
Idle agents:         0
Active coord agents: 2
Active agents total: 2
Pooled coord agents: 0Pooled
 agents total: 0

Address    AppHandl [nod-index] AgentTid   Priority   Type     State
0x04449BC0 34       [000-00034] 3392       0          Coord    Inst-Active
0x04449240 30       [000-00030] 2576       0          Coord    Inst-Active

ClientPid  Userid   ClientNm Rowsread   Rowswrtn   LkTmOt DBName
3916       USER_B   db2bp.ex 43         43         NotSet SAMPLE
2524       USER_A   db2bp.ex 153        14         NotSet SAMPLE

В выходных данных команды db2pd -agents администратор баз данных может определить идентификаторы пользователей, работающих с приложениями, — 30 и 34 (столбец Userid): приложение 30 выполняется пользователем USER_A, приложение 34 — пользователем USER_B. Такое сопоставление приложений и идентификаторов пользователей возможно только в том случае, если у каждого пользователя имеется идентификатор авторизации в базе данных. Как правило, это невозможно выполнить для приложений, выполняющихся на сервере приложений, поскольку приложения используют пул соединений, и соединения не персонифицируются.

Дополнительные сведения о приложениях можно получить с помощью параметра db2pd: -applications:

Листинг 9. Получение дополнительной информации о приложениях
db2pd -db sample -applications

Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:36:14

Applications:
Address    AppHandl [nod-index] NumAgents  CoorTid    Status                  
0x04AF8080 34       [000-00024] 1          3940       Lock-wait               
0x03841960 30       [000-00020] 1          2548       UOW-Waiting             

C-AnchID C-StmtUID  L-AnchID L-StmtUID  Appid
195      1          0        0          *LOCAL.DB2.061122195637
0        0          60       1          *LOCAL.DB2.061122195609

Данные в столбце Status подтверждают то, что уже известно администратору баз данных: приложение 34 находится в состоянии ожидания блокировки. Это уже известно, поэтому администратор баз данных обращается к столбцам C-AnchID/C-StmtUID и L-AnchID/L-StmtUID, соответственно. "C" означает "текущий", "L" - последний идентификатор привязки/уникальный идентификатор предложения. Эти идентификаторы позволяют определить последнее выполненное приложением SQL-предложение, а также предложение, выполняемое приложением в данный момент. Для этого программа db2pd вызывается с параметром -dynamic. Данный параметр показывает содержимое динамического кэша предложений:

Листинг 10. Проверка содержимого динамического кэша предложений
db2pd -db sample -dynamic

Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:37:39

Dynamic Cache:
Current Memory Used           187188
Total Heap Size               1271398
Cache Overflow Flag           0
Number of References          2
Number of Statement Inserts   3
Number of Statement Deletes   0
Number of Variation Inserts   2
Number of Statements          3

Dynamic SQL Statements:
Address    AnchID StmtUID    NumEnv     NumVar     NumRef     NumExe     
0x056CEBD0 60     1          1          1          1          1          
0x056CE850 180    1          0          0          0          0          
0x056CFEA0 195    1          1          1          1          1          

Text
UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = 'MANAGER'
SET CURRENT LOCALE LC_CTYPE = 'de_DE'
UPDATE EMPLOYEE SET SALARY = SALARY * 0.02

Dynamic SQL Environments:
Address    AnchID StmtUID    EnvID Iso QOpt Blk
0x056CECD0 60     1          1     CS  5    B
0x056D30A0 195    1          1     CS  5    B

Dynamic SQL Variations:
Address    AnchID StmtUID    EnvID VarID      NumRef     Typ 
0x056CEEB0 60     1          1     1          1          4   
0x056D3220 195    1          1     1          1          4   

Lockname
010000000100000001003C0056
01000000010000000100C30056

Сопоставить выходные данные для параметров -applications и -dynamic довольно просто:

Приложение 34 (в состоянии ожидания блокировки) в данный момент выполняет SQL-предложение, определяемое текущим идентификатором привязки 195 и текущим идентификатором предложения 1. В разделе Dynamic SQL Statements выходных данных db2pd -dynamic эти идентификаторы можно сопоставить со следующим SQL-предложением:

Листинг 11. SQL-предложение, выполняемое приложением 34
UPDATE EMPLOYEE SET SALARY = SALARY * 0.02

Последним SQL-предложением, выполненным приложением 30, которое удерживает блокировку, является предложение с идентификатором привязки 60 и последним идентификатором предложения 1. Эти идентификаторы можно сопоставить со следующим SQL-предложением:

Листинг 12. SQL-предложение, выполняемое приложением 30
UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = 'MANAGER'

Обратите внимание, что выходные данные команды db2pd -dynamic содержат другой интересный фрагмент информации, которую довольно-таки сложно выявить: Уровень локализации выполненного динамического SQL-предложения, представлен в столбце Iso раздела Dynamic SQL Environments (UR = Uncommitted Read, CS = Cursor Stability, RS = Read Stability, RR = Repeatable Read).

Подведем итог того, что администратор баз данных выявил относительно причины "зависания" приложения пользователя B:

  • "Зависание" вызвано исключительной блокировкой строки в таблице EMPLOYEE;
  • Транзакция, к которой относится блокировка, принадлежит к приложению, выполняемому пользователем A. Транзакция пользователя B ожидает снятия этой блокировки;
  • Двумя конфликтующими предложениями являются операторы UPDATE, применяемые к таблице EMPLOYEE.

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

В примере сценария программа db2pd выполняется последовательно несколько раз с различными параметрами. В реальности сценарий работы другой. Программа db2pd вызывается один раз сразу со всеми представленными выше параметрами:

Листинг 13. Вызов программы db2pd со всеми параметрами, необходимыми для анализа ожидания блокировки
db2pd -db sample -locks wait showlocks -transactions -agents -applications -dynamic
      -file db2pd.out -repeat 15 40

Выводимые данные включают информацию для каждого параметра в порядке их расположения в вызове db2pd. Обратите также внимание на два дополнительных параметра в конце вызова db2pd:

  • Параметр -file указывает, что вывод данных db2pd следует записать в файл. В нашем примере выходные данные записываются в файл db2pd.out;
  • Параметр -repeat указывает, что программа db2pd должна выполняться 40 раз через каждые 15 секунд (то есть в течение 10 минут с интервалом в 15 секунд). Выходные данные при каждом выполнении добавляются в конец файла, заданного параметром -file.

Параметры -file и -repeat полезно применять для мониторинга операций базы данных за определенный период времени. При анализе ожидания блокировок эти параметры помогают выявить ситуации блокировки, существующие только в короткие интервалы времени. Например, если значение параметра базы данных LOCKWAIT равно 20 секундам, то транзакция ожидающая блокировку, откатывается через 20 секунд ожидания. Для выявления такой ситуации необходимо задать интервал выполнения программы db2pd менее 20 секунд, например, 15, как в данном примере.

Выявление ситуаций истечения времени ожидания блокировки, возникающих случайно.

Иногда ожидание блокировки приводит к такому времени ожидания блокировки, что выполняется откат транзакций. Интервал времени, после которого для транзакции, ожидающей блокировку, будет выполнен откат, задается параметром конфигурации базы данных LOCKTIMEOUT. Одной из самых серьезных проблем, связанных с анализом ситуаций истечения времени ожидания блокировки, является факт неизвестности следующего возникновения подобной ситуации. Для выявления взаимоблокировок можно создать соответствующий монитор событий. Такой монитор событий взаимоблокировок выполняет запись при каждом возникновении ситуации взаимоблокировки. Аналогичного монитора событий для ситуаций истечения времени ожидания блокировки нет. Поэтому до выхода версии DB2 9® единственным способом выявления ситуаций истечения времени ожидания блокировки было постоянное выполнение программы db2pd или мониторинг мгновенных состояний (для непрерывного контроля с помощью db2pd можно использовать параметры -file и -repeat).

В DB2 9 включен новый механизм сбора данных мониторинга при сбоях базы данных или при возникновении определенных событий: сценарий db2cos. Для выявления событий истечения времени ожидания блокировки можно настроить базу данных для запуска сценария db2cos при каждом возникновении такого события. В сценарии db2cos можно вызывать программу db2pd с уже представленными параметрами. Рассмотрим пример использования сценария db2cos для выявления ситуаций истечения времени ожидания блокировки.

Предположим, что в этом сценарии администратор баз данных задает время ожидания блокировки базы данных 10 секунд:

Листинг 14. Обновление параметра ожидания блокировки
UPDATE DB CFG FOR SAMPLE USING LOCKTIMEOUT 10

Для запуска сценария db2cos при каждом возникновении ситуации истечения времени ожидания блокировки администратор баз данных вызывает программу db2pdcfg:

Листинг 15. Настройка сценария db2cos для вызова db2pdcfg
db2pdcfg -catch locktimeout count=1

Параметр -catch определяет сбой или событие, возникновение которого автоматически приводит к вызову сценария db2cos. Для событий истечения времени ожидания блокировки можно задать строку locktimeout. В качестве альтернативы можно задать соответствующий код ошибки SQL и код причины:

Листинг 16. Альтернативный вызов db2pdcfg для выявления ситуаций истечения времени ожидания блокировки
db2pdcfg -catch 911,68 count=1

Программа db2pdcfg, помимо определенных значений строк и SQL-кодов, допускает использование внутренних кодов ошибок DB2. Благодаря этому можно выявить большую часть ошибок и событий базы данных. События истечения времени ожидания блокировки являются одним из примеров использования db2pdcfg и db2cos.

Значение 1 для параметра count указывает, что сценарий db2cos должен выполняться только при событии истечения времени ожидания блокировки.

db2pdcfg подтверждает задание выявления ошибки при помощи вывода следующих данных:

Листинг 17. Подтверждение программы db2pdcfg настройки выявления ошибок
Error Catch #1
   Sqlcode:        0
   ReasonCode:     0
   ZRC:            -2146435004
   ECF:            0
   Component ID:   0
   LockName:       Not Set
   LockType:       Not Set
   Current Count:  0
   Max Count:      1
   Bitmap:         0x4A1
   Action:         Error code catch flag enabled
   Action:         Execute sqllib/db2cos callout script
   Action:         Produce stack trace in db2diag.log

Настройка выявления ошибок также выводится в файл отчета db2diag.log. Вместо открытия файла db2diag.log в текстовом редакторе файл db2diag.log можно отфильтровать с помощью db2diag (полезная программа для проверки содержимого файла db2diag.log):

Листинг 18. Подтверждение задания выявления ошибок в файле db2diag.log
db2diag -g funcname:=pdErrorCatch

2006-12-18-13.37.25.177000+060 I727480H285        LEVEL: Event
PID     : 4648                 TID  : 3948        PROC : db2syscs.exe
INSTANCE: DB2                  NODE : 000
FUNCTION: DB2 UDB, RAS/PD component, pdErrorCatch, probe:30
START   : Error catch set for ZRC -2146435004

ZRC -2146435004 — внутренний код ошибки DB2 для ситуации истечения времени ожидания блокировки. Проверить код можно при помощи следующего вызова db2diag:

Листинг 19. Проверка значения внутренних кодов DB2 при помощи db2diag
db2diag -rc -2146435004

При помощи db2pdcfg механизм базы данных настроен для вызова сценария db2cos в каждом случае возникновения ситуации истечения времени ожидания блокировки. Сценарий db2cos собирает всю информацию, необходимую для определения причины возникновения этой ситуации. Для этого администратор баз данных должен изменить сценарий db2cos для вызова программы db2pd с уже описанными параметрами. Сценарий db2cos можно найти в следующей вложенной папке:

  • Windows папка установки DB2\BIN\db2cos.bat, например, C:\Program Files\IBM\SQLLIB\BIN\db2cos.bat
  • UNIX/Linux: владелец экземпляра home/sqllib/bin/db2cos

По умолчанию сценарий db2cos.bat в ОС Windows® выглядит следующим образом:

Листинг 20. Содержимое файла db2cos.bat по умолчанию в ОС Windows
setlocal

:iterargs

if %0. == . goto iterdone
   if /i %0. == INSTANCE. set INSTANCE=%1
   if /i %0. == DATABASE. set DATABASE=%1
   if /i %0. == TIMESTAMP. set TIMESTAMP=%1
   if /i %0. == APPID. set APPID=%1
   if /i %0. == PID. set PID=%1
   if /i %0. == TID. set TID=%1
   if /i %0. == DBPART. set DBPART=%1
   if /i %0. == PROBE. set PROBE=%1
   if /i %0. == FUNCTION. set FUNCTION=%1
   if /i %0. == REASON. set REASON=%1
   if /i %0. == DESCRIPTION. set DESCRIPTION=%1
   if /i %0. == DiAGPATH. set DIAGPATH=%1
   shift
goto iterargs

:iterdone

if %DATABASE%. == . goto no_database
   db2pd -db %DATABASE% -inst >> %DIAGPATH%\db2cos%PID%%TID%.%DBPART%
   goto exit

:no_database
   db2pd -inst >> %DIAGPATH%\db2cos%PID%%TID%.%DBPART%

:exit

При возникновении события или ошибки на уровне базы данных сценарий db2cos по умолчанию вызывает программу db2pd с параметрами -db и -inst. Администратор баз данных заменяет соответствующую строку вызовом db2pd для сбора данных, необходимых для анализа ситуаций истечения времени ожидания блокировки:

Листинг 21. Изменение сценария db2cos для сбора данных для анализа ситуаций истечения времени ожидания блокировки
if %DATABASE%. == . goto no_database
   db2pd -db %DATABASE% -locks wait -transactions -agents -applications -dynamic
         >> %DIAGPATH%\db2cos%PID%%TID%.%DBPART%
   goto exit

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

Предположим, возникает такая же ситуация блокировки между пользователями A и B, как это было описано ранее. Но на этот раз задан параметр LOCKTIMEOUT, поэтому через 10 секунд выполняется откат транзакции пользователя B (LOCKTIMEOUT = 10). Пользователь B сообщает администратору баз данных об откате транзакции с сообщением SQL об ошибке -911 и кодом причины 68 (SQL code -911 / reason code 68 = locktimeout). В свою очередь администратор баз данных проверяет данные монитора, собранные автоматически сценарием db2cos.

Прежде всего администратор баз данных запускает программу db2diag с внутренним кодом ошибки истечения времени ожидания блокировки с целью определения точного времени возникновения этой ситуации:

Листинг 22. Определение момента возникновения события истечения времени ожидания блокировки в файле db2diag.log
db2diag -g data:=-2146435004

2006-12-18-14.27.24.656000+060 I6857H409          LEVEL: Event
PID     : 2968                 TID  : 2932        PROC : db2syscs.exe
INSTANCE: DB2                  NODE : 000         DB   : SAMPLE
APPHDL  : 0-21                 APPID: *LOCAL.DB2.061226132544
AUTHID  : FECHNER
FUNCTION: DB2 UDB, lock manager, sqlplnfd, probe:999
DATA #1 : <preformatted>
Caught rc -2146435004.  Dumping stack trace.

Запись в файле db2diag.log показывает, что истечение времени ожидания блокировки произошло 2006-12-18-14.27.24.656000. Поскольку сценарий db2cos создает файл с именем db2cos%PID%%TID%.%DBPART% в папке %DIAGPATH%, администратор баз данных может найти файл db2cos29682932.0 в папке диагностики экземпляра:

  • %DIAGPATH% = папка диагностики экземпляра = в ОС Windows по умолчанию это папка C:\Program Files\IBM\SQLLIB\DB2
  • %PID% = идентификатор процесса = 2968 (как показано в записи db2diag.log)
  • %TID% = идентификатор потока = 2932 (как показано в записи db2diag.log)
  • %DBPART% = раздел базы данных = 0 (в среде базы данных без разделов)

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

После выявления ситуации истечения времени ожидания блокировки администратор баз данных может отключить вызов сценария db2cos, выполнив программу db2pdcfg с параметром -catch clear:

Листинг 23. Удаление настройки выявления ошибок при помощи программы db2pdcfg
db2pdcfg -catch clear

All error catch flag settings cleared.

Заключение

В данной статье описан способ применения программы db2pd для выявления ситуаций ожидания блокировок. На примере сценария показано, как администратор баз данных может определить причину возникновения проблем при выполнении параллельных транзакций при помощи изучения выходных данных программы db2pd, запущенной с различными опциями. Начиная с версии DB2 9, для выявления событий истечения времени ожидания блокировки программу db2pd можно использовать вместе с новым сценарием db2cos. В статье было показано, как настроить автоматический вызов сценария db2cos в случае возникновения событий истечения времени ожидания блокировки. Также в статье описана программа db2diag - полезный инструмент для проверки содержимого файла db2diag.log.

Ресурсы

Научиться

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

  • Загрузите бесплатную ознакомительную версию DB2 Enterprise 9;(EN)
  • Теперь у вас есть возможность использовать 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=255526
ArticleTitle=Анализ ситуаций ожидания блокировок в DB2 для Linux, UNIX и Windows
publish-date=09142007