Такая ситуация, в УТ 10.3 начинаю перепроводить документы за период, первые минут пять все летит с отличной скоростью, а потом производительность резко замедляется. Делаю в ТИИ реиндексацию и пересчет итогов и тогда перепроведение идет опять с нормальной скоростью, уже до конца операции.

В управлении итогами регистры: Рассчитан с: 01.07.2023, Установить с: 01.01.2023, Рассчитан по: 31.05.2024, Установить по: 30.06.2024.

В чем причина, где копать, настройки SQL или база?

Ногами сильно не бейте, так-то я директор, а одинесю для души ))

(0)

Вариантов всего два:
-- нанять нормального сисадмина/1с-ника
-- заниматься самообразованием

Например узнать что такое статистика, пересчет индексов:
http://www.gilev.ru/updatestat/

На данном сайте есть еще много статей, не все они свежие.




P.S.
Резервные копии средствами SQL хотя бы делаются?
"SQL" это же на вашем языке MS SQL server верно ?

(1) Ну я же просил ногами не бить ))

"Резервные копии средствами SQL" (на всякий случай уточню - средствами MS SQL server) - ежедневно, "SQL" в данном контексте "MS SQL server".

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

(0) https://its.1c.ru/db/metod8dev/content/5837/hdoc - для начала, если не поможет - нужно "погружаться"

(0) директор, может всё таки время на развитие бизнеса потратить?
а не на эту фигню?))

(0) ну вообще в ут 10 до сихпор  запрос по партиями не оптимален  там надо его править и тогда все ускоряется в разы

https://infostart.ru/1c/articles/191732/

(3)(5) От души! ))
По результатам отпишусь через недельку-две.

Да, и ещё момент. Очень может быть, что пальцем в небо, но.
Модель восстановления базы в скуле - простая или полная? Если полная, дифференциальные бэкапы выполяются? Если нет, и нет задачи восстановления базы на произвольный момент времени, переведите базу в простую модель восстановления и выполните шринк

Докладываю )) Очень сильно помог регламентный запуск обновления статистики на SQL сервере (каждые 4 часа), проблема решена. Всем большое спасибо!

(8) 4 часа как-то часто, лучше ночью если не круглосуточно работаете

(7) > "переведите базу в простую модель восстановления и выполните шринк"

Это может как-то перепроведение ускорить?

(10) Сталкивался с тормозами при достижении файлом журнала транзакций какого-то критического размера именно в такой ситуации - полная модель восстановления, и нет дифбэкапов. Переводим в простую, шринкуем - и всё шевелится куда как быстрее. Если склероз не изменяет, где-то попадалась информация, что скуль постоянно "шерстит" транзакции, "не сброшенные" в БД из журнала транзакций, что и приводит к такому эффекту. Возможно, что в этом и неправ - не настолько хорошо знаю скуль, но ускорение от предложенной процедуры видел сам