Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Оценка плана  [new]
relief
Member

Откуда:
Сообщений: 1197
Есть таблица. Сделал запрос и включил "Include Actual Execution plan" - время выполнения меньше секунды.
Добавил в эту таблицу индекс - опять время выполнения меньше секунды,
но Estimated Operator Cost в первом случае был 70, а во втором 11 в крайнем левом селекте в графе плана

Правильно я понимаю, что основным критерием сравнения планов является Estimated Operator Cost на выходе?
13 фев 12, 16:13    [12082625]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
relief
Есть таблица. Сделал запрос и включил "Include Actual Execution plan" - время выполнения меньше секунды.
Добавил в эту таблицу индекс - опять время выполнения меньше секунды,
но Estimated Operator Cost в первом случае был 70, а во втором 11 в крайнем левом селекте в графе плана

Правильно я понимаю, что основным критерием сравнения планов является Estimated Operator Cost на выходе?


ну еще кроме плана существуют статистики IO. А в планах разные операторы бывают. Если просто смотреть Estimated Operator Cost - то лично мне ни о чем оно не говорит...
13 фев 12, 16:32    [12082813]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
relief
Member

Откуда:
Сообщений: 1197
SanyL
relief
Есть таблица. Сделал запрос и включил "Include Actual Execution plan" - время выполнения меньше секунды.
Добавил в эту таблицу индекс - опять время выполнения меньше секунды,
но Estimated Operator Cost в первом случае был 70, а во втором 11 в крайнем левом селекте в графе плана

Правильно я понимаю, что основным критерием сравнения планов является Estimated Operator Cost на выходе?


ну еще кроме плана существуют статистики IO. А в планах разные операторы бывают. Если просто смотреть Estimated Operator Cost - то лично мне ни о чем оно не говорит...


а есть какие то критерии оценки на что смотреть или совокупность каких параметров смотреть?
или как понять какой план эффективней?
13 фев 12, 16:37    [12082869]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
relief
SanyL
пропущено...


ну еще кроме плана существуют статистики IO. А в планах разные операторы бывают. Если просто смотреть Estimated Operator Cost - то лично мне ни о чем оно не говорит...


а есть какие то критерии оценки на что смотреть или совокупность каких параметров смотреть?
или как понять какой план эффективней?


критериев нет. План - это то как сервер выполянет запрос. А дальше Вы должны знать внутренние механизмы работы SQL сервера и архитектуру БД, чтобы сделать вид что там и там былобы оптимальнее если...
13 фев 12, 16:40    [12082893]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
т.е. как пример: что лучше index scan или index seek?
13 фев 12, 16:41    [12082904]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
relief
Member

Откуда:
Сообщений: 1197
SanyL
relief
пропущено...


а есть какие то критерии оценки на что смотреть или совокупность каких параметров смотреть?
или как понять какой план эффективней?


критериев нет. План - это то как сервер выполянет запрос. А дальше Вы должны знать внутренние механизмы работы SQL сервера и архитектуру БД, чтобы сделать вид что там и там былобы оптимальнее если...


интересно. а как понять тогда какой из запросов эффективней?
13 фев 12, 16:42    [12082914]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5124
relief
а как понять тогда какой из запросов эффективней?

с точки зрения клиента "более эффективный" тот который выполняется за меньшее время.
13 фев 12, 16:48    [12082975]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
relief,

Основным критерием сравнения является меньшая стоимость, но стоимость эта сравнивается не 11 против 70, а сравнивается стоимость возможных вариантов при компиляции. Добавив индекс, вы изменили поле возможных вариантов и соответсвенно тот план который у вас получился является наименее дешевым среди тех кариантов, которые возможны с добавленным индексом. Цифры 11 и 70 показывают только процент вклада ветки от общей.
13 фев 12, 16:49    [12082987]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
relief
SanyL
пропущено...


критериев нет. План - это то как сервер выполянет запрос. А дальше Вы должны знать внутренние механизмы работы SQL сервера и архитектуру БД, чтобы сделать вид что там и там былобы оптимальнее если...


интересно. а как понять тогда какой из запросов эффективней?


для того чтобы понять как эффективней - надо вводить метрики. А метрики зависят от того что нам критичнее - для когото более оптимален тот что меньше времени работает, для когото кто меньше ресурсов одновременно потребляет.

Вот почему я задал вопрос с index scan или index seek - он на самом деле показателен... т.е. сразу напрашивается ответ - ну конечно index seek... но если мы выбираем 90% записей таблицы - то при index seek мы потратим больше ресурсов сервера и скорее всего это будет дольше по времени. Иными словами - нельзя говорить о "сферическом коне в вакууме". План может быть одновременно хорошим для одного запроса и плохим для аналогичного\подобного.
13 фев 12, 16:49    [12082990]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SomewhereSomehow
relief,

Основным критерием сравнения является меньшая стоимость, но стоимость эта сравнивается не 11 против 70, а сравнивается стоимость возможных вариантов при компиляции. Добавив индекс, вы изменили поле возможных вариантов и соответсвенно тот план который у вас получился является наиболее дешевым среди тех кариантов, которые возможны с добавленным индексом. Цифры 11 и 70 показывают только процент вклада ветки от общей.
опечатка.
13 фев 12, 16:50    [12082998]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
SomewhereSomehow
relief,

Основным критерием сравнения является меньшая стоимость, но стоимость эта сравнивается не 11 против 70, а сравнивается стоимость возможных вариантов при компиляции. Добавив индекс, вы изменили поле возможных вариантов и соответсвенно тот план который у вас получился является наименее дешевым среди тех кариантов, которые возможны с добавленным индексом. Цифры 11 и 70 показывают только процент вклада ветки от общей.


а как оценить стоимость? вот надо ее взвесить в граммах - а что в роли этих граммов будет? и как их взвесить? Проценты - ни о чем, суммарно у нас всеравно 100%, это понятно... Дальше если у меня есть проблемы с ресурсами сервера, например, так пусть запрос работает 10 минут и грузит процессор на 20% нежели работает 3 минуты - но кроме него ни кто больше не может... а возможно у меня ресурсов сток что девать некуда - так тогда пусть он работает максимально быстро...
13 фев 12, 16:53    [12083014]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Дедушка
relief
а как понять тогда какой из запросов эффективней?

с точки зрения клиента "более эффективный" тот который выполняется за меньшее время.


но у DBA точка зрения часто отличается от клиентской, а анализ планов - в первую очередь его задача.
13 фев 12, 16:54    [12083027]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
relief
SanyL
пропущено...


критериев нет. План - это то как сервер выполянет запрос. А дальше Вы должны знать внутренние механизмы работы SQL сервера и архитектуру БД, чтобы сделать вид что там и там былобы оптимальнее если...


интересно. а как понять тогда какой из запросов эффективней?


вот чтобы оценить эффективность плана - Вы должны знать внутренние механизмы работы SQL сервера и архитектуру БД. т.е. MSSQL должен за ограниченное (подчеркиваю ограниченное) время построить план выполнения запроса. Пребрать и сравнить все варианты планов выполнения для произвольно запроса сервер не может, как пример - у вас в запросе объединение 17 таблиц, значит только чтобы оценить их варианты соединений надо оценить 17! перестановок. Кроме соединений много других хороших операций требуют оценки. Для этого зашит ряд эвристических методов. Они не всегда оптимальны - и человеческий мозг часто может придумать другое решение, например понять что нужен индекс и с индексом оно заработает лучше.

т.е. по-сути оценка плана выполнения - не имеет под собой четко структурированного процесса, это процесс эвристический.
13 фев 12, 17:02    [12083087]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
relief
Member

Откуда:
Сообщений: 1197
SanyL
Дедушка
пропущено...

с точки зрения клиента "более эффективный" тот который выполняется за меньшее время.


но у DBA точка зрения часто отличается от клиентской, а анализ планов - в первую очередь его задача.


ну вы хотя бы натолкните к критериям оценки. как научиться сравнивать
13 фев 12, 17:03    [12083102]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
relief
SanyL
пропущено...


но у DBA точка зрения часто отличается от клиентской, а анализ планов - в первую очередь его задача.


ну вы хотя бы натолкните к критериям оценки. как научиться сравнивать


1. Научиться его читать
2. Изучить все операторы (как они называются и что теоретически делают мало - надо четко знать как они работают физически)
3. Знать архитектуру БД
4. Знать как физически работают, например, индексы, как они устроены и т.д.

ну какбы если в такой последовательности будете разбираться - то через некоторое время Вы сами не заметите как сможете научиться давать оценки планам выпполнения... по-началу надо будет подумать, а потом чтото уже будет бросаться в глаза...
13 фев 12, 17:08    [12083134]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5124
relief
ну вы хотя бы натолкните к критериям оценки. как научиться сравнивать
анализ запроса
13 фев 12, 17:12    [12083172]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Дедушка
relief
ну вы хотя бы натолкните к критериям оценки. как научиться сравнивать
анализ запроса


особенно понравилось:
"7.Поддерживается ли в оптимизаторе запросов самая лучшая возможность оптимизации сложного запроса? Дополнительные сведения см. в разделе Рекомендации по настройке запроса."
13 фев 12, 17:15    [12083217]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
relief
Member

Откуда:
Сообщений: 1197
Дедушка
relief
ну вы хотя бы натолкните к критериям оценки. как научиться сравнивать
анализ запроса


Гран мерси!
13 фев 12, 17:25    [12083314]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SanyL
а как оценить стоимость? вот надо ее взвесить в граммах - а что в роли этих граммов будет? и как их взвесить? Проценты - ни о чем, суммарно у нас всеравно 100%, это понятно... Дальше если у меня есть проблемы с ресурсами сервера, например, так пусть запрос работает 10 минут и грузит процессор на 20% нежели работает 3 минуты - но кроме него ни кто больше не может... а возможно у меня ресурсов сток что девать некуда - так тогда пусть он работает максимально быстро...

Каждый физический оператор в плане имеет свою стоимость. Стоимость определяется исходя из требований оператора к I/O, CPU, Memory, например, влияет алгоритм оператора, конкретная его вариация в конкретном запросе, количество строк. Конкретных цифр я не знаю, т.к. они не афишируются. Знаю например, что одна операция чтения страницы оценивается как 1/320 = 0,003125, исходя из предположения модели о том что дисковая подсистема может выполнять 320 операций случайного доступа в секунду. Это не значит, что если у вас быстрее или медленнее, то оценки поплывут. Это величина относительная и используется совместно с другими коэффициентами, которые сохраняют баланс независимо от оборудования.
13 фев 12, 18:45    [12084023]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
SomewhereSomehow
SanyL
а как оценить стоимость? вот надо ее взвесить в граммах - а что в роли этих граммов будет? и как их взвесить? Проценты - ни о чем, суммарно у нас всеравно 100%, это понятно... Дальше если у меня есть проблемы с ресурсами сервера, например, так пусть запрос работает 10 минут и грузит процессор на 20% нежели работает 3 минуты - но кроме него ни кто больше не может... а возможно у меня ресурсов сток что девать некуда - так тогда пусть он работает максимально быстро...

Каждый физический оператор в плане имеет свою стоимость. Стоимость определяется исходя из требований оператора к I/O, CPU, Memory, например, влияет алгоритм оператора, конкретная его вариация в конкретном запросе, количество строк. Конкретных цифр я не знаю, т.к. они не афишируются. Знаю например, что одна операция чтения страницы оценивается как 1/320 = 0,003125, исходя из предположения модели о том что дисковая подсистема может выполнять 320 операций случайного доступа в секунду. Это не значит, что если у вас быстрее или медленнее, то оценки поплывут. Это величина относительная и используется совместно с другими коэффициентами, которые сохраняют баланс независимо от оборудования.


И что это Вам дает? Вот есть набор операторов с весами - Ваш запрос при этом самый оптимальный? Или можно сделать его оптимальнее? Почему?
14 фев 12, 12:43    [12087755]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SanyL,

Не понял вопроса.
Для сужения кол-ва перестановок применяются эвристики, дальше применяются правила преобразования, которые никакие не "нечетко структурированные", а вполне себе математические, генерируются разные группы операторов, все это дело сохраняется во внутренней структуре, после этого, варианты оцениваются и выбирается самый дешевый. Плюс ко всему, процесс разбит на стадии, от стадии к стаии процесс поиска усложняется.
Что вы хотите сказать, что оптимизатор не всегда выбирает оптимальный план? Это и ежу понятно. Но часто это бывает не по причине "плохих" эвристик или "общей нечеткости" процесса, а по причине нехватки/неактуальности/неточности каких-то данных или структур поиска, необходимых оптимизатору.
14 фев 12, 13:12    [12088038]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
SomewhereSomehow
SanyL,

Не понял вопроса.
Для сужения кол-ва перестановок применяются эвристики, дальше применяются правила преобразования, которые никакие не "нечетко структурированные", а вполне себе математические, генерируются разные группы операторов, все это дело сохраняется во внутренней структуре, после этого, варианты оцениваются и выбирается самый дешевый. Плюс ко всему, процесс разбит на стадии, от стадии к стаии процесс поиска усложняется.
Что вы хотите сказать, что оптимизатор не всегда выбирает оптимальный план? Это и ежу понятно. Но часто это бывает не по причине "плохих" эвристик или "общей нечеткости" процесса, а по причине нехватки/неактуальности/неточности каких-то данных или структур поиска, необходимых оптимизатору.


Нет, я сейчас не пытаюсь податься в эту сторону... я пытаюсь сказать, что оптимальность запроса не имеет однозначного критерия. т.е. - да с одной стороны если запрос потребляет минимум I/O, CPU, Memory то он максимально оптимален, но не факт что он самый быстрый по времени и наоборот самый быстрый не факт что будет оптимален по I/O, CPU, Memory. Соответственно критерий оптимальности надо выбирать свой под конкретную задачу.
14 фев 12, 13:34    [12088229]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SanyL
критерий оптимальности надо выбирать свой под конкретную задачу.
Я так и не понял, что значит на практике "выбирать под конкретную задачу"? Как именно выбрав критерий, вы, в зависимости от него, влияете на план?
14 фев 12, 13:44    [12088314]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
SomewhereSomehow
SanyL
критерий оптимальности надо выбирать свой под конкретную задачу.
Я так и не понял, что значит на практике "выбирать под конкретную задачу"? Как именно выбрав критерий, вы, в зависимости от него, влияете на план?


я не это имею ввиду,

ну вот смотрите - у Вас есть 2 разных плана. Один работает 2 минуты и, скажем, занимает проц на 100%. Другой работает 10 минут и занимает проц на 20%. Какой оптимальнее? Ну допустим если у нас куча процов - то и ладно, пусть грузит на 100... но если проц один - то лучше пусть работает 10 минут. Значит в моей ситуации второй вариант он оптимальнее, даже не смотря на то что суммарно он возможно съест больше ресурсов сервера.

Ну конечноже пример утрированный - но показателен.
14 фев 12, 13:52    [12088428]     Ответить | Цитировать Сообщить модератору
 Re: Оценка плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SanyL,

А я вот не могу сказать, что второй оптимальнее, я же не знаю других данных, может там диск от i/o все эти 10 минут умирает?

Вы говорите про управлении ресурсами, а я об оптимизации одного конкретного запроса и стоимости получающегося плана. Если речь идет о разных запросах, то каждый решает сам, как ему достигнуть цель, запустить ли ему например курсор с циклом, или один большой запрос или использовать временные таблицы или еще как-то.

Если мы говорим про один запрос (а ТС спрашивал вроде именно об этом), то как вы собираетесь сообщить серверу свой критерий? Иными словами, я не вижу смысла, например, менять соотношения коффицентов веса стоимости операции чтения и процессора, или принудительно использовать hash join, чобы увеличить нагрузку на память и снизить на что-то другое, если я знаю что у меня на сервере много процессоров или много памяти.
14 фев 12, 14:34    [12088954]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить