====== Форма "Экспресс восстановление" ======
Проект **"[[:dba_AgbDBAdmin|Агбис Сервисные работы]]"**\\
Предназначена для выполнения полного цикла восстановления базы данных с некоторыми настройками по умолчанию.\\
{{:pasted:20210913-131553.png}}\\
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 =====
1. Для корректной работы процедуры восстановления версия Firebird должна быть старше 2.5.7.\\
2. Для выполнения операции Backup/Restory для Firebird 2.5 устанавливается дополнительно Firebird Embedded, который скачивается в с сайта agbis.co.\\
===== Отключение приложений, переименование БД, клон БД =====
1. Во время выполнения процедур восстановления нужно исключить изменение базы данных другими программами.\\
Для этого \\
* отключаются от базы данных все приложения. \\
* службы, такие как агенты, останавливаются. \\
* база данных переименовывается - в результате подключение БД "Исходная" становится недоступным, а исходной базе можно обращаться через подключение БД "Переименованная".\\
2. Во время восстановления базы данных, она может быть безвозвратно испорчена.\\
Поэтому создается копия базы данных, которая подключается через подключение БД "Копия".\\
===== 3. Тестирование БД "Копия" =====
Перед выполнением операции Backup/Restory выполняются проверки и восстановления структур сервисными программами.\\
==== 3.1 FBFirstAID: Исправление ошибок ====
Для проверки и исправления некоторых ошибок в структуре базы данных используется внешняя программа "Surgeon FirebirdFirstAid".\\
Папка к ее расположением указывается в поле "Файл программы "Surgeon FirebirdFirstAid". По умолчанию ..\FirstAID\FirebirdFirstAID.exe.\\
Если программа не найдена, то она будет автоматически скачана с сайта agbis.co установлена.\\
При запуске программы запрашивается файл лицензии.\\
{{:pasted:20210913-131924.png}}\\
Нажимается **Later**\\
Программа работает без лицензии на компьютере 10 раз.\\
{{:pasted:20210913-133913.png}}
Для проверки используется БД **"Копия"**.\\
{{:pasted:20210913-133956.png}}\\
Программа не позволяет передать имя файла базы данных в виде параметра, поэтому выбирается в ручную.\\
Имя файла базы данных можно посмотреть в поле "Файл базы данных" в разделе БД "Копия". По умолчанию база данных имеет суффикс _clone.\\
{{:pasted:20210913-134547.png}}\\
Сначала нажимается кнопка, которая выдает hint "Diagnose datebase".\\
{{:pasted:20210913-135007.png}}\\
После завершения диагностики нажимается кнопка, которая выдает hint "Repair datebase".\\
{{:pasted:20210913-135059.png}}\\
Программа исправляет некоторые ошибки.\\
Результат выполнения операций с помощью **Surgeon FirebirdFirstAid** не передаются в программу **AgbDBAdmin**.\\
Поэтому решение о продолжении восстановления принимается пользователем.\\
После выполнения всех операций с помощью **Surgeon FirebirdFirstAid** программа закрывается.\\
==== 3.2 GFIX: Проверка ====
Для запуска проверки используется командный файл 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, который размещается в папке с базой данных.\\
В случае отсутствия ошибок файл лога остается пустым.\\
Если в файле лога есть записи, то считается, что проверка завешена с ошибками.\\
==== 3.3 GFIX: Исправление ошибок ====
Для запуска проверки используется командный файл 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, который размещается в папке с базой данных.\\
В случае отсутствия ошибок файл лога остается пустым.\\
Если в файле лога есть записи, то считается, что проверка завешена с ошибками.\\
==== 3.4. Проверка целостности БД ====
===== 4. Backup/Restory и проверка БД "Новая" =====
При выполнении операции Backup/Restory выполняется проверка структур и оптимизация данных базы данных.\\
Так как при выполнении операции Backup/Restory мы включаем режим игнорирования ошибок и включения индексов, то требуется обязательная
проверка структуры БД и активация индексов БД.\\
==== 4.1 Оптимизация БД (B/R) ====
Делается 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:", то считается, что восстановление завершилось с ошибкой.
==== 4.2 Сверка структуры БД "Исходной" и "Новой" ====
Выполняется подключение к базе данных до выполнения оптимизации БД "Копия" и к базе данных "Новая", которая получена в результате оптимизации.\\
Выполняется сравнение количества объектов в исходной и новой базе данных. Если они не совпадают, то считается, что восстановление завершено с ошибкой.\\
Выполняется
* сравнение количества доменов
* сравнение количества таблиц
* сравнение количества представлений
* сравнение количества процедур
* сравнение количества триггеров
* сравнение количества генераторов
* сравнение количества исключений
* сравнение количества udf
* сравнение количества ролей
* сравнение количества индексов
==== 4.3. Активация индексов БД ====
В результате выполнения программой 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 пустой, а это означает, что все индексы активированы, то процесс восстановления базы считается выполненным успешно.\\
Если часть индексов осталась неактивной, то процесс восстановления базы считается завершенным с ошибкой.\\
Ошибки, чаще всего, возникают при активации индексов связанных со вторичными ключами.
При потере значения поля связи или при потере записи на которое ссылается поле связи вторичного ключа возникает ошибка активации индекса.\\
В этом случае восстановление базы данных требует анализа ошибок и выполнения не стандартных операций.\\
Для этого следует обратится к сотрудникам технической поддержки.\\
===== 5. Восстановление работы БД "Исходная" =====
Этот пункт выполняется всегда. Работа с "Исходной" базой данных должна быть восстановлена.
Если восстановление прошло успешно, то исходная база заменяется на новую.
Если восстановление завершено с ошибкой, то возвращается исходная база.
==== 5.1. Переименование файлов БД, включение БД "Исходная" ====
Если была ошибка, то на место БД "Исходная" возвращаем БД "Переименованная".\\
Если все операции выполнены успешно, то на место БД "Исходная" возвращаем новую базу данных.\\
* Если выполнялся пункт "Оптимизация БД (B/R)", то это будет БД "Новая". \\
* Если пункт "Оптимизация БД (B/R)" не выполнялся, то это будет БД "Копия". \\
Затем выполняется контрольное подключение к БД "Исходная".\\
==== 5.2. Запуск остановленных служб ====
Запускаются остановленные перед началом восстановления службы (агенты).\\
===== 6. Отправка отчета =====
Информация о выполнении "Экспресс восстановления" отправляется на адрес электронной почты, который указан в поле "E-Mail для отчета" (по умолчанию support@agbis.ru).\\
===== Дополнительная информация =====
* [[:dba_AgbDBAdmin|Проект "Агбис Сервисные работы"]]\\