Суть проблемы: для БП 8.2 есть отчет по задолженности контрагентов, его необходимо сдавать в конце каждой недели. Для того, чтобы отчет был корректен, необходимо перед его формированием восстанавливать последовательность (т.к. часто заводим документы не в том порядке, в каком они есть в реальности, а еще часто возникает необходимость исправить что-либо в ранее проведенных документах - таковы издержки бизнес-процесса).
В базе примерно 50 тыс. документов Поступление на расчетный счет, столько же Релизаций ТиУ. На компьютере с оперативной памятью 2 ГБ восстановление посл-стей идет около суток, работать нереально. т.е. в эту базу отчет пока внедрить не могу, а нужно. Как повысить производительность? Достаточно ли увеличить оперативку? Поможет ли перевод базы с файлового режима на клиент-серверный?

запусти регламент для восстановления последовательности - пусть ночами вытягивает

больше рамы и клиент сервер немного помогут.
(1) еще лучше поможет :)

(1) регламентное задание что ли создать?
но ведь процедура длилась больше суток, ночи не хватит...

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

(3) не хватит, но в ночи к примеру 6-7 часов, итого за 4 ночи неделя проведется

(5) дак они постоянно сбивать будут

(2) эээ... что такое рама?
В том-то и дело, что "немного". А мне надо как-то показать руководству, на сколько именно процентов помогут? На 10, 20, 50? Т.к. если предстоят немалые расходы на сервер, перенос базы на клиент-серверный вариант и т.д., и если после этого все будет ползти так же медленно, то меня, мягко говоря, "по головушке не погладят".

(6) сервер все равно круглосуточно работает, зато на утро максимально реальные данные

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

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

(9) надо не по сети запускать задание, а прямо на сервере. Тогда где-то в 10 раз будет быстрее. То есть не 6 часов, а полчаса.

(9) об этом я написал в (6), но в (8) есть крупица истины. на УТРО инфа будет боль-мень актуальная

(9) Раз такой бардак - проси либо железо для сервера максимально возможной производительности + СКЛ-сервер, либо пусть бухи руками исправляют свои косяки

(13) чем больше правок руками, тем меньше последовательностей, же

(0) боюсь, тут медицина бессильна

(14) Не понял

(15) Почему?

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

+ (18) подумай лучше, как избежать восстановления

Выигрышь в скорости проведения документов при переходу на SQL может вообщеть быть отрицательным относительно работы 1го пользователя в файловом режиме.
Важно понимать другое - при такой специфике последовательность надо дробить по контрагентам и восстанавливать по ним же.
Ну и если восстанавливать её каждый день, то не нужно будет сутки ждать, не успеет она так сильно сбиться.

(18) этого я и боялась, ждала здесь этой фразы.
Потому что на форумах и в статьях не раз встречала 2 противоположных мнения в ответ на вопрос: как сделать, чтобы 1С работала быстрее:
Превое: поможет sql и максимально производительное железо!
Второе - это не поможет, т.к. 1с все равно сожрет всю память, а sgl не означает ускорение - бывает даже и наоборот, замедляет!
Рекомендовали что-то мутить с блокировками (самостоятельно для каждого документа настраивать), но тут, как я понимаю, не в блокировках дело, ведь восстановление идет монопольно.

(19), (20) - супер идея, но как именно? Можно написать обработку, которая бы восстанавливала только по тем контрагентам, по которым были измнения, тогда:
1. Как узнать, по каким? и где хранить эту разницу?
2. Как вообще работает восстановление, где код посмотреть? Точку останова там, увы, не поставишь.

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

Можно распараллелить базы. Сделать две распределённых.
В одной круглосуточно восстанавливается последовательность, в другой оперативная работа. Потом обмен данными - всё с движениями регистров быстро переливается.

(23) - спасибо, попробую.

(22)
1.Последовательность может содержать измерения, они там прям в объектах и указывается.
2. Указывается связь этого измерения с измерениями регистров, которые двигают последовательность (ну там тупо контрагент=контрагент).

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

Минусы: собъётся последовательность партионного учета.

(24) и как только сливается, сразу теряет актуальность восстановленная последовательность...

(27) периодически нужно закрывать период для изменений задним числом.
Например, в оперативной рабочей базе закрыли период на такое-то число.
В соседней распределённой спокойно восстанавливаем последовательность на это число.
Если бухгалтеру нужно изменить документ задним числом, останавливаем проведение документов, двигаем дату запрета, меняем документ, обмениваемся данными и т.п.  бесконечная борьба за последовательность ;)

Снова всем здравствуйте!
Вот - для сравнения - у меня память на компе 4 ГБ, вечером восстановление запустила, утром пришла - все готово (на копии базы, она составляет примерно 2 Гб)
На сервере: память 8 Гб, 1С и база (база 2,5 Гб) - на этом сервере, в терминальном доступе запустили восстановление посл-стей: длилось оно сутки (пол-суток монопольно, потом пользователи подключились. т.к. уже нужно было начинать работу), тогда вообще зависло. А ведь при восствновлении последовательностей часто еще и ошибки возникают, когда процедура прерывается и не может документ провести - его надо проводить руками, и заново запускать процедуру.

2(29) кому это может быть интересно?

(23) Да, такой регистр есть - отчет строится именно по нему. В программе есть доработка, чтобы типовые документы (Реал. ТиУ, Поступл. на расч. сч. и др.) двигали этот регистр. Вопрос только в том, что как в этом регистре отмечать, какие документы проведены в верной последовательности. а какие нет.

(30) Вам, например. Вы же зашли в эту тему. Или мне надо было новую создавать?

может быть попробовать оптимизировать издержки бизнес процесса? приведите пример когда каждый день надо изменять кучу документов за прошлые периоды. Может тех кто сидит на документах заставить не ошибаться при их вводе?

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

Будет получше. Конкретика зависит от слишком многих факторов, чтобы дать ответ по фотографии. Проще всего - проверить.

В порядочных конторах ввобщ запрещено доки задним числом править. За это увольняют или лишают плюшек.

(34) пусть поставшики присылают в электронном виде. Используйте ордерную схему (в начале товар), а потом документы.

Поменять бизнес-процессы не в моих силах. Но за варианты спасибо, обязательно вынесу на обсуждение, может быть руководство что-то и решит.

(34) я не про то что документы приходят позже, я про их изменение...
ИМХО конечно, но ваша борьба за последовательность смахивает на параною...
Какая именно последовательность влияет на долги контрагентов? вы же наверняка эту задолженность берете не из регистров накопления а из регистра бухгалтерии. :)

Но пока мне вот этот вариант интересует - с регистром. Имею в виду, как по нему отследить, какие документы надо перепровести, а какие нет.

а какие документы определяют важность последовательности? Долги - это суммы, на счетах, итоги по счетам фиксируются раз в месяц. после закрытия месяца изменения не должны происходить.

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

Значит отчет у вас самописный и что то допилено на регистрах. Смотреть надо структуру регистра и реализацию отчета. Копайте в эту сторону.

Пересмотр цены за услугу и исправление ее задним числом в документе в течении текущего месяца... лихо.

(43)да там всё лихо. Ну да, самописный он, и на самописном же регистре.

2(32) зашел, думал что-то интересное. а тут нюансы какой-то базы. кому они нужны - не понятно.

(0)Рам-диск для восстановления используй.
ну или SSD на худой конец.