Новые объекты (документы) не создаются
создаются новые строки ТЧ

А то надо посчитать, если считать в один поток - то долго
разделил на 10 фоновых
пользователи взвыли - 1С медленно работает

что если базу подключить к другому серверу - чем может быть чревато?

А если вообще посчитать не на 1С а потом тупо загрузить?

(1) это долго разбираться надо
и почему рабочая база - расчет зависит от настроек - считаю,меняю настройки - считаю снова - смотрю что не так - опять настройки - расчет

в общем издержки на работу в копии пока превышают издержки на работу в рабочей БД

и вот как бы таблица с которой хочу работать в копии ИБ (подключенной к рабочей БД) не модифицируется в рабочей ИБ

(2) Какое-то странное решение. Зачем один и тот же документ по 100500 раз перезаписывать добавляя новые строки? Проще тогда с РС работать

регламентные отключить не забыть...

Т.е. тренируетесь на кошках...
Увлекательное занятие.

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

(0) На ИТС написано что да можно ту же sql базу подключить к другому серверу 1С или к тому же но отдельной базой
Но сам понимаешь что этот режим очень опасен, ибо (4) да и просто при вроде бы только чтение конфа запросто может на запись что то сделать и привет

Правильный вариант по идее это кластер серверов 1С
Ну или да РИБ и на копии базы делаешь что надо

БСП помешало - спрашивает про "Копию" при старте ...

(8) Так этот механизм на внешнем файле базируется. Тебе как помешать может?
(0) А затык точно на сервере 1С, а то зная любовь ЗУП к запросам... может и SQL тормозить - тогда смысла в (0) нет.

(9) у тс нет упоминая, что это ЗУП

(0) Я бы не рисковал. Может, проще оптимизировать?

ну а по сути - чем это страшно?
нарушение нумерации - когда документы создаются из ИБ-копии
что еще?
оптимизация не наш метод - надо посмотреть в сторону РИБ - и выноса "экономической" составляющей из базы первички - но это дело ближайшей пятилетки

Можно почитать про ДатаАкселератор.

Также можно делать конвеер,когда при проведении документа пишутся только важные первичные данные,а все остальное рассчитывается потом,в том числе и служебные данные для ускорения отчетов.

(14) доступен только для лицензии КОРП ...

У меня только один вопрос,а можно ли не писать сразу результаты,а просто посчитать потоками там или как-то еще,а под конец записать один раз?

Тогда мы потоку для исполнения даем запись в регистре - он ее обсчитывает и возвращает результат в него же.
А потом одним заданием собираем все результаты и пишем.

Может сервер получше уже пора?

(18) кардинальное решение - а что,если все запустить на новом сервере.
Опять же,кластер позволяет несколько серверов.

i9-13900K уже продаются - камни супер https://www.cpubenchmark.net/singleThread.html

(17) нифига не понял
у меня суть задачи - есть "медицинские" документы осмотров и исследований
там нет привязки к "прейскуранту"
есть алгоритмы расчета прейскуранта от мед. документа

при этом расчета еще не отлажены

запускаю расчет - получаю результат - смотрю что получилось, меняю алгоритмы - опять расчет - ну и по кругу

при этом сам расчет в один поток занимает порядка 2 часов
ок- поделим по месяцам рождения пациентов - 12 потоков
но !! тогда получаем (0) - перегрузка сервера 1С 12 ядер 100% нагрузкой

(21) средствами скуля база копируется быстро
в итоге тебе нужен другой сервер/комп для разработки/отладки

и вероятно какие то проблемы с алгоритмом и запросами при расчете
ну не может оно так грузить если все нормально

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

(22) ну там "пользовательский" интерфейс - на основе СКД
т.е. на документ навешиваю СКД, потом передаю в СКД ссылку - и смотрю что получилось - медленно и печально, зато ...

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

(21) Алгоритмы можно отладить на выборке данных? Или обязательно на всех?

(24) Это печально.

(26) вопрос не про то
а о том, что копия ИБ может ли быть использована для распределения нагрузки

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

Пользователи - это отдельная история.
Помнится,я писал алгоритм,который рисует очередь ФИФО по выбранной детализации по группам партнеров,очень старался,чтобы быстро работало.
А потом,пользователи,этот отчет в несколько потоков запускали,чтобы разные детализации получить.
Что тут можно сказать.
Плэтому,вопрос нужно ставить не о том как сделать,а сначала о целесообразности расчета на реальных данных.

Если узкое место = сервер приложений, то делай кластер 1С и на отдельный сервер кластера вешай требование назначения функциональности типа [BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>]
Если узкое место = сервер СУБД, то тут по красивому не получится:
- либо через "подобрал/посмотрел" на свежей базе бэкапа/разработки;
- либо (как уже выше писали) через РИБ на отдельном сервере СУБД;
- либо через усиление сервера СУБД

у него узкое место в нагрузках
непойми кого
непойми когда
непойми где

А ему тут все непойми чего советовать пытаются.

И это... даже не обязательно будет на отдельном сервере. Совсем не обязательно.
Когда весь объем актуальных данных будет передан в РИБ узел, то оперативная загрузка туда же вводимых данных не будет занимать гигантское время.
А на параллельном узле в независимом от всех пользователей в монопольном режиме запуск расчета и результат.
Причем, если будет необходимо, то поскольку независимо от пользователей, можно в толстом клиенте сидеть монопольно.
Который будет также минимальный по размеру.
Полная загрузка данных, если она будет нужна зачем-то - в ночное время, как вариант.