Файл инициализации в процессе работы используется только для чтения параметров и никак не меняется. Поэтому для создания резервной копии файла инициализации достаточно скопировать его командой операционной системы. Команду операционной системы можно выполнить и с помощью функции system из SQL-скрипта.
Например:
system('copy c:/HYTECH/sql64.ini c:/backup', '');
В примере файл инициализации sql64.ini будет скопирован в каталог резервной копии C:/BACKUP.
Достоинства архивирования БД в оперативном режиме:
· На время работы не требуется останов БД, и пользователи могут работать с таблицами системы, которые в настоящий момент не архивируются. В целом, время простоя системы (ограничения функций) по причинам выполнения операций резервного копирования может быть снижено по сравнению с временем простоя в случае автономного архивирования.
· Гибкость: копироваться могут только те таблицы БД и управляющие файлы, которые требуются. Громе того, существенно больше возможностей по выбору времени, когда копирование может быть выполнено.
· Архив занимает меньше места, поскольку не копируются индексы.
Недостатки:
· Процедура резервного копирования и восстановления более сложная, чем в случае автономного архивирования.
· Как и в случае автономного архивирования, в оперативном режиме выполняется копирование всех данных таблицы, что может также занять значительное время.
Планирование стратегии архивирования базы данных
При разработке информационной системы необходимо разработать и стратегию архивирования ее БД. Для этого необходимо рассмотреть следующие вопросы:
· Как следует выполнять архивирование, и в каком объеме?
· Как часто следует архивировать базу данных?
· Как долго следует хранить старые копии базы данных?
· Где следует хранить старые копии базы данных?
При разработке стратегии рекомендуется следовать следующим правилам:
· Архивирование следует выполнять регулярно, через относительно небольшие промежутки времени. Чем больше интервал времени между архивациями, тем больше усилий будет затрачено на восстановление базы данных и тем меньше вероятность, что архив будет полезен.
· Архивирование должно обязательно производиться непосредственно перед и сразу после внесения изменений в структуру БД. В этом случае пользователь застрахован от возможных потерь данных при некорректных структурных изменениях.
· Всегда следует держать несколько старых архивных файлов. Это позволит частично застраховаться от ранее незамеченных ошибок. В общем случае глубина архива должна соответствовать потенциальной возможности и целесообразности восстановления БД.
· Наиболее актуальный архив (а лучше и часть старых) должен храниться на нескольких конструктивно и энергетически независимых территориально удалённых носителях. Например, на DVD-R, флеш-носителе и внешнем HDD, расположенных в разных помещениях.
· Если используемое прикладное ПО предусматривает функцию архивирования, её также следует использовать. Например, для подсистемы «Отдел кадров» это будет функция выгрузки в отдельные таблицы списка уволенных сотрудников по годам. Сведения подобного рода можно архивировать однократно.
Для выполнения успешного восстановления базы данных необходимо регулярно тестировать архивные копии. Это обеспечит проверку правильности выбранной стратегии архивирования и проверку работоспособности всех используемых программных и аппаратных компонентов.
Для проверки стратегии восстановления базы данных надо выбрать время, когда можно остановить базы данных на достаточно большой период. Далее необходимо сначала скопировать все файлы рабочей базы данных, создав резервные копии, которые останутся в неприкосновенности. Этот шаг важен для защиты рабочей базы данных на тот случай, если с копией базы данных возникнут проблемы. Затем надо восстановить базу данных, воспользовавшись для этого тестируемой копией. После процедуры копирования и восстановления надо проверить, корректно ли работает восстановленная база данных. Тестирование архивных копий позволяет своевременно обнаружить проблемы в архивировании базы данных и накопить необходимый опыт восстановления базы данных.
