Технология Клиент-Сервер 2002'4
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

SMART и DB2

СУБД должна быть в обращении такой же, как холодильник – включил и забыл. Это, возможно, слишком смелое заявление, но именно такую цель преследует IBM-овский проект SMART, призванный снизить стоимость администрирования DB2.

Интересно, что, несмотря на то, что цены на железо падают, а его производительность растет в полном соответствии с законом Мура, TCO (total cost of ownership, полная стоимость владения) остается на прежнем уровне. Дело в том, что квалифицированный администратор БД (АБД) обходится все дороже – их не становится больше, а спрос растет. В 1998 году исследование Aberdeen Group показало, что при пятилетней эксплуатации 25-пользовательской системы 81% TCO приходится на содержание обслуживающего персонала.

Рост функциональности СУБД увеличивает нагрузку на АБД. В последнее время выросшие возможности железа привели к появлению хранилищ данных в десятки терабайт. Популярные приложения типа SAP создают тысячи таблиц и поддерживают одновременную работу тысяч пользователей. Разработчики систем бьются со сложными комбинациями аппаратных платформ, дизайном схемы, ограничениями и ссылочной целостностью, первичными ключами и индексами, материализованными представлениями, размещением таблиц на дисках, shared-nothing, shared-everything, или SMP-кластерной топологией. АБД должен управлять реорганизацией таблиц, сбором статистики, резервным копированием, моделью безопасности, планами восстановления, настройкой производительности и конфигурированием. Собственно администрирование БД с него тоже никто не снимал.

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

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

В IBM сейчас ведется целый ряд проектов автономных вычислений. SMART – один из них. Аналогичные разработки ведутся для WebSphere. IBM завела даже вице-президента по автономным вычислительным системам (им стал Алан Ганек (Alan Ganek)).

Проект DB2 SMART должен породить технологию снижения человеческого участия в управлении работой DB2, и, соответственно, ТСО этой СУБД. Результатом должна стать DB2, способная:

• Динамически изменять любой параметр конфигурации в процессе работы системы.

• Уменьшать и увеличивать потребление памяти в зависимости от нагрузки.

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

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

• Отслеживать реальную производительность системы и использовать эту информацию для увеличения производительности.

• Предлагать набор действий, если производительность не соответствует ожиданиям АБД.

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

Приведет ли это к избавлению от АБД? Нет. Но это избавит АБД от рутинной работы. Сейчас АБД часто похож на пожарника – он либо пытается не допустить краха системы, либо устранить (ну, хотя бы минимизировать) последствия этого краха. На то, чтобы разобраться в сути проблемы, времени уже не хватает. Новая система должна дать АБД такую возможность, предлагая действия и самостоятельно выполняя их после подтверждения от АБД. В конце концов, АБД сможет позволить DB2 действовать самостоятельно в большинстве случаев, просто докладывая о предпринятых действиях.

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

В проекте задействованы сразу два исследовательских центра IBM, две лаборатории разработчиков и IBM Center for Advanced Studies.

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

Query Optimizer. DB2 Query Optimizer автоматически определяет лучший способ выполнения декларативного SQL-запроса. Он использует комбинацию правил переписывания (query rewrite) запроса и детализированной модели стоимости, создавая и оценивая набор альтернативных планов исполнения запроса. Оптимизатор автоматически определяет, существуют ли материализованные представления, использование которых может снизить стоимость запроса. Если они есть, оптимизатор направляет запрос к МП. Оптимизатор использует статистику по размерам каждой таблицы и распределению колонок, моделируя, сколько строк должно быть обработано любым запросом, который может выдумать пользователь. Он даже подгоняет модель стоимости под конкретную машину, на которой запущен, автоматически определяя скорость работы CPU, устройств хранения данных и сети, связывающей кластер (в среде shared-nothing) или сайты (в federated-средах).

Query Optimizer в DB2 для Linux, Unix и Windows даже содержит мета-оптимизатор, использующий правила эвристики для определения того, что запроса избыточно сложен для перечисления возможных комбинаций порядка объединения таблиц с использованием динамического программирования. Если такое случается, оптимизатор выбирает самые дешевые объединения для каждой итерации по "жадному" алгоритму, экономя время и место.

Автоматический выбор степени параллелизма. На многопроцессорных платформах оптимизация запросов включает автоматическую установку и изменение степени параллелизма запросов и утилит. Для любого запроса анализируется, как производится доступ к таблицам, и где могут возникнуть узкие места. После этого выбирается нужный уровень распараллеливания запроса. Определение оптимального уровня параллелизма для каждого запроса устраняет необходимость сложного распределения нагрузки (load balancing) при компиляции.

Утилиты загрузки данных используют распараллеливание для опережающего чтения, форматирования и записи на диск. На основании характеристик таблиц и числа доступных CPU утилиты автоматически определяют объем памяти, необходимый для буферизации, сортировки и числа субагентов, нужных для достижения оптимального параллелизма I/O и SMP.

Настройка приложений и управление ими. Наиболее важные стороны управления приложениями – управление использованием ресурсов. DB2 содержит ряд механизмов управления потреблением ресурсов как запускаемыми, так и уже работающими приложениями. Первый из них называется "предсказывающим регулятором" (predictive governor), поскольку использует производимые Query Optimizer вычисления ожидаемого количества ресурсов, потребляемых каждым запросом. Он должен сглаживать скачки нагрузки, возникающие при поступлении "долгоиграющих" запросов, способных создать избыточную нагрузку на сервер. Второй тип – реагирующий регулятор (reactive governor), отслеживающий реальное потребление ресурсов и предотвращающий их потерю. Например, он отслеживает запросы, исполняющиеся слишком долго, читающие или изменяющие слишком много страниц, или производящие слишком много блокировок, не делая COMMIT. Совместная работа обоих регуляторов эффективно защищает систему от неудачных приложений, мешающих нормальной работе.

На платформе z/OS Resource Limit Facility (RLF) содержит как предсказывающий, так и реагирующий регулятор. z/OS Workload Manager также занимается балансировкой входящей нагрузки через Parallel Sysplex, предлагая приложениям, подключающимся к DB2, работать с наименее загруженным экземпляром.

На платформах Linux, Unix и Windows DB2 Query Patroller содержит предсказывающий регулятор. Реагирующий регулятор называется просто "Governor." Query Patroller использует сведения о текущей загрузке системы и расчеты оптимизатора для каждого входящего запроса для расстановки приоритетов и графика исполнения. Завершение выполнения запроса может вызывать автоматическое оповещение пользователя. Governor управляется конфигурационным файлом, содержащим правила использования ресурсов приложениями и пользователями. Возможное действие правила включает уменьшение или увеличение приоритета приложения, или даже его закрытие.

Performance Expert. Новое средство, DB2 Performance Expert, дает возможность мониторинга производительности и сохранения полученных данных в специальном хранилище. Данные из этого хранилища доступны АБД. Buffer Pool Analyzer (анализатор пула буферов), другой компонент Performance Expert, собирает данные об активности пула буферов и моделирует изменения объектов в этом пулем (включая их размер), что позволяет АБД видеть эффект тех или иных действий, не производя реальных изменений системы.

Некоторые возможности пока существуют только в вариантах для отдельных платформ.

Index Wizard. DB2 Index Wizard, появившийся еще в 6 версии в 1999 году, помогает при разработке БД, рекомендуя создание индексов таблиц на основе нагрузки, создаваемой одним или несколькими SQL-запросами (включающих INSERT, UPDATE и DELETE). Такие данные могут быть собраны автоматически или представлены пользователем. Index Wizard использует детализированную модель производительности Query Optimizer, и предлагает наиболее вероятных кандидатов на индексирование. Использование кода Query Optimizer само по себе снижает потребность в поддержке избыточного внешнего кода и обеспечивает выбор оптимизатором именно рекомендованных индексов. Index Wizard – это утилита, запускаемая как клиентское приложение, и использующая компилятор DB2 в двух новых режимах EXPLAIN: RECOMMEND INDEXES и EVALUATE INDEXES. В режиме RECOMMEND INDEXES оптимизатор создает описания "виртуальных индексов" для различных комбинаций колонок, которые могут применять предикаты, создавать "интересные" порядки (для ORDER BY, GROUP BY или join-ов), или предоставлять данному запросу доступ "index-only". Затем по этим виртуальным индексом собирается статистика, пропускаемая через обычный процесс оптимизации запроса. Это позволяет выбрать лучший план исполнения с использованием как реальных, так и виртуальных индексов

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

Index Wizard работает под z/OS с БД, расположенными на z/OS, Linux, Unix и Windows-системах.

Service Utility (db2support). Для упрощения процесса сбора данных и определения проблем при обращениях в службы технической поддержки, в DB2 имеется утилита под названием "db2support", автоматически определяющая, какая диагностическая информация понадобится IBM Service. Разобравшись, что к чему, она собирает информацию и упаковывает ее в один zip-файл. Результат работы содержит характеристики аппаратного обеспечения (CPU, спецификации сети и устройств хранения данных), сведения об ОС и СУБД, а также ряд диагностических файлов. Описание системы хранится в HTML-формате для удобства просмотра. Кроме этого, db2support может работать в интерактивном режиме, проводя пользователя по дереву решений (decision tree), содержащему сценарии для различных проблем. Результат этой беседы сохраняется в XML-файле.

Performance Configuration Wizard автоматически определяет лучшие значения для 35 параметров конфигурации, критичных для производительности системы, включая размещение системной памяти для основных операций с БД (кэширования, сортировки, сетевых операций), а также таких параметров, как число операционных агентов БД и субагентов I/O. Для этого определяются значения параметров конфигурации СУБД (объем RAM, число дисков и CPU) и характеристики нагрузки, получаемые от пользователя. Задаваемые вопросы, рассчитаны на неподготовленного пользователя. Performance Configuration Wizard выводит значение каждого параметра конфигурации как взвешенную функцию каждой из системных характеристик. Однако выделение памяти требует большего внимания. Эти параметры определяются с помощью комбинированной модели, принимающей во внимание ограничения, вытекающие из архитектуры БД и объема доступной системной памяти.

Работать с этим визардом можно как через GUI, так и через API. Сейчас уже многие коммерческие приложения, использующие DB2 в качестве РСУБД, обращаются к Performance Configuration Wizard.

Recovery Expert. Объявленный в середине этого года DB2 Recovery Expert объединяет анализ и фильтрацию логов и репозитарий версий определений объектов, позволяя пользователю указать цели процесса восстановления. Это средство анализирует доступные средства восстановления и подсказывает, чем воспользоваться. Например, нужно восстановить набор таблиц до состояния, имевшегося пять минут назад. Recovery Expert может посоветовать анализировать лог, чтобы сгенерировать восстанавливающий состояние UNDO SQL.

Maintenance Advisor. Это кросс-платформное средство, проверяющее статистику DB2 и дающее рекомендации по запуски тех или иных средств поддержки. Оно может создавать скрипты или JCL, и выполнять задачи по расписанию. Работа с Maintenance Advisor возможна как через графический интерфейс, так и из командной строки, а также программно, через API.

Configuration Advisor. Performance Configuration Wizard претерпел существенное преображение и перевоплотился в Configuration Advisor. Недавние эксперименты с новыми алгоритмами дали хорошие результаты, особенно для OLTP-систем. Рисунок 1 показывает результаты двух опытов, в которых использовался стандартный OLTP-тест производительности. Эксперименты производились при двух уровнях нагрузки на СУБД. Для каждого из уровней нагрузки измерялась пропускная способность системы с настройками по умолчанию, с настройками, рекомендованными новым Configuration Advisor, и настройками, выставленными человеком-экспертом, имевшим несколько дней на отладку конфигурации. В обоих случаях Configuration Advisor значительно поднял производительность системы. Как ни удивительно, Configuration Advisor добился 91.3% производительности системы, настроенной экспертом в первом случае, и 98.4% – во втором.

Рисунок 1. Сравнение производительности систем, настроенных Configuration Advisor, с настроенными по умолчанию и настроенными АБД-экспертом.

В самом начале проекта SMART опрос АБД выявил, что общей проблемой является сложность выяснения, исправно ли работает DB2, и поиск подходящего лекарства, если это не так. В ответ было создано средство Health Monitor, состоящее из постоянно работающего агента, отслеживающего состояние движка СУБД, и нескольких средств, отслеживающих состояние системы и выдающих рекомендации по исправлению проблемных ситуаций. Health Monitor ищет симптомы болезни и, в случае обнаружения таковых, сигнализирует через e-mail или пейджер, или просто делает запись в логе. Он также может запускать корректирующие скрипты и другие задачи в случае появления неблагоприятных признаков. АБД отслеживает состояние системы, просматривает записи в логе и дает разрешение на выполнение рекомендуемых действий через Health Center, GUI-приложение, работающее как в локальном варианте, так и через Web.

Эти нововведения – только начало внедрения автономной технологии, которая должна полностью изменить DB2 в течение нескольких следующих релизов этой СУБД. Появятся не только инструменты автоматизации рутинных задач АБД, но и более интеллектуальные средства, переносящие DB2 на следующий уровень автоматизации и самоуправления. Мы не можем привести здесь полное описание ведущихся исследований, но попробуем дать представление о направлении движения.

Design Advisor. Как уже говорилось, Index Wizard рекомендует только создание или удаление индексов. Но выбор индексов – это только одно из множества решений, принимаемых АБД при разработке физического дизайна БД. Избыточная материализация результатов агрегирующих запросов в AST (Automated Summary Tables, материализованные представления в DB2) может существенно повысить производительность запросов, но потребляет дисковое пространство и вынуждает обновлять материализованные представления при каждом обновлении нижележащих таблиц. В DB2 8.1 AST могут включать неагрегированные запросы (теперь AST называются materialized query tables, MQT).

Разумный выбор создаваемых MQT – это еще одна, причем не самая легкая, задача для АБД. MQT, как и сами хранящиеся таблицы, нуждаются в индексировании. Более того, в разделенной (partitioned) среде эти MQT (и все базовые таблицы) нуждаются в оптимальном разбиении для минимизации переразбиения, необходимого при выполнении запросов, содержащего агрегирования, join-ы и т.д. Эти решения могут иметь последствия, слабо предсказуемые даже для экспертов.

Index Wizard будет расширен. Его функциональность, кроме рекомендаций по индексированию, будет включать рекомендации по созданию материализованных представлений и разбиению базовых таблиц. Для лучшего отражения его роли он получит название Design Advisor. Как и раньше, Design Advisor будет использовать детальную модель стоимости DB2 Query Optimizer. Новый компонент MQT будет использовать новую multiquery-оптимизацию для поиска MQT, которые могут оказаться полезными для многих запросов. При этом для более точного определения размера MQT будут применяться пробы контента базовых таблиц. Новый компонент, отвечающий за разбиение таблиц , будет использовать наиболее интересные варианты, просчитываемые Query Optimizer для каждого запроса, генерировать альтернативные планы для каждого такого варианта и только затем давать Query Optimizer возможность выбора лучшего плана. Затем он будет оценивать все запросы, используя один из этих вариантов разбиения таблиц, и пытаться найти лучшее общее решение для БД.

Online schema changes (schema evolution). Один из ключевых моментов автономной инфраструктуры DB2 для z/OS позволит изменять практически любой аспект схемы, не останавливая и не приводя в негодность package-и и представления. Почему это важно? Приложения не бывают статичными. Таблицы изменяются, удаляются колонки таблиц и индексов, меняются типы данных, индексы иногда приходится переименовывать, вводится разбиение таблиц, ну, и так далее. Эти изменения нужно вносить в процессе работы. Иногда приходится внести ряд изменений прежде, чем утилита REORG сможет привести все объекты к одной версии схемы.

Использование статистики реального времени. На z/OS уже существует сбор статистики в реальном времени (а на Linux, Unix и Windows вскоре будет), осталось научиться ее использовать. Упоминавшийся выше Maintenance Advisor будет заниматься именно этим. Эту статистику можно будет использовать и из DB2 Automation Tool.

То ли еще будет

Описанные нами возможности – только малая часть разрабатываемого сейчас под общим названием SMART. В разработке находятся, например:

Группировка таблиц. Любому АБД пригодилась бы возможность описания набора связанных объектов, который можно подать на вход другого процесса. Это как раз то, над чем сейчас работает группа Data Management Tools. Функция группировки может исследовать связи между таблицами по ссылочной целостности, поддерживаемой системой, триггерам, SQL-выражениям в связанных пакетах, и даже логам DB2. Результатом является репозиторий соотношений объектов, который могут использовать другие инструменты, например, DB2 Recovery Expert. Так, при восстановлении двух таблиц Recovery Expert может напомнить, что недавно созданная третья таблица связана системными отношениями ссылочной целостности с одной из этих двух, а также нашлась четвертая, которую нужно обновлять в том же процессе первой. Recovery Expert поможет определить набор таблиц, восстанавливаемых вместе. Другие средства тоже смогут использовать информацию о группах объектов.

Обучаемость оптимизатора запросов. Модель стоимости запросов, которую использует DB2 Query Optimizer, содержит зависимость от подсчетов числа строк, обрабатываемых на каждом этапе плана исполнения. Эта так называемая модель кардинальности (cardinality model), в свою очередь, зависит от статистики БД, используемой для определения селективности каждого предиката запроса. Обновление статистики после любого обновления БД может породить недопустимую нагрузку на СУБД, поэтому обновление статистики производится периодически, утилитой RUNSTATS. Поэтому статистика может быть устаревшей или неполной. А Query Optimizer увеличивает селективность каждого из предикатов, в сущности, считая, что все предикаты независимы. Такие предположения, лежащие в основе модели Query Optimizer, могут в некоторых случаях привести к ошибкам в выборе плана исполнения запроса.

DB2 Learning Optimizer (LEO), сейчас разрабатываемый, как часть проекта SMART, будет самостоятельно проверять модель кардинальности Query Optimizer. LEO использует отдельный исполняемый модуль для сбора реальной кардинальности для каждого из этапов плана исполнения. После выполнения запроса LEO сравнивает свои данные с вычислениями оптимизатора и вносит поправки, которые будут использованы в дальнейшем при оптимизации запросов со сходным набором предикатов. Таким образом, LEO учится на своих ошибках, аккумулируя статистику использования БД. Заметьте, что это очень обобщенный подход, пригодный для коррекции любой последовательности операций.

Meta-Optimizer. DB2 дает возможность указать уровень оптимизации каждого запроса. Если пользователь указывает уровень оптимизации 5 (используемый по умолчанию), DB2 автоматически подстроится, используя несложные эвристики. Разрабатываемая сейчас более изощренная модель мета-оптимизатора будет автоматически определять подхолящий уровень оптимизации для каждого запроса.

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

Copyright © 1994-2016 ООО "К-Пресс"