Diagnostics Pack

Oracle Diagnostics Pack предоставляет всестороннюю функциональность по мониторингу, автоматической диагностике производительности и диагностике производительности в реальном времени, встроенную в ядро базы данных и Oracle Enterprise Manager Cloud Control 12c. Управляете ли вы одной или многими базами данных, Oracle Diagnostics Pack предоставляет полное, экономически эффективное и простое в использовании решение для управления производительностью Oracle Database. При использовании с Enterprise Manager Oracle Diagnostics Pack дополнительно предоставляет отчеты о производительности и доступности на уровне предприятия, централизованный репозиторий с данными производительности, кросс-системную агрегацию данных производительности, что значительно упрощает процесс управления большим количеством баз данных.

Диагностика медленно работающей системы – задача, отнимающая много времени, с которой чаще всего сталкиваются администраторы баз данных. Oracle Diagnostics Pack включает в себя модуль самодиагностики, встроенный непосредственно в ядро базы данных Oracle, который называется Automatic Database Diagnostic Monitor (ADDM) и который полностью освобождает администраторов от сложной и тяжелой диагностики проблем производительности.

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

Для Oracle Real Application Cluster (RAC) ADDM имеет специальный режим для анализа производительности на уровне кластера. Он делает анализ глобальных ресурсов базы данных, таких как высоконагруженный SQL, эффективность межкластерного соединения, сетевые задержки, отклонения во времени отклика базы данных, пропускная способность I/O и т.д.

Другая возможность Oracle Diagnostics Pack – Real-Time ADDM – обеспечивает инновационный способ анализа проблем в зависших базах данных. Real-Time ADDM запускает набор предопределенных процедур, используя нормальный и диагностический режим связи с базой данных, для анализа текущей производительности и помогает администратору решать проблемы взаимоблокировок, зависаний, конфликтов в разделяемом пуле и многих других исключительных ситуаций, из-за которых приходится прибегать к рестарту базы данных, и которые часто приводят к значительным потерям доходов.

Oracle Diagnostics Pack включает в себя встроенный в каждую базу данных Oracle репозиторий, который называется Automatic Workload Repository (AWR). В нем содержится статистика о работе базы данных и другая релевантная информация. Через регулярные интервалы времени (раз в час по умолчанию) база данных делает снимки всех основных метрик и сохраняет их в AWR. AWR спроектирован так, чтобы оказывать малое влияние на работу базы данных и автоматически управлять своим пространством, чтобы не быть дополнительным бременем для администраторов.

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

Эти AWR базисные снимки производительности могут использоваться для последующего сравнения с текущей производительностью системы для выявления отклонений в производительности и их первопричин.

Ключевым компонентом AWR является Active Session History или ASH. ASH делает каждую секунду снимки текущего состояния всех активных сессий и сохраняет их в оперативной памяти. Собранные в оперативной памяти данные доступны через V$-представление. Эти данные также записываются каждый час в AWR для последующей диагностики производительности. ASH позволяет проводить анализ неустойчивых проблем производительности, которые длятся очень короткий промежуток времени, и избавляет от необходимости использовать SQL-трассировку. ASH подобно AWR тоже может работать с RAC, и полученная информация о распределении активности сессий по кластерным классам ожидания позволяет выявить специфичные для RAC потенциальные проблемы. Возможности ASH также были расширены для работы нарезервных базах данных, чтобы помогать анализировать производительность Oracle Data Guard.

Oracle Enterprise Manager Cloud Control 12c включает в себя ASH Analytics, инструмент для анализа ASH-данных, позволяющий администраторам агрегировать, детализировать и разбивать данные производительности по разным измерениям.

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

Oracle Diagnostics Pack включает в себя полный набор возможностей для мониторинга и уведомлений, позволяющий администраторам заблаговременно выявлять и реагировать на IT-проблемы для всего стека приложения. Администраторы могут воспользоваться как готовыми настройками Enterprise Manager для мониторинга объектов управления, так и изменить их под нужды своего ЦОД. Для баз данных существуют адаптивные пороговые значения метрик, автоматически вычисляемые самой базой данных на основе анализа своей предыдущей производительности, администратор автоматически получает уведомление, если метрика приняла статистически необычное значение. Для других типов объектов предусмотрен легкий доступ к истории метрик, позволяя администраторам определить подходящие пороговые значения, основанные на типичных значениях метрик. Если требуется осуществлять мониторинг каких-то специфичных для центра обработки данных условий, то администраторы могут определить новые метрики для любого объекта управления, используя расширения метрик. Администраторы могут настроить скрипты с корректирующими действиями, если уведомление о проблеме не имеет готового решения. Когда возникнет уведомление, эти скрипты будут автоматически выполняться и решать проблему, тем самым сводя к минимуму необходимость ручного вмешательства. Кроме того, история уведомлений также легко доступна и позволяет администраторам видеть, какие действия были осуществлены в ответ на предыдущие уведомления.

Как только мониторинг настроен, и события обнаруживаются на контролируемых объектах, уведомления об этих событиях могут быть отправлены соответствующим администраторам. Уведомления включают в себя уведомления по электронной почте, выполнение пользовательских скриптов и PL/SQL процедур и отсылку SNMP-прерываний. Кроме того, могут быть использованы управляющие коннекторы (Management Connectors) для открытия сервисных запросов в автоматизированных системах технической поддержки для инцидентов (основанных на важных событиях) и/или для отправки информации в системы управления третьих фирм. Наконец для поддержки периодов планового обслуживания объектов предоставляется возможность блэкаута, позволяя администраторам временно приостановить мониторинг объектов и предотвратить генерирование ложных уведомлений во время планового простоя.