Снегопат

Всё, я нашел причину тормозов. Всем кому интересно читаем дальше.

С помощью обработки http://infostart.ru/public/99236/ разобрал структуру БД, нашел различия в индексах между БП и УТ.
У каждого документа есть индекс вида:

Так вот в УТ, за счет общих реквизитов - разделителей учета - этот индекс дополняется еще одним измерением:

В результате получается что при отборе документов по дате, в первом случае этот индекс используется, а во втором не используется. Отсюда и тормоза. Возможно на SQL-версии мощные движки СУБД умеют оптимизировать запросы и с имеющимися индексами, но в случае файловой версии движок 1С тупит.

Вариант решения проблемы.

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

Если в учете не используются разделители учета (это как раз мой случай), то порядок действий следующий:
1. создать архивную копию БД.
2. обработкой ВыгрузкаЗагрузкаДанныхXML (я использовал слегка исправленную версию от 8.3 для Уф) выгрузить в файл все справочники и планы видов характеристик, так как слетят значения предопределенных объектов.
3. открыть состав общего реквизита ОбластьДанныхОсновныеДанные и установить признак использования в состояние "Не использовать" для всех объектов, кроме констант, регламентных заданий и планов обмена (с ними гемор). общий реквизит ОбластьДанныхВспомогательныеДанные не трогаем.
4. сохранить/обновить конфигурацию БД.
5. обработкой ВыгрузкаЗагрузкаДанныхXML загрузить из файла сохраненные ранее справочники и планы видов характеристик (слетевшие значения вернутся на место).
6. проверить работу.

По итогу конфа работает даже в целом веселее, и устраняется описанная в первом посту фича с запросами. Думаю что в ряде случаев 1С начинает наконец-то попадать в индекс там где раньше не попадала. Можно выполнить также сжатие таблиц БД, реиндексацию, реструктуризацию и т.д.

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

Спасибо. Будем знать.

Подход к решению проблемы внушает уважение!

Саш, смеешься? ))) Просто выхода другого не было, только что заключил договор с новым клиентом на абонентку и нужно было в течение 2-3 дней решить проблему с тормозами не взяв ни одной лишней копейки на оборудование или ПО. А дальше приработаюсь с ними и потихоньку пробью новый сервак и MS SQL, перепишу все тормозные участки в учете.

Наоборот, категорически приветствую. Люблю, когда к делу подходят серьезно и копают, пока не найдут истинную причину.

Очень интересная информация! Спасибо!

А может в случае, если разделители учета не используются, просто добавить условие по разделителю учета в запрос (чему там оно равно "не заданное значение")?

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

Если копия базы осталась, уточните пожалуйста этот момент, очень интересно, соответствуют ли рекомендации 1С действительности, или нет (у меня к сожалению нет подходящих баз)

Общие реквизиты отсутствуют в составе реквизитов запроса. Попытка вручную указать в запросе условие "РеализацияТоваровУслугТовары.Ссылка.ОбластьДанныхОсновныеДанные=0" или "РеализацияТоваровУслугТовары.ОбластьДанныхОсновныеДанные=0" приводят к ошибке, ругается на отсутствие такого реквизита. Соответственно вручную указать в запросе область разделения данных невозможно.