Есть Розница 2.2 каз. База 1 сентября 2018 года.
Уже 6 лет как не обновляется но дорабатывался достаточно.
Объем базы 220 ГБ.
РИБ 45-48 точек.
Куча интеграций = Битрикс, Службы доставки, База лояльности в 1С и другой софт, Звонки клиентам итп.
Развернут на кластере серверов скуль. Но 1с ный сервер (кластер) отдельный. На этом же сервере еще работают 2-3 базы более мелкие.
Бывают иногда тормоза иногда обмены тяжеловато проходят.
Есть желание свернуть базу.
Стоит ли сворачивать? Даст ли прирост скорости?
Как сворачивать если работа ведется 7/7с 8:00 до 23:00?
Кто имел опыт не стандартной свертки?
Скорее всего придется именно так и делать не стандартный подход использовать.
Например периферийные не трогать. А вот ЦБ свернуть но миграцию данных прошлого периода просто убрать из регистрации.

Похоже избитая давно тема.
Хотя тут почитал ветки там близко к моему варианту ничего нет.

Да вроде и нет особого смысла сворачивать.

"иногда обмены тяжеловато проходят." - объём базы сам по себе не оказывает влияние на обмены. Только тогда, когда очередное обновление с реструктуризацией затрагивает сами данные.
"миграцию данных прошлого периода просто убрать из регистрации." - вот этого точно не стоит делать.

(3) Я имел ввиду при свертке ЦБ и дальнейшее отправление во все ПБ.
Не хочу да и невозможно каждый узел сворачивать по дате....

Сделайте копию базы, сверните ее, затем сделайте обмен в центральный узел оригинальной базы, затем обработкой универсального переноса документов перетащите документы за эти 2-3 дня с боевой базы в свёрнутую копию и разворачивайте ее в качестве боевой

От риб отказаться вообще не вариант?

(4) не взлетит полагаю.

(5) +1

(5) Такое я практиковал раньше но с мелкими базами.
А тут база огромная и узлов много и обмен идет постоянно каждые пол часа.
Данные могут меняться в ЦБ за прошлые периоды! Ну хотя бы в течении последнего месяца. Вот тут засада.

(6) Очень сложно. Некотоыре точки имею инет не очень хороший.
ДА если и всех загнать в ЦТ то в ЦБ будет атас со скоростью обработки данных и с транзакциями думаю.

(9) Тебе не про обмены говорят, а про РИБ

Откажись от РИБ и используй другой обмен, более легковесный.

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

(0) Один из вопросов - получится после свертки корректно пересоздать периферийки при необходимости?

И по заявленному в топике описанию вообще не озвучена в чем проблема, что конкретно создает трудности в эксплуатации.
Просто большой размер центральной базы - ну может и большой. Но внутри СУБД сам по себе общий размер проблем не должен создавать.

(12) на кой их "пересоздавать"?

Ну и да, у автора не обозначено, что вообще он хочет резать - периферийные узлы облегчить или ЦБ облегчить. И цель не назначена.

(10) Да у нас итак есть обмен не риб-овский.
Там крутятся несколько видов доков типа
заказы, ОРП, перемещения, возвраты, реализация.
Розница у нас не простая там функционал нарастили прилично.
Сложно. Почти невозможно. Переделок тогда много надо.

Так что надо резать?
Размер перевыгружаемых пакетов в обмене, из-за того, что эти пакеты формируются в РИБ и туда попадают изменения конфигурации?

Хотя бы потому, что не на всех узлах высокая скорость инета.

(14) Главная цель облегчить ЦБ.
Проблема  в том что мы на грани работаем.
По моим ощущениям балансируем на лезвии ножа.
Чуть что-то делают бывают зависоны!
Хочется иметь приличный ресурс в скорости обработки данных. Скорость обмена итп.

ТУт еще мы заказали более крутые диски ссд. Быть может это нас даст еще некий интервал.

(17) не даст

(14) Например, при сбое/утере переферийки.

ну как бы предположение из практики работы. Роль супербыстрых дисков преувеличена. Когда диски были HDD и их заменяют SSD - это эффект покажет.
А замена SSD SSD - заметного эффекта не покажет.

(17) Вы пытаетесь лечить, не установив диагноз. Сначала - найти причину тормозов.

(19) гораздо проще и надежней привязать заново архивную версию, чем "пересоздавать".

Хотя понятно, что в нормальной работе проблем с созданием нового периферийного узла, даже для замены устаревшего или сломавшегося, не должно возникать

(20) Я тоже так же думал. Но нам практика показала что есть разница.
Раньше наша розница жила на лучшем из ссд дисков. А сейчас мы всех их загнали в в единый массив и даже кластеры завели (виндовый скульный - Сюрпризы жизни базы 1С в кластере.
Тут как раз таки показало нам разницу.

(21) Мне часть причин известны но я хочу быть готовым такому ценарию когда надо резать.
Рано или поздно надо резать. Или можно жить в базе 10-15 лет не разать. Тем более Розница?

(22) С отпочкованием нового узла тоже у меня были проблемы...
Очень много времени уходило. Иногда просто готовую болванку подсовывал.

т.е. взявши за момент отсчета времени замену железяки -- а заменили по факту состав используемого софта. Увидели положительный результат и решили, что замена дисков главная причина, а не повод софт обновить

(0) какими инструментами пользовались для анализа "тормозов"?

если анализа не было, то не факт, что срез и новое железо хоть как-то повлияет на быстродействие

(27) (28) Согласен. Есть такое. Надо еще изучать глубже.
Юзали ТЖ, Счетчики винды по дискам памяти и процу.

(26) Не совсем так. Просто все это совпало.
Я и ранее говорил что рано или поздно надо резать.
Быть может на это повлияло мой подход всегда резать чем наращивать железо или оптимизировать.

(29) ну и какой результат юзанья? Тяжелые запросы смотрели? Что в ТЖ во время зафиксированных тормозов? Скуль как настроен, сколько памяти выделяете в процентом соотношении? Работают через терминальник с 1с? Если да, то надеюсь он отдельно от скуля у вас?

ТЖ только ковырять начал. Пока что-то серьезное не нашел. Да и не умел. Учусь.
Скуль в кластере.  Процент памяти 60% и на одном сервера. А 1с серверы каждый по отдедьноси на 4х серверах.
В базу ходят тонким клиентом. Юзеров от 200 до 350 в день.

(32) сервер КОРП?

(33) Обычный 64й

(34) занесите денег в фирму 1С на функциональность КОРП, это позволит настойками сервера 1С (кластера) поиграться (ну там кол-во пользователей на процесс и прочие плюшки, ну и разделить по ролям хосты (например, фоновые задания на отдельный рпхост перенести?)

вот еще на подумать, контора специализируется на аудите производительности и репликация у них есть своя средствами скуля?

не реклама,  сам не пользовался, читал когда-то про них

https://www.softpoint.ru/

(36) Помню, помню еще со времен 1с77. Они что до сих пор есть?