Зависание клиента при выполнении запроса

[Deepoint]

Здравствуйте Уважаемые.
Прошу Вашей помощи, т.к. свои идеи кончились.

Два АОС-а, настроены идентично, данные так же одинаковы.
Ax 4.0, ядро - 4.0.2503.756, приложение - 4.0.2501.347
SQL 2005.
В качестве примера кода Job:

static void TestQuery(Args _args)
{
    Query                            q = new Query();
    QueryRun                      qr;
    QueryBuildDatasource    qbdsInventTrans;
    QueryBuildDatasource    qbdsSalesTable;   
    ;

    qbdsSalesTable          = q.addDataSource(tablenum(SalesTable));
    qbdsSalesTable.addRange(fieldnum(SalesTable, ShippingDateConfirmed)).value(strfmt("(ShippingDateConfirmed <= %1)", date2strxpp(16\07\2011)));

    qbdsInventTrans         = qbdsSalesTable.addDataSource(tablenum(InventTrans));
    qbdsInventTrans.addLink(fieldnum(SalesTable, SalesId), fieldnum(InventTrans, TransRefId));

    qbdsInventTrans.addRange(fieldnum(InventTrans, TransType)).value(SysQuery::value(InventTransType::Sales));
    qbdsInventTrans.addRange(fieldnum(InventTrans, StatusIssue)).value(SysQuery::range(StatusIssue::ReservPhysical, StatusIssue::OnOrder));

    qbdsInventTrans.joinMode(JoinMode::InnerJoin);
    qbdsInventTrans.fetchMode(QueryFetchMode::One2One);

    qr = new QueryRun(q);

    while(qr.next())
    {
	info("Do something...");
    }
}

Запрос срабатывает на одном АОС-е, на другом нет. Зависает на строке while(qr.next()). При этом клиент повисает, в шапке окна клиента пишет «Не отвечает».
Cессия остается в списке активных в аксапте. В SQL сессия находится в состоянии «Running». Ждал около часа результата. Безрезультатно. На другом АОС запрос выполняется сразу.
Глобальная перекомпиляция, переиндексация, очистка кэша не помогла.
Подскажите в каком направлении копать. Буду весьма признателен за любую помощь.

[NetBus]

Цитата:

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

    while(qr.next())
    {
	info("Do something...")
    }
}

точка с запятой пропущена после info

[Deepoint]

Да, прошу прощения, это я дописал уже здесь, вместо исполняемого кода ради экономии места. Сейчас исправлю.

[imir]

Данные идентичные, но базы разные? Смотрите план запроса, обновите статистику в SQL

[NetBus]

а AOS передернуть принудительно? и попробовать заново?

[Player1]

Посмотрите ваш квэри (q) через SysQueryViewer::.... как там сложится запрос?
Спрашиваю это еще и потому что лично мне как то непривычно связывать SalesTable и InventTrans, я бы вязал проводки со строками заказа SaleLine.

И еще одна вещь, зачем qbdsInventTrans.fetchMode(QueryFetchMode::One2One); ? это точно надо?

[Deepoint]

Статистику SQL обновил.
Планы запросов одинаковы. Причем, что странно, на том АОС-е что зависает трассировка срабатывает через раз. Когда сформируется запись когда нет.
Рестарт АОСов и перезагрузка сервера проводились.
Проблема осталась...

[Deepoint]

Код, к сожалению, не мой. Но суть вопроса - почему на одном АОСе работает на другом нет.
SysQueryViewer у меня нет, использую QueryBrowser. Зависает.

[Player1]

Используйте квэри- вивер или браузер или вообще info(qbds.tostring()) перед строкой qr = new QueryRun(q); а эту строку и while закоментируйте вообще.

PS: И всё таки конструкция запроса мне не нравится, я бы переписал с использованием SalesLine

[mazzy]

Цитата:

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

Запрос срабатывает на одном АОС-е, на другом нет. Зависает на строке while(qr.next()).

Вы уперлись в АОСы, а это ошибочный путь.

Цитата:

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

Данные идентичные, но базы разные?

ответьте на этот вопрос, пожалуйста.
базы разные?

если к каждой базе вручную задать аналогичные запросы в Management Studio, то время выполнения будет одинаковым?
если одинаковым, то ройте в настройки, указанные в конфигурационной утилите для АОСов
если разным (скорее всего), то ройте в сторону индексов. они скорее всего разные на разных базах. на одной из баз происходит полное сканирование вместо индексной выборки. поэтому и тормозит


дело в том, что qr.next() выполняет отправку текста запроса на SQL-сервер.
qr.next() ожидает ответа от SQL-сервера.
если висит в этом месте, то нет ответа от SQL-сервера.
АОС тут не при чем.

[Deepoint]

Да, базы разные. Восстанавливались из одного бэкапа.

[db]

Почему по разному? Ответ "потомучто". Вам уже советовали - смотрите планы запросов. Всё остальное гадание.

Вероятно на одном сервере план запроса получился "хороший", на другом "плохой".
Планы остаются в памяти для повторного использования. Можете выдать обоим серверам DBCC FREEPROCCACHE чтобы он забыли все сохраненные планы и начали с чистого листа.

Из области простых гаданий - в стандарте на InventTrans нет индекса по TransType и TransRefId который в вашем запросе был бы очень кстати. Есть ли что то похожее в вашем приложении никто из нас не знает

И опять же - смотрите планы и не гадайте - там всё написано и даже нарисовано. Чтобы оптмизаторы повели себя по разному даже в очень похожем окружении есть десятки причин.

[mazzy]

Цитата:

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

Да, базы разные. Восстанавливались из одного бэкапа.

попробуйте таки выполнить запросы напрямую из Management Studio к двум базам.
разница по времени есть? а в планах выполнения?

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

[imir]

Кстааати.. AOS-s разные - вы сравните kernel version обоих аосов, такое подозрение, что на втором не установлены SP и Ru просто

[Deepoint]

Проблему решили кардинально... Переустановкой ОС. Залил все то же самое - заработало. Понимаю, что из пушки по воробьям, но время дорого было. Всем спасибо за помощь.

[Deepoint]

Первым делом смотрел. Одинаковые.