Управление транзакциями в Oracle

Модель транзакций реляционной СУБД Oracle основана на «единице работы» (unit of work) и поддерживается большую часть операций над транзакциями (нельзя использовать ROLLBACK FORSE). Транзакция неявно начинается с началом сеанса или при выполнении первой команды SQL после последней команды COMMIT или ROLLBACK (фактически при первом изменении данных). Транзакция заканчивается при выполнении команды COMMIT или ROLLBACK.

Транзакция не зависит от блоков PL/SQL. Транзакции могут охватывать несколько системных блоков, или в одном блоке может быть несколько транзакций (автономных). PL/SQL поддерживает следующие команды для транзакций: COMMIT, ROLLBACK, SAVEPOINT, TRANSACTION и LOCK TABLE.

COMMIT делает изменения в БД постоянными и видимыми для других сеансов в соответствии со следующим синтаксисом:

COMMIT [WORK] [COMMENT текст ];

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

ROLLBACK отменяет не зафиксированные изменения, сделанные в текущей транзакции, влияет до начала транзакции или до указанной точки сохранения.

ROLLBACK [WORK] [ TO [SAVEPOINT] имя_точки_сохранения ];

SAVEPOINT устанавливает точку сохранения (именованную точку обработки) для текущей транзакции. Установка точки транзакции делает возможным выполнение частичного отката.

SAVEPOINT имя_точки_сохранения;

где имя_точки_сохранения – это необъявленный идентификатор. Внутри транзакции может быть установлено несколько точек сохранения. Если повторно использовать имя точки сохранения то точка передвинется на новую позицию и откат к исходной позиции данной точки сохранения будет невозможен.

SET TRANSACTION управляет типом транзакции

SET TRANSACTION тип_транзакции NAME имя

где имя – имя транзакции, доступное на протяжении ее выполнения; а тип_транзакции м ожет принимать следующие значения:

- READ ONLY – означает начало транзакции только для чтения. Указывает СУБД, что следует обеспечить целостность по чтению БД в пределах транзакции (по умолчанию для команды). Транзакцию заканчивают команды COMMIT или ROLLBACK. Внутри такой транзакции разрешены только команды LOCK TABLE, SELECT, SELECT INTO, OPEN, FETCH, CLOSE, COMMIT и ROLLBACK. Попытка выполнения в транзакции только для чтения других команд, такие как INSERT или UPDATE, приводит к появлению ошибки ORA-1456.

- READ WRITE – обозначает начало транзакции READ WRITE; это тип по умолчанию.

- ISOLATION LEVEL SERIALIZABLE – аналогично транзакции READ ONLY обеспечивается целостность по чтению в пределах транзакции вместо поведения по умолчанию – целостности по чтению на уровне команды. Сериализуемые транзакции не позволяют изменять данные.

- ISOLATION LEVEL READ COMMITTED – если транзакции необходимы строки, заблокированные другими транзакциями, она будет ждать снятия блокировки.

- USE ROLLBACK SEGMENT имя_сегмента_отката – указывает СУБД, что следует использовать указанный сегмент отката. Полезна, когда лишь один сегмент отката имеет большой размер, и известно, что программе необходим большой сегмент отката (например, при операции закрытия в конце месяца).

Рис.

LOCK TABLE обходит неявные блокировки БД на уровне строк, явно блокируя целиком одну или несколько таблиц в указанном режиме.

LOCK TABLE список_таблиц IN режим_блокировки MODE [NOWAIT];

где список_таблиц – список таблиц, разделенных запятыми; режим_блокировки – может принимать значения ROW SHARE (SHARE UPDATE), ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE или EXCLUSIVE.

ROW SHARE разрешает конкурирующий доступ к заблокированной таблице, но запрещает пользователям блокировать всю таблицу для эксклюзивного доступа (EXCLUSIVE). ROW SHARE и SHARE UPDATE это синонимы, используются для совместимости синтаксиса более ранних версий.

ROW EXCLUSIVE аналогично ROW SHARE, за исключением того, что дополнительно запрещает блокировать в режиме SHARE. ROW EXCLUSIVE применяется СУБД автоматически при операциях INSERT, UPDATE, DELETE.

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

SHARE ROW EXCLUSIVE используется для просмотра всей таблицы и разрешения пользователям просматривать строки в таблицы, но запрещает другие блокировки в режиме SHARE и запрещает обновлять строки.

EXCLUSIVE разрешает запросы к заблокированной таблице, но запрещает все остальные действия.

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

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

32. ПРИНЦИПЫ ЗАЩИТЫ ДАННЫХ в стандартном SQL

За реализацию системы безопасности отвечает СУБД. Язык SQL является фундаментом системы безопасности реляционной СУБД: требования, предъявляемые к системе защиты информации в базе данных, формулируются с помощью инструкций SQL. С защитой данных в SQL связаны три основные концепции:

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

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

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

Пользователи. Каждому пользователю в реляционной базе данных присваивается идентификатор – краткое имя, однозначно определяющее пользователя для СУБД. Эти идентификаторы являются основой системы безопасности. Каждая инструкция SQL выполняется в СУБД от имени конкретного пользователя. От его идентификатора зависит, будет ли разрешено или запрещено выполнение инструкции. В промышленной базе данных идентификатор пользователя назначается ее администратором. В базе данных на персональном компьютере может быть только один идентификатор пользователя, который обозначает пользователя, создавшего базу данных и являющегося ее владельцем.

На практике ограничения на имена идентификаторов зависят от реализации СУБД. Стандарт SQL1 позволяет идентификатору пользователя иметь длину до восемнадцати символов и требует, чтобы он был допустимым SQL-именем. В некоторых СУБД для мэйнфреймов длина идентификаторов ограничивалась восемью символами. В Sybase и SQL Server идентификатор пользователя может иметь до 30 символов. Если важна переносимость, то лучше всего, чтобы у идентификатора пользователя было не более восьми символов. Следует иметь в виду также и то, что всем пользователям в одном определенном отделе можно присвоить один и тот же идентификатор, так как все они имеют идентичные привилегии.

В стандарте ANSI/ISO вместо термина “идентификатор пользователя” (user-id) употребляется термин идентификатор прав доступа (authorization-id), и он встречается иногда в документации по SQL. С технической точки зрения второй термин является более правильным, так как в действительности идентификатор определяет права или привилегии. Бывают ситуации, когда имеет смысл присвоить нескольким пользователям одинаковый идентификатор. В других ситуациях один пользователь может пользоваться двумя или тремя различными идентификаторами. В промышленной базе данных идентификатор прав доступа может относиться к программам и группам программ, а не к отдельным людям.

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

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

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

В некоторых СУБД реализована своя собственная система безопасности с идентификаторами пользователей и паролями. Например, когда в СУБД ORACLE вы работаете с интерактивной SQL-утилитой, которая называется SQL*Plus, вы вводите имя пользователя и соответствующий пароль.

Защищаемые объекты. Средства защиты в SQL применяются по отношению к отдельным объектам базы данных. В стандарте SQL1 указаны два типа защищаемых объектов – таблицы и представления. Таким образом, каждая таблица и представление могут быть защищены индивидуально. Доступ к ним может быть разрешен для одних пользователей и запрещен для других. Стандарт SQL2 расширяет круг защищаемых объектов, включая в него домены, и пользовательские наборы символов.

В большинстве коммерческих реляционных СУБД дополнительно могут быть защищены и другие объекты. Например, в ORACLE важным объектом базы данных является хранимая процедура. С помощью средств защиты SQL устанавливается, какие пользователи могут создавать и удалять хранимые процедуры и какие пользователи могут их выполнять.

Привилегии. Как уже указывалось привилегии – это права пользователя на проведение тех или иных действий над определенным объектом базы данных. В SQL предоставление тех или иных прав над различными объектами баз данных возможно посредством инструкции GRANT. Обычно инструкцией GRANT пользуется владелец таблицы или представления, чтобы разрешить другим пользователям доступ к этим данным. Особенности данной инструкции рассматриваются ниже в настоящем разделе. Здесь же следует указать, что многие коммерческие СУБД поддерживают набор системных привилегий. Системная привилегия – это мощная привилегия, которая предоставляет пользователю возможность выполнять системную операцию определенного вида.

Отметим, что вопросы создания и использования таких объектов баз данных как хранимые процедуры, функции и модули будут рассмотрены ниже в разделе, посвященном PL/SQL, процедурного языка программирования, который встроен в большинство продуктов корпорации ORACLE – ведущего производителя промышленных СУБД.

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

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

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

create role order_entry;

grant select, insert, update, delete on sales.customers to order_entry;

grant select, insert, update, delete on sales. orders to order_entry;

grant select, insert, update, delete on sales.items to order_entry;

grant select, update on sales.parts to order_entry;

grant order _ entry to smith, alice, george;

В приведенном примере sales – схема базы данных; customers, orders, items, parts – таблицы этой схемы; smith, alice, george – пользователи базы данных, полномочия которых распространяются на объекты схемы sales. Как видно из примера сначала создается роль, а уже затем посредством инструкции GRANT задаются привилегии этой роли. Особенности задания инструкции GRANT рассматриваются ниже, в параграфе “предоставление привилегий”.

Дата добавления: 2014-01-04