Настройка SQL-запросов при помощи Optim Query Tuner: Часть 3. Cбор и настройка рабочей нагрузки

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

В предыдущих статьях серии было введено понятие путей доступа, демонстрировалось чтение диаграмм путей доступа в Optim Query Tuner и объяснялась методика настройки отдельных запросов. В третьей части будет представлена методика настройки рабочих SQL-нагрузок. Узнайте, как использовать InfoSphere® Optim™ Query Workload Tuner для получения рабочих SQL-нагрузок из различных источников, сбора статистики, анализа индексов, сравнения планов доступа, а также для изоляции планов и управления планами. Цель – обеспечить оптимизатор IBM® DB2® всей необходимой информацией для принятия наилучших решений по оптимизации производительности DB2-запросов и помочь оптимизатору DB2 улучшить доступ (например, собрать необходимую статистику и создать оптимальные индексы).

Терри Парселл, старший технический сотрудник, IBM

Терри Парселл – фотографияТерри Парселл (Terry Purcell), старший технический специалист лаборатории IBM Silicon Valley Lab, является ведущим проектировщиком DB2 for z/OS Optimizer. Терри имеет двадцатилетний опыт администрирования баз данных DB2 и разработки приложений в качестве заказчика, консультанта и разработчика DB2.



Кендрик Рен, программист-консультант, IBM

Кендрик Рен (Kendrick Ren) – фотографияКендрик Рен (Kendrick Ren) является техническим руководителем продуктов IBM Optim Query Tuner и Optim Query Workload Tuner в IBM Toronto lab. Он работал еще с первыми редакциями этих продуктов (тогда они назывались DB2 Optimization Expert и Optimization Service Center) с момента создания группы в 2004 году. Кендрик тесно сотрудничает с пользователями и бизнес-партнерами, использующими эти продукты, помогая им в области оптимизации запросов. До прихода в группу Optimization Expert Кендрик два года работал над продуктом IBM WebSphere Commerce Server.



Цзюнь Лю, программист-консультант, IBM

Цзюнь Лю (Jun Liu) – фотографияЦзюнь Лю (Jun Liu) является одним из технических руководителей разработки продуктов IBM Optim Query Tuner и Optim Query Workload Tuner в лаборатории IBM China Lab. Он пришел в группу в 2005 году и работал еще с предыдущими редакциями этих продуктов: DB2 Optimization Expert и Optimization Service Center. В настоящее время основное внимание уделяет разработке инструментов оптимизации индексов баз данных и настройки путей доступа SQL.



Кэвэй Вэй, программист-консультант, IBM

Кэвэй Вэй (Kewei Wei) – фотографияКэвэй Вэй (Kewei Wei) является техническим руководителем группы разработки и технической поддержки DB2 for z/OS L3 в Китае. Кэвэй работает над технологией оптимизации запросов DB2 for z/OS последние восемь лет и имеет богатый опыт настройки производительности DB2-приложений.



25.04.2013

Введение

Во второй части была представлена методология настройки отдельных запросов. Инструменты настройки запросов, такие как IBM InfoSphere Optim Query Workload Tuner (IOQWT), позволяют разработчикам приложений и администраторам баз данных анализировать пути доступа единичных запросов и повышать производительность за счет сбора дополнительной статистики, преобразования запросов или изменения схемы базы данных.

Цель настройки рабочей нагрузки – обеспечить соответствие приложения соглашению об уровне обслуживания и оптимальную общую стоимость владения (TCO) системой. В этой статье представлена методология настройки рабочей нагрузки при помощи IBM InfoSphere Optim Query Workload Tuner (IOQWT).


Сравнение настройки рабочей нагрузки с настройкой запросов

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

  1. Повышение производительности каждого запроса позволит снизить TCO и повысить шансы на соответствие требованиям к уровню обслуживания. Однако приложение может состоять из тысяч запросов, поэтому настройка каждого отдельного запроса вряд ли осуществима.
  2. Определение того, какая статистика пойдет на пользу отдельным запросам, и последующий сбор этой статистики может потребовать многократного повторения усилий. Для администратора базы данных консолидированная рекомендация RUNSTATS выгоднее многократного выполнения RUNSTATS.
  3. Настройка запросов может выявить необходимость дополнительных индексов или изменения существующих индексов. Изолированный анализ запросов не учитывает влияние изменений индексов на другие запросы и может привести к слишком большому количеству индексов, что скажется на обслуживании и управлении данными.
  4. Идентификация и сбор дополнительной статистики по отдельному запросу может привести к улучшению для одного запроса и разбалансировать другие. Поговорка "зла злом не поправишь" часто неверна в отношении клиентских рабочих нагрузок. Даже исправление одной ошибки оценки может вызвать другие ошибки в запросах, которые не были проанализированы.

Методология настройки рабочей нагрузки

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

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

Независимо от критерия общая методология настройки содержит по крайней мере четыре последовательных шага:

  1. Определение рабочей нагрузки для настройки.
  2. Настройка рабочей нагрузки.
  3. Рассмотрение рекомендаций и их применение.
  4. Проверка и сравнение исходного состояния и результата.

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


Сбор нагрузки для анализа

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

Многие пользователи выполняют сбор динамической SQL-нагрузки из кэша динамических операторов и статической SQL-нагрузки из каталога DB2. DB2 временно хранит динамические SQL-запросы в кэше динамических операторов, поэтому повторное выполнение одного и того же запроса не требует новой подготовки. Если DB2 находит в кэше идентичный экземпляр запроса, она не восстанавливает план выполнения запроса, а просто использует план, сохраненный в кэше. Можно включить трассировку кэша динамических операторов, чтобы DB2 сохраняла данные выполнения. Ниже приведен пример использования IOQWT.

Администратор баз данных запускает IOQWT и выбирает меню Start Tuning в Data Source Explorer (см. рисунок 1).

Рисунок 1. Запуск IOQWT для сбора и настройки нагрузки
Рисунок 1. Запуск IOQWT для сбора и настройки нагрузки

Открывается помощник Query Tuner Workflow Assistant, в котором можно запустить сбор SQL-запросов из многих источников, таких как Statement Cache (кэш операторов), Catalog Plan или Package, QMF и т.д. Следующий пример относится к кэшу операторов.

Рисунок 2. Сбор SQL-запросов из кэша операторов
Рисунок 2. Сбор SQL-запросов из кэша операторов

В приведенном выше примере демонстрируется приложение, выполняющееся на сервере WebSphere Application Server и использующее JDBC для подключения к DB2 9 for z/OS®. Предположим, пользователь хочет найти в системе все запросы, которые потребляют более 1 секунды процессорного времени, и проанализировать их. Сначала пользователь выбирает источник рабочей нагрузки (слева); в качестве источника выделен Statement Cache. Затем пользователь выбирает опцию Accumulated CPU. Это позволяет собрать все SQL-запросы с потребленным процессорным временем больше 1 секунды, и отсортировать результаты по процессорному времени. В примере используется ранее сохраненный фильтр, но при первом использовании нужно создать новый фильтр. Создание фильтра будет рассмотрено в следующем примере. На снимке экрана показано, что пользователь нажимает кнопку Enable Collection of Statistics непосредственно под фильтром, самым включая трассировку кэша динамических операторов. Затем пользователь нажимает кнопку Capture Now и в течение следующего часа собирает все выполненные операторы, для которых потребленное процессорное время превышает 1 секунду.

Рисунок 3. Собранные операторы в таблице
Рисунок 3. Собранные операторы в таблице

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

В другом примере администратор базы данных работает над проектом банковского приложения поддержки персональных электронных транзакций в Интернете. Администратор считает, что некоторые запросы в приложении выполняются неэффективно, а время отклика является неприемлемым. Используя другие инструменты мониторинга, администратор уже определил, что все эти запросы поступают от конкретного пользователя, а данные мониторинга показывают большое время ввода-вывода. Администратор задает фильтр с идентификатором Primary authority ID (PRIMAUTH), имеющим значение USER1, и средним количеством операций getpage (AVG_STAT_GPAG), превышающим значение, отображаемое в инструменте мониторинга, скажем, 10000. Результаты сортируются по среднему затрачиваемому времени, и пользователь может приступать к их анализу и настройке.

Рисунок 4. Задание условий фильтрации
Рисунок 4. Задание условий фильтрации
Рисунок 5. Выбор столбцов сортировки
Рисунок 5. Выбор столбцов сортировки

В приложении можно установить STMT_TOKEN, чтобы отличать в кэше динамических операторов только операторы данного конкретного приложения. В Java™ для установки STMT_TOKEN клиент может использовать программный интерфейс JDBC, например: ((DB2Connection) conn).setDB2ClientProgramId("Идентификатор вашего приложения");.

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


Сбор нагрузки в плане или пакете

Многие приложения используют статические SQL-запросы, хранящиеся в каталоге DB2. Поскольку статические SQL-запросы уже связаны, соответствующие пути доступа сгенерированы во время связывания и повторного связывания. При сборе SQL-выражений в плане или пакете результат может содержать SQL-текст и EXPLAIN-данные (если параметры связывания содержат EXPLAIN YES, DB2 будет хранить EXPLAIN-данные в PLAN_TABLE и других EXPLAIN-таблицах). Как и в случае кэша динамических операторов, IOQWT предоставляет удобные фильтры, помогающие пользователям собирать необходимые запросы статических пакетов.

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

Рисунок 6. Определение фильтра для сбора запросов в каталоге
Рисунок 6. Определение фильтра для сбора запросов в каталоге
Рисунок 7. Задание условий фильтрации
Рисунок 7. Задание условий фильтрации
Рисунок 8. Определение критериев схемы доступа
Рисунок 8. Определение критериев схемы доступа

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

Рисунок 9. Определение фильтра по объектам, на которые ссылаются пакеты
Рисунок 9. Определение фильтра по объектам, на которые ссылаются пакеты

Фильтр будет собирать все пакеты, зависящие от объектов, таких как таблицы, представления, хранимые процедуры и т.д. Будут извлечены все статические SQL-запросы этих пакетов, даже если они не связаны с объектом напрямую. Если пользователь хочет собирать только релевантные статические SQL-запросы, его пакеты должны быть связаны с помощью EXPLAIN YES, а фильтр нужно определить на другой странице, позволяющей выполнять фильтрацию по стоимости или объектам.

Рисунок 10. Определение фильтра по объектам, на которые ссылаются SQL-операторы
Рисунок 10. Определение фильтра по объектам, на которые ссылаются SQL-операторы

IOQWT просматривает EXPLAIN-данные всех статических SQL-запросов и извлекает SQL-запрос, если его план доступа содержит обращение к конкретной таблице.


Эффективная настройка рабочей нагрузки

Следующим шагом после сбора нагрузки является ее настройка. IOQWT предоставляет несколько советчиков по рабочей нагрузке, таких как советчик по статистике, советчик по индексам, советчик по запросам и советчик по путям доступа. На основании анализа SQL-операторов, EXPLAIN-данных и данных выполнения предоставляются рекомендации, базирующиеся на экспертных знаниях, встроенных в инструментальные средства. Например, советчик по статистике может предоставить рекомендации по сбору недостающих или противоречивых статистических данных, таких как кардинальность таблицы или кардинальность столбца, которые используются оптимизатором DB2 для создания эффективного плана доступа. Перед запуском советчиков по рабочей нагрузке необходимо убедиться в наличие EXPLAIN-данных. Часто, если нагрузка извлекается из кэша динамических операторов или плана/пакета без использования параметра связывания EXPLAIN YES, необходимо сначала предоставить информацию о нагрузке.

Следует отметить, что применение STMTCACHE EXPLAIN для запросов в кэше динамических операторов приведет к экстернализации существующей информации о плане доступа. Это означает, что EXPLAIN будет извлекать из кэша динамических операторов существующий план доступа. Применение EXPLAIN PLAN или EXPLAIN ALL для статического SQL-запроса приведет к генерированию нового плана доступа, который может не сохраняться в каталоге. В DB2 10 для Z/OS добавлен оператор EXPLAIN PACKAGE, который извлекает имеющуюся информацию о плане доступа, если пакет был создан на DB2 версии 9 или старше. При любом подходе будет заполняться таблица PLAN_TABLE для последующего анализа пути доступа.

Рисунок 11. Параметры EXPLAIN для эффективного хранения EXPLAIN-данных
Рисунок 11. Параметры EXPLAIN для эффективного хранения EXPLAIN-данных

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

Перед запуском советчиков нужно обратить внимание на последовательность, в которой они будут выполняться. В большинстве случаев советчик по статистике должен выполняться в первую очередь, чтобы обеспечить оптимизатору DB2 достаточно информации для выбора плана доступа. Причиной почти половины, если не больше, проблем производительности SQL-запросов является неполная статистика. Вторым рекомендуется выполнить советчик по запросам, потому что изменение запроса, особенно изменение предиката, может существенно повлиять на выбор индекса и варианты, доступные для оптимизатора. Например, если на втором этапе заменить предикат индексируемым предикатом, он сможет использовать существующий индекс. Оставшиеся два советчика можно выполнять после советчиков по статистике и запросам. Тем не менее выполнение советчиков может представлять собой итеративный процесс, так как создание нового индекса может потребовать повторного выполнения советчика по статистике для выявления и сбора недостающей статистики по индексам. В противном случае из-за отсутствия статистики DB2 может иметь неправильную информацию о новом индексе. Типичный пример: отсутствие коэффициента кластеризации для индекса может привести к неправильной оценке стоимости случайных операций ввода/вывода на страницах данных по индексу.

Ниже приведен пример сбора рабочей нагрузки для настройки. Пользователь извлекает SQL-операторы приложения из кэша динамических операторов и нажимает кнопку Save All to Workload для создания рабочей нагрузки.

Рисунок 12. Рабочая нагрузка с высокозатратными операторами
Рисунок 12. Рабочая нагрузка с высокозатратными операторами

Второй шаг – получение информации о рабочей нагрузке и вызов советчика по статистике.

Рисунок 13. Рекомендации советчика по статистике
Рисунок 13. Рекомендации советчика по статистике

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

Рисунок 14. Подробный отчет советчика по статистике
Рисунок 14. Подробный отчет советчика по статистике

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

Третьим шагом является сбор статистики в подходящее время с учетом других работ в системе. После сбора статистики пользователь еще раз выполняет действия первого шага для проверки возможных улучшений. На приведенном ниже снимке экране нагрузка DW3_B собрана до применения рекомендаций советчика по статистике, а нагрузка DW3_Sn собрана после выполнения RUNSTATS. Мы видим, что затрачиваемое время уменьшилось с 471.20 до 383.40 секунд, а процессорное – с 127.21 до 93.17 секунд.

Рисунок 15. Сравнение результатов настройки при помощи советчика по статистике
Рисунок 15. Сравнение результатов настройки при помощи советчика по статистике

Четвертый шаг – повторное получение информации о рабочей нагрузке и запуск советчика по индексам для получения рекомендаций.

Рисунок 16. Рекомендации советчика по индексам
Рисунок 16. Рекомендации советчика по индексам

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

Рисунок 17. Детали рекомендации
Рисунок 17. Детали рекомендации

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

Рисунок 18. Выбор рекомендаций согласно важности таблиц
Рисунок 18. Выбор рекомендаций согласно важности таблиц

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

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

Рисунок 19. Сбор статистики для только что добавленных индексов
Рисунок 19. Сбор статистики для только что добавленных индексов

На последнем шаге выполняется проверка повышения производительности. Приведенные ниже свежесобранные данные выполнения показывают, что после создания новых индексов производительность значительно повысилась.

Рисунок 20. Сравнение результатов после использования советчика по индексам
Рисунок 20. Сравнение результатов после использования советчика по индексам

Нагрузка, собранная после создания всех рекомендуемых индексов и сбора статистики для новых индексов, обозначена DW3_In. Затрачиваемое время уменьшилось с 383.40 до 8.99 секунд, а процессорное время – с 93.17 до 8.13 секунд.


Стабильность пути доступа

Одной из самых больших проблем для администратора баз данных является управление путями доступа тысяч запросов для поддержания стабильной производительности приложения. Регрессия путей доступа является одной из наиболее распространенных причин снижения производительности приложений. Существуют различные причины изменения путей доступа:

  • Переход на новую версию DB2 или развертывание новой системы обслуживания.
  • Обновления статистики для отражения изменений в данных.
  • Замена оборудования.
  • Изменения параметров системы.
  • Изменение физической структуры базы данных.

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

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

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

В DB2 for z/OS версий 9 и 10 имеется множество полезных функций для стабилизации путей доступа при выполнении BIND и REBIND. В DB2 9 for Z/OS есть функция управления базовым планом, позволяющая выполнять резервное копирование и восстановление (переключение) статических путей доступа при выполнении REBIND. В нее была добавлена поддержка повторного использования предварительного плана при выполнении BIND/REBIND с параметром APREUSE.

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


Сравнение путей доступа

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

Сравнение путей доступа на уровне пакета до и после REBIND

Для уменьшения опасности снижения производительности после REBIND предлагается выполнить оценку рисков до REBIND. Для выполнения оценки:

  • Сохраните информацию о текущих путях доступа интересующих вас пакетов в EXPLAIN-таблицах.
  • Выполните BIND интересующих вас пакетов под другим идентификатором коллекции и сохраните новую информацию о путях доступа в EXPLAIN-таблицы.
  • Сравните текущие пути доступа и пути доступа, порожденные новой операцией BIND, и определите изменения путей доступа.
  • Выполните анализ изменений путей доступа и настройку путей доступа, для которых выявлена регрессия.

В последующих разделах приведен пример, демонстрирующий процесс сравнения пути доступа для пакета OQTPACK4. OQTPACK4 представляет собой пакет из пяти запросов, связанных под идентификатором коллекции PROD.

Сохранение информации о путях доступа

Рекомендуется указывать EXPLAIN (YES) для операций BIND/REBIND, что позволит сохранять информацию о путях доступа в EXPLAIN-таблицы. В DB2 10 for z/OS можно выполнить оператор EXPLAIN PACKAGE, чтобы извлечь PLAN_TABLE, если изначально эта информация не была сохранена при помощи EXPLAIN (YES). Однако пакет должен быть связан в DB2 for Z/OS версий 9 или 10, и сохраняется только информация PLAN_TABLE, а не другие данные EXPLAIN-таблиц.

Например, информацию о пути доступа можно сохранить при помощи следующего оператора: EXPLAIN PACKAGE COLLECTION PROD PACKAGE OQTPACK4.

Информацию о пути доступа после выполнения REBIND можно получить путем связывания пакета под другим идентификатором коллекции. Например, можно связать пакет под идентификатором коллекции TEST: BIND PACKAGE(TEST.OQTPACK4) MEMEBER(OQTPROG4).

Сравнение путей доступа между идентификаторами коллекции

IOQWT предоставляет функцию сравнения информации о путях доступа на уровне пакетов. Эту функцию можно запустить из проекта настройки рабочей нагрузки.

Рисунок 21. Запуск сравнения рабочей нагрузки в IOQWT
Рисунок 21. Запуск сравнения рабочей нагрузки в IOQWT

IOQWT создаст рабочую нагрузку для сравнения.

Рисунок 22. Создание рабочей нагрузки для сравнения
Рисунок 22. Создание рабочей нагрузки для сравнения

На основании исходного и целевого идентификаторов коллекции IOQWT сгенерирует отчет о результате сравнения путей доступа.

Рисунок 23. Просмотр результатов сравнения
Рисунок 23. Просмотр результатов сравнения

В отчете будут выделены запросы с изменениями путей доступа или предполагаемых издержек. Изменения путей доступа нужно обязательно проанализировать, даже если отчет показывает, что издержки пути доступа в результате нового REBIND ниже, чем прежние, потому что издержки нового пути доступа могут быть вычислены на основе неточной статистики. В IOWQT можно выполнить детальную проверку пути доступа запроса.

Рисунок 24. Детальное сравнение плана доступа
Рисунок 24. Детальное сравнение плана доступа

Если нерассмотренные изменения путей доступа отсутствуют, можно спокойно выполнять REBIND для коллекции PROD. Если выявлена регрессия пути доступа, можно выполнить индивидуальные настройки запроса или блокировать/восстановить запрос при помощи функции управления планами. Информация о предотвращении регрессии путей доступа приведена в разделах "Блокировка путей доступа при помощи управления планами в DB2 10" и "Восстановление при помощи классического управления планами в DB2 9".


Сравнение путей доступа рабочей нагрузки

Подготовка к сравнению путей доступа для динамических запросов сложнее, чем для статических запросов на уровне пакетов, так как пути доступа динамических запросов не хранятся в каталоге DB2. Для подготовки к сравнению путей доступа динамических запросов выполните следующие действия:

  1. Создайте рабочую нагрузку для динамических запросов.
  2. Выполните EXPLAIN для рабочей нагрузки до осуществления каких-либо действий (запуск RUNSTATS, создание новых индексов, применение PTF и т.д.), которые могут вызвать изменение пути доступа.
  3. После действий, которые могут вызвать изменение пути доступа, снова выполните EXPLAIN для рабочей нагрузки.
  4. Сравните последние пути доступа этой нагрузки с предыдущими.
  5. Выполните анализ изменений путей доступа и настройку путей доступа, для которых выявлена регрессия.

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

Рисунок 25. Сравнение EXPLAIN-снимков
Рисунок 25. Сравнение EXPLAIN-снимков

Функции управления планами в DB2 for z/OS, которые будут рассмотрены далее, не применимы к динамическим запросам. Поэтому, возрастает вероятность того, что для борьбы с регрессией динамических запросов потребуется настройка отдельных запросов или использование советов по оптимизации для блокировки их путей доступа.


Блокировка путей доступа при помощи управления планами в DB2 10

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

DB2 10 for z/OS предлагает новый параметр APREUSE для REBIND (и BIND). Применяя параметр APREUSE (ERROR), вы подтверждаете REBIND только в случае, если все пути доступа пакета можно использовать повторно. Это наиболее осторожный подход к изменению путей доступа при использовании REBIND. Например, если необходимо использовать пути доступа из предыдущего связывания, можно выполнить повторное связывание пакета PROD.OQTPACK4 следующим образом: REBIND PACKAGE(PROD.OQTPACK4) APREUSE(ERROR).

Следует отметить, что, снижая риск регрессии путей доступа, APREUSE в то же самое время ограничивает возможности улучшения путей доступа. Тем не менее это реалистичный подход в ситуациях, когда заказчик готов рассматривать возможности улучшения путей доступа. Рассмотреть эти возможности можно во время профилактического анализа.

Если последнее связывание пакета выполнялось в DB2 9, APREUSE можно использовать только при первом выполнении BIND/REBIND в DB2 10. После первого выполнения BIND/REBIND в DB2 10 можно использовать APREUSE при последующих выполнениях.


Восстановление при помощи классического управления планами в DB2 9

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

Чтобы восстановление при помощи управления планами стало возможным, необходимо либо указать параметры связывания PLANMGMT(BASIC) или PLANMGMT(Extended), либо установить ZPARM PLANMGMT в значения BASIC или EXTENDED. В DB2 9 PLANMGMT по умолчанию имеет значение OFF, а в DB2 10 – EXTENDED. Например, если предыдущее выполнение BIND/REBIND осуществлялось с использованием PLANMGMT=BASIC, восстановить структуры предыдущего выполнения можно при помощи следующей команды REBIND: REBIND PACKAGE(PROD.OQTPACK4) SWITCH(PREVIOUS).

Эта возможность переключения управления планами доступна при переходе с DB2 8 на DB2 9, с DB2 8 на DB2 10 и с DB2 9 на DB2 10.


Заключение

В статье были рассмотрены преимущества настройки рабочей нагрузки, а также использование IBM InfoSphere Optim Query Workload Tuner в качестве неотъемлемой части усилий, направленных на упрощение и автоматизацию шагов по увеличению общей стоимости владения приложениями.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=900592
ArticleTitle=Настройка SQL-запросов при помощи Optim Query Tuner: Часть 3. Cбор и настройка рабочей нагрузки
publish-date=04252013