Почему join запрос разбивается на подзапросы!?

[3oppo]

Цитата:

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

Что вы людям голову морочите?
У этого запроса даже синтаксис неправильный.

Прошу прощения, код был удалён восстанавливал по памяти. Память подвела . Не думал что кто то будет проверять, думал так показать общий смысл…
Вот корректный код запроса:

    queryText   =
    strfmt(
      "SELECT * "
    + " FROM       RASSETTABLE A INNER JOIN"
    + "  RASSETTRANS B ON A.ACCOUNTNUM = B.ACCOUNTNUM INNER JOIN"
    + "  LEDGERTRANS C ON B.VGP_LEDGERLINKID = C.VGP_LEDGERLINKID AND B.VOUCHER = C.VOUCHER AND"
    + "  B.TRANSDATE = C.TRANSDATE"
    + " WHERE     (A.DATAAREAID = '%5') AND (A.VGP_PROPERTYTAX = %4) AND (B.DATAAREAID = '%5') AND (B.ASSETTRANSTYPE = %2) AND"
    + " (B.TRANSDATE <= CONVERT(DATETIME,'%1', 102)) AND (C.DATAAREAID = 'vgp') AND (C.VGP_LEDGERLINKMODULEREF = %3)"
    + " ORDER BY A.DATAAREAID, A.ACCOUNTNUM, B.DATAAREAID, B.ACCOUNTNUM, B.ASSETTRANSTYPE, C.DATAAREAID, C.VGP_LEDGERLINKID,"
    + " C.VGP_LEDGERLINKMODULEREF" + " OPTION (FAST 4)"
    , date2str( reportDateEnd,321,2,4,2,4,4), ip2, ip3, ip4, CurExt()   );

[3oppo]

Деадлоки проверял (при наличии юзеров) отсутствуют.
В какую сторону рыть?!

[3oppo]

Такое впечатление, что запросы стоят в некой очереди, а прямой заброс пролазит вне очереди. Только что с админом сидел рассматривали счётчики и блокировки вроде всё в норме… .. . Похоже что эта очередь создаётся Аксаптой. Она же под одним пользователем ходит в базу, хотя причём тут это… .. .
Проверил влияние прямого запроса на блокировки. Как посоветовал Mazzy. Отрабатывает сразу 5 секундный пик, но заним идёт 10 секундная полная блокировка!!! Попробую нарисовать:

.      __
__/\/    \_

То есть общее время блокирование t * 3. Да это не есть гуд.

[mazzy]

Цитата:

Сообщение от 3oppo

Такое впечатление, что запросы стоят в некой очереди, а прямой заброс пролазит вне очереди.

Аксапта не занимается очередями.

Поскольку вы говорите о "SQL Enterprise Manager" и не знаете "Management Studio", рискну предположить, что у вас SQL 2000.

Раз у вас SQL 2000, то у вас есть блокировки на чтение.

Пилите дальше. Какая блокировка выполняется при выполнении Аксаптовского запроса, а какая при выполнении прямого? Если вы сейчас скажете "никакая", то не соглашусь и попрошу сказать уровень изоляции для выполняемого запроса.

[3oppo]

Да Аксапта на SQL 2000, хотя 2005 недавно купили но Аксапту на него не перевели?! А что есть смысл?!
Вопрос в следующем, ну найду я что за блокировка лезет, а что дальше то?!

[kashperuk]

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

То есть, из этого должно было стать понятно, что запрос нормально отрабатывает и все дело в картинках.

Что Вы дальше тут еще пытаетесь оптимизировать??

[3oppo]

В каких картинках?! Про картинке, это так кто то ляпнул шутя. Там нет никаких картинок и записи мне нужны все!
Взвесив все за и против склоняюсь к использованию прямого запроса.

[kashperuk]

Цитата:

Сообщение от 3oppo

В каких картинках?! Про картинке, это так кто то ляпнул шутя. Там нет никаких картинок и записи мне нужны все!
Взвесив все за и против склоняюсь к использованию прямого запроса.

Я про вот этот пост.
Почему join запрос разбивается на подзапросы!?
Все поля врядли нужны всегда. имхо

[belugin]

А вы пробовали запрос через Connection а не через ODBCConnection?

[3oppo]

Дело в том что код объемный и не мой, досконально его изучать нету желания. Я не знаю на 100% какую инфу потом будут дёргать из этой выборки. Не включишь поле, а оно используется, и с этим такой геморрой можно будет выхватить… .. . Ошибки ведь не будет просто нету данных и всё! И не понятно когда она вылезет.
Нет с Connection я не пробовал, а зачем?! Что мне это даст!?

[belugin]

Цитата:

Сообщение от 3oppo

Нет с Connection я не пробовал, а зачем?! Что мне это даст!?

По крайней мере, можно уточнить, не кроится ли разница в настройках соединения

[AndyD]

Хм.
Но вы же привели код метода и указали, что он полный. А в этом коде используются только _rassetTable.AccountNum и _ledgerTrans.AccountNum.
Или опять о чем-то умолчали?

PS Кстати, был неправ насчет exists join запроса. В данном случае он не подойдет

[Wamr]

Зорро.

Сам по себе очень интересный основной запрос, который выгребает все проводки от начала времен до какой-то даты, а потом по ним в цикле строится какой-то мап. Просто интересно, сколько он уже эксплуатируется и как за это время подросла базулька? И как Вы думаете, когда этот цикл будет исполняться не 4800 раз, а 10 тыс или 100тыс поможет оптимизация основного запроса?

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

Посмотрите, наконец, планы исполнения запроса в рабочем режиме и из QA, так как только план запроса скажет Вам ПОЧЕМУ различается время исполнения из QA и из аксапты (но не скажет почему различаются планы )

Вы привели точный текст запроса из профайлера или подсократили упоминание индексов в нем?

[3oppo]

Цитата:

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

Хм.
Но вы же привели код метода и указали, что он полный. А в этом коде используются только _rassetTable.AccountNum и _ledgerTrans.AccountNum.
Или опять о чем-то умолчали?

Да умолчал о том что, в данном отчёте подобная выборка используется не только в этом методе, но ещё и несколько раз по коду, с незначительными изменениями! Данные не запоминаются не в каких временных таблицах, а просто это выборка повторяется опять и опять с другими целями.

Цитата:

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

Сам по себе очень интересный основной запрос, который выгребает все проводки от начала времен до какой-то даты, а потом по ним в цикле строится какой-то мап. Просто интересно, сколько он уже эксплуатируется и как за это время подросла базулька? И как Вы думаете, когда этот цикл будет исполняться не 4800 раз, а 10 тыс или 100тыс поможет оптимизация основного запроса?

Вот то-то и оно. Эксплуатируется 3 года, после «успешного внедрения» внедренцы получили свои денежки и свалили, а сей час пользователи стали жаловаться, что очень медленно отчеты формируется, да ещё и неправильно. Полез разбираться, и наткнулся на эту «корягу».

Цитата:

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

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

Не подходит.

Цитата:

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

Посмотрите, наконец, планы исполнения запроса в рабочем режиме и из QA, так как только план запроса скажет Вам ПОЧЕМУ различается время исполнения из QA и из аксапты (но не скажет почему различаются планы )

Что то пользу от плана я не совсем понял. Ну видно какие индексы использует и чё?!

Цитата:

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

Вы привели точный текст запроса из профайлера или подсократили упоминание индексов в нем?

Абсолютно точный код, скопировал весь метод полностью. Удаление индексов из запроса всё таки даёт некоторый выигрыш но не очень значительный.

[3oppo]

План запроса

Прямой




Стандартный

[Wamr]

Зорро.
Я спрашивал про SQL из поста. Смущает, что в нем нет упоминание индексов, хотя в приведенном аксаптовском коде они есть.
Может быть покажите (сами посмотрите) реальные планы из MS-профайлера?

[glibs]

Wamr, вы ничего не путаете? Просто по моим наблюдениям Аксаптовский index работает как ORDER BY, а индекс хинты в запрос, который уходит на SQL, вставляет только index hint. Правда, экспериментировал на эту тему я, по-моему, на 3.0 сп5 кр3 после того, как началось обсуждение подлого поведения ядра Аксапты, когда оно на свое усмотрение начало подставлять индекс хинты в запрос. Может это от версии ядра зависит...

Хотя нет. В мануале написано, что так и должно быть.

[glibs]

Дочитал мануал до конца. Кажись, я погорячился. Там все-таки неоднозначно написано. Прошу прощения.

[3oppo]

Устал гадать, да и времени нету больше. Буду юзать прямой запрос!
ВСЕМ СПАСИБО, за желание разобраться и помочь.

[mazzy]

и в самом деле, "чего думать? трясти надо!"