Столкнулся с такой проблемой. Из за больших размеров базы оооочень долго идёт перепроведение. Добавил в обработку перепровода логирование для расчёта сколько времени потребовалось на проведение документа. И вот что выявил. Время затраченное при повторном перепроведении в несколько раз сокращается. Например документы "выпуск продукции" при первом запуске перепроведения проводятся 15-20 минут, при провторном запуске в тех же условиях за минуту. С чем это может быть связано? Никто не сталкивался?

кэширование данных.

кеш...

Размер базы какой? Скуль или дбф?

База скульная, MDF весит 7 гигов (обрезаю каждый год).
А причём тут кэширование?

в отладчике посмотри на чем висит

reconnectnative наше все

ну и +(5), сделай замер на выпуске продукции.

Дело в том, что он все документы так проводит, это не упирается в конкретный документ... Тут скорее всего дело либо в другом... Может в принципе построения внутренних таблиц... Незнаю вообщем, вот и спросил может кто сталкивался с таким...

reconnectnative - это что? Перезакуск скуля?

(9) угу, это если много док-тов и много строк в них. общее время проведения уменьшается в 5-7 раз, у меня так было.

на базе в 5 раз больше твоей, примерно.

сделай замерчик просто ради интереса... может наведет на мысли

Это всё уже проходили, и делаем это каждую ночь перед запуском автоматического перепроведения...

(13) что делается? reconnectnative это не перезапуск скуля в ручном режиме, а именно рекконект по время проведения, например каждые 50 док-тов. в поиск.

(13) все таки сделай замер производительности в отладчике... - просят же

Сколько строк в документе, который 20 минут проводиться?

FN Сделаю, сделаю...
Я думаю что это может быть из за расчёта "правильных" партий для списания... Но что посмотрим после проведения замера...
Sh1ko 40-70 строк. А reconnectnative можно сделать средствами 1С?

(17) при использовании 1с++. Час на поиск и чтение форумов, еще час на написание обработки.

(17) Именно этими средстввами он и делается.

(17) я думаю, что при первом проведении в самом док-те заполняются какие-то данные.

проще перевести базу на 2005\2008 ..там не надо думать о рекконекте

(21) Вариант. но "что-то я очкую"©

Sh1ko поищу в нете... А обработкой этой не поделишься?:-[ При первом проведении как и при последующих никаких данных не заполняется.
Ёпрст3 База была на 2005 работала медленно, перевели месяц назад на 2008 (64 бита) и оказалось что 2005 работает намного шустрее... Через недельку будем пробовать ставить 2008 но уже 32 бита, посмотрим что получится...

И это с обновлённым железом...

(23) это всё зависит от соотношения радиусов

(23) Забудь. не нужен тебе реконект. Смотри замер + счетчики производительности + скрипт от vde

http://infostart.ru/public/16681/

FN Ну я тоже слышал что в новых скульках этой хрени нет...

(28) покажи первые 10-20 строк замера производительности при проведении одного документа "выпуск продукции" строк на 50

FN С замером завтра буду баловтаься... О результатах расскажу..

Проведение можно написать так что на sql2000 замедления не будет.
Главное не пользовать фильтры которые кладутся в tempdb

(31) УложитьСписок кладется в tempdb?

(32) да

(33) Вот и прекрасно - а у меня не так :)