Oracle считается одной из наиболее надежных и популярных систем управления базами данных. Что ждет пользователей в вышедшей относительно недавно версии Oracle 9.2?

В СУБД Oracle 9i Release 2 созданы новые и усовершенствованы существовавшие ранее механизмы обеспечения надежности и масштабируемости (Real Application Cluster, Logical Standby, FlashBack). Включена поддержка XML. В сервер Oracle интегрированы средства поддержки оперативной аналитической обработки и добычи данных. Появился механизм Oracle Streams. Усовершенствованы средства управления, самонастройки и настройки. Наконец, предусмотрена поддержка архитектуры IA-64.

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

Real Application Cluster

Достижением Oracle 9i в области обеспечения высокой надежности и масштабируемости были средства поддержки кластеризации. Компонент RAC позволяет повысить надежность (при выходе из строя одного из узлов система продолжает функционировать), увеличивает масштабируемость (пользователи одной базы данных и одного приложения «размазываются» по всем узлам кластера), позволяет постепенно наращивать мощность системы, не останавливая ее работу. При создании Oracle 9.2 разработчики оптимизировали поток информации, передаваемой между узлами кластера, использовали механизм битовых масок для управления пространством внутри сегмента и т.д.

Для упрощения установки, настройки и сопровождения кластера создан компонент RACGUARD2, который в ряде случаев автоматизирует администрирование кластера. Данный компонент позволяет: устанавливать кластер на несколько узлов так же, как устанавливается сервер Oracle на один узел; работать с кластером как в целом, так и с его отдельными узлами; объединять узлы в логические рабочие группы, определяя, что данная группа выполняет только операции выборки или работает только с конкретными приложениями; упрощает переключение узлов кластера. Раньше при создании на кластере базы данных необходимо было размещать файлы баз данных на так называемых «сырых устройствах» (raw device), что требовало более высокой квалификации администратора и усложняло выполнение операций копирования/восстановления. В Oracle 9.2 компонент Oracle Cluster File System (кластерная файловая система) позволяет хранить и программное обеспечение Oracle и файлы базы данных кластера в обычной файловой системе; использование «сырых устройств» более не является обязательным, хотя они и ускоряют работу с файлами базы данных. Большая часть расширений операционной системы, необходимых для работы кластера, поставляется Oracle и устанавливается в виде Oracle Portable Clusterware, что также упрощает создание кластера.

Механизм Logical Standby

Увы, в большинстве случаев узлы кластера находятся в пределах одного здания, поэтому при уничтожении или длительном обесточивании здания все узлы RAC выходят из строя, а потому продолжить работу системы становится невозможным. На этот случай в Oracle рекомендуют использовать механизм резервной (standby) базы данных, идея которого состоит в том, что копия эксплуатационной базы находится на большом удалении от основного вычислительного центра и постоянно «догоняет» основную базу данных.

До сих пор СУБД Oracle позволяла реализовать режим Standby физически: резервная база данных должна была быть полной копией основной, в ней нельзя было создавать дополнительные объекты, индексы и т.д. Физическую резервную базу данных можно было временно переводить в режим чтения, чтобы, скажем, напечатать отчеты, но на это время ее восстановление прекращалось, нельзя было оптимизировать операции чтения. Причина этого ограничения заключалась в том, что изменения от эксплуатационной базы данных передавались в резервный центр и там применялись на физическом уровне (быстрая прямая запись в базу). В Oracle 9.2 реализован механизм Logical Standby. Его отличие от физического заключается в том, что передаваемые в резервный центр изменения предварительно преобразуются в операторы SQL, причем процесс восстановления не блокирует работу базы данных в режиме чтения других пользователей. Теперь вспомогательная база выступает не только в роли резервной базы данных, но на ней можно одновременно с восстановлением формировать отчеты, решать аналитические задачи и т.д. Если для повышения эффективности выполнения этих задач надо создать дополнительные индексы, материализованные представления и т.д., то в логической резервной базе данных можно сделать и это.

Механизм FlashBack

Ряд сбоев в работе приложений не связан с надежностью работы оборудования или программного обеспечения, а вызван ошибками пользователей. Для борьбы с подобными сбоями в СУБД Oracle предусмотрен механизм FlashBack, позволяющий пользователю, испортившему свои данные, попросить состояние этих данных на момент времени в прошлом (до порчи), после чего неиспорченные данные можно сохранить, сравнить их с новым состоянием данных и т.д. В Oracle 9.1 для этого надо было вначале выполнить процедуру, переводящую весь сеанс пользователя в прошлое, затем получить старое состояние данных, а потом снова вернуть весь сеанс в настоящее состояние. В Oracle 9.2 пользователь может указывать, что данные ему нужны на какой-то момент времени в прошлом прямо в SQL-запросе Select, что сильно упрощает работу.

Поддержка XML, дуализм XML/SQL

Сервер Oracle теперь поддерживает не только реляционную, объектную, многомерную модель данных, но и XML. В версии 9.1 большие объемы XML-данных можно было поместить в виде XML-файлов в LOB-полях как единый кусок текста. Иначе содержимое XML-файла разбиралось и «разбрасывалось» по реляционным таблицам, а при запросе вновь собиралось в файл. В версии 9.2 поддерживаются XML-схемы и можно хранить XML-данные еще и в виде собственно XML-объектов: таблиц с типом XMLType и колонок типа XMLType.

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

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

Поддержка OLAP

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

Алгоритмы добычи данных (data mining), реализуемые ранее программным продуктом Darvin, теперь тоже встроены в сервер Oracle 9i сервер. Разработчики могут строить различные модели зависимости данных, а потом использовать эти модели для получения рекомендаций, причем и данные, и модели хранятся в базе данных Oracle.

Механизм Oracle Streams

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

  • в случае репликации захватываются и передаются изменения данных и вызовы удаленных процедур;
  • в случае работы с очередями сообщений (Advanced Queuing) передается информация о появлении сообщений и сами сообщения;
  • в случае резервирования базы данных передаются и применяются к резервной базе архивированные журнальные файлы или их элементы;
  • в случае загрузки данных в хранилища данных или Operating Data Store передаются загружаемые данные.

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

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

Совершенствование средств управления и настройки

С каждой новой версией сервера Oracle происходит совершенствование средств управления и настройки СУБД, сосредоточенных в компоненте Oracle Enterprise Manager (OEM). Кроме того, все больше проблем по настройке решается автоматически или с помощью программ-«советчиков» (Wizard). Версия 9.2 не стала исключением.

Многие ресурсы СУБД взаимозависимы, например, чтобы ускорить работу сервера, приходится выделять больше оперативной памяти, а чтобы уменьшить время восстановления базы данных приходится жертвовать быстродействием и т.д. Для уменьшения этих «жертв» в версии 9.1 в OEM появились «советчики», показывавшие диаграммы зависимости ресурсов для буферного кэша и для UNDO-области. Глядя на эти диаграммы, администратор мог понять, как надо увеличить/уменьшить размер области, и что это дает с точки зрения эффективности использования ресурсов. В версии 9.2 добавлены аналогичные средства для оптимизации размера разделяемой области памяти (Shared Pool), области выполнения SQL-операторов и минимального времени восстановления после сбоя (Mean Time To Recovery). Теперь администратор сможет понять, насколько возрастет интенсивность ввода/вывода и снизится скорость работы системы при конкретном задании минимально допустимого времени восстановления базы данных. Кроме того, эти диаграммы позволяют проводить анализ типа «что будет, если», моделируя ситуацию заранее.

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

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

Прочие усовершенствования

СУБД Oracle 9i Release 2 будет работать на компьютерах на платформе Itanium с 64-разрядными вариантами операционных систем Linux, HP-UX и Windows.

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

Марк Ривкин (mark.rivkin@oracle.com) — руководитель группы консультантов по серверным технологиям компании Oracle (Москва).