AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.05.2006, 11:03   #1  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от Gelios
...
Может кто сможет лучше?
...
При оптимизации производительности нечасто можно дать совет, который даст ощутимый эффект во всех случаях (при различном стечении обстоятельств (количество записей в таблицах, по которым выполняется запрос; особенности самих данных, например, количество компаний в терминах Аксапты, которые в одной базе живут; особенности конфигурации железа и ПО; ну и т.д.) та или иная ручная оптимизация запросов может дать как положительный, так и отрицательный эффект). Исключением является явная ошибка разработчика, когда закладывается ошибка, которая приводит к тому, что запрос работает плохо во всех или почти во всех случаях. Как, например, в данном случае, когда перед массовым обновлением таблицы в ней не удаляются индексы, в которых есть обновляемые запросом поля, особенно, если такие индексы являются кластерными (это первое, что мне сразу пришло в голову, когда мне пришлось оптимизировать процедуру дефрагментации RecId).

Не могу сказать, лучше это или нет...

В общем, мне на MS SQL Server существенно помогло принудительное использование loop join вместо hash join в указанном вами запросе. Могу увереноо сказать, что данное действие даст ощутимый эффект только в том случае, если обе (надеюсь, все понимают, о чем идет речь) таблицы не будут помещаться в кэше SQL Server. И оно вполне может не дать (тесты не проводил) ощутимого эффекта, если база относительно невелика, а оперативной памяти на сервере относительно много.

Если кому-нибудь понадобится сделать дефрагментацию на большой базе, я готов предоставить готовый код для тестирования (пока он не оттестирован на большой базе и не доказал свою эффективность, выкладывать его не вижу смысла). Самому пока проверить его на большой базе не доводилось, к сожалению.

Ну и очень много чего зависит в данной процедуре от того, насколько шустрым является дисковый массив. Судя по скорости работы стандартной процедуры, у Gelios он довольно мощный. Это как раз тот редкий случай, когда имеет смысл поиграться ручной оптимизацией размещения файлов на диске (вынести AXOLDTONEWRECIDS на отдельный диск).

А за науку про оптимизацию запроса за счет использования обращения только к индексу с меня лично большой респект.
__________________
С уважением,
glibs®
Теги
ax3.0, faq, recid, дефрагментирование recid

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
if (record) vs if (record.RecId) kashperuk DAX: Программирование 18 27.11.2008 18:53
поля, содержащие RecId somebody DAX: Программирование 15 16.05.2008 17:50
aEremenko: Дефрагментация RecID Blog bot DAX Blogs 2 06.03.2007 22:25
Два RecId у одной записи таблицы sparur DAX: Программирование 33 18.12.2006 15:56
Форма InventOnhandItem, Почему RecID у InventSum в этой форме всегда 0? Кирилл DAX: Программирование 2 25.05.2004 18:15

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:40.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.