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

3oppo · 22.06.2007, 07:41

Axapta 3.0 SP 3

Имеем запрос:

Код:

    while select _rassetTable
        index RAssetNumIdx
        where _rassetTable.VGP_PropertyTax          == NoYes::Yes
    join firstonly _rassetTrans
        index TransTypeIdx
        where _rassetTrans.AccountNum               == _rassetTable.AccountNum          &&
              _rassetTrans.AssetTransType           == RAssetTransType::Acquisition     &&
              _rassetTrans.TransDate                <= reportDateEnd
    join firstonly _ledgerTrans
        index VGP_LedgerLinkIdx
        where _ledgerTrans.VGP_LedgerLinkId         == _rassetTrans.VGP_LedgerLinkId    &&
              _ledgerTrans.VGP_LedgerLinkModuleRef  == VGP_LedgerLinkModuleRef::RAsset  &&
              _ledgerTrans.Voucher                  == _rassetTrans.Voucher             &&
              _ledgerTrans.TransDate                == _rassetTrans.TransDate
{
	…….
	//Не значительный код, заполняется мап
}

При просмотре системным монитором видим:
Кол-во Select 4837 !!!!!?!?!? Почему?! Запрос отрабатывает порядка 25 минут

Написал такой же запрос в SQL Enterprise Manager отработал за 5 секунд!!
Прямой запрос, вставлять в код не очень хочется … .. . Подскажите в чём дело и что можно сделать?!

kashperuk · 22.06.2007, 09:25

Хм. А пробовали убрать firstonly?
Вполне возможно, что для каждой записи rAssetTable делается поиск записи соответствия свой вместо простого объединения таблиц.
(как будто бы join вообще не было, а в теле while Вы отдельно искали требуемые записи)

Хотя, это всего лишь предположение - возможно кто-то поправит.

AndyD · 22.06.2007, 09:29

Интересно, а какой, по вашему, запрос должен сформироваться?

glibs · 22.06.2007, 09:40

Уровень кэширования на таблице RAssetTable у вас стандартный? Это не экземпляр временной таблицы? Запросы всегда разбиваются, если в них включена таблица с уровнем кэширования EntireTable или временная таблица.

3oppo · 22.06.2007, 11:02

Да пробовал убирать firstonly без результатно!

X++:

    while select RPayJournalTable
        where RPayJournalTable.JournalId == 'ЗП000628'
    join RPayJournalTrans
        where RPayJournalTrans.JournalId ==  RPayJournalTable.JournalId
    join RPayTrans
        where RPayTrans.SourceRecId     == RPayJournalTrans.RecId
    {
         i++;
    }
    box::info( int2str(i) );

Вот этот код выполняется за 2 select-a

to AndyD ну уж никак не из 4000 селектов!
RAssetTable стандартно не каких временных таблиц!

MPAKObec · 22.06.2007, 18:04

Насколько я понял firstonly в join-ах вообще игнорируются. У меня тоже как то получалось что join разбивал select но я так и не разобрался в чём там дело. Просто используй «прямой запрос» к базе, сам так делал. Выигрыш в скорости в РАЗЫ!!

**mazzy** · 22.06.2007, 21:58

Цитата:

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

Просто используй «прямой запрос» к базе, сам так делал. Выигрыш в скорости в РАЗЫ!!

Прямой запрос означает полный отказ от поддерки ядра
Прямой запрос в разы сложнее отлаживать и в разы дороже в сопровождении.
Прежде чем следовать совету МРАКОбеса триджы подумайте.

3oppo · 25.06.2007, 08:38

Цитата:

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

Прямой запрос означает полный отказ от поддерки ядра

Не совсем понял о чём речь?

Цитата:

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

Прямой запрос в разы сложнее отлаживать и в разы дороже в сопровождении.
Прежде чем следовать совету МРАКОбеса триджы подумайте.

Согласен! А что делать?! Если разница в скорости в 50 раз!!!

**mazzy** · 25.06.2007, 09:06

Цитата:

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

Не совсем понял о чём речь?

Нисколько не сомневаюсь, что не поняли.
Но тем не менее категорично советуете.

для начала назову пару вещей: виртуальные компани, rls.
про autorelation, временные таблицы, вычисляемые поля, про енумы, про целостность, про переопределенные методы при чтении/вставке/записи/удалении и т.п. уж как-нибудь сами.
в общем, rtfm.

Цитата:

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

Согласен! А что делать?! Если разница в скорости в 50 раз!!!

Во-первых, грамотно использовать втроенные средства.
Во-вторых, прекратите мерить разницу в монопольном режиме. Хоть раз померяйте при нормальной загрузке sql-сервера с нормальным числом пользователей. Замерьте наконец задержки, которые происходят у других пользователей из-за ваших прямых запросов. Барабашки нет.

**George Nordic** · 25.06.2007, 09:34

Цитата:

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

для начала назову пару вещей: виртуальные компани, rls.
про autorelation, временные таблицы, вычисляемые поля, про енумы, про целостность, про переопределенные методы при чтении/вставке/записи/удалении и т.п.

Забыл про самое страшное - про блокировки.

Как только вижу в коде прямое обращние к базе, это с 99% вероятностью означает, что барабашка скоро появится.

С Уважением,
Георгий

3oppo · 25.06.2007, 09:45

Цитата:

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

Нисколько не сомневаюсь, что не поняли.

?????

Цитата:

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

для начала назову пару вещей: виртуальные компани, rls.
про autorelation, временные таблицы, вычисляемые поля, про енумы, про целостность, про переопределенные методы при чтении/вставке/записи/удалении и т.п. уж как-нибудь сами.
в общем, rtfm.

А вы в этом смысле. Ну да есть некоторые неудобства. Но почти всё обходится дополнительным программированием.

Цитата:

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

Во-первых, грамотно использовать втроенные средства.

Научите плиз!? Вдруг чего не знаю.

Цитата:

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

Во-вторых, прекратите мерить разницу в монопольном режиме. Хоть раз померяйте при нормальной загрузке sql-сервера с нормальным числом пользователей.

Все замеры только на рабочей базе!

Цитата:

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

Замерьте наконец задержки, которые происходят у других пользователей из-за ваших прямых запросов.

Если это даже все 30 сек. (думаю что ЗНАЧИТЕЛЬНО меньше) это не критично для отчёта запускаемого 2 раза в месяц.

Цитата:

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

Барабашки нет.

Судя по оставшемуся главному вопросу, он всё таки есть!

MPAKObec · 22.06.2007, 18:09

А вы. Не пробовали использовать стандартные Query?! Он вроде как быстрее должен работать!

glibs · 22.06.2007, 18:36

Попробовал написать джоб похожий (на стандартной функциональности только). Select один при декларировании курсора. Дольше идут вызовы управления курсором.

Либо вы чего-то не договариваете...

А какой вид у вас имеют все 4837 запроса? Они абсолютно одинаковы? Может у вас сам метод столько раз вызывается? Тогда не удивлюсь насчет 25 мин.

3oppo · 25.06.2007, 08:32

Цитата:

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

Попробовал написать джоб похожий (на стандартной функциональности только). Select один при декларировании курсора. Дольше идут вызовы управления курсором.

Либо вы чего-то не договариваете...
.

Вот метод полностью:

X++:

protected Map initRasset01Map()
{
    Map             _ret          = new Map(Types::String, Types::Date);
    Set             _account01Set = this.initAccount01Set();
    RAssetTable     _rassetTable;
    RAssetTrans     _rassetTrans;
    LedgerTrans     _ledgerTrans;
    int             i, ip4, ip2, ip3;

    while select _rassetTable
       index RAssetNumIdx
        where _rassetTable.VGP_PropertyTax          == NoYes::Yes
    join firstonly _rassetTrans
        index TransTypeIdx
        where _rassetTrans.AccountNum               == _rassetTable.AccountNum          &&
              _rassetTrans.AssetTransType           == RAssetTransType::Acquisition     &&   
              _rassetTrans.TransDate                <= reportDateEnd
    join firstonly _ledgerTrans
        index VGP_LedgerLinkIdx
        where _ledgerTrans.VGP_LedgerLinkId         == _rassetTrans.VGP_LedgerLinkId    &&
              _ledgerTrans.VGP_LedgerLinkModuleRef  == VGP_LedgerLinkModuleRef::RAsset  &&   //ОС
              _ledgerTrans.Voucher                  == _rassetTrans.Voucher             &&
              _ledgerTrans.TransDate                == _rassetTrans.TransDate

    {
        i++;
        if (_account01Set.in(_ledgerTrans.AccountNum))
        {
            _ret.insert(_rassetTable.AccountNum, this.getDisposalDate(_rassetTable.AccountNum));
        }
    }

//    box::info( int2str(i) );

    return _ret;
}

Ставлю точку останова в начале метода и в конце, и между 2ми этими точками включаю монитор.
Переписал на прямой запрос в той же функции, выполняется вместо 26 минут - 30 секунд.

Цитата:

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

А какой вид у вас имеют все 4837 запроса? Они абсолютно одинаковы?

Посмотрел генерируемые запросы, вроде одинаковые вот такого вида:

SELECT A.TRANSDATE,A.RECID,A.VGP_LEDGERLINKID FROM RASSETTRANS A(INDEX(I_16077RASSETDATEIDX)) WHERE ((DATAAREAID=?) AND (((ACCOUNTNUM=?) AND (TRANSDATE<?)) AND ((((ASSETTRANSTYPE=?) OR (ASSETTRANSTYPE=?)) OR (ASSETTRANSTYPE=?)) OR (ASSETTRANSTYPE=?)))) OPTION(FAST 2)

внутри проскакивают 2-3 другого вида но непонятно к чему они относятся.

Цитата:

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

Может у вас сам метод столько раз вызывается? Тогда не удивлюсь насчет 25 мин.

AndyD · 25.06.2007, 09:25

Цитата:

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

Вот метод полностью:
...
Посмотрел генерируемые запросы, вроде одинаковые вот такого вида:

SELECT A.TRANSDATE,A.RECID,A.VGP_LEDGERLINKID FROM RASSETTRANS A(INDEX(I_16077RASSETDATEIDX)) WHERE ((DATAAREAID=?) AND (((ACCOUNTNUM=?) AND (TRANSDATE<?)) AND ((((ASSETTRANSTYPE=?) OR (ASSETTRANSTYPE=?)) OR (ASSETTRANSTYPE=?)) OR (ASSETTRANSTYPE=?)))) OPTION(FAST 2)

внутри проскакивают 2-3 другого вида но непонятно к чему они относятся.

По-моему, этот запрос не имеет отношнения к приведенному в коде (возможно, формируется в методе getDisposalDate()?).
Здесь идет связка по OR для нескольких условий для ASSETTRANSTYPE, а в коде x++ - по одному.

Попробуйте оставить только выборку и цикл по ней и посмотрите на результат запроса.

3oppo · 25.06.2007, 09:53

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

glibs · 25.06.2007, 13:51

Цитата:

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

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

А на количестве запросов?

Включите мониторинг длинных запросов. Посмотрите, действительно ли этот злополучный запрос так долго отрабатывает именно в Аксапте.

Запустите профайлер кода, в конце концов. Убедитесь, что время уходит именно на запрос.

3oppo · 25.06.2007, 14:30

Цитата:

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

А на количестве запросов?

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

Цитата:

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

Запустите профайлер кода, в конце концов. Убедитесь, что время уходит именно на запрос.

Запускал время уходит на весь цикл.

Что есть время выполнения запроса?! Это время до выхода из полного цикла, или это время до попадания внутрь цикла?

Обратил внимание на такую вещь:
При АКСАПТАВСКОМ запросе, попадание внутрь цикла происходит быстро ( 5 сек), НО само прохождение по циклу идёт очень медленно, хотя внутри выполняется только i++;
При прямом запросе, и попадение внутрь цикла и сам цикл (с кодом i++) делаются очень быстро.
Может это как то, кому то, прояснит ситуацию!?

belugin · 25.06.2007, 10:06

Еще можно включить трассировку SQL и походить по шагам внимательно глядя в список infolog дебаггера. И посмотреть какая строка генерирует приведенный SQL.

Еще можно трассировать SQL в файл и посмотреть по стеку какая строчка его генерит.

**Vadik** · 25.06.2007, 10:14

не проверял с клиентом SP3, но все же
- какой глубокий смысл заложен в

X++:

join firstonly RAssetTrans

и

X++:

join firstonly LedgerTrans

? Как, по-Вашему, их должен реализовать сервер БД?
- с какой целью используются

X++:

index RAssetNumIdx
index TransTypeIdx
index VGP_LedgerLinkIdx

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Не отрабатывает запрос EXISTS JOIN	Paul_ST	DAX: База знаний и проекты	8	21.03.2008 17:21
запрос с 4 таблицами. Загадка с Join	Андрей К.	DAX: Программирование	7	19.09.2007 17:12
Почему на форме "Пользовательские настройки", когда я перехожу в нее из формы, отсутствует закладка "Запрос"?	Hans	DAX: Администрирование	0	05.07.2007 13:52
2 join-а + CasheLookup = EntireTable	vallys	DAX: Программирование	1	10.03.2006 13:20
можно ли сделать с помощью join следующий запрос:	SergAY	DAX: Программирование	1	29.07.2003 11:39

Опции темы	Поиск в этой теме
Версия для печати Отправить по электронной почте	Поиск в этой теме: Расширенный поиск
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид