Файловый ЗУП. Бэкапится копированием 1СD. Размер 2 ГБ. Щас глянул, размер не менялся с 1 августа по 3 сентября. 4 сенятбря приросло 60 КБ.
Работа в базе ежедневная. Порядка 300 сотров. За месяц ввели сотни документов, а размер 1CD не изменился. Это нормально или уже надо начинать паниковать? Куда инфа то вся писалась?

не ту базу мониторишь )

где ты смотишь историю размера файла?

Размер смотрю в папке бэкапов ежедневных

Нажмите Справка - О программе. В поле каталог указано расположение Вашей файловой базы, её и смотрите.

хотя, с другой стороны, это нормально

(3) Бэкапы сжатые?

+ Место выделяется не по байту, а с запасом.

(0) нормально. В 1С настолько все неоптимизировано, что она даже для базы создает в общем случае "пустые" каркасы таблиц, которые постепенно заполняются данными.
Как достигнет предела "запасенных" записей - начнет пухнуть снова.

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

(7) Это наоборот, оптимизация.

Это клиент-серверная архитектура в реализации 1С, ежели что.
Т.е., переводя на нормальный язык с 1сового - "клиент" (1С) не отвечает за то, что "там" в базе наворочено.
Ни в SQL, ни в 1CD.

Бэкапы - обычные копии файла 1CD. Батником по ночам копируются

(9) оптимизация - это возможность шринка путсых записей.
Попробуйте сделать шринк с базой 1С.

(0) Нормально. Значит, внутри много пустого места было (могло образоваться после какой-нить реструктуризации).

(12) Сжатие таблиц информационной базы

(12) Попробуй сделать в SQL шринк большой базы. Не хвостовой, а с дефрагментацией пустого места внутрях. Заипешься ждать. Это тяжелая операция.
Необходимости в шринках я вообще не вижу, как таковой. Только если форс-мажор какой-нить.

(12) скуль такой же, память выделяется скачками. Или он тоже отстой и быдлоСУБД?

(7), (13) Спс, успокоили)

(17) сделай (14), будет расти опять

Любая СУБД старается место у ОС забирать с запасом и никогда его добровольно назад не отдает. Потому что по меркам СУБД увеличение размера файла БД - очень медленная операция.