Форма "Экспресс восстановление"

Проект «Агбис Сервисные работы«

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

1. Проверка версии Firebird
2. Отключение приложений, переименование БД, клон БД
3. Тестирование БД «Копия»
3.1. FBFirstAID: Исправление ошибок
3.2. GFIX: Проверка
3.3. GFIX: Исправление ошибок
3.4. Проверка целостности БД
4. Backup/Restory и проверка БД «Новая»
4.1. Оптимизация БД (B/R)
4.2. Сверка структуры БД «Исходной» и «Новой»
4.3. Активация индексов БД
5. Восстановление работы БД «Исходная»
5.1. Переименование файлов БД, включение БД «Исходная»
5.2. Запуск остановленных служб
6. Отправка отчета

1. Для корректной работы процедуры восстановления версия Firebird должна быть старше 2.5.7.
2. Для выполнения операции Backup/Restory для Firebird 2.5 устанавливается дополнительно Firebird Embedded, который скачивается в с сайта agbis.co.

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

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

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

Перед выполнением операции Backup/Restory выполняются проверки и восстановления структур сервисными программами.

Для проверки и исправления некоторых ошибок в структуре базы данных используется внешняя программа «Surgeon FirebirdFirstAid».
Папка к ее расположением указывается в поле «Файл программы «Surgeon FirebirdFirstAid». По умолчанию ..\FirstAID\FirebirdFirstAID.exe.
Если программа не найдена, то она будет автоматически скачана с сайта agbis.co установлена.
При запуске программы запрашивается файл лицензии.

Нажимается Later
Программа работает без лицензии на компьютере 10 раз.
Для проверки используется БД «Копия».

Программа не позволяет передать имя файла базы данных в виде параметра, поэтому выбирается в ручную.
Имя файла базы данных можно посмотреть в поле «Файл базы данных» в разделе БД «Копия». По умолчанию база данных имеет суффикс _clone.

Сначала нажимается кнопка, которая выдает hint «Diagnose datebase».

После завершения диагностики нажимается кнопка, которая выдает hint «Repair datebase».

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

Для запуска проверки используется командный файл d:\Agbis\agbDBAdmin\Temp\tmp_gfix_v.cmd

"C:\Program Files\Firebird\Firebird_2_5\bin\gfix.exe" -v -full -user sysdba -pa masterkey "d:\DB\FB2\ForRecovery\Orenburg\ARM_clone.FDB" 2>"d:\DB\FB2\ForRecovery\Orenburg\gfix_v.log"

Опции
-full - Используется вместе с -v[alidate] для проверки структур записей и страниц; освобождает неназначенные фрагменты записей.
-v[alidate] - validate database structure
Определяет и освобождает страницы, которые были выделены, не назначены никакой структуре данных. Также сообщает о разрушенных структурах.
Результаты проверки фиксируются в лог-файле gfix_v.log, который размещается в папке с базой данных.

В случае отсутствия ошибок файл лога остается пустым.
Если в файле лога есть записи, то считается, что проверка завешена с ошибками.

Для запуска проверки используется командный файл d:\Agbis\agbDBAdmin\Temp\tmp_gfix_m.cmd

"C:\Program Files\Firebird\Firebird_2_5\bin\gfix.exe" -mend -ig -user sysdba -pa masterkey "d:\DB\FB2\ForRecovery\Orenburg\ARM_clone.FDB" 2>"d:\DB\FB2\ForRecovery\Orenburg\gfix_m.log"

Опции -i[gnore] - ignore checksum errors
Игнорировать ошибки контрольных сумм при проверке или чистке
-m[end] - prepare corrupt database for backup
Отмечает разрушенные записи как неиспользуемые, следовательно, они будут пропущены при последующей проверке или копировании.

Результаты проверки фиксируются в лог-файле gfix_m.log, который размещается в папке с базой данных.

В случае отсутствия ошибок файл лога остается пустым.
Если в файле лога есть записи, то считается, что проверка завешена с ошибками.

При выполнении операции Backup/Restory выполняется проверка структур и оптимизация данных базы данных.
Так как при выполнении операции Backup/Restory мы включаем режим игнорирования ошибок и включения индексов, то требуется обязательная проверка структуры БД и активация индексов БД.

Делается Backup БД «Копия», а затем получаем БД «Новая» с помощью операции Restory.
Операции Backup/Restory выполняются программой gbak.exe из дистрибутива Firebird.
В случае Firebird 2.5 используется Firebird Embedded, Firebird 3.0 и старше позволяют использовать основные файлы службы в режиме Embedded.
В режиме Embedded база данных открывается в монопольном режиме и операция выполняется в несколько раз быстрее.
В целях экономии места используется конвейер программ gbak.exe. В этом случае промежуточный файл backup не создается, а создается сразу результирующий файл базы данных. При этом сокращается общее время на выполнения операции Backup/Restory.

Пусть
Firebird 2.5
d:\Agbis\agbDBAdmin\agbDBAdmin.exe
D:\DB\Agbis\ARM.FDB

Тогда для запуска конвейера используется командный файл

cd /D "d:\Agbis\agbDBAdmin\temp"
SET ISC_USER=sysdba
SET ISC_PASSWORD=masterkey
del "D:\DB\Agbis\backup.log"
del "D:\DB\Agbis\restory.log"
"C:\Program Files\Firebird\Firebird_2_x64_Embedded\gbak.exe" -z -b -g -ig -v -st t -y "D:\DB\Agbis\backup.log" "D:\DB\Agbis\ARM_Clone.FDB" stdout| 
"C:\Program Files\Firebird\Firebird_2_x64_Embedded\gbak.exe"  -z -c -i -n -v -st t -y "D:\DB\Agbis\restory.log" stdin "D:\DB\Agbis\ARM_fix.FDB"

Обращем внимание,
что при работе gbak.exe в режиме Backup используется ключ -ig[nore], что позволяет работать с поврежденной БД.
В документации описание ключа -ig выглядит следующим образом:
-ig
До InterBase 5 сервер использовал вычисление контрольных сумм страниц БД. С InterBase 5 эта функциональность была отключена, поскольку диски сами научились восстанавливать поврежденные блоки по контрольным суммам, и поврежденный блок либо восстанавливается автоматически и незаметно, либо не может быть восстановлен вообще. Сейчас InterBase и Firebird вместо контрольной суммы записывают на страницу число «12345». Если произошло повреждение базы данных, и данные на страницах БД искажены (нули или другая произвольная информация), то сервер при чтении такой страницы будет выдавать ошибку контрольной суммы. Параметр -ig позволяет игнорировать ошибки контрольных сумм страниц, и не останавливать резервное копирование из-за этих ошибок. Поэтому, в обычной командной строке для создания резервной копии БД категорически не рекомендуется указывать параметр -ig! Если база данных вдруг окажется повреждена, то с этим параметром вы можете «не увидеть» повреждение. Так что, -ig для gbak используется только в крайнем случае – когда поврежденная база починена утилитой gfix, но обычный backup не проходит. Только тогда имеет смысл повторить бэкап с опцией -ig.

при работе gbak.exe в режиме Restory используются ключи -i -n, что позволяет работать с поврежденной БД.
В документации описание ключей выглядит следующим образом:
-i
Не выполнять создание (активацию) индексов (последняя фаза restore). После восстановления базы данных все индексы в ней останутся отключены (неактивны). Фактически с такой базой данных работать нельзя, т. к. при отключенных индексах Primary key, Foreign key и Unique возможны нарушения целостности данных в таблицах (дублирование первичных ключей и т. д.).
Данный параметр имеет смысл использовать разве что в специфических целях – например, восстановить только данные из бэкапа за максимально быстрое время, или определить длительность создания всех индексов (замерить время gbak -c, затем замерить время gbak -c -i, после чего вычесть одно время из другого – получите длительность активации всех индексов), чтобы определить или текущую производительность каталога temp, или сравнить ее с явно заданным в конфигурации расположении temp на другом физическом диске.
Если вы восстановили бэкап с опцией -i, индексы можно активировать командой alter index nnn active (для каждого индекса).

-n
Отключает проверку constraints, если при обычном восстановлении БД оказалось, что логическая целостность оригинальной БД была повреждена (например, из-за битого индекса PK возникли дубликаты первичного ключа).
Крайне не рекомендуется для использования в «командной строке автоматизированного restore».

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

После завершения операции проверяются логи операции Backup и Restory, которые находятся в файлах, которые лежат в папке с базой данных
«D:\DB\Agbis\backup.log» и «D:\DB\Agbis\restory.log»
Если в них есть строки с текстом «gbak: ERROR:», то считается, что восстановление завершилось с ошибкой.

Выполняется подключение к базе данных до выполнения оптимизации БД «Копия» и к базе данных «Новая», которая получена в результате оптимизации.
Выполняется сравнение количества объектов в исходной и новой базе данных. Если они не совпадают, то считается, что восстановление завершено с ошибкой.
Выполняется

• сравнение количества доменов
• сравнение количества таблиц
• сравнение количества представлений
• сравнение количества процедур
• сравнение количества триггеров
• сравнение количества генераторов
• сравнение количества исключений
• сравнение количества udf
• сравнение количества ролей
• сравнение количества индексов

В результате выполнения программой GBAK операции Backup/Restory и по каким-то другим причинам часть индексов может стать неактивной.
Получаем список всех неактивных индексов запросом

select rdb$index_name 
from rdb$indices 
where (rdb$system_flag is null or rdb$system_flag = 0) and rdb$indices.rdb$index_inactive = 1 
order by rdb$foreign_key nulls first 

Составляется и выполняется запрос на активацию всех индексов.
Для этого сначала в файл Orenburg\IndexToRestore.txt, который размещается в папке с базой данных («d:\DB\FB2\ForRecovery\Orenburg\IndexToRestore.txt») записываются команды активации индексов:

ALTER INDEX MST_AGENTS_GUID ACTIVE;
ALTER INDEX MST_AGENTS_USE_DEP_ID ACTIVE;
ALTER INDEX PK_BAD_PASSWORDS ACTIVE;
...

Затем формируется командный файл с обработкой этого файла

"C:\Program Files\Firebird\Firebird_2_5\bin\isql.exe" -q -u SYSDBA -p masterkey -i "d:\DB\FB2\ForRecovery\Orenburg\IndexToRestore.txt" -m -o "d:\DB\FB2\ForRecovery\Orenburg\RestoreIndexResult.txt" "d:\DB\FB2\ForRecovery\Orenburg\ARM_fix.FDB"

Ошибки при активации индексов записываются в файл RestoreIndexResult.txt, который размещается в папке с базой данных («d:\DB\FB2\ForRecovery\Orenburg\RestoreIndexResult.txt»)

Если файл RestoreIndexResult.txt пустой, а это означает, что все индексы активированы, то процесс восстановления базы считается выполненным успешно.
Если часть индексов осталась неактивной, то процесс восстановления базы считается завершенным с ошибкой.

Ошибки, чаще всего, возникают при активации индексов связанных со вторичными ключами. При потере значения поля связи или при потере записи на которое ссылается поле связи вторичного ключа возникает ошибка активации индекса.

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

Этот пункт выполняется всегда. Работа с «Исходной» базой данных должна быть восстановлена. Если восстановление прошло успешно, то исходная база заменяется на новую. Если восстановление завершено с ошибкой, то возвращается исходная база.

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

• Если выполнялся пункт «Оптимизация БД (B/R)», то это будет БД «Новая».
  
• Если пункт «Оптимизация БД (B/R)» не выполнялся, то это будет БД «Копия».
  

Затем выполняется контрольное подключение к БД «Исходная».

Запускаются остановленные перед началом восстановления службы (агенты).

Информация о выполнении «Экспресс восстановления» отправляется на адрес электронной почты, который указан в поле «E-Mail для отчета» (по умолчанию support@agbis.ru).

• Проект "Агбис Сервисные работы"