Oracle9i. Огляд деяких нових можливостей.
Ольга Карбасова
Набір продуктів 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.
Список літератури
Для підготовки даної роботи були використані
матеріали з сайту http://www.rsdn.ru/
