Показать сообщение отдельно
Старый 07.05.2006, 11:03   #3  
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®