Тормоза при получении очередной строки из ResultSet

[Alenka]

Добрый день! Столкнулась с проблемой: при получении результата SQL-запроса через ResultSet (через подключение UserConnection) получение очередной строки данных (ResultSet.next()) занимает время, сопоставимое с выполнением всего запроса. В SQL Server Managment Studio запрос выполняется меньше секунды. Получении данных в Аксапте - около 900 строк - 20 (!) минут.
Причем данная ситуация возникает не для всех запросов. Данные другого запроса, имеющего сходную структуру, получаются мгновенно.
Если кто-нибудь сталкивался с данной ситуацией, поделитесь своим опытом или соображениями. Спасибо.
Ax3.0 sp3

[greench]

А под чем у вас база крутится?

[Alenka]

SQL Server

[greench]

Если вам не тяжело, выложите пожалуйста сюда 2-а запроса - тот который тормозит и тот, который нормально работает.

[Alenka]

оба запроса используют некоторые таблицы, которых нет на sys слое. Но могу выложить их sql-текст.
Первый запрос, получение очередной строки из которого происходит мгновенно:

 select itm.itemId
from inventTableModule itm(nolock)
join 
(select availPhysical = sum(availPhysical), itemId
from InventSum (nolock)
where availPhysical > 0
and closed = 0
and dataareaId = 'dat'
group by itemId
)as t on t.itemId = itm.itemId
join inventTable it (nolock) on it.ItemId = itm.itemId
where itm.Blocked = 1
and itm.ModuleType = 2
and itm.dataareaId = 'dat'
and it.dataareaId = 'dat'
and it.itemType = 0 
and it.itemRangeIdRef not in
( select RangeIdRef
from inventItemRangeRef ref (nolock)
where ref.RangeIdRefParent in (229837,228003,228265,225907) 
and ref.dataareaId = 'dat')

Второй зпрос, получение очередной строки которого происходит долго:

 select itm.itemId
from inventTable it (nolock)
join inventTableModule itm(nolock) on itm.ItemId = it.ItemId and moduleType = 1
where itm.Blocked = 0
and itm.dataareaId = 'dat'
and it.dataareaid = 'dat'
and it.itemType = 0
and it.itemRangeIdRef not in
( select RangeIdRef
from inventItemRangeRef ref (nolock)
where ref.RangeIdRefParent in (229837,228003,228265,225907) 
and ref.dataareaId = 'dat')
and it.ItemId not in
(select distinct itemId 
from vendContractItem (nolock)
where dataareaId = 'dat')

[ZVV]

Retail?

А если сделть подобный запрос не через UserConnection, а из основного соединения то такого же не будет, да? Нет возможности избавиться от него (от UserConnection-а)?

[Alenka]

Для Connection та же ситуация

[ZVV]

Цитата:

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

Для Connection та же ситуация

Тогда включите в Аксапте SQL-Trace и посмотрите план запроса, который на нём получается в Аксапте...
Сравните его с планом, который получается при выполнении напрямую (из Managment Studio) - есть отличия?

[Alenka]

Нет, отличий в планах исполнения нет.
Такое ощущение, что каждый раз при ResultSet.next() запрос выполняется заново (судя по времени выполнения)

[ZVV]

Цитата:

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

Такое ощущение, что каждый раз при ResultSet.next() запрос выполняется заново (судя по времени выполнения)

Поставьте в конфигурационной утилите в Advanced -INTERNAL=NOCURSORREUSE (в двухзвенке, или в толстом клиенте) и прогоните ещё раз.
Если запрос выполняется заново, то с SQL-Trace вы увидите все запросы (~900 раз)...
Если же он останется один - значит долго идёт именно fetch данных...

Чем в этом случае помочь, даже не знаю... попробуйте пошаманить, переписать запрос, разбить на 2 и т.п... Что-то должно помочь.

[greench]

А не задваивает он данные?

[greench]

+1 к пересмотреть запрос. Попробуйте пойти от простого к сложному и посмотрите после джойна какой таблицы начинаются тормоза.

[Alenka]

Цитата:

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

А не задваивает он данные?

Нет, не задваивает.

Цитата:

Если же он останется один - значит долго идёт именно fetch данных...

Вот у меня подозрения на долгий fetch. Как с этим можно бороться?

Цитата:

Попробуйте пойти от простого к сложному и посмотрите после джойна какой таблицы начинаются тормоза.

Можно попробовать,только как это отразится на времени выполнения всей операции. Если что-то выкидывать из запроса, то нужно это будет проверять в Аксапте...

[ZVV]

Цитата:

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

Вот у меня подозрения на долгий fetch. Как с этим можно бороться?

Ну проверьте таки на всякий случай, чтоб окончательно убедиться...
Как бороться - смотри выше...

Цитата:

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

Можно попробовать,только как это отразится на времени выполнения всей операции. Если что-то выкидывать из запроса, то нужно это будет проверять в Аксапте...

Конечно, проверять надо будет в Аксапте... В Студии у вас же всё и так всё хорошо работает...
Не обязательно что-то выкидывать - можно попробовать поменять местами для начала, или наоборот что-то добавить. Если не поможет - разбейте на 2 запроса, например. Пробуйте, пока не достигните приемлимого результата по скорости.

[Alenka]

Танцы с бубном вокруг запроса помогли! Tормозов при ResultSet.next() больше не стало. Правда запрос подурнел и ему определенно поплохело (в Студии стал выполняться дольше), но в общем - то же кол-во строк Аксапта стала получать за несколько секунд, вместо 20(!) минут.
Запрос стал выглядеть так:

 select it.itemId
from inventTable it (nolock)
join inventTableModule itm(nolock) on itm.ItemId = it.ItemId and moduleType = 1
join
( select it.ItemId
from inventTable it (nolock)
left join
( select distinct itemId 
from vendContractItem (nolock)
where dataareaId = 'dat'
) as v on v.ItemId = it.ITEMID
where v.ItemId is null 
) as vend on vend.ItemId = it.ItemId
where itm.Blocked = 0
and itm.dataareaId = 'dat'
and it.dataareaid = 'dat'
and it.itemType = 0
and it.itemRangeIdRef not in
( select RangeIdRef
from inventItemRangeRef ref (nolock)
where ref.RangeIdRefParent in (229837,228003,228265,225907) 
and ref.dataareaId = 'dat')

Всем спасибо за помощь.