Физическая архитектура журнала транзакций
Журнал транзакций используется для обеспечения целостности данных в базе данных и восстановления данных. В этом подразделе приводятся сведения о физической структуре журнала транзакций. Понимание физической архитектуры может помочь в повышении эффективности работы с журналами транзакций.
Журнал транзакций в базе данных сопоставляет один или несколько физических файлов. По сути, файл журнала представляет собой строку записей журнала. Физически последовательность записей журнала эффективно хранится в наборе физических файлов, которые образуют журнал транзакций.
Компонент SQL Server Database Engine делит каждый физический файл журнала на несколько виртуальных файлов журнала. Виртуальные файлы журнала не имеют фиксированных размеров. Не существует также и определенного числа виртуальных файлов журнала, приходящихся на один физический файл журнала. Компонент Database Engine динамически определяет размер виртуальных файлов журнала при создании или расширении файлов журнала. Компонент Database Engine стремится обслуживать небольшое число виртуальных файлов. После расширения файла журнала размер виртуальных файлов определяется как сумма размера существующего журнала и размера нового приращения файла. Администраторы не могут настраивать или устанавливать размеры и число виртуальных файлов журнала.
Виртуальные файлы журнала влияют на производительность системы лишь в том случае, если эти файлы журнала определяются малыми значениями size и growth_increment. Если эти файлы журнала в результате большого числа малых приращений будут разрастаться до крупных размеров, они будут иметь множество виртуальных файлов журнала. В итоге может увеличиться время запуска базы данных, а также снизиться скорость операций резервного копирования и восстановления. Рекомендуется выбирать для файлов журнала значение параметра size, близкое к окончательному требуемому размеру, а также задавать относительно большое значение growth_increment.
Журнал транзакций является оборачиваемым файлом. Рассмотрим пример. Пусть база данных имеет один физический файл журнала, разделенный на четыре виртуальных файла журнала. При создании базы данных логический файл журнала начинается в начале физического файла журнала. Новые записи журнала добавляются в конце логического журнала и приближаются к концу физического файла журнала. Усечение журнала освобождает любые виртуальные журналы, все записи которых находятся перед минимальным регистрационным номером восстановления в журнале транзакций (MinLSN). MinLSN является в журнале транзакций регистрационным номером самой старой записи, которая необходима для успешного отката на уровне всей базы данных. Журнал транзакций рассматриваемой в данном примере базы данных будет выглядеть примерно так же, как на следующей иллюстрации.
.gif "Файл журнала, разделенный на четыре виртуальных файла журнала")
Когда конец логического журнала достигнет конца физического файла журнала, новые записи журнала будут размещаться в начале физического файла журнала.
.gif "Записи журнала возвращаются к началу файла журнала")
Этот цикл повторяется бесконечно, пока конец логического журнала не совмещается с началом этого логического журнала. Если старые записи журнала усекаются достаточно часто, так что при этом всегда остается место для новых записей журнала, созданных с новой контрольной точки, журнал постоянно остается незаполненным. Однако, если конец логического журнала совмещается с началом этого логического журнала, происходит одно из двух событий, перечисленных ниже.
Если для данного журнала применена установка FILEGROWTH и на диске имеется свободное место, файл расширяется на величину, указанную в growth_increment, и новые записи журнала добавляются к этому расширению. Дополнительные сведения о настройке FILEGROWTH см. в разделе ALTER DATABASE (Transact-SQL).
Если установка FILEGROWTH не применяется или диск, на котором размещается файл журнала, имеет меньше свободного места, чем это указано в growth_increment, формируется ошибка 9002.
Если в журнале содержится несколько физических файлов журнала, логический журнал будет продвигаться по всем физическим файлам журнала до тех пор, пока он не вернется на начало первого физического файла журнала.