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

• создание новых и совершенствование старых механизмов обеспечения надежности работы и масштабируемости (RAC, Logical Standby, Flashback);
• поддержка XML в БД;
• встраивание в сервер Oracle средств поддержки OLAP и Data Mining;
• Oracle Streams;
• совершенствование средств управления, самонастройки, настройки СУБД;
• поддержка архитектуры IA64.

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

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

REAL APPLICATION CLUSTERS

Крупнейшим достижением 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, что также упрощает создание кластера. Появилась возможность объединять узлы кластера в логические рабочие группы и связывать приложения с этими рабочими группами. Тем самым можно регламентировать, с какими узлами кластера будет работать конкретное приложение.

LOGICAL STANDBY

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

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

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

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