Конечно блокировки. Непонятная ситуация.

[sergeypp]

Периодически зависает какая нибудь сессия. Блокировка обычно идет на INVENTDIM (бывают и другие, но эта таблица - 90 %). При этом очереди диска нет.. Через профайл видно что очень долго выполняется команда sp_cursorfetch. Duration в среднем 50000. В чем может быть дело? Где еще копнуть?

[sergeypp]

Уж очень долго выполняются эти операции. Вкрадывается сомнение, что здесь проблема не в очереди диска а в чем то другом.
Не могут ли как то влиять на это включенные опции
Literals in join queries from forms and reports
Literals in complex joins from X++

Еще одна особенность..
вот пример оператора.
exec sp_cursorfetch 180156358, 2, 1, 22
посмотрел описание оператора

sp_cursorfetch [@cursor =] cursor_handle
[, [@fetchtype =] fetchtype]
[, [@rownum =] rownum OUTPUT]
[, [@nrows =] nrows OUTPUT]

[@nrows =] nrows OUTPUT
Is the number of rows to fetch. nrows is int, with a default of NULL (fetch all rows).

Так вот к чему я.. Зависание происходит ТОЛЬКО на запросах у которых @nrows = 22..
Что это означает? Как Axapta генерит эти запросы.. И с чем это связано.. Заранее спасибо за любую инфу.. Уже замучался..

[Vadik]

Цитата:

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

Периодически зависает какая нибудь сессия. Блокировка обычно идет на INVENTDIM (бывают и другие, но эта таблица - 90 %). При этом очереди диска нет.. Через профайл видно что очень долго выполняется команда sp_cursorfetch. Duration в среднем 50000. В чем может быть дело? Где еще копнуть?

Блокировки на InventDim ? Скорее всего, к разработчикам - на стандартном приложении таких эффектов не припоминаю

Цитата:

Уж очень долго выполняются эти операции. Вкрадывается сомнение, что здесь проблема не в очереди диска а в чем то другом.
Не могут ли как то влиять на это включенные опции
Literals in join queries from forms and reports
Literals in complex joins from X++

Могут. Так же, как и сотни других параметров. Универсального рецепта нет. Впрочем, таблетки от всех болезней тоже пока не изобретены

Цитата:

Так вот к чему я.. Зависание происходит ТОЛЬКО на запросах у которых @nrows = 22..
Что это означает? Как Axapta генерит эти запросы.. И с чем это связано.. Заранее спасибо за любую инфу.. Уже замучался..

http://axapta.mazzy.ru/lib/indexhints/
http://www.axforum.info/forums/showthread....=&threadid=5806

[sergeypp]

Нашел место.. там следующий запрос
select forupdate inventTransReceipt
where inventTransReceipt.inventTransId == movement.transId() &&
inventTransReceipt.statusIssue == StatusIssue::None &&
inventTransReceipt.statusReceipt == StatusReceipt::Ordered &&
inventTransReceipt.transChildType == InventTransChildType::None
#inventDimJoin(inventTransReceipt.inventDimId,inventDimReceipt,inventDimReceiptO
rig,inventDimParm);

что нужно добавить, что бы обработались все строки удовлетворяющие параметрам, но курсор (sp_cursorfetch) брал только по 1 - 2 строки.. firstfast??

[sergeypp]

И такой еще вопрос где можно взять документ Databases Advanced от 3.0 окромя партнерского сайта??

[Vadik]

Цитата:

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

Нашел место.. там следующий запрос
select forupdate inventTransReceipt
where inventTransReceipt.inventTransId == movement.transId() &&
inventTransReceipt.statusIssue == StatusIssue::None &&
inventTransReceipt.statusReceipt == StatusReceipt::Ordered &&
inventTransReceipt.transChildType == InventTransChildType::None
#inventDimJoin(inventTransReceipt.inventDimId,inventDimReceipt,inventDimReceiptO
rig,inventDimParm);

что нужно добавить, что бы обработались все строки удовлетворяющие параметрам, но курсор (sp_cursorfetch) брал только по 1 - 2 строки.. firstfast??

попробуйте заменить

select forupdate inventTransReceipt

на

select forupdate forceselectorder inventTransReceipt

Цитата:

И такой еще вопрос где можно взять документ Databases Advanced от 3.0 окромя партнерского сайта??

у партнера