Поддержка 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