УПРАВЛЕНИЕ ПОЛЬЗОВАТЕЛЯМИ И РЕСУРСАМИ ORACLE
ГЛАВА 11
----------------------------------------------------------------
УПРАВЛЕНИЕ ПОЛЬЗОВАТЕЛЯМИ И РЕСУРСАМИ
Эта глава объясняет, как управлять доступом к базе данных ORACLE
в целом. Темы этой главы включают обсуждение следующих
вопросов:
* соблюдение вашего лицензионного соглашения ORACLE
* создание, сопровождение и удаление пользователей базы
данных
* создание, назначение, изменение и удаление профилей
(ресурсных лимитов)
* включение и выключение ресурсных лимитов
* вывод информации о пользователях и профилях
Относительно рекомендаций об установлении политики защиты для
пользователей и профилей обратитесь к главе 10.
Привилегии и роли контролируют доступ, который пользователь
имеет к базе данных и объектам схем внутри базы данных. Для
информации о привилегиях и ролях обратитесь к главе 12.
[Trusted]
Если вы используете Trusted ORACLE, обратитесь к документу
Trusted ORACLE7 Server Administrator's Guide для дополнительной
информации об управлении пользователями в этом окружении.
Управление пользователями и ресурсами 11-1
----------------
Управление пользователями
В каждой базе данных есть список действительных пользователей.
Для доступа к базе данных пользователь должен запустить
приложение базы данных и соединиться с инстанцией базы данных,
указав действительное имя пользователя, определенное в базе
данных. Эта секция объясняет, как создавать, сопровождать и
удалять пользователей базы данных.
Лицензирование по числу сессий и пользователей
----------------------------------------------
ORACLE помогает вам гарантировать, чтобы ваша установка
соблюдала лицензионное соглашение на сервер ORACLE. Если у вас
лицензия на одновременную работу, вы можете отслеживать и
ограничивать число сессий, одновременно соединенных с базой
данных. Если, вместо этого, у вас лицензия на число имен
пользователей, то вы можете лимитировать количество учетных имен
пользователей, созданных в базе данных. В обоих случаях вы
управляете лицензионными средствами, и должны включить эти
средства и установить соответствущие ограничения.
Чтобы использовать это средство, вы должны знать тип вашего
лицензионного соглашения и максимальное число сессий или имен
пользователей. На вашей установке может оказаться любой тип
лицензии (по числу сессий или по числу имен пользователей), но
не оба одновременно.
Замечание: В некоторых случаях на вашей установке может не
применяться ни один из этих типов лицензирования. Например, вы
можете иметь неограниченную лицензию. Лишь в этом случае вы
можете оставить лицензионный механизм отключенным: опустите
параметры LICENSE_MAX_SESSIONS, LICENSE_SESSIONS_WARNING и
LICENSE_MAX_USERS из файла параметров, или дайте нулевые
значения всем трем параметрам.
Следующие секции объясняют, как установить ограничения в
соответствии с лицензионным соглашением, и как просматривать
текущие значения и определять наивысшее число одновременных
сессий.
Лицензирование по числу сессий
При таком лицензировании лимитируется число пользовательских
сессий, которые могут быть одновременно соединены с базой данных
на данном компьютере. Вы можете установить ограничение на число
одновременных сессий перед запуском инстанции. На самом деле,
вы должны установить это ограничение как часть процедуры
начальной инсталляции; см. "Редактирование новых файлов
параметров" на странице 2-5. Вы можете также изменить
максимальное число одновременных сессий во время работы базы
данных.
Когда достигается этот лимит, только пользователи, имеющие
системную привилегию RESTRICTED SESSION (обычно АБД), могут
соединяться с базой данных; когда такой пользователь
подключается, ORACLE посылает ему сообщение о том, что достигнут
максимум сессий, и пишет сообщение в файл ALERT. Когда
достигнут максимум, вы должны подключаться лишь для того, чтобы
11-2 Руководство администратора
снимать ненужные процессы. (См. "Снятие сессий" на странице
4-13.) Не повышайте лимитов, ограничиваемых лицензией, если вы
не повысили уровень вашего лицензионного соглашения.
Помимо установки максимума, вы можете установить предупреждающий
лимит на число одновременных сессий. Когда достигается этот
лимит, ORACLE все еще позволяет соединяться новым сессиям
(вплоть до максимального лимита, описанного выше), но посылает
предупреждающее сообщение любому соединяющемуся администратору
(т.е. пользователю с системной привилегией RESTRICTED SESSION),
и записывает предупреждение в файл ALERT базы данных.
Если пользователь соединяется как INTERNAL, лимиты по-прежнему
применяются; однако ORACLE вводит лимит в действие после первого
предложения, выполненного таким пользователем.
В дополнение к ограничению числа одновременных сессий, ORACLE
отслеживает максимальное число одновременных сессий, достигнутое
с момента запуска каждой инстанции. Вы можете использовать эту
информацию для определения, не пора ли повышать лицензию для
вашей установки; см. "Вывод лицензионных ограничений и текущих
значений" на странице 11-5.
В среде параллельного сервера, каждая инстанция может иметь свое
собственное значение лимита на максимальное число сессий и
предупреждающего лимита. Однако сумма лимитов по всем
инстанциям не должна превышать лицензионного лимита на число
сессий. Обратитесь к документу ORACLE7 Parallel Server
Administrator's Guide для дополнительной информации об установке
и изменении лимитов в этом окружении.
[!] Сессии, соединяющиеся с ORACLE через программные или аппаратные
мультиплексоры (такие как монитор транзакций), также
засчитываются в лимит на число одновременных сессий; однако
лицензионный механизм ORACLE не может отличать сессии,
подключаемые таким способом. Если ваша установка использует
мультиплексоры, вы должны принять это во внимание и установить
лимит на число одновременных сессий ниже, чтобы учесть
мультиплексируемые сессии.
Следующие секции объясняют, как устанавливать и вводить в
действие лимит на число одновременных сессий.
Установка максимального числа сессий
Чтобы установить максимальное число одновременных сессий для
инстанции, задайте параметр LICENSE_MAX_SESSIONS. Например:
LICENSE_MAX_SESSIONS = 80
Если вы установите этот лимит, необязательно устанавливать
предупреждающий лимит (LICENSE_SESSIONS_WARNING). Однако
использование предупреждающего лимита облегчает управление, так
как заранее дает вам предупреждение о том, что вы близки к
максимуму.
Управление пользователями и ресурсами 11-3
Установка предупреждающего лимита на число сессий
Чтобы установить предупреждающий лимит для инстанции, задайте
параметр LICENSE_SESSIONS_WARNING в файле параметров,
используемом для запуска инстанции.
Установите предупреждающий лимит ниже, чем максимальный лимит
для числа сессий (LICENSE_MAX_SESSIONS).
Изменение лимитов на число сессий во время работы базы данных
Для изменения максимального числа сессий или предупреждающего
лимита на число сессий используйте команду ALTER SYSTEM с
соответствующей опцией. Например, следующее предложение
изменяет максимальный лимит на 100 одновременных сессий:
ALTER SYSTEM SET LICENSE_MAX_SESSIONS = 100;
Следующее предложение одновременно изменяет как максимальный
лимит, так и предупреждающий лимит:
ALTER SYSTEM
SET LICENSE_MAX_SESSIONS = 64
LICENSE_SESSIONS_WARNING = 54;
Если вы заменяете любой из этих лимитов на значение, меньшее,
чем текущее число сессий, то текущие сессии остаются; однако
новый лимит распространяется на все будущие соединения вплоть до
останова инстанции. Чтобы изменить лимит постоянно, измените
соответствующее значение в файле параметров.
Чтобы изменить лимиты на число сессий во время работы базы
данных, вы должны иметь привилегию ALTER SYSTEM. Кроме того,
для соединения с инстанцией после того, как был достигнут лимит
на максимальное число сессий, вы должны иметь привилегию
RESTRICTED SESSION.
[!] Не повышайте лимиты на число одновременных сессий, если вы
должным образом не повысили вашу лицензию на сервер ORACLE; для
информации обратитесь к вашему представителю фирмы Oracle.
Лицензирование по числу имен пользователей
При таком лицензировании лимитируется число лиц, которым
разрешено работать с ORACLE на данном компьютере. Чтобы
задействовать эту лицензию, вы можете установить лимит на число
имен пользователей, которое можно определить в базе данных, до
запуска инстанции; вы можете также изменять этот лимит во время
работы базы данных, или совсем отключить этот лимит. Когда
достигается этот лимит, вы не можете создавать новых
пользователей; при попытке сделать это ORACLE возвращает
соответствующую ошибку и записывает сообщение в файл ALERT.
Этот механизм предполагает, что каждое лицо, работающее с базой
данных, имеет уникальное имя пользователя, и что никакие два
лица не пользуются одним и тем же именем. Поэтому, чтобы
11-4 Руководство администратора
лицензирование по числу пользователей помогало вам соблюдать
лицензионное соглашение, не позволяйте разным пользователям
соединяться с базой данных под одинаковыми именами.
Если в параллельном сервере ORACLE с одной и той же базой данных
соединяются несколько инстанций, то все эти инстанции должны
иметь один и тот же лимит на число имен пользователей. Для
дополнительной информации обратитесь к документу ORACLE7
Parallel Server Administrator's Guide.
Следующие секции объясняют, как устанавливать и применять лимит
на число имен пользователей.
Установка лимита на число пользователей
Чтобы ввести в действие лимит на число имен пользователей,
установите параметр LICENSE_MAX_USERS в файле параметров базы
данных. Например:
LICENSE_MAX_USERS = 200
Если в базе данных определено больше чем LICENSE_MAX_USERS
пользователей при ее запуске, то ORACLE возвращает
предупреждение и заисывает соответствующее сообщение в файл
ALERT. Вы не сможете создавать дополнительных пользователей,
пока их число не упадет ниже этого лимита, так что вы должны
либо удалить часть пользователей, либо повысить вашу лицензию
ORACLE.
Изменение лимита на число пользователей
Чтобы изменить лимит на число пользователей во время работы
инстанции, используйте команду ALTER SYSTEM с опцией
LICENSE_MAX_USERS. Например, следующее предложение изменяет
максимальное число пользователей на 300:
ALTER SYSTEM SET LICENSE_MAX_USERS = 300;
Если вы пытаетесь заменить этот лимит на значение, меньшее, чем
текущее число пользователей в базе данных, то ORACLE возвращает
ошибку и продолжает использовать старый лимит. Если вы успешно
изменили лимит, новый лимит имеет силу до останова инстанции;
чтобы изменить лимит постоянно, измените соответствующее
значение в файле параметров.
Чтобы изменить лимит на число пользователей во время работы базы
данных, вы должны иметь привилегию ALTER SYSTEM.
[!] Не повышайте лимит на число пользователей, если вы должным
образом не повысили вашу лицензию на сервер ORACLE; для
информации обратитесь к вашему представителю фирмы Oracle.
Вывод лицензионных ограничений и текущих значений
Вы можете выдать текущие лимиты для всех лицензионных значений,
текущее число сессий и максимальное число одновременных сессий,
достигнутое за время инстанции, опросив обзор словаря данных
V$LICENSE. Вы можете использовать эту информацию для
определения необходимости в повышении вашей лицензии ORACLE, для
увеличения числа одновременных сессий или имен пользователей.
Управление пользователями и ресурсами 11-5
Например:
SELECT sessions_max s_max,
sessions_warning s_warning,
sessions_current s_current,
sessions_highwater s_high,
users_max
FROM v$license;
S_MAX S_WARNING S_CURRENT S_HIGH USERS_MAX
-------------------------------------------------------
100 80 65 88 250
Кроме того, ORACLE записывает максимальное число одновременных
сессий, достигнутое за время жизни инстанции, в файл ALERT во
время останова базы данных, так что вы можете найти это значение
там.
Чтобы выдать текущее число учетных имен пользователей,
определенных в базе данных, используйте следующий запрос:
SELECT COUNT(*) FROM dba_users;
COUNT(*)
----------
174
Идентификация пользователей
---------------------------
Пользователь, соединяющийся с инстанцией, должен быть
удостоверен либо операционной системой, либо базой данных. Для
простоты, вы можете захотеть, чтобы все пользователи
удостоверялись одним и тем же способом, но это не обязательно;
некоторые пользователи могут идентифицироваться операционной
системой, другие - базой данных. Вы указываете, как будет
удостоверяться данный пользователь, во время создания этого
пользователя, и можете позднее изменить любого пользователя,
чтобы изменить его метод идентификации.
Идентификация с помощью операционной системы
Если ваша операционная система позволяет (см. ваше руководство
по инсталляции), вы можете заставить ее идентифицировать
пользователей. Если вы делаете это, установите параметр
OS_AUTHENT_PREFIX, и используйте этот префикс в именах
пользователей ORACLE. Этот параметр определяет префикс, который
ORACLE добавляет в начало каждого учетного имени пользователя
операционной системы. При попытке пользователя соединиться с
базой данных ORACLE сравнивает его префиксованное имя с именами
пользователей ORACLE, хранящимися в базе данных.
Например, предположим, что параметр OS_AUTHENT_PREFIX задан
следующим образом:
OS_AUTHENT_PREFIX = OPS$
Если пользователь с учетным именем в операционной системе
"TSMITH" подключается к базе данных ORACLE, и этот пользователь
должен удостоверяться операционной системой, то ORACLE
11-6 Руководство администратора
проверяет, существует ли в базе данных пользователь с именем
"OPS$TSMITH", и, если это так, разрешает соединение. Все ссылки
в ORACLE на пользователя, идентифицируемого операционной
системой, должны включать (установленный) префикс, и поэтому
будут выглядеть наподобие "OPS$TSMITH".
Умалчиваемое значение этого параметра равно "OPS$" для
совместимости сверху вниз с предыдущими версиями ORACLE. Однако
вы можете предпочесть другое значение для этого префикса, или
даже установить его как пустую строку (""); использование
пустого префикса приводит к тому, что имена пользователей ORACLE
точно совпадают с именами пользователей операционной системы.
После установки параметра OS_AUTHENT_PREFIX его значение должно
оставаться неизменным на все время жизни базы данных. Если вы
все же измените этот префикс, то любое имя пользователя базы
данных, включающее старый префикс, нельзя будет использовать для
соединения с базой данных, если только не изменить метод
идентификации для этого пользователя, заставив его подключаться
через пароль.
Замечание: Значение параметра OS_AUTHENT_PREFIX может быть
чувствительно к прописным и строчным буквам в некоторых
операционных системах. Обратитесь к вашему руководству по
инсталляции [IUG] для дополнительной информации об этом
параметре инициализации.
Идентификация с помощью операционной системы и многоканальный сервер
Если вы хотите идентифицировать пользователя средствами
операционной системы, то по умолчанию этот пользователь не может
соединяться с базой данных через многоканальный сервер. Это
ограничение принято (по умолчанию), потому что удаленный
пользователь может внедрить пользователя из другой операционной
системы, используя сетевое соединение.
Если вы не озабочены проблемами защиты и хотите использовать
идентификацию пользователя операционной системой с
многоканальным сервером, установите параметр REMOTE_OS_AUTHENT в
значение TRUE в файле параметров базы данных. Это изменение
начнет действовать при очередном запуске инстанции и
монтировании базы данных. (Этот параметр по умолчанию имеет
значение FALSE.)
Идентификация средствами базы данных
Чтобы заставить ORACLE идентифицировать пользователя, задайте
пароль для этого пользователя при его создании или изменении.
Любой пользователь может изменить свой пароль в любое время.
Пароли хранятся в зашифрованном формате. Каждый пароль должен
состоять из однобайтовых символов, даже если ваша база данных
использует мультибайтовый набор символов.
Создание пользователей
----------------------
Вы создаете пользователя либо через диалоговое окно Create User
SQL*DBA, либо с помощью команды SQL CREATE USER. При любом
способе вы можете также специфицировать умалчиваемое и временное
табличные пространства для нового пользователя, квоты табличных
пространств и профиль. Рис.11-1 показывает диалоговое окно
Create User.
Управление пользователями и ресурсами 11-7
Рис.11-1
Диалог Create User
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г================= Create User =================¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Name: OPS$jward-------------------------------¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ ( ) Use Password Authentication: -------------¦ ¦
¦¦ ¦ (o) Use OS Authentication ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Default Tablespace: data1_ts----------------¦ ¦
¦¦ ¦ Temporary Tablespace: temp1_ts----------------¦ ¦
¦¦ ¦ Quota: 100M ON data_ts, 500K ON¦ ¦
¦¦ ¦ Profile: clerk-------------------¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦-----------------------------------------------¦ ¦
¦+--------¦ Mandatory (OK) (Cancel) ¦----+
¦¦ L===============================================- ¦
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Create User, показанного на рис.11-1:
CREATE USER OPS$jward
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE data_ts
TEMPORARY TABLESPACE temp_ts
QUOTA 100M ON test_ts
QUOTA 500M ON data_ts
PROFILE clerk;
Замечание: Вновь созданный пользователь не может соединяться с
базой данных, пока ему не будет назначена системная привилегия
CONNECT. См. "Назначение и отзыв привилегий и ролей" на
странице 12-15.
Спецификация имени
Внутри каждой базы данных имя пользователя должно быть
уникальным по отношению к другим именам пользователей и ролям;
пользователь и роль не могут иметь одно и то же имя. Далее,
каждый пользователь имеет ассоциированную с ним схему. Внутри
схемы, каждый объект схемы должен иметь уникальное имя.
Обратитесь к главе 8 для дополнительной информации об объектах
схемы и правилах их именования, и к главе 12 о ролях и правилах
их именования.
Имена пользователей в мультибайтовых наборах символов
В базе данных, использующей мультибайтовый набор символов, фирма
Oracle настоятельно рекомендует, чтобы каждое имя пользователя
содержало хотя бы один однобайтовый символ. Если имя
пользователя содержит только мультибайтовые символы,
зашифрованную комбинацию имя/пароль гораздо легче расшифровать.
11-8 Руководство администратора
Установление идентификации пользователя
В предыдущем примере новый пользователь должен удостоверяться
операционной системой. Имя пользователя включает умалчиваемый
префикс "OPS$". Если параметр OS_AUTHENT_PREFIX установлен
иначе (т.е. он не задает никакого префикса или задает иной
префикс), исправьте имя пользователя соответственно, устранив
префикс или подставив корректный префикс.
Альтернативно, вы можете создать пользователя так, чтобы он
удостоверялся базой данных через пароль, например:
CREATE USER jward
IDENTIFIED BY airplane
. . . ;
В этом случае пользователь при подключении должен предоставлять
базе данных правильный пароль, чтобы соединение было разрешено.
Пароли пользователей в мультибайтовых наборах символов
В базе данных, использующей мультибайтовый набор символов,
пароли пользователей должны включать ТОЛЬКО однобайтовые
символы. Мультибайтовые символы в паролях не допускаются.
Назначение умалчиваемого табличного пространства
Каждый пользователь имеет умалчиваемое табличное пространство;
когда пользователь создает объект и не указывает табличное
пространство, ORACLE сохраняет этот объект в умалчиваемом
табличном пространстве данного пользователя.
По умолчанию, для каждого пользователя умалчиваемым табличным
пространством является SYSTEM. Если пользователь не будет
создавать объектов никакого типа, это умалчиваемое значение
пригодно. Однако, если пользователь будет создавать объекты,
назначьте ему явно другое табличное пространство. Вы можете
установить умалчиваемое табличное пространство во время создания
пользователя, и изменить его позже; изменение умалчиваемого
табличного пространства будет действовать лишь на объекты,
создаваемые после такого изменения.
Решая, какое табличное пространство назначить пользователю,
рассмотрите следующие вопросы:
* Устанавливайте умалчиваемое табличное пространство лишь в
том случае, если пользователь имеет привилегии на
создание объектов (таких как таблицы, обзоры, кластеры).
* Устанавливайте умалчиваемое табличное пространство такое,
для которого пользователь имеет квоту. См. "Назначение
квот табличных пространств" на странице 11-10.
* Если возможно, устанавливайте умалчиваемое табличное
пространство, отличное от SYSTEM, чтобы уменьшить
соперничество между объектами словаря данных и
пользовательскими объектами за одни и те же файлы данных.
В примере, показанном выше, пользователю JWARD назначено
умалчиваемое табличное пространство DATA_TS.
Управление пользователями и ресурсами 11-9
Назначение временного табличного пространства
Каждый пользователь имеет временное табличное пространство;
когда пользователь выполняет предложение SQL, требующее
временного сегмента, ORACLE создает этот сегмент во временном
табличном пространстве данного пользователя.
По умолчанию, для каждого пользователя временным табличным
пространством является SYSTEM. Однако назначение каждому
пользователю иного временного табличного пространства может
уменьшить соперничество между временными сегментами и сегментами
других типов. Вы можете установить временное табличное
пространство во время создания пользователя, и изменить его
позже.
В примере, показанном выше, пользователю JWARD назначено
временное табличное пространство TEMP_TS, - табличное
пространство, специально создаваемое для хранения только
временных сегментов.
Назначение квот табличных пространств
Вы можете назначить каждому пользователю квоту для любого
табличного пространства. Назначение квоты преследует две цели:
* Если пользователь имеет привилегии создавать объекты
какого-либо типа, то он сможет создавать объекты в
указанном табличном пространстве.
* ORACLE ограничивает количество памяти, которая может быть
распределена объектам пользователя в указанном табличном
пространстве; это ограничение определяется квотой.
По умолчанию пользователь не имеет квот ни для одного табличного
пространства в базе данных. Если пользователь имеет привилегию
создавать объекты какого-либо типа, то вы должны назначить ему
квоту, чтобы он мог создавать объекты; как минимум, назначьте
ему квоту для его умалчиваемого табличного пространства, и
назначьте дополнительные квоты для других табличных пространств,
в которых он будет создавать объекты.
Вы можете назначить пользователю квоты табличных пространств при
создании пользователя, или можете добавить или изменить эти
квоты позже. Если новая назначаемая квота меньше старой, то
справедливы следующие утверждения:
* Если пользователь уже превысил новую квоту, то его
объектам в данном табличном пространстве не может
распределяться дополнительная память, пока общий объем
памяти, занятой этими объектами, не упадет ниже новой
квоты.
* Если пользователь еще не превысил новой квоты, то его
объектам в данном табличном пространстве может
распределяться дополнительная память вплоть до новой
квоты.
Лишение доступа к табличному пространству
Вы можете лишить пользователя доступа к табличному пространству,
обнулив его текущую квоту. После назначения нулевой квоты,
11-10 Руководство администратора
объекты пользователя в этом табличном пространстве остаются, но
им не может распределяться дополнительная память.
Системная привилегия UNLIMITED TABLESPACE
Чтобы разрешить пользователю потреблять неограниченное
количество памяти в любом табличном пространстве в базе данных,
назначьте ему системную привилегию UNLIMITED TABLESPACE. Это
перекрывает явные квоты табличных пространств для пользователя;
если вы позже отзовете эту привилегию, явные квоты снова начнут
действовать. Вы можете назначать эту привилегию только
пользователям, но не ролям.
Прежде чем назначать системную привилегию UNLIMITED TABLESPACE,
рассмотрите преимущества и недостатки этого назначения:
Преимущества:
* Вы можете одним предложением дать пользователю
неограниченный доступ ко всем табличным пространствам
базы данных.
Недостатки:
* Эта привилегия перекрывает все явные квоты табличных
пространств для пользователя.
* Вы не можете выборочно лишать доступа к табличным
пространствам пользователя, имеющего привилегию UNLIMITED
TABLESPACE. Вы можете управлять доступом выборочно, лишь
лишив его этой привилегии.
Назначение умалчиваемых ролей
Вы не можете назначить пользователю умалчиваемые роли в
предложении CREATE USER. При первоначальном создании
пользователя его умалчиваемой ролью считается ALL, что
заставляет все роли, впоследствии назначаемые пользователю,
становиться его умалчиваемыми ролями. Для изменения
умалчиваемых ролей пользователя используйте команду ALTER USER;
см. "Изменение пользователей" на странице 11-11.
Привилегии, требуемые для создания пользователей
Для создания пользователя базы данных вы должны иметь системную
привилегию CREATE USER. При создании нового пользователя для
него можно специфицировать квоты для любых табличных
пространств, даже если создающий не имеет квот для того или
иного табличного пространства. Из-за такой привилегированной
силы этой команды, обычно лишь администратор защиты наделяется
системной привилегией CREATE USER.
Изменение пользователей
-----------------------
Вы можете изменять характеристики домена защиты пользователя
либо через диалоговое окно Alter User SQL*DBA, либо с помощью
команды SQL ALTER USER. Изменение характеристик защиты
пользователя влияет лишь на будущие сессии этого пользователя,
но не на текущие сессии. Рис.11-2 показывает диалоговое окно
Alter User.
Управление пользователями и ресурсами 11-11
Рис.11-2
Диалог Alter User
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г======================= Alter User ======================¬ ¦
¦¦ ¦ User: ¦ ¦
¦¦ ¦ -----------------¬ ¦ ¦
¦¦ ¦ ¦ AVYRROS ¦ ( ) Do Not Change Authentication ¦ ¦
¦¦ ¦ ¦ BLAKE ¦ ( ) Change Password to: ------------¦ ¦
¦¦ ¦ ¦ CLARK ¦ (o) Change to OS Authentication ¦ ¦
¦¦ ¦ L----------------- ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Default Object Tablespace: data_ts----------------------¦ ¦
¦¦ ¦ Temp Segment Tablespace: temp_ts----------------------¦ ¦
¦¦ ¦ Quota: 100M ON data_ts, 0 ON test_ts¦ ¦
¦¦ ¦ Profile: clerk------------------------¦ ¦
¦¦ ¦ Default Roles: -----------------------------¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦---------------------------------------------------------¦ ¦
¦+-¦ Mandatory (OK) (Cancel) ¦-+
¦¦ L=========================================================- ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Alter User, показанного на рис.11-2:
ALTER USER avyrros
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE data_ts
TEMPORARY TABLESPACE temp_ts
QUOTA 100M ON data_ts
QUOTA 0 ON test_ts
PROFILE clerk;
Этот пример изменяет характеристики защиты пользователя AVYRROS
следующим образом:
* Идентификация изменяется на процедуры проверки учетного
имени в операционной системе.
* Явно устанавливаются умалчиваемое и временное табличные
пространства.
* Дается квота 100M для табличного пространства DATA_TS.
* Отбирается квота для табличного пространства TEST_TS.
* Назначается профиль CLERK.
Изменение не-администратором своего пароля
Большинство пользователей не используют SQL*DBA; тем не менее,
они могут изменять свои пароли с помощью команды ALTER USER, как
показывает следующий пример:
ALTER USER andy
IDENTIFIED BY swordfish;
11-12 Руководство администратора
Любой пользователь может изменить свой пароль таким способом, не
имея никаких специальных привилегий (кроме привилегии
соединяться с базой данных). Следует побуждать пользователей к
частому изменению ими своих паролей.
Чтобы сменить способ своей идентификации (через пароль или через
операционную систему), пользователь должен иметь привилегию
ALTER USER. Обычно лишь администраторы должны иметь такую
привилегию.
Пароли пользователей в мультибайтовых наборах символов
В базе данных, использующей мультибайтовый набор символов,
пароли пользователей должны включать ТОЛЬКО однобайтовые
символы. Мультибайтовые символы в паролях не допускаются.
Изменение умалчиваемых ролей пользователей
Умалчиваемая роль - это роль, автоматически включаемая для
пользователя, когда этот пользователь создает сессию. Вы можете
не назначить пользователю ни одной, или назначить несколько
умалчиваемых ролей. Любая роль, назначенная пользователю
непосредственно, может потенциально стать умалчиваемой ролью
этого пользователя; косвенно назначаемая роль (т.е. роль,
назначенная роли) не может быть умалчиваемой ролью. Число
умалчиваемых ролей для пользователя не может превышать
максимального числа действующих ролей, разрешаемых на одного
пользователя; в противном случае при попытке подключения
возвращается ошибка, и соединение не разрешается.
Замечание: ORACLE автоматически включает умалчиваемые роли
пользователя, когда этот пользователь создает сессию. Помещение
роли в список умалчиваемых ролей обходит идентификацию (проверку
достоверности) этой роли, независимо от того, как определена эта
идентификация - через пароль или через операционную систему.
Если вы специфицируете список ролей, то все прочие роли, которые
были назначены этому пользователю, удаляются из его списка
умалчиваемых ролей. Например, предположим, что пользователю
AVYRROS были назначены роли DEVELOPER и CLERK, и CLERK является
его единственной умалчиваемой ролью. Следующее предложение
удаляет роль CLERK из его списка умалчиваемых ролей и добавляет
в этот список роль DEVELOPER:
ALTER USER avyrros
DEFAULT ROLE developer;
В этом случае, все роли, которые впоследствии будут назначаться
пользователю AVYRROS, не будут умалчиваемыми ролями, и будут
отключены при соединении.
Если вы специфицируете ALL для списка умалчиваемых ролей
пользователя, то каждая роль, непосредственно назначаемая
пользователю, автоматически добавляется в его список
умалчиваемых ролей. Путем последующей модификации можно удалять
вновь назначенные роли из списка умалчиваемых ролей
пользователя. Следующий пример заставляет все роли, которые
были назначены пользователю AVYRROS, перейти в его список
умалчиваемых ролей, так же, как и все роли, которые будут
назначаться этому пользователю позже:
ALTER USER avyrros
DEFAULT ROLE ALL;
Управление пользователями и ресурсами 11-13
Далее, вы можете специфицировать ALL EXCEPT со списком ролей, и
перечисленные при этом роли будут единственными ролями из
назначенных пользователю, которые не попадают в его список
умалчиваемых ролей. Например, следующее предложение добавляетв
список умалчиваемых ролей все роли, назначенные пользователю
AVYRROS, за исключением роли PAYROLL; все роли, назначаемые
позже, также будут включаться в список умалчиваемых ролей этого
пользователя.
ALTER USER avyrros
DEFAULT ROLE ALL EXCEPT payroll;
Чтобы заставить пользователя не иметь ни одной умалчиваемой
роли, специфицируйте NONE в его списке умалчиваемых ролей,
например:
ALTER USER avyrros
DEFAULT ROLE NONE;
Изменение умалчиваемых ролей пользователя действует на
последующие сессии; оно не действует на сессии, активные в
данный момент времени.
Отзыв роли от пользователя автоматически удаляет эту роль из его
списка умалчиваемых ролей.
Привилегии, требуемые для изменения пользователей
Как отмечалось выше, каждый пользователь может изменять свой
собственный пароль. Однако для изменения любой другой опции в
своем домене защиты, вы должны иметь системную привилегию ALTER
USER. Обычно лишь администраторы защиты имеют эту привилегию,
так как она позволяет модифицировать домен защиты ЛЮБОГО
пользователя. Эта привилегия включает право устанавливать квоты
табличных пространств для пользователя по любому табличному
пространству в базе данных, даже если лицо, выполняющее
модификацию, не имеет квот для того или иного табличного
пространства.
Удаление пользователей
----------------------
Когда пользователь удаляется, его имя и ассоциированная с ним
схема удаляются из словаря данных, вместе со всеми объектами,
содержащимися в этой схеме.
Замечание: Если вы не хотите удалять объекты пользователя, но
хотите лишить его доступа к базе данных, отберите у этого
пользователя привилегию CREATE SESSION.
Пользователь, который в данный момент соединен с базой данных,
не может быть удален. Чтобы удалить такого пользователя, вы
должны сначала снять все его сессии с помощью диалогового окна
SQL*DBA Kill Session или команды SQL ALTER SYSTEM с опцией KILL
SESSION; см. "Снятие сессий" на странице 4-13.
Для удаления пользователя из базы данных используйте либо
диалоговое окно Drop User SQL*DBA, либо команду SQL DROP USER.
Рис.11-3 показывает диалоговое окно Drop User.
11-14 Руководство администратора
Рис.11-3
Диалог Drop User
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г=============== Drop User =====================¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ User: ¦ ¦
¦¦ ¦ --------------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ ADAMS ¦ ¦ ¦
¦¦ ¦ ¦ BLAKE ¦ ¦ ¦
¦¦ ¦ ¦ CLARK ¦ ¦ ¦
¦¦ ¦ ¦ JONES ¦ ¦ ¦
¦¦ ¦ L-------------------------------------------- ¦ ¦
¦¦ ¦ [X] Including Associated Schema Objects ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦-----------------------------------------------¦ ¦
¦+--------¦ Mandatory (OK) (Cancel) ¦----+
¦¦ L===============================================- ¦
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Если схема удаляемого пользователя содержит какие-нибудь
объекты, то должен быть выбран переключатель Icluding Associated
Schema Objects, чтобы успешно удалить вместе с пользователем его
ассоциированные объекты и внешние ключи, которые зависят от
таблиц этого пользователя; если вы не выберете этот
переключатель, а схема пользователя содержит объекты, то
возвращается сообщение об ошибке, и пользователь не удаляется.
Перед удалением пользователя, схема которого содержит объекты,
тщательно проверьте, не приведет ли удаление этих объектов к
непредвиденным вами последствиям. Обратите внимание на
возможные каскадные эффекты; например, перед удалением
пользователя, владеющего таблицей, проверьте, не зависят ли от
этой таблицы какие-нибудь обзоры или процедуры.
Следующее предложение является командным эквивалентом
диалогового окна Drop User, показанного на рис.11-3:
DROP USER jones CASCADE;
Привилегии, требуемые для удаления пользователей
Для удаления пользователей и объектов его схемы вы должны иметь
системную привилегию DROP USER. Из-за такой силы этой
привилегии, обычно ей наделяется лишь администратор защиты.
Управление пользователями и ресурсами 11-15
----------------
Управление ресурсами через профили
Профиль - это поименованный набор ресурсных лимитов. Если
ресурсные лимиты включены, ORACLE ограничивает использование
пользователем ресурсов базы данных и инстанции в соответствии с
его профилем. Вы можете назначить профиль любому пользователю,
и можете назначить умалчиваемый профиль всем пользователям, не
имеющим явно назначенных профилей. Чтобы профили имели силу,
ресурсные лимиты должны быть включены для базы данных в целом.
Эта секция объясняет, как создавать, назначать, изменять и
удалять профили, а также как включать и выключать управление
ресурсами.
Создание профилей
-----------------
Для создания профиля используйте либо диалоговое окно Create
Profile SQL*DBA, либо команду SQL CREATE PROFILE. При создании
профиля вы можете одновременно установить несколько ресурсных
лимитов. Рис.11-4 показывает диалоговое окно Create Profile.
Рис.11-4
Диалог Create Profile
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г====================== Create Profile =====================¦
¦¦ ¦ ¦
¦¦ ¦ Name: clerk------------------------ ¦
¦¦ ¦ ¦
¦¦ ¦ [X] Sessions/User (o) Limit: 2---- ( ) Unlimited ¦
¦¦ ¦ [X] CPU Time/Session ( ) Limit: ----- (o) Unlimited ¦
¦¦ ¦ [X] CPU Time/Call (o) Limit: 6000- ( ) Unlimited ¦
¦¦ ¦ [X] Connect Time (o) Limit: 480-- ( ) Unlimited ¦
¦¦ ¦ [X] Idle Time (o) Limit: 30--- ( ) Unlimited ¦
¦¦ ¦ [X] Logical Reads/Session ( ) Limit: ----- (o) Unlimited ¦
¦¦ ¦ [X] Logical Reads/Call (o) Limit: 100-- ( ) Unlimited ¦
¦¦ ¦ [ ] Private SGA/Session ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [ ] Composite Limit ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ ¦
¦¦ ¦-----------------------------------------------------------¦
¦+-¦ Mandatory (OK) (Cancel) ¦
¦¦ L===========================================================¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Create Profile, показанного на рис.11-4:
CREATE PROFILE clerk LIMIT
SESSIONS_PER_USER 2
CPU_PER_SESSION unlimites
CPU_PER_CALL 6000
LOGICAL_READS_PER_SESSION unlimited
LOGICAL_READS_PER_CALL 100
IDLE_TIME 30
CONNECT_TIME 480;
11-16 Руководство администратора
Все не специфицированные ресурсные лимиты для нового профиля
принимают значения, установленные умалчиваемым профилем с именем
DEFAULT. Вы можете также специфицировать лимиты для профиля
DEFAULT. (См. "Использование умалчиваемого профиля" ниже.)
Привилегии, требуемые для создания профиля
Для создания профиля вы должны иметь системную привилегию CREATE
PROFILE.
Использование умалчиваемого профиля
-----------------------------------
Каждая база данных автоматически имеет умалчиваемый профиль с
именем DEFAULT. Лимиты этого профиля используются в двух
случаях:
* Если пользователю явно не назначен профиль, то на него
действуют ВСЕ лимиты умалчиваемого профиля.
* Все не специфицированные ресурсные лимиты любого профиля
принимают значения, установленные умалчиваемым профилем.
Первоначально, все лимиты профиля DEFAULT имеют значение
UNLIMITED, т.е. не ограничены. Однако, чтобы предотвратить
нелимитированное потребление ресурсов пользователями через
умалчиваемый профиль, администратор защиты должен изменить
умалчиваемые лимиты, используя диалоговое окно Alter Profile или
типовое предложение ALTER PROFILE, например:
ALTER PROFILE default LIMIT
. . . ;
Изменять лимиты в профиле DEFAULT может любое лицо, имеющее
системную привилегию ALTER PROFILE. Профиль DEFAULT не может
быть удален.
Назначение профилей
-------------------
После создания профиля вы можете назначать его пользователям
базы данных. Каждому пользователю в любой момент времени может
быть назначен лишь один профиль. При назначении профиля
пользователю, уже имеющему профиль, новый профиль перекрывает
ранее назначенный профиль. Назначение профиля не влияет на
текущие сессии пользователя. Профили могут назначаться только
пользователям, но не ролям и не другим профилям.
Для назначения профилей пользователям можно использовать диалоги
SQL*DBA Create User и Alter User, а также команды SQL CREATE
USER и ALTER USER. См. секции "Создание пользователей" на
странице 11-7 и "Изменение пользователей" на странице 11-11 для
дополнительной информации о назначении профиля пользователю.
Изменение профилей
------------------
Для изменения значений лимитов в любом профиле можно
использовать либо диалоговое окно SQL*DBA Alter Profile, либо
команду SQL ALTER PROFILE. Рис.11-5 показывает диалоговое окно
Alter Profile.
Управление пользователями и ресурсами 11-17
Рис.11-5
Диалог Alter Profile
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ г====================== Alter Profile ======================¦
¦¦ ¦ Profile: ¦
¦¦ ¦ -------------------------------------------------------¬ ¦
¦¦ ¦ ¦ CLERK ¦ ¦
¦¦ ¦ ¦ DBA ¦ ¦
¦¦ ¦ ¦ DEFAULT ¦ ¦
¦¦ ¦ L------------------------------------------------------- ¦
¦¦ ¦ [ ] Sessions/User ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [ ] CPU Time/Session ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [X] CPU Time/Call ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [ ] Connect Time ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [ ] Idle Time ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [X] Logical Reads/Session (o) Limit: 20000 ( ) Unlimited ¦
¦¦ ¦ [ ] Logical Reads/Call ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [ ] Private SGA/Session ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦ [ ] Composite Limit ( ) Limit: ----- ( ) Unlimited ¦
¦¦ ¦-----------------------------------------------------------¦
¦+-¦ Mandatory (OK) (Cancel) ¦
¦¦ L===========================================================¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Alter Profile, показанного на рис.11-5:
ALTER PROFILE clerk LIMIT
CPU_PER_CALL default
LOGICAL_READS_PER_SESSION 20000;
Любое значение лимита, специфицированное при изменении профиля,
перекрывает предыдущее значение для этого лимита. Значение
DEFAULT заставляет указанный лимит вернуться к его умалчиваемому
значению в базе данных (см. "Использование умалчиваемого
профиля" на странице 11-17). Все лимиты, не затрагиваемые
изменением, сохраняют свое прежние значения. Любые изменения
лимитов не действуют на текущие сессии; новые значения лимитов в
профиле будут иметь силу лишь для сессий, создаваемых после
изменения профиля.
Привилегии, требуемые для изменения профиля
Для изменения профиля вы должны иметь системную привилегию ALTER
PROFILE.
Использование составных лимитов
-------------------------------
Помимо явного задания конкретных ресурсных лимитов, в профиле
может быть также установлен единственный составной лимит,
который учитывает всю смесь ресурсов системы. Составной лимит
профиля может быть установлен через переключатель Composite
Limit диалоговых окон Create Profile или Alter Profile SQL*DBA,
либо с помощью параметра COMPOSITE_LIMIT команд SQL CREATE
PROFILE или ALTER PROFILE. Составной лимит задается в ЕДИНИЦАХ
СЕРВИСА. Единица сервиса представляет собой взвешенную сумму
всех используемых ресурсов. Например, следующее предложение
CREATE PROFILE определяет профиль, в котором используется
составной лимит:
11-18 Руководство администратора
CREATE PROFILE clerk LIMIT
COMPOSITE_LIMIT 20000
SESSIONS_PER_USER 2
CPU_PER_CALL 1000;
Заметьте, что в профиле могут одновременно существовать как
явные лимиты ресурсов, так и составной лимит. Лимит,
достигнутый первым, приводит к прекращению работы сессии.
Составной лимит добавляет дополнительную гибкость в ограничение
использования системных ресурсов.
Корректная установка количества единиц сервиса для составного
лимита зависит от общего объема ресурсов, используемых средним
пользователем профиля. Как и для каждого конкретного ресурсного
лимита, для определения нормального диапазона изменений
составного ресурса необходимо собрать историческую информацию
для типичных пользователей профиля.
Каждая система имеет свой набор характеристик; одни ресурсы
системы могут быть более ценны, чем другие. Поэтому ORACLE
также позволяет вам назначить каждому системному ресурсу
СТОИМОСТЬ. Стоимость взвешивает каждый ресурс системы на уровне
базы данных. Стоимости применяются лишь для расчета составного
лимита профиля; они не применяются для явного задания
индивидуальных ресурсных лимитов.
Стоимость может быть назначена лишь некоторым системным
ресурсам, включая CPU_PER_SESSION, LOGICAL_READS_PER_SESSION,
CONNECT_TIME и PRIVATE_SGA. Для установления стоимостей
ресурсов в базе данных можно использовать диалоговое окно Alter
Resource Cost SQL*DBA или команду SQL ALTER RESOURCE COST.
Рис.11-6 показывает диалоговое окно Alter Resource Cost.
Управление пользователями и ресурсами 11-19
Рис.11-6
Диалог Alter Resource Cost
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦¦ г===== Alter Resource Cost ====¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ CPU Time/Session: 1---- ¦ ¦
¦¦ ¦ Connect Time: ----- ¦ ¦
¦¦ ¦ Logical Reads/Session: 50--- ¦ ¦
¦¦ ¦ Private SGA/Session: ----- ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦------------------------------¦ ¦
¦¦ ¦ (OK) (Cancel) ¦ ¦
¦¦ L==============================- ¦
¦+-------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Alter Resource Cost, показанного на рис.11-6:
ALTER RESOURCE COST
CPU_PER_SESSION 1
LOGICAL_READS_PER_SESSION 50;
Большая стоимость означает, что ресурс очень дорогой, тогда как
маленькая стоимость означает, что ресурс недорогой. По
умолчанию, каждому ресурсу первоначально приписана нулевая
стоимость. Нулевая стоимость означает, что данный ресурс не
засчитывается в составном лимите (т.е. использование этого
ресурса ничего не стоит). Пустая стоимость (NULL) не может быть
назначена никакому ресурсу. Обратитесь к вашему руководству по
инсталляции [IUG] для дополнительной информации и рекомендаций
по установке стоимости ресурсов.
Привилегии, требуемые для установки стоимости ресурсов
Для установки стоимости ресурсов вы должны иметь системную
привилегию ALTER RESOURCE.
Удаление профилей
-----------------
Для удаления профиля можно использовать либо диалоговое окно
SQL*DBA Drop Profile, либо команду SQL DROP PROFILE. Рис.11-7
показывает диалоговое окно Drop Profile.
11-20 Руководство администратора
Рис.11-7
Диалог Drop Profile
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г=============== Drop Profile =================¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Profile: ¦ ¦
¦¦ ¦ --------------------------------------------¬¦ ¦
¦¦ ¦ ¦ CLERK ¦¦ ¦
¦¦ ¦ ¦ DBA ¦¦ ¦
¦¦ ¦ ¦ ¦¦ ¦
¦¦ ¦ L--------------------------------------------¦ ¦
¦¦ ¦ [X] Reassign Profile Users to Default Profile¦ ¦
¦¦ ¦----------------------------------------------¦ ¦
¦¦ ¦ Mandatory (OK) (Cancel) ¦ ¦
¦¦ L==============================================- ¦
¦+-------------------------------------------------------------+
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Чтобы успешно удалить профиль, который был назначен
пользователю, необходимо выбрать переключатель Drop Even If
Currently Assigned.
Следующее предложение является командным эквивалентом
диалогового окна Drop Profile, показанного на рис.11-7:
DROP PROFILE clerk CASCADE;
Любой пользователь, которому был назначен удаляемый профиль,
автоматически получает вместо него профиль DEFAULT. Профиль
DEFAULT не может быть удален. Заметьте, что удаление профиля не
затрагивает текущих активных сессий; оно будет замечено лишь в
сессиях, создаваемых впоследствии.
Привилегии, требуемые для удаления профиля
Для удаления профиля вы должны иметь системную привилегию DROP
PROFILE.
Включение и выключение ресурсных лимитов
----------------------------------------
Профиль может создаваться, назначаться пользователям, изменяться
и удаляться любым полномочным пользователем базы данных; однако
ресурсные лимиты, установленные в профиле, будут действовать
лишь тогда, когда вы включите режим лимитирования системных
ресурсов в ассоциированной базе данных. Включение и выключение
лимитирования ресурсов можно осуществлять двумя различными
способами, как описано в следующих двух секциях.
Включение и выключение ресурсных лимитов перед запуском
Если базу данных можно на время остановить, то вы можете
включить или выключить лимитирование ресурсов через параметр
инициализации RESOURCE_LIMIT в файле параметров базы данных.
Действительными значениями этого параметра являются TRUE
(включает лимитирование) и FALSE; по умолчанию принимается
Управление пользователями и ресурсами 11-21
FALSE. После редактирования файла параметров необходимо
остановить и перезапустить базу данных, чтобы изменение режима
лимитирования имело эффект. При каждом запуске инстанции
значение этого параметра определяет действующий режим
лимитирования ресурсов.
Включение и выключение ресурсных лимитов при открытой базе данных
Если базу данных нельзя останавливать, или если изменение режима
лимитирования ресурсов необходимо изменить на время, то вы
можете включить или выключить лимитирование ресурсов с помощью
команды ALTER SYSTEM. Значение, специфицируемое в команде ALTER
SYSTEM, перекрывает значение параметра инициализации
RESOURCE_LIMIT. Например, следующее предложение включает режим
лимитирования ресурсов для базы данных:
ALTER SYSTEM
SET RESOURCE_LIMIT = TRUE;
Однако предложение ALTER SYSTEM изменяет режим лимитирования
ресурсов не на постоянной основе; после останова и повторного
запуска базы данных, режим лимитирования ресурсов определяется
значением параметра инициализации RESOURCE_LIMIT.
Привилегии, требуемые для включения и выключения ресурсных лимитов
Для изменения режима лимитирования системных ресурсов при
открытой базе данных вы должны иметь системную привилегию ALTER
SYSTEM.
----------------
Вывод информации о пользователях и профилях
Словарь данных хранит информацию о каждом пользователе и каждом
профиле, включая:
* всех пользователей в базе данных
* умалчиваемое табличное пространство каждого пользователя
* временное табличное пространство каждого пользователя
* квоты табличных пространств каждого пользователя
* профили и ресурсные лимиты для каждого пользователя
* стоимость, назначенную каждому системному ресурсу
* использование памяти для каждой текущей сессии
Следующие обзоры словаря данных представляют интерес в том, что
касается информации о пользователях и профилях:
11-22 Руководство администратора
* ALL_USERS
* USER_USERS
* DBA_USERS
* USER_TS_QUOTAS
* DBA_TS_QUOTAS
* USER_RESOURCE_LIMITS
* DBA_PROFILES
* RESOURCE_COST
* V$SESSION
* V$SESSTAT
* V$STATNAME
Обратитесь к приложению B для подробной информации о каждом из
этих обзоров.
Примеры
-------
Примеры этой секции предполагают, что в базе данных были
выполнены следующие предложения:
CREATE PROFILE clerk LIMIT
SESSIONS_PER_USER 1
IDLE_TIME 30
CONNECT_TIME 600;
CREATE USER jward
IDENTIFIED BY wildcat
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp_ts
QUOTA 500K ON users
PROFILE clerk;
CREATE USER tsmith
IDENTIFIED BY bedrock
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp_ts
QUOTA unlimited ON users;
Пример 1:
Вывод всех пользователей и ассоциированной информации
SELECT * FROM sys.dba_users;
USERNA USER_ID PASSWORD DEFAUL TEMPOR CREATED PROFILE
------ ------- -------------- ------ ------ --------- --------
SYS % 522D06CDE017CF93 SYSTEM SYSTEM 31-JUL-90 PUBLIC_DEFAULT
SYSTEM % 9B30B3EB7A7EE46A SYSTEM SYSTEM 31-JUL-90 PUBLIC_DEFAULT
JWARD % DEE4F647381D62C4 USERS TEMP_TS 12-SEP-90 CLERK
TSMITH % 4791F162172E7834 USERS TEMP_TS 12-SEP-90 PUBLIC_DEFAULT
Управление пользователями и ресурсами 11-23
Все пароли выдаются в зашифрованном виде.
Пример 2:
Вывод ролей пользователей
Следующий запрос выдает, для каждого пользователя, все роли,
назначенные этому пользователю, и указывает, назначена ли роль с
опцией ADMIN OPTION и является ли она умалчиваемой:
SELECT * FROM sys.dba_role_privs WHERE grantee = 'CCLOSKEY';
GRANTEE GRANTED_ROLE ADM DEF
-------------------------- ------------------------- --- ---
CCLOSKEY CLERK YES YES
CCLOSKEY PAYROLL NO NO
CCLOSKEY WEEKLY_ADMIN NO NO
Пример 3:
Вывод всех квот табличных пространств
Следующий запрос выдает все квоты табличных пространств, которые
были назначены пользователям.
SELECT * FROM sys.dba_ts_quotas;
TABLESPACE USERNAME BYTES MAX_BYTES BLOCKS MAX_BLOCKS
---------- --------- ---------- ---------- --------- ----------
SYSTEM SYSTEM 0 0 0 0
SYSTEM JWARD 0 512000 0 250
SYSTEM TSMITH 0 -1 0 -1
Когда назначаются конкретные квоты, точное число указывается в
столбце MAX_BYTES. Неограниченные квоты отмечаются "-1".
11-24 Руководство администратора
Пример 4:
Вывод всех профилей и назначенных лимитов
Следующий запрос выдает все профили в базе данных и
ассоциированные значения для каждого лимита в каждом профиле:
SELECT * FROM sys.dba_profiles
ORDER BY profile;
PROFILE RESOURCE_NAME LIMIT
---------------- --------------------------------- -------------
CLERK COMPOSITE_LIMIT UNLIMITED
CLERK SESSIONS_PER_USER 1
CLERK CPU_PER_SESSION UNLIMITED
CLERK CPU_PER_CALL UNLIMITED
CLERK LOGICAL_READS_PER_SESSION UNLIMITED
CLERK LOGICAL_READS_PER_CALL UNLIMITED
CLERK IDLE_TIME 30
CLERK CONNECT_TIME 600
CLERK PRIVATE_SGA UNLIMITED
DEFAULT COMPOSITE_LIMIT UNLIMITED
DEFAULT SESSIONS_PER_USER UNLIMITED
DEFAULT CPU_PER_SESSION UNLIMITED
DEFAULT CPU_PER_CALL UNLIMITED
DEFAULT LOGICAL_READS_PER_SESSION UNLIMITED
DEFAULT LOGICAL_READS_PER_CALL UNLIMITED
DEFAULT IDLE_TIME UNLIMITED
DEFAULT CONNECT_TIME UNLIMITED
DEFAULT PRIVATE_SGA UNLIMITED
Пример 5:
Вывод использования памяти по сессиям пользователей
Следующий запрос выдает все текущие сессии, показывая
пользователя ORACLE и текущую память для каждой сессии:
SELECT username, value || 'bytes' "Current session memory"
FROM v$session sess, v$sesstat stat, v$statname name
WHERE sess.sid = stat.sid
AND stat.statistic# = name.statistic#
AND name.name = 'session memory';
Количество памяти, выдаваемое в столбце "Current session
memory", отражает память, распределенную в разделяемом пуле для
каждой сессии, соединенной через многоканальный сервер. Вы
можете ограничивать объем памяти, распределяемой на
пользователя, с помощью ресурсного лимита PRIVATE_SGA.
Чтобы выдать максимальное количество памяти, которое было
распределено каждой сессии с момента старта инстанции, замените
в приведенном выше запросе 'session memory' на 'max session
memory'.