Простейший способ ввода и сохранения данных о производительности DB2

Использование механизма мониторинга с помощью утилит DB2

Вы когда-нибудь задумывались о том, как можно легко собрать данные о производительности своей системы DB2 без помощи дополнительных инструментов? Эта статья учит использовать новый механизм мониторинга из версии V10.1 DB2 для Linux, UNIX и Windows (первоначально предложенный в версии 9.7). В ней также объясняется, как скомбинировать утилиты DB2 для выбора, ввода и хранения данных и использовать их для анализа с помощью простых SQL-запросов или инструментов бизнес-анализа.

Гвидо Вербрак, консультант Software Group Lab Services, IBM

Фото Гвидо ВербракаГвидо Вербрак (Guido Verbraak) работает с DB2, начиная с 2003 года. Он помогает клиентам получить максимальную отдачу от их установок DB2 в качестве консультанта подразделения Software Group Lab Services в странах Бенилюкса. Занимается главным образом DB2 на платформах Linux, UNIX и Windows, но знаком и с DB2 для z/OS. Его повседневная работа связана с решением вопросов по обеспечению высокой готовности, резервному копированию/восстановлению и производительности во всевозможных ситуациях, с которыми сталкиваются пользователи DB2. До прихода группу программного обеспечения он управлял большой системой хранилища данных на базе DB2 для z/OS и накопил богатый опыт в области создания масштабируемых, высокопроизводительных хранилищ данных.



07.05.2013

Введение

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

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

Следующие инструкции показывают, как построить базу данных производительности. Примеры составлены с помощью DB2 V10.1 для Linux, UNIX и Windows. Поскольку механизм мониторинга появился в DB2 9.7, можно использовать и эту версию DB2. Механизм мониторинга входит во все редакции DB2.


Сбор данных о производительности и их сохранение

Чтобы собрать и сохранить данные о производительности, нужно:

  1. Определить, какие данные требуется собрать в базе данных производительности и за какой промежуток времени.
  2. Создать базу данных для сбора этой информации.
  3. Настроить механизм для сбора данных о производительности и их записи в базу данных.

Какие данные вводить и за какой период времени

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

Листинг 1. Команда для распечатки списка таблиц
list tables for schema SYSIBMADM

Рисунок 1 иллюстрирует выходные данные команды распечатки списка таблиц: имя таблицы или представления, имя схемы, тип (T-таблица, V-представление) и время создания.

Рисунок 1. Команда для распечатки списка таблиц
Команда для распечатки списка таблиц Она возвращает список всех таблиц и представлений, относящихся к схеме SYSIBMADM

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

  • функции мониторинга, ориентированные на различные объекты базы данных и компоненты DB2. Их имена начинаются с mon_get;
  • табличные функции, ориентированные на WorkLoad Management(WLM). Эти табличные функции дают представление о том, как работает DB2 с точки зрения WLM. Все их имена начинаются с wlm_get;
  • функции, имена которых начинаются с admin_get, предоставляют информацию, которую можно использовать в установке типа системы администрирования базы данных (например, если нужно контролировать размеры таблиц или потребление памяти).

Полный список всех доступных табличных функций и административных представлений приведен в Информационном центре DB2 9.7 для Linux, UNIX и Windows (см. раздел Ресурсы).

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

Листинг 2. Запрос доступных табличных функций
select funcname from syscat.functions where funcname like 'MON_GET%' \n
or funcname like 'WLM_GET%' or funcname like 'ADMIN_GET%'

Пример списка доступных табличных функций приведен на рисунке 2.

Рисунок 2. Запрос доступных табличных функций
Запрос доступных табличных функций

Информационный центр DB2 содержит всю необходимую информацию о выходных данных табличных функций (см. раздел Ресурсы).

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

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

Листинг 3. Пример запроса
SELECT
current_timestamp,
tabschema,
tabname,
table_scans
FROM TABLE(MON_GET_TABLE('','',-2)) AS t

Табличная функция MON_GET_TABLE имеет три входных параметра. Первый ― это схема таблицы, второй — имя таблицы, а третий параметр позволяет указать, из какого члена базы данных DPF (database partition feature) требуется собирать данные.

Этот пример позволяет охватить все обращения ко всем таблицам для всех схем всех членов базы данных. Вот почему первые два параметра пусты (' '), а последний равен -2, что соответствует всем членам.

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


Определение интервала сбора данных

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

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

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


Настройка базы данных производительности

Существует несколько способов настройки базы данных производительности. Наиболее важный вопрос — местоположение данных.

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

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

Первый шаг ― создание базы данных производительности в нужном экземпляре и подключение к ней. Можно использовать параметры по умолчанию для базы данных PERFDB, показанные в листинге 4.

Листинг 4. Создание базы данных и подключение
create db perfdb

connect to perfdb

На рисунке 3 приведен пример оператора создания БД и последующего оператора connect.

Рисунок 3. Создание базы данных и подключение
Создание базы данных и подключение

Следующий шаг — создание таблицы TABLESCANS, содержащей собранные данные. DB2 создает таблицу на основе запроса с использованием одних и тех же типов данных. После создания таблицы можно подать команду describe table для проверки ее определения.

Листинг 5. Запрос для создания таблицы для хранения данных
create table tablescans as
describe table tablescans
(SELECT
current_timestamp as current_timestamp,
tabschema,
tabname,
table_scans
FROM TABLE(MON_GET_TABLE('','',-2)) AS t) with no data

Пример оператора создания таблицы приведен на рисунке 4 (см. увеличенное изображение).

Рисунок 4. Создание таблицы для хранения данных
Создание таблицы для хранения данных

Настройка механизма сбора и передачи нужных данных

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

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

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

  1. Подключение к целевой базе данных.
  2. Объявление курсора с помощью оператора select.
  3. Вызов утилиты load для фактической загрузки данных в целевую таблицу.
  4. Отключение.

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

Листинг 6. Запрос для создания сценария загрузки, объявляющего курсор
CONNECT to PERFDB;

DECLARE C1 CURSOR database sample user <userid> using <password> FOR
SELECT
current_timestamp,
tabschema,
tabname,
table_scans
FROM TABLE(MON_GET_TABLE('','',-2)) AS t;

LOAD FROM "C1" of cursor
MESSAGES "C:\temp\msg.txt" 
TEMPFILES PATH "C:\temp" 
INSERT INTO TABLESCANS
(current_timestamp,
tabschema,
tabname,
table_scans) 
NONRECOVERABLE 
INDEXING MODE AUTOSELECT;

CONNECT RESET;

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

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

Листинг 7. Выполнение сценария загрузки
 db2 -tvf loadcursor.sql

Результат демонстрирует выполненный оператор утилиты load, включая некоторую статистику по количеству загруженных строк (см. увеличенное изображение).

Рисунок 5. Выполнение созданного сценария загрузки
Выполнение сценария загрузки

Предыдущие примеры были разработаны на платформе Windows, но их можно легко использовать и на платформах Linux и UNIX.

Нужно иметь в виду несколько особенностей.

  • Большинство измерений в механизме мониторинга носят накопительный характер. Чтобы узнать приращения значений между двумя измерениями, необходимо вычесть одно из другого.
  • Ключи «старого» монитора, работавшего на уровне экземпляра, не оказывают влияния на сбор данных в рамках «нового» механизма, который работает на уровне базы данных.
  • В этой статье приводится лишь простой пример. Ничто не мешает читателю объединить нескольких табличных функций в один запрос и извлекать эти данные.

Практические советы

Если планируется собирать много данных в целях управления производительностью системы DB2, то, вероятно, более экономически эффективным и простым в применении решением будет Optim Performance Manager (OPM). OPM включен в состав DB2 Advanced Enterprise Server Edition (AESE) и продается как отдельный продукт. Это всеобъемлющее и упреждающее решение для мониторинга в режиме реального времени и хранения данных о производительности DB2 и InfoSphere Warehouse для Linux, UNIX и Windows. Дополнительную информацию можно найти по ссылкам, приведенным в разделе Ресурсы.

Для настройки запросов, целых задач и для создания отчетов по собранным данным можно использовать информацию, полученную с помощью других продуктов, таких как Optim Query Workload Tuner, Optim Query Tuner или Cognos BI. Например, можно собрать данные о топ-10 выполненных запросов в своей среде за определенный период времени и ввести их в качестве входных данных для решения задач настройки в Optim Query Workload Tuner.


Заключение

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

Ресурсы

Комментарии

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=928940
ArticleTitle=Простейший способ ввода и сохранения данных о производительности DB2
publish-date=05072013