Если такое происходит, обратите внимание на следующее:
Посмотрите, какой режим восстановления (Recovery) стоит на закладке Options в свойствах базы данных.
Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. Журнал транзакций автоматически не обрезается. Этот режим обеспечивает максимальные возможности восстановления (за счет снижения производительности). Только в этом режиме вы можете использовать зеркальное отображение баз данных и автоматическую доставку журналов (log shipping). Именно этот режим выбирается по умолчанию для пользовательских баз данных, поскольку он настроен для базы данных model. Если изменить режим восстановления для базы данных model, то для создаваемых баз данных по умолчанию будет выбираться новый режим.
Bulk-logged (режим неполного протоколирования) — это компромисс между требованиями производительности и возможностями восстановления. При использовании этого режима запись в журнал практически отключается (в терминологии Microsoft — проводится минимальное протоколирование) для операций следующих типов:
- массовой вставки (команды BULK INSERT, SELECT INTO, загрузка средствами bcp и т. п.);
- вставка/изменение больших двоичных данных (text, ntext, image);
- операции по созданию, перестроению и удалению индексов.
Автоматическая перезапись журналов транзакций при этом не производится, работа с транзакциями, не включающими в себя перечисленные операции, производится как обычно.
При работе в этом режиме вы лишаетесь возможности использовать журнал транзакций для восстановления (при утрате файлов данных, на момент времени или на метку транзакции), если в нем была хотя бы одна запись о перечисленных ранее операциях. Microsoft рекомендует не использовать этот режим восстановления на постоянной основе, а переключаться в него из режима Full на время выполнения больших операций массовой вставки, а потом возвращаться обратно.
Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций. Но в этом режиме использовать журнал транзакций для восстановления уже не удастся. Вы не сможем даже выполнить резервное копирование журнала транзакций: команда BACKUP LOG в этом режиме сразу вернет ошибку.
Усечение журнала транзакций зависит от операции резервного копирования (backup): если не делать резервное копирование, то лог транзакций в режиме Full будет расти.
Для базы данных предприятия в свойствах базы я установил опцию Full Recovery. Базу надо периодически архивировать, для чего я настроил автоматическое архивирование базы данных (каждый месяц Full ) (каждое утро differential ) и журнала транзакций (каждый час Transaction log). Вот исходя из этого вы и выбираете режим бэкапа, а периодичность в основном зависит от того сколько Вы готовы потерять данные.
Обратите внимание так же на пункт контекстного меню "Shrink Database" (shrink - англ. усечение, усадка, усушка, уменьшение). Эта операция уменьшает размер базы данных путем "удаления неиспользуемых страниц" ("remove unused pages").
В свойствах базы данных есть опция "Auto Shrink", которая активизирует автоматическое уменьшение базы, во время периодических проверок неиспользуемого места ("during periodic checks for unused space").
Процесс усечение журнала освобождает место в файле для повторного использования журналом транзакций. Поскольку сжатие не позволяет усечь или удалить активную часть журнала, усечение откладывается на длительный срок, в течение которого записи журнала остаются активными.
Записи журнала могут оставаться активными по множеству причин. Чтобы определить, что препятствует усечению журнала транзакций в конкретном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.database.
Некоторые из этих причин (длительные транзакции, приостановленный сеанс зеркального отображения базы данных и др.) могут привести к переполнению журнала транзакций. Дополнительные сведения о том, что нужно делать при переполнении журнала транзакций, см. в разделе Устранение неполадок при переполнении журнала транзакций (ошибка 9002).
Активные длительные транзакции
Для активной транзакции требуется, чтобы журнал остался активным, начиная с записи, содержащей начало транзакции. Например, если запуском и завершением транзакции управляет пользователь, то типичной причиной возникновения длительной транзакции служит отсутствие пользователя после начала транзакции, в то время как для продолжения транзакции требуется его участие. В таких случаях сама по себе ожидающая транзакция формирует очень маленькую запись журнала, однако задерживает усечение журнала и приводит к его увеличению.
Зеркальное отображение базы данных и журнал транзакций
Для зеркального отображения базы необходимо, чтобы каждая запись журнала оставалась активной, пока экземпляр основного сервера получает уведомления от экземпляра зеркального сервера о записи на диск. Если экземпляр зеркального сервера начинает отставать от экземпляра основного сервера, то соответствующим образом увеличивается место на диске, занимаемое активным журналом. В этом случае может потребоваться остановка зеркального отображения базы данных, применение к зеркальной базе данных резервной копии журнала, усекающей журнал (с использованием параметра WITH NORECOVERY) и повторный запуск зеркального отображения.
|
Важное примечание!
Более того, перед запуском зеркального отображения потребуется вручную применить все дополнительные резервные копии журнала (обязательно с использованием параметра WITH NORECOVERY), если таковые были созданы после требуемой резервной копии. Зеркальное отображение может быть запущено после применения самой последней резервной копии журнала.
|
Репликация транзакций и журнал транзакций
Репликация слиянием и репликация моментальных снимков не влияют на размер журнала, в отличие от репликации транзакций. Если база данных содержит одну или несколько публикаций транзакций, журнал не может быть усечен, пока все транзакции, связанные с публикациями, не будут доставлены в базу данных распространителя. Если журнал транзакций становится слишком большим, а агент чтения журнала запускается по расписанию, необходимо рассмотреть возможность сокращения интервала между его запусками или возможность его установки в режим непрерывной работы. Если он установлен в режим непрерывной работы (по умолчанию), необходимо убедиться в том, что он запущен.
Кроме этого, если в базе данных публикации или распространителя установлен параметр «синхронизация с резервной копией», то журнал транзакций не усекается до тех пор, пока не будет осуществлено резервное копирование всех транзакций. Если журнал транзакций становится слишком большим и этот параметр установлен, то необходимо рассмотреть сокращение интервалов резервного копирования журнала транзакций.
В следующей таблице кратко описываются значения столбцов log_reuse_wait и log_reuse_wait_desc представления каталога sys.database.
| Значение столбца log_reuse_wait |
Значение столбца log_reuse_wait_desc |
Описание |
| 0 |
NOTHING |
В данный момент существует один или более виртуальных файлов журнала, доступных для повторного использования. |
| 1 |
CHECKPOINT |
С момента последнего усечения журнала не было новых контрольных точек, либо заголовок журнала не перемещался за пределы виртуального файла журнала (для всех моделей восстановления).
Это широко распространенная причина задержки усечения журнала. Дополнительные сведения см. Контрольные точки и активная часть журнала.
|
| 2 |
LOG_BACKUP |
Чтобы переместить заголовок журнала вперед, необходимо выполнить резервное копирование журнала (только для полной модели восстановления и модели восстановления с неполным протоколированием).
Примечание
Резервные копии журналов не препятствуют усечению.
После завершения создания резервной копии журнала заголовок журнала перемещается вперед и некоторое пространство журнала может освободиться для повторного использования.
|
| 3 |
ACTIVE_BACKUP_OR_RESTORE |
Выполняется резервное копирование или восстановление данных (для всех моделей восстановления).
Резервное копирование данных работает аналогично активной транзакции, поэтому его выполнение предотвращает усечение. Дополнительные сведения см. ниже в подразделе «Операции резервного копирования и восстановления данных».
|
| 4 |
ACTIVE_TRANSACTION |
Активна одна из транзакций (для всех моделей восстановления).
•Во время начала создания резервной копии журнала может существовать длительная транзакция. В этом случае, чтобы освободить пространство, может потребоваться создание другой резервной копии журнала. Дополнительные сведения см. ниже в разделе «Длительные активные транзакции».
•Транзакция отложена (только в SQL Server 2005 Enterprise Edition и более поздних версиях). Отложенная транзакция — это активная транзакция, откат которой был заблокирован по причине недоступности какого-либо ресурса. Дополнительные сведения о причинах, вызывающих появление отложенных транзакций, и о том, как их можно вывести из такого состояния, см. в разделе Отложенные транзакции.
|
| 5 |
DATABASE_MIRRORING |
Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных намного отстает от основной (только для модели полного восстановления).
Дополнительные сведения см. далее в разделе «Зеркальное отображение базы данных и журнал транзакций».
|
| 6 |
REPLICATION |
Во время репликации транзакций в базу данных распространителя не доставляются транзакции, имеющие отношение к публикациям (только для модели полного восстановления).
Дополнительные сведения см. далее в разделе «Репликации транзакций и журнал транзакций».
|
| 7 |
DATABASE_SNAPSHOT_CREATION |
Создается моментальный снимок базы данных (для всех моделей восстановления).
Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
|
| 8 |
LOG_SCAN |
Производится просмотр журнала (для всех моделей восстановления).
Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
|
| 9 |
OTHER_TRANSIENT |
Эта значение сейчас не используется. |
| 
