![]() |
#1 |
Участник
|
Ухудшение работы SQL-запросов
Доброго времени суток!
Существует интересная проблемка: имеется CRM 4 с SQL server 2005. примерно пол года назад было замечено что запросы связанные с entity1 стали выполнятся ооооочень медленно. грубо говоря запрос select top(1) * from entity1 выполнялся около 1.5 минут такое же поведение присутствовало и в функционале црм - квери на вытягивание рекорд работали медленно и постепенно начинали взлетать (ограничение на время запроса и т.д.) количество рекорд entity1 не было большим (существовали сущности с большим количеством и работали нормально) теперь подобное поведение начало повторятся и для сущности entity2. пока-что не так сильно заметно, но уверен что дело идет к такой же ситуации... как человек не шибко шарящий в SQL серверах и каких-либо тонкостях их работы прошу помощи в устранении/предостережении таких проблем. хотябы что конкретно можно почитать относительно SQL-серверов по этому поводу? |
|
![]() |
#2 |
MCT
|
А сколько записей в таблицах, что так тормозит?
Индексы не пытались строить?
__________________
Axapta book for developer |
|
![]() |
#3 |
Участник
|
В момент когда запросы на entity1 уже работали плохо, там было около 100 000 записей.
В тот же момент у entity2 было около 300 000 и запросы работали мгновенно. Сейчас кол-во записей изменилось минимально (или совсем не изменилось), а запросы отрабатываются медленней. можно даже сказать что "с каждым днем" происходит замедление. |
|
![]() |
#4 |
MCT
|
Записей не много. CRM работает в основном с представлениями, а не с таблицами поиграйтесь с индексами, должно помочь.
__________________
Axapta book for developer |
|
![]() |
#5 |
Участник
|
А вы пользуетесь функционалом предоставления общего доступа к записям? Это может очень оказывать значительное влияние, так как join с таблицей общего доступа есть почти в каждом представлении.
|
|
![]() |
#6 |
Участник
|
проблема в том, что не только CRM тормозит. запросы плохо работают в самом сиквеле...
т.е. фактически со стороны CRM-а проблема идет на второй план. а можно поподробнее об "Индексах" в SQL? хотябы название валидное на англейском, чтобы гуглить лучше было =) |
|
![]() |
#7 |
MCT
|
Начните отсюда
__________________
Axapta book for developer |
|
![]() |
#8 |
Участник
|
Благодарю!
будем читать... |
|
![]() |
#9 |
Участник
|
Цитата:
Вообще, добавление индексов обычно помогает. Еще если я не путаю, то установка update rollup'ов может сбросить индексы (если в rollup'е есть обновление таблицы), тогда надо будет их заново создать. |
|
![]() |
#10 |
Участник
|
|
|
![]() |
#11 |
Участник
|
Цитата:
select top (100) * from Filteredentity1e ? Так как пользователь получает списки именно через представления Filtered, которые как раз включают в себя join'ы с правами доступа и т.п. |
|
![]() |
#12 |
Участник
|
select top (100) * from Filteredentity1 - 25 секунд =(
|
|
![]() |
#13 |
Участник
|
Вот небольшая статья про индексы:
http://www.dynamicscrmpros.com/2012/...tuning-part-2/ Попробуйте добавить индекс поле с GUID сущности, для начала. |
|
![]() |
#14 |
Участник
|
Неоднократно сталкивались с тем, что SELECT TOP(1) может начать "глючить" в произвольный момент времени. Именно на SQL 2005. В общем виде решение так и не найдено. (Размер таблицы 10,000-100,000, размер выборки без TOP(1) - 10-100 записей. Время исполнения выборки без TOP(1) - миллисекунды. Выборка с TOP(1) - десятки секунд.) Пересчет статистики, как правило, не помогает. "Разумное" добавление индексов - тоже.
|
|
|
|