Oracle enterprise manager что это
Обновлено: 03.07.2024
Диспетчер предприятия Oracle (Oracle Enterprise Manager — OEM) представляет собой обширный набор инструментов для управления базами данных с графическим интерфейсом; он поставляется в виде части серверного программного обеспечения Oracle уже много лет и постоянно совершенствуется. OEM предлагает широкий спектр служб,в том числе возможности создания отчетов и отправки уведомлений по электронной почте и на пейджер.
Разумеется, управлять базами данных можно и c помощью самостоятельно разработанных сценариев SQL и PL/SQL, но OEM предлагает привлекательный клиентский каркас консольного стиля, способный упрощать выполнение практически всех повседневных операций по управлению и задач вроде резервного копирования, восстановления, экспорта, импорта и загрузки данных, включительно. Хотя для решения этих задач можно использовать поставляемые Oracle пакеты, OEM значительно облегчает работу с такими новыми инструментами администратора баз данных в Oracle Database 11g, как Segment Advisor (Консультант по настройке правильного размера областей оперативной памяти), SQL Access Advisor (Консультант по оптимизации путей доступа) и SQL Tuning Advisor (Консультант по настройке кода SQL). Если в предыдущих версиях установка различных компонентов OEM в основном выглядела довольно сложно, то последние версии OEM являются в этом отношении довольно удобными для пользователя.
Начиная с выхода Oracle Database 10g, на выбор предлагается две версии OEM — Database Control, позволяющая управлять только одной базой данных, и Grid Control,позволяющая управлять целой системой. С помощью Grid Control управлять можно не только используемой в масштабах всего предприятия базой данных, но и серверами приложений, хостами и прочими службами. В этом разделе будет показано, как конфигурировать и использовать обе версии OEM. Для тех, кто не умеет писать сценарии,OEM является идеальным вариантом, потому что поставляется со всеми существенно важными сценариями для управления базой данных и другими службами. Сегодняшним администраторам баз данных следует стараться овладевать OEM и пользоваться его мощными возможностями для увеличения глубины и масштабов своих операций по управлению базами данных.
На заметку! Те, у кого установлена версия Oracle Application Server 10g, для управления экземпляром сервера приложений могут использовать консоль Application Server Control (Управление сервером приложений).
Обычно администраторы баз данных Oracle применяют для управления своими базами данных различные сценарии. Эти сценарии можно как писать самостоятельно, так и загружать с любого посвященного администрированию баз данных сайта в Интернете (каковых доступно очень много). Они могут представлять собой как основанные только на SQL сценарии, так и смешанные сценарии, включающие и элементы сценариев SQL*Plus, и элементы сценариев оболочки UNIX. Их можно запускать вручную, а можно и автоматизировать, обеспечив автоматическое наблюдение за работой системы с рассылкой соответствующих уведомлений на пейджеры или адреса электронной почты.Большинство администраторов баз данных также предпочитают пользоваться для этого и средствами операционной системы, например, утилитами GlancePlus, sar, vmstat и iostat.
Возможность наблюдать за производительностью баз данных является далеко не единственным преимуществом применения OEM. Предлагаемый в OEM механизм про активного управления событиями (proactive event management), например, позволяет устанавливать пороговые значения для различных параметров базы данных, связанных с уведомлением о событиях, а механизм планирования выполнения заданий (job scheduling) делает традиционный подход с применением файла crontab несколько старомодным. Кроме того, в OEM можно осуществлять настройку приложений и выполнять операции по реконструкции схемы. И, наконец, OEM значительно облегчает выполнение многих связанных с администрированием баз данных задач, например,резервное копирование, восстановление, загрузку данных и реорганизацию таблиц в оперативном режиме.
По мере изучения различных областей OEM уровень навыков по администрированию баз данных будет постепенно расти, эффективность увеличиваться, а время, затрачиваемое на выполнение важных, но утомительных задач, наподобие проверки журналов и наблюдения за различными компонентами базы данных, значительно сокращаться.
Преимущества использования OEM для управления базами данных Oracle
В OEM предлагается несколько функциональных возможностей, которые делают его привлекательным средством для управления базами данных. В целом набор инструментов OEM позволяет производить мониторинг баз данных, управлять физической памятью и различными объектами баз данных и анализировать производительность баз данных. Давайте отдельно рассмотрим различные предлагаемые OEM преимущества.
Готовые средства управления
OEM представляет собой готовое решение для мониторинга и управления целыми системами. Хотя чуть позже в разделе “Конфигурирование и использование Database Control” будут описаны способы настройки различных компонентов OEM, никаких действительно трудных операций по конфигурированию, которые нужно выполнять для начала работы с OEM, не существует, даже в случае версии Grid Control. На самом деле OEM Database Control вообще не требуется конфигурировать в случае создания новой базы данных Oracle с помощью приложения DBCA (Database Configuration Assistant — Помощник по конфигурированию сервера базы данных) или выбора варианта создания новой базы данных во время инсталляции Oracle Database Server.
Управление через Веб
Мониторинг в реальном времени базы данных Oracle
В OEM предлагается замечательная возможность для осуществления мониторинга базы Oracle в реальном времени, а также возможность для генерации различных отчетов по базам данных. Без OEM требуется использовать сценарии SQL, а те не всегда быстро справляются с обработкой информации. Например, сценарии SQL, предназначенные для обнаружения блокирующих объект пользователей, просто “славятся” своей медленной работой. С помощью OEM, однако, можно без промедления просматривать все имеющиеся в базе данных блокировки. Аналогично, OEM также помогает выявлять в системе ожидания (waits) и выяснять причины их возникновения.
Мониторинг полной среды
Как уже должно быть известно, причиной плохой производительности (или недоступности) базы данных может являться наличие проблемы где-то в стеке приложения — в базе данных, в веб-серверах или в сервере, обслуживающем какой-нибудь из компонентов приложения. OEM позволяет следить за производительностью всех компонентов в этом стеке, а не только за производительностью базы данных Oracle. Это значит, что с помощью OEM можно очень быстро выяснить, почему база данных начала работать медленно. Возможно, один из веб-серверов не справляется с обработкой запросов на подключение по какой-то причине, а база данных работает вполне нормально.
Ниже приведен перечень элементов, за которыми OEM может следить и по показателям которых он может составлять отчеты:
- вся платформа;
- впечатление конечного пользователя:
- доступность систем и веб-приложений;
- расширенные сетевые компоненты;
- бизнес-транзакции;
- анализ хронологических данных и отслеживание изменений.
Мониторинг производительности приложений
В OEM предлагаются средства для осуществления мониторинга за производительностью приложений (Application Performance Monitoring — APM), которые позволяет легко диагностировать проблемы в системе и следить за производительностью баз данных.Они умеют собирать сведения и генерировать отчеты не только о состоянии, но так-же и показателях времени отклика всех баз данных в системе. Эта информация помогает своевременно управлять базами данных и предотвращать возникновение в них проблем.
За счет применения предлагаемых в OEM механизмов предупреждения и уведомления, администраторы баз данных могут быстро информировать руководителей о плохо работающих компонентах системы и, следовательно, устранять узкие места до того, как база данных станет полностью недоступной для пользователей.
В частности, средства APM позволяют выполнять следующие функции.
- Следить за производительностью и доступностью системы.
- Выявлять перебои и узкие места во всех компонентах системы приложений.
- Анализировать исходные причины проблем с производительностью.
- Выполнять диагностику производительности с возможностью детализации.
- Сводить к минимуму время простоя приложений за счет применения эффективных средств разрешения проблем.
Возможность масштабированного управления
OEM является очень легко масштабируемым средством, и потому никаких дополнительных ресурсов для управления постоянно разрастающимся предприятием не требуется. При необходимости добавить в систему новые серверы, достаточно просто запустить на новом узле приложение Management Agent (Агент управления), которое поможет собрать всю необходимую информацию об этих серверах и находящихся на них базах данных.
Управление консолидированными базами данных Oracle
OEM позволяет получать быстрое высокоуровневое представление обо всей среде — серверах, базах данных, серверах приложений и т.д. — посредством своих домашних страниц. У каждого управляемого целевого компонента имеется своя домашняя страница, на которой отображаются краткие сведения о его состоянии и производительности.За счет предоставления краткой главной информации на таких домашних страницах,OEM помогает быстро выяснить основную причину любых проблем в системе.
Кроме того, OEM позволяет эффективно запрашивать самые новейшие кодовые заплаты для всех установленных на предприятии продуктов Oracle. Если новые заплаты уже доступны, загрузить и установить их с помощью OEM не представляет труда.
Управление интегрированными системами
OEM легко интегрировать со средствами мониторинга масштаба системы, наподобие HP OpenView. Такая интеграция средств управления базами данных и серверами позволяет просматривать события и базы данных и системы из одного браузера. Два продукта, по сути, начинают работать как единый интегрированный комплект средств управления. Для обеспечения возможности интеграции операций OEM и OpenView служит модуль Smart Plug-In (SPI).
Архитектура и компоненты OEM
Как уже рассказывалось ранее, OEM поставляется в виде двух компонентов — Database Control и Grid Control. Для осуществления мониторинга и управления только одной базой данных вполне хватает компонента OEM Database Control. Для компонента OEM Database Control, ничего конфигурировать не нужно — он готов к использованию с самого момента создания новой базы данных Oracle Database 11g, при условии, что та создавалась с помощью DBCA или Oracle Universal Installer. В случае если база данных создавалась с нуля оператором CREATE DATABASE, однако, Database Control потребуется сконфигурировать посредством утилиты emca (Enterprise Manager Configuration Assistant — Консультант по настройке диспетчера предприятия).
Для управления масштабными и сложными средами необходимо использовать компонент OEM Grid Control, который инсталлируется отдельно от базы данных Oracle.
В целом, Database Control можно считать подмножеством Grid Control, поскольку Grid Control умеет делать все то же, что Database Control, плюс также помогать осуществлять в системе управление и такими целевыми объектами, которые не являются базами данных.
На заметку! Помимо Database Control и Grid Control, в состав OEM также входит компонент Oracle Enterprise Manager Application Server Control (Управление сервером приложений), который помогает управлять отдельными экземплярами Oracle Application Server. Экземпляр Oracle Application Server (Сервер приложений Oracle) устанавливается автоматически как часть инсталляции Grid Control. Именно он отвечает за работу компонента Grid Control Management Server.
Oracle Enterprise Manager (OEM) позволяет администраторам управлять работой сложных информационных систем, построенных преимущественно на основе технологий Oracle, а также включающих программные продукты других компаний.
OEM оснащен широким набором функциональных возможностей и позволяет снизить стоимость и сложность управления бизнес-приложениями в распределенных вычислительных средах. Он предоставляет разнообразные функции диагностики многоуровневых Интернет-/Интранет-приложений, инструменты тонкой настройки производительности баз данных и приложений, а также полнофункциональную среду, обеспечивающую управление прикладными программными системами и интеграцию с другими инструментами управления.
Содержание
Компоненты Oracle Enterprise Manager
Provisioning Pack
OEM Provisioning Pack позволяет быстро и эффективно установить программное обеспечение или применить патчи одновременно на большое количество компьютеров. Кроме того, он обеспечивает загрузку операционной системы на новые компьютеры и поддерживает клонирование программного обеспечения с одного компьютера на другие.
Автоматическая установка программного обеспечения. OEM позволяет автоматически устанавливать операционную систему Linux на новые компьютеры [Источник 1] , используя стандартный PXE (Preboot Execution Environment) загрузочный процесс. Он также обеспечивает установку дополнительного ПО поверх операционной системы. После того как операционная система будет установлена на компьютер, он автоматически регистрируется в Enterprise Manager, как еще одна единица управления, и становится доступным для других автоматических операций по управлению программным обеспечением – такими, как применение патчей. OEM также поддерживает клонирование эталонного ПО на другие компьютеры.
Клонирование баз данных и серверов приложений. Кроме клонирования, ПО OEM также предлагает схожий способ клонирования баз данных на основе работающей базы данных или на основе ее резервной копии. Это значительно быстрее, чем создавать базу данных «с нуля», так как пропускается операция создания словаря базы данных, занимающая обычно ощутимую часть времени.
Таким образом, Provisioning Pack позволяет создавать стандартные конфигурации программного обеспечения и предоставляет инструменты, позволяющие обнаруживать и устранять любые отклонения от стандарта. Provisioning Pack контролирует весь жизненный цикл программного обеспечения: от установки и клонирования до применения патчей и выдачи отчетов, повышая тем самым эффективность его использования и снижая затраты на его сопровождение.
Configuration Management Pack
Oracle Database Configuration Management Pack (OCMP) собирает и хранит для последующего анализа информацию о конфигурациях компонентов Oracle Grid, проверяет соответствие конфигураций заранее установленным политикам безопасности и сопровождения. Собираемая OCMP информация включает в себя:
- Описание конфигурации аппаратного обеспечения: количество и тактовая частота процессоров, оперативная память, жесткие диски, сетевые компоненты.
- Описание конфигурации операционной системы: параметры операционной системы, установленные пакеты и патчи, информация о файловых системах.
- Описание конфигурации ПО Oracle: версии, установленные патчи, инициализационные параметры.
Благодаря OCMP упрощается расследование ситуаций, при которых системы, предполагавшиеся быть одинаковыми, ведут себя по-разному. Critical Patch Advisory предупреждает пользователей о новых критических патчах, выпущенных Oracle, и немедленно определяет те системы в Oracle Grid, в которых требуется его применить. OCMP Policy Manager помогает администраторам определять конфигурационные политики, состоящие из правил безопасности, правил хранения и т.д., на соответствие которым будут автоматически проверяться конфигурации как существующих, так и вновь добавляемых компонентов Grid (узлы, базы данных, слушатели). Примеры несоответствия конфигурационным политикам:
- SPFILE не используется
- Недостаточное число контрольных файлов
- Обнаружены открытые TCP/IP порты узла
- Не включен контроль сложности паролей.
Администратору немедленно приходит уведомление о любом нарушении установленных конфигурационных политик.
Change Management Pack
Change Manager Pack (CMP) позволяет Администратору БД делать изменения в экспериментальной БД и после того, как они будут признаны успешными, распространить их на эксплуатационные базы данных. Главным достоинством пакета является то, что, прежде чем делать изменения, он проводит сложный анализ зависимостей, и администратор баз данных всегда может знать последствия своих действий по изменению БД и может быть уверен в качестве и согласованности выполнения этих изменений.
Администратор базы данных выбирает, какой объект будет синхронизироваться. Два модуля – DB Quick Change и DB Alter – позволяют быстро модифицировать любые характеристики объектов БД. АБД может менять не только структуру объектов, но и их параметры хранения, при этом CMP выполнит все работы по перемещению и пересозданию объектов. Модуль DB Propagate позволяет выбрать базе группу объектов и скопировать/воссоздать эти объекты в других БД. При этом учитывается взаимосвязь объектов. Копироваться могут не только описания объектов, но и данные.
Tuning Pack
Oracle Tuning Pack (OTP) – набор модулей, встроенных в ядро Oracle Database и Oracle Enterprise Manager для автоматической настройки и оптимизации приложений, работающих с базами данных Oracle. OTP автоматизирует процесс настройки SQL предложений и процесс реорганизации объектов базы данных с целью увеличения производительности системы. Основные компоненты OTP:
- SQL Tuning Advisor
- SQL Access Advisor
- Object Reorganization Wizard.
Oracle Database способна сама автоматически определять неэффективные ресурсоемкие SQL-предложения, используя ADDM и AWR. Эти SQL-предложения могут быть проанализированы с помощью SQL Tuning Advisor (STA). STA использует специальный режим оптимизатора запросов Automatic Tuning Optimizer. В данном режиме оптимизатор запросов выполняет дополнительные действия по оптимизации SQL запроса. В частности, ATO может частично выполнять оптимизируемый запрос, чтобы проверить правильность своей оценки стоимости выполнения запроса. Object Reorganization Wizard (ORW) автоматизирует процесс реорганизации объектов базы. Реорганизация используется для перестройки сильно фрагментированных таблиц и индексов, для перемещения объектов в другое табличное пространство, для пересоздания объектов с новыми оптимальными параметрами хранения. Реорганизация объектов может производиться в оперативном и автономном режимах. ORW строит отчет о планируемых изменениях и скрипт с командами, которые будут выполняться. Это помогает администратору точно понять, на что в базе данных повлияет реорганизация, прежде чем начать ее реальное осуществление.
Diagnostics Pack
Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control (OEM CC) - это линейка продуктов Oracle для управления облачными системами [Источник 2] .
К основным возможностям Enterprise Manager относятся:
- Комплексное решение для управления жизненным циклом облачных вычислений, позволяющее быстро настраивать, управлять и поддерживать корпоративные облака и традиционные ИТ-среды Oracle
- Максимальная отдача от инвестиций в ИТ-менеджмент благодаря лучшим решениям для интеллектуального управления стеком Oracle и инженерными системами с интеграцией базы знаний Oracle в реальном времени с каждой клиентской средой
- Лучшие уровни обслуживания для традиционных и облачных приложений благодаря управляемому приложениями управлению приложениями
Enterprise Manager Cloud Control включает в себя следующие компоненты:
- Oracle Management Agent
- Oracle Management Service
- Oracle Management Repository
- Plug-ins
- Enterprise Manager Cloud Control Console
Oracle Management Agent
Oracle Management Agent является интегрированным программным компонентом, который позволяет конвертировать неуправляемый узел в управляемый узел в системе Enterprise Manager. Агент управления работает совместно с плагинами для мониторинга целевых объектов, запущенных на этом управляемом узле.
Oracle Management Service (OMS)
Oracle Management Service (OMS) - это веб-приложение, которое организует контроль и управление агентами управления и плагинов для обнаружения целей, а также собранной ими информацией в хранилище для будущего отчета и анализа. OMS также предоставляет пользовательский интерфейс для Cloud Manager Cloud Manager.
Oracle Management Repository
Oracle Management Repository- это хранилище, в котором хранится вся информация, собранная агентом управления. Он состоит из объектов, таких как задания базы данных, пакеты, процедуры, представления и табличные пространства. Затем OMS организует данные, чтобы их можно было получить в OMS и отобразить в консоли управления Cloud Manager. Поскольку данные хранятся в репозитории управления, их можно разделить между любым количеством администраторов, получающих доступ к Cloud Control для управления предприятием.
Plug-ins
Plug-ins- это подключаемые приложения, которые предлагают специальные возможности управления, адаптированные под конкретные типы объектов управления.
Базовые плагины, устанавливаемые с Enterprise Manager Cloud Control:
| Название | Описание |
|---|---|
| Oracle Database | Позволяет обнаруживать, контролировать и управлять базами данных Oracle и связанными с ними объектами, такими как Oracle Real Application Clusters (Oracle RAC), Oracle Automatic Storage Management (Oracle ASM) и т.д. |
| Oracle Fusion Middleware | Позволяет находить, контролировать и управлять продуктами Oracle Fusion Middleware, такими как Oracle WebLogic Domain, Oracle WebLogic AdminServer, Oracle WebLogic Server, Oracle SOA Suite, Oracle Web Tier и т.д. |
| Oracle Exadata | Позволяет обнаруживать, контролировать и управлять объектами Oracle Exadata. |
| Oracle Cloud Framework | Позволяет получить доступ к основным функциям, которые являются общими для облачных сервисов, таких как Middleware, как служба (MWaaS), база данных как служба (DBaaS), инфраструктура как служба (IaaS) и тестирование как служба (TaaS). |
| Oracle System Infrastructure | Позволяет находить, контролировать и управлять аппаратными системами Oracle и инженерными системами Super Cluster, включая серверное оборудование, шасси, стойки, блок распределения питания, сетевое оборудование, операционные системы, программное обеспечение для виртуализации и программное обеспечение для кластеризации. |
Oracle Enterprise Manager 13c
Oracle Enterprise Manager 13c предоставляет наиболее полное решение для управления средами Oracle [Источник 3] . Ключевые возможности продукта включают в себя полное управление жизненным циклом облачных вычислений, интегрированное управление облаком и бизнес-управление приложением. Он также предоставляет комплексные возможности управления Oracle Linux. Клиенты могут использовать Oracle Enterprise Manager 13c для управления всеми установленными серверами Oracle Linux [Источник 4] . Oracle Enterprise Manager 13c позволяет администраторам:
- Обнаруживать ассетов в центре обработки данных и организовывать их в группах
- Мониторинг ассетов
- Управление Oracle Linux
- Работа с патчами Oracle Linux
- Контроль соответствия систем корпоративным правилам
- Выполнение операционных процедур на группе серверов или на отдельных серверах
Oracle Enterprise Manager 13c легко интегрируется в существующую инфраструктуру патчей и инициализации Linux, поскольку ее управление основано на открытых стандартах Linux (настройка yum, подготовка к загрузке PXE).
По Вашему запросу ничего не найдено.
Рекомендуем сделать следующее:
- Проверьте правильность написания ключевых слов.
- Используйте синонимы введенных Вами ключевых слов, например “приложение” вместо “программное обеспечение”.
- Попробуйте воспользоваться одним из популярных поисковых запросов ниже.
- Начните новый поиск.
Enterprise Manager Cloud Control
Oracle Enterprise Manager is Oracle’s on-premise management platform that provides a single dashboard to manage all of your Oracle deployments, in your data center or in the cloud. Through deep integration with Oracle’s product stack, it provides market-leading management and automation support for Oracle applications, databases, middleware, hardware, and engineered systems.
Oracle Enterprise Manager Features and Products
Product Information
Blog: The Dashboard for the Modern Database Fleet
Screenwatch Demonstrations: Oracle Enterprise Manager
Blog: Oracle Enterprise Manager Is Now Available on Oracle Cloud Marketplace
Video: Oracle OpenWorld 2019 Enterprise and Cloud Manageability Session Now Available for Download
Product Information
Oracle Enterprise Manager Documentation and Community
The Oracle Enterprise Manager family of products provides comprehensive solutions for testing, deploying, operating, monitoring, diagnosing, and resolving problems in today’s complex IT environments.
Looking for documentation? Review documentation for the most current Oracle Enterprise Manager release, review the Getting Started documentation, or review documentation from older Oracle Enterprise Manager releases.
Community Forums and Blog
There is a very active discussion forum covering Oracle Enterprise Manager. Visit the Oracle Enterprise Manager Community Space in Oracle Groundbreakers.
For ongoing news and best practices from Oracle, visit the Oracle Enterprise Manager Blog.
Oracle Enterprise Manager ( OEM ) - это набор веб-инструментов, предназначенных для управления программным и аппаратным обеспечением, производимым корпорацией Oracle, а также некоторыми организациями, не относящимися к Oracle.
СОДЕРЖАНИЕ
Релизы
Oracle Enterprise Manager включает три выпуска:
Управление базой данных Oracle Enterprise Manager
Oracle Enterprise Manager Database Control, самый старый и, пожалуй, самый известный выпуск, нацелен на управление базами данных Oracle . Он возник как клиент Java, способный настраивать базы данных и управлять ими.
Серверное управление приложениями Oracle Enterprise Manager
Oracle Application Server также имеет веб-интерфейс для управления сервером приложений.
Oracle Enterprise Manager Grid Control
Функции системного мониторинга включают функцию мониторинга, которая поддерживает обнаружение и уведомление о надвигающихся ИТ-проблемах. Он отслеживает экземпляры Oracle Database , Oracle Real Application Clusters, а также фермы и кластеры Oracle Application Server. OEM Grid Control поставляется с набором показателей производительности и работоспособности, которые позволяют отслеживать технологические компоненты, такие как приложения, серверы приложений, базы данных, а также внутренние компоненты, на которые они полагаются, такие как хосты, операционные системы и хранилище.
Архитектура OEM для Grid Control состоит из трех отдельных компонентов:
- агент сбора (Oracle Management Agent или OMA)
- агент агрегации ( Oracle Management Server или OMS)
- агент репозитория (Oracle Management Repository или OMR)
OMA работает на целевом хосте и собирает информацию об оборудовании, операционной системе и приложениях, которые работают на целевом хосте. OMS работает на одном или двух серверах и собирает данные, созданные OMA. OMS извлекает информацию из OMA и объединяет коллекции в репозиторий . OMS также действует как пользовательский интерфейс, генерируя веб-страницы для администраторов баз данных для просмотра состояния систем и служб. OMR представляет собой экземпляр базы данных Oracle, в которой хранятся данные, собранные OMS. Установщики могут сделать OMR высокодоступным или отказоустойчивым , запустив его на экземпляре Oracle RAC на нескольких узлах.
Плагины на каждом из OMA могут настраивать или управлять данными, предоставленными OEM, путем расширения данных, которые собирают OMA. Администраторы могут настроить анализ данных с помощью «пакетов управления», чтобы просматривать определенные коллекции данных для отображения производительности системы. Текущая версия OEM позволяет разрабатывать и настраивать собственные подключаемые модули для мониторинга любого желаемого приложения. OMA собирают данные с помощью специально разработанного плагина и передают результаты в формате XML обратно в OMS, который затем сохраняет и анализирует данные по желанию. Oracle Enterprise Manager продолжает расширять сферу мониторинга, предлагая подключаемые модули управления для компонентов, не относящихся к Oracle, которые разрабатываются Oracle и совместно разрабатываются сторонними поставщиками. Например, доступны подключаемые модули для Veritas Storage Foundation , VMWare vSphere и EMC Clariion .
Ключевые особенности OEM Grid Control:
- Системный мониторинг
- Управление группами
- Система вакансий
- Информационный Издатель
- Управление соответствием
- Расширение Enterprise Manager
- Управление целями
Oracle Enterprise Manager Cloud Control
Это выпуск Oracle начиная с 13c.
Функциональность
Выполнение
OEM по умолчанию использует SYSMAN схему в базе данных Oracle в качестве учетной записи / репозитория суперадминистратора. Служебные программы, такие как emctl или emdctl выполняют фактические функции. OEM также предоставляет альтернативу командной строки EMCLI (интерфейс командной строки EM) с командами для обеспечения тех же функций, что и EM на основе пользовательского интерфейса.
Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи — помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) — платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.
Performance Home
На вкладке Performance Home можно увидеть основные графики утилизации БД.
Average Runnable Process
Этот график дает общее понимание использования CPU.
| № | Показатель | Описание |
|---|---|---|
| 1 | Instance Foreground CPU | Отображает утилизацию CPU процессами текущего инстанса, напрямую запущенными клиентом, например выполнение запросов. Список событий ожидания текущего инстанса можно посмотреть в AWR-отчете |
| 2 | Instance Background CPU | Отображает утилизацию CPU фоновыми процессами текущего инстанса, например LGWR. Список событий фонового процесса текущего инстанса можно посмотреть в AWR-отчете или в официальной документации Oracle |
| 3 | Non-database Host CPU | Отображает утилизацию CPU процессами, не относящимися к текущему инстансу |
| 4 | Load Average | Отображает среднюю длину очереди процессов, ожидающих выполнения |
| 5 | CPU Treads/CPU Cores | Отображает лимит максимально возможного использования CPU |
Average Active Sessions
- Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
- Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
- Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH — Active Session History).
Throughput
Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.
Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет — необходимо изменить настройки БД.
Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график — основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.
Статистику по I/O можно смотреть в разрезе функций, в разрезе типов и в разрезе групп потребителей ресурсов (группы пользователей). Для этого на графике необходимо выбрать соответствующий Breakdown. Графики показывают количество I/O-операций в секунду и их вес в разрезе выбранного значения Breakdown. Для большей детализации можно провалиться глубже в статистику, выбрав соответствующее значение на графике или в легенде, и посмотреть статистику именно по выбранному значению.
I/O Function
График дает представление об уровне утилизации диска приложениями или джобами. То есть на графике можно увидеть, какие процессы больше всего читали и писали за определенный период.
Можно выделить следующие категории:
| № | Категория | Описание |
|---|---|---|
| 1 | Фоновые процессы | Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации) |
| 2 | Активность | XML DB, Streams AQ, Data Pump, Recovery, RMAN |
| 3 | Тип I/O | Включает прямую запись и чтение (в том числе чтение из кэша) |
| 4 | Другое | Включает операции ввода/вывода управляющих файлов |
I/O Type
Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.
Consumer group
Дает представление об утилизации диска в разрезе групп пользователей: показывает, какая группа пользователей выполняет операции чтения и записи в определенный период. Включает в себя фоновые процессы.
Parallel Executions
Раздел дает представление о показателях, связанных с параллельным выполнением запросов. Параллельный запрос делится на несколько процессов для ускорения выполнения запроса. Параллельное выполнение полезно при выполнении тяжелых запросов. Подробнее можно прочесть в официальной документации Oracle.
Services
Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS — это установка пользовательского сеанса.
ASH Report
ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.
- События ожидания и группы событий ожидания.
- Группы пользователей, пользователи, сервисы, инстансы.
- SQL-запросы.
AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.
Load Profile
Здесь отображается общая информация по тому, как была загружена БД за выбранный период.
| № | Параметр | Описание |
|---|---|---|
| 1 | DB Time(s) | Сумма времени утилизации процессора и время ожидания (без простоя) |
| 2 | DB CPU(s) | Нагрузка на процессор |
| 3 | Background CPU(s) | Загрузка процессора фоновыми задачами |
| 4 | Redo size | Объем чтения |
| 5 | Logical reads | Среднее количество логических чтений блоков |
| 6 | Block changes | Среднее значение измененных блоков |
| 7 | Physical reads | Физическое чтение в блоках |
| 8 | Physical writes | Количество записей в блоках |
| 9 | Read I/O requests | Количество чтений |
| 10 | Write I/O requests | Количество записей |
| 11 | Read I/O (MB) | Объем чтения |
| 12 | Write I/O (MB) | Объем записей |
| 13 | IM scan rows | Количество строк в In-Memory Compression Units (IMCU), которые были доступны |
| 14 | Session Logical Read IM | Чтения в In-Memory |
| 15 | User calls | Пользовательские вызовы |
| 16 | Parses | Разборы |
| 17 | Logons | Количество входов |
| 18 | Excecutes | Количество вызовов |
| 19 | Rollback | Количество откатов данных |
| 20 | Transacions | Количество транзакций |
Instance Efficiency Percentages
| № | Показатель | Критерии |
|---|---|---|
| 1 | Buffer nowait | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
| 2 | Buffer Hit | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
| 3 | Library cache hit | Если показатель меньше 95% — нужно расширять shared pool (либо причина в bind-переменных) |
| 4 | Redo NOWAIT | Если показатель меньше 95%, это говорит о проблеме в redo log buffer или redo log |
| 5 | Parse CPU to Parse Elapsd | Показатель должен быть больше или равен 90%, тогда большинство процессов не ожидает ресурсов, что говорит о правильной работе базы данных |
| 6 | Non-Parse CPU | Показатель должен приближаться к 100%, это значит, что большинство ресурсов CP используется в различных операциях, кроме parsing, что говорит о правильной работе базы данных. Если Non-Parse CPU низкий, значит, база много времени тратит на разбор запроса вместо реальной работы |
| 7 | In-memory sort | Значение меньше 100 говорит о том, что сортировка идет через диск, а также есть потенциальные проблемы с PGA_AGGREGATE_TARGET,SORT_AREA_SIZE,HASH_AREA_SIZE и bitmap setting |
| 8 | Soft Parse | Чем он выше, тем меньше у нас Hard Parse |
| 9 | Latch Hit | Чем он выше, тем меньше мы ждем Latches (если он низкий — у нас проблемы с CPU-Bound и Latches) |
Top 10 Foreground Events by Total Wait Time
В разделе находится топ-10 событий, которые ожидали ресурсов дольше остальных.
При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.
Описание некоторых событий ожидания:
| № | Событие ожидания | Описание |
|---|---|---|
| 1 | DB CPU | Отображает процессорное время, затраченное на пользовательские операции над БД. Это событие должно находиться на первом месте списка |
| 2 | db file sequential read | Метрика сигнализирует, что пользовательский процесс не находит нужный блок в buffer cache, загружает его с диска в SGA и ждет физического ввода/вывода |
| 3 | db file scattered read | Указывает на проблему с фулл-сканами, возможно, нужны индексы |
| 4 | read by other session | Может говорить о том, что размер блока слишком большой или задержка (latency) слишком большая |
| 5 | enq TX – row lock contention | Событие возникает при ожидании блокировки строки для дальнейшей ее модификации DML-запросом. Если показатель больше 10%, необходимо разбираться в причинах. Более детальную информацию можно посмотреть в разделе Segments by Row Lock Waits, в котором есть сведения о том, какие таблицы были заблокированы и какими запросами |
| 6 | DB FILE SEQUENTIAL READ | Если среднее значение параметра больше 100 мс, это может свидетельствовать о том, что диск работает медленно |
| 7 | LOG FILE SYNC | Значение AVG WAIT более 20 мс может свидетельствовать о проблемах |
| 8 | DB FILE SCATTERED READ | Если это событие выполняется — возможно, имеет смысл создать дополнительные индексы. Для более подробной информации нужно перейти к разделу Segments By Physical Read, в котором находится информация по таблицам и индексам, в которых происходит физическое чтение |
| 9 | direct path read temp ИЛИ direct path write temp | Эти события дают информацию по использованию временных файлов |
| 10 | Buffer Busy Wait | Событие указывает на то, что несколько процессов пытаются обратиться к одному блоку памяти, то есть пока первый процесс работает с конкретным блоком памяти, остальные процессы находятся в статусе ожидания |
Host CPU и Instance CPU
Здесь стоит обратить внимание на %Idle и %Total CPU. Если показатель %Idle низкий, а %Total CPU высокий, это может свидетельствовать о том, что процессор является узким местом.
Foreground Wait Class, Foreground Wait events и Background Wait Events
Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.
SQL statistics
Раздел содержит несколько таблиц со статистикой по SQL-запросам, отсортированным по определенному критерию.
Подробнее про оптимизацию запросов и примеры типичных проблем в запросах можно почитать в статье Проактивная оптимизация производительности БД Oracle.
| № | Параметр | Описание |
|---|---|---|
| 1 | SQL ordered by Elapsed Time | Топ SQL-запросов по затраченному времени на их выполнение |
| 2 | SQL ordered by CPU Time | Топ SQL-запросов по процессорному времени |
| 3 | SQL ordered by User I/O Wait Time | Топ SQL-запросов по времени ожидания ввода/вывода для пользователя |
| 4 | SQL ordered by Gets | Запросы к БД, упорядоченные по убыванию логических операций ввода/вывода. При анализе стоит учитывать, что для PL/SQL-процедур их количество прочитанных Buffer Gets будет состоять из суммы всех запросов в рамках этой процедуры |
| 5 | SQL ordered by Reads | Этот раздел схож с предыдущим: в нем указываются все операции ввода/вывода, наиболее активно физически считывающие данные с жесткого диска. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода |
| 6 | SQL ordered by Physical Reads (UnOptimized) | В этом разделе выводятся неоптимизированные запросы. В Oracle неоптимизированными считаются все запросы, которые не обслуживаются DSFC или Exadata Cell Smart Flash Cache (ECSFC) |
| 7 | SQL ordered by Executions | Наиболее часто выполняемые запросы |
| 8 | SQL ordered by Parse Calls | Отображает количество попыток разбора SQL-запросов до его выполнения |
| 9 | SQL ordered by Sharable Memory | Запросы, занимающие больший объем памяти общего пула SGA |
| 10 | SQL ordered by Version Count | Здесь показано количество SQL-операторов экземпляров одного и того же оператора в разделяемом пуле |
| 11 | Complete List of SQL Text | Показывает полный SQL-запрос, не только его хэш. В этой таблице можно найти неоптимальные запросы (например, запросы по всем столбцам таблицы «select * from. », запросы с большим количеством «like» и т. п.) |
Active Session History (ASH) Report
В данной таблице находятся самые тяжелые SQL запросы, на которые приходится наибольший процент активности и наибольшее время ожидания.
В таблице содержится статистика по запросам, на которые приходится наибольший процент выборочной активности и подробная информация о их плане выполнения. Вы можете использовать эту информацию, чтобы определить, какая часть выполнения SQL операторов значительно повлияла на затраченное время SQL оператора.
Читайте также: