Сильные тормоза при разноске Заказа на продажу

[sukhanchik]

А можно подетальнее сообщить по плану запроса? Интересуют параметры, нарисованные в зеленых овалах. А в нижней строке - интересует где больше просаживается производительность - на объединении таблиц или на поиске.

[ena_ax]

Цитата:

Сообщение от sukhanchik

А можно подетальнее сообщить по плану запроса? Интересуют параметры, нарисованные в зеленых овалах. А в нижней строке - интересует где больше просаживается производительность - на объединении таблиц или на поиске.

Странно, по плану небольшие затраты и ожижаемое кол-во строк.

[sukhanchik]

Цитата:

Сообщение от ena_ax

Странно, по плану небольшие затраты и ожижаемое кол-во строк.

А на суммировании? (Stream Aggregate)

Может просто сейчас не тормозит запрос?

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

[ena_ax]

Цитата:

Сообщение от sukhanchik

А на суммировании? (Stream Aggregate)

Может просто сейчас не тормозит запрос?

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

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

Сводное планирование не используем. Пересчет склада запускаю только я.

[ena_ax]

При очередной зависании замедлении системы снял показания Tracer. План выполнения запроса показывает минимальные затраты на выполнение, при этом общее время ожидания велико.
В это время на SQL в Activity Monitor блокировка процесса 55 (см. рис.) - база tempdb


create table #tmpDBCCinputbuffer ([Event Type] nvarchar(512), [Parameters] int,
[Event Info] nvarchar(512))
insert into #tmpDBCCinputbuffer exec ('DBCC INPUTBUFFER(79)')
select [Event Info] from #tmpDBCCinputbuffer

Может в этом проблема?

Помимо реиндексации проблема решается перезапуском SQL.

[somebody]

Вообще-то DBCC INPUTBUFFER(79) всего лишь означает, что данный процесс снял информацию о последней команде процесса 79.
Блокировка Sch-M - это schema lock, в tempdb накладывается, например, при truncate временных таблиц, а вообще при изменении структуры таблицы.

Не в этом направлении надо копать.

Вы в момент подвисания запроса снимите его план в SQL Server Management Studio (естественно, в синтаксисе T-SQL), и выложите его сюда, а лучше - на sql.ru.

Одновременно в SQL Profiler'е мониторьте блокировки на участвующие в запросе таблицы Аксапты.
Если план нормальный, значит, дело в блокировках другим процессом, или внутренних блокировках.
Чтобы отбросить 1-й вариант: может, запускаются какие-то jobs SQL-сервера/пакеты Аксапты, конкурирующие?