Здраствуйте.
База Альфа авто ред.5, работает под платформой 8.2, на SQl 2012. Ситуация следующая: в одно прекрасное утро (несколько месяцев назад) стали долго заполнятся новые документы при  вводе на основании.Время ожидания может достигать 5-7минут. Обычно в течении максимум пары секунд-документ уже сформирован. Так как В Альфе Кусок ода закрыт от просмотра, диагностировать до конца отладчиком причину не получается. Выходом (что бы не перезагружать сервак SQl или 1с) является только запуск перестроения индекса и обновления статистики средствами SQL (Причем именно последовательно и вместе-в другом варианте не срабатывает). Поисходит обработка всех таблиц базы данных- а это довольно длительный процесс и в момент выполнения -база 1с подтормаживает. Хватает этого на разные отрезки времени от нескольких часов до нескольких суток.  Причем чем дальше-тем короче период возникновения сабжа (примерное наблюдение). Для ускорения работы этогомеханизма хочу отловить таблицу(-ы) которая наиболее нужны в обработке и написать задание в SQL именно обработки этих таблиц-должно быстрее обновляться . Кто знает, каким скриптом SQl можно получить таблицы -котрые наимболе нуждаются в обработке?

можно сделать запрос по недостающим индексам

https://gist.github.com/a-sitnikov/910f2a34e3a2c62fefb00bce5f0f5f56

(0) ты лучше посмотри, какие запросы на SQL сервере выполняются, когда ты проводишь докуменнт

А неэффективные индексы - это индексы, которые места занимают много, а используются мало раз.
Но они никак не скорость выполнения запросов не влияют. Разве что на запись

Вернее их называть избыточными, а не неэффетивными

(3) Проблема не в процессе проведения, а в процессе ввода на основании. Запросы я пытаюсь поймать -пока каша какая та...

замерь профайлером запросы более 1-2с

(6) Может в коде дело все-таки?А в поддержку не обращались?

Можно я тут спрошу быстренько? :)
В окне показателей производительности:
Вызовов 1 время 0.02 отправлено 200 получено 300
Сам вопрос:
отправлено НА сервер или ОТ сервера, получено сервером или клиентом?
Исходя из контекста что это серверные вызовы, то, думаю, что сервер получил 300 и вернул 200.
Или нет?

(0) "Выходом (что бы не перезагружать сервак SQl или 1с) является только запуск перестроения индекса и обновления статистики средствами SQL (Причем именно последовательно и вместе-в другом варианте не срабатывает)."
Поставьте выполнение сего в ночной джоб/задачу планировщика винды.

(10) Ночью набор регламентов выполняется -проблема может возникнуть через пару часов работы

Замер производительности делал? Видно какая процедура или строка кода больше всех кушает? ТИИ?

Есть несколько способов которые я использовал на практике для поиска "тяжелых" запросов:
1. Чтобы поймать в sql profiler'e длительные по времени запросы, необходимо создать трассировку с фильтром по показателю duration (в миллисекундах больше или равно), а события выбрать  RPC:Completed и SQL: BatchCompleted. Мне таким образом удалось поймать все длительные запросы к базе, и понять какие механизмы требуют оптимизации.
2. Также в Вашем случае вполне возможно что возникают блокировки таблиц, их можно поймать выполнив процедуру sp_locks на базе, в которой Вы работаете, в тот момент когда "подвисает создание докуменов на основании".Процедура Вам вернет заблокированные объекты БД. Через DBID с помощью функции DB_Name() Вы найдете наименование таблицы в БД, а через обработку "ПосмотрМетаданных.epf" вы найдете наименование таблицы в конфигурации 1С.

http://catalog.mista.ru/public/81694/

(12) Самый долгий вызов процедуры-уходит в защищенный модуль, и собственно посмотреть что там дальше происходит-почти не получается..

Подниму тему. Ситуацию поймал при зависании ввода на основании. Профайлером Sql снял информацию ,что происходит в этот момент. нашел самый длительный запрос-71сек. (фильтр по длительности более 2сек поставил, остальные запросы от 2 сек до 10 сек по времени и их очень много). Сам пока не очень разобрался в записях профайлера-может кто поможет из более опытных людей-что там  в этом самом длинном запросе тормозит?

http://ximage.ru/index.php?id=1496653218
http://ximage.ru/index.php?id=1496653311
http://ximage.ru/index.php?id=1496653334
http://ximage.ru/index.php?id=1496653355
http://ximage.ru/index.php?id=1496653373

(16) надо поискать обработку которая гуглится по "1с получить структуру хранения метаданных"

Таблицы 1с , участвующие в запросе , я нашел. Не пойму что дальше делать. Один и тот же запрос 1с отрабатывает по времени по разному до перестроения индексов и после. Как проанализировать на чем спотыкается и тормозит запрос?

хз, мб кто поправит
смотрим на запрос из 5 и видим (раз) два условия на НеРавно не по кластерному индексу и (два) соединение потом по не ссылочному типу. Из (раз) получаем два скана долгих по не кластеру и потом цикл по кластеру. Из (два) в довесок получаем тяжелую сортировку для соединения

тяжесть видно по ссылке 3 из (16)

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

CСпасибо за направление поиска. Пока мало понимания, сижу разбираюсь

https://habrahabr.ru/company/pgdayrussia/blog/329542/ про постгри, но классно написано

(22) Оперативный СрезПоследних там у вас, без Итогов.

Но могу ошибаться.

Добавьте галочку "итоги по срезу последних"

или избавьтесь от необходимости срезапоследних по методике Ненавижу1С

(22) Но лучше найти наименование регистра сведений с помощью обработки структуры таблиц 1С и глобальным поиском по конфе найти все запросы по срезам последних(первых, но вряд ли), проставить точки останова и дождаться воспроизведения.

И прислать текст запроса и структуру регистра сюда.

(24) там РС, не РН

(26) Я о РС и веду речь.

(27) пару страничек, позязя

(28) шта?

он должен доказать

не интересно, раз модуль закрыт

Сейчас опять попал на тормоза ввода на основании документа. Методом перебора попробовал отобрать таблицу из которой притормаживает. Начал с самого длинного запроса и сразу угадал. текст запроса:
Самыйдлинныйзапрос  71271мс РегистрСведений.РегистрацияВремениРабот

exec sp_executesql N'SELECT
T1.Q_001_F_000RRef,
T3.Q_002_F_001RRef,
T3.Q_002_F_002_
FROM (SELECT
T2._Fld7406RRef AS Q_001_F_000RRef,
MAX(T2._Period) AS Q_001_F_001_,
T2._Fld7411 AS Q_001_F_002_
FROM _InfoRg7405 T2 WITH(NOLOCK)                            
WHERE (T2._Fld7408RRef = P1) AND (T2._Fld7407RRef <> @P2)
GROUP BY T2._Fld7406RRef,
T2._Fld7411) T1
LEFT OUTER JOIN (SELECT
T4._Fld7406RRef AS Q_002_F_000RRef,
T4._Fld7407RRef AS Q_002_F_001RRef,
T4._Fld7411 AS Q_002_F_002_,
MAX(T4._Period) AS Q_002_F_003_
FROM _InfoRg7405 T4 WITH(NOLOCK)
WHERE (T4._Fld7408RRef = @P3) AND (T4._Fld7407RRef <> @P4)
GROUP BY T4._Fld7406RRef,
T4._Fld7407RRef,
T4._Fld7411) T3
ON (((T1.Q_001_F_000RRef = T3.Q_002_F_000RRef) AND (T1.Q_001_F_001_ = T3.Q_002_F_003_)) AND (T1.Q_001_F_002_ = T3.Q_002_F_002_))',N'P1 varbinary(16),@P2 varbinary(16),@P3 varbinary(16),@P4 varbinary(16)',0x00000000000000000000000000000000,0xA4A10D6407153BC548BAFB0D700F8CFA,0x00000000000000000000000000000000,0xA4A10D6407153BC548BAFB0D700F8CFA"

Поставил в SQL пересоздание индекса только по этой таблице,отработало быстро-сек 5 наверное. После этого документ стал вводится достаточно быстро. Приведенный запрос отработал за 258 мс-и он самый длительный из цепочки запросов. Поэтому пока поставлю в планы обслуживания SQL задание на перестроение индекса этой таблицы раз 3 часа -понимаю,что это костыль, но пока времени нет плотнее заниматься. Вызов это запроса формируется (как я понял) где то в закрытом модуле, я его расположение примерно увидел,но переделывать пока не придумал как.