Программный комплекс "Оптимизатор запросов в MS SQL 2005"   

Для системы 1С:УПП 8.1 и других подобных "тяжелых" конфигураций очень актуальна задача оптимизации неэффективных запросов. В результате на практике оптимизация запросов на MS SQL 1C 8.1 и 1С 8.2 - это тяжелая, кропотливая работа, требующая высокой квалификации. Компания СофтПоинт предлагает новый продукт "Оптимизатор запросов в MS SQL 2005", который позволяет максимально упростить процесс оптимизации запросов для MSSQL 2005 1С 8.1 и 1С 8.2.

Конкурентные преимущества "Оптимизатора запросов в MS SQL 2005":

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

  2. Возможно оценить эффект оптимизации в динамике. Оптимизированные запросы изменят статистику распределения нагрузки. Эти изменения во времени можно будет наблюдать в удобном графическом представлении.

  3. Возможно оценить эффект от того или иного индекса и понять в каких конкретно запросах он сработает.

  4. Можно найти "узкие" места в запросах с детализацией до "узла" плана выполнения и предикатов. Группировку можно сделать также в разрезе объектов 1С и возможность в графическом интерфейсе просматривать план выполнения с названиями объектов 1С.

  5. "Оптимизатор запросов в MS SQL 2005" не только понимает, какой индекс необходимо добавить, но и дает рекомендации по оптимальному синтаксису и оптимальной структуре запросов.

  6. Сбор данных информации не нагружает рабочую систему (доп. нагрузка не более 5 %).

  7. Анализ селективности получаемой информации пользователями (анализ замера "рекордсетов").

Детальное описание каждого из преимуществ "Оптимизатора запросов в MS SQL 2005":

Эффективная оценка вклада каждого запроса в общую нагрузку SQL сервера.

"Оптимизатор запросов в MS SQL 2005" легко интегрируется с системой мониторинга производительности "PerfEpxert",  что в комплексе позволяет отображать и анализировать важную информацию для разработчиков 1С по оптимальным запросы SQL, и знать, где именно в 1С они вызываются, а также какой вклад дают в общую нагрузку. Увидев статистику нагрузки на сервер по CPU, reads и т.п. в разрезе Номеров строк и модулей 1С, разработчик четко будет понимать, что именно в 1С необходимо оптимизировать и какой это даст эффект.

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

Пример: У одного из клиентов бухгалтерский запрос работал с не оптимальными планами выполнения, отличающимися друг от друга. Проведенный анализ показал, что основной вклад дает определенная строка модуля 1С, формирующая бухгалтерский запрос к счету товарных остатков. Просмотр плана выполнения запроса на первый взгляд не показал явных ошибок. Анализ выполненный с помощью "Оптимизатора запросов в MS SQL 2005" показал, что большую часть нагрузки дает узел плана выполнения с поиском по индексу. При этом количество строк возвращаемых узлом было большим и недостаточно селективным. В данном случае гораздо лучше себя вел тот же самый запрос с сканированием индекса, а не поиском по нему. В результате задача достаточно быстро решилась добавлением предварительной проверки условий даты отбора. И при определенных значения интервала не являющимся достаточно селективным условие - это вообще исключалось из SQL конструкции (переносилась проверка в клиентскую часть). Хотя, конечно, в данном случае имелась определенная специфика работы планировщика запросов MS SQL. 

Оценка оптимизации в динамике.

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

Эффективная оптимизации в расстановке индексов.

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

Эффективность группировки нагрузки на систему в разрезе узлов планов запросов.

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

Эффективность оптимизации индексов и запросов (на уровне синтаксиса).

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

Эффективный анализ фильтрации при выборке данных.

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

Практически нулевая нагрузка, создаваемая средствами мониторинга, на систему в целом.

Анализ планов выполнения происходит непрерывно на отдельном сервере мониторинга. Механизмы сбора максимально оптимизированы за счет чего дополнительная нагрузка на сервер системой сбора данных составляет не более 5-и процентов.