Axapta + Oracle + FIRST_ROWS = проблемы

[Wamr]

Есть Акспта 3.0SP3 + Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
Для тестирования взял 2 запросика из 1 формы, с фильтром и без

static void Job127(Args _args)
{
    UserConnection  con = new UserConnection();
    Statement       stat = con.createStatement();
    CustInvoice4PaymJour_RU         paymJour;
    CustInvoice4PaymSalesLink_RU    salesLink;
    ;

    //stat.executeUpdate("ALTER SESSION SET query_rewrite_enabled=true");
    //stat.executeUpdate("ALTER SESSION SET query_rewrite_enabled=false");
    //stat.executeUpdate("ALTER SESSION SET NLS_SORT='RUSSIAN'");
    stat.executeUpdate("ALTER SESSION SET NLS_SORT='BINARY'");
    //stat.executeUpdate("ALTER SESSION SET NLS_COMP=ANSI");
    stat.executeUpdate("ALTER SESSION SET NLS_COMP='BINARY'");

    paymJour.setConnection(con);
    salesLink.setConnection(con);

    select firstfast paymJour
        order by Invoice4PaymId, Invoice4PaymDate
    join salesLink
        where salesLink.Invoice4PaymId   == paymJour.Invoice4PaymId
           && salesLink.Invoice4PaymDate == paymJour.Invoice4PaymDate
           && salesLink.SalesId          == paymJour.SalesId
           && salesLink.OrigSalesId      == "0099556";

    select firstfast paymJour
        order by Invoice4PaymId, Invoice4PaymDate
    join salesLink
        where salesLink.Invoice4PaymId   == paymJour.Invoice4PaymId
           && salesLink.Invoice4PaymDate == paymJour.Invoice4PaymDate
           && salesLink.SalesId          == paymJour.SalesId;
}

Время исполнения:
первого 6,5 сек (получаем всего 1 запись)
второго 0,1 сек (получаем первую запись)

После изменения настроек

    stat.executeUpdate("ALTER SESSION SET NLS_SORT='RUSSIAN'");
    //stat.executeUpdate("ALTER SESSION SET NLS_SORT='BINARY'");

Имеем обратную картину со временем исполнения
первого 0,1 сек (получаем всего 1 запись)
второго 5,5 сек (получаем первую запись)

Очень хочется, чтобы оба запроса быстро выполнялись
Есть какие-нибудь мысли, куда смотреть?
(нанять опытного DBA не предлагать плиз)

P.S. NLS_SORT='BINARY' - прописано в ktd-файле, так что при большом желании можно поменять раз и навсегда

[Vadik]

PHP код:

join salesLink index hint Invoice4PaymIdx 


?
клиент кстати какой версии?

[Wamr]

Фишка в том, что у нас еще исторически сложилось -hint=2, так что index hint не пройдет.
Это запросы аналог запросов из формы, а там так просто с index hint не получится. Кроме того, такая фигня практически во всех формах, => ищу универсальное решение

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

[Vadik]

Цитата:

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

Фишка в том, что у нас еще исторически сложилось -hint=2, так что index hint не пройдет

forceorder стало быть тоже можно не предлагать..

Цитата:

Клиент оракловый?

нет, интересовала версия клиента аксапты (или aos-а, в зависимости от)
c kernel rollup-ами были (вернее, есть) некоторые .. мм.. забавности..

планы наверное не помешали бы

[Wamr]

ЗАПРОС №1

SELECT /*+ FIRST_ROWS */ A.*, B.* 
FROM CUSTINVOICE4PAYMJOUR_RU A,CUSTINVOICE4PAYMSALESLINK_RU B 
WHERE (SUBSTR(NLS_LOWER(A.DATAAREAID),1,3)=NLS_LOWER('sth')) 
AND ((SUBSTR(NLS_LOWER(B.DATAAREAID),1,3)=NLS_LOWER('sth')) 
AND ((((SUBSTR(NLS_LOWER(A.SALESID),1,20)=SUBSTR(NLS_LOWER(B.SALESID),1,20)) 
AND (SUBSTR(NLS_LOWER(A.INVOICE4PAYMID),1,20)=SUBSTR(NLS_LOWER(B.INVOICE4PAYMID),1,20))) 
AND (A.INVOICE4PAYMDATE=B.INVOICE4PAYMDATE)) 
AND (SUBSTR(NLS_LOWER(B.ORIGSALESID),1,20)=NLS_LOWER('             0099556')))) 
ORDER BY SUBSTR(NLS_LOWER(A.DATAAREAID),1,3),SUBSTR(NLS_LOWER(A.INVOICE4PAYMID),1,20),A.INVOICE4PAYMDATE

План до (медленный)

6  SELECT STATEMENT
   5  NESTED LOOPS
     2  BMSSA.CUSTINVOICE4PAYMJOUR_RU TABLE ACCESS [BY INDEX ROWID]
       1  BMSSA.I_16003INVOICE4PAYMIDX INDEX [RANGE SCAN]
     4  BMSSA.CUSTINVOICE4PAYMSALESLINK_RU TABLE ACCESS [BY INDEX ROWID]
       3  BMSSA.I_16392INVOICE4PAYMIDX INDEX [RANGE SCAN]

план после (быстрый)

7  SELECT STATEMENT
   6  SORT [ORDER BY]
     5  NESTED LOOPS
       2  BMSSA.CUSTINVOICE4PAYMSALESLINK_RU TABLE ACCESS [BY INDEX ROWID]
         1  BMSSA.I_16392ORIGSALESIDX INDEX [RANGE SCAN]
       4  BMSSA.CUSTINVOICE4PAYMJOUR_RU TABLE ACCESS [BY INDEX ROWID]
         3  BMSSA.I_16003SALESIDX INDEX [RANGE SCAN]

ЗАПРОС №2

SELECT /*+ FIRST_ROWS */ A.*, B.* 
FROM CUSTINVOICE4PAYMJOUR_RU A,CUSTINVOICE4PAYMSALESLINK_RU B 
WHERE (SUBSTR(NLS_LOWER(A.DATAAREAID),1,3)=NLS_LOWER('sth')) 
AND ((SUBSTR(NLS_LOWER(B.DATAAREAID),1,3)=NLS_LOWER('sth')) 
AND ((((SUBSTR(NLS_LOWER(A.SALESID),1,20)=SUBSTR(NLS_LOWER(B.SALESID),1,20)) 
AND (SUBSTR(NLS_LOWER(A.INVOICE4PAYMID),1,20)=SUBSTR(NLS_LOWER(B.INVOICE4PAYMID),1,20))) 
AND (A.INVOICE4PAYMDATE=B.INVOICE4PAYMDATE)))) 
ORDER BY SUBSTR(NLS_LOWER(A.DATAAREAID),1,3),SUBSTR(NLS_LOWER(A.INVOICE4PAYMID),1,20),A.INVOICE4PAYMDATE

план до (быстрый)

6  SELECT STATEMENT
   5  NESTED LOOPS
     2  BMSSA.CUSTINVOICE4PAYMJOUR_RU TABLE ACCESS [BY INDEX ROWID]
       1  BMSSA.I_16003INVOICE4PAYMIDX INDEX [RANGE SCAN]
     4  BMSSA.CUSTINVOICE4PAYMSALESLINK_RU TABLE ACCESS [BY INDEX ROWID]
       3  BMSSA.I_16392INVOICE4PAYMIDX INDEX [RANGE SCAN]

план после (медленный)

7  SELECT STATEMENT
   6  SORT [ORDER BY]
     5  NESTED LOOPS
       2  BMSSA.CUSTINVOICE4PAYMJOUR_RU TABLE ACCESS [BY INDEX ROWID]
         1  BMSSA.I_16003RECID INDEX [RANGE SCAN]
       4  BMSSA.CUSTINVOICE4PAYMSALESLINK_RU TABLE ACCESS [BY INDEX ROWID]
         3  BMSSA.I_16392INVOICE4PAYMIDX INDEX [RANGE SCAN]

[Wamr]

Видно, что планы изменились одинаково - вместо выборки по индексу, соответствующего ORDER BY, появляется шаг сортировки (6)

Версия ax32serv.exe 3.0.1951.3730

[ZVV]

Цитата:

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

Видно, что планы изменились одинаково - вместо выборки по индексу, соответствующего ORDER BY, появляется шаг сортировки (6)

Версия ax32serv.exe 3.0.1951.3730

Ну это логично, т.к. в таком режиме он не может использовать индексы для сортировки. А при "бинари" он просто берёт подходящий сортировке индекс и (учитывая хинт FIRST_ROWS) берёт по нему первые записи. Другое дело, что с индексом он (оптимизатор), по ходу, в первом запросе не угадал.
Немножко об этих и похожих ситуациях я уже писал тут.

Сорри за некрофилию...