Это мои текущие настройки:
Режим восстановления: Простой исходный размер файла журнала: 10 МБ Автоматическое увеличение файла журнала: Нет Автоматическое сжатие базы данных: Выкл.
Для автоматического роста файла журнала установлено значение Нет, потому что я не хочу, чтобы файл журнала увеличивался. Моя цель - сохранить размер файла журнала постоянно маленьким, поскольку он мне не нужен для целей восстановления.
Подходят ли для этого обе настройки?
Кроме того, что произойдет, если у меня будет большая транзакция, включающая множество операций вставки и удаления (изменение на сумму более 10 МБ). Операция не завершится из-за нехватки места в файле журнала?
В модели полного восстановления. содержимое журнала сбрасывается каждый раз, когда выполняется фиксация без открытых транзакций. Это могло случиться довольно часто.
ЕСЛИ журнал перегружен, БД не может зафиксировать. Изменения будут отменены. Обратите внимание, что в простой модели это было бы РЕДКО, но теоретически это МОЖЕТ быть возможным. Хотя я бы назвал это чисто теоретическим.
В то же время вы не можете использовать резервные копии журналов для своевременного восстановления.
Да, если журнал заполняется из-за более крупной транзакции, а для файла журнала задано значение NO autogrow, транзакция завершится ошибкой и откатится.
Это может быть не так редко, как вы думаете. Восстановление индекса - это обычная операция по обслуживанию, при которой используется большой объем журнала.
Вы не упомянули размер вашего файла данных или вид деятельности, которую обрабатывает ваша база данных, поэтому я не могу узнать, достаточно ли 10 МБ.
я буду никогда оставьте файл журнала с отключенным автоматическим увеличением. Это просто напрашивается на неприятности. Конечно, вы хотите получить уведомление когда он растет, и вы можете сделать монитор, который делает это. Вам просто не нужна страница посреди ночи, потому что какой-то пользователь запустил большой отчет или что-то в этом роде.
Просто чтобы прояснить ситуацию:
В простой модели восстановления усечение файла журнала не связано напрямую с фиксацией. Файл журнала усечен, поэтому файлы виртуального журнала можно повторно использовать для других транзакций. только при возникновении контрольной точки. Контрольные точки выполняются настолько часто, насколько SQL считает необходимым записывать грязные страницы на диск. Также на КПП неактивная часть файла журнала (не используется ни одной транзакцией) усекается, что позволяет повторно использовать журнал транзакций для других транзакций. После того, как журнал был усечен, файл журнала можно сжать, чтобы при необходимости уменьшить физический размер.
Таким образом, фиксация не создает контрольную точку, если вы не укажете ее явно в транзакции после фиксации. С другой стороны, контрольная точка, которая фактически генерирует усечение журнала, не будет иметь никакого эффекта, если журнал содержит информацию о незафиксированных транзакциях.
Чтобы ответить на ваши вопросы:
Подробнее об управлении файлами журнала: http://technet.microsoft.com/en-us/library/ms189085.aspx
Если это ваша производственная БД, то иметь модель простого восстановления - не лучшая идея. Autogrowth должен помочь вам, если у вас не закончится дисковое пространство.