Восстановление поврежденной базы данных

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

Основными причинами повреждения баз данных являются:

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

При отключении питания на компьютере-сервере все процессы обработки данных резко прерываются. В результате информация в базе данных может исказиться или пропасть. После восстановления питания сервер просматривает данные, отслеживает незавершенные транзакции, не ассоциируемые ни с одним из клиентов, и «откатывает» все изменения, проведенные в рамках этих прерванных транзакций. Однако отключение питания не всегда сопровождается лишь такими незначительными потерями. Если сервер в момент отключения питания производил расширение базы данных, то велик риск получить «потерянные» страницы в файле базы данных (orphan pages), т.е. такие страницы, которые физически распределены и зарегистрированы на страницах учета страниц, но запись данных на которые невозможна. Бороться с потерянными страницам в файле базы данных умеет только инструмент починки и модификации BackUtil или gfix (стандартная утилита FireBird). Потерянные страницы приводят только к излишнему расходу дискового пространства и как таковые не служат причиной потери или порчи данных. Но отключение питания может приводит и к более серьёзным повреждениям. После отключения питания и повторного включения может пропасть большое количество данных, в том числе и подтвержденных. Это происходит из-за того, что подтвержденные данные записываются не напрямую в файл базы данных на диске, а используют для этой цели файловый кэш операционной системы. То есть серверный процесс передает операционной системе команду на запись данных на диск, операционная система в свою очередь отправляет подтверждение на сервер, что данные сохранены на диске, а на самом деле данные находятся в файловом кэше. Операционная система не сбрасывает эти данные на диск, так как оценивает, что оперативной памяти еще много, и откладывает медленные операции записи на диск до тех пор, пока не закончится свободная оперативная память.

2. Дефекты и неисправности серверного компьютера, особенно дисков, дисковых контроллеров, оперативной памяти компьютера и кеш-памяти RAID-контроллеров.

3. Файловое копирование или другой файловый доступ к базе данных при запущенном сервере. Выполнение команды shutdown или отключение пользователей обычным порядком не является гарантией того, что сервер ничего не делает с базой; если sweep interval не установлен в 0, может выполняться sweep. Кроме того, после отключения последнего пользователя сервер выполняет уборку лишней информации. Обычно эта процедура занимает 1–2 мин, но, если перед этим выполнялось много операций delete или update, процесс может быть более длительным.

4. Исчерпывание свободного дискового пространства во время работы с базой.

5. Для всех серверов Borland FireBird превышение допустимого количества транзакций без выполнения backup/restore.

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

Программа предназначена для выполнения операций резервного копирования, восстановления, починки данных и копирования данных за выбранный период в автономном режиме. После старта она выполняет свои функции согласно заданному расписанию без привлечения к себе внимания со стороны пользователя. Лог работы программы ведется в журнале событий ОС Windows.

В отличие от программ, которые работают как сервисы Windows и могут запускаться до логина пользователя в ОС, «Планировщик резервного копирования данных» останется не запущенным пока пользователь не пройдет регистрацию в ОС. Поэтому для запуска программы необходимо произвести вход в Windows. Так как программа поставляется в дистрибутиве серверной части системы, то такой пользователем должен обладать правами администратора ОС.

Важно отметить, что:

1. Планировщик резервного копирования можно закрыть только через меню пиктограммы из системного трея

2. Если он выполняет какие либо действия то закрыть программу нельзя пока процесс не завершится.

3. Если в процессе выполнения архивирования, профилактики попытаться выключить компьютер, то программа не даст этого сделать.

Лог работы программы ведется в журнале событий ОС Windows.

Перед выполнением операций резервного копирования (BackUp) и восстановления базы данных (Restore), происходит анализ свободного места на диске. При этом:

1. Свободного места на диске, где находится БД АИСТ-М должно быть достаточно для хранения самой БД и ее копии, которая создается при восстановлении БД (Restore). Если БД состоит из нескольких файлов, то при оценке места на диске учитывается их общий размер.

2. Свободного места на диске, где находятся файлы архивной копии БД должно быть не меньше общего размера самой БД.

При отсутствии свободного места выполнении функций будет остановлено.

Программа реализует следующие функции:

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

Профилактика базы данных (Backup/Restore) – включает в себя выполнение сразу двух операций: резервного копирования данных (Backup) и восстановления данных (Restore). Профилактика выполняется как для получения резервной копии базы данных, так и для очистки базы данных от временных записей, что позволяет уменьшить размер БД. На этапе восстановления могут создаваться многофайловые БД, что определяется настройкой программы. При восстановлении все БД отключаются немедленно, а также происходит перезапуск сервера БД. Восстановление по этой причине возможно только на сервере БД. Следует отметить, что функция профилактики БД имеет приоритет выполнения перед функцией регулярного резервного копирования данных. В случае, когда в расписании для этих функций указаны одинаковые параметры запуска (например, совпадает день и время запуска), то будет выполнена только профилактика БД. Это обусловлено тем, что профилактика уже включает в себя операцию резервного копирования данных (BackUp).

Перед выполнением восстановления БД (Restore) создается копия текущей БД, с расширением docpoint2.__b . Копия БД необходима для быстрого отката, при возникновении нештатных ситуаций. Для восстановления работоспособности системы достаточно переименовать файл(ы) копии БД. Например, копия БД docpoint2.__b переименовывается в docpoint2.gdb. При каждом запуске «Планировщика резервного копирование» проверяется, есть ли файл БД docpoint2.gdb. В случае если файл не найден (такое может произойти например в случае если во время выполнения профилактики БД произошло отключение сервера), то выдается текстовое сообщение о том что файл БД отсутствует и администратору системы предлагается восстановить базу из копии (автоматически переименовать docpoint2.__b в docpoint2.gdb )

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

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

Удаление документов по указанную дату – используется для удаления «устаревших» документов и уменьшения размера БД. Пользователь может выбрать дату и время, на которую требуется удалить документы. Удаление документов происходит от самой ранней даты изменения документа найденной в БД, до даты выбранной пользователем. По умолчанию дата устанавливается из расчета, текущая дата минус один год. Периодически необходимо выполнять ревизию документов, для того чтобы те документы которые необходимо отставить, имели относительно свежую дату их изменения. Для этого, например, можно иметь некий переход в технологической схеме, прохождение через который менял бы дату изменения документа. Информация о количестве удаленных документов сохраняется в лог файле BackUtil.log.

Очистка BODY_LOG – удаление в каталоге BODY_LOG временных файлов не связанных ни с одним документом БД.

При откате (RollBack) транзакции, например, когда пользователь отказывается от сохранения изменений в документе, работая в ПЗ «Модуль обработки документов», в каталоге каталога BODY_LOG формируются временные файлы. Удаление таких файлов, не связанных ни с одним из документов, выполняется автоматически при выполнении функций регулярного резервного копирования и профилактике БД. Однако очистка каталога может быть выполнена по запросу пользователя. Для этого следует выбрать в меню «Операции» пункт «Очистить 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.