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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-05-09