Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование II

Ответ
 
Опции темы Опции просмотра
  #11  
Старый 13.10.2009, 05:19
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Задание директив ресурсного плана



Задание директив ресурсного плана

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

В Enterprise Manager для задания директив плана используется несколько страниц.

1. На странице General группы потребителей связываются с планами. На этой странице задается значение CPU_MTH, определяющее использование времени CPU каждой группой потребителей или подпланом.
2. Страница с закладкой Parallelism позволяет задать ограничение для уровня параллелизма любых операций внутри группы потребителей.
3. Вы можете контролировать максимальное количество одновременных активных сеансов внутри группы потребителей (закладка Session Pool). Сеанс, в котором параллельно выполняется операция, рассматривается как один активный сеанс.
4. Можно установить ограничение на максимальный совокупный объем генерируемой информации отмены для группы потребителей (закладка Undo Pool).
5. Можно задать ограничение на максимальное время выполнения операции (закладка Maximum Execution Time).
6. Можно осуществлять контроль использования ресурсов, задав для этого критерий, по которому производится автоматическое переключение сеансов в другую группу потребителей (закладка Consumer Group Switching).
7. Можно задать ограничение на период времени, в течение которого сеанс простаивает, после чего он будет аварийно завершен. Дополнительно можно установить ограничение на время, в течение которого сеанс блокирует другие сеансы (закладка Idle Time).

Примечание: представленные здесь возможности будут подробно рассмотрены на последующих слайдах с указанием номеров приведенных здесь закладок (в виде Закладка п).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #12  
Старый 13.10.2009, 05:22
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Методы распределения ресурсов в плане



Методы распределения ресурсов в плане

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

Существует два способа задания распределения времени CPU с помощью параметра CPU_MTH:

EMPHAS IS- метод по умолчанию, используемый для многоуровневых планов, в которых задаются проценты использования ресурсов CPU, распределяемых между группами потребителей.
RATIO (на основе заданной пропорции) - метод, применимый для одноуровневых планов, в которьгх используются показатели, пропорционально которым распределяется время CPU.

PARALLEL DEGREE_LIMIT_MTH - метод ограничения максимального уровня параллелизма операций. Этот параметр разрешено использовать только в директивах, которые ссылаются на группы потребителей ресурсов, но не на подпланы. Возможно применение абсолютного метода, с помощью которого указывается количество процессов, которое может быть задано для операции. Если в нескольких директивах плана есть ссылки на один и тот же подплан или группу потребителей, степень параллелизма для такого подплана или группы потребителей будет ограничена минимальной величиной всех входных значений.


ACTIVE_SESS_POOL_MTH - метод ограничения количества активных сеансов. При превышении заданного ограничения все оставшиеся сеансы неактивны и ждут в очереди. Единственно возможный и действующий по умолчанию метод- ACTIVE_SESS_POOL_ABSOLUTE.

QUEUING_MTH - метод управления порядком, в котором будут выполняться находящиеся в очереди неактивные сеансы. Единственно возможный и действующий по умолчанию метод -FIFO_TIMEOUT.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #13  
Старый 13.10.2009, 05:23
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Сравнение методов EMPHASIS и RATIO



Сравнение методов EMPHASIS и RATIO

Метод распределение EMPHASIS определяет степень важности сеансов различных групп потребителей в ресурсном плане. Для распределения времени CPU используются уровни от 1 до 8, причем уровень 1 имеет наивысший приоритет. Устанавливается процент времени CPU, выделяемый каждой группе потребления на каждом уровне.


Следующие правила применяются для метода выделения ресурсов на основе степени важности (EMPHASIS) :

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

Потребляемые ресурсы, не используемые на данном уровне, передаются на следующий уровень. Например, если группы потребителей на уровне 1 используют только 60% доступных ресурсов, остальные 40% становятся доступными для групп потребителей на уровне 2.

Сумма процентных значений для данного уровня должна быть меньше либо равна 100.

Если для любого уровня нет явно заданных директив плана, по умолчанию выделяется 0% для всех ггодпланов или групп потребителей.

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

Политика RATIO (на основе заданной пропорции) - это одноуровневый метод распределения ресурсов CPU. Вместо процентных значений задаются числовые величины, отражающие пропорцию, в соответствие с которой ресурсы CPU предоставляются группе потребителей. Например, пусть имеется три группы потребителей OLTP_USERS, DSS_USERS и BATCH_USERS, и для них заданы следующие показатели пропорциональности:

OLTP_USERS: 4
DSS_USERS: 3
BATCH_USERS: 2
OTHER: 1


Это означает то же самое, что пользователям группы OLTP_USERS следует предоставить 40% ресурсов, DSS_USERS - 30%, BATCH_USERS - 20%, а всем остальным группам (OTHER) - 10% доступных ресурсов.


Если никто из групп OTHER и DSS_USERS не использует в настоящий момент ресурсы CPU, тогда группе потребителей OLTP_USERS будет выделяться две трети доступных ресурсов и группе потребителей BATCH_USERS - оставшаяся треть ресурсов.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #14  
Старый 13.10.2009, 05:26
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Механизм пула активных сеансов



Механизм пула активных сеансов

Пул активных сеансов позволяет администратору базы данных управлять максимальным количеством одновременных активных сеансов, приходящимся на одну группу потребителей. С помощью этой функциональной возможности косвенно контролируется объем ресурсов, используемый группой потребителей, так как он пропорционален количеству активных сеансов. Использование пула активных сеансов может помочь сократить число серверных процессов, которые занимают системные ресурсы. В результате устраняется дополнительный страничный обмен, свопинг, а также снижается расходование других ресурсов (например, оперативной памяти). Это происходит, потому что система препятствует одновременному выполнения слишком большого числа заданий.

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

Для каждой группы потребителей ресурсов существует только одна очередь, обслуживаемая по алгоритму первым прибыл, первым обслужен (first in, first out - FIFO) с таймаутом. Очередь реализована в виде структуры в оперативной памяти и из нее нельзя прямо запросить данные.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #15  
Старый 13.10.2009, 05:27
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Настройка пула активных сеансов



Настройка пула активных сеансов

С помощью Enterprise Manager можно просто сконфигурировать установочные параметры пула активных сеансов для ресурсного плана.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #16  
Старый 13.10.2009, 05:28
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Максимальное расчетное время выполнения



Максимальное расчетное время выполнения

DBA в любой момент может определить максимальное расчетное время любой операции, задав в директиве ресурсного плана параметр MAX_ESTIMATED_EXEC_TIME. После установки этого параметра менеджер ресурсов базы данных начинает оценивать время выполнения любого задания. Если расчетная продолжительность операции превышает MAX_EST_EXEC_TIME, операция не начинается и возвращается ошибка ORA-07455. В результате запрещается выполнение чрезвычайно длительных заданий, использующих слишком много системных ресурсов.

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

Оцениваемое расчетное время для данной операции основывается на статистиках, собранных для оптимизатора по стоимости.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #17  
Старый 13.10.2009, 05:28
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Конфигурирование переключения группы потребителей



Конфигурирование переключения группы потребителей

ЕМ Database Control Console предоставляет графический интерфейс для конфигурирования автоматического переключения группы. Такие действия можно выполнять, когда создается новый или редактируется существующий ресурсный план.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #18  
Старый 13.10.2009, 05:30
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Возврат в исходную группу потребителей при завершении вызова



Возврат в исходную группу потребителей при завершении вызова

Можно задать возврат сеанса в исходную группу потребителей при завершении вызова верхнего уровня (top call). Для этого необходимо отметить поле "Switch back to original group after call?" в окне Create Resource Plan или Edit Resource Plan. В результате сеанс будет возвращаться в группу, которой он принадлежал сразу после установления соединения. Вызов верхнего уровня определяется либо как обрабатываемый целиком блок PL/SQL, либо как команды SQL, передаваемые клиентом для выполнения при отдельном вызове.

Параметр SWITCH_TIME_IN_CALL наиболее полезен при использовании пула сеансов на сервере промежуточного уровня. В этом случае на промежуточном уровне делается попытка использовать сеанс, установленный после одного пользовательского вызова для обработки вызова другого конечного пользователя. В результате границы обработки действительно совпадают с вызовами, и действия предыдущего конечного пользователя не должны оказывать влияния на следующего конечного пользователя.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #19  
Старый 13.10.2009, 05:31
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Возврат в исходную потребителей при завершении вызова (продолжение)



Возврат в исходную потребителей при завершении вызова (продолжение)

Например, пусть менеджер ресурсов при подсоединении пользователя на основе его исходной группы потребителей (initial consumer group) размещает сеанс в группе DSS_GROUP. После этого пользователь выполняет запрос и параметр SWITCH_TIME_IN_CALL задает интервал времени (в секундах) перед переключением сеанса пользователя в группу, определяемую параметром SWITCH_GR0UP. После завершения вызова верхнего уровня ресурсный менеджер автоматически переводит пользователя обратно в первоначальную группу потребителей.

Примечание: Невозможно задать в одной директиве оба параметра SWITCH_TIME_IN_CALL и SWITCH TIME. Параметр SWITCH_TIME главным образом предназначен для клиент-серверных приложений.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #20  
Старый 13.10.2009, 05:32
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Настройка тайм-аута



Настройка тайм-аута

Для задания в ресурсном плане максимальных тайм-аутов используется закладка Idle Time. В столбцах "Max Idle Time (sec)" и "Max Idle Time if Blocking Another Session (sec)"
указываются значения параметров MAX_IDLE_TIME и MAX_IDLE_BLOCKER_TIME процедуры DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE. Оба значения задаются в секундах.

Директива MAX_IDLE_TIME определяет максимальное время в секундах, в течение которого сеанс может не выполняться или находиться в ожидании ввода-вывода. Если сеанс превышает заданное ограничение, фоновый процесс PMON принудительно завершает сеанс и и удаляет все его структуры. Также имеется возможность указать отдельное ограничение на время, в течение которого простаивающий сеанс блокирует другой сеанс. Для этого используется директива MAX_IDLE_BLOCKER_TIME, определяющая в секундах допустимое максимальное время блокирования простаивающим сеансом другого сеанса. Значение параметра времени простоя по умолчанию - NULL, что означает отсутствие ограничения. То же самое можно задать явно, установив значение UNLIMITED. Эти директивы предоставляют более дифференцированный контроль времени простоя по сравнению с профилями, в которых нельзя разделить блокирующие и неблокирующие сеансы.

В приведенном выше примере процесс PMON принудительно завершает сеансы, которые простаивают более 600 секунд, а также сеансы, которые простаивают и блокируют другие сеансы дольше 300 секунд. PMON проверяет эти ограничения каждую минуту. При превышении одного из эти ограничений PMON принудительно завершает сеанс и очищает все его ресурсы.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 02:07. Часовой пояс GMT +3.


Powered by vBulletin®