SQL Server. Ведение журнала и восстановление в SQL Server

Одними из самых непонятных составных частей SQL Server являются механизмы ведения журнальчика и восстановления. Складывается воспоминание, что сам факт существования журнальчика транзакций и то, что неверное управление этим журнальчиком может приводить к неполадкам, ставит в тупик многих «невольных админов баз данных» (DBA). Почему журнальчик транзакций может неограниченно возрастать в размере? Почему в неких ситуациях требуется очень много времени для того, чтоб база данных стала доступной после сбоя системы? Почему нереально на сто процентов отключить ведение журнальчика? Почему не удается соответствующим образом вернуть базу данных? Что из себя представляет журнальчик транзакций, и для чего он существует?

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

Что из себя представляет ведение журнальчика?

Ведение журнальчика и процедура восстановления присущи не только лишь SQL Server — во все коммерческие системы управления реляционными базами данных (RDBMS) должны заходить эти средства для обеспечения поддержки разных параметров ACID транзакций. Сокращение ACID обозначает Atomicity (атомарность), Consistency (согласованность), Isolation (изоляция) и Durability (устойчивость), являющиеся базовыми качествами систем обработки транзакций (таких как RDBMS). Подробнее об этом можно прочесть в разделе «Свойства ACID» библиотеки MSDN.

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

Набор из 1-го либо нескольких конфигураций можно сгруппировать (и, практически, так всегда и делается) в транзакцию, обеспечивающую базисную единицу процесса внесения конфигураций (атомарность) в базу данных, когда идет речь о юзерах, разработчиках приложений и DBA. Транзакция заканчивается удачно (фиксация) либо заканчивается аварийно либо отменяется (откат). В первом случае гарантируется, что операции, формирующие транзакцию, отражены в базе данных. Во 2-м случае гарантируется, что операции не будут отражены в базе данных.

Транзакции в SQL Server бывают очевидными и неявными. При очевидной транзакции юзер либо приложение выдает оператор BEGIN TRANSACTION T-SQL, оповещающий о запуске данным сеансом группы связанных конфигураций. Очевидная транзакция удачно заканчивается, когда выдается оператор COMMIT TRANSACTION, оповещающий об успешном выполнении группы конфигураций. Если заместо него выдается оператор ROLLBACK TRANSACTION, все конфигурации, выполненные в данном сеансе с момента выдачи оператора BEGIN TRANSACTION, обращаются (откатываются), и транзакция отменяется. Откат транзакции может быть принудительно вызван наружным событием, к примеру, нехваткой для базы данных свободного места на диске либо выходом из строя сервера. Эти случаи подвергнутся рассмотрению дальше.

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

Вам может показаться, что в этом нет необходимости, так как один оператор T-SQL не может генерировать огромное число конфигураций в структурах хранилища базы данных, но разглядите, к примеру, оператор ALTER INDEX REBUILD. Хотя этот оператор не может содержаться в очевидной транзакции, он может генерировать большущее число конфигураций в базе данных. Потому нужен механизм, обеспечивающий в случае неверного развития событий (к примеру, если отменяется выполнение оператора) соответствующее выполнение воззвания конфигураций.

В качестве примера разглядим, что происходит, если в неявной транзакции обновляется одна строчка таблицы. Представим для себя ординарную неупорядоченную таблицу, содержащую столбец c1 с целочисленными данными и столбец c2 с символьными данными. В таблице имеется 10 000 строк, и юзер посылает запрос на обновление последующим образом.

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE ‘%Paul%’;

Производятся последующие операции.

Странички данных из SimpleTable считываются с диска в память (буферный пул), потому можно делать поиск соответственных строк. Оказывается, что на 3-х страничках данных имеется 5 строк, соответственных предикату предложения WHERE.
Модуль хранилищ автоматом запускает неявную транзакцию.
Эти три странички и 5 строк данных блокируются для выполнения обновлений.
Конфигурации вносятся в 5 записей данных на 3-х страничках данных, находящихся в памяти.
Конфигурации записываются также в записи журнальчика транзакций на диске.
Модуль хранилищ автоматом фиксирует эту неявную транзакцию.<