Есть тестовая база на MS SQL. Работает единственный пользователь, фоновые задачи отключены.
Есть внешняя обработка. При первом выполнении команды расчета производится считывание набора записей непериодического независимого регистра сведений - набор неких показателей. Часть показателей зависят от других. Делаем расчет всех показателей, и производится обратная запись в регистр. На все уходит порядка минуты, полторы.
При повторном выполнении этой же самой команды (такие же параметры расчета) происходит зависание выполнения запроса примерно на час!!!
После этого все повторяется - первый расчет проходит нормально, последующий зависает.
Пытаюсь профайлером определить суть проблемы, но нормально им пользоваться пока не умею и соответственно ни чего не вижу :(
Куда рыть?

Ого, привет Тамбов!

зависает на чем хоть ? На расчете показателей или при записи набора движения в регистр ?

Строго на запросе. Пакетный запрос.

Последующий расчет и запись набора проходит без проблем. И результат правильный. Только долгий :)

(0)Как настроено выделение памяти для SQL и сколько собственно ее выделено?

может потому что при 2м расчете идет ПЕРЕзапись набора?

(0) Вот тут посмотри куда рыть https://youtu.be/cSTYlitD8GM

(5)Может не совсем понял суть вопроса. На виртуальном сервере (тестовый) до 10Г, на реальном до 40Г оперативки. Монитор ресурсов говорит что память есть.
(6)Может, только моих знаний по блокировкам не хватает что бы объяснить происходящее.

настрой профайлер на долгие запросы

возможно при записи набора данных
у скл сервер что-то слетает типа статистики.
и он не может строить эффективный план запроса.

помогало разовое чтение таблицы в пределах измененных данных + обычно читаемых  (было достаточно быстро).

т.е. после записи прочитайте их из бд.

(8)Имелось ввиду на самом SQL server какие настройки по использованию памяти. Может там какое-то ограничение стоит

Судя по всему тупит оптимизатор запросов. План запросов принципиально разный. И в обоих случаях не оптимальный. Причем при повторном вызове не оптимальный фатально.
И еще - при вызове этого запроса из консоли первый план запроса равен тому что получается из обработки при первом проходе, а при последующих вызовах, получается вообще третий план запроса - самый быстрый (хотя тоже не оптимальный).
Почему так происходит - не понял. То что сильно поверхностно читал статьи по оптимизации - понял. Пошел переписывать запрос и искать вменяемую статью по борьбе со всякими Nested Loops и Index Scan и прочее...

кстати в там в регистре расчетов не хватает кластерного индекса на какой то таблице