Всем привет!
Большая организация, больше сотни филиалов. Если раньше на тех же продажах база росла на 10-20% в год, то сейчас объём может скакнуть на 10% за месяц.
База прилично допилена разными франчами и нами, но большого размера самостоятельно добавленных объектов не видим.

Через .dt пробовали перезагружать, ощутимо не помогает.
ТИИ не сделать - за выходные не успеет, а на неделю организацию остановить никто не даст.

Поделитесь, пожалуйста, опытом и общепринятой практикой в таких случаях.
У какого какой максимальный размер УТ?

Что делать?
Глубоко копать архитектуру и данные SQL-таблиц?
Начать с 1 января работу в новой базе с чистого листа?

так а посмотреть причину? Может кто то решил хранить картинки в базе или включили историю данных

возъми копию и сравни какие таблички резко выросли

Посмотреть, какие таблицы весят больше всего и сделать выводы.

Полина сейчас конфигурации весят, может полтеррабайта?

Пол гига? Ты серьезно?

*(4) полгига

(4) тьфу, точно - ПОЛТЕРРАБАЙТА

может еще в сторону железа посмотреть, возможно пора делать апгрейд

размер базы вроде же не должен особо влиять на работу. если нет кривых каких то отчетов обработок которые данные от начала до конца времен перелопачивают.
добавляйте диски да память своевременно и пусть живет.

ТИИ делают на копии.
размер базы влияет на скорость развертывания резервной копии.
база требует ухода. возможно не закрываются остатки.возможно неправильно настроено автоувеличение размера.
возможна дефрагментация.

(1) Картинки в томе на диске, история версий включена. Но как оценить затраты места на историю версий?
(2),(3) - больше всего весят РегистрНакопления.СебестоимостьТоваров и РегистрНакопления.ТоварыКПоступлению. Они же и растут. Есть ещё пара самописных регистров, подумаем над их оптимизаций.
(8),(9) - железо только что проапргейдили, работает вроде вменяемо по скорости. Но пугает рост и необходимость больших объёмов для резервного копирования и технических операций.

(10) почитаем про закрытие остатков и автоувеличение размера.
Дефрагментация SQL? Недавно переносили на новый сервер, меньше не стала.

(11) История версия - это регистр сведений

(13) 12 гигов занимает... вроде пока терпимо.

Была у меня такая база УПП 1.2, в таблицах документов по 5млн записей, удалять документы средствами 1С было нереально долго, о стандартной свертке можно было забыть. Быстрее всего удалить все документы из самых жирных таблиц запросами SQL за секунды удаляются миллионы документов, провести ТИИ, в регистрах автоматом будут удалены все движения без документов. После этого удалить все не используемые товары и контрагентов и другую НСИ, внести остатки на начало и вперед.
Можно (даже нужно) оставить 1год с документами, и внести остатки задним числом на начало прошлого года. Так даже надежнее потому что остатки уже не изменятся, а если начинать с чистой базы, нач. остатки будут постоянно корректироваться.

(15) Тормозила, что-ли? Зачем резать-то?

+(15) моя УПП занимала 750гб, была распределена на несколько дисков, т.е. файлы и лог базы были разделены на 20 или 30 файлов точно не помню. База летала, руководство просило свертку чтобы отчеты быстрее работали.

1С может занимать и 5ТБ, какая вообще разница, главное правильно ее хранить на дисках, массив из ССД, разделенные файлы базы и все будет отлично.

(17) Хм. Интересно. А для чего 20-30 файлов?

(11) Регистр весит или таблицы остатков и текущих итогов?

(20) и он был изменен по сравнению с типовым? Может добавили по измерению индексацию\доп.упорядочивание?

(0) Начать с 1 января работу в новой базе с чистого листа!

Точнее заранее подготовить базу где будут остатки на 1-е января 2020 и движения за 2020 год, настроить онлайн синхронизацию с текущей полной базой и с 1 января 2021 перейти на нее гладко.

(0) Если тормозов нет, работать дальше. А куда вы денетесь?

(18) "разделенные файлы базы и все будет отлично." - зачем? Прекрасно базы > 1 Тб живут одним файлом.

чую, автор не знает ни про пересчет итогов, ни про закрытие регистров в ноль, ни про свертку

(25) "не знает ни про пересчет итогов" - он уже через dt выгружал/загружал.

(24) сегментация больших баз уменьшает нагрузку на память и диск, сиквел разные файлы перезаписывает, или читает сразу из нескольких что быстрее чем из одного большого файла, который медленнее инициализируется на дисках при обращении на запись.

(0) Попробовать запустить вот это
https://yadi.sk/d/LJ2xEA5Zj6pz9w

и посмотреть не вернет ли она какой нибудь дичи.

(0) резервные копии бд полные, частичные или журнала делаются ?
и как часто и за какой период хранятся ?

(0) у нас объем базы 850 ГБ, полет нормальный. Планы обслуживания на скуле должны четко работать, тогда все будет нормально.

(27) А есть какие-нибудь результаты тестов? В самом деле интересно.

(0) если в dt при таком объеме выгружается, то значит итоги распухли. Скорее всего какой-то регистр не закрывается.

(30) у вас тоже платны обслуживания на каких-то мега-скриптах?
Кто бы помог раз и навсегда понять периодичность и порядок обслуживания баз SQL.

(33) Обычно под обслуживанием имеют ввиду реиндекс. Например: http://www.gilev.ru/dbreindex/
И обновление статистики. И настройку шага роста базы. А дальше sql сам справится :)

Бэкапы - отдельная песнь.

(34)
все зависит от цели.
если цель администрирование -  обеспечение бесперебойной работы,
то задача намного шире - тут и производительность и надежность и резервирование.

просто реиндексация и принудительное обновление статистики - типовой шаблон , вообще бессмысленный  вне 1с8 .

А вот управление индексами - вполне живая задача, требующая периодического внимания в силу динамичного изменения состава данных
и смешанной модели 1с olap-oltp,  даже при наличии ssd .