* Файл теневой копии не менее уязвим от "бросков и стрел жестокой фортуны", чем любые другие файлы вашей файловой системы.
* Одна потеря или повреждение файла теневой копии делает все теневое копирование бесполезным.
* Смерть диска или ненадежный модуль памяти способны принести огромный вред до того, как они полностью разрушат вашу базу данных. Каждый ошибочный фрагмент будет точно записан в теневую копию.
В дополнение нужно сказать, что теневая копия не может принимать соединения. Никогда не пытайтесь соединяться с теневой копией или влиять на нее при использовании инструментов системы или базы данных. Сервер "знает", что он должен сделать с теневой копией для ее преобразования в активную базу данных.
! ! !
СОВЕТ. Не будет серьезных проблем, если теневая копия случайно повреждена или удалена. Пока вы знаете, что случайности могут произойти, теневая копия для здоровья базы данных может быть восстановлена в любое время просто удалением копии и новым ее созданием.
. ! .
Реализация теневого копирования
В Firebird существует синтаксис DDL для создания и удаления теневых копий с различными предложениями для задания размещения, режима работы и размера файла. Изменение теневой копии требует удаления существующей копии и создания новой с новыми спецификациями.
Теневая копия, которая является одним дисковым файлом, называется файлом теневой копии. Теневая копия, состоящая из нескольких файлов, - которые могут располагаться более чем на одном диске, - называется набором теневых копий. Наборы теневых копий группируются в множество наборов теневых копий [39] Для автора оказалось невозможным найти кого-нибудь, кто мог бы объяснить преимущества (если они существуют) ведения множества наборов теневых копий. Система нумерации могла быть результатом некоторой функциональности, которая никогда не была реализована. При отсутствии лучшей информации, похоже, имеет смысл остановиться на одном наборе
.
Размещение и распределение файлов теневой копии
Теневая копия должна быть создана на жестком диске, отличном от диска размещения файлов активной базы данных, поскольку одной из главных целей теневого копирования является восстановление работоспособности при сбоях диска.
Дисковое устройство должно быть физически подключено к машине, на которой выполняется сервер Firebird. Файлы в наборе теневых копий могут находиться на разных дисках для улучшения ввода/вывода и выделения дискового пространства. Как и спецификации файлов базы данных, спецификации для теневых копий являются зависимыми от платформы.
Варианты теневой копии
Режим (AUTO или MANUAL)
Установка режима - автоматический (с или без атрибута условная, CONDITIONAL) или ручной - определяет, что произойдет, если теневая копия станет недоступной.
Режим AUTO устанавливается по умолчанию. Он позволяет базе данных продолжить работу в случае, когда теневая копия станет недоступной, или наоборот, теневая копия будет целой, а диск с базой данных окажется поврежден.
* В момент, когда теневая копия станет недоступной, появится окно, чтобы проинформировать об этом администратора базы данных.
* Если ставшая недоступной теневая копия была создана с атрибутом CONDITIONAL, Firebird автоматически создает новую теневую копию, если это возможно.
* Если теневое копирование не является условным, то понадобится заново создать теневую копию вручную.
Режим MANUAL прекращает дальнейший доступ к базе данных в случае, когда теневая копия становится недоступной. Закройте ее, если продолжение теневого копирования является более важным, чем продолжение операций с базой данных.
Для восстановления соединения администратор должен удалить старый файл теневой копии, удалить на нее ссылки и создать новую теневую копию.
Условное теневое копирование
Одной из причин, по которой теневая копия становится недоступной, является ситуация, когда она принимает на себя функции главной базы данных в случае "гибели" аппаратуры существующей базы данных - как-никак это основная идея теневого копирования [40] CONDITIONAL SHADOW на самом деле имеет смысл как дополнение к AUTO, и только. Если CONDITIONAL создана как второй набор по отношению к AUTO, то она будет пустой до тех пор, пока с базой или с AUTO SHADOW не произойдет сбой. При сбое CONDITIONAL SHADOW будет наполнена страницами из целого файла и примет на себя функции альтернативной копии, таким образом даже в случае сбоя дисковой системы будет существовать две копии базы данных. И, разумеется, CONDITIONAL SHADOW не имеет смысла как дополнение к manual shadow (как и комбинация из двух SHADOW- AUTO + MANUAL), Т. к. при MANUAL в случае сбоя работа сервера с базой останавливается. - Прим. науч. ред.
!
Читать дальше