Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 26)

Буфера СУБД занимают определенную часть оперативной памяти и используются для обмена информацией данными со вторичной памятью. Только после того как соответствующий буфер выгружен во вторичную память, можно считать, что выполненные операции обновления приобрели постоянный характер.

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

Если на момент отказа системы транзакция еще не была завершена, менеджер восстановления должен отменить любые е результаты (откатить). Если требуется откатить только одну транзакцию, то это – частичный откат. Кроме того, транзакция может отменяться по внутренним причинам – по требованию пользователя или в результате возникновения исключительной ситуации в прикладной программе. Если требуется выполнить откат всех активных транзакций, то это – глобальный откат.

Функции восстановления

Типичная СУБД должна предоставлять такие функции восстановления как:

• механизм резервного копирования, предназначенного для периодического создания копий БД;

• средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в БД изменения;

• функции создания контрольных точек, обеспечивающих перенос выполняемых в БД изменений во вторичную память с целью сделать их постоянными;

• менеджер восстановления, обеспечивающий восстановление согласованного состояния БД, нарушенного в результате отказа.

Механизм резервного копирования. Любая СУБД должна предоставлять механизм, позволяющий создавать резервную копию БД и ее файла журнала через установленные промежутки времени и без необходимости останавливать систему. Резервное копирование может выполняться для Бд в целом или в инкрементном режиме. В последнем случае в копию помещаются сведения только об изменениях. Как правило резервные копии создаются на автономных носителях – например, на магнитных лентах.

Файл журнала. Для фиксации хода выполнения транзакций в БД СУБД использует специальный файл, который называется журналом. В него может помещаться след. информация:

• записи о транзакциях, включающие:

• идентификатор транзакции;

• тип записи журнала (начало транзакции, операции вставки, обновления или удаления, отмены или фиксации транзакции);

• идентификатор элемента данных, вовлеченного в операцию обработки БД,

• копию элемента данных до операции;

• копию элемента данных после операции;

• служебную информацию файла журнала, включающую указатели на предыдущую и последующую записи журнала для этой транзакции;

• записи контрольных точек.

Часто журнал используется и для других целей, отличных от целей восстановления. В этом случае он может содержать дополнительную информацию (например, сведения о пользователях, об операциях, о завершении сеанса пользователя).

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

Один из подходов к автономной обработке файла журнала состоит в разделении оперативного файла на две независимые части, организованные в виде файлов с произвольным доступом. Записи журнала помещаются в первый файл до тех пор, пока он не оказывается заполненным до установленного уровня (например, на 70%). Затем открывается второй файл и все записи журнала для новых транзакций помещаются уже в него. Сведения о старых транзакциях помещаются в первый файл до тех пор, пока обработка всех старых транзакций не будет завершена. В этот момент первый файл закрывается и переводится в автономное состояние. Подобный подход упрощает восстановление отдельных транзакций, т.к. записи о каждой транзакции всегда содержатся в одном фрагменте файла журнала – либо в оперативном, либо в автономном. Следует отметить, что файл журнала потенциально является узким местом с точки зрения производительности любых систем, поэтому скорость записи информации в файл журнала может оказаться одним из важнейших факторов, определяющих общую производительность системы с БД.

Создание контрольных точек.

Контрольная точка – это момент синхронизации между базой данных и журналом регистрации транзакций. Все буфера системы принудительно записываются во вторичную память системы.

Контрольные точки организуются через установленный интервал времени и включают выполнение следующих действий.

• Запись всех имеющихся в ОЗУ записей журнала во вторичную память;

• Запись всех модифицированных блоков в буфера БД во вторичную память;

• Помещение в файл журнала записи контрольной точки. Эта запись содержит идентификаторы всех транзакций, которые были активны в момент создания этой контрольной точки.

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

Методы восстановления

Тип процедуры, которая будет использоваться для восстановления БД, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта:

• Если базе данных нанесены обширные повреждения (например, разрушилась магнитная головка диска), то потребуется восстановить ее последнюю резервную копию, после чего повторить в ней все выполненные транзакции, сведения о которых присутствуют в журнале регистрации. Безусловно, предполагается, что файл журнала поврежден не был. Рекомендуется, чтобы во всех случаях, когда это возможно, файл журнала создавался на дисковых носителях, отличных от тех, на которых размещены основные файлы базы данных. Подобное решение снижает риск одновременной потери как файлов базы данных, так и файла ее журнала.

• Если база данных не получила физических повреждений, но лишь утратила согласованность размещенных в ней данных (например, из-за аварийного останова системы в процессе обработки транзакций), то достаточно будет отменить те изменения, которые вызвали переход базы данных в несогласованное состояние. Кроме того, возможно потребуется повторно прогнать некоторые транзакции, чтобы иметь уверенность в том, что внесенные в них изменения действительно зафиксированы во вторичной памяти. В данном случае нет необходимости обращаться к резервной копии базы данных, поскольку вернуть БД в согласованное состояние можно с помощью информации о содержимом полей до и после модификации, сохраняемой в файле журнала. Далее будем рассматривать только 2-й случай.

Метод восстановления с использованием отложенного обновления

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

• При запуске транзакции в журнал помещается запись Начало транзакции.

• При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные (за исключением значения элементов данных до обновления). Реально запись изменений в буфере СУБД или саму БД не производится.

• Когда транзакция достигает своей конечной точки, в журнал помещается запись Транзакция завершена. Все записи журнала по данной транзакции выводятся на диск, после чего выполняется фиксация внесенных транзакцией изменений. Для внесения действительных изменений в БД используется информация, помещенная в файл журнала.

• В случае отмены выполнения транзакции записи журнала по данной транзакции аннулируются и не выводятся на диск.

• Любые транзакции, для которых в файл журнала присутствуют записи Начало транзакции и Транзакция завершена должны быть выполнены повторно. Процедура повторного прогона транзакций выполняет все операции записи в БД, используя информацию о состоянии элемента данных после обновления, содержащуюся в записях журнала по данной транзакции, причем в том порядке, в каком они были записаны в файл журнала. Если эти операции записи уже были успешно завершены до возникновения отказа, это не окажет никакого влияния на состояния элементов данных, поскольку они не могут быть испорчены, если будут записаны еще раз. Однако, этот метод гарантирует, что будут обновлены любые элементы данных, которые не были корректно обновлены до момента отказа.

• Любая транзакция, для которой в файле журнала присутствуют записи Начало транзакции и Отмена транзакции, просто игнорируются, поскольку никаких реальных обновлений информации в БД по ней не выполнялось, а значит, не требуется и реального выполнения их отката.

Метод восстановления с использованием немедленного обновления

При использовании этого протокола все изменения вносятся в БД сразу же после из выполнения в транзакции, не дожидаясь ее завершения. Помимо необходимости повторного прогона изменений, выполненных транзакциями, закончившимися до появления сбоя, в данном случае может потребоваться выполнить откат изменений, внесенных транзакциями, которые не были завершены к этому моменту. При применении данного метода файл журнала используется с целью восстановления следующим образом.

• При запуске транзакции в журнал помещается запись Начало транзакции.

• При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные.

• Как только упомянутая выше запись будет помещена в файл журнала, все выполненные обновления вносятся в буфера БД.

• В собственно файлы базы данных изменения будут внесены при очередной разгрузке буферов БД во вторичную память.

• Когда транзакция завершает свое выполнение, в файл журнала заносится запись Транзакция завершена.

Очень важно, чтобы в файл журнала все записи (или хотя бы определенная их часть) помещалась до внесения соответствующих изменений в БД. Это требование известно как протокол предварительной записи журнала. При использовании этого протокола менеджер восстановления всегда сможет безопасно предположить, что если для определенной транзакции в файле журнала отсутствует запись Транзакция завершена, то это значит, что эта транзакция была активна в момент возникновения отказа, и, следовательно, должна быть отменена.

Если выполнение транзакции было прекращено, то для отмены выполненных ею изменений может быть использован файл журнала, так как в нем сохранены сведения об исходных значениях всех измененных элементов данных.

На случай отказа системы процедурой восстановления предусмотрено использование файла журнала для повторного прогона или отката транзакций.

Метод теневых страниц

Этот метод предусматривает организацию на время выполнения транзакции двух таблиц страниц – текущую и теневую. Когда транзакция начинает работать, обе таблицы идентичны. Теневая таблица страниц никогда не изменяется и может быть использована для восстановления БД в случае отказа системы. В ходе выполнения транзакции текущая таблица страниц используется для записи в БД всех вносимых изменений. После завершения транзакции текущая таблица страниц становится теневой таблицей. Этот метод имеет ряд преимуществ перед предыдущими методами:

• исключается нагрузка, связанная с ведением журнала транзакций;

• процесс восстановления происходит значительно быстрее, поскольку нет необходимости в повторном прогоне или откате операций.

Однако ему свойственны и определенные недостатки: фрагментация данных и необходимость периодического выполнения процедуры сборки мусора для возврщения в систему неиспользуемых блоков памяти.

7. ЭКСПЛУАТАЦИЯ БАЗ ДАННЫХ

Типичная СУБД обычно предоставляет различные утилиты администрирования БД, включая утилиты загрузки данных и контроля за функционированием системы.

БД и СУБД являются корпоративными ресурсами, которыми следует управлять так же, как и любыми другими ресурсами. Управление данными и БД предусматривает управление и контроль за СУБД и помещенными в нее данными. Администратор данных (АД) отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, бизнес - правил и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации руководству высшего звена, контролируя соответствие общего направления развития базы данных, установленным корпоративными целями.

Администратор базы данных (АБД) отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение безопасности и целостности данных, за сопровождение операционной системы, а также за обеспечение максимальной производительности приложений и пользователей. По сравнению с АД, обязанности АБД носят более технический характер, и для него необходимо знание конкретной СУБД и системного окружения. В одних организациях между этими ролями не делятся различий, а в других важность корпоративных ресурсов отражена именно в выделении отдельных групп персонала с указанным кругом обязанностей.

В проектировании больших БД участвуют два разных типа разработчиков: разработчики логической базы данных и разработчики физической базы данных. разработчик логической БД занимается идентификацией данных (т.е. сущностей и их атрибутов), связей между данными и устанавливает ограничения, накладываемые на хранимые данные. Он должен обладать всесторонним и полным пониманием структуры данных организации и ее бизнес - правил. Бизнес правила описывают основные характеристики данных с точки зрения организации. Например, «Любой сотрудник не может отвечать одновременно более чем за десять сдаваемых в аренду или продаваемых объектов недвижимости».

Для более эффективной работы разработчик логической БД должен как можно раньше вовлечь всех предполагаемых пользователей БД в процесс создания модели данных. Работа разработчика логической БД делится на два этапа:

• Концептуальное проектирование БД, которое совершенно не зависит от таких деталей ее воплощения, как конкретная целевая СУБД, приложения, языки программирования или любые другие физические характеристики.

• Логическое проектирование БД, которое проводится с учетом особенностей выбранной модели данных: реляционной, сетевой, иерархической или объектно-ориентированной.

Разработчик физической БД получает готовую логическую модель данных, занимается ее физической реализацией, в том числе:

• преобразование логической модели данных в набор таблиц и ограничений целостности данных;

• выбором конкретных структур хранения и методов доступа к данным, обеспечивающих необходимый уровень производительности при работе с БД;

• проектированием любых требуемых мер защиты данных.

Многие этапы физического проектирования БД в значительной степени зависят от выбранной целевой СУБД.

Характеристики

Список файлов книги