|
23.08.2007, 10:10 | #1 |
Участник
|
Тормоза SQL при наличии в InventDimId русских букв.
Заметил интересную особенность SQL 2005 (Axapta 3.0 SP5 KR2).
Все номерные серии в Аксе у меня начинаются с русских букв (пример: НА99999 - InventDimId) Так вот при joine к таблицам InventSum, InventTrans (запрос на T-SQL) происодят жуткие тормоза (загруз SQL на 8 процессорной тачке под 100%). Если в запросе в условии join TRIM первые руссие символы - запрос выполняется несколько секунд при слабой загрузке проца. 1-й вопрос: Используете ли вы в номерных сериях документов в Аксе русские буквы. 2-й вопрос: Может ли эта ситуация реально влиять на производительность выполнения запросов. |
|
23.08.2007, 10:20 | #2 |
Участник
|
Я бы посмотрел план запроса - может со статистикой чего?
А SP какие-нибудь на SQL накатаны? |
|
23.08.2007, 10:43 | #3 |
Участник
|
Статистику перед этим пересчитывал.
Да канечно все последний апдейты SP2 |
|
23.08.2007, 10:50 | #4 |
Участник
|
Цитата:
Сообщение от polygris
Заметил интересную особенность SQL 2005 (Axapta 3.0 SP5 KR2).
Все номерные серии в Аксе у меня начинаются с русских букв (пример: НА99999 - InventDimId) Так вот при joine к таблицам InventSum, InventTrans (запрос на T-SQL) происодят жуткие тормоза (загруз SQL на 8 процессорной тачке под 100%). Если в запросе в условии join TRIM первые руссие символы - запрос выполняется несколько секунд при слабой загрузке проца. 1-й вопрос: Используете ли вы в номерных сериях документов в Аксе русские буквы. 2-й вопрос: Может ли эта ситуация реально влиять на производительность выполнения запросов. 2. Для служебных идентификаторов лучше использовать не #, а спецсимвол &. Код получается компактнее. http://axapta.mazzy.ru/lib/numbersequenceformat/ |
|
23.08.2007, 10:56 | #5 |
Участник
|
Collation: Cyrillic_General_CI_AS
|
|
23.08.2007, 16:25 | #6 |
Участник
|
тогда вряд ли из-за него.
смотрите в профайлер и в план запроса. |
|
28.08.2007, 12:28 | #7 |
Участник
|
Результаты расследования проблемы.
Первое, что сделали это в InventDim в поле InventDimId заменили (с помощьюе renamePrimaryKey()) первые две русские буквы нулями (запрос без трима начал работать и отработал за 30 сек. С тримом - отработал за 10 секунд (т.е. как и раньше, в принципе другого и не могло и быть) Второе, что сделали это обрезали InventDimId в InventDim до трех цифр (опятьже с помощью renamePrimaryKey()). Результат запрос без тримов выполняется 3 секунды. Т.е. можно сделать вывод о том чем меньше размер ключа в InventDimId, тем шустрей работает JOIN по этому полю. |
|
28.08.2007, 12:55 | #8 |
Участник
|
Тебе уже намекнули, посмотри план выполнения этого запроса собственно на сервере. В MS SQL. И не мучь животинку (AXAPTA) разными настройками пока не поймешь причину тормоза.
Если бы ты с этого начал, то мог бы заметить, что от размера поля скорость завист слабо. Она зависит от используемых индексов. Если работает TRIM(), то индекс использовать нельзя. Вынужденно сканируем таблицу. Отсюда и тормоз. |
|
28.08.2007, 13:02 | #9 |
Участник
|
Цитата:
Если бы ты с этого начал, то мог бы заметить, что от размера поля скорость завист слабо. Она зависит от используемых индексов. Если работает TRIM(), то индекс использовать нельзя. Вынужденно сканируем таблицу. Отсюда и тормоз
Тогда получается при моем размере таблици InventDim скан работает быстрее чем прыжок по индексу. |
|
28.08.2007, 13:48 | #10 |
Участник
|
Откуда же я знаю какой именно у тебя план выполнения в разных ситуациях? Ты же об это скромно умалчиваешь Поэтому твои выводы, мягко говоря, не достоверные. Скорее всего, следствие каких-либо стечений обстоятельств.
|
|
Теги |
ax3.0 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|