Тип процедуры, которая будет использована для восстановления базы данных, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта.
Если базе данных нанесены обширные повреждения (например, разрушилась магнитная головка диска, так называемый “жесткий” сбой), то потребуется восстановить ее последнюю резервную копию, после чего повторить в ней все выполненные транзакции, сведения о которых присутствуют в журнале регистрации. Безусловно, предполагается, что файл журнала поврежден не был. Рекомендуется во всех случаях, когда это возможно, файл журнала создавать на дисковых носителях, отличных от тех, на которых размещены основные файлы базы данных. Подобное решение снижает риск одновременной потери, как файлов базы данных, так и файла ее журнала.
Если база данных не получила физических повреждений, но лишь утратила согласованность размещенных в ней данных (например, из-за аварийного останова системы в процессе обработки транзакций, так называемый “мягкий” сбой), то достаточно будет отменить те изменения, которые вызвали переход базы данных в несогласованное состояние. Кроме того, возможно потребуется повторно прогнать некоторые транзакции, чтобы иметь уверенность в том, что внесенные в них изменения действительно зафиксированы во вторичной памяти. В данном случае нет необходимости обращаться к резервной копии базы данных, поскольку вернуть базу в согласованное состояние можно с помощью информации о содержимомполей дои после модификации, сохраняемой в файле журнала.
Дальше мы подробно рассмотрим два метода восстановления, которые могут быть применены в последнем из указанных выше случаев – т.е. когда база данных не была полностью разрушена, но лишь утратила согласованное состояние. Предлагаемые методы, известные как метод отложенного обновленияиметод немедленного обновления,отличаются друг от друга способом внесения обновлений во вторичную память. Кроме того, мы бегло познакомимся с альтернативным методом, известным как метод теневых страниц.
Метод восстановления с использованием отложенного обновления. При использовании этого протокола, обновления не заносятся в базу данных тех пор, пока транзакция не выдаст команду фиксации выполненных изменений. Если выполнение транзакции будет прекращено до достижения этой точки, никаких изменений в базе данных выполнено не будет, поэтому не потребуется и их отмена. Однако в данном случае может потребоваться повторный прогон уже завершившихся транзакций, поскольку их результаты могли еще не достичь вторичной памяти. При применении данного метода, файл журнала используется с целью восстановления следующим образом.
1) При запуске транзакции в журнал помещается запись: Начало транзакции.
2) При выполнении любой операции записи, помещаемая в файл журнала строка содержит все указанные выше данные (за исключением значения элементов данных до обновления). Реально запись изменений в буфере СУБД или саму базу данных не производится.
3) Когда транзакция достигает своей конечной точки, в журнал помещается запись: Транзакция завершена. Все записи журнала по данной транзакции выводятся на диск, после чего выполняется фиксация внесенных транзакцией изменений. Для внесения действительных изменений в базу данных используется информация, помещенная в файл журнала.
4) В случае отмены выполнения транзакции, записи журнала по данной транзакции аннулируются и не выводятся на диск.
Обратите внимание на то, что записи журнала по выполненной транзакции выводятся на диск до того, как ее результаты будут зафиксированы. Поэтому, если отказ базы данных произойдет в процессе действительного выполнения обновлений в базе данных, помещенные в журнал сведения сохранятся и требуемые обновления можно будет выполнить позже. В случае отказа файл журнала анализируется с целью выявления транзакций, которые находились в процессе выполнения в момент отказа, начиная с последней строки. Файл журнала просматривается в обратном направлений вплоть до записи о последней выполненной контрольной точке.
5) Любые транзакции, для которых в файле журнала присутствуют записи Начало транзакциии Транзакция завершенадолжны быть выполнены повторно. Процедура повторного прогона транзакций выполняет все операции записи в базу данных, используя информацию о состоянии элемент данных после обновления,содержащуюся в записях журнала по данной транзакции, причем в том порядке, в каком они были записаны в файле журнала. Если эти операции записи уже были успешно завершены до возникновения отказа, это не окажет никакого влияния на состояние элементов данных, поскольку они не могут быть испорчены, если будут записываться еще раз. Однако этот метод гарантирует, что будут обновлены любые элементы данных, которые не были корректно обновлены до момента отказа.
6) Любая транзакция, для которой в файле журнала присутствуют записи Начало транзакциии Отмена транзакции, просто игнорируется, поскольку никаких реальных обновлений информации в базе данных по ней не выполнялось, а значит, не требуется и реального выполнения их отката.
Если в процессе восстановления возникнет другой системный сбой, записи файла журнала могут быть использованы для восстановления базы данных еще раз. В данном случае не имеет значения, сколько раз каждая из строк журнала была использована для повторного внесения изменений в базу данных.
Метод восстановления с использованием немедленного обновления. При использовании этого протокола все изменения вносятся в базу данных сразу же после их выполнения в транзакции, не дожидаясь ее завершения. Помимо необходимости повторного прогона изменений, выполненных транзакциями, закончившимися до появления сбоя, в данном случае может потребоваться выполнить откат изменений, внесенных транзакциями, которые не были завершены к этому моменту. При применении данного метода файл журнала используется с целью восстановления следующим образом.
1) При запуске транзакции в журнал помещается запись: Начало транзакции.
2) При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные.
3) Как только упомянутая выше запись будет помещена в файл журнала, все выполненные обновления вносятся в буфера базы данных.
4) В собственно файлы базы данных изменения будут внесены при очередной разгрузке буферов базы данных во вторичную память.
5) Когда транзакция завершает свое выполнение, в файл журнала заносится запись: Транзакция завершена.
Очень важно, чтобы в файл журнала все записи (или хотя бы определенная их часть) помещались до внесения соответствующих изменений в базу данных. Это требование известно как протокол предварительной записи журнала.Если изменения вначале будут внесены в базу данных и сбой в системе возникнет до помещения информации об этом в файл журнала, то менеджер восстановления не будет иметь возможности отменить (или повторить) данную операцию. При использовании протокола предварительной записи журнала менеджер восстановления всегда сможет безопасно предположить, что если для определенной транзакции в файле журнала отсутствует запись Транзакция завершена, значит, эта транзакция была активна в момент возникновения отказа и, следовательно, должна быть отменена.
Если выполнение транзакции было прекращено, то для отмены выполненных ею изменений может быть использован файл журнала, так как в нем сохранены сведения об исходных значениях всех измененных элементов данных. Поскольку транзакция может выполнить несколько изменений одного и того же элемента, отмена обновлений выполняется в обратном порядке. Независимо от того, были ли результаты выполнения транзакции внесены в саму базу данных, наличие в записях журнала исходных значений полей гарантирует, что база данных будет приведена в состояние, отвечающее началу отмененной транзакции.
На случай отказа системы процедурой восстановления предусмотрено использование файла журнала для повторного прогона или отката транзакций. Для любой транзакции Т, для которой в файле журнала присутствуют записи Начало транзакции и Транзакция завершена, следует выполнить ее повторный прогон, используя для внесения в базу данных значения после изменениявсех обновленных полей – как было описано выше. Отметим, что если новые значения уже были реально внесены в файлы базы данных, повторная их перезапись, хотя и будет излишней, тем не менее не окажет на базу данных никакого отрицательного влияния. Те же изменения, которые еще не достигли базы данных к моменту отказа, будут в нее внесены в процессе восстановления. Для любой транзакции S, для которой в файле журнала присутствует запись Начало транзакции, но нет записи Транзакция завершена, необходимо выполнить откат внесенных ею изменений. На этот раз из записей файла журнала извлекается информация о значении измененных полей до их изменения, что позволяет привести базу данных в стояние, которое она имела до начала данной транзакции. Операции отмены выполняются в порядке, обратном порядку их записи в файл журнала.
Альтернативой описанным выше схемам восстановления, построенным на использовании файла журнала, является метод теневых страниц. Этот метод предусматривает организацию на время выполнения транзакции двух таблиц страниц – текущую и теневую. Когда транзакция начинает работу, обе таблицы страниц идентичны. Теневая таблица страниц никогда не изменяется и может быть использована для восстановления базы данных в случае отказа системы. В ходе выполнения транзакции текущая таблица страниц используется для записи в базу данных всех вносимых изменений. После завершения транзакции текущая таблица становится теневой таблицей. Метод теневых страниц имеет ряд преимуществ перед методами использования журнала транзакций: исключается нагрузка, связанная с ведением журнала транзакций, процесс восстановления происходит существенно быстрее, поскольку нет необходимости в повторном прогоне или откате операций. Однако ему свойственны и определенные недостатки: фрагментация данных и необходимость периодического выполнения процедуры сборки мусора для возвращения в систему неиспользуемых блоков памяти.
