27_SH43-0144-00 (1038594), страница 74
Текст из файла (страница 74)
Для управления этим поведениемможно во время восстановления из резервной копии указать, хотите ли вы,чтобы ROLLFORWARD повторно создавала контейнеры во времявосстановления с повтором транзакций. (Можно отредактировать списокконтейнеров табличных пространств в окне Контейнеры - Изменитьзаписной книжки Восстановить базу данных или Восстановить табличноепространство в Центре управления.)Повтор транзакций для изменений в базе данных|Восстановление с повтором транзакций выполняет построение восстановленнойиз резервной копии базы данных и позволяет привести базу данных в состояние,в котором она находилась на определенный момент времени после снятия с неерезервной копии. Это может быть либо время окончания файлов журнала, либовремя между резервным копированием и концом файлов журнала.||||||Примечание: Когда восстановление из резервной копии и повтор транзакцийвыполняются до конца файлов журнала, ID резервной копии,показанный после команды LIST HISTORY, указывает предельноевозможное время.
Это значит, что значение ID резервной копии 99991231235959. ID резервной копии трансформируется такимобразом только после выполнения повтора транзакций.|||||||||Восстановление до определенного момента времени можно использовать, еслинедоступен активный или архивированный журнал. В этом случае можновыполнить повтор транзакций до момента времени, после которого журналнедоступен. Повтор транзакций до определенного момента времени можнотакже произвести в случае ошибочной транзакции в отношении базы данных. Втакой ситуации необходимо восстановить базу данных из резервной копии, азатем повторить транзакции до времени непосредственно перед ошибочнойтранзакцией.Глава 8.
Восстановление базы данных347Рисунок 10. Восстановление с повтором транзакцийМожно также выполнить восстановление с повтором транзакций доопределенного момента времени для табличных пространств. Более подробнуюинформацию смотрите в разделе “Повтор транзакций для изменений втабличном пространстве” на стр. 353.|Для использования этого метода база данных должна быть сконфигурированатак, чтобы было разрешено восстановление с повтором транзакций.Особенности файла конфигурации и файлах журнала базы данных изложены вследующих разделах:vvvvvПараметры конфигурации для записи в журнал базы данныхПовтор транзакций для изменений в табличном пространствеПланирование использования команды ROLLFORWARDВызов команды ROLLFORWARDИспользование файла положения копии загрузкиv Особенности файлов журналаv Потеря файлов журнала.Если у вас есть таблицы, содержащие столбцы DATALINK, смотрите такжераздел “Восстановление баз данных и табличных пространств и повтортранзакций до конца файлов журнала” на стр.
384 и “Восстановление баз данныхи табличных пространств и повтор транзакций до определенного моментавремени” на стр. 385.Параметры конфигурации для записи в журнал базы данныхВ файле конфигурации базы данных содержатся параметры, относящиеся квосстановлению с повтором транзакций. Параметры по умолчанию неподдерживают такое восстановление, поэтому, если вы планируете егоиспользование, некоторые из этих параметров необходимо изменить.Дополнительную информацию о конфигурировании DB2 UDB смотрите в книгеРуководство администратора: Производительность.348Руководство администратора: РеализацияПервичные файлы журнала (logprimary)Этот параметр показывает число создаваемых первичных файловжурнала.Для первичного файла журнала вне зависимости от его заполненноститребуется одно и то же дисковое пространство.
Поэтому, еслисконфигурировать больше файлов журнала, чем необходимо, дисковоепространство будет использоваться непроизводительно. Еслисконфигурировать слишком мало файлов журнала, можно столкнуться ссостоянием заполненности журнала. При выборе числаконфигурируемых файлов журнала следует учитывать, какой размер вызадаете для каждого из файлов, и может ли ваша прикладнаяпрограмма обрабатывать состояние заполнения журнала.Если вы включаете восстановление с повтором транзакций длясуществующей базы данных, замените число первичных файлов журналана сумму числа первичных и вторичных файлов плюс 1.
В базе данных,для которой разрешено восстановление с повтором транзакций, вжурнал записывается дополнительная информация для полей longvarchar и LOB.||||Общее ограничение на размер файлов журнала составляет 32 Гбайт. Этозначит, что число файлов журнала (LOGPRIMARY + LOGSECOND),умноженное на размер каждого из этих файлов в байтах (LOGFILSIZ *4096), должно быть меньше 32 Гбайт.Дополнительную информацию об этом параметре конфигурациисмотрите в книге Руководство администратора: Производительность.Вторичные файлы журнала (logsecond)Этот параметр задает число вторичных файлов журнала, которыесоздаются и используются для файлов журнала восстановления (толькопри необходимости).Когда первичные файлы журнала заполняются, по мере необходимостипо одному выделяются вторичные файлы журнала (с размером,указанным logfilsiz) вплоть до максимального числа, задаваемого этимпараметром.
Если вторичных файлов журнала требуется больше, чемразрешено этим параметром, прикладной программе будет возвращенаошибка, и всякая активность для этой базы данных прекратится.Дополнительную информацию об этом параметре конфигурациисмотрите в книге Руководство администратора: Производительность.|Размер журнала (logfilsiz)Этот параметр определяет число страниц для каждого изсконфигурированных файлов журнала. Размер одной страницы - 4Кбайт.Глава 8.
Восстановление базы данных349||Примечание: Общее ограничение на размер журнала - 32 Гбайт (то есть(logfilsiz + logprimary) x logfilsiz < 32 Гбайт/4096).|Размер первичных файлов файлов журнала непосредственно влияет напроизводительность. Когда база данных сконфигурирована длясохранения файлов журнала, при заполнении одного из файлов выдаетсятребование на размещение и инициализацию нового файла. Увеличениеразмера файла журнала уменьшает число запросов на выделение иинициализацию новых файлов журнала.
(Однако не забывайте, что прибольшом размере файлов журнала требуется больше времени наформатирование новых файлов). Форматирование новых файловжурнала прозрачно для прикладных программ, связанных с базойданных, поэтому на производительность базы данных не влияет.Предположим, что у вас есть прикладная программа, поддерживающаябазу данных в открытом состоянии для сокращения расходовпроцессорного времени на ее открытие; тогда значение размера файлажурнала должно определяться количеством времени, необходимого дляавтономного снятия копий архивированных файлов журнала.Скорость передачи данных устройства, используемого для храненияавтономных архивированных файлов журнала, и программногообеспечения, используемого для изготовления копий, должны, какминимум, равняться средней скорости записи данных в файлы журналаменеджером баз данных.
Если эта скорость передачи меньше скоростигенерирования новых данных журнала, при достаточнопродолжительном времени записи в журнал, определяемом количествомсвободного места на диске, диск может полностью заполниться. В этомслучае обработка базы данных остановится.Особенно критична скорость передачи данных при использованиимагнитной ленты и некоторых оптических носителей. (Информацию обиспользовании различных носителей для хранения файлов журналасмотрите в разделе “Приложение C.
Обработчик пользователя длявосстановления баз данных” на стр. 441.) На некоторых ленточныхустройствах для записи файла любого размера требуется одинаковоевремя. Необходимо знать производительность архивирующегоустройства.Ленточные устройства обладают и другими уникальными свойствами.Важна частота требований на архивирование. Если время для любойоперации копирования равно пяти минутам, размера файла журналадолжно хватать на то, чтобы вместить данные за пять минут работыпри пиковой нагрузке. Кроме всего прочего, у ленточного устройства350Руководство администратора: Реализациямогут быть конструктивные ограничения на число операций в день. Всеэти факторы следует учитывать при определении размера файлажурнала.При определении размера файлов журнала также следует учитыватьснижение потерь этих файлов.
Файл журнала архивируется целиком.При использовании одного большого файла журнала увеличиваетсявремя между архивированиями. При ошибке носителя, на которомнаходятся файлы журнала, информация о некоторых транзакциях,возможно, будет утеряна. Уменьшение размера файла журналаувеличивает частоту архивирования, но может уменьшить потериинформации при ошибках носителя, поскольку можно будетиспользовать маленькие файлы журнала, предшествующие утерянному.Буфер журнала (logbufsz)Этот параметр позволяет указывать величину совместно используемойпамяти базы данных, отводимой под буфер записей журнала до ихпомещения на диск.
Записи журнала записываются на диск в следующихслучаях:v Принимается транзакцияv Заполняется буфер журналаv Происходит некоторое другое внутреннее событие менеджера базданных.Буферизация записей журнала приводит к увеличению эффективностиввода/вывода файлов журнала, поскольку записи журнала записываютсяна диск реже и за один раз на диск записывается больше записей.Число принятий для группировки (mincommit)Этот параметр позволяет откладывать помещение записей журнала надиск до выполнения минимального числа принятий.
Такая отложеннаязапись может помочь уменьшить излишнюю нагрузку на менеджер базданных, связанную с записью в журнал, и таким образом улучшитьпроизводительность, когда несколько прикладных программ требуютмного принятий за очень короткий отрезок времени.Такая группировка принятий будет происходить только тогда, когдазначение этого параметра больше 1 и число связанных с базой данныхприкладных программ больше значения этого параметра.
Пригруппировке принятий выполнение требований прикладных программна принятия откладывается либо до истечения одной секунды, либо дотого времени, когда число требований на принятие сравняется созначением этого параметра (если это произойдет раньше).Новый путь к журналу (newlogpath)Файлы журнала базы данных изначально создаются в подкаталогеSQLOGDIR каталога, в котором расположена база данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
