MSSQL Server 10 - побочный журнал роста, 100 ГБ / неделя

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

Редактировать:

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

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

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

Исходная информация:

1. На правильно настроенном сервере MSSQL журналы транзакций физически отделены от данных: они находятся не только на отдельном томе, но и на совершенно отдельном RAID-массиве.
2. Если база данных (или физический том, на котором хранится база данных) потеряна, вы можете восстановить данные из самой последней резервной копии, а затем воспроизвести журналы транзакций для восстановления данных до момента сбоя.
3. Любые записи в журнале транзакций, созданные до самой последней резервной копии, можно удалить из файла LDF. Обычно сами журналы сохраняются до того, как их удаляют; это сохраняет возможность восстановления в произвольные моменты времени, которые могут предшествовать самой последней резервной копии, если сохраняются более старые резервные копии.

Итак, вот главный вопрос: как выполняется резервное копирование этого SQL-сервера и удаляются ли журналы транзакций во время каждой резервной копии? Был ли ночной процесс резервного копирования, который внезапно перестал работать?

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

Кроме того - данные и журналы не имеют никакого дела на диске c. Разделение ввода-вывода в загруженной базе данных является ключом к производительности.

Кроме того, переместите их из диска C. Недостаток этого диска приведет к сбою БД и может привести к повреждению

Как сказал Крис, когда ваша БД установлена ​​в режим полного восстановления (который почти наверняка есть), вы должны выполнить какое-то резервное копирование, чтобы обрезать журнал транзакций. Если нет, вы увидите, что он постоянно растет. Если вам не нужно окно восстановления этой БД, тогда вы можете просто установить режим восстановления обратно на Основной.

Я бы изменил модель восстановления в базе данных модели с FULL на SIMPLE.

В нашей организации модель полного восстановления - это осознанное решение, которое мы планируем. Установка SIMPLE в базе данных модели исключает возможность заполнения файла журнала накопителем, поскольку у него не было регулярных резервных копий.

Какая версия MSSQL? В SQL Server 2008 удалена возможность усекать файлы журналов (и у них для этого есть веские и веские причины), поэтому, если ваш файл журнала выходит из-под контроля, необходимо запустить его снова и подготовить надлежащие планы обслуживания, чтобы гарантировать, что это больше не повторится.

Тем не менее, если вы не используете:

• Зеркальное
• Доставка журнала транзакций

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