использования комбинации двух вышеупомянутых технологий. В старых версиях Oracle использование OCI могло привести к созданию программ, которые работали во много раз медленнее, чем эквивалентная программа на Рго*С или Pro*COBOL. В Oracle? этот недостаток устранен, но пользователи, вероятнее всего, так и не увидят никакого повышения производительности при работе с OCI.

Версия 7.3

Выпуск версии ?.3 ознаменовал собой появление большого числа важных новых возможностей. По сути дела, как уже отмечали представители Oracle на конференциях и брифингах, единственная причина, по которой версию ?.3 не назвали OracleS, состоит в том, что название OracleS было давно зарезервировано для объектно-ориентированного расширения Oracle.

Разделяемый пул

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

Гистограммы зпачеппп

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

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

Во-вторых, у оптимизатора запросов версии 7.3, как и прежде, нет модели, которая угитывает загрузку центрального процессора, связанную с выполнением предложений, содержащих условия. Для ранних версий оптимизатора по стоимости была характерна сильная тенденция к использованию полного сканирования таблицы для условий, которые выполнялись бы быстрее посредством диапазанного сканирования индекса. В результате тестов, проведенных для версии 7.3.2, обнаружилось, что в некоторых случаях оптимизатор выбирал полное сканирование таблицы там, где диапазонное сканирование индекса выполнялось бы быстрее, а в других случаях

он выбирал диапазонное сканирование индекса вместо полного сканирования таблицы.

В-третьих, Oracle не распространила сферу использования распределений значений на оптимизацию запросов, содержащих связанные переменные. Например, запрос следующего вида

SELECT COUNT(*) FROM trades WHERE currency = NOK

оптимизировать довольно просто, если имеются индекс по валюте (CURRENCY) и гистограмма, показывающая, что значение NOK встречается менее чем в 1,25% случаев. Если же эта гистограмма говорит о том, что значение USD встречается более чем в 85% случаев, то единственно правильного варианта оптимизации для запроса

SELECT COUNT(*) FROM trades WHERE currency = :curr;

не существует, и для выбора хорошей стратегии доступа мы должны знать значение связанной переменной. Это серьезная проблема, поскольку с годами программисты, работающие над высокопроизводительными приложениями, вбили себе в голову, что связанные переменные {-.сипь приведенном примере) - лучший подход к использованию разделяемого пула и экономии времени на синтаксический анализ. Возникает эта проблема потому, что Oracle придерживается своего традиционного подхода: оптимизация каждого дерева синтаксического анализа производится до его первого выполнения, а затем этот же план запросов используется для последующих выполнений.

Снятие ограничении па число экстентов

В версии 7.3 каждый объект (таблица, индекс, кластер, сегмент отката, временный сегмент) может иметь неограниченное число экстентов в базе данных. Эта особенность очень полезна для администраторов БД. Для проектировщика она уменьшает потенциальный ущерб от ошибок в планировании пространства.

Bitmap -индексы

До версии 7.0 Oracle поддерживала только индексы со структурой В-де-рева. В версии 7.0 были введены хеш-кластеры, но они оказались не особенно привлекательны для проектировщиков и разработчиков. Хеш-кластеры, как оказывается, используются относительно редко, и, по некоторым данным, те, кто их использует, ожидаемого повышения производительности не добились.

В версии 7.3.3 Oracle поддерживает bitmap-индексы на сервере (они в течение нескольких лет используются в продукте SQL*TextRetrieval). Bitmap-Индексы могут быть очень эффективными для не очень избирательных Ключей, например, для внешних ключей к таблицам с кодовыми значениями, особенно когда в условии WHERE указано несколько таких ключей и Используется логическая операция AND.

Новые способы выполнения соединении

Традиционными для Oracle стратегиями эквисоединений являются вложенные циклы (nested loops) и сортировка-слияние (sort merge). Эти методы очень эффективны, но дают плохую производительность при определенных условиях, обычно существующих в приложениях хранилищ данных и OLAP-приложениях.

В версии 7.3 Oracle предложила соединения по схеме звезда и хеш-соединения. Оптимизатор запросов может развертывать их раздельно или вместе.

Соединение по схеме звезда ориентировано на запросы, где центральная таблица фактов соединяется с несколькими справочными таблицами, каждая из которых может соединяться с таблицей фактов, но никогда не соединяется с другими справочными таблицами. Соединение по схеме звезда нацелено на использование именно такого отсутствия взаимосвязей - сначала формируется декартово произведение всех нужных строк из справочных таблиц, а затем выполняется его соединение с таблицей фактов. Соединения по схеме звезда особенно уместны в приложениях для хранилищ данных.

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

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

А/)хитек1пурп сетевых вычислении

По мере усовершенствования сетевых продуктов Oracle их коммуникационные возможности расширялись, и сейчас эти продукты обеспечивают не только выполнение SQL-предложений на сервере, но и передачу удаленных вызовов процедур.

В рамках новой архитектуры - Network Computmg Architecture (Архитектура Сетевых Вычислений, рис. 2.1) Oracle опубликовала ряд стандартных интерфейсов, позволяющих картриджам, или именованным сервисам, делать запросы и отвечать на запросы, поступающие из других картриджей. Эти картриджи, которые могут включать относительно традиционные клиенты и серверы, формально не организованы в иерархию, но каждый из них взаимодействует с общим связующим уровнем. Здесь просматривается четкая аналогия с World Wide Web и, действительно, в качестве одного из языков для создания картриджей поддерживается Java. Следует также ожидать, что Oracle будет продвигать свой сетевой компьютер (Network Computer, NC) как основной пользовательский интерфейс для выполнения картриджей, написанных на Java.