Прошу в ICQ 201216890 - обсудим.

посмотри еще эту тему
http://www.1cpp.ru/forum/YaBB.pl?num=1276610073

Пишите. Мне интересно.

У автора топика установлен SQL 2000 SP3.
После предварительного общения стало ясно что проблема заключается именно в перепроведении документов за период. Анализ замеров производительности показал что:
1) При проведении документа НЕ НА ТА действительно самым узким местом является расчет регистров при списании МПЗ.
2) При проведении документа НА ТА узким местом оказался модуль взаиморасчетов который проверял на наличие Налога с продаж в документе реализации. Так в цикле использовался вызов функции глНп... (не помню точно) ну и прочие моменты.
Был проведен анализ состояния фрагментации индексов и созданы планы обслуживания (job-ы).
По данным выводам было принято решение об оптимизации участка взаиморасчетов что и было сделано изменением кода.
После данных манипуляций стало ясно, что оптимизация путем перевода на прямые запросы принесет прирост порядка 20-30% при этом основная проблема замедления проведения на SQL 2000 решена не будет. В связи с высокой нагруженностью базы и сроками на реализацию оптимизации в пределах 8 часов было принято решение о выставлении приоритета на внедрение ReconnectNative при перепроведении документов. Была реализована обработка по перепроведению документов со сдвигом ТА в случае непроведения документа на следующий, изменен глобальный модуль для отсутствия курсоров.
Таким образом эффект достигнутый именно комплексом мероприятий по анализу и устранению узких мест привел к требуемому результату - перепроведению базы за время которое для этого отведено. Перевод на прямые запросы расчетов при проведении на ТА дадут в среднем от 20 до 30 % как выше и говорилось, но затраты на внедрение данного решения не соответствуют эффективности полученного результата на текущий момент.

(8) В переводе на русский в (7) сказано:
1. Поменяли код расчета взаиморасчетов. Полезно, но не совсем то.
2. Поставили в джобах дефрагментацию индексов. Это всегда полезно. Но опять не совсем то.
3. Использовали ReconnectNative. Вот теперь самое то.

Не знаю какой это ПУБ, но в Украинском точно сделано тормознуто, там регистры расчитвыются не один раз а построчно (когда то переделывал), можно начать искать в этом направлении.
2 - Посмотреть на таблицу остатков по регистрам, возможно остатки не закрываются и висят где то пересортицы, закрыть ненужные значения.
3 -  Быстрая обработка движений - добавляет в табицу движений регистра (RA) 2 поля "DATE_TIME_IDDOC" и "IDDOCDEF". Не думаю что при расчеие остатков эти поля необходимы
4 - Отбор движений - добавляет индекс к таблице движений по измерению
5 - Отбор итогов добавляет индекс в таблицу итогов по измерению

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

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

Neo писал(а) 14. Января 2011 :: 12:02:

Либо можно оптимизировать, либо остатки считаются неправильно, в зависимости от того, уникальны ли $Док.Товар в пределах документа.