27_SH43-0144-00 (1038594), страница 78
Текст из файла (страница 78)
В файл хронологии восстановления также помещается запись синформацией, которую можно использовать для повторного создания таблицы.Отброшенную таблицу можно восстановить так:||||1. Получите идентификацию отброшенной таблицы. Эта идентификация можетбыть получена из файла хронологии восстановления при помощи командыLIST HISTORY DROPPED TABLE. Будет показан список отброшенныхтаблиц и информация, необходимая для повторного их создания.||||Примечание: ID отброшенной таблицы приводится в выводе LIST HISTORYпод столбцом ID резервной копии.Дополнительную информацию об этой команде смотрите в руководствеCommand Reference.2. Восстановите резервную копию уровня базы данных или табличногопространства, сделанную до отбрасывания таблицы.||||||||3.
Повторите транзакции до определенного момента времени послеотбрасывания, используя опцию RECOVER DROPPED TABLE командыROLLFORWARD. Другая информация, необходимая при использовании этойопции, включает в себя идентификацию отброшенной таблицы и путь ккаталогу, в который будут записаны файлы вывода. Этот путь к каталогудолжен быть доступен для всех разделов базы данных или существовать накаждом из разделов. Дополнительную информацию об этой командесмотрите в руководстве Command Reference.4. Повторно создайте таблицу, используя оператор CREATE TABLE из файлахронологии восстановления.5.
Импортируйте в таблицу данные, экспортированные командойROLLFORWARD.Экспортированные данные записываются в файлы с использованиемследующего соглашения об именах: в каталоге_экспорта, указанномпользователем в команде ROLLFORWARD, создается подкаталог для каждогоГлава 8. Восстановление базы данных365раздела базы данных. Пользователь может создать подкаталоги передтребованием на повтор транзакций. Это можно использовать для экспортаданных на конкретный диск или компьютер. Имена этих подкаталогов имеютвид “NODEnnnn”, где nnnn - номер раздела базы данных или узла. В каждый изподкаталогов экспортируется файл данных под именем “data”. В каталогахданных данные отброшенной таблицы содержатся в том виде, в котором онисуществовали на каждом из разделов базы данных.На тип данных, восстановимых из отброшенной таблицы, существуютопределенные ограничения.
За один раз может быть восстановлена только однаотброшенная таблица. Для восстановления нескольких отброшенных таблицприведенная выше последовательность восстановления должна быть повторенадля каждой таблицы. Особенности восстановления:v Нельзя восстановить данные типа большой объект или LONG. ОпцияDROPPED TABLE RECOVERY не поддерживается для табличныхпространств с типом LONG. Попытки использования табличногопространства с типом LONG приведут к возвращению ошибки SQL628N. Припопытке восстановить отброшенную таблицу, содержащую столбцы типабольшой объект или LONG VARCHAR, в сгенерированном файле экспортадля них будет установлено пустое значение. Опция DROPPED TABLERECOVERY может иметь значение “ON” только для табличных пространствтипа REGULAR, но не TEMPORARY или LONG.v Могут быть восстановлены имена связанных файлов, связанных со столбцамиDATALINK. После импорта данных таблица должна быть синхронизированапри помощи Менеджера связей DB2.
Возможность резервного восстановлениярезервных копий файлов Менеджером связей DB2 зависит от того, успели лиих удалить при чистке мусора.v Нельзя восстановить метаинформацию, связанную с типами строк.(Восстанавливаются данные, но не метаданные.) Будут восстановлены данныев таблице иерархии типизированной таблицы. Данные могут содержатьбольше информации, чем было в отброшенной типизированной таблице.Особенности файлов журналаПри работе с файлами журнала базы данных надо учитывать следующее:v Нумерация архивированных файлов журнала начинается с S0000000.LOG изаканчивается на S9999999.LOG (10000000 файлов). Менеджер баз данныхначинает отсчет с S0000000.LOG при следующих условиях:– Когда файл конфигурации базы данных изменен, чтобы разрешитьфункцию повтора транзакций.– Когда файл конфигурации базы данных изменен, чтобы отключитьфункцию повтора транзакций.– При начале нового цикла файлов журнала; то есть когда использован файлS9999999.LOG.366Руководство администратора: РеализацияКогда метод восстановления с повтором транзакций заканчивается успешно,последний файл журнала, использованный для повтора транзакций, усекается,и запись в журнал начинается со следующего последовательного номера.
Напрактике это означает, что повторно используются все файлы журнала вкаталоге журнала с последовательным номером, большим, чем у последнегофайла, использованного для восстановления с повтором транзакций.Убедитесь, что вы сделали копию файлов журнала до выполнения командыROLLFORWARD. (Для копирования файлов журнала в другое положениеможно использовать программу обработчика пользователя.)Разные файлы журнала могут иметь дублирующие имена потому, что:– Менеджер баз данных начинает переименовывать файлы журнала сS0000000.LOG (как описано выше).– Менеджер баз данных повторно использует имена файлов журнала послевосстановления базы данных (как с повтором транзакций, так и без).Менеджер баз данных подразумевает, что неправильный файл журнала неучаствует в восстановлении с повтором транзакций, но он не можетопределить положение необходимого файла журнала.
Вам необходимопроверить, что для восстановления с повтором транзакций доступныправильные файлы журнала.v Если вы переместили файлы журнала в положение, отличное от указанногопараметром конфигурации базы данных logpath, используйте для указаниядополнительного пути к ним параметр OVERFLOW LOG PATH командыROLLFORWARD.Если при повторе транзакций для базы данных или табличного пространстваэта операция не может найти следующий файл журнала, имя ненайденногофайла возвращается в SQLCA, а восстановление с повтором транзакцийостанавливается. Если больше нет доступных файлов журнала, дляпрекращения обработки в этом случае можно воспользоваться командойROLLFORWARD.Если вы прерываете восстановление с повтором транзакций (указав опциюSTOP в команде ROLLFORWARD) и к базе данных или к табличномупространству не был применен файл журнала, содержащий завершениетранзакции, для незавершенной транзакции будет выполнен откат длягарантии согласованности базы данных или табличного пространства.vАрхивные файлы журнала размещаются в соответствии с путем к журналу.По умолчанию путь к журналу - подкаталог SQLOGDIR; это можно изменитьпри помощи параметра конфигурации newlogpath.
Чтобы поместить архивныефайлы в другое положение, включите для базы данных обработчикпользователя или измените путь к журналу при помощи параметраnewlogpath. В таком случае может потребоваться использовать параметрOVERFLOW LOG PATH команды ROLLFORWARD, чтобы указать на них приповторе транзакций.Глава 8. Восстановление базы данных367v При включении обработчика пользователя путем изменения файлаконфигурации базы данных архивные файлы журнала могут бытьперенаправлены на указанное пользователем устройство хранения, например,на ленточное устройство. Для управления хранением архивных файловжурнала можно также использовать программу обработчика пользователя.Информацию о программе обработчика пользователя смотрите в разделе“Приложение C.
Обработчик пользователя для восстановления баз данных”на стр. 441.v Изменение параметра newlogpath не затрагивает существующие архивныефайлы журнала. Необходимо следить за расположением архивных файлов.v Если база данных, в которой разрешено восстановление с повторомтранзакций, восстановлена либо без повтора транзакций, либо только доопределенного момента времени, один из архивных файлов журнала можетбыть связан с двумя или более последовательностями архивных файлов базыданных из-за повторного использования имен файлов журнала. (Примерсоздаваемых файлов журнала показан в разделе рис.
13. Если вы невыполняете восстановление с использованием “Резервной копии 2”, особоевнимание следует обратить на то, что можно использовать двепоследовательности файлов журнала.) Перед тем как отбрасывать архивныйфайл журнала, убедитесь, что он вам не понадобится.Рисунок 13. Повторное использование имен файлов журналаv Если при восстановлении всей базы данных был произведен повтортранзакций до определенного момента времени с остановкой в некоторомпромежуточном месте файлов журнала, создается новая последовательностьфайлов журнала. Эти две последовательности файлов журнала нельзяобъединять.
Если у вас есть резервная копия, сделанная без отключения,которая затрагивает первую последовательность файлов журнала, именно этупоследовательность и надо использовать при выполнении восстановления сповтором транзакций.v Если после восстановления вы создали новую последовательность файловжурнала, все резервные копии табличных пространств, сделанные в старойпоследовательности, становятся недействительными. В этом случае368Руководство администратора: Реализациявосстановление отбрасывает резервные копии табличных пространств. Вотдельных экземплярах восстановление, возможно, не сможет распознать, чтотакая резервная копия недействительна (особенно для резервных копий,сделанных без отключения), и восстановление будет успешным. Однакоповтор транзакций для табличного пространства не удастся, и табличноепространство останется в состоянии ожидания повтора транзакций.На приведенной выше диаграмме предположим, что снятие резервной копии 3завершилось между S0000013.LOG и S0000014.LOG в верхнейпоследовательности файлов журнала.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
