Oracle9i. Обзор некоторых новых возможностей

Набор товаров конторы Oracle Oracle9i состоит из 3-х главных компонент – Oracle9i Database (сервер базы данных), Oracle9i Application Server (сервер приложений) и Oracle9i Developer Suite (средства разработки). В этой статье пойдет речь о инновациях Oracle9i Database.

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

Разработчику

Исторически сложилось, что при знакомстве с новым продуктом сначала обычно интересуются тем, появились ли какие-то принципно новые средства и технологии разработки. В Oracle8i таковой «революцией» было возникновение на сервере языка Java как кандидатуры PL/SQL. В Oracle9i так новых средств разработки серверной части приложений не появилось. Да и новых способностей старенькых хороших Java и PL/SQL полностью довольно, чтоб облегчить процесс сотворения приложений, а в неких случаях поменять технологию разработки.

Поначалу разглядим новые способности конкретно для разработки приложений. Но будем держать в голове о том, что неплохого разработчика заинтересовывают не только лишь средства разработки («как сделать…»), да и средства оптимизации («…чтоб отлично работало!»). Не считая того, при установке тиражируемой системы заказчику нередко выясняется, что количество юзеров существенно превосходит запланированное. Потому принципиально иметь возможность масштабирования системы.

Развитие SQL приемущественно движется в сторону соответствия эталонам. SQL в Oracle9i соответствует требованиям эталона ISO SQL1999. Для ублажения этих требований в язык введено много новых синтаксических конструкций. Это, к примеру, оператор CASE, перекрывающий функциональность старенькой хорошей функции DECODE (в примерах по традиции употребляются всем известные таблицы Emp и Dept):
SELECT ename «Фамилия»,
(CASE WHEN sal4000 THEN ‘Высочайшая’
ELSE ‘Средняя’
END) «Заработная плата»
FROM emp;

Поменялся и синтаксис соединений. Сейчас и в Oracle есть понятия правого/левого/полного наружного соединения (outer join), к примеру, запрос
select ename, dname from emp right outer join dept
on (emp.deptno=dept.deptno);

возвращает тот же итог, что и
select ename, dname from emp, dept
where emp.deptno(+)=dept.deptno;

А вот запрос
select ename, dname from emp full outer join dept
on (emp.deptno=dept.deptno);

в древнем синтаксисе аналога не имеет.

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

Нововведения в PL/SQL более революционны, они носят еще более кардинальный нрав. Приверженцам объектной технологии приятно будет выяснить, что в объектных типах появилось наследование, принципы которого удовлетворяют эталону ANSI SQL99. Наследование в Oracle9i строго иерархическое, множественное наследование не допускается. Типы-потомки наследуют у собственного родителя атрибуты и способы. Естественно, потомки могут добавлять свои атрибуты и способы, также и переопределять способы родителя. Пример типа-родителя:
CREATE TYPE Person AS OBJECT
(
person_id NUMBER,
date_of_birth DATE,
name VARCHAR2(30),
address VARCHAR2(100),
MEMBER PROCEDURE Hire, — может переопределяться
FINAL MEMBER FUNCTION Age RETURN NUMBER — не переопределяется
) NOT FINAL; — может иметь подтипы

Вероятные подтипы:
CREATE TYPE Student UNDER Person
(deptid NUMBER, major VARCHAR2(30)); — добавление атрибутов
CREATE TYPE Employee UNDER Person
(empid NUMBER, mgr VARCHAR2(30))
NOT FINAL;
CREATE TYPE PartTimeEmployee UNDER Employee
(numhours NUMBER);

Вводится и понятие абстрактных (not-instantiable) типов и способов. Разработчик может создавать подтипы таких типов, но не может создавать экземпляры таких типов.

PL/SQL-пакеты можно компилировать в виде разделяемых библиотек. Это избавляет затратные расходы на интерпретацию PL/SQL-кода, что может привести к ускорению выполнения в 2-10 раз. Так что сейчас желающие сумеют писать функции вычисления интегралов на PL/SQL, не жертвуя при всем этом производительностью. Естественно, если PL/SQL-программы активно работают с базой данных, значимого выигрыша от компиляции PL/SQL получить не получится.

В SQL и PL/SQL появились новые типы данных. В особенности оригинален тип AnyData. В столбце этого типа в каждой строке могут храниться данные различных типов (в одной строке – символьные, в другой – числовые, в третьей – структура из 2-ух бинарных и 3-х числовых полей). Описание типа данных в поле каждой определенной строчки хранится в самом поле. Доступ к данным такового типа пока вероятен только через OCI.

Наименее оригинальны, но более полезны новые типы для даты и времени. Во-1-х, тип TimeStamp дает возможность хранить в базе данных дату с точностью до толикой секунды (до 9 символов после запятой). Во-2-х, тип TimeStamp with Time Zone вкупе с датой хранит код часового пояса. Сопоставление данных этого типа осуществляется с учетом часового пояса. Это очень упрощает работу с распределенными системами и репликацией. Кстати, перечень стандартных часовых поясов в Oracle9i обхватывает весь земной шар. Введены и два принципно новых типа данных для хранения интервалов времени, не привязанных к определенной дате – INTERVAL DAY TO SECOND и INTERVAL YEAR TO MONTH. Используя эти типы, комфортно задавать, к примеру, длительность испытательного срока при приеме на работу:
Create table Jobs(job varchar2(9), trial_period INTERVAL YEAR TO MONTH);
insert into Jobs — испытательный срок
values (‘MANAGER’,’1-6′) — для менеджера – 18 месяцев;
select ename, hiredate,
hiredate + trial_period — и когда же он завершится?
from emp — а вот очередной пример нового
natural join jobs; — синтаксиса соединений

Поддержка Java активно развивается в направлении соответствия все более новым эталонам. В Oracle9i поддерживаются эталоны Servlet 2.2, JavaServer Pages 1.1, JDBC 2.0.

Раздельно стоит упомянуть и поддержку XML. Введен новый тип данных XMLType, реализованный как LOB, и работа с данными этого типа поддерживается через SQL, PL/SQL и Java.

Мысль глобализации отыскала свое применение в развитии поддержки многоязыковых баз данных и средств работы с ними, что отражено и в терминологии: термин National Language Support заменен в Oracle9i на Globalization. Посреди инноваций в этой области можно выделить новейшую шифровку для двухбайтного Unicode (UTF16), Unicode на базе шифровки EBCDIC (UTFE) и многоязыковые сортировки. Для облегчения перевода базы данных на новейшую шифровку предлагается утилита Character Set Scanner. Она сканирует базу данных и определяет, какие столбцы каких таблиц будет нужно расширить, и какие знаки будут потеряны при переходе. Утилита Locale Builder позволяет видоизменять языковые, территориальные и лингвистические установки (правила сортировки, наименования дней и месяцев, правила перевода меж верхним и нижним регистрами, форматы даты и т.п.), также и таблицы шифровки.

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

Понятно, что поддержка целостности чтения (read consistency) в Oracle реализована через многоверсионность. Если сессия изменила данные и не зафиксировала (commit) транзакцию, то другие сессии получают старенькую версию данных. После фиксации транзакции отмена её конфигураций уже невозможна, а все другие сессии начинают созидать изменённое состояние данных. Потому фактически нереально проверить, верно ли работает какое-нибудь огромное пакетное задание типа выставления счетов всем клиентам. Без фиксации транзакций такового рода вещи обычно не обходятся, и если вы нашли, что счета выставлены некорректно, отменить уже ничего нельзя, и данные испорчены.

Сейчас для схожих тестов можно сделать рабочую область и работать в ней. Снутри рабочей области действуют стандартные правила и стандартные методы поддержания целостности чтения. Юзер, работающий в собственной рабочей области, может делать запросы, конфигурации данных и фиксировать транзакции. Эти конфигурации, даже зафиксированные, видны только юзерам, действующим в той же самой рабочей области. После окончания работы с рабочей областью её можно убить, утратив все конфигурации в ней, либо соединить с главным содержимым базы данных. Так что вышеперечисленная задачка тестирования решается так: создаём рабочую область, перебегаем в неё, запускаем функцию, смотрим итог. Если всё верно – соединяем с основными данными, если нет – уничтожаем рабочую область и ищем ошибку…

Оптимизация приложений

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

Нереально бросить без внимания ещё одно оригинальное новаторство – битовые индексы соединения (bitmap join indexes, BJI). Это обыденные битовые индексы, но построенные по столбцам, которых в индексируемой таблице нет. К примеру, в таблице продаж (назовем её по традиции Sales) есть код региона реализации, но нет его наименования. Заглавие есть в справочнике регионов (Regions). В то же время запрос, выбирающий все реализации по региону с данным заглавием, достаточно типичен. При его выполнении всякий раз требуется соединение (join) таблиц Sales и Regions. Разглядим пример.

Сделаем таблицы:
create table Regions
(
region_id number primary key, — первичный ключ обязателен для сотворения BJI
region_name varchar2(200)
);
create table Sales
(
id number primary key,
region_id number, — опустим ограничения наружного ключа
product_id number,
amount number,
sal_date date
);

Выполним запрос:
Select sum(amount)
from sales, regions
where
regions.region_id = sales.region_id
and regions.region_name = ‘Центр’

Разглядим план выполнения этого запроса (это не единственно вероятный, но полностью возможный план). В плане, естественно, находится просмотр обеих таблиц и операция их соединения:
SELECT STATEMENT Optimizer=ALL_ROWS
SORT (AGGREGATE)
NESTED LOOPS
TABLE ACCESS (FULL) OF ‘SALES’
TABLE ACCESS (BY INDEX ROWID) OF ‘REGIONS’
INDEX (UNIQUE SCAN) OF ‘REGIONS_PK’ (UNIQUE)

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

Сделаем индекс:
create bitmap index Sales_reg_bji
on Sales(regions.region_name)
from Sales, Regions
where sales.region_id=regions.region_id

Чтоб побудить оптимизатор использовать этот индекс, применим подсказку (hint). В действительности, если таблицы будут довольно большенными, подсказки вероятнее всего не пригодятся, т.к. цена выполнения этого запроса с внедрением индекса будет значительно меньше, чем без него:
select /*+ index(sales sales_reg_bji) */
sum(amount) from sales, regions
where
regions.region_id = sales.region_id
and regions.region_name = ‘Центр’

Разглядим план выполнения и убедимся, что просмотр таблицы Regions и операция соединения пропали:
SELECT STATEMENT Optimizer=ALL_ROWS
SORT (AGGREGATE)
TABLE ACCESS (BY INDEX ROWID) OF ‘SALES’
BITMAP CONVERSION (TO ROWIDS)
BITMAP INDEX (SINGLE VALUE) OF ‘SALES_REG_BJI’

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

Real Application Cluster

Разработка Real Application Cluster заслуживает отдельной статьи либо даже серии статей. Эта разработка позволяет перенести приложение, разработанное без учёта особенностей кластерной архитектуры, на кластер, и получить при всем этом существенное повышение и производительности, и отказоустойчивости.

Не считая этого к средствам обеспечения масштабируемости можно отнести автоматическое рассредотачивание памяти PGA и тонкое рассредотачивание ресурсов сервера (развитие технологии Database Resource Manager).

Очень огромное внимание в Oracle9i уделено средствам работы с хранилищами данных. При работе с ними, обычно, требуется решить две главные трудности – как загрузить данные в хранилище и как их позже рассматривать.

Для решения первой препядствия данные необходимо поначалу извлечь из какого-нибудь источника (нередко этим источником является OLTP-система), позже конвертировать (выполнить денормализацию, просуммировать по какому-либо показателю и т.п.), и позже загрузить в базу данных. Для обозначения этого процесса обычно употребляется аббревиатура ETL (Extraction, Transformation and Loading).

Одна из главных задач в процессе ETL – найти, какие данные были изменены после последней загрузки хранилища. Разработка Change Data Capture позволяет выслеживать все конфигурации данных, сохранять информацию об конфигурациях в таблицах конфигураций (change tables) и просматривать конфигурации данных за подходящий просвет времени.

Если данные в хранилище загружаются из наружных файлов, то возникновение наружных таблиц (External Tables) дает возможность избежать 1-го из шагов в ETL-процессе. Наружняя таблица – это таблица, структура которой описана в базе данных, а данные хранятся в плоском файле. В базе данных нужно обрисовать формат этого файла, для этого употребляется язык, очень схожий на язык управляющих файлов SQL*Loader. Естественно, наружные таблицы можно использовать только для запросов. Описываются они примерно так:
create table emp_external
(
empno number(4),
ename char(10),
job char(9),
mgr number(4),
sal number(7,2),
comm number(7,2),
deptno number(2)
)
organization external
(
type oracle_loader — другого пока нет
default directory emp_dir — объект типа Directory в базе данных
access parameters
(
fields rtrim
(
EMPNO (01:04),
ENAME (06:15),
JOB (17:25),
MGR (27:30),
SAL (32:39),
COMM (41:48),
DEPTNO (50:51)
)
)
location (‘ulcase2.dat’)
)

Для облегчения шага Transformation в ETL-процессе предлагаются конвейерные (pipelined) функции. Это функции, которые на входе получают набор строк (ref cursor) и на выходе выдают тоже набор строк (nested table). Их принципная новизна в том, что это огромное количество строк они выдают не сходу, а по одной. Снутри таковой функции ставится оператор PIPE ROW, который выдает одну строчку результата и приостанавливает выполнение функции до того времени, пока среда, вызвавшая эту функцию (это может быть, к примеру, тоже конвейерная функция), не востребует последующую строчку. Разглядим пример конвейерной функции.

Объявление типа для источника (producer) данных:
create or replace package emp_pipe is
type strong_refcur_t is ref cursor return emp%rowtype;
end;

Объявление типа для приемника (consumer) данных:
create or replace type emp_t is
object (empno number, ename varchar2(10), sal number);
create or replace type emp_t_table as table of emp_t;

Сама конвейерная функция:
create or replace FUNCTION emp_pipe_fun(cur emp_pipe.strong_refcur_t)
RETURN emp_t_table
PARALLEL_ENABLE (PARTITION cur BY ANY)
PIPELINED is
one_row cur%rowtype;
BEGIN
LOOP
FETCH cur INTO one_row;
/* Тут можно воткнуть всякую обработку приобретенной строчки */
EXIT WHEN cur%NOTFOUND;
/* Оператор PIPE ROW возвращает одну строчку результата */
PIPE ROW (emp_t(one_row.empno, one_row.ename, one_row.sal*10));
END LOOP;
CLOSE cur;
/* RETURN вызывается без аргументов, */
/* т.к. все результаты функция уже возвратила через PIPE ROW */
RETURN;
END;

Внедрение этой функции:
select * from table(emp_pipe_fun(cursor(select * from emp)));

Итог работы emp_pipe_fun может послужить источником данных для другой конвейерной функции (назовем ее another_fun):
Select *
from table(another_fun(cursor(
select * from table(emp_pipe_fun(cursor(select * from emp))))));

Это позволяет «нанизывать» такие функции друг на друга и организовывать сборочный поток преобразования данных.

Новый SQL-оператор Merge и новый многотабличный синтаксис оператора Insert упрощают шаг Loading. Оператор Merge – реализация стандартной для хранилищ данных операции UPSERT, созданной для решения задач типа «если реализации в данном регионе уже были – прирастить сумму продаж (Update) по коду региона, если не было – воткнуть строчку с кодом и суммой продаж (Insert)». К примеру (используем уже упоминавшиеся таблицы Sales и Regions):

Сделаем суммарную таблицу продаж по регионам:
create table Sales_sum (region_id number, sum_amount number);

Внесем в нее данные о продажах за последние день:
merge into sales_sum SS
using (select region_id, amount from sales where sal_date>sysdate-1) S
on (SS.region_id=S.region_id)
when matched then — реализации по региону уже были
update set SS.sum_amount=SS.sum_amount+S.amount
when not matched then — 1-ая продажа в данном регионе
insert (SS.region_id, SS.sum_amount)
values (S.region_id, S.amount);

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

Сделаем таблицы для архивных данных и больших сделок:
create table sales_arch as select * from sales where 0=1;
create table super_sales as select * from sales where 0=1;

Перенесем данные:
insert all
when amount>100000
then into super_sales values (id, region_id, product_id, amount, sal_date)
when 1=1
then into sales_arch values (id, region_id, product_id, amount, sal_date)
select * from sales;

Админу

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

Остановки базы данных можно поделить на плановые (к примеру, для конфигурации характеристик экземпляра) и внеплановые (разные сбои). Oracle9i позволяет значительно снизить частоту плановых остановок, так как допускает динамическое изменение практически всех характеристик экземпляра, в том числе и таких характеристик системной глобальной области, как размер кэша буферов базы данных либо разделяемого пула. Что все-таки касается сбоев, то гарантировать их отсутствие не может никто. Oracle9i содержит средства для понижения вероятности сбоев и очень безболезненного устранения их последствий.

Разработка Oracle Data Guard – развитие старенькой идеи запасной базы данных (Standby Database). Главным недочетом старенького варианта была невозможность полного восстановления запасной базы перед ее активизацией. Если при аварии основного сервера повреждался текущий журнальчик (current redo log), то все конфигурации базы данных, записанные в этот журнальчик, терялись невозвратно. Для многих OLTP-систем это было неприемлемо. Разработка Oracle Data Guard позволяет админу базы данных самому избрать, что для него важнее – недопущение утраты даже самого малого количества данных либо наибольшая производительность. Если утрата данных недопустима, то можно вынудить Oracle отправлять конфигурации на запасный сервер в синхронном режиме, т.е. пока эти конфигурации не выполнятся на запасной базе данных, транзакция не считается зафиксированной. Естественно, это может привести к неким потерям в производительности. Можно использовать старенькый способ – конфигурации передаются на запасный сервер только после наполнения еще одного журнальчика на основном сервере. Здесь мы жертвуем сохранностью данных ради производительности. И есть компромиссный вариант – конфигурации передаются на запасный сервер «практически синхронно», тогда маленькая утрата данных в случае аварии вероятна, но маловероятна.

Особенного внимания заслуживает новенькая возможность Recovery Manager – восстановление отдельного блока файла данных. Ранее одним из стандартных методов восстановления при обнаружении покоробленного (corrupted) блока было копирование файла, содержащего этот блок, из запасной копии и применение к нему архивных и оперативных журналов. Это добивалось как минимум перевода покоробленного табличного места в автономный режим на время копирования файла, что приводило к недоступности части данных на достаточно долгий срок. Сейчас Recovery Manager может извлечь из запасной копии только покоробленный блок, выполнить его восстановление с помощью журналов и записать восстановленный блок в файл данных. В данном случае временно труднодоступными оказываются только данные в покоробленном блоке.

Так именуемые возобновляемые операции (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 1
insert into small_extent_table s select * from small_extent_table
ORA-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, чтоб разрешить DML
loop
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.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.