Перейти к тексту

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

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

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

  • Закрыть [x]

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

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

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

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

  • Закрыть [x]

Диагностика повреждений, возникающих при использовании IBM DB2

Понимание, выявление и устранение

Амиткумар Бамани, инженер по программному обеспечению, IBM
Amitkumar Bamane
Амиткумар Бамани (Amitkumar Bamane) является обладателем сертификата IBM Certified Advanced Technical Expert for DB2 (сертифицированный технический эксперт с углубленным уровнем знаний по продукту DB2). Он работает аналитиком в группе углубленной технической поддержке DB2 при лаборатории IBM India Software Lab (г. Пуна, Индия) и специализируется на оказании содействия заказчикам продуктов IBM DB2 из разных стран мира.

Описание:  В статье описывается, как распознавать и категоризировать наиболее распространенные повреждения, возникающие при использовании продукта IBM DB2®. Рассматриваются корректирующие и упреждающие методы для успешной борьбы с повреждениями.

Дата:  11.07.2013
Уровень сложности:  средний
Активность:  761 просмотров
Комментарии:  


Введение

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

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

В начале статьи рассматриваются возможные источники повреждений. После этого разъясняется выполнение следующих задач.

  1. Распознавание и устранение повреждения. Распознавание и категоризация повреждения в базе данных при использовании продукта DB2 с помощью сообщений о типичных признаках повреждений, регистрируемых в журнальном файле db2diag.log. В общих чертах повреждения могут быть классифицированы на пять категорий: повреждение страницы данных (или повреждение таблицы), повреждение индекса, повреждение CBIT, повреждение журнала, повреждение упакованного дескриптора.
  2. Использование команд db2dart и INSPECT для распознавания повреждения. Описание полезных команд DB2 — db2dart и INSPECT, — применяемых для проверки базы данных на наличие повреждений.
  3. Подходы к восстановлению после повреждения. После того как повреждение выявлено, очень важно уметь правильно выбрать подход, собрать необходимые данные и провести восстановление после повреждения. Вы узнаете о возможных подходах к восстановлению и научитесь делать выбор из имеющихся вариантов.
  4. Упреждающие стратегии для профилактики повреждений. Обсуждение наилучших практических методик.

Источники

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

  1. Поврежденная файловая система — одна из наиболее распространенных причин повреждений в базе данных. Внезапные остановы системы; скачки напряжения; двойное монтирование файловой системы; миграция дисков; такие действия на уровня файловой системы, как проверка и восстановление файловой системы (напр., с использованием утилит типа fsck в среде Linux®) при работающей базе данных; использование комбинации Ctrl+Alt+Delete при открытом файле, а также вирусы — все эти факторы способны внести непреднамеренные и нежелательные изменения в базу данных.
  2. Аппаратная неисправность
  3. Сбой оперативной памяти.
  4. Дефект в DB2
  5. Проблемы ввода/вывода и сетевые проблемы (проблемы в сетевых адаптерах, коммутаторах и т. д.).
  6. Некорректный программный код приложения.
  7. Несоответствие между значением страницы в буферном пуле (sqldPage) и значением страницы, хранящейся в файловой системе.
  8. Повреждение вследствие перезаписывания дисковых данных.
  9. Вмешательство пользователя в важные конфигурационные файлы базы данных, файлы журнала, файлы управления журналом и т. д., переводящее базу данных в несогласованное состояние.

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


Распознавание и устранение

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

При возникновении состояния ошибки, которое СУБД DB2 не в состоянии обработать корректно, она применяет метод под названием panic, заключающийся в самостоятельном инициировании аварийной остановки. Когда DB2 обнаруживает повреждение страницы, она останавливает всю обработку посредством контролируемой аварийной остановки (panic), поскольку она не способна подтвердить целостность базы данных. Это мера также призвана предотвратить дальнейшее повреждение или потерю данных.

При обнаружении повреждения в базе данных DB2 записывает определенные сообщения об ошибках в журнал db2diag.log. В случае возникновении сбоя — при заранее активированной функции FODC (first occurrence data capture) — осуществляется сбор данных на основе определенных "симптомов". DB2 9.5 осуществляет автоматический сбор FODC-данных при возникновении любого из следующих условий.

  1. Условие FOCD_Trap — произошло прерывание в масштабе экземпляра (instance wide trap).
  2. Условие FODC_Panic — механизм DB2 обнаружил несоответствие и решил не продолжать дальнейшую работу.
  3. Условие FODC_BadPage — была обнаружена плохая страница.
  4. Условие FODC_DBMarkedBad — база данных была помечена как плохая по причине ошибки.

Крайне важно задействовать соответствующие возможности операционной системы (ОС) и аппаратных средств для сбора необходимой информации, в том числе диагностических сведений об ОС (например, выходную информацию таких механизмов AIX®, как errpt –a, snap и fileplace) и диагностических сведений об оборудовании (сохраненные состояния, журналы ошибок и т.д.). Необходимо убедиться в наличии достаточного дискового пространства для ответственных файлов, таких как дампы и каталоги журналов, чтобы гарантировать полную регистрацию критических событий.

Просмотр журнала db2diag.log позволяет уточнить, чем вызвано событие типа panic — повреждением или иной причиной. Далее будут описаны процедуры распознавания повреждений в DB2 и их категоризации. Рассмотрим некоторые из наиболее распространенных сообщений об ошибках в журнале db2diag.log, которые указывают на наличие того или иного повреждения.

Повреждение страницы данных

Повреждение страницы данных указывает на наличие повреждения в реальных данных таблицы. При обнаружении повреждения данных в журнал db2diag.log заносится несколько сообщений. Эти сообщения необходимы для распознавания затронутого объекта. В листинге 1 показан пример сообщения об ошибке в журнале db2diag.log.


Листинг 1. Пример сообщение об ошибке при повреждении страницы данных
                 
2012-02-04-03.13.05.261082-360 I3442A358          LEVEL: Error 
PID     : 393470               TID  : 1           PROC : db2pfchr 0 
INSTANCE: inst1                NODE : 000 
FUNCTION: DB2 UDB, buffer pool services, sqlbReadAndReleaseBuffers, 
probe:13 
RETCODE : ZRC=0x86020001=-2046689279=SQLB_BADP "page is bad" 
DIA8400C A bad page was encountered. 
. 
. 
. 
2012-02-04-03.13.05.264301-360 I3801A437          LEVEL: Error 
PID     : 393470               TID  : 1           PROC : db2pfchr 0 
INSTANCE: inst1                NODE : 000 
FUNCTION: DB2 UDB, buffer pool services, sqlbReadAndReleaseBuffers, 
probe:13 
DATA #1 : String, 158 bytes 
Obj={pool:9;obj:20;type:0} State=x27 Parent={9;20}, EM=1120, PP0=1152 
Page=51235 Cont=17 Offset=2848 BlkSize=15 
sqlbReadAndReleaseBuffers error: num-pages=16

Согласно показанным выше сообщениям об ошибках, в DB2 имеется плохая страница в табличном пространстве ID 9 и в табличном пространстве ID 20. Тип объекта помечен как type:0, что указывает на повреждение страницы данных.

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

db2 "select char(tabname,20), char(tabschema,20) from
                    syscat.tables where tableid=20 and tbspaceid=9"

Обратите внимание, что DB2 выводит ошибки типа "плохая страница" только для тех страниц, к которым она пыталась получить доступ. Таким образом, это не обязательно означает, что повреждены только упомянутые страницы. Чтобы определить масштабы повреждения, следует с помощью команд INSPECT или db2dart явным образом проверить все страницы в базе данных.

Схожие сообщения об ошибках регистрируются в журнале db2diag.log при повреждении во временных таблицах. Если поле типа data в сообщении об ошибке, записанном в журнал db2diag.log, содержит значение, превышающее 128, это указывает на повреждение во временной таблице. Если объект имеет тип type:3, это указывает на повреждение LOB-данных в таблице.

Повреждение индекса

Индекс — это объект базы данных, содержащий упорядоченный набор указателей, которые ссылаются на строки в базовой таблице. С повреждениями индекса связано множество различных проблем, включая следующие.

  1. Уникальный элемент индекса дублирует различные RID-идентификаторы записей или один и тот же RID-идентификатор
  2. Несколько элементов индекса указывают на один и тот же RID-идентификатор.
  3. Ключ индекса находится в ненадлежащем месте (некорректный порядок ключей индекса).
  4. Строка существует, но ключи индекса в каком-либо индексе или в некоторых индексах не существуют.
  5. Элемент индекса указывает на пустую ячейку данных или на неиспользуемую ячейку данных либо RID-идентификатор является некорректным.
  6. Некорректные указатели на предыдущую или следующую страницу индекса, некорректное значение high key и другие повреждения на страницах индекса

Ниже показан пример сообщения об ошибке при повреждении индекса.


Листинг 2. Пример сообщения об ошибке при повреждении индекса
                 
2012-01-30-01.35.50.952434+000 I29308542A2532     LEVEL: Severe 
PID     : 1175792              TID  : 33926       PROC : db2sysc 0 
INSTANCE: inst1                NODE : 000         DB   : SAMPLE 
APPHDL  : 0-7                  APPID: *LOCAL.inst1.120130013528 
AUTHID  : TP0ADM 
EDUID   : 33926                EDUNAME: db2redow (TP0) 0 
FUNCTION: DB2 UDB, buffer pool services, sqlb_verify_page, probe:3 
MESSAGE : ZRC=0x86020001=-2046689279=SQLB_BADP "page is bad" 
DIA8400C A bad page was encountered. 
DATA #1 : String, 64 bytes 
Error encountered trying to read a page - information follows : 
DATA #2 : String, 23 bytes 
Page verification error 
DATA #3 : Page ID, PD_TYPE_SQLB_PAGE_ID, 4 bytes 
23046981 
DATA #4 : Object descriptor, PD_TYPE_SQLB_OBJECT_DESC, 72 bytes 
Obj: {pool:9;obj:11076;type:1} Parent={8;11076} 
                

Как показано в листинге 2, в сообщении об ошибке присутствует объект типа type:1, что указывает на повреждение страницы индекса. Этот индекс размещен в табличном пространстве ID 9 и имеет идентификатор 11076. Данный индекс находится в таблице, входящей в табличное пространство ID 8; эта таблица имеет идентификатор ID 11076. Для извлечения имени базовой таблицы и имени индекса нужно обратиться с запросом к таблицам каталога.

Показанный выше фрагмент журнала db2diag.log указывает на наличие плохой страницы индекса. Другие типичные признаки в журнале db2diag.log, указывающие на повреждение индекса: сообщения SQLI_NOKEY и row not found после выполнения функции index.

Повреждение CBIT

DB2 использует CBIT для подтверждения того, что страница, считанная с диска в буферный пул, не является частичной страницей (partial page) и не была изменена по причине какого-либо повреждения.

Основная идея CBIT состоит в том, что перед записью страницы одному разряду в каждом секторе (512 байтов) этой страницы присваивается одинаковое значение. Перед записью какой-либо страницы на диск DB2 вычисляет контрольную сумму и записывает ее на этой странице. При считывании этой страницы обратно в буферный пул производится повторное вычисление контрольной суммы и сравнение результата с сохраненным значением. Если некоторые биты различаются, это указывает на неполную запись страницы или на наличие повреждения на диске.


Листинг 3. Пример сообщение об ошибке при повреждении CBIT
                 
2012-03-12-04.45.17.559235-240 I1104A2616 LEVEL: Severe
PID : 2551866 		       TID : 1 	  PROC : db2pfchr
INSTANCE: inst1   	       NODE : 000
FUNCTION: DB2 UDB, buffer pool services, sqlbVerifyCBITS, probe:1110
MESSAGE : ZRC=0x86020019=-2046689255=SQLB_CSUM "Bad Page, Checksum Error"
DIA8426C A invalid page checksum was found for page "".
DATA #1 : String, 64 bytes
Error encountered trying to read a page - information follows :
DATA #2 : String, 95 bytes
CBIT verification error
bitExpected is 0, userByte is 33, sector 7 (from head of page, 0 based)
DATA #3 : Page ID, PD_TYPE_SQLB_PAGE_ID, 4 bytes
            

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

Повреждение журнала

Журнал транзакций в DB2 — это просто запись всех изменений, которые имели место в базе данных. Для отслеживания изменений, произведенных транзакциями, необходим метод для нанесения меток времени на изменения в данных, а также на записи в журнале. В DB2 этот механизм нанесения метки времени реализуется с помощью т.н. LSN-номера (Log Sequence Number). В случае повреждения журнала вы можете получить следующее сообщение об ошибке в файле db2diag.log.


Листинг 4. Пример сообщение об ошибке при повреждении журнала
                 
2010-06-07-12.37.21.143998+120 I8673583A553       LEVEL: Severe 
PID     : 2498668              TID  : 27358       PROC : db2sysc 56 
INSTANCE: inst1              NODE : 056         DB   : SAMPLE 
APPHDL  : 998-22947            APPID: *N998.inst1.100607192315 
AUTHID  : LOADDSF 
EDUID   : 27358                EDUNAME: db2agntp (SAMPLE) 56 
FUNCTION: DB2 UDB, data protection services, sqlpgrlg, probe:291 
DATA #1 : < reformatted >
Error -2028994519 when reading LSN 00000B1C261B4FD3 from log file 
S0119292.LOG tellMe 1 dpsAcbFlags 1000 setSkipOutputBuf 0 
                
2010-06-07-12.37.21.144202+120 I8674137A487       LEVEL: Severe 
PID     : 2498668              TID  : 27358       PROC : db2sysc 56 
INSTANCE: inst1              NODE : 056         DB   : SAMPLE
APPHDL  : 998-22947            APPID: *N998.inst1.100607192315 
AUTHID  : LOADDSF 
EDUID   : 27358                EDUNAME: db2agntp (SAMPLE) 56 
FUNCTION: DB2 UDB, data protection services, sqlpgrlg, probe:291 
DATA #1 : < preformatted >
HeadLsn 00000B1B8B996EB3, copyLookForLsn 00000B1C261B4FD3                               
                
2010-06-07-12.37.21.158065+120 I8675153A549       LEVEL: Error 
PID     : 2498668              TID  : 27358       PROC : db2sysc 56 
INSTANCE: inst1              NODE : 056         DB   : SAMPLE
APPHDL  : 998-22947            APPID: *N998.inst1.100607192315 
AUTHID  : LOADDSF 
EDUID   : 27358                EDUNAME: db2agntp (SAMPLE) 56 
FUNCTION: DB2 UDB, data protection services, sqlptudo, probe:1010 
RETCODE : ZRC=0x87100029=-2028994519=SQLP_BADLSN "Invalid LSN value." 
DIA8538C An invalid log sequence number (LSN), the value was "".
            

Повреждение журналов способно породить серьезные проблемы в процессе выполнения таких операций, как накат изменений (roll-forward) базы данных, восстановление после аварийного отказа, HADR-репликация и т. д., которые фактически реплицируют содержимое журналов. Накат изменений базы данных позволяет поддерживать согласованность базы данных. Эта операция восстанавливает базу данных посредством применения транзакций, записанных в журнальных файлах базы данных. Процесс наката изменений осуществляется после восстановления базы данных или табличного пространства по резервному образу.

Повреждение упакованного дескриптора

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


Листинг 5. Пример сообщения об ошибке при повреждении упакованного дескриптора
                 
2011-08-22-20.50.00.922275-300 I154161182E497      LEVEL: Severe 
PID     : 14152                TID  : 184633256288 PROC : db2sysc 0 
INSTANCE: inst1             NODE : 000          DB   : SAMPLE
APPHDL  : 0-64465              APPID: 161.166.44.48.27625.11082301341 
AUTHID  : DTADM1 
EDUID   : 606                  EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, catcache support, sqlrlc_systables_fetch_from_disk, 
probe:200 
MESSAGE : Corrupt PD->length in table:DTWF    .JBPM_TASKINSTANCE 
                
2011-08-22-20.50.00.922476-300 I154161680E1588     LEVEL: Severe 
PID     : 14152                TID  : 184633256288 PROC : db2sysc 0 
INSTANCE: inst1             NODE : 000          DB   : SAMPLE
APPHDL  : 0-64465              APPID: 161.166.44.48.27625.11082301341 
AUTHID  : DTADM1 
EDUID   : 606                  EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, catcache support, sqlrlc_systables_fetch_from_disk, 
probe:201 
MESSAGE : Length in PD=3792, LFD length=10104, DMS length=10104 
DATA #1 : String, 11 bytes 
Corrupt PD: 
DATA #2 : Dumped object of size 3792 bytes at offset 1386248, 53 bytes 
/volumes/work/db2dump/xnawmtp5/14152.606.000.dump.bin 
DATA #3 : LOB Descriptor, PD_TYPE_LOB_DESCRIPTOR, 60 bytes 
SQLDX_LD: Size:60 
    x0000        lfd_check                        0x49 
    x0001        lfd_version                      6 
    x0002        lfd_numsegs                      1 
    x0003        lfd_flags                        0x00 
    x0004        lfd_size                         10104 
    x000C        lfd_life_lsn                     0000009860A6FF2D 
    x0014        lfd_mini_numsegs                 0 
    x0015        lfd_first                        4 
    x0016        lfd_descsize                     60 
    x0018        lfd_last_pages                   16 
    x001C        lfd_last_bytes                   10104 
    x0038        lfd_dir                          Regular Directory 
Offsets 
        lfd_dir[0]: 33888 (16K) 
    Hexdump of LOB descriptor follows: 
        4906 0100 0000 0000 7827 0000 0000 0098 
        60A6 FF2D 0004 3C00 1000 0000 7827 0000 
        0000 0000 0000 0000 0000 0000 0000 0000 
        0000 0000 0000 0000 6084 0000 
            

В случае повреждения PD-дескриптора таблица становится недоступной.


Использование команд db2dart и INSPECT для распознавания повреждения

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

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

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

Инспектирование баз данных, табличных пространств и таблиц с помощью команды db2dart

По умолчанию команда db2dart осуществляет инспектирование всей базы данных. В этом случае пользователю необходимо задать лишь имя базы данных. По умолчанию команда db2dart создает файл отчета под именем databaseName.RPT. В среде базы данных с единственным разделом этот файл создается в текущем каталоге. В среде базы данных с несколькими разделами этот файл создается в подкаталоге диагностического каталога. Этот подкаталог имеет имя вида DARTnnnn, где nnnn — номер раздела.

Если база данных имеет большие размеры, а вас интересует лишь одно определенное табличное пространство, вы можете воспользоваться опцией /TS. При использовании этой опции вы должны указать в командной строке нужный идентификатор табличного пространства (с помощью параметра /TSI) или позволить утилите db2dart вывести соответствующую подсказку. Если вам не известен идентификатор этого табличного пространства, вы сможете получить его с помощью команды DB2 LIST TABLESPACES.

Аналогичным образом вы сможете проинспектировать одиночную таблицу и связанные с ней объекты (LOB, индексы и т. д.) с помощью опции /T. При использовании этой опции необходимо указать имя нужной таблицы или идентификатор объекта и идентификатор табличного пространства, в котором размещается эта таблица. Для определения идентификатора объекта и идентификатора табличного пространства для таблицы можно обратиться с запросом к таблице каталогов SYSIBM.SYSTABLES.

Выполнение дампа форматированных табличных данных с помощью команды db2dart

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

Если произошло нечто подобное, вам необходимо извлечь максимально возможный объем данных, чтобы табличное пространство и таблицу можно было создать заново. В такой ситуации можно воспользоваться опцией /DDEL команды db2dart, чтобы извлечь табличные данные и представить их в кодировке ASCII с разделителями. В следующих параграфах эти опции описываются более подробно.

Команда INSPECT

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

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


Подходы к восстановлению после повреждения

Проблемы повреждения базы данных иногда являются весьма запутанными; для выбора наилучшего выхода из сложившейся ситуации может потребоваться поддержка квалифицированных специалистов IBM. Ниже для наиболее распространенных типов повреждений будут описаны процедуры действий и рекомендации по отысканию наилучших вариантов восстановления. После того, как повреждение обнаружено, второй по важности момент — это выявление источника проблемы. Для начала необходимо исправить текущую ситуацию.

Восстановление в случае повреждения страницы данных

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

  1. Если имеется резервная копия базы данных, восстановите базу данных и осуществите накат изменений вплоть до конца журналов. Это самый корректный подход (при условии его осуществимости), который является предпочтительным при небольших размерах базы данных.
  2. Вы также можете восстановить табличное пространство и осуществить накат изменений вплоть до конца журналов. Это может оказаться наилучшим вариантом, если повреждение является локальным.
  3. Если вы располагаете другими способами воссоздания данных для поврежденной таблицы или имеете копию соответствующих табличных данных, удалите таблицу и создайте ее заново. Вам потребуется DDL-код этой таблицы; если вы располагаете данными для этой таблицы, то вам необходимо удалить таблицу, воссоздать таблицу с помощью этого DDL-кода, а затем воссоздать данные с помощью любых средств, которые могут оказаться в вашем распоряжении.
  4. Если у вас нет рабочего резервного образа и вы не располагаете никаким способом для воссоздания таблицы, вы можете воспользоваться командой db2dart с опцией /ddel для "спасения" данных из поврежденной таблицы. Предварительно необходимо получить DDL-код таблицы с помощью команды db2look. Вы можете извлечь DDL-код из поврежденной таблицы следующим образом.
    db2look -d <dbname> -e
                            -z <schema_name> -t <table_name> -o <output_file_name>
                        

    Рассмотрим пример применения команды db2dart с опцией /ddel для спасения данных из поврежденной таблицы: db2dart <dbname> /ddel. Эта команда принимает четыре входных значения: идентификатор объекта таблицы или имя таблицы, идентификатор табличного пространства, номер начальной страницы, количество страниц. В качестве числа страниц можно указать конкретное значение или достаточно большое число (например, 999999999), которое обеспечит извлечение всех страниц этой таблицы. Кроме того, если определенная страница в таблице имеет слишком большие повреждения, может потребоваться неоднократное выполнение команды db2dart /DDEL – для сокращенного диапазона страниц или с пропуском поврежденной страницы.

    Файл дампа представлен в формате с разделителями в кодировке ASCII, соответствующей кодовой странице базы данных. Команда db2dart не осуществляет преобразования кодовой страницы. После того как вы будете располагать всеми данными, спасенными из поврежденной таблицы, вы можете проверить выходной файл *.DEL и убедиться в том, что все данные существуют. После этого вы можете удалить поврежденную таблицу и впоследствии создать ее заново с использованием данных, извлеченных с помощью команды db2dart. Обратите внимание, что команда db2dart/DDEL не работает с LOB-данными.

  5. Если вы располагаете способом для воссоздания поврежденного табличного пространства, вы можете с помощью команды restart database пометить поврежденное табличное пространство как ожидающее удаления. Позднее вы сможете воссоздать поврежденное табличное пространство.
  6. Если ни один из вышеперечисленных вариантов не может быть осуществлен или порождает какую-либо ошибку в процессе таких операций, как извлечение данных, удаление таблицы, воссоздание таблицы и т. д., обратитесь за содействием в службу поддержки IBM. В зависимости от сложившейся у вас ситуации специалисты службы поддержки IBM помогут удалить поврежденную таблицу, инициализировать поврежденные страницы в состояние NULL и т. д.

Восстановление в случае повреждения индекса

Если в файле db2diag.log и/или в отчетах команды db2dart имеются признаки повреждения индекса, то с помощью команды db2dart вы можете пометить этот индекс как недействительный и тем самым избавиться от плохих индексов. Впоследствии вы сможете воссоздать эти индексы.

Команда db2dart имеет опцию для маркировки недействительного индекса и перевода его в состояние ожидания удаления. Пометить поврежденный индекс как недействительный можно с помощью команды db2dart /MI. Пример: db2dart <dbname> /MI /TSI 9 /OI 11076.

Вы можете задать время для воссоздания индекса посредством присвоения параметру INDEXREC соответствующего значения (restart, access и т. д.). Так, воссоздать индексы при попытке доступа приложения к индексу можно следующим образом: db2 update db cfg for <dbname> INDEXREC ACCESS.

После того, как вы сделаете плохой индекс недействительным и обновите параметр INDEXREC, вы сможете подключиться к базе данных.

Если проблема вызвана ошибкой индекса типа NOKEY, можно применить несколько команд db2dart для вывода нужной информации в файл db2diag.log. При необходимости вы можете выполнить команды db2dart <dbname>/di для вывода дампа форматированных данных индекса с целью анализа первопричины повреждения индекса. Необходимо сохранить эти команды с помощью grep в среде UNIX® или с помощью Find в среде Windows®, а затем сохранить их в виде файла. Отредактируйте этот файл и замените имя DBNAME на имя своей базы данных. Если проблема повторялась неоднократно, то в этом файле могут оказаться дублирующиеся элементы. Вам необходимо сохранить лишь последний набор команд db2dart. Чтобы с помощью команды db2dart убедиться в том, что индекс действительно является плохим, можно выполнить команду вида db2dart <dbname> /t /tsi <tablespace_id> /oi <table_id> , где tablespace_id и table_id — это идентификатор табличного пространства и идентификатор объекта базовой таблицы, в которой определен этот индекс.

Восстановление в случае ошибок CBIT

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

Восстановление в случае повреждения журнала

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

При возникновении ошибок по причине плохих журналов при накате изменений необходимо в первую очередь проверить, об ошибке какого журнального файла сообщает DB2. В этом случае можно воспользоваться командой db2flsn для получения имени файла, который содержит журнальную запись, идентифицируемую соответствующим LSN-номером (log sequence number). Таким образом, если в файле db2diag.log имеются сообщения 'bad_lsn', можно использовать команду db2flsn для отыскания соответствующего журнального файла.

Если нужный журнальный файл отсутствует или принадлежит к некорректной цепочке журналов, вы можете поискать корректный журнальный файл. Если накат изменений завершился неудачей из-за поврежденного журнала, попытайтесь выполнить накат изменений на определенный момент времени. Интервал до начала этой операции наката изменений должен быть равен показателю "минимальное время восстановления" или превышать его. Минимальное время восстановления определяет самый ранний момент времени для начала наката изменений, когда база данных становится непротиворечивой. Если вы не в состоянии выполнить это условие, вам следует обратиться за содействием в службу поддержки IBM. Другой вариант восстановления — использование с этой целью оффлайновой резервной копии базы данных и отказ от осуществления наката изменений на основе журналов. В этом случае зарегистрированные в журналах транзакции не будут повторно применены к этой базе данных.

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

В терминологии HADR сервер, который обрабатывает транзакции, называется первичным (primary), а "партнерская" база данных, которая получает журналы и воспроизводит их, называется резервной (standby). В процессе восстановления по содержимому журнала на резервном HADR-компоненте этот компонент может испытать аварийную остановку по причине плохого журнала. С целью выявления плохого журнала вы можете проверить файл db2diag.log на резервном компоненте и попытаться предоставить хорошую копию этого журнала с первичного устройства. Имея в своем распоряжении хороший журнальный файл, вы сможете запустить функцию HADR.

  1. Выполните команду start на HADR-компоненте, находящемся в режиме standby: db2 start hadr on db <dbname> as standby.
  2. Выполните команду start на HADR-компоненте, находящемся в режиме primary:db2 start hadr on db <dbname> as primary.

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

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

Восстановление в случае повреждения упакованного дескриптора

Для устранения повреждения упакованного дескриптора можно воспользоваться инструментом db2cat. Перед тем как изменять упакованный дескриптор, необходимо проконсультироваться со службой поддержки IBM. Для изменения упакованного дескриптора выполните следующие действия.

  1. export DB2SVCPW=<service_password from IBM support>
  2. db2cat -d <dbname> -s <schema> -n <tablename> -f <raw pd output file> -o <message file>
  3. db2cat -d <dbname> -s <schema> -n <tablename> -g <generated pd output file> -o <message file>
  4. db2cat -d <dbname> -s <schema> -n <tablename> -r <generated pd output file> -o <message file>

    (в качестве входных данных для опции замены -r используйте файл, сгенерированный с опцией -g).

  5. Экспортируйте данные из таблицы (при необходимости)
  6. Удалите таблицу
  7. Воссоздайте таблицу (при необходимости)
  8. Импортируйте пользовательские данные (при необходимости)

Теперь вы можете снова применить к базе данных верификационную опцию db2cat: db2cat -d <dbname> -s % -n % -v .

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


Упреждающие стратегии по избежанию возможных повреждений

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

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

  1. Отслеживание всех изменений.
  2. Установка последнего пакета исправлений и, если это возможно, новейшей версии DB2 и новейшей версии операционной системы (в случае их применимости).
  3. Регулярная проверка состояния файловой системы и сети
  4. Корректное выключение DB2 – в максимально возможной степени.
  5. Применение команды db2dart к базе данных в оффлайновом режиме с целью проверки на наличие повреждений. Если вы не можете позволить себе перевод производственной базы данных в оффлайновый режим, что необходимо для выполнения команды db2dart, восстановите недавние резервные копии производственной базы данных на тестовой машине и примените команду db2dart к этой базе данных. В качестве альтернативного варианта вы можете воспользоваться командой INSPECT, когда база данных находится в онлайновом режиме. Этот подход можно использовать для раннего обнаружения повреждений или для превентивной проверки состояния базы данных на наличие повреждений.
  6. Наличие хорошей политики резервного копирования. Резервная копия как таковая не обнаруживает повреждения в страницах, поэтому рекомендуется иметь мощную политику резервного копирования и достаточное количество резервных копий.
  7. Применение таких дисковых конфигураций, как RAID, помогающих минимизировать повреждения данных за счет использования избыточных дисков для резервирования данных.
  8. Применение хороших источников бесперебойного питания для противодействия повреждениям, вызываемым скачками напряжения.
  9. Отслеживание недавно выявленных дефектов в IBM DB2 и в операционной системе.

Заключение

В статье были рассмотрены наиболее распространенные повреждения при использовании продукта IBM DB2. Были продемонстрированы различные признаки в сообщениях о повреждения в файле db2diag.log, а также было показано, как на основе этих сообщений распознавать тип повреждения и как устранять возникшие проблемы. И, наконец, были описаны команды db2dart и INSPECT, весьма полезные при работе с повреждениями.


Ресурсы

Научиться

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

  • Теперь у вас есть возможность использовать DB2 бесплатно. Загрузите DB2 Express-C, бесплатную версию редакции DB2 Express Edition для сообщества, которая имеет такие же базовые функции по работе с данными, что и DB2 Express Edition и способна служить прочным фундаментом для создания и развертывания приложений.

Обсудить

Об авторе

Amitkumar Bamane

Амиткумар Бамани (Amitkumar Bamane) является обладателем сертификата IBM Certified Advanced Technical Expert for DB2 (сертифицированный технический эксперт с углубленным уровнем знаний по продукту DB2). Он работает аналитиком в группе углубленной технической поддержке DB2 при лаборатории IBM India Software Lab (г. Пуна, Индия) и специализируется на оказании содействия заказчикам продуктов IBM DB2 из разных стран мира.

Помощь по сообщениям о нарушениях

Сообщение о нарушениях

Спасибо. Эта запись была помечена для модератора.


Помощь по сообщениям о нарушениях

Сообщение о нарушениях

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.


developerWorks: вход


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


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

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

 


При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Выберите ваше отображаемое имя

При первом входе в 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=937069
ArticleTitle=Диагностика повреждений, возникающих при использовании IBM DB2
publish-date=07112013