SHRINKDATABASE - плюсы и минусы сего действия?

← →
zom (2004-11-25 11:23) [0]

Почему бы на базах не ставить АутоШринк всегда?
и что вообще это дает?

Ну если мне нужны логи долго и упорно но их шринкать не нужно... а кроме логов есть причины НЕ делать шринк?
и какая польза от шринка, кроме свободного места? скорость работы базы увеличится? а как насчет времени создания временных таблиц в зависимости от spaceAvaliable?

← →
MOA © (2004-11-25 11:51) [1]

>Почему бы на базах не ставить АутоШринк всегда?
Уменьшение базы - процесс, требующий ресурсов. Тормозить будет (может) сервер во время шринка.
>Ну если мне нужны логи
А зачем они могут понадобиться? См. BOL "Recovery model". Вас интересует, видимо, Full.
>какая польза от шринка, кроме свободного места?
Никакой.
>кроме логов есть причины НЕ делать шринк?
Ну вот логами опять непонятно?

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

← →
zom (2004-11-25 12:05) [2]

да с логами понятно ;) они мне НЕ нужны (мы их почти и не ведем..)

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

ну тогда средний вариант - шринк в еженедельном джобе ;)

← →
MOA © (2004-11-25 12:37) [3]

Всё же, не могли бы Вы пояснить - что Вы подразумеваете под логами? Log - файлы, которые ведёт MSSQL или самописные?
Вообще-то, можно применить такой метод - воспользоваться Database Maintance Plan, и запланировать его, например, на ночь, или(и) на выходные. Там есть пунктик Shrink ;).
Удачи!

← →
zom (2004-11-25 12:44) [4]

Под логами - файлы которые ведет MSSQL, по ним при желании много чего восстановить, если предварительно настроить (но нам оно не потребно).
А за идею про Database Maintance Plan спасибо - как то не задумывался что полезной может оказаться фича...

← →
MOA © (2004-11-25 12:59) [5]

>Под логами - файлы которые ведет MSSQL, по ним при желании много чего восстановить
Ага! Точно, ч так и подозревал ;).
Если у Вас база пополняется не очень интенсивно и не круглосуточно, позвольте примерчик:
1. Переводим базу в режим Full Recovery Model
2. Делаем Maintance Plan:
2.1 на ночь - Transaction Log Backup + что ещё нужно ;)
2.3 на выходные - делаем Complete Backup + проверку целостности + настройку индексов + Shrink
Храним Complete Backup + Transaction Log Backup за тот период времени, на который может понадобится откат.
Эффект:
Вы сможете откатится на любое время с точностью до секунды, на которое есть бэкапы.
Файлы логов не будут здорово расти, если не было массовых вставок-удалений.
С файлами баз - аналогично.
PS Если бэкапов не делать - логи будут расти бесконечно ;).
Удачи!

← →
zom (2004-12-07 16:08) [6]

Как раз массовые вставки очень популярны... и делиты ;)

>Как раз массовые вставки очень популярны... и делиты ;)
Если сколько вставили - (почти) столько и удалили - просто настроить соотв. параметр в св-вах базы - чтобы поменьше "дышала".
И если нужны откаты "в прошлое" - Full Recovery Model + бэкапы (базы и чаще - лога транзакций) + хранение (и тех и других) на промежуток, внутри которого может потребоваться откат.
Удачи!

SHRINKDATABASE - плюсы и минусы сего действия? Найти похожие ветки