А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Режим синхронной записи на диск (FW ON) является более безопасным и приводит к минимизации возможной потери данных, однако следствием его применения является некоторая потеря производительности. Режим асинхронной записи (FW OFF) увеличивает производительность, однако значительно возрастает риск потери большого количества данных.
Для получения максимально возможной производительности обычно устанавливают режим FW OFF, в результате чего при сбое питания теряется гораздо большее количество данных, чем при синхронном режиме записи на диск. При установке режима записи следует хорошенько взвесить, насколько увеличение производительности важнее возможности потерять несколько часов работы при неожиданном сбое питания.
Часто сами пользователи грешат неджентльменским отношением к InterBase. В небольших организациях, где экономят на любых мелочах, зачастую на компьютер-сервер, на котором установлен сервер СУБД, также ставят другие серверные (и не только серверные) программы. И в случае их "зависания", недолго думая, нажимают на Reset, что повторяется несколько раз на дню. Хотя InterBase является необычайно устойчивым к таким действиям по сравнению с другими СУБД и позволяет начать работу с базой данных сразу после аварийной перезагрузки, однако такое обращение не проходит бесследно. В результате аварийных перезагрузок накапливаются потерянные страницы, теряются связи между страницами данных. Это может продолжаться довольно долго, однако развязка рано или поздно наступит. Когда "битые страницы" появятся среди страниц учета страниц (PIP) или затронут страницы генераторов или, еще хуже, испортится заголовочная страница базы данных, то база данных может просто больше не открыться и превратиться в большой кусок разрозненных данных, из которого нельзя извлечь ни байта полезной информации.
Повреждения жесткого диска
К такому же печальному результату могут привести повреждения жесткого диска (появление bad sectors) и нехватка дискового пространства в момент расширения базы данных. В последнем случае может произойти очень неприятная вещь: InterBase укажет на заголовочной странице, что файл базы данных теперь состоит из N страниц, в то время как реальное расширение файла до указанного размера аварийно прервется из-за нехватки дискового пространства. При этом скорее всего произойдет аварийное завершение сервера, затем он запустится снова и попытается подключиться к базе данных. Сравнит количество декларированных страниц в заголовке базы данных с реальным размером файла и откажется работать с таким файлом, выдав сообщение об ошибке "Unexpected end of file". Именно такой случай поломки базы данных мы подробно рассмотрим ниже.
Ошибки проектирования базы данных
Необходимо также рассказать о некоторых ошибках, допускаемых разработчиками базы данных, которые могут привести к невозможности восстановления базы данных из резервной копии (файлы *.gbk, создаваемые программой gbak). Прежде всего это небрежное обращение с ограничениями целостности на уровне базы данных. Типичный пример - это ограничения NOT NULL. Предположим, что мы имеем таблицу, которая заполнена некоторым количеством записей. Теперь мы добавим к такой таблице с помощью команды ALTER TABLE еще один столбец, причем укажем, что он не может содержать неопределенных значений NULL, примерно так:
ALTER TABLE sometable ADD Fieldl INTEGER NOT NULL
И в данном случае не возникнет никакой ошибки, как этого можно было бы ожидать. Эта модификация метаданных выполнится, и мы не получим никаких сообщений об ошибках или предупреждений, что создает иллюзию нормальности данной ситуации. Однако если теперь мы произведем резервное копирование базы данных (backup) и попытаемся восстановить (restore) базу данных из этой резервной копии, то на этапе восстановления получим сообщение об ошибке (о том, что в столбец, имеющий ограничение NOT NULL, вставляются NULL) и процесс восстановления прервется. Эта резервная копия невосстановима. Если же восстановление было направлено в файл, имеющий то же имя, что и существующая база данных (т. е. при восстановлении перезаписывался существующий рабочий файл базы данных), то потеряем всю имеющуюся информацию. Это связано с тем, что ограничения NOT NULL реализуются с помощью системных триггеров, которые проверяют лишь вновь поступающие данные, т. е. "срабатывают" при вставке и модификации записей, а существующие данные обходят своим вниманием. При восстановлении же все данные из резервной копии вставляются в пустые, только что созданные таблицы; вот тут-то и выявляются недопустимые NULL в столбце с ограничением NOT NULL.
Некоторые программисты считают такое поведение InterBase ошибкой, но другое поведение просто не позволяет добавить поле с ограничением NOT NULL к таблице с данными. Вариант с требованием обязательного значения по умолчанию и заполнения им в момент создания публично обсуждался архитекторами Firebird, но не был принят из тех соображений, что программист, очевидно, намерен заполнить его в соответствии с каким-то алгоритмом, в общем случае довольно сложным и, возможно, итеративным. При этом не исключено, что он не будет иметь возможности отличить записи, пропущенные предыдущей итерацией, от незаполненных записей.
Похожий дефект данных может возникать в результате сбоев алгоритма сборки "мусора" из-за некорректного задания пути к базе (причина повреждения, указанная в п. 3) при соединении и при файловом доступе к файлам базы данных во время работы с ней сервера 4). При этом в некоторых таблицах могут появиться записи, целиком заполненные NULL. Выявить такие записи довольно сложно, поскольку они не соответствуют ограничениям контроля целостности и уникальности данных, наложенным на таблицы, и оператор Select их просто "не видит", хотя в резервную копию они попадают. В случае невозможности восстановления по этой причине следует обработать исходную базу программой gfix (см. ниже), найти и удалить такие записи, используя неиндексированные атрибутные поля в качестве условий поиска, после чего повторить попытку снятия резервной копии и восстановления из нее базы.
Подводя итог, можно сказать, что причин возникновения тех или иных поломок базы данных существует большое количество и всегда следует рассчитывать на худшее, а именно, что база данных по ч ой или иной причине повредится. Значит надо быть готовым ее восстановить и спасти ценную информацию. Далее мы рассмотрим профилактические процедуры, гарантирующие сохранность баз данных InterBase, а также способы починки поврежденных баз данных.
Профилактика повреждений баз данных InterBase
Профилактические действия, которые следует производить для предотвращения поломок баз данных, - это постоянное создание резервных копий (подробно о резервном копировании см. главу "Резервное копирование и восстановление из резервной копии"). Это самый надежный рубеж обороны против повреждений базы данных. Только резервное копирование дает 100%-ную гарантию сохранности данных. Но, как описано выше, в результате резервного копирования может получиться и невосстановимая, т. е. бесполезная, копия, поэтому восстановление базы из копии никогда не должно выполняться путем записи поверх оригинала и резервное копирование должно следовать определенным правилам.
Во-первых, резервное копирование должно быть как можно более частым, во-вторых, оно должно быть последовательным, и, в-третьих, резервные копии нужно проверять на возможность восстановления.
Частое резервное копирование означает, что нужно достаточно часто делать резервную копию, например один раз в сутки. Чем меньше промежуток данных между резервным копированием базы данных, тем меньше данных потеряется в результате сбоя.
Последовательность резервного копирования означает, что резервные копии должны накапливаться и храниться как минимум неделю. Если есть возможность, то нужно записывать резервные копии на специальные устройства типа стримера, если нет - то хотя бы скопировать их на другой компьютер. История резервных копий позволит отследить скрытые повреждения и справиться с ошибкой, которая возникла давно, а проявилась, как всегда, неожиданно.
Необходимо проверять, можно ли восстановить без ошибок полученную резервную копию. Проверить это можно только одним способом - через тестовый процесс восстановления (restore). Надо сказать, что процесс восстановления занимает примерно в 3 раза больше времени, чем резервное копирование, и для больших баз проверку на восстановление ежедневно делать затруднительно, так как это может прервать работу пользователей на несколько часов, т. е. ночного перерыва может и не хватить. Конечно, организациям, имеющим базы данных такого большого объема лучше, не экономить "на спичках" и выделить отдельный компьютер для этих целей.
В том случае, если сервер должен функционировать при значительной нагрузке по 24 часа 7 дней в неделю, можно воспользоваться механизмом SHADOW для снятия "моментальных" снимков с базы данных и дальнейших операций по резервному копированию уже с моментальной копией. Подробно процесс резервного копирования и восстановления баз данных описан в главе "Резервное копирование и восстановление базы данных из резервной копии".
