Модели восстановления в DB2
К типам восстановления, которые можно использовать в базах геоданных на DB2, относится восстановлении версии, которое использует цикличное журналирование; восстановление с повтором транзакций, которое использует архивное журналирование; или восстановление с высокой отказоустойчивостью (HADR).
Примечание:Убедитесь, что вы восстановили все базы данных, которые образуют базу геоданных ArcSDE, при восстановлении базы геоданных ArcSDE for DB2 для z/OS.
- Восстановление версии и цикличное журналирование
Цикличное журналирование использует кольцо журналов для записи изменений в базе данных. Когда последний журнал кольца заполняется, снова используется первый. Поскольку информация о транзакциях может быть перезаписана, при использовании цикличного журналирования, восстановление с повтором транзакций невозможно; однако восстановление обычно не требуется во время загрузки данных. Цикличное журналирование – это модель журналирования, использующаяся по умолчанию.
- Восстановление с повтором транзакций и архивное журналирование
Если вы хотите использовать восстановление с повтором транзакций, с базами геоданных ArcSDE рекомендуется применять архивное журналирование. Архивное журналирование не перезаписывает файлы журналов; вместо этого создаются дополнительные журналы для записи всех транзакций с момента последнего архивирования. Для архивного журналирования требуется больше дискового пространства, поскольку журналы не используются повторно, как при цикличном журналировании.
- HADR
Восстановление с высокой отказоустойчивостью – это функция репликации базы данных, доступная в DB2 для защиты данных с помощью репликации изменений данных из исходной (первичной) базы данных в целевую (дежурную). Если первичная база данных останавливается, можно переключиться к дежурной на время восстановления первичной.
Для HADR можно выбрать один из трех режимов синхронизации: синхронный, полусинхронный или асинхронный.
В синхронном режиме, изменения, внесенные в первичную базу данных, не записываются в нее, пока связанные журналы не будут записаны в журналы транзакций дежурной базы данных. Это позволяет синхронизировать две базы данных, поскольку никакие изменения не записываются в первичную базу, пока они не сохранены в файле журнала дежурной базы данных (и, следовательно, не стали доступными для восстановления). Этот режим оказывает наибольшее влияние на производительность первичной базы данных.
В полусинхронном режиме, изменения, внесенные в первичную базу данных, не записываются в нее, пока связанные журналы не будут записаны в память дежурной базы данных. Это почти так же эффективно, как и синхронный режим, и оказывает меньшее влияние на первичную базу данных. Однако если произойдет сбой дежурной базы данных после закрепления данных в первичной, передаваемые данные могут быть потеряны и две базы более не будут одинаковыми.
Транзакции COMMIT к первичной базе данных не затрагиваются передачей записей журнала а дежурную базу данных. В этом режиме вероятность расхождения данных между двумя базами выше. Имеются и другие способы репликации, которые могут использоваться в DB2, включая репликацию SQL и репликацию Q. Обратитесь к документации по DB2 для получения более подробной информации.
Для восстановления базы геоданных, можно использовать команду RECOVER DATABASE или мастер восстановления данных из DB2 Control Center. Базу геоданных можно восстановить в существующую базу данных или в новую. Следующие замечания относятся к восстановлению данных в новую базу данных:
- Если вы восстанавливаете данные в новую базу, необходимо подключиться к экземпляру.
- Если вы восстанавливаете данные в новую базу на другом сервере, а исходный и конечный серверы не используют страницу кодировки по умолчанию, необходимо создать базу данных на целевой машине с корректной кодовой страницей до восстановления данных. Если вы не выполните это действие, а ваша рабочая кодовая страница отличается от исходной, то утилита восстановления примет кодовую страницу по умолчанию. Это приведет к ошибке SQL2548N.
- Если вы восстанавливаете данные в новую базу, файл истории восстановлений из архивного образа станет файлом истории восстановлений новой базы данных.
Когда вы выполняете полное восстановление базы данных, к ней не должно быть подключений, кроме того, которое было создано после восстановления базы данных. Кода восстанавливается полный архив базы данных, DB2 проверяет, что все табличные пространства, указанные в архивном образе, присутствуют в базе данных, в которую восстанавливаются данные. (Это может быть существующая или новая, пустая база данных.) Если обнаружено, что табличное пространство отсутствует или недоступно, операция восстановления выдает ошибку.
Чтобы избежать этой ситуации, можно выполнить операцию переадресации восстановления. Это позволяет задать новые табличные пространства, отсутствующие в целевой базе данных, в которые можно восстановить табличные пространства из архивного образа. Подробнее о переадресации восстановления см. в документации по DB2.
Если вы восстанавливаете только отдельные табличные пространства, база данных может оставаться подключенной, если пользователи не будут подключаться к восстанавливаемым табличным пространствам.
Подсказка
- Можно автоматизировать архивацию и извлечение файлов журналов по выходу пользователя из программы. Для этого необходимо задать параметр конфигурации logarchmeth1 для USEREXIT.
Подробнее о разработке и использовании программы выхода пользователя см. в документации по DB2.
- Если используется разделенная база данных, необходимо запустить команду RECOVER DATABASE из раздела каталога. Когда вы восстанавливаете разделенную базу данных по состоянию на определенную дату, затрагиваются все разделы, указанные в файле db2nodes.cfg. Когда вы восстанавливаете данные по последним записям в журналах, можно выбрать разделы для восстановления. Если определенные разделы не заданы, будут восстановлены все разделы, указанные в файле db2nodes.cfg.