был. Рекомендуется, чтобы во всех случаях, когда это возможно, файл журнала создавался на дисковых носителях, отличных от тех, на которых размещены основные файлы базы данных. Подобное решение снижает риск одновременной потери как файлов базы данных, так и файла ее журнала.
Если база данных не получила физических повреждений, но лишь утратила согласованность размещенных в ней данных (например, из-за аварийного останова системы в процессе обработки транзакций), то достаточно будет отменить те изменения, которые вызвали переход базы данных в несогласованное состояние. Кроме того, возможно потребуется повторно прогнать некоторые транзакции, чтобы иметь уверенность в том, что внесенные в них изменения действительно зафиксированы во вторичной памяти. В данном случае нет необходимости обращаться к резервной копии базы данных, поскольку вернуть БД в согласованное состояние можно с помощью информации о содержимом полей до и после модификации, сохраняемой в файле журнала. Далее будем рассматривать только 2-й случай.
Метод восстановления с использованием отложенного обновления
При использовании этого протокола обновления не заносятся в БД до тех пор, пока транзакция не выдаст команду фиксации выполненных изменений. Если выполнение транзакции будет прекращено до достижения этой точки, никаких изменений в БД выполнено не будет, поэтому не потребуется и их отмена. Однако в данном случае может потребоваться повторный прогон уже завершившихся транзакций, поскольку их результаты могли еще не достичь вторичной памяти. При применении данного метода файл журнала используется с целью восстановления следующим образом.
При запуске транзакции в журнал помещается запись
Начало транзакции.
201
При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные (за исключением значения элементов данных до обновления). Реально запись изменений в буфере СУБД или саму БД не производится.
Когда транзакция достигает своей конечной точки, в журнал помещается запись Транзакция завершена. Все записи журнала по данной транзакции выводятся на диск, после чего выполняется фиксация внесенных транзакцией изменений. Для внесения действительных изменений в БД используется информация, помещенная в файл журнала.
В случае отмены выполнения транзакции записи журнала по данной транзакции аннулируются и не выводятся на диск.
Любые транзакции, для которых в файл журнала присутствуют записи Начало транзакции и Транзакция завершена должны быть выполнены повторно. Процедура повторного прогона транзакций выполняет все операции записи
вБД, используя информацию о состоянии элемента данных после обновления, содержащуюся в записях журнала по данной транзакции, причем в том порядке, в каком они были записаны
вфайл журнала. Если эти операции записи уже были успешно завершены до возникновения отказа, это не окажет никакого влияния на состояния элементов данных, поскольку они не могут быть испорчены, если будут записаны еще раз. Однако, этот метод гарантирует, что будут обновлены любые элементы данных, которые не были корректно обновлены до момента отказа.
Любая транзакция, для которой в файле журнала присутствуют записи Начало транзакции и Отмена транзакции, просто игнорируются, поскольку никаких реальных обновлений информации в БД по ней не выполнялось, а значит, не требуется и реального выполнения их отката.
202
Метод восстановления с использованием немедленного обновления
При использовании этого протокола все изменения вносятся в БД сразу же после из выполнения в транзакции, не дожидаясь ее завершения. Помимо необходимости повторного прогона изменений, выполненных транзакциями, закончившимися до появления сбоя, в данном случае может потребоваться выполнить откат изменений, внесенных транзакциями, которые не были завершены к этому моменту. При применении данного метода файл журнала используется с целью восстановления следующим образом.
При запуске транзакции в журнал помещается запись Начало транзакции.
При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные.
Как только упомянутая выше запись будет помещена в файл журнала, все выполненные обновления вносятся в буфера БД.
В собственно файлы базы данных изменения будут внесены при очередной разгрузке буферов БД во вторичную память.
Когда транзакция завершает свое выполнение, в файл журнала заносится запись Транзакция завершена.
Очень важно, чтобы в файл журнала все записи (или хотя бы определенная их часть) помещалась до внесения соответствующих изменений в БД. Это требование известно,
как протокол предварительной записи журнала. При использовании этого протокола менеджер восстановления всегда сможет безопасно предположить, что если для определенной транзакции в файле журнала отсутствует запись Транзакция завершена, то это значит, что эта транзакция была активна в момент возникновения отказа, и, следовательно, должна быть отменена.
Если выполнение транзакции было прекращено, то для отмены выполненных ею изменений может быть использован
203
файл журнала, так как в нем сохранены сведения об исходных значениях всех измененных элементов данных.
На случай отказа системы процедурой восстановления предусмотрено использование файла журнала для повторного прогона или отката транзакций.
Метод теневых страниц
Этот метод предусматривает организацию на время выполнения транзакции двух таблиц страниц – текущую и теневую. Когда транзакция начинает работать, обе таблицы идентичны. Теневая таблица страниц никогда не изменяется и может быть использована для восстановления БД в случае отказа системы. В ходе выполнения транзакции текущая таблица страниц используется для записи в БД всех вносимых изменений. После завершения транзакции текущая таблица страниц становится теневой таблицей. Этот метод имеет ряд преимуществ перед предыдущими методами:
-исключается нагрузка, связанная с ведением журнала транзакций;
-процесс восстановления происходит значительно быстрее, поскольку нет необходимости в повторном прогоне или откате операций.
Однако ему свойственны и определенные недостатки: фрагментация данных и необходимость периодического выполнения процедуры сборки мусора для возврщения в систему неиспользуемых блоков памяти.
204
7. ЭКСПЛУАТАЦИЯ БАЗ ДАННЫХ
Типичная СУБД обычно предоставляет различные утилиты администрирования БД, включая утилиты загрузки данных и контроля за функционированием системы.
БД и СУБД являются корпоративными ресурсами, которыми следует управлять так же, как и любыми другими ресурсами. Управление данными и БД предусматривает управление и контроль за СУБД и помещенными в нее данными. Администратор данных (АД) отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, бизнес - правил и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации руководству высшего звена, контролируя соответствие общего направления развития базы данных, установленным корпоративными целями.
Администратор базы данных (АБД) отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение безопасности и целостности данных, за сопровождение операционной системы, а также за обеспечение максимальной производительности приложений и пользователей. По сравнению с АД, обязанности АБД носят более технический характер, и для него необходимо знание конкретной СУБД и системного окружения. В одних организациях между этими ролями не делятся различий, а в других важность корпоративных ресурсов отражена именно в выделении отдельных групп персонала с указанным кругом обязанностей.
В проектировании больших БД участвуют два разных типа разработчиков: разработчики логической базы данных и разработчики физической базы данных. разработчик логической БД занимается идентификацией данных (т.е. сущностей и их атрибутов), связей между данными и устанавливает ограничения, накладываемые на хранимые данные. Он должен обладать всесторонним и полным пониманием структуры
205