Выявление проблем DB2 при помощи команд и утилит AIX

Вы являетесь администратором базы данных IBM® DB2®, установленной в ОС AIX®? Узнайте, как можно использовать утилиты и команды AIX для администрирования и решения проблем, влияющих на работу базы данных DB2, таких как повышенная загрузка процессора, процессы-сироты, утечки памяти, зависания и прочее. В статье обсуждается процесс сбора данных, которые вы можете использовать для самостоятельного решения проблем или отправки в службу технической поддержки IBM.

Стивен Леветт, техническая поддержка DB2, IBM

Stephen LevettСтивен Леветт (Stephen Levett) работает в службе поддержки IBM Information Management, расположенной в Фарнборо. Он занимается технической поддержкой пользователей DB2 в Европе, на Ближнем Востоке и в Африке. Ранее он работал в SWG Services, занимался профессиональным обслуживанием и консультированием клиентов IBM.



Суита Гупта, специалист технической поддержки DB2, IBM

Суита Гупта (Suita Gupta) входит в состав группы поддержки информационного управления GTS (Information Management Support) IBM, Фарнборо. Она обеспечивает техническую поддержку DB2 для заказчиков в Великобритании и Ирландии. Ранее Суита работала техническим специалистом в инновационном центре IBM (Innovation Center IBM), Куала-Лумпур, помогая ISV-партнерам перейти на DB2 с других СУБД. Связаться с Суитой можно по электронной почте suitagup@uk.ibm.com.



25.07.2011

Введение

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

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

Данные, собранные при помощи этих команд, можно отправить в службу технической поддержки IBM при создании запроса в системе управления проблемами (problem management request, PMR) для ускорения решения инцидента. В конце каждого раздела статьи перечисляются документы, которые необходимо предоставить службе технической поддержки. Хотя эта статья содержит советы по решению проблем, которые можно использовать в качестве основы, за официальной консультацией вам следует связаться со службой поддержки IBM.


Мониторинг загрузки процессора

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

ps

Команда ps отображает текущее состояние активных процессов. Используйте команду ps -auxw | sort r +3 |head 10 для сортировки и вывода списка 10 процессов, наиболее активно использующих процессор. В листинге 1 показана выдача команды ps:

Листинг 1. Пример выдачи команды ps
root@bagpuss $ ps auxw|sort -r +3|head -10
USER      PID   %CPU  %MEM   SZ  RSS    TTY STAT  STIME  TIME   COMMAND
sharon   1658958  0.1  9.0 218016 214804 - A      Sep 13 38:16 db2agent (idle) 0
dpf      1036486  0.0  1.0 14376 14068   - A      Sep 17  3:10 db2hmon 0
sharon   1822932  0.0  1.0 12196 11608   - A      Sep 12  6:41 db2hmon 0
dpf      1011760  0.0  0.0 9264  9060    - A      Sep 17  3:03 db2hmon 3
dpf      1532116  0.0  0.0 9264  9020    - A      Sep 17  3:04 db2hmon 2
dpf       786672  0.0  0.0 9264  8984    - A      Sep 17  3:02 db2hmon 5
dpf      1077470  0.0  0.0 9264  8968    - A      Sep 17  3:03 db2hmon 1
dpf      1269798  0.0  0.0 9248  9044    - A      Sep 17  2:50 db2hmon 4
db2inst1  454756  0.0  0.0 9012  7120    - A      Jul 19  0:52 db2sysc 0

topas

При выполнении команды ps -ef вы видите использование процессора для отдельных процессов. Для получения дополнительных данных можно использовать команду topas. Подобно команде ps, команда topasзапрашивает избранную статистику об активности локальной системы. В листинге 2 приведен пример выдачи команды topas, указывающий на то, что процесс DB2 использует 33% загрузки процессора. Вы можете использовать выдачу topas для получения специальной информации, такой как идентификатор процесса, загрузка процессора и имя владельца, запустившего процесс. Обычно можно увидеть несколько процессов db2sysc, запущенных от имени одного владельца. В разных утилитах вывода информации о процессах процессы DB2 могут отображаться под разными названиями.

Листинг 2. Пример выдачи команды topas
Name          PID    CPU%  PgSp Owner
db2sysc      105428  33.3  11.7 udbtest
db2sysc       38994  14.0  11.9 udbtest
test          14480   1.4   0.0 root
db2sysc       36348   0.8   1.6 udbtest
db2sysc      116978   0.5   1.6 udbtest
db2sysc      120548   0.5   1.5 udbtest
sharon        30318   0.3   0.5 root
lrud           9030   0.3   0.0 root
db2sysc      130252   0.3   1.6 udbtest
db2sysc      130936   0.3   1.6 udbtest
topas        120598   0.3   3.0 udbtest
db2sysc       62248   0.2   1.6 udbtest
db2sysc       83970   0.2   1.6 udbtest
db2sysc      113870   0.2   1.7 root

vmstat

Команда vmstat может использоваться для мониторинга загрузки процессора. С ее помощью вы можете оценить загрузку процессора пользовательскими и системными процессами. В листинге 3 показан пример выдачи команды vmstat:

Листинг 3. Пример выдачи команды vmstat
kthr 	memory 	page 		faults		cpu 
----- ----------- ------------------------ ------------ ----------- 
r  b avm     fre   re pi po  fr sr  cy   in     sy   cs   us  sy id   wa 
32 3 1673185 44373 0  0  0    0 0    0  4009  60051 9744  62  38    0   0 
24 0 1673442 44296 0  0  0    0 0    0  4237  63775 9214  67  33    0   0 
30 3 1678417 39478 0  0  0    0 0    0  3955  70833 8457  69  31    0   0 
33 1 1677126 40816 0  0  0    0 0    0  4101  68745 8336  68  31    0   0 
28 0 1678606 39183 0  0  0    0 0    0  4525  75183 8708  63  37    0   0 
35 1 1676959 40793 0  0  0    0 0    0   4085 70195 9271  72  28    0   0 
23 0 1671318 46504 0  0  0    0 0    0  4780  68416 9360  64  36    0   0 
30 0 1677740 40178 0  0  0    0 0    0  4326  58747 9201  66  34    0   0 
30 1 1683402 34425 0  0  0    0 0    0  4419  76528 10042 60  40    0   0 
0 0 1684160 33808  0  0  0    0 0    0  4186  72187 9661  73  27    0   0

При чтении выдачи команды vmstat, показанной выше, можно игнорировать первую строку. Значимыми колонками являются: us, sy, id и wa.

  • id: время простоя.
  • wa: время ожидания ввода-вывода.
  • us: время выполнения кода не ядра (пользовательский уровень).
  • sy: время выполнения кода ядра (системный уровень).

В листинге 3 приведен пример загрузки процессора в среднем на 65% на пользовательском уровне и на 35% на системном уровне. Значения Pi и Po равны 0, что говорит об отсутствии проблем со страничной памятью. Колонка wa указывает на то, что, по всей видимости, нет никаких проблем ввода-вывода.

В листинге 4 приведен пример необычно высокого значения параметра wa (ожидание ввода-вывода), указывающего на то, что подсистема ввода-вывода является узким местом и приводит к нерациональному использованию процессора. Вы можете проверить выдачу команды errpt -a на наличие каких-либо проблем с носителями информации или подсистемой ввода-вывода.

Листинг 4. Пример выдачи команды vmstat с ошибками ввода-вывода
kthr memory page faults cpu 
----- ----------- ------------------------ ------------ ----------- 
r b  avm    fre re pi po  fr      sr     cy   in    sy   cs   us  sy id wa 
2 8  495803 3344 0 0   0   929    1689    0   998  6066  1832 4   3  76 16 
0 30 495807 3340 0 0   0   0        0     0   1093 4697  1326 0   2  0  98 
0 30 495807 3340 0 0   0   0        0     0   1055 2291  1289 0   1  0  99 
0 30 495807 3676 0 2   0   376    656     0   1128 6803  2210 1   2  0  97 
0 29 495807 3292 0 1   3   2266   3219    0   1921 8089  2528 14  4  0  82 
1 29 495810 3226 0 1   0   5427   7572    0   3175 16788 4257 37  11 0  52 
4 24 495810 3247 0 3   0   6830   10018   0   2483 10691 2498 40  7  0  53 
4 25 495810 3247 0 0   0   3969   6752    0   1900 14037 1960 33  5  1  61 
2 26 495810 3262 0 2   0   5558   9587    0   2162 10629 2695 50  8  0  42 
3 22 495810 3245 0 1   0   4084   7547    0   1894 10866 1970 53  17 0  30

iostat

Команда iostat поможет вам быстро выяснить, испытывает ли ваша система проблемы с производительностью подсистемы ввода-вывода. В листинге 5 приведен пример выдачи команды iostat:

Листинг 5. Пример выдачи команды iostat
System configuration: lcpu=4 disk=331 
tty: 	tin 	tout    avg-cpu:   % user    % sys    % idle    % iowait 
0.0 	724.0                17.9     12.3      0.0       69.7

Disks: 		% tm_act   Kbps 		tps        Kb_read  Kb_wrtn 
hdisk119 		100.0      5159.2 		394.4       1560    24236 
hdisk115 		100.0      5129.6 		393.0       1656    23992 
hdiskpower26   	100.0      10288.8		790.8       3216    48228

%tm_act: процент времени, которое был активен физический диск, относительно общего количества времени запросов к диску. Kbps: среднее количество информации, записанной на диск в килобайтах. tps: количество обращений в секунду к физическому диску. Kb_read: общее количество данных (в килобайтах) с начала измерения, считанных с физических томов. Kb_wrtn: общее количество данных (в килобайтах) с начала измерения, записанных на физические тома.

Для проверки в случае конфликта рассматриваемых ресурсов следует обратить внимание на значение параметра %tm_act из вышеприведенной выдачи. Увеличение этого значения, особенно более чем на 40%, означает, что этот процесс для завершения ожидает операции ввода-вывода, и вы имеете дело с проблемой подсистемы ввода-вывода. Проверьте, у какого из жестких дисков выше процент активности, и если DB2 использует этот диск, вы получите пищу для размышлений относительно того, как связаны эти два фактора.

Необходимая информация

Для обращения в службу технической поддержки вы должны собрать следующую информацию:

  1. db2support.zip
  2. truss -f -o truss.out -p <pid> для процессов с наибольшей загрузкой процессора;
  3. db2pd -stack <pid> для процессов с наибольшей загрузкой процессора.

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


Решение проблем, связанных с процессами-сиротами

В некоторых случаях, даже после выполнения команды db2stop, вы видите (при помощи команды ps -ef | grep DB2), что отдельные процессы DB2, такие как db2fmp, продолжают работать и расходовать системные ресурсы. В случае нештатного завершения работы, рекомендуется выполнить команду ipclean после остановки программы. Выполнение команды db2stop должно по определению вызвать завершение работы всех процессов, связанных с DB2, тем не менее, некорректное завершение работы приложения, использующего эти процессы, может привести к образованию процессов-сирот.

Процессами-сиротами DB2 являются процессы, не прикрепленные или не связанные ни с одним из процессов DB2. Некорректное завершение приложения включает в себя: выключение при помощи Ctrl+C, закрытие сеанса KSH или сброс при помощи параметра -9.

Единственный способ убедиться в том, что процесс является сиротой, это попытаться получить и сопоставить идентификаторы процессов (process ID, PID) из выдачи команды ps -ef и колонки Coordinator выдачи команды db2 list applications show detail. Если PID отсутствует в выдаче db2 list apps output, значит это процесс-сирота. Например, выполнив команду db2 list applications show detail, вы получите следующую выдачу:

Листинг 6. Пример выдачи list applications
CONNECT Auth Id Application Name Appl. 
Application Id Seq# Number of Coordinating DB 
Coordinator Status Status Change Time DB Name DB Path 
Handle Agents partition number pid/thread 

JDE test.exe 2079 AC1C5C38.G80D.011F44162421 0001 1 0 2068646
UOW Waiting 04/04/2006 09:25:17.036230 PTPROD 
/db2pd/otprod/ptprod/otprod/NODE0000/SQL00001/ 

--NOTICE PID 2068646. Это PID на локальном сервере.

Часть выдачи команды ps -ef сервера: 

ps -ef |grep 2068646 
otprod 2068646 483566 0 09:06:28 - 0:59 db2agent (PTPROD) 0

Из этой выдачи следует, что процесс с PID 2068646 не является сиротой и прикреплен к процессу DB2.

Чтобы избежать образования процессов-сирот, вы можете сделать следующее: выполните нормальный, чистый выход на стороне клиента, чтобы DB2 получила соответствующее уведомление и могла очистить соответствующие ресурсы на сервере. Измените значение параметра TCPKEEPIDLE на время меньшее, чем по умолчанию, и настройте значения параметров DB2CHECKCLIENTINTERVAL и KEEPALIVE.

Необходимая информация

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

  1. Выдачу команды ps -ef| grep db2;
  2. db2support.zip с параметром -c
  3. 3. Стек вызовов процессов, собранный при помощи команды dbx, db2pd -stack или kill -36 <pid>. Команда dbx запускает популярный отладчик, используемый в ОС Solaris и AIX. Выдача dbx содержит много полезной информации и может выглядеть следующим образом:
    Листинг 7. Команда dbx
    dbx -a <PID>
    At the dbx prompt type 
    th 		--- Displays all threads for the process 
    th info 	--- Displays additional info about the threads 
    where 		--- Get stack trace for thread 1 
    th current 1  --- Makes t1 current 
    where 		--- Displays stack for thread 1 
    th current 2  --- Makes thread 2 current 
    where 		--- Displays stack for thread 2. 
    ... continue for all threads of the process 
    detach - 	--- Detach from process
    dbx -a <PID of orphan process>

Выявление повреждения базы данных

Если пользователи жалуются на то, что не могут получить доступ к отдельным объектам базы данных или не могут подключиться к ее определенным разделам, значит, существует вероятность повреждения. В этом разделе рассматриваются некоторые из ошибок, записываемых DB2, а также способы отделить их от ошибок операционной системы (ОС), являющихся следствием или причиной повреждения базы данных DB2. Вы можете столкнуться с ошибками, подобными тем, что приведены в листинге 8, являющемся частью журнала db2diag.log.

Листинг 8. Сообщения об ошибках
RETCODE : ZRC=0x87040001=-2029780991=SQLD_BADPAGE "Bad Data Page" 
DIA8500C A data file error has occurred, record id is "". 

Or
RETCODE: ZRC=0x86020019=-2046689255=SQLB_CSUM "Bad Page, Checksum Error"   
DIA8426C A invalid page checksum was found for page "". 

Or
2007-07-09-11.29.45.696176+120 I16992C16377 LEVEL: Severe 
PID : 68098 TID : 1 PROC : db2agent (sample) 
INSTANCE: instest NODE : 000 DB : sample
APPHDL : 0-635 APPID: *LOCAL.instest.070709082609 
FUNCTION: DB2 UDB, buffer pool services, sqlbcres, probe:20 
MESSAGE : Important: CBIT Error 
DATA #1 : Hexdump, 4096 bytes

Если DB2 сталкивается с каким-то видом повреждений при попытке обратиться к данным в контейнере, и DB2 не может получить доступ к данным, регистрируются подобные ошибки, а база данных может быть помечена как сбойная. Вы можете сузить круг возможных причин повреждения. В журнале db2diag.log ищите сообщения похожие на следующие:

Листинг 9. Сообщения об ошибках с подробной информацией об объектах базы данных
2006-04-15-03.15.37.271601-360 I235258C487 LEVEL: Error 
PID : 152482 TID : 1 PROC : db2reorg (SAMPLE) 0 
INSTANCE: instest NODE : 000 DB : SAMPLE 
APPHDL : 0-68 APPID: *LOCAL.SAMPLE.060415091532 
FUNCTION: DB2 UDB, buffer pool services, sqlbrdpg, probe:1146 
DATA #1 : String, 124 bytes 
Obj={pool:5;obj:517;type:0} State=x27 Parent={5;517}, EM=55456, 
PP0=55488 Page=55520 Cont=0 Offset=55552 BlkSize=12 
BadPage

Сообщения об ошибках, приведенные выше, обозначают повреждение в табличной области 5 и идентификаторе таблицы 517. Чтобы проверить на какую таблицу они ссылаются, выполните следующий SQL-запрос:

Листинг 10: Запрос для поиска поврежденной таблицы
db2 "select tabname, tbspace from syscat.tables where tbspaceid = 5 and tableid = 517"

На уровне ОС наиболее распространенными причинами повреждения являются либо аппаратные проблемы, либо ошибка файловой системы. Например, если вы видите в журнале db2diag.log что база данных помечена как поврежденная с ошибкой ECORRUPT (89), как показано ниже:

Листинг 11. Пример ошибок связанных с повреждениями файловой системы
2007-05-22-13.45.52.268785-240 E20501C453 LEVEL: Error (OS) 
PID : 1646696 TID : 1 PROC : db2agent (SAMPLE) 0 
INSTANCE: tprod NODE : 000 DB : SAMPLE 
APPHDL : 0-32 APPID: GA260B45.M505.012BC2174219 
FUNCTION: DB2 UDB, oper system services, sqloopenp, probe:80 
CALLED : OS, -, unspecified_system_function 
OSERR : ECORRUPT (89) "Invalid file system control data detected."

Вы можете проверить следующие параметры:

  1. Обратитесь к выдаче команды и ищите сообщения, связанные с аппаратной подсистемой ввода-вывода или дисковой подсистемой. В листинге 12 приведен пример выдачи errpt -a, показывающей повреждение файловой системы.
    Листинг 12. Пример выдачи команды errpt
    LABEL: J2_FSCK_REQUIRED 
    IDENTIFIER: B6DB68E0 
    Date/Time: Thu Jun 7 20:59:49 DFT 2007 
    Sequence Number: 139206 
    Machine Id: 000BA256D600 
    Node Id: cmab 
    Class: O 
    Type: INFO 
    Resource Name: SYSJ2 
    Description 
    FILE SYSTEM RECOVERY REQUIRED 
    Probable Causes 
    INVALID FILE SYSTEM CONTROL DATA DETECTED 
    Recommended Actions 
    PERFORM FULL FILE SYSTEM RECOVERY USING FSCK UTILITY 
    OBTAIN DUMP 
    CHECK ERROR LOG FOR ADDITIONAL RELATED ENTRIES 
    Detail Data 
    ERROR CODE 
    0000 0005 
    JFS2 MAJOR/MINOR DEVICE NUMBER 
    0032 0004 
    CALLER 
    0028 8EC8 
    CALLER 
    0025 D5E4 
    CALLER 
    002B 4AC8
  2. Выполните команду fsck для файловой системы, содержащей контейнер, чтобы убедиться в том, что она работоспособна. Команда fsck в интерактивном режиме проверяет и исправляет все сбои файловой системы. В Информационом центре pSeries и AIX мы можем найти следующие примеры использования fsck.
    Листинг 13. Команда fsck
    Для проверки всех файловых систем по умолчанию введите:
    fsck
    При этом fsck запрашивает подтверждение 
    
    перед внесением любых изменений в файловую систему.
    
    Для проверки файловой системы /dev/hd1, введите:
    fsck /dev/hd1
    При этом будет проверена отмонтированная файловая система, 
    расположенная на устройстве /dev/hd1.

Необходимая информация

Для обращения в службу технической поддержки вы должны собрать следующую информацию:

  1. errpt -a
  2. db2support.zip
  3. отчет fsck

Отладка утечек памяти

Важно различать, насколько это возможно, утечки памяти и общесистемное падение производительности из-за возросших требований к памяти. Таким образом, для начала будет уместно убедиться, что в системе не изменилось ничего, что могло бы привести к повышенному расходу памяти. Остаток этой части посвящен методам, используемым в ОС AIX для обнаружения, отслеживания и устранения этих утечек. В статье не обсуждаются подробно утилиты и приемы работы в DB2, хотя они упоминаются при необходимости.

Что такое утечка памяти?

Википедия описывает утечку памяти, как

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

Точнее говоря, это ошибка в коде, при которой вызовы выделения памяти malloc() не сопровождаются соответствующими вызовами очистки памяти free(). Отсутствие соответствующих системных вызовов free() приводит к образованию неочищенных блоков. Как правило, это медленный процесс, который может продолжаться дни или недели, особенно если процесс остается активным, как часто это и случается. Некоторые утечки даже невозможно обнаружить, например, если приложение было завершено и его процессы были удалены.

В листинге 14приведен отрывок кода на языке C, демонстрирующий утечку памяти. В этом примере память была доступна и назначена при помощи переменной 's', но не была сохранена. После возврата этой функции, указатель удаляется и выделенная память не очищается, а становиться недоступной.

Листинг 14. Пример кода на языке C
#include <stdio.h>
#include <stdlib.h>
void f(void)
{
     void* s;
     s = malloc(50); /* выделение памяти */
     return;         /* утечка памяти – см. комментарий ниже */ 
     /* 
      * Память была доступна и предназначена для s, но не сохранена.
      * После возврата этой функции указатель был удален, 
      * и выделенная память стала недоступной.
      *
      * Для «исправления» этого кода, либо добавьте где-нибудь внутри 
      * функции f() "free(s)", либо необходимо возвратить s 
      * из функции f(), а вызывающий функцию f() должен
      * выполнить free().
      */
}
int main(void)
{
     /* это бесконечный цикл, вызывающий функцию, приведенную выше */
     while (1) f(); /* Из-за утечек памяти malloc рано или поздно 
	 				возвратит нулевое значение */
     return 0;
}

Как обнаруживать, отслеживать и устранять утечки памяти

Для начала, если вы подозреваете наличие утечки памяти в работе DB2, вам необходимо связаться с корпорацией IBM. Но как вам понять, что вы столкнулись именно с утечкой? В этом разделе обсуждаются некоторые способы диагностики.

Первый способ заключается в использовании утилиты ps. Утилита ps используется для простого и быстрого выявления утечек. Ниже приведен пример, как отдельный процесс занимает все больше места.

Листинг 15. Пример выдачи 'ps aux' с увеличением размера процесса
ps aux:

1st iteration:      
USER         PID %CPU %MEM   SZ  RSS    TTY STAT    STIME  TIME
COMMAND                                                 
db2inst1  225284  0.2  0.0 19468 18280     - A    11:26:06 10:34    
db2logmgr                                                       
                                                                     
2nd iteration:                                                       
db2inst1  225284  0.1  0.0 19696 18512      - A    11:26:06 10:34    
db2logmgr                                                       
                                                                     
3rd iteration:                                                       
db2inst1  225284  0.1  0.0 19908 18724      - A    11:26:06 10:36    
db2logmgr                                                       
                                                                     
4th iteration:                                                       
db2inst1  225284  0.1  0.0 20116 18932      - A    11:26:06 10:36    
db2logmgr                                                      
                                                                     
5th iteration:                                                       
db2inst1  225284  0.1  0.0 20312 19128      - A    11:26:06 10:37    
db2logmgr                                                    
                                                                     
ps -kelf:                                                            
                                                                     
1st iteration:        
F S      UID     PID    PPID   C PRI NI ADDR    SZ    WCHAN    
STIME    TTY  TIME CMD                                               
40001 A db2inst1  225284  254158   0  60 20 580e59400 18466         
11:26:06      - 10:34 db2logmgr (***) 0                           
                                                                     
2nd iteration:                                                       
40001 A db2inst1  225284  254158   1  60 20 580e59400 18696          
11:26:06      - 10:34 db2logmgr (***) 0                           
                                                                     
3rd iteration:                                                       
40001 A db2inst1  225284  254158   0  60 20 580e59400 18900          
11:26:06      - 10:36 db2logmgr (***) 0                           
                                                                     
4th iteration:                                                       
40001 A db2inst1  225284  254158   0  60 20 580e59400 20106          
11:26:06      - 10:36 db2logmgr (***) 0                           
                                                                     
5th iteration:                                                       
40001 A db2inst1  225284  254158   0  60 20 580e59400 20312          
11:26:06      - 10:37 db2logmgr (***) 0

При выявлении потенциальной утечки памяти в выдаче ps aux ключевыми являются значения параметров SZ и RSS. Как вы могли заметить, значения, выделенные полужирным шрифтом, увеличиваются. Этого недостаточно, однако необходимо для определения причины и последующей отладки. Пожалуйста, вновь обратитесь с этой проблемой в службу технической поддержки, которая по всей вероятности предпримет следующие действия для решения проблемы.

Отладка при помощи procmap и gencore

От имени суперпользователя root:

  1. procmap <db2logmgr pid>> procmap.1
  2. ps aux > ps_aux.1
  3. ps -kelf > ps_kelf.1
  4. gencore <db2logmgr pid> <file>

и затем через некоторое время:

  1. procmap <db2logmgr pid> > procmap.2
  2. ps aux > ps_aux.2
  3. ps -kelf > ps_kelf.2
  4. gencore <db2logmgr pid> < file>

Затем повторите эти действия еще 2 или 3 раза. Обратите внимание, что в 64-разрядной версии AIX gencore создает очень большие файлы. Независимо от размера слова должен быть включен параметр fullcore. Для проверки правильности настроек ОС можно использовать следующие команды:

Листинг 16. Команда lsattr
lsattr -El sys0| grep -i core
fullcore     true                  Enable full CORE dump                             True

Необходимо правильно настроить ограничения для соответствующего владельца. Вам может понадобиться включить MALLOC_DEBUG и экспортировать его в оболочку DB2. Ниже приведен соответствующий пример.

Для запуска следующей загрузки DB2 в режиме отладки памяти выполните команду: db2set DB2MEMDBG=FFDC . > Для запуска следующей загрузки DB2 в режиме отладки malloc выполните команду: export MALLOCDEBUG log:extended stack_depth 12. Также добавьте MALLOCDEBUG в переменную регистра DB2 DB2ENVLIST: > db2set DB2ENVLIST MALLOCDEBUG. Затем остановите и перезапустите DB2.

Сразу после создания файлов core, вы можете использовать snapcore для обработки файлов core и библиотек в файле pax. Ниже приведен пример использования snapcore:

Листинг 17. Пример использования snapcore
snapcore /home/db2inst1/sqllib/db2dump/c123456/core
/home/db2inst1/sqllib/adm/db2sysc

По умолчанию эта команда создает файл с расширением *.pax в каталоге /tmp/snapcore. Файлы core бесполезны без соответствующих исполняемых файлов, в данном случае db2sysc, а не db2logmgr, рост которых наблюдался потому, что это процесс, а не исполняемый файл. Затем служба поддержки DB2 может использовать файлы core для поиска выделений памяти DB2 malloc() без соответствующих вызовов free().


Восстановление после зависаний

Что такое зависание

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

Для начала надо выяснить, является ли это зависанием или резким падением производительности. Затем вам необходимо выяснить причину или круг возможных причин этого. Несколько простых вопросов вам немного помогут:

  • Почему вы считаете, что это зависание?
  • Зависают все команды DB2?
  • Насколько долго выполняется команда?
  • Сколько длиться обычное выполнение команды?

Затем определите круг возможных причин:

  • Зависает ли ОС? Если ответ утвердительный, вам следует обратиться в службу поддержки AIX.
  • Работает ли оператор ?db2 connect?
  • Работают ли SQL-запросы через существующие подключения?
  • В случае использования среды DPF, можно ли работать с другими разделами?
  • Можно ли работать с другими базами данных?

Восстановление

Пожалуйста, не забудьте собрать стеки до начала восстановления. Сразу после получения стеков, единственный оставшийся вариант это выполнить команду db2_kill. Затем проверьте все процессы, общую память IPC, очереди сообщений и семафоры, оставшиеся после уничтожения процесса. Возможно, вам придется вручную удалить все найденные объекты. Дополнительно можно попытаться выполнить команду ipclean для удаления этих ресурсов. Если связи IPC не сбрасываются после выполнения команд ipclean и ipcrm и после удаления процессов при помощи команды kill -9, значит, по всей вероятности, процессы зависли и вам необходимо обратиться в службу поддержки AIX.

По завершении, выполните команду db2start, а затем restart db.

Необходимая информация

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

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

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

Плохой способ решения проблемы и сбора данных:

  • инцидент;
  • обнаружение;
  • восстановление;
  • включение FFDC (требует перезагрузки);
  • перезагрузка (сбой №2) запланированный сбой, надеемся, что проблема не повторится еще раньше;
  • инцидент (сбой №3);
  • обнаружение;
  • сбор данных;
  • восстановление;
  • диагностика (время идет!).

Способ получше:

  • инцидент (сбой №1);
  • обнаружение;
  • восстановление;
  • включение FFDC;
  • инцидент (сбой №2);
  • обнаружение;
  • сбор данных;
  • восстановление;
  • диагностика (время идет!).

Правильный способ решения проблемы и сбора данных:

  • инцидент (сбой №1);
  • обнаружение;
  • сбор данных;
  • восстановление;
  • диагностика (время идет!).

Трассировка стека

Трассировка стека – это снимок вызовов функции в определенный момент времени. Несколько трассировок стека с разницей в несколько минут создают представление о работе процесса. Существует множество способов собрать трассировки стеков, ниже приведены наиболее надежные, по моему мнению. Procstack <pid зависшего процесса> >> pid.pstack.out Это утилита AIX, которая просто выгружает стек в файл. Команда, приведенная в этом примере, дописывает файл, поскольку мы не хотим, чтобы при последующих запусках файл был перезаписан. Kill -36 <pid> Эта команда не уничтожает процесс, а отправляет сигнал выгрузить его стек. Фактически эта команда создает форматированный файл в области DIAGPATH DB2. Поскольку kill выдает больше информации, чем procstack и использует внутренние механизмы работы, этот способ, как правило, является предпочтительным, особенно если присутствуют сотни процессов, которые могут быть причиной проблемы. В этой статье обсуждаются системные утилиты AIX для отладки DB2. Однако обсуждение способов диагностики проблем зависаний было бы неполным без упоминания о db2pd. Для получения трассировки стеков можно использовать следующие заклинания:

db2pd -stacks (это создает выгрузку трассировки стека для всех процессов)

db2pd -stack <pid> (это создает выгрузку трассировки стека для указанного процесса) Файл выгрузки создается в области DIAGPATH DB2. В листинге 18 приведен пример использования db2pd.

Листинг 18. Использование db2pd -stacks
1. -stacks
$ db2pd -stacks
Attempting to dump all stack traces for instance.
See current DIAGPATH for trapfiles.
2. -stack <pid>
$ db2pd -stack 1454326
Attempting to dump stack trace for pid 1454326.
See current DIAGPATH for trapfile.

Служба поддержки DB2 попросит вас упаковать и сжать область DIAGPATH. Как правило, они попросят вас выполнить команду db2support, которая сделает это за вас, с использованием корректных параметров. Однако, если для создания трассировки вы использовали procstack, вам понадобиться вручную указать файлы выдач.

Truss

Можно использовать команду truss, но она не так эффективна, как выгрузка стека, она пригодна лишь для диагностики, если процесс попал в цикл и не может продолжать работу. Если процесс завис, только выгрузка стека может помочь понять, что произошло.

ps

Будет не лишним собрать листинги ps для всех разделов, по возможности, до и после выгрузок стека. Если вы собираете данные вручную, псевдокод будет выглядеть следующим образом:

Листинг19. procstack
Procstack Pid or PIDs  >> procstack.out
Ps eafl >>  pseafl.out
Ps aux >>  psaux.out
Sleep 120
Повторите, по крайней мере, 3 раза.

Или:

Kill -36 <pid> or PIDs
Ps eafl  >>  pseafl.out
Ps aux  >>  psaux.out
Sleep 120
Повторите, по крайней мере, 3 раза.

NB: Служба поддержки IBM DB2 может предоставить скрипт для сбора данных, 
автоматизирующий эти операции.

Диагностика не отвечающих приложений

Иногда приложения просто не реагируют на внешние раздражители, и вы гадаете, что произошло и как их разбудить. Если приложение не реагирует после выполнения команды force application, можете больше не искать выход. Для начала, важно понимать, что команда force не гарантирует принудительного обновления. Это просто оболочка для команд сброса ОС.

Не вдаваясь в подробности архитектуры DB2, отметим, что существуют ситуации, в которых использовать операции принудительного сброса опасно. Например, db2agent имеет более высокий приоритет, чем команда force. Следовательно, в этом случае force не работает, что является технической особенностью.

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

Восстановление

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

Необходимая информация

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

  1. Повторяющиеся трассировки стека не отвечающих процессов db2agent или DB2.
  2. Листинги ps и других элементов, таких как db2level, dbm cfg, db cfg, db2diag.log, а также, по возможности, снимки приложений.

Заключение

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

Ресурсы

Научиться

Обсудить

Комментарии

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=742612
ArticleTitle=Выявление проблем DB2 при помощи команд и утилит AIX
publish-date=07252011