4.17.Работа с ЦУП. Получение плана запроса

Для начала несколько облегчим себе жизнь.

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

1. Из основного меню выбрать ЦУП – Сценарии.
2. Добавим свой сценарий «Мониторинг настроенный» путем копирования существующего предопределенного сценария «Мониторинг». Табличную часть заполняем, как показано на рис. 4.17.1. На нем показаны как раз все те показатели, которые обычно нужны для работы, и правильный порядок элементов структуры сценария. Строки рекомендуется добавлять копированием уже имеющихся.

Рис. 4.17.1. Добавление и заполнение своего сценария

После сохранения сценарий станет доступен в меню Выбор сценария (см. рис. 4.17.2).

Рис. 4.17.2. Меню выбора сценария

Дальнейшие действия по получению плана запроса будем проводить, считая, что сценарий настроили. Чтобы его получить, нужно:

1. Подключиться к интересующей вас базе в режиме Мониторинг настроенный. Список счетчиков заполнится автоматически.
2. Настроить счетчик «Анализ запросов», как показано на рис. 4.17.3. В режим настройки можно войти двойным щелчком на названии показателя. Можно установить минимальную длительность запроса, которая будет приниматься для рассмотрения. Запросы с меньшей длительностью будут игнорироваться. Установка минимальной длительности на 0, как на рисунке, повышает точность разбора, но дополнительно повышает нагрузку на систему и сильно увеличивает длительность анализа. Установка «Получать планы запросов» также дополнительно повышает нагрузку на систему, но часто именно ради нее анализ и делается.

Рис. 4.17.3. Настройка счетчика «Анализ запросов»

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

Рис. 4.17.4. Идет замер. Флажки установлены для показателей статистики и анализа запросов с целью получения их планов

• Подождать 1 минуту с момента установки флажков. Если это рабочая база и подключение проведено в рабочее время, счетчики начнут в онлайне показывать статистику по запросам, по ожиданиям на блокировках и по ошибкам блокировок СУБД. В примере это тестовая база. В ней запускаем на выполнение те действия, которые собирались анализировать (перепроведение документов Реализация товаров и услуг).
• После завершения интересной активности (ее видно по статистическим показателям) подождать 1 минуту, выключить счетчики, сняв флажки.
• В примере замер проводился 6 минут (включая ожидания по минуте в начале и в конце). Увеличение длительности должно производиться осознанно. Чем длиннее замер, тем дольше будет идти анализ.
• Выйти из режима мониторинга, нажав Стоп.
• Подключиться к интересующей вас базе в режиме просмотра, выбрать интересующий интервал времени, нажать Анализ в окне просмотра или Авто в окне монитора анализа (см. рис. 4.17.5).

Рис. 4.17.5. Включение анализа

• Начнется анализ (см. рис. 4.17.6), который займет какое-то время. В это время, вообще говоря, можно проводить новые замеры, запустив клиента «1С» и войдя в ту же базу ЦУП второй раз.

Рис. 4.17.6. Анализ в своей сессии блокирует окно, но можно зайти в ЦУП второй раз, продолжать замеры и отслеживать состояние анализа по «монитору анализа»

1. Результаты анализа по готовности появятся в виде таблицы, их надо изучить и сделать выводы. В нашем случае анализ 6-минутного замера занял чуть меньше часа.

Как было видно на рисунках со статистикой, замер имеет явно выраженный пик. Посмотрев таблицу результатов (см. рис. 4.17.7 и 4.17.8), можно увидеть, что вопреки ожиданиям он не относится ни к учету авансов, ни к партионному учету, а относится просто к записи в одну из таблиц регистра бухгалтерии «Хозрасчетный». Почему это произошло, станет ясно дальше.

Рис. 4.17.7. Результат анализа. Запросы, отсортированные в порядке убывания длительности. Длительность здесь интерпретируется как вес

Рис. 4.17.8. Результат анализа. Таблицы базы, отсортированные в порядке убывания длительности запросов к ним

1. Двойным щелчком по строке с надписью «Выполнение запросов» перейти собственно в анализ (см. рис. 4.17.9). В примере можно увидеть, что таких запросов было довольно много, и некоторые из них имеют ощутимый вес.

Рис. 4.17.9. Анализ запросов

1. Двойной щелчок по тексту запроса (выбранное поле на рис. выше) приводит к получению деталей об этом запросе, разделенных на несколько вкладок. Часть из них показана на рис. 4.17.10–4.17.13.

Рис. 4.17.10. Детали запроса. Контекст вызова

Рис. 4.17.11. Детали запроса. Текст запроса, как его получает сервер СУБД. В нижнем окне этот же запрос переведен в термины метаданных

Рис. 4.17.12. Детали запроса. План запроса. Часть 1

Рис. 4.17.13. Детали запроса. План запроса. Часть 2 (правее)

1. План запроса получен. Надо проанализировать его визуально. По плану из примера видно, что поиск по индексу, возвращающий по одной строчке, выполнялся 217 раз (см. оператор Nested Loops). На Table Scan можно не обращать внимания, он осуществляется по временной таблице.

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

1. После выполнения анализа в режиме просмотра также станет доступна статистика анализа, по которой можно соотносить анализ со статистикой запросов, ожиданиями на блокировках и ошибками блокировок (см. рис. 4.17.14). Для наглядности в свойствах показателя можно поменять масштаб.

Рис. 4.17.14. Режим просмотра. Стала доступна статистика анализа. Ср. рис. «Включение анализа» на шаге 8

Отправить