Oracle9i. Огляд деяких нових можливостей

Зміст



Набір продуктів фірми Oracle Oracle9i складається з трьох основних компонентів – 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 sal <1000 THEN "Низька"
WHEN sal> 4000 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. У стовпці цього типу в кожному рядку можуть зберігатися дані різних типів (в одному рядку – символьні, в іншій – числові, в третій – структура з двох бінарних і трьох числових полів). Опис типу даних у полі кожної конкретної рядки зберігається в самому полі. Доступ до даних такого типу поки можливий тільки через OCI.

Менш оригінальні, але не менш корисні нові типи для дати і часу. По-перше, тип TimeStamp дає можливість зберігати в базі даних дату з точністю до часток секунди (до 9 знаків після коми). По-друге, тип 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") – для менеджера – півтора року;
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). Введення робочих областей можна розглядати як появу в базі даних ще одного рівня версійність.

Відомо, що підтримка цілісності читання (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) дозволяє уникнути одного із кроків у 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 – перший продаж в даному регіоні
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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*