Отмена сортировки по умолчанию на форме

[egorych]

Ой, сколько откликов за ночь! Отвечаю по порядку.
Аксапта 3 KR2 на Oracle 10g.
Да, речь идет об медленном открытии формы. Табличка партицированная (~250млн. записей), видимо поэтому order by очень сильно тормозит!
Для 1 записи (или нескольких - история) открывается мгновенно.
Пробовал вставлять sortclear и в init и в execute - результат однинаков т.е. никакого! Попробую еще с подменой query.
Св-во index на датасорсе не заполнено
Статистика и индекс перестроены, пересчитаны и залочены - табличка архивная, заполняется 1 раз в год.
Почему думаю, что тормозит order by? Я собственно не думаю, а знаю - пробовал в разных видах этот запрос делать во внешних тулзах - как только убираешь сортировку - все работает быстро!

[mazzy]

Цитата:

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

Аксапта 3 KR2 на Oracle 10g.

Ух ты, какая древность.
А свойство primary index на самой таблице?

(cluster index пусть остается)

===============
добавлено: у меня только ax3.0 SP6. ни в исходном слое, ни в SP6 в свойствах не установлен Primary Index. А вот в SP2 - не помню.

[egorych]

Цитата:

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

Ух ты, какая древность.
А свойство primary index на самой таблице?
(cluster index пусть остается)

И primary и cluster - все поля пустые!
В том и вопрос, что все известные мне способы отмены сортировки почему-то не работают!

[AndyD]

Цитата:

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

И primary и cluster - все поля пустые!
В том и вопрос, что все известные мне способы отмены сортировки почему-то не работают!

Интересно.
У меня в конфиге из подписи кластерный индекс есть

А если таблицу просматривать в Обозревателе из Аксапты - тоже тормозит, или открывает быстро?

[egorych]

Цитата:

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

Индекс TableRecIdIdx - не является уникальным. Соотвественно, не может быть и первичным

Да, это так, но т.к. индекс на таблице 1, то система добавила к нему RecID автоматом и получился уникальный индекс.

Цитата:

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

У меня другой вопрос.
Каким образом хранятся в кластерном индексе рассчитанные значения для функционального ключа? И как упорядочиваются записи по нему?

Не совсем понял вопрос? Косяпта, как известно, в случае Оракла использует т.н. FBI и, соответственно в запросах также использует обертку для строковых полей из NLS_LOWER и SUBSTR, поэтому индексы используются нормально. Это то очем спрашивали?

Цитата:

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

А если таблицу просматривать в Обозревателе из Аксапты - тоже тормозит, или открывает быстро?

Тоже тормозит - на сервере запрос получается все равно с order by !

[tricky]

может быть это поможет

[AndyD]

Цитата:

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

Да, это так, но т.к. индекс на таблице 1, то система добавила к нему RecID автоматом и получился уникальный индекс.

В базе да, добавит. Но вот в Аксапты нельзя сделать неуникальный индекс (Mandatory=No) первичным - интерфейс не позволит. По-этому я и обратил на это внимание

Цитата:

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

Не совсем понял вопрос? Косяпта, как известно, в случае Оракла использует т.н. FBI и, соответственно в запросах также использует обертку для строковых полей из NLS_LOWER и SUBSTR, поэтому индексы используются нормально. Это то очем спрашивали?

Нет
Это был вопрос, что бы понять, как оно устроено.
Не обращайте внимание

Цитата:

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

Тоже тормозит - на сервере запрос получается все равно с order by !

А план выполнения не пробовали смотреть? С order by и без него

[egorych]

Цитата:

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

А план выполнения не пробовали смотреть? С order by и без него

Да план смотрел - разница в "SORT ORDER BY" - что, в общем, логично.
запрос такой -

PHP код:

SELECT /*+ FIRST_ROWS */A.DESCRIPTION,A.LOGTYPE,A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME,A.CREATEDBY,A.CREATEDTRANSACTIONID,A.RECVERSION,A.RECID,A.DATA 
FROM SYSDATABASELOG_ARH A 
WHERE (SUBSTR(NLS_LOWER(DATAAREAID),1,3)=NLS_LOWER(:in1)) 
ORDER BY SUBSTR(NLS_LOWER(A.DATAAREAID),1,3),A.TABLE_,A.LOGRECID,A.CREATEDDATE,A.CREATEDTIME 


планы такие

[AndyD]

Цитата:

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

Ух ты, какая древность.
А свойство primary index на самой таблице?

(cluster index пусть остается)

===============
добавлено: у меня только ax3.0 SP6. ни в исходном слое, ни в SP6 в свойствах не установлен Primary Index. А вот в SP2 - не помню.

Индекс TableRecIdIdx - не является уникальным. Соотвественно, не может быть и первичным

Да и зачем нужен, в данном случае, Primary Key?


У меня другой вопрос.
Каким образом хранятся в кластерном индексе рассчитанные значения для функционального ключа? И как упорядочиваются записи по нему?

[mazzy]

Цитата:

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

Да и зачем нужен, в данном случае, Primary Key?

Спрашиваю, потому что автор не сказал ни о версии, ни модификациях.
теперь мы можем быть уверены, что индексов в свойствах нет ни на форме, ни в таблице.

но ведь барабашки - нет!

значит, остаются какие-то непонятнки с ядром ax3.0 SP2.
Насколько я помню, SP2 глючный какой-то был. Мы старались обновлять клиентов до SP3, а потом хотя бы до Kernel Rollup 2. В KR2 много чего поправлено в ядре было.

egorych, у вас точно exe-шники от ax3.0 SP2?
или вы exe-шники таки обновляли?
что показывается в окне Помощь \ О программе?

можете скриншот привести?
щас мы вашу версию определим http://forum.mazzy.ru/index.php?showtopic=881

заодно, вы пробовали обновлять exe-шники до SP5? можете попробовать на тестовой базе и сообщить о результатах? может это багофича ядра какая-нибудь.

[AndyD]

Цитата:

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

значит, остаются какие-то непонятнки с ядром ax3.0 SP2.
Насколько я помню, SP2 глючный какой-то был. Мы старались обновлять клиентов до SP3, а потом хотя бы до Kernel Rollup 2. В KR2 много чего поправлено в ядре было.

egorych, у вас точно exe-шники от ax3.0 SP2?
или вы exe-шники таки обновляли?
что показывается в окне Помощь \ О программе?

У него в подписи
Axapta 3.0 sp - хз какой, kr2
Что-то сомневаюсь, что там sp2