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

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

Не следует рассматривать приведенные выше сведения об использовании кэша как указание на то, что программист обязан предусматривать в коде какие-то специальные действия для вывода данных из кэша. Все операции, связанные с использованием кэша, осуществляются СУБД SQL Server автоматически. А приведенное здесь описание предназначено для использования только в качестж иллюстрации, позволяющей понять, как применяются журналы и какие действия требуются для осуществления транзакции. Кроме того, если требуется достичь максимальной производительности, то необходимо руководствоваться сведениями о том, как данные передаются в кэш и как долго они хранятся на страницах кэша в оперативной памяти, поэтому важно знать, как происходит запись в журнал, как данные попадают в кэш и выводятся из него.

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

Очистка кэша вручную с помощью команды CHECKPOINT.

Нормальный останов сервера (останов, в ходе которого не используется опция WITH NOWAIT, отменяющая выгрузку кэша на диск).

Изменение любого аспекта режима эксплуатации базы данных (например, переход к монопольному применению базы данных, к эксплуатации только под уттравлением владельца базы данных, dbo, и т.д.).

Применение опции Simple Recovery после заполнения журнала на 70%.

Сформировать контрольную точку

Внести в кэш данные, которые использовались последними у по времени /

Записать / модифицированные/ страницы кэша на диск

Записать изменения в журнал

Рис. 12.1. Блок-схема процесса ведения журнала

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

Рассмотрим действия, выполняемые в связи с указанными причинами, более подробно.

Использование команды checkpoint

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

CHECKPOINT

Очевидно, что команда создания контрольной точки является несложной.

СУБД SQL Server справляется с задачей управления контрольными точками весьма успешно, поэтому такие обстоятельства, в которых приходится создавать контрольные точки вручную, возникают довольно редко.

Самому автору чаще всего приходится создавать контрольные точки вручную на том этапе цикла разработки, когда в базе данных разрешена опция Truncate On Checkpoint (вероятность тюго, что данная опция окажетея активной в какой-либо производственной базе данных, весьма мала). Депо в тюм, чтю в ходе разработки программного обеспечения для базы данных нередко возникают такие ситуации, в которых выполнение тех или иных сценариев занимает очень много времени или происходит довольно быстрое заполнение журнала. Безусяовно, всегда остается возможность вызвать на выполнение соот-вететвующую команду, чтобы самостоятельно усечь содержимое журнала, но команда CHECKPOINT является немного более краткой и быстродействующей, и есяи опция Truncate On Checkpoint актиена, приводит к получению тюго же результата.

Выполнение оператора checkpoint после восстановления

На одном из этапов запуска сервера осуществляется ряд действий, называемых восстановлением (более подробные сведения о восстановлении приведены ниже в данной главе). Для управления этим процессом предусмотрена возможность разрешить опцию Checkpoint on Recovery, которая выполняет операции, определяемые ее названием, - обеспечивает создание контрольной точки после каждого восстановления базы данных, в данном случае - после каждого запуска сервера.

Вообще говоря, применение этой опции не рекомендуется. Деяо в том, что контрольная точка создается автоматически каждый раз после нормального завершения работы системы, поэтому в действительности в журнале отсутствуют какие-либо данные, которые могли бы быть обозначены контрольной точкой, ведь такие данные обнаруживаются, только если останов системы произошел из-за какого-то сбоя. Есяи же опция Checkpoint on Recovery разреи/ена, то сервер вынужден проходить процесс создания контрольной точки при любых обстоятельствах, даже есяи этого фактически и не требуется, что приводит к увеличению продолжительности запуска; безусловно, при от-сутетвии данных, которые должны быть переданы в основной файл базы данных (в результате их фиксаций в ходе создания контрольной точки), затраты времени на выполнение этих действий невелики, но все равно становятея причиной замедления запуска.

Создание контрольной точки при нормальном останове сервера

в процессе эксплуатации СУБД SQL Server часто обнаруживается, что от момента выдачи команды останова и до полного прекращения работы сервера проходит довольно продолжительное время. Дело в том, что сам процесс останова может начаться только после того, как в СУБД SQL Server будет создана контрольная точка, а затем вызваны на выполнение процедуры разгрузки памяти и другие процедуры-деструкторы, позволяющие вначале освободить ресурсы системы. Иными словами, до начала процесса останова все данные, зафиксированные в журнале, должны быть перенесены в физическую базу данных, а для этого может потребоваться определенное