Уважаемые специалисты, пожалуйста посоветуйте:

База УТ11, пытаюсь хоть немного ее разогнать (регулярно подтормаживает), обнаружил, что на 10Гб размера в файловой копии - 4Гб занимает ХранилищеСистемныхНастроек и 1.5 Гб - адресная информация и ее история. Вопрос - чем чревата полная чистка хранилища системных настроек? Я конечно попробую грохнуть информацию неработающих пользователей, но вдруг проще удалить вообще все? И почему это хранилище так раздувается, прямо как незакрытый регистр? Такой же вопрос по адресной информации - похоже что при создании базы в нее загрузили полный классификатор - до какой степени его можно чистить?

Адресный можно полностью потереть и заново загрузить
ХранилищеСистемныхНастроек тоже можно чистить.

Но сначала понятно дело на копии проверь все

(1) спасибо, а все таки чем может быть чревата полная очистка ХранилищеСистемныхНастроек?

(2) Грохнули всех юзеров и завели снова, но в документах они остались, только настройки того.

Кардинально решит проблему только переход на клиент-серверный вариант.

(3) какие настройки в УТ11 могут быть такими важными, чтобы их потерю заметили юзеры?

(4) рабочая база уже в клиент-сервере. Файловая версия применяется только для поиска раздутых вещей (обработка пузомерка для файловой версии).

(5) Странный подход. Традиционные замеры не помогают?

(5) значения по умолчанию в для документов и настройки дефолтные в формах

(7) для новых документов

Сколько пользователей ИБ в этой базе заведено?

(6) я в этой конторе новенький и прав у меня (например доступ к скулю) очень мало. Опыта в восьмерке тоже. Тапер играет как умеет.

(7),(8) пропадание этих настроек повлияет на работу? Спасибо, учту- сначала снесу настройки уволенных и поищу, чъих настроек слишком много.

(9) Живых - 40. Всего - 59.

Вдогонку - найдено несколько пользователей с количеством настроек - 2-3 тысячи (у остальных - 100-500). В основном это записи с ключом "Отчет.ПоступлениеИОтгрузкаТоваров/ПоступлениеИОтгрузкаТовара07e0b33d-4bbb-467b-b8a4-818959eec75b/КлючТекущегоВарианта". Могу я их грохнуть или пользователь огорчится?

Покажи список настроек для одного и того же отчета

(11) Грохай. На копии можно всё, что хочешь.

(12) можно уточнить, что именно надо показать? Сколько вариантов отчета есть? Или показать записи по этому отчету из хранилища?

(13) на копии я уже все грохнул, но интересно как дела пойдут на живой базе у живых пользователей.

Если нужен просто список ключей этого отчета (он типовой в УТ11), то вот ссылка (извините за гуглодиск)
https://docs.google.com/spreadsheets/d/1oopMPyk5KLVq8jh-Bb1dmWPb8pX4P4oFPqFALrw3HWw/edit?usp=sharing

(14) У одного и того же пользователя сколько записей для одного и того же варианта отчета? Я так понял, очень много с разными суффиксами-гуидами

(16) вот навскидку вывел одного пользователя - 1420 записей по одному отчету. Чую что бесовщина, но обосновать не могу.

(17) В конфигурацию походу кто-то добавил код в модуль формы

КлючСохраненияПоложенияОкна = Новый УникальныйИдентификатор();

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

(17) ну может там в параметры выведена дата? вот пользователь за каждый день формирует, как минимум 365 дней в году, а если в сочетании периодов, то и еще больше. Ну это я так фантазирую. Хотя, на формируемый уникальный ключ могут влиять все настройки отборов. Допустим, перечень разных складов будет давать два-три десятка просто в сочетании с какими-то еще вариантами это даст такое вот количество.

(18) а если еще и при каждом открытии окна, так будет совсем много для такого активного менеджера в отделе закупок, формирующего что-то по остаткам.

Кстати, для (17) - а попробуйте сравнить этот отчет с типовым, в чем-то существенном его никто не модифицировал?

Как результат - на каждое закрытие формы база растет на 160 букв кириллицы, что в UTF кажись занимает ~320 байт

Самое смешное, что отчет то будет выдавать результат быстро-быстро, но очень-очень долго открываться

(18) я дико извиняюсь, но этот отчет - типовой (специально проверил. Строки, похожие на "КлючСохраненияПоложенияОкна = Новый УникальныйИдентификатор();" - встречаются в общих модулях, но они похоже тоже не добавленные.

(21) я практически уверен, что так и есть - в базе постоянные какие-то тормоза.

И еще - я сделал полное сравнение текущей конфигурации и типовой - в изменениях не встречается КлючСохраненияПоложенияОкна.

(23) опередил. как минимум, я это и хотел предложить - сравнить

Необязательно идет переопределение ключа положения окна. Может, там дописывается ГУИД в КлючТекущегоВарианта...

"в изменениях не встречается КлючСохраненияПоложенияОкна" // Надо поискать в изменениях "Новый УникальныйИдентификатор()"

Да, стопудово ГУИД дописывается к ключу варианта отчета

"я в этой конторе новенький" // Вычисли автора кода, подыми свой авторитет ))

(26) "Новый УникальныйИдентификатор()" не встречается в изменениях, встречается только УникальныйИдентификатор() - как параметр открытия форм (посторонних) и выгрузки таблиц во временное хранилище.

Я кстати понял, как эта зараза плодится, но не нашел конкретное место записи. Пользователь открывает карточку товара, выбирает Доступные остатки, в открывшемся отчете - нажимает Расшифровать другим отчетом - Поступление и отгрузка. После чего в хранилище системных настроек появляется три записи. Пытаюсь отладчиком поймать, но пока не нашел - вызываемый отчет ПоступлениеИОтгрузкаТоваров - написан на СКД, а в настройках СКД я пока совсем начинающий.

Отладчиком ты не поймаешь, это ведь автоматически сохраняемые настройки

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

"абсолютно у все объектов было включено изменение" // А смысл каждый раз лезть и искать в дереве поставщика, чтобы снять замочек?

(30) а что тогда остается? Регулярная чистка? Я уже решился тупо удалить все записи, относящиеся к этому отчету.

(33) Конечно удаляй. Насчет регулярной чистки - сначала проверил бы, в демобазе такое вопроизводится или нет...

(32) а обновления ставить? Замочек снять - дело минуты. Зато теперь конфигуратор в куче мест тупо тормозит, даже после возврата замочков.

Большое всем спасибо за помощь. Как приятно не оставаться одному наедине с проблемой.

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

"а обновления ставить?" // Так есть же настройка "показывать дважды измененные"

(36) мне показалось (возможно я неправ) - разница в скорости все же есть.

Последний вопрос не дает покоя - как избавиться от распухания этого регистра? Только регулярная чистка?

(39) Можно не вносить данные или  не пользоваться отчетами.

(39) не буду рекламировать или искать по просьбе, но как-то мне попадались на глаза уже готовые обработки для чистки что-то такого. Я не вникал в детали.
Можно и самому написать, тем более, после такого детального разбора, как сделал тс, чтоб обсуждать проблему в этой ветке.

(39) Я бы на твоем месте все-таки проверил (34) и в случае невоспроизведения в демо-базе искоренил причину дописывания гуидов

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