Механизм резервного копирования
Любая СУБД должна предоставлять механизм, позволяющий создавать резервные копии базы данных и ее файла журнала через установленные интервалы времени. Резервная копия базы данных используется в случае повреждения или разрушения файлов базы данных во вторичной памяти. Резервное копирование может выполняться как для базы данных в целом, так и в инкрементном режиме. В последнем случае в копию помещаются сведения только об изменениях, накопившихся с момента создания предыдущей полной или инкрементной копии системы. Как правило, резервные копии создаются на автономных носителях, например, на магнитных лентах.
Файл журнала
Для фиксации хода выполнения транзакций в базе данных СУБД использует специальный файл, который называют журналом. Он содержит сведения обо всех обновлениях, выполненных в базе данных. В файл журнала может помещаться следующая информация:
– записи о транзакциях, включающие: идентификатор транзакции; тип записи журнала (начало транзакции, операции вставки, обновления или удаления, отмена или фиксация транзакции); идентификатор элемента данных, вовлеченного в операцию обработки базы данных (операции вставки, удаления и обновления); копию элемента данных до операции, т. е. его значение до изменения (только операции обновления и удаления); копию элемента данных после операции, т. е. его значение после изменения (только для операций обновления и вставки); служебную информацию файла журнала, включающую указатели на предыдущую и следующую записи журнала для этой транзакции (любые операции);
– записи контрольных точек.
Очень часто файл журнала используется и для других целей, отличных от задач восстановления (например, для сбора сведений о текущей производительности, накопления контрольной информации и т. д.). В этом случае в файл журнала может помещаться множество дополнительной информации (например, сведения об операциях чтения, о регистрации пользователей, о завершении сеансов пользователей и т. д.).
По причине его важности для процессов восстановления файл журнала транзакций может создаваться в двух и даже в трех экземплярах, которые будут автоматически поддерживаться системой. В случае повреждения одной копии при восстановлении будет использована другая. Раньше файлы журнала обычно создавались на магнитных лентах, поскольку этот носитель был надежнее и дешевле магнитных дисков. Однако в настоящее время требуется, чтобы СУБД была способна быстро восстанавливать нормальную работу в случае незначительных повреждений. В связи с этим требуется, чтобы файл журнала был доступен оперативно и создавался на устройстве, поддерживающем произвольный доступ с достаточно высокой скоростью обмена.
В некоторых больших системах, в которых каждый день генерируется огромный объем помещаемой в файл журнала информации (например, ежедневный объем в 104 Мбайт), не представляется возможным содержать все эти данные оперативно доступными в течение всего требуемого времени. Оперативный доступ к файлу журнала требуется только в случае восстановления после незначительных отказов (например, при откате транзакции в результате взаимной блокировки). В случае более тяжелых аварий (например, обрыве головки магнитного диска) на восстановление системы потребуется более длительное время. В подобных случаях простои, связанные с приведением отдельных фрагментов журнала в оперативное состояние, оказываются вполне приемлемыми.
Один из подходов к автономной обработке файла журнала состоит в разделении оперативного журнала на две независимые части, организованные в виде файлов с произвольным доступом. Записи журнала помещаются в первый файл до тех пор, пока он не оказывается заполненным до установленного уровня (например, на 70 %). Затем открывается второй файл и все записи журнала для новых транзакций записываются уже в него. Сведения о старых транзакциях помещаются в первый файл до тех пор, пока обработка всех старых транзакций не будет завершена. В этот момент первый файл закрывается и переводится в автономное состояние. Подобный подход упрощает восстановление отдельных транзакций, поскольку записи о каждой отдельной транзакции всегда содержатся в одном фрагменте файла журнала – либо в оперативном, либо в автономном. Следует отметить, что файл журнала потенциально является узким местом с точки зрения производительности любых систем, поэтому скорость записи информации в файл журнала может оказаться одним из важнейших факторов, определяющих общую производительность системы с базой данных.
Создание контрольных точек
Помещаемая в файл журнала информация предназначена для использования в процессе восстановления системы после отказа. Одно из основных затруднений в этой схеме состоит в том, что, когда происходит отказ, может отсутствовать какая-либо информация о том, насколько далеко назад следует «откатиться» в файле журнала, чтобы начать повторный прогон уже завершенных транзакций. В результате может оказаться, что повторный прогон будет выполнен для тех транзакций, которые уже были окончательно зафиксированы в базе данных. Для ограничения объема поиска и последовательной обработки информации в файле журнала используется технология создания контрольных точек.
Определение. Под контрольной точкой понимают момент синхронизации между базой данных и журналом регистрации транзакций.
Все буферы системы принудительно записываются во вторичную память системы.
Контрольные точки организуются через установленный интервал времени и включают выполнение следующих действий:
– запись всех имеющихся в оперативной памяти записей журнала во вторичную память;
– запись всех модифицированных блоков в буферах базы данных во вторичную память;
– помещение в файл журнала записи контрольной точки. Эта запись содержит идентификаторы всех транзакций, которые были активны в момент создания этой контрольной точки.
Если транзакция выполняется последовательно, то после возникновения отказа файл журнала просматривается с целью обнаружения последней из транзакций, начавших свою работу до момента создания последней контрольной точки. Любая более ранняя транзакция будет зафиксирована в базе данных. Это значит, что все ее изменения были перенесены на диск в момент создания последней контрольной точки. Следовательно, прогону подлежит только транзакция, которая была активна в момент создания контрольной точки, а также все прочие транзакции, которые начали свою работу позже, и для которых в журнале присутствуют записи как начала, так и завершения. Та транзакция, которая была активна в момент отказа, должна быть отменена. В случае, если транзакции выполняются в системе параллельно, потребуется повторный прогон всех транзакций, которые завершили свою работу с момента создания контрольной точки, и выполнение отката всех транзакций, которые были активны в момент отказа.
Обычно создание контрольных точек представляет собой относительно недорогую операцию, поэтому часто оказывается возможным создавать три или даже четыре контрольные точки в час. В результате при сбое потребуется восстановить работу, выполненную всего лишь за 15 – 20 минут.
Во время восстановления после сбоя механизм более сложен. Тот факт, что страницы базы данных не записываются на диск при фиксации транзакции, означает, что нет гарантии того, что набор страниц базы данных на диске точно отражает набор изменений, описанных в журнале транзакций — как для зафиксированных, так и для незафиксированных транзакций. Однако, в заголовке страницы всех страниц базы данных имеется поле (96-байтная часть 8192-байтной страницы, содержащая метаданные с информацией о странице), содержащее LSN последней записи журнала, оказавшей влияние на страницу. Это дает возможность системе восстановления принять решение относительно конкретной записи журнала, которую необходимо восстановить.
· Для записи журнала из зафиксированной транзакции, в которой страница базы данных имеет LSN не меньший, чем LSN записи журнала, не требуется никаких действий. Результаты воздействия записи журнала уже записаны в страницу на диске.
· Для записи журнала из зафиксированной транзакции, в которой страница базы данных имеет LSN, меньший, чем LSN записи журнала, необходимо выполнить накат записи журнала, чтобы обеспечить сохранение результатов транзакции.
· Для записи журнала из незафиксированной транзакции, в которой страница базы данных имеет LSN, не меньший, чем LSN записи журнала, необходимо выполнить откат записи журнала, чтобы результаты транзакции не были сохранены.
· Для записи журнала из незафиксированной транзакции, в которой страница базы данных имеет LSN, меньший, чем LSN записи журнала, не требуется никаких действий. Результаты воздействия записи журнала не были сохранены на странице на диске, и в таком случае ничего делать не требуется.
Механизм восстановления после сбоя прочитывает журнал транзакций и обеспечивает сохранение всех результатов зафиксированных транзакций в базе данных, а результаты всех не зафиксированных транзакций не сохраняются в базе данных — выполняются фазы REDO и UNDO, соответственно. По завершении восстановления после сбоя база данных становится согласованной с точки зрения транзакций и доступной для использования.
Ранее упоминалось, что одним из применений операции контрольной точки является сокращение количества времени, занимаемого процедурой восстановления после сбоя. Периодическое сбрасывание на диск всех «грязных» страниц сокращает число страниц, измененных зафиксированными транзакциями, но изображений которых еще нет на диске. Это, в свою очередь, сокращает число страниц, к которым требуется применять восстановление REDO во время восстановления после сбоя.
Восстановление после сбоя возможно только в том случае, если не пострадал журнал транзакций. На деле журнал транзакций является самой важной частью базы данных — это единственное место, в котором в случае сбоя гарантируется наличие описаний всех изменений базы данных.
Если журнал транзакций отсутствует или поврежден после сбоя, тогда восстановление после сбоя выполнить невозможно, в результате чего база данных становится сомнительной. В этом случае базу данных необходимо восстанавливать из резервных копий или использовать для восстановления менее желательные режимы, такие как аварийное восстановление.
Журнал транзакций представляет собой специальный файл, необходимой любой базе данных для надлежащего функционирования. Когда создается новая база данных, журнал транзакций, по существу, пуст. По мере возникновения транзакций записи журнала последовательно записываются в журнал транзакций, из чего следует, что создание нескольких файлов журнала транзакций не дает никакого выигрыша в производительности, что является широко распространенным заблуждением. Журнал транзакций будет использовать все файлы журнала по очереди.
В журнале транзакций могут перемежаться записи журнала для параллельных транзакций. Следует помнить о том, что записи журнала для одной транзакции связаны посредством своих LSN, поэтому нет необходимости все записи журнала, относящиеся к одной транзакции, группировать в одном журнале. Практически, номера LSN можно представлять себе как метку времени.
Физическая архитектура журнала транзакций показана на рис. 1. Внутренне он разбит на небольшие части, называемые виртуальными файлами журналов (или файлами VLF). Это просто вспомогательные средства для облегчения внутреннего управления журналом транзакций.
Когда файл VLF заполняется, процедура ведения журнала автоматически переходит к следующему VLF в журнале транзакций. Можно было бы подумать, что, в конце концов, журнал транзакций столкнется с нехваткой места, но именно в этом вопросе журнал транзакций решительно отличается от файлов данных.
Рис. 1 Физическая архитектура журнала транзакций
В действительности журнал транзакций является кольцевым файлом, поскольку записи журнала в начале журнала транзакций отбрасываются (или очищаются). Затем, когда процедура ведения журнала достигает конца журнала транзакций, она снова поворачивает в начало и начинает писать поверх того, что было там ранее.
Запись журнала транзакций становится не нужной, если имеют место следующие факты:
· Транзакция, частью которой является эта запись, зафиксирована.
· Все страницы базы данных, которые она изменила, записаны на диск процедурой контрольной точки.
· Данная запись журнала не требуется для резервного копирования (полного, выборочного или журнала).
· Эта запись журнала не требуется никакому компоненту, читающему журнал (например, средству зеркального отображения базы данных или репликации).
Запись журнала, потребность в которой сохраняется, называется активной, и файл VLF, имеющий по крайней мере одну активную запись журнала, также называется активным. Время от времени журнал транзакций проверяется с целью выяснения, являются ли активными все записи журнала в заполненном VLF, или нет; если они все не активны, VLF помечается как отброшенный (что означает, что VLF можно перезаписывать, когда исчерпается свободное место в журнале транзакций). Когда VLF отбрасывается, он никак не перезаписывается и не опустошается, а просто помечается как отброшенный и впоследствии может быть использован повторно.
Этот процесс называется усечением журнала, что не следует путать с реальным сокращением размера журнала транзакций. При усечении журнала никогда не изменяется физический размер журнала транзакций, а изменяется только состояние частей журнала транзакций на активное или неактивное.
На рис. 2 показан журнал транзакций из рис. 1 после проведения усечения.
Рис. 2 Журнал транзакций после усечения журнала
Активные VLF образуют логический журнал, являющийся частью журнала транзакций, содержащей активные записи журналов. Сама база данных знает, с какого места процедура восстановления после сбоя должна начинать чтение записей журнала в активной части журнала — с начала самой старой активной транзакции в журнале, MinLSN (она хранится в загрузочной странице базы данных).
Процедуре восстановления после сбоя не известно, в каком месте следует прекратить чтение записей журнала, поэтому она продолжает до тех пор, пока не достигнет пустого раздела журнала транзакций (если журнал транзакций еще не исчерпал свое свободное пространство) или записи журнала, чьи биты четности не соответствуют последовательности из предыдущей записи журнала.
По мере того, как файлы VLF становятся отброшенными, а новые файлы — активными, логический журнал перемещается в физическом файле журнала транзакций и, в конце концов, вынужден снова завернуть в начало, как показано на рис. 3.
Рис. 3 Циклический характер журнала транзакций
Проверка того, возможно ли усечение журнала при каком-либо из следующих условий:
· При возникновении контрольной точки в модели восстановления SIMPLE или в других моделях восстановления, если никогда не выполнялось полное резервное копирование. (При этом предполагается, что база данных, после вывода из модели SIMPLE, остается в модели восстановления псевдо-SIMPLE до тех пор, пока не будет выполнено полное резервное копирование базы данных.)
· При завершении резервного копирования журнала.
Следует помнить, что усечение журнала может оказаться невозможным, поскольку существует много причин, по которым запись журнала должна оставаться активной. Если усечение журнала невозможно, файлы VLF не могут быть отброшены, и, в конечном счете, журнал должен увеличить свой размер (или должен быть добавлен еще один журнал транзакций). Чрезмерное разрастание журнала транзакций может привести к проблемам с производительностью вследствие эффекта, известного под названием фрагментация VLF. Устранение фрагментации VLF иногда может привести к впечатляющему повышению производительности действий, связанных с журналом.
Усечению журнала могут воспрепятствовать две широко известные проблемы.
· Длительно выполняющаяся активная транзакция. Весь журнал транзакций, с первой записи журнала из самой старой активной транзакции, никогда не может быть усечен до тех пор, пока эта транзакция не будет зафиксирована или аварийно завершена.
· Переключение на модель восстановления FULL, выполнение полной резервной копии и полный отказ от создания резервных копий журнала. Весь журнал транзакций остается активным в ожидании резервного копирования процедурой резервного копирования журнала.
Если журнал транзакций исчерпал весь объем и не может продолжить дальнейшее увеличение, поступает сообщение об ошибке 9002, и вам потребуется предпринять шаги для предоставления дополнительного пространства, например увеличить объем файла журнала, добавить еще один файл журнала или устранить все, что мешает усечению журнала.
Ни при каких обстоятельствах не следует удалять журнал транзакций, пытаться восстановить его с помощью недокументированных команд или просто обрезать его с помощью параметров NO_LOG или TRUNCATE_ONLY команды BACKUP LOG (которая удалена из SQL Server 2008). Эти параметры приведут либо к несогласованности с точки зрения транзакций (и, что более вероятно, к повреждению файла), либо лишат возможности надлежащего восстановления базы данных.
Модели восстановления
Тип процедуры, которая будет использована для восстановления базы данных, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта:
– если базе данных нанесены обширные повреждения (например, разрушилась магнитная головка диска), то потребуется восстановить ее последнюю резервную копию, после чего повторить в ней все выполненные транзакции, сведения о которых присутствуют в журнале регистрации. Безусловно предполагается, что файл журнала поврежден не был. Отметим, что по возможности файл журнала следует создавать на дисковых носителях, отличных от тех, на которых размещены основные файлы базы данных. Подобное решение снижает риск одновременной потери как файлов базы данных, так и файла ее журнала;
– если база данных не получила физических повреждений, но лишь утратила согласованность размещенных в ней данных (например, из-за аварийного останова системы в процессе обработки транзакций), то достаточно будет отменить те изменения, которые вызвали переход базы данных в несогласованное состояние. Кроме того, возможно потребуется повторно прогнать некоторые транзакции, чтобы иметь уверенность в том, что внесенные в них изменения действительно зафиксированы во вторичной памяти. В данном случае нет необходимости обращаться к резервной копии базы данных, поскольку вернуть базу в согласованное состояние можно с помощью информации о содержимом полей до и после модификации, сохраняемой в файле журнала.
Рассмотрим два метода восстановления, которые могут быть применены в последнем из указанных выше случаев (когда база данных утратила согласованное состояние
Модель восстановления FULL подразумевает, что регистрируется каждая часть каждой операции, и это называется полной регистрацией. После выполнения полного резервного копирования базы данных в модели восстановления FULL в журнале транзакций не будет проводиться автоматическое усечение до тех пор, пока не будет выполнено резервное копирование журнала. Если вы не намерены использовать резервные копии журнала и возможность восстановления состояния базы данных на конкретный момент времени, не следует использовать модель восстановления FULL. Однако, если вы предполагаете использовать зеркальное отображение базы данных, тогда у вас нет выбора, поскольку оно поддерживает только модель восстановления FULL.
Модель восстановления BULK_LOGGED обладает такой же семантикой усечения журнала транзакций, как и модель восстановления FULL, но допускает частичную регистрацию некоторых операций, что называется минимальной регистрацией. Примерами являются повторное создание индекса и некоторые операции массовой загрузки — в модели восстановления FULL регистрируется вся операция.
Но в модели восстановления BULK_LOGGED регистрируются только изменения распределения, что радикально сокращает число создаваемых записей журнала и, в свою очередь, сокращает потенциал разрастания журнала транзакций.
Модель восстановления SIMPLE, фактически ведет себя с точки зрения ведения журнала так же, как и модель восстановления BULK_LOGGED, но имеет совершенно другую семантику усечения журнала транзакций. В модели восстановления SIMPLE невозможны резервные копии журнала, что означает, что журнал может быть усечен (если ничто не удерживает записи журнала в активном состоянии) при возникновении контрольной точки. Для каждой из этих моделей имеются доводы за и против, выраженные в терминах возможных (или требуемых) вариантов резервных копий и возможности восстановления состояния на разные моменты времени.