Имя: Пароль:
IT
Админ
MS SQL сжатие баз
,
0 LehhaK
 
23.09.13
12:07
Вот познаю потихоньку основы администрирования MS SQL. Заметил странную особенность: база данных с 10 гб за 3 недели доросла до 22. Лог файл распух до 9гб. Попробовал сжать базы Задачи/сжать/файлы. Показывает, что у базы 50% свободно, а у лога - 85%. Модель восстановления - простая. Тут вроде как логу вообще расти не с чего. Полный бэкап - каждую ночь. Решил  в регламентные задачи добавить сжатие баз (ночью, после бэкапа). Хочу спросить: чем это чревато? Скажется ли это как то на работа БД? Если место свободное - зачем скуль его отъедает? М.б. вообще ему не мешать (благо, место на жестком позволяет)? Или тут по аналогии с ОЗУ - сколько дал, столько и отъест?:) Ну и не пинайте, админом скуля стал неожиданно.
1 Aleksey
 
23.09.13
12:09
скажется только на фрагментацию на винте
2 LehhaK
 
23.09.13
12:10
(1) Если дефрагментация раз в неделю проходит - нормуль?
3 LehhaK
 
23.09.13
12:10
И если это никак не скажется на производительности - нафига эти лишние гигабайты скулю?
4 Chai Nic
 
23.09.13
12:42
(3) Ему на них пофиг.
5 упс
 
23.09.13
12:47
(0) Если место позволяет - лучше не мешать. Когда sql server увеличивает размер журнала транзакций (происходит его расширение), он перестаёт обрабатывать запросы на запись - т.е. всякие реорганизации/перестройки индексов (а похоже, что именно из-за них вырстает лог) будут периодически "подтупливать".
6 LehhaK
 
23.09.13
12:51
(5) И до какого размера лучше не мешать? Например лог бухии уже равен весу самой базы. Все равно не мешать? З.ы. Можно же размер файла лога ограничить. Рекомендуют до половины базы. А как тут ограничивать, если он за 3 недели столько отъел? Или после ограничения он начнет таки писать в уже отъетое место и не жрать новое?
7 Aleksey
 
23.09.13
12:52
(6) нельзя ограничить размер лог файла, ибо тупо программа скажет не могу увеличить лог идите нафиг
8 Jaap Vduul
 
23.09.13
12:52
Не надо сжимать, это, как правило, отрицательно сказывается на производительности (т.к. затем на выделение дискового пространства будет тратиться дополнительное время).
Сжатие имеет смысл делать только при дефиците места на дисках.
9 yukon
 
23.09.13
12:53
(0) > Тут вроде как логу вообще расти не с чего.

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

Цитата (из 12 части):
Чего не следует делать с журналом транзакций никогда в жизни ни при каких обстоятельствах.
...
* сжимать (SHRINKFILE) лог на регулярной основе, по расписанию. А вот это — необсуждаемый, совершенно полный и законченный бред. Даже продуманное и обоснованное однократное сжатие лога следует рассматривать как ситуацию чрезвычайную и как попытку предотвратить надвигающуюся катастрофу. Делая же это по расписанию вы признаете, что не прочь поработать «пожарником» на постоянной основе, вместо того что бы один раз тщательно потушить все «очаги возгорания» имеющиеся во вверенной вашим заботам системе.
10 упс
 
23.09.13
12:54
(6) точно модель восстновления простая? Если да - проверяйте что у вас там в базе творится.
11 LehhaK
 
23.09.13
12:57
(10) Точно. Будем смотреть, но творится во всех базах (ЗУП, БП, УТ). Если учесть, что ЗУП и БП типовые и в них работает 2 с половиной человека, то, мне кажется, в них ничего не творится
(9) Ок, удалил из расписаиня :)
12 упс
 
23.09.13
12:59
+(10) я имею в виду, что при простой модели восстановления журнал транзакций может расти по двум причинам:
1) обрабатывается огромное количество данных в одной транзакции;
2) очень долго не закрывается какая-либо транзакция.
13 zva
 
23.09.13
13:12
(0) а прирост для лог. файла какой стоит? в % или МБ
Если база за 3 недели на 12 ГБ выросла, там явно не 2,5 человек работают...
14 LehhaK
 
23.09.13
13:13
(13) на 12 ГБ выросла УТ. В той 60 человек. Прирост лога - по 50 мб.
Программист всегда исправляет последнюю ошибку.