====== Форма "Экспресс восстановление" ====== Проект **"[[: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|Проект "Агбис Сервисные работы"]]\\