Доброго времени суток!
Имеется 1С-ная база, которая крутится на SQL 2012.

1) Размер базы 570 ГБ
2) Модель восстановление "Простая"
3) Автоувеличение/максимальный размер "С шагом по 20 МБ, без ограничений"
4) Каждую ночь выполняется план обслуживания: Перестроение индекса, обновление статистики, Создание резервной копии, Очистка старых копий

Захожу в меню "Сжатие файла данных". Система сообщает, что Доступно свободного пространства 26%, а значит базу можно сжать до 420 ГБ. Выполняю сжатие, база ужимается до указанных 420 ГБ.

Через сутки проверяю параметры базы - ее размер снова 570 ГБ!
Делал данную операцию несколько раз, все-равно через день объем базы возростает до 570 ГБ.

Вопрос - почему? И как высвободить это пространство?

Это тестовая, что-ли?

(1) Какая разница?

А почему Автоувеличение такое маленькое значение* Из какой логики вы исходили ставя такой размер?

Опять таки каждую ночь идет "перестроение индексов и прочее" и вас удивляетесь что база меняет свой размер?

(0) Сколько если не секрет идет бэкап по времени?

1) "А почему Автоувеличение такое маленькое значение" - Я его не устанавливал - наследие предком. Собственно сейчас и интересуюсь, как оптимальней настроить

2) "Опять таки каждую ночь идет "перестроение индексов и прочее" и вас удивляетесь что база меняет свой размер" - собственно говоря ДА, удивляюсь. Хотите сказать перестроение индексов увеличивает базу на 26% ?

(2) Непонятно зачем тестовую обслуживать.
Если не тестовая, непонятно зачем ограничивать.

(4) Просто скульный бекап пару часов, примерно

(5) понятие не имею что вы там делаете днем. Может вы там каждый день перепроводите. Или с утра создаете 100500 документов а в обед удаляете.
Как знать что там у вас происходит. Попробуйте отключить и узнаете

(6) "непонятно зачем ограничивать." - в смысле зачем сжимать?

Чем меньше база, тем меньше она съедает места на жестких + тем меньше бекап и т.д.

(8) "непонятно зачем ограничивать." - Ок, общая рекомендация какая? Т.е. какая рекомендация по настройке при каких поведенческих схемах?

(9) Почему вы так думаете? Вы что по F5 файлы копируете?

(4) Ого как долго. У меня база тоже 540 гиг, скульный бэкап при работающих пользователях (они работают круглосуточно, просто разные нагрузки) длится в районе -  20- 25 минут.

Что вы там храните на 540 гигов?

(11) В том числе. Бекапы потом по нескольким точкам копируются, в том числе на удаленный FTP сервер через инет. Поэтому размер имеет значение.

(13) Не поверишь - ДАННЫЕ!

Какая разница, что мы храним. Что обычно хранят в 1С-ных базах торговые предприятия? Вопрос топика в другом!

(0) Нет смысла файлы шринкать. Только хуже будет.

(9) Бэкап можно делать со сжатием на лету - тогда пофигу на размер файлов.

(15) ну прости мое любопытство.
Мне 7-нику сложно представить такой объем. Нет конечно бухия на 8-ке тоже прилично весит (100+ гигов). Но там данные за 5 лет.
Вот интересно 570 гигов - это данные за последние 30 лет? Или действительно на 8-ка толпа пользователей может сгенерировать такой объем данных за год? Тогда интересно ОФ или УФ и что за оборудование

(3) +100
Сами сказали:
" Каждую ночь выполняется план обслуживания: Перестроение индекса" -Отсюда и размер.
Забейте на шринк.

(17) У нас почти 1Тб, рост больше 1Гб в день, и что?

(17) Это данные за более чем 10 лет.

+ Система контроля изменения данных. НЕ БСП, но место под себя съедает тоже изрядно.

+ Пара кривых регистров, доставшихся по наследству, выправить которые еще предстоит.

Фотографии в базе НЕ храним

(19) ничего.
Если не ошибаюсь самописка на ОФ?

(19) Не знаю. Так что?

(5) После перестроения индексов SQL оставляет немного места для уменьшение фрагментации при дальнейшем росте/изменении данных. Сжатие базы выбрасывает этот резерв.
(17) Во многих типовых на 8-ке есть встроенный почтовый клиент. В базе может запросто хранится несколько десятков гигабайт почтовых вложений (отправленные счета, сметы).

Перестроение индекса и обновление статистики по всем таблицам каждый день - это на самом деле глупости. Современные MSSQL сервера итак неплохо ведут статистику.

Это надо делать при значительных порциях данных заливаемых в конкретную таблицу и сильно изменяющих значения в ключевых полях индексов. И как правило это какое-то не обычное наполнение данными.

И да, а еще одна глупость, это держать такую базу в simple режиме, надо full. Но это не имеет отношения к вопросу в (0).

у меня 55 Гб 7.7 база, уже тяжеловато в работе..
вот чешу репу как ее бы почикать )
пока удаление того что можно безболезненно и относительно быстро удалить сокращает до 47 Гб, хочется ужаться примерно до половины.

(25) а чем фулл поможет, если никто не делает дифф бэкапов?

(17) У нас база 540 гиг , УПП на обычных формах.
Работаем с 01.07.2012 года.
В год ~ 550 000 Документов реализации + сопутствующие.

может и потребности в восстановлении на любую точку и не быть совсем

(21) " самописка на ОФ" - да, данные за 2 года.

(27) Время реакции изрядно улучшится.
Кроме того, общий объём бэкапов с фулл моделью будет меньше. При этом дифф бэкапы могут и не понадобиться.

(27)
А мы ведь бекапы делаем не для того чтобы места занимать по меньше, а для того чтобы при попадании американской крылатой ракеты томогавк в серверную мы потеряли как можно меньше данных. Вот автор темы потеряет данные максимум за весь день. А я потеряю за 15 минут.

Про диф. бекапы, не совсем понял (может имеете в виду бекапы лога?), что а мешает их делать чтобы место сэкономить?

(32) А куда у вас делаются диф. бэкапы, в облако?

(33)на сервер в другую серверную. Мы исходим из того, что две ракеты ракеты тамогавк одновременно по нам это дорого даже для америки.

(34) Ну у меня локальные Бэкапы + копии на QNAP в другом кабинете, и плюс я приезжаю раз в пару дней с внешним USB диском и копирую туда, диск храню дома.
Паранойя.

(35)ну у нас тоже ходят слухи админы бекапы еще куда-то в обака подливают, но это уже на случай затяжной ядерной войны и это не моя зона ответственности. :)

*облака
так что паранойя и у нас тоже есть )

(0) http://catalog.mista.ru/public/114634/
это сделайте, поможет

(32) дифф бэкапы и бэкапы лога  - это одно и тоже

(39)это смелое утверждение, но не верное.

(39) да уж...
рекомендую таки почитать что-нибудь, желательно не беллетристику.
Например: http://catalog.mista.ru/public/173494/

(39) Смешно...