Введение

Для современного глобального бизнеса очень важно поддерживать высокую доступность данных в режиме 24x7. Возможность приостановленного ввода/вывода в IBM DB2 UDB обеспечивает интерфейс для оперативного отделяемого зеркалирования при непрерывной доступности системы, удовлетворяющей этим критическим потребностям. В этой статье определяются и объясняются ключевые понятия отделяемого зеркалирования и приостановленного ввода/вывода и даются пошаговые инструкции для нескольких различных сценариев.

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

В начало

Что такое отделяемая зеркальная копия?

Отделяемая (отделенная) зеркальная копия – это идентичная, независимая и мгновенная копия дискового тома, которую можно присоединить к другой системе. Отделенная зеркальная копия базы данных DB2 UDB представляет собой набор одинаковых, независимых и мгновенных копий дисковых томов, содержащих все ее управляющие файлы и файлы данных, включая все содержимое каталога базы данных, все контейнеры табличных пространств, каталог локальной базы данных и каталог с активными журналами (если он не находится в каталоге с базой данных). Отделение каталога с активными журналами требуется только для создания копии базы данных с использованием параметра snapshot команды db2inidb. В случае использования двух других параметров, standby и mirror, не требуется отделения каталога с активными журналами.

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

Ниже рассматривается более подробно содержимое отделенной зеркальной копии базы данных DB2 UDB:

• Каталог базы данных:

  Когда создается база данных, информация о ней, включая информацию по умолчанию, хранится в структуре каталогов. Иерархическая структура каталогов создается в том месте, информация о котором извлекается из команды db2 create database. Структура каталогов создается в виде "<путь к базе данных>/<имя экземпляра>/<имя узла>/SQLnnnnn/." Подкаталог с именем SQLnnnnn в этой структуре называется каталогом базы данных. В имени этого подкаталога используется обозначение базы данных, и оно представляет базу данных. Например, в SQL00001 содержатся объекты, связанные с первой базой данных, а последующим базам данных даются следующие номера: SQL00002 и так далее.

  В каталоге базы данных содержатся управляющие файлы базы данных (SQLBP.1, SQLBP.2, SQLSPCS.1, SQLSPCS.2, SQLSGF.1, SQLSGF.2, SQLDBCON, DB2RHIST.ASC, DB2TSCHNG.HIS, SQLOGCTL.LFH, SQLOGMIR.LFH и SQLINSLK), подкаталоги SQLT* для стандартных табличных пространств, управляемых системой, необходимые для функционирования базы данных, подкаталог SQLOGDIR — стандартный путь для журналов, подкаталог SYSTOOLSPACE для автоматической сборки статистической информации и возможностей реорганизации, а также подкаталог DB2EVENT для мониторов событий по умолчанию.

  Можно легко определить каталог базы данных, соответствующий базе данных, с помощью команды db2 list db directory on <путь к базе данных>.

• Каталог локальной базы данных:

  Каталог локальной базы данных находится в каждом пути (или "диске" для Windows), в котором была определена база данных. Структура каталога имеет вид "<путь к базе данных>/<имя экземпляра>/<имя узла>/sqldbdir/". Этот каталог содержит один элемент для каждой базы данных, доступных из этого места. При использовании отделяемого зеркалирования рекомендуется создавать единственную базу данных в пути к базе данных, чтобы в каталоге локальной базы данных ("sqldbdir") содержался только один элемент для единственной базы данных.

• Контейнеры табличных пространств:

  Все контейнеры табличных пространств, не являющиеся частью каталога базы данных, должны быть частью отделенной зеркальной копии. Информация о контейнерах табличных пространств может быть получена с помощью команд db2 list tablespaces и db2 list tablespace containers for <id-табличного-пространства>.

• Каталог активных журналов:

  Путь к журнальным файлам следует включать в отделенную зеркальную копию только для клона базы данных. Информация о каталоге активных журналов может быть получена с помощью команды db2 get db cfg for <псевдоним-базы-данных>.

Функциональность приостановленного ввода/вывода

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

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

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

Вот пример вывода команды db2 list tablespaces, в котором показывается состояние табличного пространства:

Tablespace ID                           = 0
Name                                    = SYSCATSPACE
Type                                    = System managed space
Contents                                = Any data
State                                   = 0x10000
Detailed explanation:
    Write Suspended

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

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

В начало

Обычные способы использования отделенной зеркальной копии

Отделенная зеркальная копия базы данных DB2 UDB, созданная с использованием возможностей приостановленного ввода/вывода, предоставляет пользователю много вариантов использования, что делает ее подходящей для достижения различных целей. Вот некоторые обычные способы использования отделенной зеркальной копии:

Клонирование исходной базы данных

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

База данных горячего резерва

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

Копирование с рабочей системы без нагрузки на нее

DB2 UDB позволяет сделать полную резервную копию базы данных из резервной базы данных (если в ней только табличные пространства, управляемые базой данных (DMS)), когда она находится в приостановленном состоянии «накатывания» изменений. Это устраняет накладные расходы, связанные с резервным копированием рабочей базы данных. В утилите резервного копирования DB2 предусмотрен специальный случай резервирования после команды db2inidb с параметром standby. Журнальные файлы, созданные на исходной базе данных после отделения зеркала, могут быть использования для восстановления путем «накатывания» изменений. Копирование резервной базы данных, содержащей табличные пространства, управляемые системой (SMS), в настоящее время не поддерживается по двум основным причинам:

1. Чтобы осуществлять резервное копирование табличных пространств, управляемых системой, DB2 должна запросить системные каталоги, чтобы получить список таблиц, которые должны быть включены в образ резервного копирования. На отделенной зеркальной копии эти каталоги будут в неправильном состоянии (пока не будет выполнен накат). Следовательно, DB2 не может надежным образом получить список таблиц.
2. Резервное копирование с помощью отделенной зеркальной системы захватит состояние контейнеров базы данных на исходной системе в момент, когда произошло разделение. Однако, отделенная зеркальная система не будет ничего знать о состоянии базы данных в это время (эта проблема также разрешается накатом). Поэтому, если на исходной системе происходят какие-либо операции, которые не могут делаться одновременно с резервным копированием (или, что то же самое, заставят резервное копирование ожидать блокировку или какой-либо другой элемент синхронизации),то резервное копирование отделенного зеркала будет заблокировано аналогичным способом. Но поскольку в общем случае невозможно определить, протекает ли в данный момент какая-либо из этих операций, резервное копирование на отделенной системе блокируется полностью.

Эти ограничения не распространяются на контейнеры, управляемые базой данных, потому что:

1. DB2 не требуется список таблиц для осуществления резервного копирования табличных пространств, управляемых базой данных, и
2. Есть характерные для таких табличных пространств блокировки, которые не позволяют несовместимым операциям происходить одновременно с резервным копированием, и они также принудительно делаются во время разделения.

Резервное копирование и восстановление на системном уровне

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

Высокоскоростное резервное копирование и восстановление

Возможности приостановленного ввода/вывода в сочетании с возможностями зеркалирования таких интеллектуальных серверов хранения данных, как IBM Enterprise Storage Server® (ESS, известный как Shark) с технологией FlashCopy® или EMC Symmetrix Remote Data Facility (SRDF) с функцией мгновенного разделения, обеспечивают быстрое резервное копирование и восстановление рабочей базы данных.

В начало

Подробности реализации

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

1. Приостановление ввода/вывода в исходной базе данных
2. Отделение зеркала исходной базы данных
3. Возобновление ввода/вывода в исходной базе данных
4. Инициализация отделенной зеркальной копии в нужном режиме

Приостановка ввода/вывода

Операции записи в исходной базе данных могут быть приостановлены посредством CLP (Command Line Processor — процессор командной строки) с помощью команды db2 set write. Ввод/вывод может быть также приостановлен из приложения путем вызова db2SetWriteForDB из DB2 API с входным параметром DB2_DB_SUSPEND_WRITE.

db2 connect to <псевдоним-БД>
db2 set write suspend for database

Отделение зеркала

Процесс отделения не зависит от DB2 UDB и полностью зависит от того, как это сделано в устройстве хранения. Нет каких-либо особых аппаратных или программных требований для использования возможностей приостановленного ввода/вывода для отделения зеркала базы данных DB2 UDB.

IBM рекомендует использовать интеллектуальные серверы хранения данных, как например, IBM ESS или EMC Symmetrix, которые создают почти мгновенные копии данных полностью самостоятельно. Однако, нет ограничений на использование команд операционной системы, инструментов или любых других утилит для создания отделенной зеркальной копии.

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

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

Для отделения зеркала делаются следующие шаги:

1. Соединиться с исходной базой данных
2. Приостановить ввод/вывод (все операции записи) в исходной базе данных
3. Отделить зеркальную копию (используя метод на усмотрение пользователя)
4. Возобновить ввод/вывод (все операции записи) на исходной базе данных

Возобновление ввода/вывода

Операции записи на исходной базе данных могут быть возобновлены из CLP с помощью команды db2 set write. Если соединение, используемое для приостановления операций записи, разорвется или повиснет, а все последующие попытки соединения также зависнут, то ввод/вывод может быть возобновлен с помощью команды db2 restart database с параметром write resume. В этом случае никакое восстановление после аварии не будет выполнено, если только эта команда не сделана после аварии базы данных. Важно помнить, что параметр write resume может применяться только к первичной базе данных и его не следует применять к зеркальной копии базы данных.

Ввод/вывод на исходной базе данных может быть также возобновлен из приложения с помощью вызова db2SetWriteForDB из DB2 API со значением DB2_DB_RESUME_WRITE. Вызов db2DatabaseRestart из DB2 API также возобновляет ввод/вывод (в дополнение к восстановлению после аварии) на исходной базе данных в зависимости от значения входной величины. Правильные значения входного параметра DB2_DB_SUSPEND_NONE and DB2_DB_RESUME_WRITE.

db2 set write resume for database

db2 restart database <псевдоним БД> write resume

Инициализация отделенной зеркальной копии

Отделенная зеркальная копия базы данных DB2 UDB, созданная с помощью приостановленного ввода/вывода, остается в состоянии "Приостановленной записи", пока она не будет инициализирована в какое-либо рабочее состояние. Следовательно, отделенная зеркальная копия базы данных DB2 UDB должна быть инициализирована до того, как ее можно будет использовать.

Команда db2inidb инициализирует отделенную зеркальную копию в рабочее состояние путем выполнения аварийного восстановления, либо помещения ее в приостановленное состояние «наката» изменений. Команду db2inidb можно использовать только для инициализации отделенной зеркальной копии, созданной с помощью приостановленного ввода/вывода.

В зависимости от параметра (snapshot, standby или mirror), использованного в команде db2inidb, отделенная зеркальная копия может быть инициализирована в качестве:

• Клона исходной базы данных
• Резервной базы данных
• Зеркальной копии базы данных

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

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

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

Формат конфигурационного файла для перемещения (текстовый файл) имеет следующий вид:

DB_NAME=oldName,newName
DB_PATH=oldPath,newPath
INSTANCE=oldInst,newInst
NODENUM=nodeNumber
LOG_DIR=oldDirPath,newDirPath
CONT_PATH=oldContPath1,newContPath1
CONT_PATH=oldContPath2,newContPath2

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

Отделенная зеркальная копия базы данных DB2 UDB, созданная с помощью возможностей приостановленного ввода/вывода, может быть использована в качестве клона исходной базы данных путем инициализации ее с параметром snapshot snapshot команды db2inidb.

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

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

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

Как только по отношению к отделенной зеркальной копии будет дана команда db2inidb с параметром snapshot, успешно завершившаяся или неудачная, параметр standby или mirror нельзя использовать, поскольку начата новая цепочка журналов.

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

1. Создать экземпляр базы данных (если не существует).
2. Занести базу данных в каталог (системный каталог базы данных) с параметром ON:
   
   

   db2 catalog database <имя-БД> as <псевдоним-БД> on <путь-к-БД>

   
   
3. Сделать доступным отделенную зеркальную копию:
   1. Монтировать отделенную зеркальную копию каталога базы данных.
   2. Монтировать отделенную зеркальную копию всех контейнеров табличных пространств. (Если контейнеры находятся в нескольких каталогах, тогда все каталоги контейнеров должны быть смонтированы.)
   3. Монтировать каталог локальной базы данных (sqldbdir).
   4. Монтировать отделенную зеркальную копию каталога журналов (если журнальные файлы не находятся в том же каталоге, что и каталог базы данных в исходной базе данных).
4. Запустить менеджер базы данных (нужно убедиться, что переменная DB2INSTANCE установлена):
   
   

   db2start

   
   
5. Инициализировать отделенную зеркальную копию:
   
   

   db2inidb <целевая-БД> as snapshot [relocate using <config_file>]

   
   

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

Отделенная зеркальная копия базы данных DB2 UDB, созданная с помощью возможностей приостановленного ввода/вывода, может быть использована в качестве резервной базы данных путем инициализации ее с параметром standby команды db2inidb.

После инициализации отделенная зеркальная копия помещается в приостановленное состояние «наката» изменений как резервная база данных. База данных будет находиться постоянно в приостановленном состоянии наката до тех пор, пока накат не будет остановлен.

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

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

1. Создать экземпляр базы данных (если не существует).
2. Занести базу данных в каталог (системный каталог базы данных) с параметром ON:
   
   

   db2 catalog database <имя ДБ> as <псевдоним-ДБ> on <путь-к-ДБ>

   
   
3. Сделать доступной отделенную зеркальную копию:
   1. Монтировать отделенную зеркальную копию каталога базы данных.
   2. Монтировать отделенную зеркальную копию всех контейнеров табличных пространств. (Если эти контейнеры расположены в нескольких каталогах, то все каталоги контейнеров должны быть смонтированы.)
   3. Монтировать каталог локальной базы данных (sqldbdir).
4. Запустить менеджер базы данных (нужно убедиться, что переменная DB2INSTANCE установлена):
   
   

   db2start

   
   
5. Инициализировать отделенную зеркальную копию:
   
   

   db2inidb <целевая-БД> as standby [relocate using <config_file>]

   
   
6. Постоянно забирать неактивные журнальные файлы из исходной базы данных и накатывать их на целевую базу данных:
   
   

   db2 rollforward db <целевая-БД> to end of logs

   
   

Если исходная база данных становится недоступной (например, если происходит сбой), резервная база данных на целевой системе может быть активирована для доступа пользователей. Чтобы активировать резервную базу данных, пользователь должен вывести резервную базу данных из приостановленного состояния наката. Это может быть сделано с помощью команды db2 rollforward с параметром stop или complete, чтобы привести базу данных в непротиворечивое состояние. Как только база данных окажется в непротиворечивом состоянии, пользователи могут переключиться на резервную базу данных и продолжить работу. Пользовательским приложениям потребуется сделать новые соединения с этой активированной резервной базой данных. Журнальные файлы, созданные на резервной базе данных, нельзя применять к исходной базе данных.

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

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

После инициализации отделенной зеркальной копии в качестве зеркала, база данных будет приведена в приостановленное состояние наката. Существующие журнальные файлы будут использоваться для восстановления методом наката на исходной базе данных. До тех пор пока не будет произведен накат до конца журналов, и не будет выдан stop/complete, восстановление после аварии не начнется, а база данных будет оставаться в противоречивом состоянии. Важно отметить, что отделенная зеркальная копия должна оставаться в состоянии «приостановленной записи», пока она не будет скопирована поверх исходной базы данных.

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

1. Остановить экземпляр исходной базы данных:
   
   

   db2stop

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

   db2start

   
   
4. Инициализировать зеркальную копию на исходной базе данных:
   
   

   db2inidb <исходная-БД> as mirror [relocate using <config_file>]

   
   
5. Накатить до конца журналов и остановиться:
   
   

   db2 rollforward database <исходная-БД> to end of logs and stop

   
   

Многораздельные базы данных

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

Поскольку каждый раздел рассматривается как отдельная база данных, операции записи должны быть приостановлены на каждом разделе данных независимо от всех остальных. Следовательно, пользователю не нужно выполнять db2_all для приостановления ввода/вывода на всех разделах. Однако, если каждый раздел приостанавливается независимо, операции записи на разделе каталога должны быть приостановлены в последнюю очередь. В многораздельной базе данных попытка приостановить ввод/вывод на любом из разделов, не являющихся узлом каталога, потребует соединения с узлом каталога для получения доступа. Если раздел каталога приостановлен, то соединение может зависнуть.

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

Пример

Если в многораздельной базе данных на AIX есть четыре раздела (0,1,2,3), где разделом каталога является 0, тогда приостановить и возобновить ввод/вывод можно следующим образом:

db2 export DB2NODE=1
db2 terminate
db2 connect to <псевдоним-БД>
db2 set write suspend for database

db2 export DB2NODE=2
db2 terminate
db2 connect to <псевдоним-БД> 
db2 set write suspend for database

db2 export DB2NODE=3
db2 terminate
db2 connect to <псевдоним-БД>
db2 set write suspend for database

db2 export DB2NODE=0
db2 terminate
db2 connect to <псевдоним-БД>
db2 set write suspend for database

db2_all restart database <псевдоним-БД> set write resume

При инициализации отделенной зеркальной копии команда db2inidb не требует соединения с базой данных. Следовательно, эту команду можно выполнять независимо на каждом разделе или можно запустить db2_all для работы db2inidb одновременно на всех разделах. Единственное требование: менеджер базы данных должен быть запущен.

Если есть какое-то количество сомнительных транзакций на момент отделения зеркальной копии (многораздельной базы данных) на некоторых разделах, команда db2inidb с параметром snapshot может завершиться отказом во время стороннего восстановления. Это вполне возможно. Чтобы разрешить сомнительную транзакцию может потребоваться соединение раздела данных с другим разделом данных. Если раздел данных, с которым установлен контакт, еще не обрабатывался командой db2inidb, запрос будет отвергнут и, следовательно, завершится неудачей с одним из следующих сообщений об ошибке:

• SQL20153N Отделенное зеркало базы данных находится в приостановленном состоянии.
• SQL1391N База данных уже используется другим экземпляром менеджера базы данных.

SQL20153N может произойти только в случае, если db2inidb запускается последовательно на каждом разделе данных, тогда как SQL1391N может произойти, когда db2inidb запускается параллельно на всех разделах данных.

В этом случае простой повторный запуск команды restart database на сбойных разделах решит эту проблему.

Поэтому, можно дать такие рекомендации для инициализации отделенной зеркальной копии базы данных DB2 UDB для многораздельной базы данных:

1. Запустить команду db2inidb на всех разделах данных одновременно, используя db2_all, или запустить db2inidb индивидуально на каждом разделе по очереди.
2. Запустить команду db2 restart database (без параметра write resume) на всех разделах для обеспечения начала стороннего восстановления на всех разделах, чтобы разрешить все сомнительные транзакции (поскольку пользователям может быть неудобно или сложно искать неудавшиеся случаи косвенного восстановления).

Следует иметь в виду, что сказанное выше применимо только тогда, когда используется параметр snapshot в команде db2inidb. Так как аварийное восстановление не производится с параметрами standby и mirror, то к этим случаям это не относится.

В начало

Отлаживание проблем с отделенной зеркальной копией

При работе с отделенной зеркальной копией всегда присутствуют три набора действий:

1. Приостановление и возобновление ввода/вывода на исходной базе данных с помощью команды db2 set write.
2. Отделение зеркала.
3. Инициализация отделенной зеркальной копии с помощью команды db2inidb.

При отладке проблемы, связанной с приостановленным вводом/выводом, команда технической поддержки IBM DB2 будет внимательно рассматривать действия 1 и 3. Поскольку процесс разделения происходит полностью вне DB2 UDB, пользователям следует привлечь поддержку соответствующего поставщика устройств хранения, чтобы отладить любые проблемы, связанные с используемым процессом отделения.

В общем случае в набор данных, собранных и предоставленных в поддержку IBM, должны входить:

• Копии db2diag.log, вывод команды db2level, конфигурация менеджера базы данных (db2 get dbm cfg) и конфигурация базы данных (db2 get db cfg for <псевдоним-БД>) как с исходной, так и целевой систем
• Копия файла SQLOGCTL.LFH (из исходной базы данных) сразу после выполнения команды db2 set write
• Копии файла SQLOGCTL.LFH из целевой системы до и после выполнения команды db2inidb
• В точности все подробности метода и команд сторонних разработчиков, использованных (в последовательности) для отделения зеркала

В начало

Заключение

В этой статье рассказывалось о концепции отделенной зеркальной копии в контексте базы данных DB2 UDB и о том, как можно использовать возможности приостановленного ввода/вывода для реализации различных решений достижения высокой доступности в целях обеспечения постоянной доступности системы. Были также подробно раскрыты действия по приостановлению/возобновлению ввода/вывода, отделения зеркальной копии и инициализации ее таким образом, чтобы ее можно было использовать как в много-, так и однораздельной среде.

Отказ от обязательств

Информация, представленная в этом документе, распространяется по принципу «как есть», без каких-либо гарантий, высказанных или подразумеваемых, и ни IBM, ни автор не несут ответственность за любые последствия ее использования.

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Split mirror using suspended I/O in DB2 Universal Database: оригинал статьи (EN).
  
  
• DB2 Universal Database for Linux, UNIX, and Windows - Support (EN) — отличный источник для поиска новейших сетевых ресурсов по DB2 UDB.
  
  
• IBM DB2 Universal Database: Data Recovery and High Availability Guide and Reference Version 8.2 (EN) предоставляет подробную информацию и демонстрирует, как использовать утилиты для резервного копирования и восстановления IBM DB2 Universal Database (UDB).В этой книге также объясняется важность высокой доступности и описывается поддержка отказоустойчивости DB2 на нескольких платформах.
  
  
• IBM DB2 Universal Database: Command Reference Version 8.2 (EN) предоставляет информацию об использовании системных команд и командного процессора (command line processor, CLP) для выполнения функций администрирования базы данных.
  
  
• IBM DB2 Universal Database: Administrative API Reference Version 8.2 (EN) предоставляет информацию об использовании интерфейсов прикладного программирования (API) для выполнения функций администрирования базы данных.
  
  
• "Split Mirror using Suspended I/O in IBM DB2 Universal Database Version 7" (EN) (developerWorks, апрель 2002) дает обзор возможностей приостановленного ввода/вывода DB2 UDB версии V7.2.
  
  
• На сайте зона DB2 на developerWorks (EN) можно узнать больше о DB2. Там можно найти техническую документацию, статьи «как сделать?», информацию для образования, загрузки, информацию о продуктах и многое другое.
  
  

Об авторе

У Шейхеда Квази (Shahed Quazi) более 8 лет опыта научно-исследовательской работы по технологиям баз данных во время работы над разработкой DB2 UDB в IBM Toronto Software Lab. Он специализируется на администрировании баз данных, высокой доступности и связи на платформах UNIX, Linux и Windows. Шейхед является сертифицированным техническим экспертом по DB2, у него степень бакалавра компьютерных наук от Йоркского университета, Канада. В настоящее время он работает в качестве независимого консультанта по DB2 в Торонто. Дополнительную информацию о нем можно получить на сайте www.DB2DBA.ca (EN).

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Что такое отделяемая зеркальная копия?
• Обычные способы использования отделенной зеркальной копии
• Подробности реализации
• Отлаживание проблем с отделенной зеркальной копией
• Заключение
• Ресурсы
• Об авторе
• Комментарии