Замечания по выпуску


7.6 Глава 8. Восстановление базы данных

7.6.1 Как использовать приостановленный ввод-вывод

В главу 8 "Восстановление базы данных" надо добавить следующий новый раздел по использованию функции приостановленного ввода/вывода:
Прим.:Приведенная далее информация об утилите db2inidb перекрывает информацию в книге Что нового Версии 7.2.

С DB2 поставляется новый инструмент db2inidb, который позволяет выполнить восстановление после аварии и перевести базу данных в состояние отложенного повтора транзакций.

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

Варианты использования db2inidb зависят от способа зеркального копирования устройств хранения. В следующих вариантах использования предполагается, что вся база данных копируется зеркально, согласованно с системой хранения.

В многоузловой среде, прежде чем можно будет использовать отделенный образ на любом из разделов, нужно запустить инструмент db2inidb на каждом разделе. Инструмент db2inidb можно запустить на всех разделах одновременно.

  1. Создание клона базы данных

    Цель этой операции - создание копии исходной базы данных, используемой только для чтения. Следующие процедуры описывают, как получить клон базы данных:

    1. Приостановите ввод-вывод в исходной системе, введя следующую команду:
           db2 set write suspend for database
      
    2. Воспользуйтесь командой уровня операционной системы, чтобы отделить зеркальную копию от исходной базы данных.
    3. Возобновите ввод-вывод в исходной системе, введя следующую команду:
           db2 set write resume for database
      

      После выполнения этой команды база данных в исходной системе должна вернуться в обычное состояние.

    4. Подключитесь к зеркальной копии базы данных с другого компьютера.
    5. Запустите этот экземпляр базы данных, введя команду:
           db2start
      
    6. Запустите восстановление после аварии DB2, введя следующую команду:
      db2inidb имя_базы_данных AS SNAPSHOT
      
      Прим.:Эта команда выполнит откат изменений, внесенных транзакциями, начатыми во время отделения зеркальной копии.

    Тот же процесс можно использовать для автономного резервного копирования, но если восстановление происходит в исходной системе, эту резервную копию нельзя будет использовать для повтора транзакций, поскольку последовательность файлов журнала ей не соответствует.

  2. Использование отделенной зеркальной копии в качестве резервной базы данных

    Так как для зеркальной (резервной) базы данных непрерывно выполняется повтор транзакций с использованием журналов, новые журналы, которые создаются в исходной базе данных, постоянно считываются из исходной системы. Следующая процедура описывает, как отделенная зеркальная копия может использоваться в качестве резервной базы данных:

    1. Приостановите в исходной базе данных операции записи ввода-вывода.
    2. Отделите зеркальную копию от исходной системы.
    3. Возобновите в исходной базе данных запись ввода-вывода, чтобы вернуть ее в обычный режим.
    4. Присоедините зеркальную копию базы данных к другому экземпляру.
    5. Переведите зеркальную копию в состояние отложенного повтора и выполните для нее повтор транзакций. Запустите инструмент db2inidb (db2inidb <алиас_базы_данных> as standby), чтобы вывести базу данных из состояния приостановленной записи и перевести базу данных с зеркальной копией в состояние отложенного повтора.
    6. Скопируйте журналы, установив программу обработчика пользователя для получения файлов журналов из исходной системы, чтобы гарантировать доступность для данной зеркальной копии базы данных самых новых журналов.
    7. Повторите транзакции базы данных до конца журналов.
    8. Вернитесь к шагу f и повторяйте данный процесс, пока исходная база данных не будет закрыта.

  3. Использование отделенной зеркальной копии в качестве резервной копии

    Следующая процедура описывает, как использовать зеркальную копию системы в качестве резервной копии для восстановления исходной системы:

    1. Воспользуйтесь командами операционной системы, чтобы скопировать данные и журналы зеркальной копии на место первичной системы.
    2. Запустите этот экземпляр базы данных, введя команду:
           db2start
      
    3. Чтобы перевести зеркальную базу данных в состояние отложенного повтора и отменить состояние приостановленной записи, введите следующую команду.
      db2inidb алиас_базы_данных AS MIRROR
      
    4. Повторите транзакции базы данных до конца журналов.

7.6.2 Инкрементное резервное копирование и восстановление

В главу 8 "Восстановление базы данных" вставьте следующий раздел об инкрементном резервном копировании и восстановлении:

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

Теперь DB2 поддерживает инкрементное резервное копирование и восстановление (за исключением данных длинных полей и больших объектов). Инкрементная резервная копия - это резервная копия, содержащая лишь те страницы, которые были изменены после снятия предыдущей резервной копии. Помимо страниц с измененными данными и индексом, каждая инкрементная резервная копия содержит все метаданные первоначальной базы данных (такие как конфигурация базы данных, определения табличных пространств, хронологию базы данных и так далее), которые сохраняются при обычном полном резервном копировании.

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

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

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

Чтобы восстановить базу данных или табличное пространство до согласованного состояния, процесс восстановления должен начаться с согласованной резервной копии всего воссоздаваемого объекта (базы данных или табличного пространства)и должен затем использовать все соответствующие инкрементные копии в описанном ниже порядке (смотрите раздел "Метод восстановления").

Чтобы разрешить отслеживание изменений базы данных, DB2 поддерживает новый параметр конфигурации базы данных TRACKMOD, который может иметь одно из двух допустимых значений:

Значение TRACKMOD по умолчанию для существующих баз данных - NO; для новых баз данных - YES.

Уровень отслеживания в этом случае - табличное пространства (как для SMS, так и для DMS).

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

7.6.2.1 Восстановление из инкрементных резервных копий

Операция восстановления из инкрементных резервных копий всегда содержит следующие шаги:

  1. Определение инкрементной копии назначения. Сначала администратор базы данных должен найти последнюю копию, подлежащую восстановлению, и из утилиты восстановления DB2 запросить операцию инкрементного восстановления. Этот образ при инкрементном восстановлении называется целевым образом, поскольку он будет последним из восстановленных образов. Команда инкрементного восстановления для этого образа может инициировать создание новой базы данных, конфигурация и определения табличных пространств которой будут взяты из этой целевой копии. Инкрементная целевая копия задается при помощи параметра TAKEN AT в команде RESTORE DATABASE.
  2. Восстановление наиболее поздней полной базы данных или табличного пространства в качестве отправной точки, к которой можно применять последовательные инкрементные резервные копии.
  3. Восстановление каждой из требуемых инкрементных резервных полных копий или копий табличного пространства в том порядке, в котором они создавались, начиная с исходной копии, восстановленной на шаге 2.
  4. Повторение шага 3, пока не будет вторично прочитана копия назначения из шага 1. Всего в ходе операции инкрементного восстановления происходит два обращения к целевой копии. Во время первого обращения из копии считываются только начальные данные; никакие пользовательские данные не считываются. Полная копия считывается и обрабатывается только во время второго обращения.

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

Например:

   1. db2 restore database sample incremental
taken at <отметка>
 
      где:
        <отметка> указывает на последнюю инкрементную резервную копию, 
        которую нужно восстановить
 
   2. db2 restore database sample incremental taken at <отметка1>
 
      где:
        <отметка1> указывает на начальную полную копию базы данных (или 
        табличного пространства)
 
   3. db2 restore database sample incremental taken at <отметкаX>
 
      где:
        <отметкаX> указывает на каждую из инкрементных резервных копий в 
        порядке их создания
 
   4. Повторить шаг 3, восстанавливая все инкрементные резервные копии вплоть 
      до копии <отметка>

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

7.6.3 Параллельное восстановление

Теперь DB2 использует несколько агентов как при восстановлении после аварии, так и при восстановлении с повтором транзакций базы данных. Можно ожидать повышения производительности при этих операциях, особенно в симметричной многопроцессорной среде (SMP); использование нескольких агентов при восстановлении базы данных использует дополнительные процессоры, доступные на компьютерах SMP.

С этим усовершенствованием связан новый тип агента - db2agnsc. DB2 выбирает число агентов, используемых при восстановлении базы данных, на основе числа процессоров в компьютере. Для компьютеров SMP число используемых агентов равно числу процессоров + 1. На компьютерах с одним процессором для более производительного чтения журналов, обработки записей журналов и предварительной выборки страниц данных используются три агента.

DB2 распределяет записи журнала между агентами так, чтобы они могли применять их одновременно, где возможно. Запись в журнал ведется параллельно на уровне страниц (записи журнала на одной и той же странице данных обрабатываются одним агентом), поэтому производительность растет даже в том случае, когда вся работа выполняется на одной таблице.

7.6.4 Резервное копирование в именованные конвейеры

Теперь доступна поддержка резервного копирования базы данных в локальные именованные конвейеры (и восстановление из них) в системах на основе UNIX. Программа записи и программа чтения именованного конвейера должны находиться на одном и том же компьютере. Конвейер должен существовать и располагаться в локальной файловой системе. Поскольку именованный конвейер обрабатывается как локальное устройство, нет необходимости указывать, что назначение является именованным конвейером. Вот пример для AIX:

  1. Создайте
  именованный конвейер:
      mkfifo /u/dbuser/mypipe
 
  2. Используйте этот конвейер как назначение для операции резервного 
     копирования базы данных:
      db2 backup db sample to /u/dbuser/mypipe
 
  3. Восстановите базу данных:
      db2 restore db sample into mynewdb from /u/dbuser/mypipe

7.6.5 Резервное копирование из отдельной копии

Теперь DB2 поддерживает полное автономное резервное копирование базы данных на отделенной зеркальной копии базы данных. Оперативное резервное копирование не поддерживается и в нем нет необходимости, поскольку база данных, которая находится в состоянии отложенного повтора транзакций, все равно недоступна. Когда происходит восстановление отдельной зеркальной резервной копии, она нуждается в повторе транзакций, поскольку во время отделения могли быть активные транзакции.

Прим.:Для пакета исправления DB2 версии 7.1 FixPak 3 и DB2 версии 7.2 эта поддержка ограничена базами данных, которые содержат только табличные пространства DMS. При попытке резервного копирования базы данных после отделения и базы данных, содержащей табличные пространства SMS, резервное копирование не будет выполнено.

После того, как база данных была разделена, нужно задать при помощи утилиты db2inidb одну из следующих опций:

Вот несколько сценариев использования:

7.6.6 Архивирование журнала по требованию

Теперь DB2 поддерживает закрытие (и, если включена опция обработчика пользователя, то и архивирование) активного журнала восстановимой базы данных в любое время. Это дает возможность собрать полный комплект файлов журнала до известного момента, и затем использовать эти файлы журнала для изменения резервной базы данных.

Прим.:Архивирование журналов по требованию не гарантирует, что файлы журналов будут сархивированы немедленно; оно прерывает запись журнала и выдает запрос на архивирование, но обработчик пользователя может вызвать некоторую задержку

Вы можете инициировать архивирование журнала по требованию, введя новую команду DB2 ARCHIVE LOG или вызвав новый API db2ArchiveLog.

7.6.7 Создание зеркальной копии журнала

В главу 8 "Восстановление базы данных" следует добавить следующий новый раздел по использованию функции приостановленного ввода/вывода:

Теперь DB2 поддерживает создание зеркальной копии журнала на уровне базы данных. Создание зеркальной копии файлов журнала помогает защитить базу данных от таких опасностей, как:

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

Переменная реестра DB2_NEWLOGPATH2 позволяет базе данных записывать идентичную вторую копию файлов журнала в другой путь. Рекомендуется разместить вторичный путь на другом физическом диске (желательно с другим контроллером диска). Тогда контроллер диска не будет уязвимой точкой.
Прим.:Поскольку Windows NT и OS/2 не позволяют "монтировать" устройство с произвольным именем пути, на этих платформах невозможно задать вторичный путь на другом устройстве.

DB2_NEWLOGPATH2 может быть включена (задана равной 1) или выключена (задана равной 0). Значение по умолчанию - ноль. Если этой переменной присвоена 1, имя вторичного пути равно текущему значению переменной LOGPATH плюс символ 2. Например, в среде SMP, если LOGPATH равен /u/dbuser/sqllogdir/logpath, вторичный путь журнала будет /u/dbuser/sqllogdir/logpath2. В среде MPP, если LOGPATH равен /u/dbuser/sqllogdir/logpath, DB2 присоединит к пути указатель узла, и в качестве первичного пути журнала будет использовать /u/dbuser/sqllogdir/logpath/NODE0000. В этом случае вторичный путь журнала будет /u/dbuser/sqllogdir/logpath2/NODE0000.

При первом включении DB2_NEWLOGPATH2 вторичный путь журнала не используется, пока не будет завершен текущий файл журнала при следующем запуске базы данных. Это аналогично тому, как сейчас используется NEWLOGPATH.

Если возникает ошибка при записи в первичный или вторичный путь журнала, база данных пометит отказавший путь как "плохой", запишет сообщение в файл db2diag.log и будет помещать следующие записи журнала только в оставшийся "хороший" путь журнала. DB2 не будет пытаться еще раз использовать "плохой" путь, пока не будет завершен текущий файл журнала. Когда DB2 потребуется открыть следующий файл журнала, она проверит, допустим ли этот путь, и если да, начнет использовать его. Если нет, DB2 не будет пытаться еще раз использовать путь до первого обращения к следующему файлу журнала. Попыток синхронизировать пути журналов не производиться, но DB2 сохраняет информацию о происходящих ошибках доступа, чтобы использовать правильные пути при архивации файлов журнала. Если сбой произойдет при записи в оставшийся "хороший" путь, база данных прервет работу.

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

Теперь доступна поддержка for кроссплатформенного резервного копирования и восстановления между Sun Solaris и HP. Передача резервной копии между системами должна происходить в двоичном режиме. В системе назначения база данных должна быть создана с той же кодовой страницей/территорией, что и система, в которой была создана исходная база данных.

7.6.9 Особенности менеджера связей данных DB2/Особенности утилиты резервного копирования

Второй абзац в этом разделе замените на следующий текст:

   Когда на файлы есть ссылки, серверы связей данных планируют их 
   асинхронное копирование на архивный сервер, например, ADSM, 
   или на диск. При работе утилиты резервного копирования DB2 
   проверяет, что скопированы все внесенные в расписание для 
   копирования файлы. В начале снятия резервной копии DB2 
   связывается со всеми серверами связей данных, указанными в 
   файле конфигурации DB2.
   Если у сервера связей данных есть один или несколько связанных 
   файлов и он не запущен или же остановлен во время резервного 
   копирования, резервная копия не будет содержать полной 
   информации DATALINK. Операция резервного копирования при этом
   завершится успешно. Перед тем, как этот сервер связей данных 
   можно будет снова объявить доступным для базы данных, надо 
   успешно завершить все отложенные резервные копирования. Если 
   резервное копирование вызвано, когда число отложенных резервных 
   копирований на этом сервере связей данных уже вдвое превышает 
   значение num_db_backups (смотрите ниже), операция резервного 
   копирования завершится неудачно. Перед последующими операциями 
   резервного копирования надо перезапустить этот сервер связей 
   данных и завершить отложенные операции резервного копирования.

7.6.10 Особенности менеджера связей данных DB2/Особенности утилиты восстановления и повтора транзакций

Замените абзацы, начинающиеся с:

   Если вы восстанавливаете из резервной копии базу данных или табличное 
   пространство и не указали опцию WITHOUT DATALINK...
   и
   Если вы восстанавливаете из резервной копии базу данных или табличное 
   пространство и не указали опцию WITHOUT DATALINK...

на:

   Когда вы восстанавливаете базу данных или табличное пространство, для 
   успешного завершения операции восстановления необходимы следующие 
   условия:
 
   o Если не работает любой из серверов связей данных, записанных в файле 
     резервной копии, операция восстановления все равно завершится успешно.
 
     Таблицы с информацией о столбце DATALINK, пострадавшие из-за отсутствия
     сервера связей данных, после операции восстановления будут переведены в 
     состояние отложенного согласования связей данных (или отложенного 
     повтора транзакций - если выполнялся повтор транзакций).
     Прежде чем серверы связей данных смогут быть снова помечены как 
     доступные для базы данных, этот процесс восстановления должен успешно 
     завершиться.
   o Если любой из серверов связей данных, записанных в файле резервной копии,
     остановится во время операции восстановления, операция восстановления
     завершится неудачно. Восстановление можно перезапустить при неработающем 
     сервере связей данных (смотри выше).
   o Если предыдущая операция восстановления остается незавершенной на 
     каких-либо серверах связей данных, последующие операции восстановления 
     базы данных или табличных пространств будут завершаться неуспешно до 
     тех пор, пока не будут перезапущены эти серверы связей данных и не будет 
     завершено незавершенное восстановление.
   o Информация обо всех столбцах DATALINK, записанных в файле резервной копии,
     должна существовать в соответствующих регистрационных таблицах серверов 
     связей данных.
     Если в регистрационных таблицах не записано всей информации о столбцах 
     DATALINK, после завершения операции восстановления (или отложенного 
     повтора транзакций - если выполнялся повтор транзакций) таблица с 
     отсутствующим столбцом DATALINK переводится в состояние невозможности 
     согласовать связи данных.
     Если резервная копия не записана в регистрационные таблицы, это может 
     означать, что предоставленный файл резервной копии более ранний, чем 
     значение для num_db_backups, и уже был помечен для "чистки мусора". 
     Это означает, что архивированные файлы из этой более ранней резервной 
     копии были удалены и не могут быть восстановлены. Все таблицы, у 
     которых есть столбцы DATALINK, переводятся в состояние отложенного 
     согласования связей данных.
     Если резервная копия не записана в регистрационные таблицы, это может 
     означать, что процесс резервного копирования до сих пор не завершен, 
     поскольку не работает сервер связей данных. Все таблицы, у которых есть 
     столбцы DATALINK, переводятся в состояние отложенного согласования 
     связей данных. Когда сервер связей данных будет перезапущен, процесс 
     резервного копирования будет завершен до процесса восстановления. 
     Таблица остается доступной для пользователей, но ссылки в столбцах 
     DATALINK могут быть неверными (например, файл, заданный значением 
     столбца DATALINK, может быть не найден). Если вы не хотите этого, 
     можно перевести таблицу в состояние ожидания проверки, введя 
     оператор "SET CONSTRAINTS for имя_таблицы TO DATALINK RECONCILE 
     PENDING".

Если после операции восстановления из резервной копии таблица находится в состоянии невозможности согласования связей данных, данные столбца DATALINK можно исправить одним из способов, предлагаемых в разделе "Вывод таблицы из состояния невозможности согласования связей данных (Datalink_Reconcile_Not_Possible State)".

Примечание в конце первого абзаца остается прежним.

В конце этого раздела добавьте следующую информацию:

      Настоятельно рекомендуется сархивировать файл datalink.cfg, 
   чтобы предусмотреть некоторые необычные случаи восстановления, 
   поскольку файл datalink.cfg в резервной копии базы данных лишь
   отражает файл datalink.cfg, каким он был на момент резервного 
   копирования. В некоторых случаях восстановления требуется иметь 
   наиболее поздний файл datalink.cfg. Таким образом, необходимо 
   создавать резервную копию файла datalink.cfg после каждого 
   вызова команды ADD DATALINKS MANAGER или DROP DATALINKS MANAGER.
   Это поможет получить наиболее поздний файл datalink.cfg, если 
   самый свежий файл datalink.cfg на диске недоступен.
   Если наиболее поздний файл datalink.cfg на диске недоступен, 
   замените существующий файл datalink.cfg (восстановленный из 
   резервной копии) наиболее поздним файлом datalink.cfg, 
   сархивированным до запуска восстановления повтором транзакций.
   Сделайте это после восстановления базы данных.

7.6.11 Восстановление баз данных из резервных копий, сделанных в автономном режиме, без повтора транзакций

Восстановление без повтора транзакций можно выполнять только на уровне базы данных, но не на уровне табличного пространства. Восстановить базу данных без повтора транзакций можно, либо задав базу данных, для которой невозможен повтор транзакций (то есть использующую циклическую запись журнала), либо указав параметр WITHOUT ROLLING FORWARD в команде RESTORE DATABASE.

Если вы используете утилиту восстановления с опцией WITHOUT DATALINK, все таблицы со столбцами DATALINK переводятся в состояние отложенного согласования связей (DRP), а во время операции восстановления никакого согласования с серверами связей данных не выполняется.

Если вы не используете опцию WITHOUT DATALINK, а сервер связей данных, записанный в файл резервной копии, больше не определен для базы данных (то есть был отброшен при помощи команды DROP DATALINKS MANAGER), те таблицы, что содержали ссылки DATALINK на отброшенный сервер связей данных, утилитой восстановления переводятся в состояние DRP.

Если вы не используете опцию WITHOUT DATALINK, все серверы связей данных доступны и вся информация о столбцах DATALINK полностью записана в регистрационные таблицы, то для всех серверов связей данных, записанных в файл резервной копии, происходит следующее:

Прим.:Описанные шаги невозможны, если резервная копия, использованная для операции восстановления базы данных, была снята в момент, когда не работал хотя бы один сервер связей данных, поскольку информация DATALINK в резервной копии не полна. Описанные шаги также невыполнимы, если резервная копия, использованная для операции восстановления базы данных, была снята после восстановления базы данных с повтором транзакций или без него. В обоих случаях все таблицы со столбцами DATALINK переводятся в состояние отложенного согласования связей, а во время операции восстановления никакого согласования с серверами связей данных не выполняется.

7.6.12 Восстановление баз данных и табличных пространств и повтор транзакций до конца файлов журнала

При восстановлении базы данных или табличного пространства с последующим повтором транзакций до конца файлов журнала (при условии, что все файлы доступны) проверка синхронизации не требуется, если только во время операции восстановления нет ни одного неработающего сервера связей данных, записанного в файле резервной копии. Если вы не уверены, что для операции повтора транзакций есть все файлы журнала, или полагаете, что может потребоваться синхронизация значений DATALINK, сделайте следующее:

  1. Введите оператор SQL для затронутых таблиц:
       SET CONSTRAINTS FOR имя_таблицы
    TO DATALINK RECONCILE PENDING
    
    Это переведет таблицу в состояние отложенного согласования связей данных и в состояние отложенной проверки.
  2. Если вы не хотите, чтобы таблица находилась в состоянии отложенной проверки, введите следующий оператор SQL:
       SET CONSTRAINTS FOR имя_таблицы IMMEDIATE CHECKED
    
    Это выведет таблицу из состояния отложенной проверки, но оставит ее в состоянии отложенного согласования связей данных. Для вывода таблицы из этого состояния необходимо использовать утилиту согласования.

Может оказаться, что файл резервной копии содержит ссылки DATALINK на менеджер связей DB2 (то есть менеджер связей DB2 был зарегистрирован в базе данных во время резервного копирования), который в дальнейшем был отброшен от базы данных. Для каждого табличного пространства, для которого выполняется восстановление с повтором транзакций и которое содержит хотя бы одну таблицу со ссылками DATALINK на отброшенный менеджер связей DB2, все таблицы утилитой повтора транзакций переводятся в состояние DRP.

7.6.13 Взаимодействие менеджера связей данных и восстановления

В следующей таблице показаны разные типы восстановления, которые можно выполнить; действия менеджера связей данных DB2 во время восстановления и повтора транзакций, и необходимо ли запускать утилиту согласования после завершения восстановления:
Тип восстановления Действия менеджера связей во время восстановления Действия менеджера связей во время повтора транзакций Согласование
Невосстановимая база данных (logretain=NO)
Восстановление базы данных из полной резервной копии при работе всех серверов связей данных Выполняется быстрое согласование Нет Может быть запущена дополнительно при подозрении на ошибки связывания файлов
Восстановление базы данных с использованием опции WITHOUT DATALINK Таблицы переводятся в состояние Datalink_Reconcile_Pending (ожидание согласования связей данных) Нет Обязательно
Восстановление базы данных из полной резервной копии, когда хотя бы один из серверов связей данных не работает Быстрое согласование выполняется лишь на тех таблицах в табличных пространствах, у которых нет связей с неработающим сервером связей данных, тогда как остальные таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Нет Требуется для таблиц в табличных пространствах со связями с неработающим сервером связей данных
Восстановление базы данных из неполной резервной копии при работе всех серверов связей данных Быстрое согласование не производится, все таблицы со столбцами DATALINK переводятся в состояние Datalink_Reconcile_ Pending state (ожидание согласования связей данных) Нет Обязательно
Восстановимая база данных (logretain=YES)
Восстановление базы данных с использованием опции WITHOUT ROLLING FORWARD из полной резервной копии при работе всех серверов связей данных Выполняется быстрое согласование Нет Необязательно
Восстановление базы данных с использованием опций WITHOUT ROLLING FORWARD и WITHOUT DATALINK из полной или неполной резервной копии при работающих или неработающих серверах связей данных Таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Нет Обязательно
Восстановление базы данных с использованием опции WITHOUT ROLLING FORWARD из полной резервной копии, когда хотя бы один из серверов связей данных не работает Быстрое согласование выполняется лишь на тех таблицах в табличных пространствах, у которых нет связей с неработающими серверами связей данных, тогда как остальные таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Нет Требуется на таблицах в табличных пространствах со связями с неработающими серверами связей данных
Восстановление базы данных с использованием опции WITHOUT ROLLING FORWARD из неполной резервной копии при работающих или неработающих серверах связей данных Быстрое согласование не производится, все таблицы со столбцами DATALINK переводятся в состояние Datalink_Reconcile_ Pending state (ожидание согласования связей данных) Нет Обязательно
Восстановление базы данных и повтор транзакций до конца журналов из полной резервной копии при работе всех серверов связей данных Никаких действий Никаких действий Необязательно
Восстановление базы данных и повтор транзакций до конца журналов из полной резервной копии, когда при выполнении повтора транзакций хотя бы один из серверов связей данных не работает Никаких действий Никаких действий Необязательно
Восстановление базы данных и повтор транзакций до конца журналов из полной или неполной резервной копии, когда во время восстановления любой из серверов связей данных не работает Никаких действий Все таблицы со столбцами DATALINK переводятся в состояние Datalink_Reconcile_Pending state (ожидание согласования связей данных) Требуется для всех таблиц со столбцами DATALINK
Восстановление базы данных и повтор транзакций до конца журналов из неполной резервной копии при работе всех серверов связей данных во время восстановления Никаких действий Никаких действий Необязательно
Восстановление базы данных и повтор транзакций до конца журналов из полной или неполной резервной копии при работе всех серверов связей данных, когда на любом из серверов связей данных резервная копия неизвестна Никаких действий Все таблицы в табличных пространствах со связями с сервером связей данных, на котором резервная копия неизвестна, переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Обязательно
Восстановление табличного пространства и повтор транзакций до конца журналов из полной резервной копии при работе всех серверов связей данных Никаких действий Никаких действий Необязательно
Восстановление табличного пространства и повтор транзакций до конца журналов из полной резервной копии, когда при выполнении повтора транзакций хотя бы один из серверов связей данных не работает Никаких действий Никаких действий Необязательно
Восстановление табличного пространства и повтор транзакций до конца журналов из полной или неполной резервной копии, когда во время восстановления любой из серверов связей данных не работает Никаких действий Все таблицы в табличных пространствах со связями с любым неработающим сервером связей данных переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Требуется для таблиц в табличных пространствах со связями с любым неработающим сервером связей данных
Восстановление табличного пространства и повтор транзакций до конца журналов из неполной резервной копии при работе всех серверов связей данных Никаких действий Никаких действий Необязательно
Восстановление базы данных и повтор транзакций до определенного момента времени из полной или неполной резервной копии при работающих или не работающих серверах связей данных во время процесса восстановления и/или повтора транзакций Никаких действий Таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Обязательно
Восстановление табличного пространства и повтор транзакций до определенного момента времени из полной или неполной резервной копии при работающих или не работающих серверах связей данных во время процесса восстановления и/или повтора транзакций Никаких действий Таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Обязательно
Восстановление базы данных с другим именем базы данных, алиасом, именем хоста или экземпляра без повтора транзакций(NOTE1) Таблицы переводятся в состояние Datalink_Reconcile _Not_Possible (согласование связей данных невозможно) Нет Необязательно, но таблицы в состоянии Datalink_Reconcile_ Not_Possible (согласование связей данных невозможно) нужно исправить вручную
Восстановление базы данных с другим именем базы данных, алиасом, именем хоста или экземпляра и повтор транзакций Никаких действий Таблицы переводятся в состояние Datalink_Reconcile _Not_Possible (согласование связей данных невозможно) Необязательно, но таблицы в состоянии Datalink_Reconcile_Not _Possible (согласование связей данных невозможно) нужно исправить вручную
Восстановление базы данных из непригодной к использованию резервной копии (образ был удален при чистке мусора на сервере связей данных) без повтора транзакций (NOTE1), с опцией WITHOUT DATALINK или без нее Таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Никаких действий Обязательно
Восстановление базы данных из непригодной к использованию резервной копии (образ был удален при чистке мусора на сервере связей данных) и повтор транзакций, с опцией WITHOUT DATALINK или без нее Никаких действий Таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Обязательно
Восстановление табличного пространства из непригодной к использованию резервной копии (образ был удален при чистке мусора на сервере связей данных) и повтор транзакций Никаких действий Таблицы переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных) Обязательно

Примечания:

  1. Восстановление с использованием резервной копии, сделанной в автономном режиме, и опции WITHOUT ROLLING FORWARD (logretain включен), или восстановление с использованием резервной копии, сделанной в автономном режиме (logretain выключен).

  2. Полная резервная копия - это резервная копия, снятая при всех работающих серверах связей данных. Неполная резервная копия - это резервная копия, снятая, когда хотя бы один из серверов связей данных не работал.

  3. Процесс быстрого согласования не производится, если резервная копия, использованная для операции восстановления базы данных, была снята после восстановления базы данных - с повтором транзакций или без него. В этом случае все таблицы со столбцами DATALINK переводятся в состояние Datalink_Reconcile_ Pending (ожидание согласования связей данных)

7.6.14 Обнаружение ситуации, требующей согласования

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


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