Книга: Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

Профилактика повреждений баз данных InterBase

Профилактика повреждений баз данных InterBase

Профилактические действия, которые следует производить для предотвращения поломок баз данных, - это постоянное создание резервных копий (подробно о резервном копировании см. главу "Резервное копирование и восстановление из резервной копии"). Это самый надежный рубеж обороны против повреждений базы данных. Только резервное копирование дает 100%-ную гарантию сохранности данных. Но, как описано выше, в результате резервного копирования может получиться и невосстановимая, т. е. бесполезная, копия, поэтому восстановление базы из копии никогда не должно выполняться путем записи поверх оригинала и резервное копирование должно следовать определенным правилам.

Во-первых, резервное копирование должно быть как можно более частым, во-вторых, оно должно быть последовательным, и, в-третьих, резервные копии нужно проверять на возможность восстановления.

Частое резервное копирование означает, что нужно достаточно часто делать резервную копию, например один раз в сутки. Чем меньше промежуток данных между резервным копированием базы данных, тем меньше данных потеряется в результате сбоя.

Последовательность резервного копирования означает, что резервные копии должны накапливаться и храниться как минимум неделю. Если есть возможность, то нужно записывать резервные копии на специальные устройства типа стримера, если нет - то хотя бы скопировать их на другой компьютер. История резервных копий позволит отследить скрытые повреждения и справиться с ошибкой, которая возникла давно, а проявилась, как всегда, неожиданно.

Необходимо проверять, можно ли восстановить без ошибок полученную резервную копию. Проверить это можно только одним способом - через тестовый процесс восстановления (restore). Надо сказать, что процесс восстановления занимает примерно в 3 раза больше времени, чем резервное копирование, и для больших баз проверку на восстановление ежедневно делать затруднительно, так как это может прервать работу пользователей на несколько часов, т. е. ночного перерыва может и не хватить. Конечно, организациям, имеющим базы данных такого большого объема лучше, не экономить "на спичках" и выделить отдельный компьютер для этих целей.

В том случае, если сервер должен функционировать при значительной нагрузке по 24 часа 7 дней в неделю, можно воспользоваться механизмом SHADOW для снятия "моментальных" снимков с базы данных и дальнейших операций по резервному копированию уже с моментальной копией. Подробно процесс резервного копирования и восстановления баз данных описан в главе "Резервное копирование и восстановление базы данных из резервной копии".

При создании резервной копии и затем при восстановлении базы данных из этой копии происходит пересоздание всех данных в базе данных Этот процесс backup/restore, или коротко - b/r) способствует исправлению большинства нефатальных ошибок в базе данных, связанных с повреждениями жесткого диска, выявляет проблемы с целостностью данных в базе, очищает базу данных от "мусора" (старых версий и фрагментов записей, незавершенных транзакций), значительно уменьшает размер базы данных. Можно сказать, что регулярный b/r - залог здоровья базы данных InterBase. Если база данных рабочая, то рекомендуется производить b/r еженедельно. Правда, есть свидетельства о базах данных InterBase, которые интенсивно используются по несколько лет без backup/restore. Тем не менее для собственного спокойствия все-таки желательно производить эту процедуру, тем более что ее легко можно автоматизировать.

Если по каким-то причинам невозможно часто производить процесс backup/restore (особенно restore), то можно воспользоваться инструментом для проверки и восстановления баз данных gfix, который позволяет провести проверку и восстановление многих ошибок без b/r.

Оглавление книги