Регламент восстановления БД после сбоя

ВНИМАНИЕ! Ниже рассматривается ситуация, когда основной сервер БД вышел из строя вместе с зеркальным сервером или когда зеркалирование не было настроено.

Это очень плохая ситуация и ее нужно стараться ИЗБЕГАТЬ.

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

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

К восстановлению БД из резервной копии нужно прибегать ТОЛЬКО В САМОМ КРАЙНЕМ СЛУЧАЕ во избежание потенциальных проблем.

Изложенный ниже сценарий, приводящий к восстановлению БД из резервной копии, КРАЙНЕ НЕЖЕЛАТЕЛЕН, он приведет к потере части оперативных данных, касающихся текущих заданий на печать ФСМ/АМ. Восстановить эту информацию автоматически будет НЕВОЗМОЖНО.

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

1) физические отказы:

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

б) выход из строя комплекса технических средств за счет аварий техногенного характера - повреждение внешних каналов связи, нарушение электропитания здания, повреждение водоснабжения здания и т.д.;

в) выход из строя одиночного сервера;

г) выход из строя одиночного дискового массива сервера;

д) выход из строя диска сервера;

2) логические отказы

а) сбой общесистемного или специального программного обеспечения;

б) нарушение логической целостности информации, хранящейся на диске сервера.

3) ошибки в работе персонала (ввод некорректных данных).

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

При возникновении событий, описанных в пунктах 1) и 2) возможны 3 варианта развития:

1) сервер (диски) физически не доступны;

2) сервер частично доступен - есть возможность подключиться к нему;

3) сервер не доступен, однако информация на физических дисках не повреждена и её можно взять, т.е. скопировать физические файлы БД.

При возникновении варианта 1, восстановление системы состоит из следующих шагов (с учётом восстановления физических параметров сервера):

1) установка ПО SQL Server 2005;

2) восстановление БД " RFTS_ALCO" из полной резервной копии;

3) восстановление системной БД " master" из резервной копии;

4) восстановление системной БД " msdb" из резервной копии;

5) поэтапное восстановление всех резервных копий журнала транзакций (ЖТ);

6) полное резервное копирование БД " RFTS_ALCO".

Таким образом, система (данные) будет восстановлена на момент последнего резервного копирования ЖТ.

При возникновении варианта 2, прежде чем приступить к восстановлению системы, необходимо попытаться сохранить текущий журнал транзакций (ЖТ) БД " RFTS_ALCO", т.е. сделать его резервное копирование. Затем выполнить все пункты из предыдущего варианта и плюс к этому, если удалось сохранить последний ЖТ, восстановить его (шаг между 5 и 6).

Таким образом, система (данные) будет восстановлена либо на момент последнего резервного копирования ЖТ, либо полностью.

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

1) установка ПО SQL Server 2005;

2) остановка всех служб (сервисов) SQL Server;

3) копирование (замена) сохранённых физических файлов баз данных на место новых. При этом папки расположения баз данных должны быть такими же, как и до краха;

4) запуск служб (сервисов) SQL Server;

5) полное резервное копирование БД " RFTS_ALCO".

Применение варианта 3 так же возможно при возникновении ситуации, описанной в пункте 2)a., когда произошёл сбой в ПО SQL Server, однако физические файлы баз данных не повреждены.

При необходимости восстановить систему после возникновения ситуации, указанной в пункте 3), можно воспользоваться возможностью SQL Server восстанавливать данные на определённый момент времени. Для этого необходимо выполнить следующие шаги:

1) восстановление БД " RFTS_ALCO" из полной резервной копии;

2) поэтапное восстановление резервных копий журнала транзакций, с указанием времени, до которого нужно восстановить базу (параметр STOPAT = time);

3) полное резервное копирование БД " RFTS_ALCO".

Внимание! При восстановлении узла системы необходимо, чтобы версии БД и программных компонентов системы совпадали. При несовпадении версий любой компонент системы (Транспортный Сервис, ПС Участника ЕГАИС и т.д.) не запустится, в логах (Event log и в текстовом файле лога) появится соответствующая ошибка о несовпадении версии ПО и БД.

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

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

Рисунок 65 – Пример ошибки при неактуальном состоянии базы данных

Для возможности дальнейшей работы программных модулей системы с базой данных, которая находится в неактуальном состоянии, её необходимо активировать при помощи «Утилиты активации узла после сбоя». Активация необходима для определения корректности базы данных узла и поддержки целостности данных в системе.

Для восстановления работоспособности базы данных администратору системы необходимо:

1. Запустить «Утилиту активации узла после сбоя» на компьютере, где установлен транспортный сервис. Для этого откройте Пуск → Все программы → ЕГАИС → Транспортный сервис → Активация узла после сбоя.

Рисунок 66 – Утилита активации узла после сбоя

1. Получить параметры активации Код1, Код2, нажав на кнопку «Получить»
   (рисунок 68).

Рисунок 67 – Параметры активации

1. Полученные параметры активации передать сотрудникам ГНИВЦ и получить от них в ответ код активации.
2. Ввести полученный код активации в окне «Утилиты активации узла после сбоя» и нажать на кнопку «Активировать» (рисунок 68).

Рисунок 68 – Активация узла после сбоя

После восстановления работоспособности узла и его активации необходимо до начала работы с ПС Организаций обязательно выполнить загрузку файлов восстановления, полученных от МРУ и УТО (см. подраздел «Загрузка данных из файла»). В результате будут получены недостающие записи и документы, которые до сбоя были переданы вышестоящему узлу и были сохранены в его БД, а также документы, полученные ранее и утерянные в результате сбоя БД.

Затем необходимо дождаться прохождения автоматической синхронизации.