Зачем Использовать Менеджер ресурсов

Рубрика: Управление Ресурсами

  • Можно управлять ресурсами баз данных и операционной системы, такими как:

    • Использование ЦП

    • Степень параллелизма

    • Число активных сеансов

    • Генерация отката

    • Время выполнения операции

    • Время простоя

    • Консолидация базы данных

    • Консолидация сервера

  • Можно также определить критерии, при удовлетрорении которых происходит автоматическое переключение сеансов на другую потребительскую группу.

Зачем Использовать Менеджер ресурсов

Менеджер ресурсов Базы данных обеспечивает несколько средств выделения ресурсов:

  • Метод ЦП: Позволяет Вам определить, как ресурсы ЦП выделяются среди потребительских групп и подпланов

  • Степень Предела Параллелизма: Позволяет Вам управлять максимальной степенью параллелизма для любой операции в пределах потребительской группы

  • Пул Активных Сеансов с Очередью: Позволяет Вам ограничивать число параллельных активных сеансов для потребительской группы или подплана. Если группа превышает максимальное позволенное число сеансов, новые сеансы помещаются в очередь, где они ожидают завершения активного сеанса. Можно также определить ограничение по времени относительно того, сколько времени сеанс будет ожидать прежде, чем выйти с ошибкой.

  • Пул отката: Позволяет Вам управлять общей суммой отката, которая может быть сгенерирована потребительской группой или подпланом. Всякий раз, когда полное пространство отката превышает количество, определенное UNDO_POOL, никакие дальнейшие команды INSERT, UPDATE или DELETE не позволяются, пока пространство отката не освобождается другим сеансом в той же самой группе, или пул отката не увеличивается для потребительской группы. Если квота потребительской группы превышается во время выполнения оператора DML, работа прерывается и возвращает ошибку. Запросы по-прежнему позволяются, даже если потребительская группа превысила свой порог отката.

  • Предел Времени выполнения: Позволяет Вам определять максимальное время выполнения, позволенное для операции. База данных Oracle использует статистику оптимизатора на основе издержек, чтобы оценить, сколько времени потребует операция. Если это время превышает максимальное позволенное время (MAX_EST_EXEC_TIME), операция возвращает ошибку и не запускается. Если потребительская группа ресурсов имеет больше чем одну директиву плана с указанием MAX_EST_EXEC_TIME, Менеджер ресурсов выбирает самое рестриктивное из всех входящих значений.

  • Предел Времени простоя: Позволяет Вам определить количество времени, в течение которого сеанс может быть неактивным, после чего он будет завершен (MAX_IDLE_TIME). Можно далее ограничить Менеджер ресурсов, чтобы завершать только те сеансы, которые блокируют другие сеансы (MAX_IDLE_TIME_BLOCKER).

  • Переключение Потребительской группы: Начальная потребительская группа является группой, в которой был бы сеанс, который только вошел в систему. Главный вызов определяется как обработка всего блока PL/SQL как один вызов или, аналогично, обработка SQL-операторов, которые запускаются отдельно клиентом, как отдельные вызовы. Эта функциональность главным образом выгодна для трехуровневых приложений, где сервер среднего уровня реализует объединение в пул сеансов. В этом случае средний уровень имеет тенденцию делать один вызов для конечного пользователя и затем использовать тот же самый сеанс для вызова другого конечного пользователя. Поэтому, границами работы являются в действительности вызовы, и действия предшествующего конечного пользователя не должны влиять на следующего конечного пользователя. Можно создать директиву плана, так чтобы Менеджер ресурсов автоматически переключал пользователя назад в начальную потребительскую группу в конце главного вызова.
    Отметьте: Нельзя определить оба параметра SWITCH_TIME_IN_CALL и SWITCH_TIME внутри одной и той же директивы. Параметр SWITCH_TIME прежде всего предназначается для клиент-серверных приложений, тогда как параметр SWITCH_TIME_IN_CALL для трехуровневых приложений.

  • Консолидация базы данных: Менеджер ресурсов позволяет Вам оптимизировать распределение ресурсов среди параллельных сеансов базы данных. Консолидация базы данных требует, чтобы приложения были изолированы друг от друга. Если одно приложение испытывает увеличение рабочей нагрузки, то увеличение не должно влиять на другие приложения. Кроме того, производительность каждого приложения должна быть согласованной . Хорошими кандидатами приложений для Консолидации Базы данных являются автоматизированные задачи обслуживания, потому что в настоящий момент эти приложения могут занимать до 100% ресурсов ЦП сервера.

  • Консолидация сервера: Поскольку многие тестовые базы, базы разработки и небольшие производственные базы данных неспособны полностью использовать серверы, на которых они находятся, консолидация сервера обеспечивает возможную альтернативу. С консолидацией сервера ресурсы более полно используются, выполняя многократные экземпляры базы данных на сервере. Метод управления выделениями ЦП на многопроцессорном сервере с несколькими экземплярами базы данных называют Экранированием Экземпляров. Поскольку Экранирование Экземпляров просто сконфигурировать и оно не требует лицензирования или установки новое программного обеспечения, это - превосходная альтернатива другим инструментам консолидации сервера, таким как виртуализация и менеджеры по рабочей нагрузке O/S.

Можно получить доступ к планам ресурсов в графическом интерфейсе Enterprise Manager или в командной строке с помощью пакета DBMS_RESOURCE_MANAGER.

Далее: Использование Планировщика Oracle

Смотрите также
Комментарии
Написать

(обязательно)

(обязательно)

Это не спам (обязательно)