(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Как раздать пользователям приоритеты

Источник: Interface
Владимир Пржиялковский, преподаватель УКЦ Interface Ltd.

Не секрет, что уже достаточно давно фирма Oracle испытывает в области средств моделирования данных нечто вроде кризиса жанра (впрочем, не выделяясь в этом среди своих конкурентов). Взять хотя бы ее искания в этом направлении в продолжении последних лет, а заодно и результаты этих исканий. Замечая на протяжении длительного времени лишь ближние рыночные ориентиры, фирма сама подвела себя к нелегкой ситуации - перспективы в этой области неясны... В области же эксплуатационной то же самое поведение Oracle оказалось не столь пагубным, и наверстывание многого из того, что можно было бы сделать давным-давно, пока возможно, и реально продолжается с каждой последней версией. Словом - здесь лучше поздно, чем никогда, хотя в других областях может статься лучше никогда, чем поздно.

Первое, например, касается очень простой задачи: как научиться выдавать пользователям, работающим с базой данных, приоритеты на процессорное время Oracle? Чтобы какой-нибудь из пользователей, запуская сложные запросы, не мешал работе остальных?

Кое-что по части администрирования использования ресурсов системы известно и применяется на практике давно. Имеются в виду профили, которые можно приписывать пользователям, и которые позволяют ограничивать процессорное время и обращения к диску в рамках отдельных запросов или всего сеанса. Ну а если мы не хотим вводить абсолютные ограничения, а хотим ввести приоритеты?

Такая возможность появилась в версии 8.1. Многие, наверное, обратили внимание на отсутствующие в более ранних версиях термины resource manager или consumer group, появившиеся формах OEM и в документации, но разобраться в них все было недосуг. Между тем, понять, о чем идет речь, вовсе нетрудно, что мы сейчас вместе и сделаем.

Постановка задачи

Допустим, мы хотим разбить пользователей на три группы:

  • администраторов, которым хотим гарантировать не менее 70% процессорного времени
  • прикладников, которым хотим гарантировать не менее 20% процессорного времени
  • всех остальных, которым достаточно будет иметь не менее 10% процессорного времени.

Из этого, конечно, не следует, что, к примеру, прикладники будут всегда довольствоваться только 20-ю процентами. Если кроме них на машине - никого, то все 100% своего времени Oracle отдаст им. (Более сложные ситуации оставим пока в покое).

Пусть, в свою очередь, прикладники делятся на

  • операционистов, которым нужно гарантировать не менее 90% от времени прикладников и
  • аналитиков, требующих не менее 10% времени, выделенного прикладникам, для выполнения-таки своих задач по подготовке отчетов.

То есть, аналитики будут запускать свои задания практически в фоновом режиме и мешать работе операционистов почти не будут; время для них - не столь уж критично.

Что для такой организации труда нужно сделать?

Диспетчер ресурсов

…Точнее было бы перевести "диспетчер ресурса" (resource manager), а еще точнее - "диспетчер ресурса процессорного времени", поскольку сейчас именно и только об этом ресурсе идет речь. В него входят:

  • два системных (встроенных, создаваемых автоматически при создании БД) пакета: DBMS_RESOURCE_MANAGER и DBMS_RESOURCE_MANAGER_PRIVS с определенными, с вовсе не очевидными правилами использования (см. дальше),
  • несколько новых ролей
  • серия новых виртуальных таблиц в словаре-справочнике (а также некоторые добавления в прежние таблицы).

Вот основные понятия, с которыми имеет дело диспетчер ресурсов.

Группа потребителей (consumer group) - группа пользователей Oracle, с которой связывается та или иная гарантированная доля процессорного времени

Ресурсный план (resource plan) - именованная схема распределения долей процессорного времени

Рабочая область (pending area) - временная область, в которой, по технологии диспетчера ресурсов, собирается и проверяется на корректность ресурсный план, прежде чем его можно будет употреблять.

Подготовительные действия

Поначалу нужно выбрать пользователя-администратора, который будет создавать группы потребителей и ресурсные планы в рабочей области, расположенной у себя. Если этот пользователь по вашему выбору - не SYS и не SYSTEM (а к такому решению могут располагать организационные моменты), ему нужно дать право:

EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE( -

'SCOTT', 'ADMINISTER_RESOURCE_MANAGER', FALSE);

EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE( -

Технология диспетчера организована так, что привилегия ADMINISTER RESOURCE MANAGER выдается и отбирается не обычными командами GRANT и REVOKE, а процедурно, на манер, как сделано выше.

Теперь администратор диспетчера ресурсов должен создать рабочую область, где будет создаваться и готовиться план (см. предложения ниже):

EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

Создаем план

От имени администратора диспетчера выдаем:

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PLAN(

'DAILY',

'The plan for normal daily operations');

DBMS_RESOURCE_MANAGER.CREATE_PLAN(

'APPLICATIONS',

'The subplan for applications');

END;

/

Мы создали два плана: основной ('DAILY') и один подчиненный ('APPLICATIONS'). Подчиненных может быть и больше, а может и вовсе не быть.

Создаем потребительские группы

От имени администратора выдаем:

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(

'Database support',

'Database administration group');

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(

'Operators',

'Customer management department');

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(

'Analytics',

'System analysis group');

END;

/

Тут созданы три потребительские группы; из кода полностью ясно, как.

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

Привязываем потребительские группы к плану

Из созданной выше структуры для плана строим полноценный план, приписывая этой структуре потребительские группы:

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'DAILY ',

'Database support',

'Resource allocation for DBA group',

cpu_p1 => 70);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'DAILY ',

'APPLICATIONS',

'Resource allocation for application users',

cpu_p1 => 20);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'DAILY ',

'OTHER_GROUPS',

'For users not included to any group.',

cpu_p1 => 10);

END;

/

То же самое продолжаем для подчиненного плана:

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'APPLICATIONS',

'Operators',

'For general operators',

cpu_p1 => 90);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(

'APPLICATIONS',

'Analytics',

'For the report writers',

cpu_p1 => 10);

END;

/

Итак, мы сформировали полный план в виде дерева с двумя уровнями. "Листья" дерева - потребительские группы, а промежуточное звено - подчиненный план.

Передаем план в распоряжение системы

Теперь мы готовы к тому, чтобы проверить сформированный план на правильность: может быть, в нем присутствуют циклы, отсутствующие группы или другие некорректности? Выдадим:

EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

Если все в порядке (а в нашем случае должно быть так), план DAILY можно "сдавать в эксплуатацию":

EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

Включаем в потребительские группы пользователей Oracle

План готов к работе, но наши потребительские группы созданы только номинально: в них нет пользователей. По технологии, предлагаемой Oracle, пользователь системы может быть подключен к какой-нибудь группе только при наличии у него права SWITCH CONSUMER GROUP. Выдается оно также с помощью API, то есть одного из наших двух пакетов:

BEGIN

DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(

'SYSTEM', 'Database support', FALSE);

DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(

'SCOTT', 'Operators', FALSE);

DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(

'ADAMS', 'Analytics', FALSE);

END;

/

И только теперь пользователей (из списка выше, коль скоро у них появилось на то право) можно фактически включать в группы:

BEGIN

DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP(

'SYSTEM', 'Database support');

DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP(

'SCOTT', 'Operators');

DBMS_RESOURCE_MANAGER.SET_INITIAL_CONSUMER_GROUP(

'ADAMS', 'Analytics');

END;

/

План начинает действовать

Если теперь ADAMS запустит большой, но "несмертельный" запрос (например, на удвоение безындексной таблицы из полмиллиона записей), никто больше с Oracle не работает, и мы от имени SCOTT попросим выдать EMP, то увидим, что в нашем распоряжении отнюдь не 90% ресурсов. Чтобы план DAILY заработал, требуется поставить последнюю точку:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = DAILY;

Думаю, что радость пользователя SCOTT от времени реакции системы после этого с лихвой окупит его страдания от набирания всех [PL/]SQL-операторов, указанных выше !

Точку можно поставить и по-другому. Указание RESOURCE_MANAGER_PLAN = DAILY можно включить в файл INIT.ORA, и тогда план будет автоматически включаться в действие при старте СУБД, а не быть активным только до первого останова.

Усовершенствования

Описанную выше схему организации приоритетного доступа к процессорному времени можно развивать дальше. Вот некоторое, что приходит в голову сразу:

  • Естественно, что дерево плана может быть более "высоким", чем двухуровневое, или быть одноуровневым, или более широким. Есть, правда, ограничение на высоту: 7 уровней.
  • Вы можете подготовить второй план под название NIGHTLY, в котором поменять доли групп Operators и Analytics, например, на противоположные: 10 и 90%. В вечернее время и на ночь вы можете переключать систему на план NIGHTLY, подразумевая спад операционной активности со стороны приложения и рост аналитической (подготовка отчетов). С началом рабочего дня можно снова переводить систему на план DAILY.
  • Более того, вы можете обойтись без простановки RESOURCE_MANAGER_PLAN в файл INIT.ORA, а подготовить триггер на старт БД, который будет делать простую проверку текущего времени и включать дневной или ночной план; что-нибудь вроде:

CREATE OR REPLACE TRIGGER resource_plan_on_startup

AFTER STARTUP ON DATABASE

DECLARE

switch_to_daily varchar2(40) :=

'ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = DAILY';

switch_to_nightly varchar2(40) :=

'ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = NIGHTLY';

BEGIN

IF (SYSDATE > TRUNC(SYSDATE) + 9 / 24) AND

(SYSDATE < TRUNC(SYSDATE) + 18 / 24) THEN

EXECUTE IMMEDIATE switch_to_daily;

ELSE EXECUTE IMMEDIATE switch_to_nightly;

END IF;

END;

/

В этом случае, однако, вам придется позаботиться об автоматическом переключении плана при наступлении 9 утра и 6 вечера. Сделать это можно с помощью пакета DBMS_JOB.

Чем это все хорошо

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

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

Что делать дальше

Как это часто бывает в Oracle, простые внешне идеи при реализации обрастают пугающим новичка изобилием технических подробностей, в которых отнюдь не просто разобраться. (Объективно это или субъективно - для меня пока загадка. Поделитесь своим мнением!. Есть они и в случае с диспетчером ресурсов. Любознательные имеют возможность ознакомиться с ними, заглянув в документацию по Oracle. Надо надеяться, что полнофункциональный пример, приведенный выше, сделает такое знакомство менее травмирующим.



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции Oracle »
Написать редактору 
 Рекомендовать » Дата публикации: 01.03.2001 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Oracle Database Personal Edition Named User Plus License
Oracle Database Personal Edition Named User Plus Software Update License & Support
Oracle Database Standard Edition 2 Processor License
Oracle Database Standard Edition 2 Named User Plus License
ABBYY PDF Transformer+ Full
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
OS Linux для начинающих. Новости + статьи + обзоры + ссылки
СУБД Oracle "с нуля"
Adobe Photoshop: алхимия дизайна
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Рабочее зеркало букмекера 1win (1)
Сегодня в случае недоступно официального сайта есть рабочие зеркала БК 1win...
 
Автомобиль (4)
Доброй ночи. Планируем приобрести авто, рассматриваем б.у варианты, как проще всего подобрать...
 
Новости спорта - все послдение события в одном месте (1)
Пользователи, которые увлекаются ставками на спорт, должно следить за последними изменениями в...
 
Как выводить деньги в лучших казино? (1)
Порой игрок казино из рейтинга 2021 https://casino2021.net/ все сделал точно, заявка на вывод...
 
Русификация рамки IDEF0 BPWin4 (44)
Возможно ли русифицировать рамку диаграмм в BPWin4?
 
 
 



    
rambler's top100 Rambler's Top100