Доброе утро!

Мучает такой вопрос, не знаю с какой стороны подступиться.

УТ 10.3, РИБ, полный план обмена: 3 филиала(по одному пользователю в каждом), 1 головной офис(~35 пользователей). Размер базы данных за 2 года достиг 15 гб.
В главном офисе все крутится на mssql и мощном железе - проблем никаких.
А вот в филиалах, в файловом варианте и на более слабых компьютерах, стало немного подтормаживать. Не то чтобы очень, но первые звоночки уже есть и работать стало менее комфортно.
На сайте Гилева(http://www.gilev.ru/mssqlvsfile/) нашел информацию, что после 16 гб в файловых базах возникают проблемы с тормозами.

Какие варианты дальнейшей эксплуатации системы возможны:
1. Делать неполный план обмена, обмениваться только необходимой информацией.
2. Писать под филиалы отдельную конфу, в которой не будет ничего лишнего и выстраивать обмен.
3. Каким-то образом свернуть(обрезать) базу в филиалах, поскольку аналитика там не нужна.

Апгрейд железа не рассматриваю, так как компы в филиалах стоят не плохие, не сервер же мощный им ставить.

Может быть у кого то есть еще мысли, поделитесь, пожалуйста.
Есть у кого базы больше 16 гб в файловом варианте? Если есть, то как работают?

вариант - поставить Розницу, в ней есть правила обмена с УТ, при необходимости допилить напильником (КД)

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

как-то так

Вариант №1: мне больше всех нравится.

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

Вариант №2 и №3: можно сделать, но тогда это будет уже не РИБ, а УРИБ (в принципе, конфигурации могут быть одинаковые, но не идентичные).

Вот как-то так :)

(1) На счет розницы неплохой вариант, но конечно хотелось бы остаться в привычной среде. Это буду использовать в последнюю очередь.
(2) Такой вариант нравится мне больше, но пока слабо представляю как все это сделать, надо будет погрызть книжки. (3) Не очен ьпонял что Вы имеете в виду "В принципе можно написать для филиалов   "отдельную" конфигурации смысл которой - удаление "избыточных" данных. "

(2) а хотя представил, ничего сложного.
Минус вижу только один - если развалится обмен и придется делать новый образ, эту операцию нужно будет повторить. Кроме того, делать это будет нужно периодически при распухании и запас тут достаточно большой, к примеру до тех пор, пока таблица документов реализаций не достигнет 4 гб, чего ждать долго, сейчас она 32 мб:)

(4) работы максимум на субботу-воскресенье :) (чтобы в базе никто не работал) главное определить что можно грохнуть - регистры, справочники, документы..

пишется обормотка для непосредственного удаления данных

РегистрацияИзмененийДляОбмена82 (обычное приложение).epf есть на ИТС или встроенная обормотка Регистрация изменений для обмена - это чтобы посмотреть какие изменения зарегистрированы для обмена и очистить всю регистрацию...

(5) почему он развалиться должен? если что-то лишнее грохнул, не проблема заново на обмен зарегистрировать из Главного узла, главное не переборщить с количеством изменений :)

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

посмотрел размеры таблиц, ~70-80% данных находятся в:
РегистрНакопления.Продажи
РегистрСведений.СписанныеТовары
РегистрНакопления.Продажи
РегистрНакопления.ПартииТоваровНаСкладах
РегистрНакопления.ТоварыОрганизаций
РегистрНакопления.НДСРасчетыСПокупателями
РегистрНакопления.ТоварыНаСкладах
РегистрНакопления.ПартииТоваровНаСкладах
РегистрНакопления.ПродажиСебестоимость
РегистрНакопления.ТоварыКПолучениюНаСклады
РегистрСведений.ОбъектыДоступаДокументов
Документ.ОтчетОРозничныхПродажах.ТабличнаяЧасть.Товары
РегистрНакопления.ТоварыОрганизаций
РегистрНакопления.ТоварыНаСкладах

Можно выборочно почистить только эти регистры

(7) просто были пару раз проблемы из-за пользователей, могут например комп в момент обмена перезагрузить ил типа того:)

Имхо: у РИБ есть одно "неоценимое" достоинство для особо ленивых :) - базу подчиненного узла всегда можно "реанимировать" по данным базы главного узла. Не хотелось бы от этого отказываться. Меня, например, это уже не раз выручало. На филиалах не только "слабая" техника, но и юзверы такие же :) Даже, зачастую, и админов нет :(

(10) так и делаем, про то и говорю, что после этого опять обрезать данные надо будет

Короче что будет сделано:
Полностью очищу эти регистры и "корректировкой записей регистров" введу начальные остатки по ним.
После этого сниму с этих корректировок регистрацию изменений, выгрузка-загрузка базы через конфигуратор и по идее все...

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

По результатам отпишусь.

(8) Как смотрел? Это важно, потому что база очень часто "распухает" не только от этих регистров.

(офф) вспомнил весьма эмоциональную ветку :) v8: О чем молчит 1С (хранение оборотного регистра)

(13) смотрел размеры таблиц в mssql в главном филиале.