- Збір даних про продуктивність і їх збереження
- Які дані вводити і за який період часу
- Лістинг 1. Команда для роздруківки списку таблиць
- Малюнок 1. Команда для роздруківки списку таблиць
- Лістинг 2. Запит доступних табличних функцій
- Малюнок 2. Запит доступних табличних функцій
- Лістинг 3. Приклад запиту
- Визначення інтервалу збору даних
- Налаштування бази даних продуктивності
- Лістинг 4. Створення бази даних і підключення
- Малюнок 3. Створення бази даних і підключення
- Лістинг 5. Запит для створення таблиці для зберігання даних
- Малюнок 4. Створення таблиці для зберігання даних
- Лістинг 6. Запит для створення сценарію завантаження, який оголошує курсор
- Лістинг 7. Виконання сценарію завантаження
- Малюнок 5. Виконання створеного сценарію завантаження
- практичні поради
- висновок
- Ресурси для скачування
Використання механізму моніторингу за допомогою утиліт DB2
Традиційно параметри продуктивності отримують за допомогою знімків поточного стану. Ці знімки дають багато інформації, але не дуже добре підходять для збору історичних даних. Щоб зібрати історичні дані, доводиться відкидати багато непотрібних знань. До того ж для того щоб витягти дані з моментального знімка і зберегти їх, потрібно написати об'ємний сценарій.
У версії DB2 9.7 з'явився новий механізм моніторингу. Він працює на рівні бази даних, а його SQL-інтерфейс дозволяє отримати від DB2 в точності те, що потрібно. Для початку потрібні лише деякі початкові знання в області SQL і готові функції DB2.
Наступні інструкції показують, як побудувати базу даних продуктивності. Приклади складені за допомогою DB2 V10.1 для Linux, UNIX та Windows. Оскільки механізм моніторингу з'явився в DB2 9.7, можна використовувати і цю версію DB2. Механізм моніторингу входить в усі редакції DB2.
Збір даних про продуктивність і їх збереження
Щоб зібрати і зберегти дані про продуктивність, потрібно:
- Визначити, які дані потрібно зібрати в базі даних продуктивності і за який проміжок часу.
- Створити базу даних для збору цієї інформації.
- Налаштувати механізм для збору даних про продуктивність і їх записи в базу даних.
Які дані вводити і за який період часу
Існує кілька способів збору даних про продуктивність DB2 з використанням нового механізму моніторингу. Один з них полягає у використанні уявлень, розташованих в схемі SYSIBMADM. Ці уявлення готові до застосування за допомогою SQL і побудовані шляхом об'єднання результатів однієї або більше табличних функцій. Відомості про доступні уявленнях можна отримати, використовуючи наступний запит до бази даних.
Лістинг 1. Команда для роздруківки списку таблиць
list tables for schema SYSIBMADM
Малюнок 1 ілюструє вихідні дані команди роздруківки списку таблиць: ім'я таблиці або подання, ім'я схеми, тип (T-таблиця, V-уявлення) і час створення.
Малюнок 1. Команда для роздруківки списку таблиць
Інша можливість - використання табличних функцій, які є в 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. Це завдання можна розбити на чотири етапи:
- Підключення до цільової базі даних.
- Оголошення курсору за допомогою оператора select.
- Виклик утиліти load для фактичного завантаження даних в цільову таблицю.
- Відключення.
Запит, наведений у лістингу 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 з використанням табличних функцій. Потім ми завантажили отримані дані в окрему базу даних, яку можна використовуватися для цілей аналізу чи в якості джерела інформації для інших інструментів управління продуктивністю або звітності.
Ресурси для скачування
Схожі теми
Підпишіть мене на повідомлення до коментарів
<
