Поиск по этому блогу

вторник, 18 января 2011 г.

Администрирование DB2. Backup, Restore и их логи

Часть I. Виды восстановления.

 
Восстановление версии - восстановление предыдущей версии базы данных с использованием образа, созданного при резервном копировании. Используется для невосстановимых баз данных у которых нет архивированных журналов. При помощи опции команды   WITHOUT ROLLING FORWARD этот метод можно использовать и для восстановимых баз данных.
Восстановление повтором - повторное применение транзакций, записанных в файлах журналов базы данных, после того, как база данных или табличное пространство восстановлены из образа резервной копии.
Восстановление после отказа - автоматическое восстановление базы данных в случае отказа до момента завершения и принятия всех изменений, составляющих часть одной или нескольких единиц работы (транзакций). Достигается откатом незавершенных транзакций и завершением принятых транзакций, которые еще оставались в памяти к моменту отказа. Главная цель этого вида восстановления - привести базу данных в согласованное, рабочее состояние. Важным параметром для восстановления после отказа является autorestart, его значение on (по умолчанию) говорит о том, что менеджер баз данных самостоятельно будет производить откат незавершенных транзакций и переводить базу данных в согласованное состояние, и после сбоя вам не понадобиться вручную вызывать команду restart database.
Виды журналов.
У каждой базы данных есть связанные с ней журналы. В этих журналах хранятся записи изменений базы данных.
Журналы восстановления — информация о транзакциях для восстановления при ошибках программ или системы
Хронология восстановления — сводная информация о резервном копировании. (файл в каталоге БД). Используется для отслеживания событий, связанных с восстановлением, операций резервного копирования и восстановления.
Активный журнал (Active) - Файлы журналов которые служат для аварийного восстановления. Содержат информацию о текущих транзакциях, которые еще не были зафиксированы, либо был произведен откат или зафиксированы, но изменения в них еще не были переписаны в файлы БД. На количество транзакций, которые будут находиться в активном журнале влияет параметр конфигурации БД MINCOMIT
Архивные журналы - содержат данные о принятых транзакциях.
Типы записи (регистрации) в журнал.
В DB2 существует два типа регистрации в журналах: циклическая и архивная . Каждая из них обеспечивает свой вид восстановления. Самая простая - циклическая запись, она определяется по умолчанию при создании новой базы данных, фактически такой тип регистрации означает, что существуют только активные журналы, которые и перезаписываются по мере необходимости. На схеме ее область обведена зеленым цветом.

 Восстановимые базы данных должны использовать архивный тип записи в журнал. (на схеме ее область обведена  синим цветом). Как видно из схемы, кроме активных журналов появляются еще и  архивные журналы с данными о принятых транзакциях, которые и позволяют восстановить базу данных из резервной копии - на момент времени 12:00, плюс накатить транзакции, которые прошли после снятия резервной копиии, в том числе и о транзакции которая произведена в 14:00. На схеме видно, что на этот момент времени в одном из архивных журналов хранится запись о принятой транзакции insert into test... именно эта транзакция и будет накатываться (ROLLWORWARD) на нашу автономную копию. Впрочем, мы вольны и не накатывать эту транзакцию.

О параметрах конфигурации.
Невосстановимые базы данных. Циклическая запись.
выбирается по умолчанию, когда создается новая база данных. 
Параметрам конфигурации базы данных logarchmeth1 и  logarchmeth2 = OFF.  При этом типе регистрации в журнале допустимы только полные автономные резервные копии базы данных. При выполнении резервного копирования база данных должна находиться в автономном состоянии (недоступном для пользователей). Из названия понятно, что для восстановления с целью устранения ошибок транзакций и сбоев системы при циклической записи используется "кольцо" журналов. Эти журналы используются и сохраняются только до точки, гарантирующей целостность текущих транзакций. Количество транзакций в активном журнале определяется параметром mincommit. Циклическая запись не позволяет выполнять повтор транзакций, выполненных после снятия последней полной резервной копии. Все изменения со времени последней резервной копии теряются. Данные восстанавливаются до конкретной точки времени создания полной резервной копии (восстановлением версии).
Конфигурация БД для циклической записи (get db cfg)
Обработчик пользов. для регистрации включен  (USEREXIT) = OFF // устаревший параметр
Сохранение в журнале для восстанов.включено (LOGRETAIN) = OFF // устаревший параметр

Первый метод архивирования журнала       (LOGARCHMETH1) = OFF
Второй метод архивирования журнала       (LOGARCHMETH2) = OFF


Восстановимые базы данных. Архивная запись.
Параметр logarchmeth1 и (или) userexit должен быть отличен от off. Чаще всего используется
     параметр бд logarchmeth1 LOGRETAIN.
Параметр logarchmeth1 определяет отношение менеджера db2 к архивным журналам:
Logarchmeth1 LOGRETAIN
После архивирования файлов журналов нужно удалить их из каталога активных журналов, чтобы занимаемое ими пространство можно было использовать для новых файлов журналов. При заполнении очередного файла журнала DB2 начинает записывать данные в новый файл, если максимальное число основных и дополнительных файлов журнала еще не достигнуто.

Logarchmeth1 - не OFFи не LOGRETAIN
После заполнения файла журнала он автоматически архивируется с помощью программы обработчика пользователя. Файлы журнала обычно не удаляются. Если потребовался новый файл журнала, а свободного файла нет, то переименовывается и заново используется один из архивных файлов журнала. Архивный файл журнала не удаляется и не переименовывается после того, как он был закрыт и скопирован в каталог архивных журналов. Когда DB2 требуется новый файл журнала, то переименовывается самый старый архивный журнал. Файл журнала, перемещенный в каталог базы данных во время восстановления, удаляется, как только он становится ненужным. Если в DB2 есть свободное место в пространстве журналов, то в каталоге базы данных будут находиться старые файлы журнала.


Для архивной записи существует своя классификация типов резервного копирования:
Инкрементная или кумулятивная. - каждая следующая инкрементная резервная копия содержит информацию всех предыдущих. Предшественником   инкрементной   резервной   копии   всегда   является   последняя   успешная   полная   резервная   копия.
    параметры бд (trackmod = yes)
Разностная или дифференциальная - содержит только те страницы, которые изменились с момента создания предыдущей копии любого типа, дельту.  Предшественником   разностной   резервной   копии   является   последняя   резервная   копия   со   всеми   табличными   пространствами,   входящими   в   данную   разностную   резервную   копию.
    параметры бд (trackmod = no)
Практика.
Переводим базу данных в восстановимую, на архивный тип записи.
Используя wizard (Центру управления ->Конфигурировать запись в журнал базы данных) мы получаем следующий скрипт
CONNECT TO CLIENTPF;
QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS; - отключаем пользователей и стабилизируем базу данных
UNQUIESCE DATABASE;
CONNECT RESET;
UPDATE DB CFG FOR CLIENTPF USING
    logarchmeth1 LOGRETAIN - переводим базу на архивный способ регистрации
либо
    logarchmeth1 D:\DB2LOGS\CLIENTPF\ARHLOG - указываем путь к архивным журналам, автоматическое обслуживание
    logprimary 30
    logsecond 8
    logfilsiz 1024
    newlogpath D:\DB2LOGS\CLIENTPF\LOG; - переопределим путь для логов


Перевод бд из невосстановимой в восстановимую требует создания полной резервной копии бд.
Чтобы   восстановить   базу   данных   или   табличное   пространство   до   согласованного   состояния,   процесс   восстановления   должен   начаться с согласованной  резервной  копии  всей базы данных. Кроме того, при изменении параметров logretain и/или userexit необходимо сделать резервную копию базы данных.
-- резервная копия, необходима при изменении параметров logretain и/или userexit
BACKUP DATABASE CLIENTPF TO "D:\DB2LOGS\CLIENTPF\BACKUP" WITH 2 BUFFERS BUFFER 1024 PARALLELISM 1 COMPRESS  WITHOUT PROMPTING;

Центр управления предлагает нам иную конфигурацию, с "автоматическим" управлением архивными журналами, в результате мы получаем две директории, в одной сохраняются логи и активные и архивные, в другую копируются архивные логи. ??? При этом значение параметра LOGRETAIN не изменяется.
UPDATE DB CFG FOR CLIENTPF USING logarchmeth1 "DISK:D:\DB2LOGS\CLIENTPF\ARHLOGS" ...
Пример конфигурации. Архивная разностная (дифференциальная).
 Сохранение в журнале для восстанов.включено (LOGRETAIN) = RECOVERY
 Первый метод архивирования журнала       (LOGARCHMETH1) = LOGRETAIN - включаем архивирование
 Обработчик пользов. для регистрации включен  (USEREXIT) = OFF
 Отслеживать измененные страницы              (TRACKMOD) = OFF - копия будет разностной
 Путь к файлам журнала                                   = D:\DB2LOGS\CLIENTPF\LOG\
 Первый активный файл журнала                            = S0000000.LOG

В том случае, если вы задали путь (logarchmeth1 DISK:...), архивные журналы будут сохранятся в этой директории, если  LOGRETAIN = RECOVERY, то архивные   журналы   сохраняются   в   каталоге   журналов   базы   данных  (logpath).

logarchmeth1, logarchmeth2 - методы архивирования журналов
В версии 8 используется параметр logarchmeth1 - Метод   архивирования   журнала   1 и  метод   архивирования   журнала   2   logarchmeth2.   Если   заданы   оба   параметра,   каждый   из   файлов   журнала   архивируется   дважды.   У   вас   будет   две   копии   архивированных   файлов   журнала   в   разных   директориях.  
Для невосстановимых баз данных
OFF   Метод   архивирования   журнала   не   используется.   База   данных   использует   циклическую   запись   и   не   допускает   восстановления   с   повтором   транзакций.   Опция   по   умолчанию.  
Для восстановимых баз данных
LOGRETAIN Только   для   logarchmeth1,   что   эквивалентно   установке   для   параметра   конфигурации   logretain   значения   RECOVERY.
USEREXIT   Только   для   logarchmeth1   и   эквивалентна   заданию   для   параметра   конфигурации   userexit   значения   ON.  
DISK   Путь   для   архивирования   файлов   журнала. Пример. logarchmeth1 "DISK:D:\DB2LOGS\CLIENTPF\ARHLOGS" - архивные файлы будут находиться в каталоге D:\DB2LOGS\CLIENTPF\ARHLOGS

trackmod - включение отслеживания измененных страниц.
Для инкрементных резервных копий следует включить параметр trackmod, он позволяет отслеживать изменения базы данных.
NO - инкрементное резервное копирование не разрешено
YES - инкрементное резервное копирование разрешено, менеджер отслеживает изменения табличных пространств, и, если изменения были, то включает табличное пространство в резервную копию. !!! К включению этого параметра надо подходить крайне осторожно, т.к. отслеживание изменений неблагоприятно сказывается на производительности при выполнении пишуших транзакций (insert, update) !!!

logretain - включение хранения журналов (устаревший параметр)
No - журналы не хранятся.
Recovery - журналы хранятся и могут использоваться для восстановления с повтором транзакций.

Перевод вида записи из архивной в циклическую приведет к тому, что менеджер баз данных удаляет все журналы в каталоге logpath (включая и оперативные файлы архивных журналов), выделяет новые файлы активных журналов и возвращается к циклической записи.
userexit (устаревший параметр)  Если этот параметр включен, запись журналов с сохранением выполняется независимо от значения параметра logretain . Этот параметр также указывает, что для архивации и восстановления файлов журнала должен использоваться обработчик пользователя.
Файлы журналов архивируются, когда менеджер баз данных закрывает файл журнала. Они извлекаются из архива, когда становятся нужны утилите ROLLFORWARD для восстановления базы данных.
logpath - положение файлов журнала.  Менять этот параметр можно с помощью другого параметра newlogpath. То есть чтобы переопределить пути к журналам достаточно выполнить команду update db cfg using newlogpath D:\DB2LOGS\CLIENTPF\LOG.

Параметры, повышающие отказоустойчивость системы.
Параметр failarchpath, в случае сбоя копирования по основному пути, например переполнение диска, архивы будут сохраняться в указанном  failarchpath месте.
Путь журналов переполнения OVERFLOWLOGPATH, на самом деле альтернативный путь журналов. По этому пути DB2 будет искать журналы, необходимые для повтора транзакций, аналогично заданию опции OVERFLOW LOG PATH команды ROLLFORWARD.
Для бд, сконфигурированных с бесконечным количством логов каталог (logsecond -1), в котором DB2 будет хранить файлы активного журнала, восстановленные из архива. (Файлы архивного журнала восстанавливаются для выполнения операций отката, если они уже не хранятся в пути активного журнала).

 Путь журналов зеркальной копии MIRRORLOGPATH - поддержка двойного ведения журнала.
 Блокировать журнал при переполн.диска (BLK_LOG_DSK_FUL) = NO
 Блокировать операции, не занесенные в журнал   (BLOCKNONLOGGED) = NO
 Процент макс.перв.простр.журнала у транзакции(MAX_LOG) =  0
 Число акт.файлов журнала на актив.ед.раб. (NUM_LOG_SPAN)= 0
 numarchretry - число повторных попыток при ошибке
Прим.Если у вас нет параметров ARCHRETRYDELAY, NUMARCHRETRY и FAILARCHPATH, значит ваша db2 устарела.

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

Размер   файла   журнала   (logfilsiz)   размер   каждого   журнала   в   страницах   по   4   Кбайта. Максимальный размер журнала для версии 7 - 32Гб, версии 8 - 256Гб.
Переключение   с   одного   журнала   на   другой   приводит   к   определенному   снижению   производительности. Чем больше размер файл журнала, тем меньше операций переключения с журнала на журнал потребуется, однако при этом увеличивается вероятность сбоя или задержки   в   сценариях   распределения   журналов.

Максимальное пространство журнала на одну транзакцию (max_log) -  процент первичного пространства журнала, который может использоваться для одной транзакции. Если задано значение 0, доля первичного пространства журнала, используемая для одной транзакции, не ограничивается.
Если прикладная программа нарушает ограничение, заданное параметром конфигурации max_log, эта прикладная программа принудительно отсоединяется от базы данных, для транзакции выполняется откат и возвращается ошибка SQL1224N.
Это поведение можно переопределить, задав для переменной реестра DB2_FORCE_APP_ON_MAX_LOG значение FALSE. При этом для транзакций, нарушающих заданное параметром конфигурации max_log ограничение, будет фиксироваться неудача и возвращаться ошибка SQL0964N. Прикладная программа сможет выполнить принятие выполненных предыдущих операторов в единице работы или откат выполненных операторов для отката единицы работы.

Первичные файлы журнала (logprimary) - число первичных файлов журнала, размером logfilsz. При конфигурировании этого параметра следует учесть, что в количество журналов должно определяться исходя объема транзакции и параметра mincommit. Для восстановимых баз данных в журналы записывается дополнительная информация для полей LONG VARCHAR и LOB.

Вторичные файлы журнала (logsecond)  - число вторичных файлов журнала, если первичные файлы заполняются, то db2 по одному выделяет  вторичные файлы журналов.

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

число занимаемых журналов (num_log_span) -
 не равно 0 - сколько активных файлов журнала разрешается занимать активной транзакции.
 равно 0 - одна транзакция может занимать неограниченное число файлов журнала. Такое поведение использовалось для транзакций до Версии 8.

Как отличить активный журнал и архивный журнал?
Если вы выбрали вариант logarchmeth1 LOGRETAIN (LOGRETAIN = RECOVERY) и не назначили USEREXIT, то следить за архивными файлами придется вручную. Для этого необходимо знать какой из журналов является активным, а какой - архивный. Для этого достаточно посмотреть параметр БД loghead,
>get db cfg
Первый активный файл журнала                            = S0000008.LOG
Журналы с номерами меньше, чем указано - архивные и их можно переместить.
После завершения оперативного резервного копирования db2 принудительно закрывает активный журнал и он архивируется. т.е. с момента времени, когда сделан backup для бд все журналы становятся архивными.

Еще одна команда, которая даст нам более подробную информацию о журналах и резервных копиях - LIST HISTORY
Сокращения
Backup types: F - Offline N - Online I - Incremental offline O - Incremental online D - Delta offline E - Delta online
Archive Log types: P - Primary log path M - Secondary (mirror) log path F - Failover archive path 1 - Primary log archive method 2 - Secondary log archive method
прочие сокращения в help

db2 list history since 20101201 for clientpf - получить историю начиная (since) c 20101201
результат
Первая копия: сделана 2010-12-31, offline, активный журнал - S0000000.LOG
 Оп Об. Время+Последоват.  Тип     Уст     Первый журн. Текущий журн ID рез.копии
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20101231095537001       F        D      S0000000.LOG S0000000.LOG
 ---------------------------------------
-------------------------------------
    Комментарий: DB2 BACKUP CLIENTPF OFFLINE
    EID: 359 Положение: D:\DB2LOGS\CLIENTPF\BACKUP - путь к backup'у
Вторая копия: сделана  20110102, тип - 1 - Primary log archive method
 Оп Об. Время+Последоват.  Тип      Уст         Первый журн.     Текущий журн ID рез.копии
 -- --- ------------------ ---- --- ------------ ------------ --------------
  X  D  20110102163553          1        D          S0000001.LOG     C0000000
 ----------------------------------------------------------------------------
  EID: 361 Положение: D:\DB2LOGS\CLIENTPF\DB2\CL1\NODE0000\C0000000\S0000001.LOG
db2 list history backup since 20101201 for clientpf

результат
 после полного backup тип (F) изменился текущий журнал s (S0000005.LOG), журнал (C0000000) остался на месте
 Оп Об. Время+Последоват.  Тип  Уст     Первый журн. Текущий журн ID рез.копии
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20110114112156001       F    D          S0000005.LOG S0000005.LOG
 ----------------------------------------------------------------------------

Чистим журналы и историю. PRUNE
Самый простой способ удалить старые файлы журнала - перезапустить базу данных. После перезапуска базы данных в ее каталоге останутся только новые файлы журнала и файлы журнала, которые не удалось заархивировать программе обработчика пользователя. (??)

PRUNE HISTORY/LOGFILE Command
чистим историю и удаляем логи
>db2 prune history 20110101 and delete
после выполнения этой команды снова запускаем list history backup и убеждаемся, что история подчищена до 01/01/2011, удаляются файлы  архивных журналов, из директории с активными журналами (указано в logpath) для конфигурации Logarchmeth1 LOGRETAIN
или в директории указанной в параметре logarchmeth1 "DISK:D:\DB2LOGS\CLIENTPF"
опция and delete говорит о том, что архивные логи будут физически удалены с диска, но только в том случае, если вы не используете опцию userexit (в этом случае пользовательская программа сама должна позаботиться об удалении/перемещении логов)
Для версии 9.7 проверено
Для версии 8.2 ???
удаляем журналы
db2 prune LOGFILE PRIOR TO S0000030.LOG
Опять таки стоит отметить, что удаляются журналы из директории logarchmeth1 "DISK:D:\DB2LOGS\CLIENTPF"
удаляются архивные файлы младше (индекс меньше) S0000030.LOG.

Command syntax
  >>-PRUNE-------------------------------------------------------->
>--+-HISTORY-- timestamp --+-------------------+--+------------+-
+-><
   |                     '-WITH FORCE OPTION-'  '-AND DELETE-' |
   '-LOGFILE PRIOR TO-- log-file-name ---------------------------'


WITH FORCE OPTION
Specifies that the entries will be pruned according to the time stamp specified, even if some entries from the most recent restore set are deleted from the file. A restore set is the most recent full database backup including any restores of that backup image. If this parameter is not specified, all entries from the backup image forward will be maintained in the history.
Примечание для опции FORCE:    Настоятельно   рекомендуется   не   применять   опцию   FORCE   в   команде   PRUNE   HISTORY.   По   умолчанию   эта   команда   не   удаляет   те   записи   хронологии,   которые   могут   понадобиться   для   восстановления   с   самого   свежего   полного  образа   резервной   копии,   однако   с   опцией   FORCE   можно   удалить   записи,   необходимые   для   автоматического   восстановления.  

Путаница со старыми новыми параметрами
В версиях предшествующих DB2 8 (честно говоря не могу сказать до какой именно версии) для перевода базы данных на архивную запись следовало менять параметр logretain на RECOVERY, в этом случае архивные   журналы   сохраняются   в   каталоге   журналов   базы   данных,   и   база   рассматривается   как   восстановимая,   то   есть   для   нее   разрешен   повтор   транзакций. Или (и) включить параметр userexit. Согласно справочной информации, параметр logretain и userexit устарели и оставлены только для совместимости с предыдущими версиями.
Изменение параметра logretain на RECOVERY в версии 8.2 приведет и к  изменению параметра LOGARCHMETH1 на LOGRETAIN. То же самое будет если поменять LOGARCHMETH1 на LOGRETAIN. Аналогично и для userexit.
Параметров logretain  RECOVERY и logarchmeth1 "DISK:D:\DB2LOGS\CLIENTPF"  приведет к тому, что в результате команды prune в директории с активными журналами будут накапливаться логи, хотя из директории с архивными журналами (D:\DB2LOGS\CLIENTPF) файлы логов исправно удаляются
Автоматическое управление файлами журналов?
Используя центр управления -> Конфигурировать запись в журнал базы данных. Мы можем получить возможность автоматического управления архивными файлами журналов. Для этого wizard предлагает задать путь в параметре logarchmeth1
UPDATE DB CFG FOR CLIENTPF USING logarchmeth1 "DISK:D:\DB2LOGS\CLIENTPF\LOGS" ...

Кроме того, мы получаем отдельно путь для архивных журналов, отдельно путь для активных журналов. Prune чистит архивные журналы (путь указанный в logarchmeth1) , а файлы по пути активных журналов (logpath D:\DB2LOGS\CLIENTPF\ACTIVELOG\) накапливаются. О том какой журнал является активным говорит параметр конфигурации бд loghead.

Параметры-индикаторы.
backup_pending - индикатор отложенного резервного копирования
Значение ON этого параметра указывает, что перед обращением к базе данных необходимо сделать ее полную резервную копию. Параметр меняется при переходе бд из невосстановимого состояния в восстановимое, т.е. были изменены logarchmeth1 или logretain или userexit .
Если бд переходит к циклическому типу записи (logretain или userexit  выключены, logarchmeth1(2) = OFF), повтор транзакций для базы данных становится невозможным, поскольку журналы для нее более не сохраняются. В этом случае менеджер баз данных удаляет все журналы в каталоге logpath (включая и оперативные файлы архивных журналов), выделяет новые файлы активных журналов и возвращается к циклической записи.
log_retain_status - индикатор состояния хранения журналов указывает, что файлы журналов сохраняются на случай восстановления путем повтора транзакций.  Этот параметр задается, когда значение параметра logretain равно Recovery.

Список параметров (для 9.5)
    * ARCHRETRYDELAY
    * BLK_LOG_DSK_FUL
    * FAILARCHPATH
    * LOGARCHOPT1
    * LOGARCHOPT2
    * LOGBUFSZ
    * LOGFILSIZ
    * LOGPRIMARY
    * LOGRETAIN
    * LOGSECOND
    * MAX_LOG
    * MIRRORLOGPATH
    * NEWLOGPATH
    * MINCOMMIT
    * NUMARCHRETRY
    * NUM_LOG_SPAN
    * OVERFLOWLOGPATH
    * USEREXIT