Так называемые возобновляемые операции (Resumable Operations) позволяют бороться с другим очень распространенным видом сбоев – нехваткой пространства в базе данных. Каждый администратор наверняка не раз попадал в ситуацию, когда операция вроде перестроения большого индекса или реорганизации огромной таблицы работает несколько часов и обрывается из-за нехватки места в табличном пространстве (постоянном или временном) или невозможности расширить сегмент отката. В Oracle9i такую операцию можно объявить возобновляемой. Тогда в случае возникновения подобной ошибки процесс не прерывается, а приостанавливается до тех пор, пока администратор не устранит препятствие или не истечет заданный таймаут. Вот как это выглядит.
Создадим таблицу (для чистоты эксперимента – в управляемом системой (dictionary managed) табличном пространстве, т.к. в локально-управляемом (locally managed) не действует параметр Maxextents):
| create table Small_extent_table tablespace dict_tbs storage (initial 10K maxextents 1) as select * from emp; |
Несколько раз продублируем в ней данные:
| insert into Small_extent_table select * from Small_extent_table; |
Примернонапятой-шестойпопыткеполучимошибку «ORA-01631: max # extents (1) reached in table SCOTT.SMALL_EXTENT_TABLE». Включим возобновляемые операции (для этого пользователь должен иметь привилегию Resumable):
| alter session enable resumable; |
Попробуем еще раз:
| insert into Small_extent_table select * from Small_extent_table; |
Сессия зависает и ждет возможности добавить экстент в таблицу. Из другой сессии обнаружим это:
| select name, sql_text, error_msg from dba_resumable; |
Получим:
| User SCOTT(70), Session 7, Instance 1insert into small_extent_table s select * from small_extent_tableORA-01631: max # extents (1) reached in table SCOTT.SMALL_EXTENT_TABLE |
Устраним причину ошибки:
| alter table Scott.Small_extent_table storage (maxextents 10); |
Теперь осталось только убедиться, что в первой сессии оператор Insert успешно закончился.
Еще один классический вид сбоев – ошибки пользователей. Если кто-то из пользователей, разработчиков или сам администратор случайно удалил таблицу или запустил неотлаженную процедуру, восстановить потерянные данные бывает очень трудно. В Oracle8i в таких случаях очень помогает утилита Log Miner. В Oracle9i эта утилита обогатилась новыми возможностями, такими как восстановление текста DDL-операций или возможность пропуска поврежденной части журнала.
Кроме Log Miner, восстановить данные после пользовательской ошибки помогает еще одно нововведение – ретроспективные запросы (flashback query). С помощью процедур пакета dbms_flashback пользователь может задать нужный момент времени (предшествующий ошибке), и после этого все его запросы будут возвращать состояние данных на указанный момент. Попробуем это сделать.
Удалим важные данные из таблицы:
| delete from small_extent_table;Commit; |
Посмотрим состояние данных на момент, предшествующий фиксации транзакции (точное время фиксации можно получить с помощью LogMiner):
| exec dbms_flashback.enable_at_time(‘05.12.2001 15:21:58')select * from small_extent_table; |
Полученные «старые» данные можно сохранить в базе и ликвидировать последствия ошибки:
| declare cursor c is (select * from scott.small_extent_table); cc c%rowtype;begin exec dbms_flashback.enable_at_time(‘05.12.2001 15:21:58')open c; -- открываем курсор, находясь в режиме FlashBack dbms_flashback.disable; -- выключаем FlashBack, чтобы разрешить DMLloop fetch c into cc; exit when c%notfound; insert into scott.small_extent_table values (cc.empno, cc.ename, cc.job, cc.mgr, cc.hiredate, cc.sal, cc.comm, cc.deptno);end loop;end;/commit; |
Естественно, возможность восстановления старого состояния данных ограничена объемом сегментов отката.
У администратора базы данных остается все меньше возможностей повредить базу данных. Не секрет, что одной из наиболее распространенных причин сбоев является ошибочное стирание файла базы данных администратором, например, при удалении табличного пространства. В 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.