Принимаются советы по оптимизации УРБД. УТ 10.3.3 #453587

Всем здрасьте. Ситуация в следующем. Есть склад - центральный узел. Стоит скуль. База уже порядка 20 гб. Платформа 8.1.11. Конфа УТ 10.3.3. Распределенка по магазинам - 7 узлов. Везде файловая. План обмена - полный. Базы у них 8-9 гигов в основном из-за отсутствия изображений номенклатуры и ее свойств.(т.к. это используется для сайта и нужно только в центре). Задача-максимум: минимизировать лишнюю информацию в узлах, чтоб базы остались живыми еще как можно дольше. Уже поудалял все ненужные движения по неиспользуемым регистрам. Сейчас хочу удалить все журналы документов, тк они не используются. Самый категоричный вариант - сделать план обмена только по организациям. (Каждому узлу соответствует своя.) Но много заморочек, в частности, есть необходимость сделать возможность в каждом узле видеть остатки других узлов. Вопросов несколько: 1. Как лучше реализовать, при обмене по организациям, чтобы видели все остатки? 2. Сильно ли затормозит базу, если в каждый узел перенести все изображения? (Прогнозное распухание базы до 12-13 гигов) Просто пользователи в магазинах тоже хотят лицезреть картинки. 3. Что еще можно придумать для уменьшения баз в узлах? Всем заранее большое спасибо за советы.

Нууууу. Подменять тип документа при обмене. Типа Поступление товаров, реализация товаров (по другим организациям)-> Отображение движений товаров (непроводной документ, чисто "хранитель" движений.

Нет. Теоретически - почти ничего не изменится кроме объема

З.Ы. Посмотри ссылки на справочник "Организации" - в частности Рег сведений, и подумай, может их фильтровать....

А у меня была мысль сделать регистр сведений "Остатки товаров". Обновлять его ночью. И подвязать на него отчеты. То есть не должно тупить сильнее? и конец не станет ближе? (в смысле работы с нормальной скоростью)

1. выгрузи в скуль 2. замерь размер таблиц 3. анализируй самые тяжелые таблицы 4. думай ---- а то вслепую можно крохи удалить, а слона не заметить --- а сворачить не думал?

Сворачивать очень не хочется клиентам. Это самый крайний вариант. Я в принципе следую пунктам 3 и 4. Тут и без скуля понятно. По мелочам не заморачиваюсь в принципе. Основной объем данных - более 100 000 номенклатуры (и все, что с ней связано) и расходные документы. Все, что связано с партионным учетом и НДС удалено за ненадобностью.

ап чтоль

Вместо АпЧтоЛи :) Файловую оптимизировать? :( Пингвин + Постгрю :) Расшифрую: я не заморачивался с "оптимизацией" - а заменил на Linux + PostgreSQL.

Все замечательно, но 36*7 = много денюшек на серверные лицензии. При том, что нагрузка в магазинах минимальная. Никаких отчетов. Тупо забивать чеки. И сейчас работает нормально. Беспокоит перспектива.

емае.. 7-9 гиг для магазина с требованием "забивать только чеки" - что-то явно сильно много...

Это шо за беда. Кто то бота тестит? Ну хорошо. 90% - забивать чеки. + Должны видеть остатки везде. + Расходные со склада на их магазин для автоматического прихода. Просто пока что полный план обмена. Придумывать с его урезанием наверняка придется. Но позже. В принципе у меня уже ряд мыслей сформировался по уменьшению баз в узлах и обмену по организациям. Остаются открытыми вопросы №1 и №2 в .

Что касается 2) Есть обработка на инфостарте по выгрузке всех картинок из базы в папку. Предполагаю что файловая распухнет в магазинах примерно на этот объем. Что бы рекомендовать по 1) надо знать сколько у тебя организаций, остатки по каким Организациям тебе нужный в магазинах. В принципе проблема решаема очень изящно на УТ с помощью дописки при выгрузке данных в подчиненные и еще в паре мест. Отчеты переписывать не надо. Насколько помню основные сложности возникали с Партиями, но я там все решаемо. Припоминаю что как то терли вот такую тему по итогу решили задачу.