45804 (665148), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Удалим важные данные из таблицы:

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

Полученные «старые» данные можно сохранить в базе и ликвидировать последствия ошибки:

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

У администратора базы данных остается все меньше возможностей повредить базу данных. Не секрет, что одной из наиболее распространенных причин сбоев является ошибочное стирание файла базы данных администратором, например, при удалении табличного пространства. В Oracle9i появились файлы, управляемые сервером Oracle (Oracle Managed Files, OMF). При добавлении файла в базу достаточно указать его размер, а его имя будет сгенерировано Oracle. При удалении файла из базы данных Oracle сам стирает его с диска. Таким образом, с администратора базы данных снимается обязанность манипулировать файлами базы данных, а значит, уменьшается вероятность ошибки.

Жизнь администратора базы данных в Oracle9i вообще заметно облегчена, многие рутинные операции по администрированию Oracle выполняет сам. Динамическое изменение параметров экземпляра и автоматическое управление файлами уже упоминалось. Кроме этого, можно заставить Oracle самостоятельно конфигурировать сегменты отката. Администратор должен только создать специальное табличное пространство для хранения информации отката, а необходимое количество сегментов отката оптимального размера создаст сам Oracle. К тому же администратор может задать, сколько времени Oracle должен сохранять информацию отката даже после фиксации транзакции. Это позволяет если не избавиться от знакомой многим ошибки «ORA-1555: snapshot too old», то существенно снизить вероятность ее проявления.

Задача переноса данных из одной базы в другую тоже заметно облегчается. Возможность использования переносимых табличных пространств (transportable tablespaces) раньше существенно ограничивалась требованием одинакового размера блока в базе-источнике и базе-приемнике. В Oracle9i в одной базе данных могут сосуществовать табличные пространства с разным размером блока, так что это ограничение снимается. Используя разные размеры блока в одной базе данных, можно оптимально организовать хранение данных различного характера.

Защита от сбоев – важная, но не единственная задача администратора базы данных. Ничуть не менее важна защита данных от несанкционированного доступа. Одно из решений, предлагаемых Oracle9i для защиты данных – виртуальная собственная база данных (Virtual Private Database, VPD). Это развитие технологии детализированного контроля доступа (Fine-Grained Access Control), реализованной в Oracle8i. Как известно, с помощью этой технологии можно было к любой таблице присоединить набор функций, которые срабатывали при каждом запросе или изменении таблицы. Функция возвращала текстовую строку, которая присоединялась к условию WHERE запроса или DML-оператора и таким образом ограничивала набор строк, которые пользователь мог видеть или изменять. Эти функции обычно использовали так называемый контекст приложения (application context). Контекст приложения можно рассматривать как набор переменных, содержащих атрибуты пользователя, такие как должность пользователя, номер его отдела, уровень допуска и т.п. Контекст обычно заполнялся триггером при входе пользователя в базу данных, и функции детализированного контроля доступа использовали атрибуты контекста для того, чтобы определить, к каким данным имеет доступ данный пользователь.

Эта система хорошо работает в классической клиент-серверной технологии, когда пользователь открывает сессию в базе данных и сохраняет эту сессию за собой. В многоуровневой архитектуре сервер приложений часто открывает в базе данных сразу несколько сессий и затем передает эти сессии работающим через него пользователям. Причем через одну сессию могут работать несколько пользователей, имеющих разные права и уровни допуска, поэтому они должны иметь и разные контексты. В VPD эта проблема решается введением понятия глобального контекста (Global Context) и идентификатора клиента. Теперь в одной сессии в одном контексте может быть несколько одинаковых атрибутов (например, несколько должностей) с разными значениями и разными идентификаторами клиента. Сервер приложений, передавая сессию пользователю, должен установить идентификатор, и пользователь сможет работать со своими значениями атрибутов контекста.

В Oracle9i входит и готовый вариант реализации этой технологии – Oracle Label Security. Это функциональность Trusted Oracle, реализованная средствами VPD. Контроль доступа к строкам основан на системе меток, которые можно назначить каждому пользователю, приложению и строке в таблице. Вся система настраивается через графический интерфейс Oracle Policy Manager, не требуя никакого программирования.

Заключение

Объем одной статьи не позволяет подробно описать все новые средства Oracle9i Database, не говоря уже о других продуктах серии 9i. Поэтому в этой статье мы сосредоточили свое внимание на наиболее интересных на наш взгляд новшествах. В дальнейших материалах мы планируем рассмотреть возможности продукта, не вошедшие в этот обзор.

Все примеры, приведенные в этой статье, были проверены автором на Oracle9i Enterprise Edition Release 9.0.1.1.1 – Production на Windows NT Version 4.0 Service Pack 5.

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://www.rsdn.ru/

Характеристики

Список файлов реферата