Выпуск 20

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

1. Какими способами можно создать пользователя (аккаунт)?
2. В чем разница между ролью (role) и привилегией (privilege)?
3. Какими правами обладает только что созданный пользователь?
4. В каком табличном пространстве хранится информация о пользователях?
5. Какой привилегией необходимо обладать, чтобы иметь право создавать новых пользователей (аккаунты)?

Обращаю внимание, что на некоторые вопросы в рассылке ответов нет. Чтобы узнать ответ, воспользуйтесь дополнительной литературой или заходите на форум рассылки. Напоминаю, что архив рассылки вы всегда можете посмотреть на сайте oranet.ru

Управление профилями пользователей

Прежде чем говорить об управлении профилями, давайте разберемся, что же это такое.

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

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

Если не назначить явно никакого профиля, то будет назначен специальный профиль "по-умолчанию" (DEFAULT).

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

Включение и выключение ресурсных ограничений

Строго говоря, есть два способа включить ресурсные ограничения. Первый способ: перед запуском экземпляра базы данных в инициализационном файле параметров указать строку RESOURCE_LIMIT = true (false). Второй способ – это воспользоваться специальной командой ALTER SYSTEM SET RESOURCE_LIMIT = TRUE.

Создание профиля

Профили могут быть созданы, удалены или изменены несколькими способами. Как всегда нам может помочь Enterprise Manager (воистину, всемогущий инструмент) или SQL-команда. Для создания профиля необходимо обладать системной привилегией CREATE PROFILE. Ниже я дам небольшие пояснения опций при создании профиля с помощью Enterprise Manager. На вкладке General опции поделены на Details и Database Services. Для секции Details:

• CPU / Session ( Sec /100) – время (в сотых долях секунды), которое может использоваться сессией.
• CPU / Call ( Sec /100) – время (в сотых долях секунды), которое сессия может использовать на каждый вызов.
• Connect Time ( Min ) – допустимое время соединения для сессии (в минутах).
• Idle Time ( Min ) – время ожидания (бездействия), после которого сессия будет отключена.

• Concurrent Sessions ( Per User ) – максимальное число параллельных сессий для одного пользователя.
• Reads / Session ( Blocks ) – число блоков данных, которые может прочитать сессия (включая данные на диске и из буфера).
• Reads / Call ( Blocks ) – максимальное число блоков данных, которые могут быть прочитаны за один вызов.
• Composite Limit ( Service Units ) – сложное ограничение, составленное из предыдущих ограничений.

• Expire Password – время действия пароля, после истечения которого необходимо изменить пароль.
• Keep Password History – хранить определенное количество старых паролей, с тем чтобы пользователи не могли использовать старые пароли повторно.
• Enforce Password Complexity – требование использовать сложные пароли.
• Lock Account on Failed Logon – ограничение попыток неудачного входа пользователей (после указанного количества попыток аккаунт будет заблокирован).

Если какие-либо ограничения не указывать, то будут использоваться параметры по-умолчанию. Как видите, опций довольно много (я указал далеко не все).   Можно создать профиль с помощью SQL -команды, например:

CREATE PROFILE clerk LIMIT
    SESSIONS_PER_USER 2
    CPU_PER_SESSION unlimited
    CPU_PER_CALL 6000
    LOGICAL_READS_PER_SESSION unlimited
    LOGICAL_READS_PER_CALL 100
    IDLE_TIME 30
    CONNECT_TIME 480;

Изменение профиля

Изменить любой профиль вы можете SQL-командой ALTER PROFILE (вы должны обладать одноименной системной привилегией). Обратите внимание, что при изменении профиля для текущих сессий ограничения не изменяются. Чтобы изменения вступили в силу надо открыть новую сессию (пользователь должен перелогиниться). Пример команды:

ALTER PROFILE clerk LIMIT
    CPU_PER_CALL default
    LOGICAL_READS_PER_SESSION 20000;

Удаление профиля

Для удаления профиля вы должны обладать системной привилегией DROP PROFILE. Для того чтобы успешно удалить профиль, который был назначен некоторым пользователям, пользуйтесь опцией CASCADE . Например:

DROP PROFILE clerk CASCADE;

Если хотите посмотреть информацию о существующих профилях, воспользуйтесь представлением DBA_PROFILES или раскройте ветку профилей в Enterprise Manager. Вот и все что нужно знать о профилях, теперь перейдем к теме управления процессами Oracle.

Управление процессами

Рассмотрим, как работают процессы Oracle, и что они делают. В СУРБД Oracle используются два типа процессов: пользовательские процессы (также называемые теневыми или серверными процессами) и Oracle -процессы (или фоновые процессы). В разных операционных системах процессы могут называться по-разному, но суть от этого не меняется. Например, в Windows это нити (threads) запущенной службы, в Unix это могут быть демоны (daemons).

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

Фоновые процессы выполняют определенные задачи сервера Oracle. Эти задачи варьируются от взаимодействия с другими экземплярами Oracle до поддержки работоспособности системы, самовосстановления после сбоя и записи грязных блоков на жесткий диск. Девять Oracle-процессов DBWR, LGWR, CKPT, PMON, SMON, RECO, ARCH, LCKn и Dnnn были рассмотрены в четвертом выпуске рассылки.

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

Возможны два режима взаимодействия серверных процессов с пользовательскими. В первом случае осуществляется связь один-к-одному, т.е. каждому пользовательскому процессу выделяется один серверный (так называемый, выделенный режим – dedicated server configuration). Во втором случае один серверный процесс может обслуживать несколько пользовательских (разделяемый режим – shared server configuration).

Каждый серверный процесс требует системных ресурсов, поэтому при большом количестве пользователей необходимо переходить на shared-режим.

Отличия между dedicated и shared

Есть определенные задачи, которые выполняются только с выделенным серверным процессом, это:

• Запуск и остановка экземпляра;
• Восстановление данных;
• Запуск пакетного задания (job) .

Dedicated server

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

В dedicated -режиме серверный процесс работает с одним пользовательским процессом. Чтобы потребовать выделенный серверный процесс в shared -режиме, надо указать SRVR=DEDICATED в строке соединения.

Shared server

Многопотоковый серверный процесс может обслуживать сразу несколько пользовательских процессов. Это достигается с помощью процессов-диспетчеров, которые поддерживают очереди запросов (в разделяемом пуле - shared pool). После выполнения запроса, он возвращается опять диспетчеру через shared pool в SGA .

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

Оптимизация shared-сервера

Многопотоковый серверный процесс может обслуживать сразу несколько пользовательских процессов. Это достигается с помощью процессов-диспетчеров, которые поддерживают очереди запросов (в разделяемом пуле - shared pool). После выполнения запроса, он возвращается опять диспетчеру через shared pool в SGA.

Для настройки и оптимизации shared -режима, надо изменить некоторые параметры в файле параметров. Также необходимо внимательно наблюдать за разделяемым пулом (shared pool) чтобы памяти было достаточно.

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

SELECT SUM(value) || 'bytes' "Memory" FROM v$sesstat, v$statname WHERE name = 'session memory' AND v$sesstat.statistic# = v$statname.statistic#;

Этим вы узнаете сколько используется shared-памяти. Разделив на количество активных сессий можно рассчитать память на одну сессию. Умножив на количество пользователей можно рассчитать необходимый размер shared pool . Напомню, что память выделяется гранулами. Если общий объем памяти сервера меньше 128Мб, то гранула составляет 4Мб. Если больше 128Мб, то гранула равна 16Мб. Т.е. размер shared pool (впрочем, и всех других структур памяти) должен быть кратен грануле.

Если вам кажется, что shared pool маловат, то увеличьте значение параметра LARGE_POOL_SIZE в файле параметров. Ошибочно можно подумать, что лучше увеличить значение SHARED_POOL_SIZE, но это не так. Shared pool используется для библиотечного кэша и словаря данных, разделяемых SQL и PL / SQL-процедур, и, при дополнительной нагрузке, возникает фрагментация памяти.

Другим важным параметром является количество серверных процессов – SHARED_SERVERS. Он задается файлом параметров, либо, при открытой базе, с помощью следующей SQL-команды:

ALTER SYSTEM SET SHARED_SERVERS = 2;

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

ALTER SYSTEM SET DISPATCHERS = ‘(PROTOCOL=TCP) (DISPATCHERS=3)';

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

Подводя итоги

На этом мы пока остановимся. Что же мы сегодня узнали?

А узнали мы, что такое профиль, и как с ним работать. А также прошли небольшой экскурс в суть работы Oracle-процессов. Разобрали разницу между выделенным и разделяемым режимами работы Oracle-сервера.

Что дальше?

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

Вопросы – Ответы

Вопрос: Что собой представляет профиль DEFAULT?
Ответ: Профиль DEFAULT создается системой при создании базы данных. По-умолчанию назначается всем пользователям и не имеет ограничений.

Вопрос: Что такое выделенный процесс?
Ответ: Выделенный процесс имеет связь один-к-одному с пользовательским процессом. Каждому пользователю выделяется свой серверный процесс.

Вопрос: Что такое разделяемый процесс?
Ответ: Разделяемый процесс работает сразу с несколькими пользовательскими процессами. Диспетчеры обслуживают очередь запросов, а разделяемый процесс выполняет их.

На этом я завершаю этот выпуск.
Всего наилучшего, Lemon .

Злыгостев А.А. – lemon@oranet.ru или zlygostev@gmail.com