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

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

Физическая база данных может содержать много учетных разделов пользователей Oracle, которые защищены паролями. Необходимо ввести имя пользователя и пароль независимо от того, какой инструмент используется для получения доступа к базе данных. Роли - это не то же самое, что пользователи Oracle.

14.8 Протоколирование (аудит)

Механизм протоколирования Oracle обеспечивает три типа протоколов. Протокол привилегий прослеживает, какие системные привилегии используются. Протокол операторов отслеживает, какие операторы SQL используются для всех объектов. Протокол объектного уровня контролирует доступ к объектам. Можно запустить эти протоколы, чтобы проследить, когда операторы отрабатываются успешно и когда они терпят неудачу. Можно использовать протоколирование, чтобы отследить любую попытку вторжения в систему.

Кроме того, можно устанавливать, что записывается в протокол. Может записываться один элемент на операцию независимо от того, сколько попыток выполнить операции было сделано в течение сеанса соединения. Или, альтернативно, записывается один элемент протокола для каждой попытки (успешной или нет) операции в течение сеанса.

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

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

15. Резервное копирование и восстановление

15.1 Различные типы сбоев

Основные типы сбоев: сбой оператора SQL, сбой пользовательского процесса, машинный сбой, сбой распределенной транзакции, сбой экземпляра и дисковый сбой/потеря файла.

15.1.1 Сбой оператора SQL

В Oracle такой оператор DML, как UPDATE, выполняется или для всех строк, удовлетворяющих предложению WHERE, или вообще ни для одной из них.

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

Другие операторы DML в транзакции остаются в отложенном состоянии, готовом для фиксации или отката транзакции.

15.1.2 Сбой пользовательского процесса

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

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

15.1.3 Машинный сбой

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

Оператор COMMIT пишет изменения только в журнальные файлы; он не записывает блоки данных на диск в момент, когда выполняется фиксация транзакции. Если блоки базы данных с зафиксированными изменениями записаны в файлы базы данных перед машинным сбоем, фоновый процecc SMON, очевидно, не должен повторять изменения для этих блоков.

15.1.4 Сбой экземпляра

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

15.1.5 Сбой распределенной транзакции

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

15.1.6 Дисковый сбой/потеря файла

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

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

15.2 Холодное резервное копирование

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

Если выполняется только холодное резервное копирование, единственной возможностью, доступной в случае потери файла данных, является восстановление всех файлов из последней резервной копии. Вся работа с БД, выполненная начиная с последнего резервного копирования, теряется.

15.2.1 Архивирование

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

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

С опцией архивирования не будет потеряно никаких изменений в базе данных, если доступен полный набор журнальных файлов. Все изменения, фиксированные перед потерей файла, повторяются. Если потеряны управляющие или журнальные файлы, их восстановление также возможно.

15.3 Горячее резервное копирование

Некоторые системы (такие как системы заказа авиабилетов) не допускают остановки, базы данных для создания резервной копии. Холодное резервное копирование здесь - недоступная роскошь.

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

Для выполнения горячего резервного копирования база данных должна выполняться в режиме ARCHIVELOG.

Если происходит сбой с потерей данных, можно восстанавливать потерянные файлы базы данных, иcпользуя горячие резервные копии и оперативные и автономные журнальные файлы, созданные с момента резервного копирования. База данных восстанавливается в актуальное состояние без каких-либо потерь фиксированных транзакций.

15.4 Экспорт и импорт

Наряду с возможностями самой СУБД, Oracle предлагает две утилиты, который могут использоваться для резервного копирования и восстановления базы данных. Эти утилиты полезны администраторам базы данных для создания копий всей системы, а также разработчикам приложений для временного резервного копирования своих данных и объектов и восстановления в собственные учетные разделы пользователя.

Утилита Export выводит дамп определений и данных для специфицированной части базы данных в двоичный файл операционной системы. Утилита Import читает файл, порожденный программой Export, воссоздает определения объектов и вставляет данные.

Для импорта полной базы данных должна существовать шаблонная база данных.

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

Для больших, заполненных данными баз данных выполнение утилит Export и Import может потребовать и длительного времени; много часов -- не редкость. Однако эти утилиты обеспечивают возможность выборочного экспортирования и импортирования, различных учетных разделов пользователей и даже отдельных объектов.

16. Мультиплексирование

16.1 Управляющие файлы

Чтобы защититься от потери управляющего файла, СУБД Oracle может поддерживать больше одной копии этого файла, для чего достаточно сделать согласованные копии существующего управляющего файла и изменить параметры INIT.ORA. Дублирование незначительно влияет на производительность базы данных. Если все копии управляющего файла потеряются, можно вручную восстановить их, используя команду

CREATE CONTROLFILE

16.2 Журнальные файлы

В журнал записывают все изменения в блоках данных базы данных. Если база данных функционирует в режиме ARCHIVELOG и потеряны только автономные журнальные файлы, следует закрыть базу данных и выполнить резервное копирование всех трех наборов файлов БД.

Если, однако, потеряны оперативные журнальные файлы, можно потерять часть работы, поскольку некоторая часть информации, необходимой для воспроизведения изменений файлов базы данных, находится в журнальных оперативных файлах. Чтобы это предотвратить, можно мультиплексировать (дублировать) оперативные журнальные файлы таким же образом, как управляющий файл. Когда программное обеспечение СУБД записывает изменения в один из журнальных файлов, та же информация записывается в точную копию этого файла.

17. Распределенные базы данных

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

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

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

Распределенная транзакция - транзакция, которая изменяет таблицы нескольких баз данных и затем ожидает фиксации всех изменений. Если где-либо происходит сбой, все изменения на всех базах данных отменяются. Двухфазный механизм фиксации транзакций Oracle управляет синхронизацией фиксаций во всех базах данных и может автоматически отменять изменения во всех базах данных, если происходит какой-либо сбой. Фоновый процесс RECO синхронизирует эту операцию.

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

Снимок создается для той базы данных, какую нужно скопировать. СУБД Oracle автоматически посылает какие-либо изменения, сделанные в главной копии таблицы, в каждую из копий-снимков через определенные пользователем интервалы времени без какого-либо ручного вмешательства.

Механизм снимка допускает модификации в снимке таблицы, при этом изменения посылаются из таблицы-копии обратно в главную таблицу.

17.1 Поддержка национальных языков

Средство поддержки национальных языков Oracle (National Language Support -- NLS) позволяет пользователям использовать базу данных на их собственных языках. Это средство обеспечивает следующие функции:

1) Поддержка различных схем кодирования, т.е. данные, созданные в схеме кодирования на одной машине, могут быть обработаны и представлены на другой. Для этого определяется символьный набор, который будет использоваться для хранения данных в базе данных, как часть оператора CREATE DATABASE.

2) Управление языком вывода ошибок сервера и информационных сообщений, чисел; дат, форматов, валюты и начального дня недели.

3) Поддержка лингвистической сортировки гарантирует, что символы появляются в корректном порядке.

4) Определение языка NLS осуществляется как для базы данных в целом, так и на уровне сеанса. Изменяя параметры сеанса, но не внося изменений в учетный раздел пользователя Oracle, можно выполнять одни сеансы на английском языке, другие на немецком и т.д., если одно имя пользователя Oracle соединено с базой данных через несколько различных сеансов.

17.2 Прохождение оператора SQL через архитектуру

Здесь показано как соединяются основные части архитектуры Oracle и отслежены этапы выполнения типичного оператора SQL. Для простоты будем говорить об Oracle SQL*Plus и машине сервера базы данных на платформе UNIX без какой-либо сети. Пусть экземпляр Oracle только что запущен в однозадачной конфигурации.

Алгоритм выполнения оператора SQL:

1) Пользователь запускает инструмент SQL*Plus и вводит имя пользователя Oracle и пароль.

2) Oracle подтверждает имя пользователя и пароль, сверившись со словарем данных, и посылает ответ пользовательскому процессу для подтверждения соединения.

3) Пользователь вводит оператор SELECT.

4) Oracle должен произвести разбор SELECT прежде, чем выполнить его, поэтому вызывается синтаксический анализатор и оптимизатор Oracle. Если бы какой-либо пользователь ранее уже ввел точно такой же оператор, "разобранная" версия могла бы находиться в области разделяемого пула в памяти. Oracle в этом случае использует результаты разбора, так что для данного оператора никакой дополнительный анализ не выполняется.

5) Чтобы транслировать оператор SELECT, Oracle должен получить имена объектов, привилегий и другую информацию из словаря данных. Область кэша словаря данных в разделяемом пуле в SGA не содержит информации о таблицах, поэтому анализ оператора SELECT приостанавливается для считывания информации.

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

7) Разбор исходного пользовательского оператора SELECT продолжается, и Oracle строит план оптимизации, чтобы определить способ выполнения оператора.

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

9) Oracle выполняет оператор и возвращает результаты пользователю.

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

11) Oracle блокирует строки, которые будут модифицироваться.

12) Прежде чем Oracle выполняет UPDATE, информация старого состояния блоков регистрируется в сегменте отката, а исходная версия значений также записывается в буферном кэше журнала.

13) Oracle модифицирует строки и записывает новую версию значений в буферном кэше журнала.

14) Пользователь вводит команду COMMIT, чтобы сделать изменение в базе данных окончательным.

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

16) Сегмент отката освобождается (но не перезаписывается) для использования другими процессами.

17) Oracle освобождает блокировки в таблице.

18) Пользователь получает сообщение об успешной фиксации транзакции (точная формулировка этого сообщения изменяется в зависимости от инструмента и версии).

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

18. Безопасность

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

* Управление работой пользователей и аутентификация

* Управление привилегиями и ролями

* Ограничение использования ресурсов баз данных

* Работа с паролями пользователей

* Аудит баз данных

18.1 Управление работой пользователей

Первой линией защиты от нежелательного проникновения в базы данных является управление доступом к системе. Чтобы пользователь мог соединиться с базой данных Oracle, он должен иметь в ней имя (username). Создавать имена пользователей можно при помощи SQL-команды CREATE USER.

18.2 Аутентификация пользователей

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

18.2.1 Аутентификация по паролю

Oracle может опознавать имя пользователя по паролю {password). Когда пользователь запускает приложение, оно требует ввести имя и соответствующий этому имени, пароль. Затем Oracle проверяет подлинность запроса на соединение с помощью информации, содержащейся в учетных сведениях пользователя, которые управляются базой данных. Аутентификация по паролю распространена в системах клиент/сервер Oracle, когда пользователи соединяются с сервером баз данных Oracle при помощи клиентских машин. программный сетевой файл

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

18.2.2 Аутентификация операционной системы

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

18.2.3 Аутентификация глобального имени пользователя

Oracle может опознавать глобальное имя пользователя (global usemame) при помощи внешнего сетевого сервиса. Когда пользователь запускает приложение и запрашивает соединение, Oracle проверяет подлинность запроса с помощью информации о пользователе, управляемой внешним сервисом защиты. В Огас1е8 имеется собственный сервис защиты, Oracle Security Server, который можно применять для работы с глобальными пользователями баз данных. Аутентификация глобального имени пользователя распространена в тех сетевых средах, где требуется доступ к нескольким базам данных Oracle, а сеть не всегда достаточно защищена.

18.3 Табличная область пользователя

18.3.1 Табличная область по умолчанию

Табличная область (tablespace) -- это логический элемент хранения базы данных, который организует физическое хранение ее информации. Для каждого пользователя базы данных можно задать табличную область по умолчанию (defaiili tablespace). Когда пользователь создает новый объект базы данных, например таблицу или индекс, и не указывает табличную область для этого объекта явно, Oracle сохраняет этот объект в таблнчной областн по умолчанию для этого пользователя. Если не указано обратное, то табличной областью по умолчанию для пользователя являсгся область SYSTEM.

18.3.2 Временная табличная область пользователя

Часто для выполнения SQL-операторов необходимо временное рабочее пространство. Например, для запроса, который соединяет и сортирует большой объем данных, может потребоваться временное рабочее пространство для построения результирующего множества данных. При необходимости Oracle ныделяет такое пространство для SQL-операторов пользователя во временной таблнчной области (temporary tablespace) этого пользователя. Если не указано обратное, то временной табличной областью пользователя является табличная область SYSTEM.

18.4 Блокированные и разблокированные учетные сведения пользователей

В Oracle можно управлять доступом к базам данных, блокируя (lock) и разблокируя (unlock} в любое удобное время учетные сведения пользователей. Когда учетные сведения пользователя заблокированы, он не может соединиться с Oracle. Чтобы затем разрешить пользователю обращаться к базам данных посредством своих учетных сведений, необходимо их разблокировагь. Для чего же блокируются и разблокируются учетные сведения пользователей?

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

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

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

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

18.5 Работа с привилегиями

Пользователи системы баз данных Oracle не могут соединяться с сервером баз данных или выполнять какие-либо существенные действия, если они не имеют привилегий {privileges) .на проведение определенных операций с базами данных,: Например, пользователь базы данных не может:

* Соединяться с базой данных Oracle, не имея .системной привилегии CREATE SESSION (установить сеанс)

* Создавать таблицы в соответствующей схеме, не имея системной привилегии CREATE TABLE (создать таблицу)

* Удалять строки из какой-либо таблицы другой схемы, не имея объектной привилегии DELETE (удалить) для этой таблицы

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

18.5.1 Типы привилегий

Существуют два различных типа привилегий, управляющих доступом к базам данных Oracle: системные привилегии и объектные привилегии.

18.5.2 Системные привилегии

Системная привилегия (system privilege) -- это мощная привилегия, которая предоставляет пользователю возможность выполнять системную операцию определенного вида. Для примера ниже приведены некоторые из почти ста системных привилегий, существующих в Oracle

* С помощью системной привилегии CREATE SESSION (установить сеанс) пользователь может соединяться с сервером баз данных и устанавливать сеанс связи с базой дайных.

* С помощью системной привилегии CREATR TABLE (создать таблицу) пользователь может создавать таблицы в своей собственной схеме.

* С помощью системной привилегии CREATE ANY TABLE (создать любую таблицу) пользователь может создавать таблицы в любой схеме базы данных.

* С помощью системной привилегии CREATE ANY TYPE (создать любой тип) пользователь может создавать типы и тела соответствующих типов в любой схеме базы данных.

* С помощью системной привилегии SELECT ANY TABLE (выбрать любую таблицу) пользователь может обращаться с запросами к любой таблице базы данных.

* .С помощью системной привилегии EXECUTE ANY PROCEDURE (выполнить, пробую процедуру) пользователь может выполнять любую хранимую процедуру, хранимую функцию или модульный компонент базы данных,

* С помощью системной привилегии EXECUTE ANY TYPE (выполнить любой тип) пользователь может ссылаться на методы любого типа базы данных, а также выполнять их.

Системные привилегии могут влиять на безопасность всей системы баз данных, поэтому необходимо учитывать, что:

* Администратор базы данных является единственным пользователем, который должен иметь мощную системную привилегию ALTER DATABASE (изменить базу данных), позволяющую изменять физическую структуру и доступность системы баз данных.

* Разработчикам, обычно необходимо несколько системных привилегий для построения схем баз данных, обеспечивающих работу приложений клиентов. В числе этих системных привилегий CREATE TABLE (создать габлицу). CREATE VTEW (создать представление) и CREATE. TYPE (создать тип).

* Каждый пользователь системы обычно имеет системную привилегию CREATE SESSION (установить сеанс), которая разрешает пользователю соединяться с сервером баз данных.

18.5.3 Объектные привилегии

Объектная привилегия {object privilege) предоставляет пользователю возможность выполнять операцию определенного вида с конкретным объектом, базы данных, например с таблицей, с представлением или с хранимой процедурой. Например: I

* С помощью объектной привилегии SELECT (выбрать) для представления CUST пользователь может обращаться с запросами к этому представлению и считывать необходимую информацию.

* С помощью объектной привилегии INSERT (ввести) для таблицы CUSTOMERS пользователь может вводить в нее новые строки.

* С помощью привилегии EXECUTE (выполнить) для объектного типа PART_TYPE пользователь может применять этот тип при создании других объектов базы данных и выполнять методы этого типа.

18.5.4 Предоставление и отмена привилегий

Дать пользователю системную или объектную привилегию можно с помощью SQL-команды GRANT (предоставить), а лишить привилегии можно с помощью SQL-команды REVOKE (отменить). Предоставлять и отменять привилегии пользователей могут только конкретные лица. Управляя какой-либо системой и привилегиями пользователей необходимо помнить, что:

* Предоставить системную привилегию может лишь пользователь, имеющий системную привилегию с правами администратора на предоставление привилегий другим пользователям.

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

18.5.5 Работа с привилегиями при помощи ролей

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

18.6 Система ролей в базе данных

18.6.1 Предварительно установленные роли базы данных

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

CONNECT Основная роль пользователей, которая позволяет соединяться с базой данных, а затем создавать таблицы, представления, синонимы, последовательности, связи баз данных и кластеры данных в соответствующей схеме.

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

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

SELECT_CATALOG_ROLE Позволяет обращаться с запросами к представлениям словаря данных, созданным администратором.

DELETE_CATALOG_ROLE Позволяет удалять записи из журнала аудита базы данных

EXECUTE_CATALOG_ROLE Позволяет выполнять модули утилиты RDBMS

EXP_FULL_DATABASE Позволяет экспортировать и импортировать информацию,

IMP_FULL_DATABASE содержащуюся в базе данных, при помощи утилит экспорта и импорта

18.6.2 Роли, определяемые пользователями

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

18.6.3 Разрешение и запрещение ролей

Пользователь, которому предоставлена роль, не всегда имеет доступ к ее привилегиям. В Oracle приложения могут разрешать и запрещать роли для любого пользователя. После того как приложение разрешает (enables) роль для пользователя, ему становятся доступны ее привилегии. И. соответственно, когда приложение запрещает (disables) роль для пользователя. он более не имеет доступа к ее привилегиям. Возможность динамически управлять набором привилегий позволяет приложениям обеспечивать постоянную корректность наборов привилегий пользователей во время работы с данным приложением. Например, когда пользователь запускает приложение по вводу заказов, с помощью SQL-команды SET ROLE это приложение разрешает ему применять для работы заранеее определенную для этого приложения роль. Когда пользователь завершает свою работу, приложение запрещает для него эту роль и он не может применять привилегии приложения по вводу заказов во время работы с другим приложением.

18.6.4 Роли по умолчанию

Каждый пользователь имеет перечень ролей по умолчанию (default roles). Их Oracle создает автоматически при установлении пользователем нового сеанса связи с базой данных. Они удобны, когда нужно разрешить роли, необходимые пользователю во время работы с Oracle, независимо от того, какое приложение он применяет.

18.6.5 Аутентификация ролей

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

18.7 Ограничение использования ресурсов

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

18.7.1 Квоты для табличных областей

Пользователь не может создавать объекты в табличной области, если он не имеет квоты (quota) для нее. Квота для табличной области устанавливает максимальное пространство, которое в этой области могут занимать объекты пользователя. Пользователь по желанию может иметь квоты для 0, для 1 или для всех табличных областей базы данных. Когда ему предоставляется некоторая квота, ее нужно указывать либо определенным числом байтов, либо как неограниченный объем пространства табличной области.

Когда пользователю необходима неограниченная квота для каждой табличной области базы данных, можно не устанавливать неограниченные квоты для всех табличных областей системы, а предоставить ему системную привилегию UNLIMITED TABLESPACE (неограниченная табличная область). V ВНИМАНИЕ

18.7.2 Наборы параметров для ограничения ресурсов

Чтобы управлять потреблением ряда других ресурсов системы, можно использовать наборы параметров для ограничения ресурсов. Набор параметров для ограничения ресурсов (resource limit profile) -- это группа конкретных установок для ограничения ресурсов, назначаемых одному или нескольким пользователям базы данных. С помощью такого набора можно ограничивать потребление:

* Времени центрального процессора (в сотых долях секунды) -- на сеанс или на оператор

* Числа логических операций ввода/вывода -- на сеанс или на оператор

* Параллельных сеансов связи с базой данных -- для пользователя

* Максимального времени соединения и времени простоя (в минутах) -- на сеанс

* Максимального объема памяти сервера, доступной для сеанса связи с многопоточным сервером

18.7.3 Робота с учетными сведениями пользователей

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

* Числом последовательных неудачных попыток установить соединение, после чего Oracle блокирует учетные сведения.

* Сроком действия (в днях) пароля учетных сведений, ограничивающим его существование.

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

* Числом дней, которое должно пройти, или числом изменений пароля пользователя, перед тем, как он сможет снова использовать старый пароль.

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

18.7.4 Набор параметров для ограничения ресурсов по умолчанию

Каждая база данных Oracle имеет набор параметров для ограничения ресурсов по умолчанию (default resourse limit profile). Когда для создаваемого пользователя базы данных конкретный набор параметров не указывается, Oracle автоматически присваивает этому пользователю набор параметров по умолчанию. Все параметры этого набора по умолчанию устанавливаются неограниченными, параметры учетных сведений могут варьироваться.

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

19. Аудит баз данных

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

19.1 Избирательный аудит

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

* Можно выполнять аудит конкретных SQL-операторов безотносительно к конкретным объектам. Например, можно назначать Oracle генерировать запись аудита всякий раз, когда какой-либо пользователь выполняет оператор DROP TABLE, и не учитывать, к какой таблице относится этот оператор

* Можно выполнять аудит использования мощных системных привилегий. Например, назначать Oracle генерировать запись аудита всякий раз, когда какой-либо пользователь применяет системную привилегию SELECT ANY TABLE для запроса к таблице базы данных.

* Можно выполнять аудит определенных SQL-операторов для конкретных объектов базы данных. Например, назначать Oracle генерировать запись аудита всякий раз, когда какой-либо пользователь удаляет запись из таблицы SALES.CUSTOMERS.

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

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

19.2 Записи аудита и журнал аудита

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

Oracle хранит сгенерированные записи аудита в журнале аудита (audit trail}, называемом также контрольным журналом. Журнал аудита -- это место хранения информации аудита. В Oracle разрешается сохранять генерируемые записи аудита либо в журнале аудита базы данных, либо в таком же журнале операционной системы, в которой работает Oracle Server. При использовании журнала аудита базы данных можно легко просматривать и находить записи аудита с помощью SQL-запросов к предварительно созданных для этого журнала представлений словаря данных. При использовании журнала аудита операционной системы можно объединять информацию аудита базы данных с информацией аудита операционной системы.

20. Схемы - организующие объекты базы данных

Каждое приложение баз данных строится на основе набора связанных объектов, в которых хранятся данные конкретного приложения, обеспечивающие его функционирование. Основные объекты Oracle:

- Схемы

- Таблицы

- Ограничения целостности

- Представления

- Индексы и кластеры данных

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

- Синонимы

Связанные объекты базы данных организуются в схему (schema) базы данных, то есть все объекты, необходимые для работы приложения, организованы в схему.

Схемы физически е организуют места хранения объектов баз данных; связанные объекты организуются логически. То есть логическая организация объектов баз данных внутри схем предназначена исключительно для использования преимуществ организации объектов и не имеет ничего общего с физической дисковой памятью, применяемой для хранения объектов баз данных.

Логическая организация, предлагаемая схемами, имеет практическую пользу. Для примера рассмотрим базу данных Oracle с двумя схемами, S1 и S2. В каждой из схем содержится таблица, называемая Т1. Хотя таблицы называются одинаково, каждая из них идентифицируется однозначно, так как они находятся в различных схемах баз данных. Используя стандартную уточняющую запись через точку, можно определить полные имена таблиц как S1.T1 и S2.T1.

Для пояснения различий между логической и физичecкoй организациями можно воспользоваться принципами размещения файлов на диске операционной системой. Компоновка каталогов и файлов в графической программе управления файлами, например, в Microsoft Windows Explorer, совсем не обязательно соответствует физическому местонахождению каталогов и файлов на конкретном диске. Каталоги файлов представляют логическую организацию файлов операционной системы. Базовая операционная система решает, где физически хранить блоки каждого файла, независимо от логической организации каталогов этих файлов.

20.1 Соотношение схем и учетных сведений пользователей баз данных

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

20.2 Словарь данных -- уникальная схема

В каждой из баз данных Oracle ряд системных таблиц, представлений и других объектов применяется для управления метаданными (metadata) -- данными о данных базы данных. Совокупность системных объектов называется словарем данных (data dictionary) или системным каталогом (system catalog) базы данных Oracle. Oracle организует данные, содержащиеся в словаре данных, в схему SYS.

20.3 Таблицы баз данных

Таблицы являются базовыми структурами любой реляционной базы данных. Таблица (table) -- это организованная совокупность записей (records), или строк (rows), имеющих одинаковые атрибуты (attributes), или столбцы (columns).

При создании таблицы в первую очередь нужно обращать внимание:

- На столбцы таблицы, описывающие ее структуру

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

20.3.1 Столбцы и типы данных

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

Oracle поддерживает множество основных типов данных, применяющихся при создании таблиц реляционных баз данных и столбцов этих таблиц.

20.3.2 Наиболее часто используемые типы данных Oracle

Тип данных Описание

CHAR (размер) Сохраняет строки символов фиксированной длины до 2000 байтов

VARCHAR2 (размер) Сохраняет строки символов переменной длины до 4000 байтов

NUMBER (точность, масштаб) Сохраняет числа любого вида

DATE. Сохраняет даты и время .

CLOB Сохраняет однобайтовые символьные большие объекты размером до четырех гигабайтов

BLOB Сохраняет двоичные большие объекты размером до четырех гигабайтов

20.3.3 CHAR и VARCHAR2 -- символьные типы данных Огасlе

CHAR и VARCHAR2 -- типы данных Oracle, наиболее часто используемые для хранения строк символов в столбцах таблиц. Тип данных CHAR удобен для тех столбцов, в которых хранятся строки символов фиксированной длины, например, коды штатов США, состоящие из двух букв. В противоположность этому, тип данных VARCHAR2 полезен для столбцов, содержащих строки символов переменной длины, например, имена, фамилии и адреса. Основное различие между этими двумя типами данных заключается в методе сохранения строк, длина которых меньше размера столбца.

* Если длина строки, содержащейся в столбце CHAR, меньше размера столбца, Oracle заполняет оставшуюся часть строки пробелами для того, чтобы получить строку, по длине соответствующую размеру столбца.

* Если длина строки, содержащейся в столбце VARCHAR2, меньше размера столбца, Oracle сохраняет только строку, не дополняя ее пробелами.

Таким образом, если длина строк в столбце изменяется, их лучше сохранять в столбце, имеющем тип VARCHAR2, а не CHAR.

20.3.4 NUMBER -- числовой тип данных Oracle

Для объявления столбцов, предназначенных для хранения чисел, можно воспользоваться типом данных Oracle, называемым NUMBER. Посредством единственного типа данных Oracle обеспечивается хранение чисел всех типов: целых чисел, чисел с плавающей точкой, действительных чисел и т.д. Можно ограничить диапазон чисел, допустимых для столбца, указав точность (precision) и масштаб (scale) для столбца типа NUMBER.

20.3.5 DATE -- временной тип данных Oracle

Если для столбца таблицы объявляется тип данных DATE, в столбце можно хранить временную информацию любого вида, в том числе даты и время.

20.3.6 CLOB, BLOB и другие -- мультимедийные типы данных Oracle

Базы данных являются защищенными, быстродействующими и безопасными хранилищами данных, поэтому они часто используются в качестве хранилищ информации для мультимедийных приложений. Для обеспечения функционирования таких ресурсоемких приложений в Огас1е8 предлагается несколько различных типов данных больших объектов (LOB - large objects), с помощью которых можно сохранять неструктурированную информацию, например, текстовые документы, статические изображения, видео-, аудиоинформацию и др.

* В столбцах типа CLOB хранятся символьные объекты, например, документы.

* В столбцах типа BLOB хранятся двоичные объекты, например, графические данные, видеокадры или звуковые файлы.

* В столбцах типа BFILE. хранятся указатели файлов на объекты LOB. управляемые файловыми системами, внешними по отношению к базе данных. Например, столбец типа BFILE может быть списком ссылок на имена файлов фотографий, хранящихся на диске CD-ROM.

20.3.7 Сравнение типов денных LOB со старыми типами данных больших объектов Oracle

Для обеспечения обратной совместимости в Огас1е8 продолжают поддерживаться старые типы данных Oracle, разработанные для больших объектов, такие, как LONG и LONG RAW. Однако новые типы данных LOB имеют ряд преимуществ по сравнению со старыми типами данных больших объектов Oracle.

* В таблице может быть несколько столбцов CLOB, BLOB и BFILE, а столбец LONG или LONG RAW может быть только один.

* В столбце таблицы хранятся только небольшие указатели или локаторы (locators) на объекты LOB, а не сами большие объекты. В противоположность этому, данные столбца LONG хранятся непосредственно в таблице.

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

* Приложения могут обращаться к частям объекта LOB и манипулировать ими. К полю же LONG приложения должны обращаться как к атомарной (неделимой) порции данных.

20.3.8 Поддержка национальных языков для символьных типов данных

Средство Oracle, называемое NLS {National Language Support -- поддержка национальных языков), позволяет базам данных сохранять символьные данные на многих, языках и манипулировать ими. В некоторых языках для представления наборов символов требуется несколько байтов. Специальные типы данных Oracle, называемые NCHAR, NVARCHAR2 и NCLOB, являются, типами данных, дополняющими CHAR, VARCHAR2 и CLOB соответственно.

...