SAS2014,

Ну это наверно Idera, Red Gate, Sentry One и прочее... Я думаю у них что нибудь есть.
Но я предпочитаю по дедовски, по хардкору, через запросы :)

Ролг Хупин,

Ну это ж очевидно, когда работает все медленно :)

Andy_OLAPSAS2014пропущено...


это как один из примеров по нехватки памяти, просто щас серверу выделено макс 5 Гб, и у системе остается 2-3 Гб
вот и думаю этого достаточно или это одна из причин торможения работы БД на сервере
Коллега, подумайте вот о чем.
У Вас есть таблица небольшая, несколько миллионов строк, которая влезает в 10% оперативной памяти. И вторая аналогичная.
Вам нужно вывести select top 1000 from table1 left join table2 on неоднозначное_условие.
Оптимизатор MSSQL полез в статистику, а она устарела. И он промахнулся. Вместо того, чтобы простым table scan или index scan пробежать по двум таблицам и выдать ответ за несколько миллисекунд - он взял и решил, что из второй таблицы прилетит 2-3 строки, а поэтому построит цикл nested loops, прикрутив выборку из первой. Это была ошибка - под такое условие из второй таблицы прилетит 2-3 миллиона строк, каждую из которых нужно будет обработать на процессоре.

Памяти свободной - ну просто навалом. Запрос быстро отработает и на 5400 rpm HDD диске в ноутбуке. А база "тормозит". Куда упирается? В тактовую частоту процессора (ну и в шину и в L3 кэш, но это мелочи).

Таки Вы хоть обвешайте сервер самым крутым железом - ничего не поможет. Без - как уже тут правильно Вам подметили - главного инструмента.

"Такое средство есть. Это квалифицированный DBA" (с)


Вы понятия не имеете как работает оптимизатор, видимо.
Во первых у вас никогда не будет такого разброса в статистике и факт если она обновляется автоматом, напомню, когда таблица пустая статистика устаревает сразу же как вы добавили данные, после этого она устаривает после добавления 500 строк (если до этого было меньше 500) и потом 500+20%, я думаю вы сами можете посчитать что при таком раскладе такого разброса не будет. Более того при флаге 2371 и в 2016 по умолч. используется динамический порог обновления статистики это: SQRT(1000 * кол-во строк).
Также при использовании Top может быть использован Row Goal и здесь также может быть не однозначно как поведет себя запрос, при неравномерном распределении данных. Также не забывайте об индексах.
Я даже решил проверить как поведет себя оптимизатор при таком разбросе.
Обновил статистику с немного неверными данными, т.е. сделал Update Statistics name with rowcount = 5 для Employer
В таблице 65552 строки, это таблица Employer (я специально вставил много строк), обьеденим с таблицей Orders (830 строк, статтистика свежая) по EmployeID, итог: вверху скан Orders, внизу seek Employer через Nested Loop.
OK. А что если заказов намного больше, делаем Update Statistics name with rowcount = 1 000 000
Тут у нас интереснее, он сделал скан Employer, потом сделал Seek к индексу по EmpID на Orders, 65552 раза, вернул 830 строк, потом сделал Key Lookup к Orders. Даже если убрать Top работает довольно быстро.
Более забавно если мы добавим условие, к примеру Employes.ID > 8 (по факту есть только один такой empid, это 9, и у него 43 заказа). Даже так, при крайе неверном кол-во ожидаемых строк, SQL выбрал похожий план как и вообще без where, только теперь вверху вместо скана Employer идет Seek.
Также Нндо учитывать что когда он считает ожидаемое кол-во строк он использует помимо статистики метаданные, когда считает селективность.
К примеру возьмем план при where E.ID > 8, вверху у нас seek с ожидаемым количеством строк 4.99939, он взял это число сначала посчитав селективность, а потом умножив ее на кол-во строк из статистики. Селиктивность в данном случе у нас 0.999878 (65544/65552) округленное до нужной стпени, умноженное на 5. При этом если бы мы сделали условие Employes.ID > 8 and Employes.ID < 100 то ожидаемое кол-во строк было бы 1, так как после подсчтеа селективности и умножение ее на данные из статистики мы получим меньше 1 строки, а SQL должен вернуть минимум одну строку.

Я к чему все это, вы прям так мастерски предсказали как себя запрос поведет. К тому же надо быть полным "спецом" чтобы н езаметить такие расхождения.

Andy_OLAP,

Буду знать, что насильное использование паралельного плана означает "я знаю как работает SQL" :)