DeepEdit!

М. Ривкин

Весной 2002 года компания Oracle (www.oracle.com) выпустила новый релиз своей СУБД – Oracle9i Release 2 (Oracle9.2). В этом релизе были исправлены некоторые ошибки, обнаруженные в релизе 1, повысилось быстродействие и эффективность работы СУБД. Появилось много новых возможностей, наиболее интересными из которых являются следующие:

создание новых и совершенствование старых механизмов обеспечения надежности работы и масштабируемости (RAC, Logical Standby, Flashback);

поддержка XML в БД; 

встраивание в сервер Oracle средств поддержки OLAP и Data Mining; 

Oracle Streams;

совершенствование средств управления, самонастройки, настройки СУБД;

поддержка архитектуры IA64.

Рассмотрим их подробнее.

Надежность и масштабируемость: 

Крупнейшим достижением Oracle9i в области обеспечения высокой надежности и масштабируемости было создание средств поддержки реальных кластеров – компонента Real Application Cluster (RAC). Напомним, что RAC позволяет повысить надежность системы (при выходе из строя одного из узлов, система продолжает функционировать), увеличивает масштабируемость системы (пользователи одной БД и одного приложения “размазываются” по всем узлам кластера), позволяет постепенно наращивать мощность системы, не останавливая ее работу (подключать “на лету” новые узлы).

При создании релиза 2 была значительно повышена эффективность работы RAC. Разработчики не только оптимизировали работу опции Real Application Cluster, но и проанализировали узкие места сервера, работающего в кластерном режиме. Многие элементы СУБД были переписаны по результатам этого анализа для того, чтобы в кластерном режиме Oracle работал более быстро и надежно. Так, например, был оптимизирован поток информации, передаваемой между узлами кластера, использован механизм битовых масок для управления пространством внутри сегмента и т. д.

Для упрощения установки, настройки и сопровождения кластера создана компонента RACGUARD2, которая значительно упрощает а иногда и автоматизирует администрирование кластера, упрощает переключение узлов кластера. Раньше при создании на кластере базы данных необходимо было размещать файлы БД на так называемых “сырых устройствах” (Raw devices). Это усложняло администрирование RAC, требовало более высокой квалификации администратора базы данных, усложняло выполнение операций копирования/восстановления БД. В релизе 2 администратор БД может использовать кластерную файловую систему Oracle Cluster File System и хранить программное обеспечение Oracle и файлы кластеризирной БД в обычной файловой системе. Большая часть расширений операционной системы, необходимых для работы кластера, разработаны непосредственно в корпорации Oracle. Эти расширения поставляются Oracle и инсталлируются в виде так называемого Oracle Portable Clusterware, что также упрощает создание кластера. Появилась возможность объединять узлы кластера в логические рабочие группы и связывать приложения с этими рабочими группами. Тем самым можно регламентировать, с какими узлами кластера будет работать конкретное приложение.

К сожалению, обычно узлы кластера находятся недалеко друг от друга, как правило, в одном здании. Поэтому при уничтожении или длительном обесточивании здания RAC не может обеспечить продолжение работы системы, так как все его узлы выходят из строя одновременно. На случай таких катастрофических сбоев Oracle рекомендует использовать механизм резервной (standby) БД. Идея состоит в том, что копия эксплуатационной БД находится на большом удалении от основного вычислительного центра и постоянно “догоняет” основную производственную БД. То есть все изменения основной БД архивируются и передаются в резервный центр, а там автоматически применяются к резервной БД. В случае выхода из строя основной БД, резервная БД переводится из режима восстановления в режим эксплуатации, и приложения очень быстро могут продолжить свою работу, причем (при определенных режимах) без потери данных.

До недавнего времени Oracle мог поддерживать только физический standby режим. В этом случае резервная БД должна была быть полной копией основной БД, в ней нельзя создавать дополнительные объекты, индексы и так далее. Физическую standby-базу можно временно переводить в режим чтения, чтобы напечатать, например, отчеты, но на это время ее восстановление останавливалось, да и оптимизировать операции чтения было нельзя. Причина была в том, что изменения, проведенные в производственной БД, передавались в резервный центр и там применялись на физическом уровне (быстрая прямая запись в БД).

В релизе 2 Oracle реализовал логический standby-механизм. Отличие от физического standby заключается в том, что передаваемые в резервный центр изменения не применяются к standby-базе на физическом уровне, а предварительно преобразуются Oracle в SQL-операторы, то есть процесс восстановления standby-базы не блокирует работу других пользователей с этой БД в режиме чтения. Теперь эта база выступает не только в роли резервной БД, но на ней можно одновременно с восстановлением печатать отчеты, решать аналитические задачи и так далее. Если для повышения эффективности выполнения этих задач надо создать дополнительные индексы, материализованные представления и другое, то в логической standby-базе это сделать можно. 

Компонента управления физической и логической standby-базой – DATA GUARD облегчает, а часто и автоматизирует создание standby-базы, ее администрирование, конфигурирование, перевод standby-базы в режим производственной БД и наоборот.

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

В релизе 2 пользователь может указывать, что данные ему нужны на какой-то момент времени в прошлом, прямо в SQL-запросе 

select

. Это сильно упрощает работу и не требует перевода сеанса в прошлое и обратно.

 

Вторым крупнейшим достижением Oracle является создание XML-базы данных. Теперь сервер Oracle поддерживает не только реляционную, объектную и многомерную модели данных, но и XML. Ранее мы могли хранить большие объемы XML-данных в БД двумя способами: либо они хранились в виде XML-файлов в LOB-полях как единые текстовые участки, либо содержимое XML-файла разбиралось, разбрасывалось по реляционным таблицам, а при запросе этого XML-документа опять собиралось в файл. 

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

Не меньшим достоинством является и то, что теперь XML и реляционные данные сосуществуют в одной универсальной модели и с XML-данными можно работать посредством SQL и Java, а с реляционными данными можно работать через XML-интерфейсы, например через XPath. Поскольку из SQL можно работать с XML-данными и их частями, то теперь легко построить, например, обычный индекс по реквизиту, содержащемуся в XML-файлах и быстро находить нужные файлы. Можно построить реляционное представление (View), столбцы которого есть реквизиты XML-файлов и далее работать с этим View, как с обычным реляционным представлением. Например, если в некотором приложении запрос на товары приходит от заказчика в виде сообщений, содержащих XML-текст, то теперь легко можно написать запрос, одновременно работающий с реляционными данными, очередями сообщений, XML-данными, геоинформацией, контекстом. Например:

Запрос: 

  

И наоборот, создав над реляционными или объектными таблицами БД XMLType View, можно работать с этими данными через XML-интерфейс. В Oracle9.2 поддерживаются следующие стандарты доступа к данным: SQLX, Xpath, DOM, JavaBeans, JNDI.

Кроме хранения XML-данных в виде атрибутов объектов, Oracle9i позволяет создать XML-репозиторий и хранить библиотеки XML-документов. При этом можно задавать иерархию папок документов, контролировать версии документов, организовать дополнительный контроль доступа к файлам и папкам на основе ACL (списков контроля доступа).

Реляционная модель очень удобна для представления данных в информационно-управляющих системах. Однако, для аналитических систем более удобна многомерная модель данных, где данные представлены в виде многомерных кубов, которые можно легко вращать, получать срезы, агрегировать информацию и так далее. Для создания OLAP-систем Oracle ранее использовал продукт Express Server, который являлся СУБД с многомерной моделью. Данные из оперативных реляционных систем приходилось перегружать или подкачивать в Express Server. Express Server не обеспечивал такой же уровень надежности, масштабирования, защиты, как реляционный сервер Oracle. Поэтому Oracle начал встраивать возможности и функциональность Express Server в обычный сервер Oracle.

В релизе 2 эти возможности реализованы полностью. Теперь сервер Oracle9i поддерживает и многомерную модель данных. Вы можете проектировать многомерные кубы и решать, как они будут храниться в Oracle9i (в реляционных таблицах или в LOB-полях – workspace). В Oracle9i реализован весь набор функций, присущий ранее Express, а также некоторые дополнительные функции. Реализованы более эффективные способы хранения, а скорость обработки часто превышает скорость Express Server. Кроме того, метаданные и данные хранятся в единой БД Oracle, используя все преимущества СУБД Oracle9i (надежность, защита, масштабируемость, единое управление, единое копирование/восстановление и так далее). Для работы с спроектированными многомерными кубами используются JavaBeans, входящие в состав Oracle JDeveloper.

Алгоритмы Data Mining, реализуемые ранее продуктом Darvin, теперь тоже встроены в сервер Oracle9i. Используя API, разработчики могут строить различные модели зависимости данных, а потом использовать эти модели для получения рекомендаций в своих приложениях. И данные, и модели хранятся в БД Oracle. В релизе 2 была добавлена поддержка таких методов построения модели, как деревья решений и кластеризация, реализованы функции выбора наилучшей модели, определения важности атрибутов.

 

 

В СУБД Oracle есть много различных вариантов передачи данных и сообщений о событиях между разными серверами Oracle:

Если применяется механизм репликации, захватываются и передаются изменения данных и вызовы удаленных процедур. 

Если происходит работа с очередями сообщений (Advanced Queuing), передается информация о появлении сообщений и сами сообщения. 

В случае применения standby-базы данных, передаются и применяются к standby-базе архивированные журнальные файлы или их элементы. 

Если производится загрузка данных в хранилища данных или Operating Data Store, то передаются загружаемые данные.

Все эти механизмы хорошо работают и легко конфигурируются в отдельности. Но если надо одновременно использовать несколько из них, то конфигурирование усложняется, производительность падает, растет нагрузка на производственную систему. При этом очевидно, что одни и те же данные в разных форматах передаются для разных механизмов. Для того, чтобы снизить нагрузку на сервер и облегчить конфигурацию перечисленных механизмов, Oracle создал новый единый унифицированный механизм передачи данных и сообщений о событиях, объединяющий все выше перечисленные возможности. Он называется Oracle Streams. 

Oracle Streams состоит из трех элементов:

захват событий и данных (capture);

складирование их в единый упорядоченный по времени информационный поток в едином формате (Stage); 

транспортировка и применение изменений к целевым БД (Apply);

Захват данных происходит автоматически из журнальных файлов. Захватываются только те данные и события, которые необходимы для выполнения конкретных заказанных действий. Захваченные данные и события преобразуются в единый универсальный формат хранения и помещаются в область хранения (Stage). При помещении в эту область они могут преобразовываться, модифицироваться и так далее. Кроме того, существует API, позволяющий помещать данные в область хранения программам загрузки данных, пользовательским приложениям или программам, работающим с чужими СУБД. 

Далее потоки изменений идут по указанным маршрутам (через несколько серверов), и те узлы, которые подписаны на эти изменения, берут их из потока и применяют к своим БД, реализуя репликацию, или прием сообщений, или восстановление standby-базы. Поскольку захват изменений идет из журналов, снижается нагрузка на исходную БД и не требуется прямой доступ и права на него для этой БД. Благодаря Oracle Streams можно реализовать обмен неточными копиями и подмножествами объектов (они преобразуются при передаче). Исходная и целевые СУБД могут иметь разные версии и работать на разных платформах. 

 

С каждой новой версией сервера Oracle совершенствуются средства управления и настройки СУБД – Oracle Enterprise Manager (OEM). Кроме того, все больше и больше проблем по настройке решается автоматически (самонастройка) или с помощью программ - советчиков (Wizards). Новый релиз Oracle9i не стал исключением. Кроме того, OEM релиза 2 поддерживает все новые возможности релизов 1 и 2 Oracle9i.

Многие ресурсы СУБД взаимозависимы. Например, чтобы ускорить работу сервера, приходится выделять больше оперативной памяти, чтобы уменьшить время восстановления БД приходится жертвовать быстродействием. Желательно эти “жертвы” снизить и оптимизировать. Для этого в OEM релиза 1 были введены советчики, показывающие диаграммы зависимости ресурсов для буферного кэша и для UNDO-области. Глядя на эти диаграммы, администратор мог быстро понять, на сколько надо увеличить/уменьшить размер области и что это ему дает с точки зрения эффективности использования ресурсов. В релизе 2 добавлены такие же средства для оптимизации размера разделяемой области памяти (shared pool), области выполнения SQL-операторов (SQL Executive Memory) и минимального времени восстановления после сбоя (Mean Time To Recovery). Теперь администратор легко сможет понять, насколько возрастет интенсивность ввода/вывода и снизится скорость работы системы при конкретном задании минимально допустимого времени восстановления БД. Кроме того, эти диаграммы позволяют проводить анализ типа “что будет если”, то есть моделировать ситуацию заранее.

Сервер Oracle начал собирать информацию об интенсивности использования объектов БД. Диаграммы типа Top Object (например, Top SQL) в OEM позволят увидеть, какие таблицы, индексы, секции использовались наиболее интенсивно или были предметом спора за ресурсы. Анализ этой информации позволит увеличить производительность системы.

В последнее время в большинстве компаний широко используются массивы RAID-дисков. Файлы, составляющие БД Oracle, обычно размещаются на этих RAID-массивах. Часто сложно понять, на каком физическом устройстве реально размещен какой-либо файл базы. Поэтому в OEM появилась возможность посмотреть топологию ввода/вывода, а именно, отображение связи между файлами БД Oracle и логическими и физическими устройствами хранения.

В последнее время большой интерес вызывают компьютеры с архитектурой IA64 на базе процессора Itanium. Многие собираются использовать Oracle на этих компьютерах. Версия Oracle9i релиз 2 будет работать на Itanium компьютерах с 64 разрядной ОС Linux, HP UX и Windows. Сейчас доступна версия 9.0 для разработчиков (Developer Release), а в конце года появится промышленный релиз Oracle9i R2 (9.2) для архитектуры IA64. 

В релизе 2 выполнена поддержка Java 1.3.1, Unicode 3.1. Развиваются языки программирования Java и PL/SQL. Введена поддержка скроллируемого курсора для языков С и С++. Реализовано много изменений для ускорения процедур обновления (upgrade) приложений (быстрая загрузка PL/SQL-кода, переименование столбцов и ограничений целостности, отслеживание повторной загрузки неизмененного PL/SQL-кода и так далее). Развивается List Partitioning. Теперь можно использовать смешанный Range/List Partitioning и задать для List Partitioning секцию по умолчанию (default), куда будут попадать все записи с значениями, отсутствующими в списке List Partitioning. Реализована возможность параллельного выполнения DML-операций для таблиц, неразделенных на секции. 

В Oracle 9.2 реализована возможность сжатия данных при их хранении. Если в блоке данных встречается большое число одинаковых значений колонки таблицы, то дубли не хранятся, а реконструируются при запросе записи из блока. Это позволяет значительно снизить объем хранения данных и более эффективно использовать дисковые массивы. Особенно большой выигрыш это дает при создании хранилищ данных.

Oracle9i релиз 2 уже несколько месяцев успешно используется пользователями Oracle. Большинство новых возможностей, описанных в этой статье, уникальны и не только не реализованы у основных конкурентов Oracle (IBM, Microsoft), но даже и не планируются в будущих версиях их СУБД. Это относится и к RAC, и к эффективной поддержке XML, и к Oracle Streams и ... Таким образом, можно констатировать, что с выпуском Oracle9i релиз 2 компания Oracle обеспечила еще более высокий уровень надежности, быстродействия, защищенности и эффективности работы пользовательских приложений.

Oracle 9.2 является финальным релизом Oracle 9i. Поэтому мы рекомендуем всем пользователям СУБД Oracle постепенно переходить на использование этого релиза.  Сейчас компания Oracle работает над созданием Oracle 10i  и новой версии Enterprise Manager (OEM 4), которая позволит мониторить и настраивать не отдельные компоненты, а всю прикладную систему.