ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.12.2023
Просмотров: 24
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
каталога BODY_LOG формируются временные файлы. Удаление таких файлов, не связанных ни с одним из документов, выполняется автоматически при выполнении функций регулярного резервного копирования и профилактике БД. Однако очистка каталога может быть выполнена по запросу пользователя. Для этого следует выбрать в меню «Операции» пункт «Очистить
BODY_LOG». Эта операция, а также период, за который будет произведена очистка, возможны при соответствующей настройке программы.
Физическое копирование БД - при выполнении этой операции происходит только копирование БД, без проведения процедуры backup/restore. Копирование производится в каталог для резервных копий БД.
Возврат состояния до последней операции – при выполнении этой операции происходит переименовывание копии базы оставшейся после последнего выполнения операции
«Профилактика БД». Важно запомнить, что при выполнении этой операции текущий вариант базы будет перезаписан более старой ее копией, без возможности возврата к нему.
Если на сервере установлено несколько БД АИСТ-М, то перед выполнением операции будет выдано окно со списком всех баз зарегистрированных в системе. И только после выбора конкретной базы будет выполнена выбранная операция
Как происходит восстановление уже поврежденной БД в случае внезапного отключения электропитания? Для понимания этого сравним БД с файловой системой FAT. Для того чтобы восстановить конкретный файл в файловой системе, выполняются 2 действия:
1. Проверка файловой системы на целостность (логическую), например утилитой scandisk.
2. Проверка остался ли этот файл без изменений (например, специальной программой, работающей с файлом).
Аналогичные действия необходимо произвести над неисправной БД.
1. Проверить целостность БД. База данных, как и файловая система, построена на страницах, которые выделяются в одном пространстве по мере необходимости.
2. Выполнить одну за другой функции «Выполнить резервное копирование» (Backup) и
«Выполнить восстановление БД» (Restore).
Эти операции позволят выяснить, удачно ли прошло логическое восстановление БД. Если в ходе этих операций не возникло никаких ошибок, то база данных логически цела, и может использоваться для работы. Исключением может быть «потеря» нескольких документов, по причине того, что они в момент выключения находились в памяти операционной системы и не были сохранены (или были сохранены частично) на диске. Если базу восстановить не удается, то при наличии резервной копии (если она создается регулярно) есть возможность просто восстановить данные на момент последнего резервного копирования, при этом вся работа, происходившая после создания резервной копии будет утеряна, но будут восстановлены в полном объеме данных за весь период до резервного копирования.
Для восстановления БД в случае ее поломки (повреждения), не связанной с отключением электропитания, существует другой алгоритм.
Важно запомнить, что ввиду особой сложности этой процедуры, ее может выполнять только вручную администратор системы. При этом восстановление выполняется только для одной конкретной БД. Восстановление требует остановки работы подразделения, т.к. во время операции производится остановка сервиса СУБД.
1. Перед выполнением операции будет выполнен запуск скрипта, если он прописан (по умолчанию отсутствует).
2. Если в системе зарегистрировано более одной БД, то пользователю выдается список зарегистрированных БД, из которого он должен выбрать, какую из БД он будет восстанавливать.
3. Выбор пользователем файла - архивной копии. По умолчанию путь к хранению архивной копии будет указан тот, куда производится автоматическое архивирование БД.
4. Запрос на сохранение копии текущей БД, перед восстановлением путем копирования файла. Копирование может и не производится. При выборе варианта с сохранением будет запрошен путь, куда сохранять копию БД.
5. Проверяется состояние службы «AutoServiceDocPoint», если она запущена, то выполняется ее остановка. Если сервис был запущен, то состояние сохраняется, для последующего запуска службы, после выполнения операции.
BODY_LOG». Эта операция, а также период, за который будет произведена очистка, возможны при соответствующей настройке программы.
Физическое копирование БД - при выполнении этой операции происходит только копирование БД, без проведения процедуры backup/restore. Копирование производится в каталог для резервных копий БД.
Возврат состояния до последней операции – при выполнении этой операции происходит переименовывание копии базы оставшейся после последнего выполнения операции
«Профилактика БД». Важно запомнить, что при выполнении этой операции текущий вариант базы будет перезаписан более старой ее копией, без возможности возврата к нему.
Если на сервере установлено несколько БД АИСТ-М, то перед выполнением операции будет выдано окно со списком всех баз зарегистрированных в системе. И только после выбора конкретной базы будет выполнена выбранная операция
Как происходит восстановление уже поврежденной БД в случае внезапного отключения электропитания? Для понимания этого сравним БД с файловой системой FAT. Для того чтобы восстановить конкретный файл в файловой системе, выполняются 2 действия:
1. Проверка файловой системы на целостность (логическую), например утилитой scandisk.
2. Проверка остался ли этот файл без изменений (например, специальной программой, работающей с файлом).
Аналогичные действия необходимо произвести над неисправной БД.
1. Проверить целостность БД. База данных, как и файловая система, построена на страницах, которые выделяются в одном пространстве по мере необходимости.
2. Выполнить одну за другой функции «Выполнить резервное копирование» (Backup) и
«Выполнить восстановление БД» (Restore).
Эти операции позволят выяснить, удачно ли прошло логическое восстановление БД. Если в ходе этих операций не возникло никаких ошибок, то база данных логически цела, и может использоваться для работы. Исключением может быть «потеря» нескольких документов, по причине того, что они в момент выключения находились в памяти операционной системы и не были сохранены (или были сохранены частично) на диске. Если базу восстановить не удается, то при наличии резервной копии (если она создается регулярно) есть возможность просто восстановить данные на момент последнего резервного копирования, при этом вся работа, происходившая после создания резервной копии будет утеряна, но будут восстановлены в полном объеме данных за весь период до резервного копирования.
Для восстановления БД в случае ее поломки (повреждения), не связанной с отключением электропитания, существует другой алгоритм.
Важно запомнить, что ввиду особой сложности этой процедуры, ее может выполнять только вручную администратор системы. При этом восстановление выполняется только для одной конкретной БД. Восстановление требует остановки работы подразделения, т.к. во время операции производится остановка сервиса СУБД.
1. Перед выполнением операции будет выполнен запуск скрипта, если он прописан (по умолчанию отсутствует).
2. Если в системе зарегистрировано более одной БД, то пользователю выдается список зарегистрированных БД, из которого он должен выбрать, какую из БД он будет восстанавливать.
3. Выбор пользователем файла - архивной копии. По умолчанию путь к хранению архивной копии будет указан тот, куда производится автоматическое архивирование БД.
4. Запрос на сохранение копии текущей БД, перед восстановлением путем копирования файла. Копирование может и не производится. При выборе варианта с сохранением будет запрошен путь, куда сохранять копию БД.
5. Проверяется состояние службы «AutoServiceDocPoint», если она запущена, то выполняется ее остановка. Если сервис был запущен, то состояние сохраняется, для последующего запуска службы, после выполнения операции.
6. Проверяется состояние службы «ControlServerService», если она запущена, то выполняется ее остановка. Если сервис был запущен, то состояние сохраняется, для последующего запуска службы, после выполнения операции.
7. Останавливается сервис управления СУБД (FireBird).
8. Выполняется изменение расширения для файлов БД с gdb на __b. С целью иметь копию
БД в ее первоначальном виде (в случае неудачного восстановления БД), а также с целью недоступности БД по «привычному» пути. Т.е. при попытке после старта сервиса СУБД выполнить подключение к БД, пользователь получит сообщение о том, что БД не найдена. Если в процессе переименования возникли ошибки, то сервис управления СУБД (FireBird) будет запущен.
9. Выполняется старт службы СУБД (FireBird) и выполняется пауза, указанная в параметре
«Задержка (в миллисекундах) между остановкой/запуском сервисов». По умолчанию, после установки системы пауза равна 2000 (2 секунды). Пауза предназначена для времени инициализации запущенного сервиса.
10. Выполняется восстановление БД. Восстановление производится не в файл с расширением gdb, а в файл с расширением _db. С той целью, чтобы пользователи не могли подключаться к БД во время восстановления. Размер страницы БД берется из параметра «Размер страницы БД при восстановлении» настроек, по умолчанию этот параметр равен 4096.
10.1. При необходимости (в зависимости от выбора пользователя), производится копирование БД. Файл копируется из __b по указанному пути в gdb.
10.2. Перед восстановлением выполняется контроль свободного места на диске. Проверка производится следующим образом если свободного места на диске плюс место, занимаемое ранее переименованным файлом БД (с расширением __b) больше, чем архивная копия этой БД +10%, то места достаточно для выполнения операции. Информация о расчете свободного места пи любом исходе заносится в протокол. В случае нехватки места на диске операция завершается аварийно
(запись об этом событии попадает в протокол) и происходит обратное п.5 переименование фала
БД с расширением gdb.
10.3. Выполняется восстановление БД в файл с расширением _db через Firebird API, вся информация о ходе выполнения восстановления попадает в файл протокола. Для совместимости поддерживается восстановление многофайловых архивов. Архивы БД, берутся по месту, указанному в настройках хранения архивных копий, для дополнительно зарегистрированных БД из подкаталогов DB1, DB2 и т.д.
10.4. Восстановление, в отличие от предыдущих версий данного программного продукта, производится в один файл (многофайловость не поддерживается), а поэтому производится дополнительный контроль присутствия вторичных файлов БД (с расширениями gd1m gd2 и т.д. и
__1, __2 и т.д.), если такие файлы найдены, то они являются мусором и удаляются, о чем информация заносится в протокол.
10.5. Если восстановление завершено успешно, то файл, куда производилось восстановление БД (_db) изменяет свое расширение на gdb. Иначе происходит переименование обратное п.5. из файла с расширением __b в файл с расширением gdb (откат к предыдущей версии).
11. Если до операции сервис AutoServiceDocPoint не был запущен, то производится его запуск.
12. Если до операции сервис «ControlServerService» не был запущен, то производится его запуск.
13. После выполнения операции будет выполнен запуск соответствующего скрипта
«ПОСЛЕ восстановления БД», если он прописан (по умолчанию отсутствует).
Важным элементом сохранения информации являются профилактические действия, которые следует производить для предотвращения поломок баз данных, – это постоянное создание резервных копий. Это самый надежный способ от повреждений базы данных. Только резервное копирование дает полную гарантию сохранности данных. Но в результате резервного копирования может получиться и невосстановимая копия, поэтому восстановление базы из копии никогда не должно выполняться путем записи поверх оригинала и резервное копирование должно следовать определенным правилам. Во-первых, резервное копирование должно быть как можно более
частым, во-вторых, оно должно быть последовательным, и, в-третьих, резервные копии нужно проверять на возможность восстановления.
Частое резервное копирование означает, что нужно достаточно часто делать резервную копию, например один раз в сутки. Чем меньше промежуток данных между резервным копированием базы данных, тем меньше данных потеряется в результате сбоя.
Последовательность резервного копирования означает, что резервные копии должны накапливаться и храниться как минимум неделю. Если есть возможность, то нужно записывать резервные копии на специальные устройства типа стримера, если нет – то скопировать их на другой компьютер. История резервных копий позволит отследить скрытые повреждения и справиться с ошибкой системы.
Необходимо проверять, можно ли восстановить без ошибок полученную резервную копию.
Проверить это можно только одним способом – через тестовый процесс восстановления (restore).
Надо отметить, что процесс восстановления занимает примерно в 3 раза больше времени, чем резервное копирование, и для больших баз проверку на восстановление ежедневно делать затруднительно, так как это может прервать работу пользователей на несколько часов.
В том случае, если сервер должен функционировать при значительной нагрузке можно воспользоваться механизмом SHADOW для снятия «моментальных» снимков с базы данных и дальнейших операций по резервному копированию уже с моментальной копией.
При создании резервной копии и затем при восстановлении базы данных из этой копии происходит пересоздание всех данных в базе данных. Этот процесс (backup/restore) способствует исправлению большинства нефатальных ошибок в базе данных, связанных с повреждениями жесткого диска, выявляет проблемы с целостностью данных в базе, очищает базу данных от старых версий и фрагментов записей, незавершенных транзакций, значительно уменьшает размер базы данных. Если база данных рабочая, то рекомендуется производить эту процедуру еженедельно.
Если по каким-то причинам невозможно часто производить процесс backup/restore
(особенно restore), то можно воспользоваться инструментом для проверки и восстановления баз данных gfix, который позволяет провести проверку и восстановление многих ошибок без использования процедуры backup/restore.
Частое резервное копирование означает, что нужно достаточно часто делать резервную копию, например один раз в сутки. Чем меньше промежуток данных между резервным копированием базы данных, тем меньше данных потеряется в результате сбоя.
Последовательность резервного копирования означает, что резервные копии должны накапливаться и храниться как минимум неделю. Если есть возможность, то нужно записывать резервные копии на специальные устройства типа стримера, если нет – то скопировать их на другой компьютер. История резервных копий позволит отследить скрытые повреждения и справиться с ошибкой системы.
Необходимо проверять, можно ли восстановить без ошибок полученную резервную копию.
Проверить это можно только одним способом – через тестовый процесс восстановления (restore).
Надо отметить, что процесс восстановления занимает примерно в 3 раза больше времени, чем резервное копирование, и для больших баз проверку на восстановление ежедневно делать затруднительно, так как это может прервать работу пользователей на несколько часов.
В том случае, если сервер должен функционировать при значительной нагрузке можно воспользоваться механизмом SHADOW для снятия «моментальных» снимков с базы данных и дальнейших операций по резервному копированию уже с моментальной копией.
При создании резервной копии и затем при восстановлении базы данных из этой копии происходит пересоздание всех данных в базе данных. Этот процесс (backup/restore) способствует исправлению большинства нефатальных ошибок в базе данных, связанных с повреждениями жесткого диска, выявляет проблемы с целостностью данных в базе, очищает базу данных от старых версий и фрагментов записей, незавершенных транзакций, значительно уменьшает размер базы данных. Если база данных рабочая, то рекомендуется производить эту процедуру еженедельно.
Если по каким-то причинам невозможно часто производить процесс backup/restore
(особенно restore), то можно воспользоваться инструментом для проверки и восстановления баз данных gfix, который позволяет провести проверку и восстановление многих ошибок без использования процедуры backup/restore.