27_SH43-0144-00 (1038594), страница 80
Текст из файла (страница 80)
Затем можно запустить команду RESTORE и использоватьметод восстановления с повтором транзакций до необходимого моментавремени. Если какие-нибудь из необходимых файлов будут повреждены илиутеряны во время этого процесса, у вас есть резервная копия всех файловжурнала в другом месте.Информация файла хронологии восстановленияФайл хронологии восстановления создается с каждой из баз данных иавтоматически обновляется всякий раз при:v Резервном копировании базы данных или табличного пространстваv Восстановлении из резервной копии базы данных или табличногопространства|vvvvvПовторе транзакций для базы данных или табличного пространстваИзменении табличного пространстваСтабилизации табличного пространстваПереименовании табличного пространстваЗагрузке таблицыv Отбрасывании таблицыv Реорганизации таблицыv Обновлении статистики таблицы.Рисунок 14.
Создание и обновление файла хронологии восстановленияГлава 8. Восстановление базы данных373|||Сводную информацию о резервном копировании в этом файле можноиспользовать для восстановления всей или части базы данных до определенногомомента времени. Информация в файле включает в себя:|||v Поле идентификации (ID), связанной с каждой из записей для ее уникальнойидентификацииv Какая часть базы данных была скопирована и как|||v Время снятия копииv Положение копии (информация об устройстве и логическом пути доступа ккопии)|||v Время последнего восстановления из резервной копииv Время переименования табличного пространства с показом его предыдущегои текущего имени|||||v Состояние резервной копии: активная, неактивная, с истекшим срокомдействия или удаленнаяv Последний номер последовательности файлов журналов, сохраненный прирезервном копировании базы данных или обработке восстановления сповтором транзакций.|||Чтобы посмотреть записи в файле хронологии восстановления, используйтекоманду LIST HISTORY.
Дополнительную информацию об этой командесмотрите в руководстве Command Reference.||||||Примечание: Когда восстановление из резервной копии и повтор транзакцийвыполняются до конца файлов журнала, ID резервной копии,показанный после команды LIST HISTORY, указывает предельноевозможное время. Это значит, что значение ID резервной копии 99991231235959. ID резервной копии трансформируется такимобразом только после выполнения повтора транзакций.|Каждая операция резервного копирования (как табличного пространства, так ицелой базы данных) включает в себя копию файла хронологии восстановления.Этот файл хронологии восстановления связывается с базой данных.Отбрасывание базы данных удаляет файл хронологии восстановления.Восстановление базы данных в новом положении восстанавливает файлхронологии восстановления.
Восстановление не переписывает существующийфайл хронологии восстановления.Если текущая база данных непригодна к использованию или недоступна, асвязанный с ней файл хронологии восстановления поврежден или удален, опциякоманды RESTORE позволяет восстановить только файл хронологиивосстановления. Затем этот файл хронологии восстановления можно будетпросмотреть, чтобы получить информацию о том, какую резервную копиюиспользовать для восстановления базы данных.374Руководство администратора: РеализацияРазмером этого файла управляет параметр конфигурации rec_his_retentn,указывающий время хранения (в днях) записей в файле.
Даже если для этогопараметра установлен нуль (0), сохраняется самая свежая резервная копия базыданных и ее набор восстановления. (Эту копию можно удалить только путемиспользования PRUNE с опцией FORCE.) Период хранения по умолчанию - 366дней. Можно задать неопределенное число дней хранения, указав значение -1. Вэтом случае сокращение файла надо выполнять явно. Дополнительнуюинформацию об этом параметре конфигурации смотрите в книге Руководствоадминистратора: Производительность.Для файла хронологии восстановления можно делать запросы и выполнятьразличные команды, используя вызов функций API, процессор команднойстроки или Центр управления. Пять основных запросов и команд - это OPEN,CLOSE, GET NEXT, UPDATE и PRUNE. (Дополнительную информацию осинтаксисе этих команд смотрите в книге Command Reference.
Дополнительнуюинформацию о вызове функций API смотрите в книге Administrative APIReference. Для получения дополнительной информации о Центре управлениявызовите его с вашей рабочей станции.)Подробная информация о файле хронологии записана в структуре SQLUHINFO.Дополнительную информацию об этой структуре смотрите в книгеAdministrative API Reference.Чистка мусораЗа числом резервных копий баз данных DB2, документированных в файлехронологии восстановления автоматически следит функция под названием“чистка мусора DB2”. Число сохраняемых ″активных″ резервных копийопределяет параметр конфигурации num_db_backups.
Активная резервная копия- та, при помощи которой можно восстановить текущее состояние базы данных,используя текущие файлы журнала для повтора транзакций. ″Неактивную″резервную копия нельзя использовать для подобного восстановления, посколькудля нее требуется другой набор файлов журнала.В каждом из примеров, показанных на следующем рисунке, предполагается, чтодля num_db_backups было задано значение 4.Глава 8. Восстановление базы данных375Рисунок 15. Активные резервные копии базы данныхВсе уже не нужные резервные копии базы данных помечаются как копии “систекшим сроком”. Эти резервные копии рассматриваются как уже не нужные,поскольку есть несколько более свежих копий, как определено num_db_backups.Все резервные копии табличных пространств и резервные копии загрузки,сделанные до истечения срока годности резервной копии базы данных, такжепомечаются как копии “с истекшим сроком”.Рисунок 16.
Резервные копии базы данных с истекшим сроком годностиВсе резервные копии базы данных, помеченные как “неактивные” и сделанныераньше момента снятия резервной копии с истекшим сроком годности, такжепомечаются как копии “с истекшим сроком”. Все связанные “неактивные”резервные копии табличных пространств и резервные копии загрузки такжепомечаются как копии “с истекшим сроком”.|||||Если в резервном копировании участвуют столбцы DATALINK, как описано вследующем разделе, для запроса чистки мусора связанных файлов серверасвязей данных, связь с которыми потеряна до времени снятия резервной копии систекшим сроком, производится обращение ко всем серверам связей данных, накоторых запущен DB2 Data Links Manager.
После физического удаления этихрезервных копий на основе информации, содержавшейся в файле хронологии,можно использовать команду PRUNE HISTORY для удаления из файлахронологии записей “с истекшим сроком”. Если не укоротить файл хронологииявным образом, следующее резервное копирование базы данных приведет кавтоматическому удалению записей “с истекшим сроком”.376Руководство администратора: РеализацияЧистка мусора DB2 помечает также записи файла хронологии для резервнойкопии базы данных DB2 или табличного пространства как “неактивные”, еслиэта резервная копия не соответствует текущей последовательности файловжурнала. Текущая последовательность файлов журнала определяетсявосстановленной резервной копией базы данных DB2 и обработаннымифайлами журнала. После восстановления резервной копии базы данных всерезервные копии базы данных, сделанные после ее восстановления, становятся“неактивными”, поскольку восстановленная резервная копия начинает новуюцепочку файлов журнала.
Резервная копия табличного пространства становится“неактивной”, когда после ее восстановления, текущего состояния базы данныхDB2 нельзя достичь с использованием текущей последовательности файловжурнала. (Когда резервная копия базы данных DB2 или табличногопространства становится “неактивной”, чистка мусора DB2 уведомляет об этомвсе серверы связей данных, на которых запущен Менеджер связей данных DB2, исоответствующие наборов резервных копий файлов также помечаются как“неактивные” .)Рисунок 17.
Активные резервные копии базы данныхРисунок 18. Неактивные резервные копии базы данныхЧистка мусора DB2 вызывается после завершения резервного копирования базыданных DB2. Значение параметра конфигурации db2_num_backups используетсядля просмотра текущего файла хронологии, начиная с последней записи.Глава 8. Восстановление базы данных377Чистка мусора DB2 также вызывается после завершения восстановлениярезервной копии базы данных как с повтором транзакций, так и без него.Если восстановлена “активная”, но не самая последняя резервная копия базыданных, записанная в файле хронологии, все последующие резервные копиибазы данных, принадлежащие той же самой последовательности файловжурнала, помечаются как “неактивные”.Если восстановлена “неактивная” резервная копия базы данных, все неактивныерезервные копии базы данных, принадлежащие к текущей последовательностифайлов журнала, снова помечаются как “активные”.
Как и при восстановлении“активной” резервной копии базы данных, все активные резервные копии базыданных, больше не находящиеся на текущей последовательности файловжурнала, помечаются как “неактивные”.Если в выполняемой резервной копии участвуют столбцы DATALINK, чисткамусора DB2 свяжется со всеми серверами связей данных, на которых запущенDB2 Data Links Manager, чтобы внести такие же изменения статуса длясоответствующего набора резервных копий файлов на серверах связей данных.После каждого резервного копирования всей базы данных параметрконфигурации rec_his_retentn используется для удаления из файла хронологиизаписей “с истекшим сроком”. Все резервные копии “с истекшим сроком”удаляются.Если не используется опция WITH FORCE, команда PRUNE HISTORY можетбыть использована в любое время для удаления из файла хронологии толькорезервных копий, помеченных как копии “с истекшим сроком”. (Если удаленарезервная копия, не являющаяся копией “с истекшим сроком”, выполняетсяобращение ко всем серверам связей данных и запрашивается установка флагадля чистки мусора в соответствующем наборе резервных копий файлов.)378Руководство администратора: РеализацияРисунок 19.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
