Графический план выполнения

Инструментальные средства формирования плана выполнения в графической форме позволяют собрать все информационные компоненты вывода оператора SHOWPIjAN ALL и представить их в наиболее наглядном виде. В настоящее время основным инструментальным средством формирования графического плана выполнения является программа Management Studio. Следует отметить, что при использовании этого инструмента выбор опций, необходимых для формирования плана выполнения, осуществляется с помощью программы Management Studio, а не синтаксических конструкций языка T-SQL, поэтому при его эксплуатации невозможно обойтись без указанной программы.

Графический план выполнения может быть создан в двух версиях: как оценочный и как фактический. Оценочная версия в большей степени напоминает формируемую с помощью оператора SHOWPLAN на языке T-SQL; иными словами, при использовании этой версии план запроса только разрабатывается, но фактически не выполняется. А при формировании фактического плана выполнения происходит ожидание завершения запроса, и только после этого отображаются данные, позволяющие судить о том, как в действительности был выполнен запрос.

Как правило, результаты, полученные с помощью двух указанных версий, хотя бы в чем-то различаются. Безусловно, выполнение запроса в СУБД SQL Server начинается в соответствии с теми указаниями, которые содержатся в заранее подготовленном плане запроса, но в дальнейшем, как правило, обнаруживается, что оценки стоимости, содержащиеся в этом плане, требуют уточнения, поэтому ход дальнейшего выполнения запроса корректируется. Для оценки стоимости осуществления отдельных операций обработки данных в СУБД SQL Server используются статистические данные, касающиеся таблиц и индексов, которые накапливаются в процессе работы. Эти статистические данные иногда становятся искаженными или совершенно устаревшими, поэтому оптимизатор запросов вынужден вносить в них корректировки непосредственно в ходе выполнения запроса, если при этом обнаруживается, что фактически наблюдаемые статистические данные отличаются от накопленных.

Тем не менее оценочный план выполнения в большинстве случаев является вполне приемлемым. Предусмотрены два способа формирования графического плана выполнения, которые описаны ниже.

Выбор команды Display Estimated Execution Plan в меню Query.

Щелчок на кнопке Display Estimated Execution Plan панели инструментов и вызов команды в меню Query (при использовании этого способа отображается только план с активизированной опцией NOEXEC).

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

После этого создается графическое отображение иерархии различных подпроцессов. Для просмотра данных о стоимости и другой конкретной информации о любом

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

Query 1: SELECT *

Cwery cost (relative to the batch> : 1004 FFOH Sales.SalesOrderHeader

Caput e Scalar Ctost: 1 (

Cost: 1 *

Clustered Inde:r Scan [AdveitureVorks] . [Sales]. (SaiesOtfie. Cost: ЭЭ S

Рис. 23.1. Всплывающая подсказка в графическом платье выполнения

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

Оператор statistics

Для полчения реальной информации, основанной на статистических данных конкретного запроса, можно также использовать программу SQL Server Profiler и оператор STATISTICS PROFILE.

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

Оператор set statistics io on\ off

Оператор SET STATISTICS 10 ON OFF часто используется для анализа хода выполнения запроса с точки зрения его производительности. Оператор STATISTICS 10 позволяет получить важную информацию о том, какая работа фактически проводится в связи с выполнением запроса, в том числе сгруппированную по показателям, указанным ниже.

Physical Reads. Показатель Physical Reads позволяет узнать, какое количество физических страниц было считано с диска. Значение этого показателя никогда не превышает значение показателя Logical Reads. Следует учитывать, что повторное вьшолнение запроса может привести к уменьшению значения показателя Physical Reads, поскольку к страницам, которые уже находятся в буферном кэше, не применяются операции физического чтения. Кроме того, это значение уменьшится, если некоторые страницы будут считаны заблаговременно в связи с использованием механизма опережающего чтения, приме-

няемого в СУБД SQL Server. Это означает, что количество физических страниц, действительно считанных при выполнении запроса, часто бывает меньше того количества, которое могло бы быть считано при других обстоятельствах.

Logical Reads. Показатель Logical Reads является более надежным свидетельством того, какое количество страниц данных требуется для выполнения запроса, по сравнению с показателем Physical Reads, поскольку в нем учитываются все операции логического чтения данных.

Read Ahead Reads. Показатель Read Ahead Reads позволяет определить количество страниц, считанных в кэш в результате применения механизма опережающего чтения SQL Server. В действительности страницы, считанные таким образом, могут и не использоваться для выполнения запроса.

Scan Count. Показатель Scan Count позволяет определить количество операций просмотра таблицы.

Часть информации, формируемой при выполнении оператора STATISTICS 10, может быть получена с помощью утилиты perfmon. В частности, коэффициент попадания в кэш вычисляется путем вычитания количества операций физического чтения из количества операций логического чтения и деления полученного остатка на общее количество операций чтения (под этим подразумевается количество операций логического чтения).

Ключом к успешному использованию оператора STATISTICS 10 является поиск с его помощью всех таблиц, в процессе работы с которыми обнаруживается чрезмерно большое количество операций физического или логического чтения.

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

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

Оператор set statistics time on j off

Оператор SET STATISTICS TIME ON OFF позволяет определить, какое количество процессорного времени фактически требуется для выполнения запроса. Безусловно, для этой цели можно было бы использовать оператор SELECT GETDATE () и вычислять разницу отметок времени до и после выполнения запроса, но оператор SET STATISTICS TIME ON OFF является более удобным, поскольку позволяет определить, сколько времени потребовалось на интерпретацию и планирование запроса, а также на его выполнение.

Опция Include Client Statistics

Предусмотрена также возможность просматривать статистическую информацию о соединении в ходе выполнения запроса. Для этого достаточно выбрать опцию Include Client Statistics в меню Query. После выбора этой опции появляется вкладка Client Statistics в области окна результатов Query Window, как показано на рис. 23.2.