Восстановление данных и высокая доступность

Обзор резервного копирования

Обратите внимание на следующие ограничения:

Запуск оперативного резервного копирования табличного пространства DMS допускается, когда таблица в этом же табличном пространстве реорганизуется в оперативном режиме. На стадии усечения для операции реорганизации может иметь место ожидание блокировок.
Запуск оперативного резервного копирования табличного пространства SMS не допускается, когда таблица в этом же табличном пространстве реорганизуется в оперативном режиме. Обе операции требуют монопольной блокировки.

Использование резервного копирования

Для утилиты резервного копирования действуют следующие ограничения:

Операция резервного копирования табличного пространства и операция восстановления табличного пространства не могут выполняться одновременно, даже если табличные пространства разные.
Для возможности восстановления базы данных с повтором транзакций в среде многораздельных баз данных нужно регулярно выполнять резервное копирование базы данных по списку узлов и у вас должен быть как минимум один образ резервной копии для остальной части узлов в системе (даже для узлов, не содержащих пользовательских данных для этой базы данных). Образ резервной копии раздела базы данных на сервере раздела базы данных, не содержащем для этой базы данных пользовательских данных, требуется в двух ситуациях:
- Если после последнего резервного копирования в систему базы данных был добавлен сервер раздела базы данных, и на нем требуется выполнить восстановление с повтором транзакций.
- Если используется восстановление до заданного момента времени, которое требует, чтобы все разделы базы данных в системе находились в состоянии отложенного повтора транзакций.
- Операции оперативного резервного копирования для табличных пространств DMS несовместимы со следующими операциями:
  - загрузка
  - реорганизация (только в автономном режиме); в копируемом табличном пространстве может использоваться оперативная реорганизация таблицы, хотя на стадии усечения для операции реорганизации могут существовать ожидания блокировок.
  - отбрасывание табличного пространства
  - усечение таблицы
  - создание индекса
  - операции CREATE TABLE и ALTER TABLE с опцией NOT LOGGED INITIALLY

Обзор высокой доступности - восстановления после аварий (High availability disaster recovery, HADR)

При выполнении команд START HADR, STOP HADR или TAKEOVER HADR могут генерироваться соответствующие коды ошибки: SQL01767N, SQL01769N или SQL01770N с кодом причины 98. Этот код причины указывает, что на сервере, на котором запущена эта команда, не установлена лицензия для HADR. Чтобы исправить эту проблему, установите действительную лицензию HADR при помощи команды db2licm или же установите версию сервера, в дистрибутив которой входит действительную лицензия HADR.

Поддержка межплатформенного резервного копирования и восстановления

DB2 Universal Database (UDB) поддерживает операции межплатформенного резервного копирования и восстановления.

Базы данных, созданные в DB2 UDB Версии 8 на платформе 32-битной Windows можно восстанавливать в DB2 UDB Версии 8 на платформе 64-битной Windows, и наоборот.

Базы данных, созданные в DB2 UDB Версии 8 на платформе 32-битной Linux x86, можно восстанавливать в DB2 UDB Версии 8 на платформе 64-битной Linux x86-64 или IA64, и наоборот.

Базы данных, созданные в DB2 UDB Версии 8 на платформах AIX, HP-UX, Linux PPC, Linux zSeries или операционной среды Solaris в 32-битной или 64-битной версии, можно восстанавливать в DB2 UDB Версии 8 на платформах AIX, HP-UX, Linux PPC, Linux zSeries или операционной среды Solaris (32-битной или 64-битной).

Резервное копирование на ленту (Linux)

Максимальный размер блока для ленточных устройств 3480 и 3490 ограничен в Linux 61440 байтами

Табл. 33. Ограничение максимального размера блока для ленточных устройств 3480 и 3490 в Linux
Устройство	Подсоединение	Максимальный размер блока	Ограничение размера буфера DB2 (в страницах по 4 Кбайта)
3480	s370	61440	15
3490	s370	61440	15

Tivoli Storage Manager

При вызове команды BACKUP DATABASE или RESTORE DATABASE можно указать, что для управления операциями резервного копирования и восстановления базы данных и табличного пространства должен применяться продукт Tivoli Storage Manager (TSM). Версия API клиента TSM должна быть не ниже 4.2.0, кроме следующих случаев:

64-битные системы Solaris, в которых необходим API клиента TSM версии 4.2.1.
64-битные системы Windows NT, в которых необходим API клиента TSM версии 5.1.
32-битные системы Linux для iSeries и pSeries, для которых минимальная версия API клиента TSM - 5.1.5
64-битные системы Linux для iSeries и pSeries, для которых минимальная версия API клиента TSM - 5.3
64-битные системы Linux на AMD Opteron, для которых минимальная версия API клиента TSM - 5.2.0.
64-битные системы Linux для zSeries, для которых минимальная версия API клиента TSM - 5.2.2.

Ограничения на значения параметров локального хоста и локальной службы HADR

Порты HADR_LOCAL_SVC и HADR_REMOTE_SVC (параметры локального хоста и локальной службы HADR, задаваемые при подготовке команды update database configuration) не должны использоваться другими службами. Если параметры конфигурируются из командной строки Linux или UNIX, необходимо задать те же значения в файле /etc/services.

Дополнительные требования к системе для HADR

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

Чтобы убедиться в отсутствии ошибок воспроизведения по журналу, при создании новых табличных пространств надо следить за журналом db2diag.log и журналом администратора на резервной базе данных.

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

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

db2 connect to my_database
db2 list tablespaces show detail
Прим.:

Выполните команду db2 list tablespaces show detail, чтобы вывести состояние всех табличных пространств и получить номер ID табличного пространства, необходимый на шаге 5.
db2 stop hadr on database my_database
db2 "restore database my_database tablespace (my_tablespace) online redirect"
db2 "set tablespace containers for my_tablespace_ID_# ignore rollforward container operations using (path '/my_new_container_path/')"
db2 "restore database my_database continue"
db2 rollforward database my_database to end of logs and stop tablespace "(my_tablespace)"
db2 start hadr on database my_database as primary

Нереплицируемые операции для HADR

В документации Версии 8.2 утверждается:

Объекты типов BLOB и CLOB; однако пространство для таких объектов будет выделено в резервной базе данных.

Следует читать:

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

HADR не поддерживает журналы на непосредственных устройствах

HADR не поддерживает использование прямого ввода-вывода (прямой доступ к дискам) для файлов журналов базы данных. В случае обнаружения журналов на непосредственных устройствах при запуске HADR командой START HADR или путем перезапуска базы данных после конфигурирования HADR соответствующая команда завершится неудачно с сообщением SQL1768N, код причины "9".

| | |

Сравнение монитора ошибок и монитора работоспособности

Монитор работоспособности и монитор ошибок - инструменты, работающие с одним экземпляром базы данных. Монитор работоспособности при помощи индикаторов |работоспособности оценивает работоспособность по определенным аспектам |производительности менеджера баз данных или производительности баз данных. Индикатор работоспособности измеряет работоспособность по некоторому аспекту |определенного класса объектов базы данных, например, табличных пространств. Для определения работоспособности данного класса объектов базы данных можно |оценивать индикаторы работоспособности по определенным критериям. Кроме того, индикаторы работоспособности могут генерировать оповещения, |уведомляющие вас, если индикатор превысит пороговое значение или укажет, что |объект базы данных находится в ненормальном состоянии.

В отличие от монитора работоспособности, монитор ошибок отвечает только за |поддержку работы экземпляра, за которым он наблюдает. В случае неожиданного прерывания работы наблюдаемого экземпляра DB2 UDB монитор ошибок перезапускает этот экземпляр. Монитор ошибок недоступен в Windows.

| | |

Отключение монитора ошибок

Чтобы отключить монитор ошибок для экземпляра базы данных DB2INST1, введите в окне команд DB2 UDB команду:

   db2fm -i db2inst1 -f no

| |

Прим.:

Если файл реестра монитора ошибок не существует, применяются значения по умолчанию.

В системах UNIX, чтобы убедиться, что монитор ошибок для DB2INST1 больше не работает, введите команду:

   ps -ef|grep -i fm

В системах Linux введите команду:

   ps auxw|grep -i fm

Если вы увидите строку, содержащую слова db2fmd и DB2INST1, это значит, что |для этого экземпляра монитор ошибок все еще работает. Чтобы выключить монитор ошибок, введите от имени владельца экземпляра команду:

   db2fm -i db2inst1 -D

[ Начало страницы |Страница назад | Страница вперед | Содержание ]