| 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 заслуживает отдельной статьи или даже серии статей. Эта технология позволяет перенести приложение, разработанное без учёта особенностей кластерной архитектуры, на кластер, и получить при этом существенное увеличение и производительности, и отказоустойчивости.
Кроме этого к средствам обеспечения масштабируемости можно отнести автоматическое распределение памяти 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.amountwhen 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 может извлечь из резервной копии только поврежденный блок, выполнить его восстановление при помощи журналов и записать восстановленный блок в файл данных. В этом случае временно недоступными оказываются только данные в поврежденном блоке.