Вот познаю потихоньку основы администрирования MS SQL. Заметил странную особенность: база данных с 10 гб за 3 недели доросла до 22. Лог файл распух до 9гб. Попробовал сжать базы Задачи/сжать/файлы. Показывает, что у базы 50% свободно, а у лога - 85%. Модель восстановления - простая. Тут вроде как логу вообще расти не с чего. Полный бэкап - каждую ночь. Решил  в регламентные задачи добавить сжатие баз (ночью, после бэкапа). Хочу спросить: чем это чревато? Скажется ли это как то на работа БД? Если место свободное - зачем скуль его отъедает? М.б. вообще ему не мешать (благо, место на жестком позволяет)? Или тут по аналогии с ОЗУ - сколько дал, столько и отъест?:) Ну и не пинайте, админом скуля стал неожиданно.

скажется только на фрагментацию на винте

(1) Если дефрагментация раз в неделю проходит - нормуль?

И если это никак не скажется на производительности - нафига эти лишние гигабайты скулю?

(3) Ему на них пофиг.

(0) Если место позволяет - лучше не мешать. Когда sql server увеличивает размер журнала транзакций (происходит его расширение), он перестаёт обрабатывать запросы на запись - т.е. всякие реорганизации/перестройки индексов (а похоже, что именно из-за них вырстает лог) будут периодически "подтупливать".

(5) И до какого размера лучше не мешать? Например лог бухии уже равен весу самой базы. Все равно не мешать? З.ы. Можно же размер файла лога ограничить. Рекомендуют до половины базы. А как тут ограничивать, если он за 3 недели столько отъел? Или после ограничения он начнет таки писать в уже отъетое место и не жрать новое?

(6) нельзя ограничить размер лог файла, ибо тупо программа скажет не могу увеличить лог идите нафиг

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

(0) > Тут вроде как логу вообще расти не с чего.

Как перестать называть журнал транзакций SQL Server лог-файлом и прекратить борьбу за его размер.
В 12 частях.
Часть 1: http://www.sqlcmd.ru/trans_log_internals-part01.html

Цитата (из 12 части):
Чего не следует делать с журналом транзакций никогда в жизни ни при каких обстоятельствах.
...
* сжимать (SHRINKFILE) лог на регулярной основе, по расписанию. А вот это — необсуждаемый, совершенно полный и законченный бред. Даже продуманное и обоснованное однократное сжатие лога следует рассматривать как ситуацию чрезвычайную и как попытку предотвратить надвигающуюся катастрофу. Делая же это по расписанию вы признаете, что не прочь поработать «пожарником» на постоянной основе, вместо того что бы один раз тщательно потушить все «очаги возгорания» имеющиеся во вверенной вашим заботам системе.

(6) точно модель восстновления простая? Если да - проверяйте что у вас там в базе творится.

(10) Точно. Будем смотреть, но творится во всех базах (ЗУП, БП, УТ). Если учесть, что ЗУП и БП типовые и в них работает 2 с половиной человека, то, мне кажется, в них ничего не творится
(9) Ок, удалил из расписаиня :)

+(10) я имею в виду, что при простой модели восстановления журнал транзакций может расти по двум причинам:
1) обрабатывается огромное количество данных в одной транзакции;
2) очень долго не закрывается какая-либо транзакция.

(0) а прирост для лог. файла какой стоит? в % или МБ
Если база за 3 недели на 12 ГБ выросла, там явно не 2,5 человек работают...

(13) на 12 ГБ выросла УТ. В той 60 человек. Прирост лога - по 50 мб.