Журналирование

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

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

Журнал транзакций поддерживает следующие операции:

• восстановление отдельных транзакций;
• восстановление всех незавершенных транзакций при запуске SQL Server;
• накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
• поддержка репликации транзакций;
• Поддержка решений высокого уровня доступности и аварийного восстановления: Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.

Просмотр журнала ошибок SQL Server

Журнал ошибок сервера SQL Server позволяет убедиться, что процессы были завершены успешно (например, операции резервного копирования и восстановления, пакеты команд или другие сценарии и процессы). Это полезно при определении любых текущих или потенциальных проблем, включая сообщения автоматического восстановления (особенно если экземпляр SQL Server был остановлен и перезапущен), сообщения ядра и другие сообщения об ошибках на уровне сервера.

По умолчанию журнал ошибок содержится в файлах Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG и ERRORLOG.n. Новый журнал ошибок создается при каждом запуске экземпляра сервера SQL Server, хотя циклическую смену журнала ошибок можно организовать при помощи системной хранимой процедуры sp_cycle_errorlog без перезапуска экземпляра сервера SQL Server. Обычно сервер SQL Server хранит резервные копии шести предыдущих журналов и присваивает наиболее свежей копии расширение «.1», следующей расширение «.2» и т. д. Файл текущего журнала ошибок расширения не имеет.

Логическая архитектура журнала транзакций

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

• Log Sequence Number: регистрационный номер транзакции (LSN). Каждая новая запись добавляется в логический конец журнала с номером LSN, который больше номера LSN предыдущей записи.
• Prev LSN: обратный указатель, который предназначен для ускорения отката транзакции.
• Transaction ID number: идентификатор транзакции.
• Type: тип записи Log-файла.
• Other information: Прочая информация.

Двумя основными типами записи Log-файла являются:

• Transaction Log Operation Code: код выполненной логической операции, либо
• Update Log Record: исходный и результирующий образ измененных данных. Исходный образ записи – это копия данных до выполнения операции, а результирующий образ – копия данных после ее выполнения.

Действия, которые необходимо выполнить для восстановления операции, зависят от типа Log-записи:

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

В журнал транзакций записываются различные типы операций: 0. BEGINXACT: Begin Transaction 4. Insert 5. Delete 6. Indirect Insert 7. Index Insert 8. Index Delete 9. MODIFY: Modify the record on the page 11. Deferred Insert (NO-OP) 12. Deferred Delete (NO-OP) 13. Page Allocation 15. Extent Allocation 16. Page Split 17. Checkpoint 20. DEXTENT 30. End Transaction (Either a commit or rollback) 38. CHGSYSINDSTAT — A change to the statistics page in sysindexes 39. CHGSYSINDPG — Change to a page in the sysindexes table

Каждая транзакция резервирует в журнале транзакций место, чтобы при выполнении инструкции отката или возникновения ошибки в журнале было достаточно места для регистрации отката. Объем резервируемого пространства зависит от выполняемых в транзакции операций, но обычно он равен объему, необходимому для регистрации каждой из операций. Все это пространство после завершения транзакции освобождается.

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

Физическая архитектура журнала транзакций

На физическом уровне журнал транзакций состоит из одного или нескольких физических файлов. Каждый физический файл журнала разбивается на несколько виртуальных файлов журнала (VLF). VLF не имеет фиксированного размера. Не существует также и определенного числа VLF, приходящихся на один физический файл журнала. Компонент Database Engine динамически определяет размер VLF при создании или расширении файлов журнала. Компонент Database Engine стремится обслуживать небольшое число VLF. Администраторы не могут настраивать или устанавливать размеры и число VLF.

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

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

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

• Если для данного журнала применена установка FILEGROWTH и на диске имеется свободное место, файл расширяется на величину, указанную в growth_increment, и новые записи журнала добавляются к этому расширению.

• Если установка FILEGROWTH не применяется или диск, на котором размещается файл журнала, имеет меньше свободного места, чем это указано в growth_increment, формируется ошибка 9002.

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