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

Версия 7. О

В этом разделе представлены ключевые особенности СУБД Oracle версии 7.0, которые оказывают существенное влияние на проектирование.

Триггеры, процедуры и функции

В первых выпусках Oracle? была реализована возможность хранения и выполнения кода внутри базы данных либо в форме триггеров, которые могли применяться к таблицам, либо в форме процедур и функций, вызываемых из клиентского приложения через анонимные блоки PL/SQL.

PL/SQL - переносимый язык третьего поколения, запатентованный корпорацией Oracle, - в версии ?.0 подвергся существенной модернизации, но область его применения все равно остается несколько ограниченной. Хотя у этого языка есть ряд особенностей, которые делают его привлекательным и эффективным для реализации правил обработки данных и бизнес-правил в схеме базы данных, на наш взгляд, ему не хватает мощности и гибкости для того, чтобы стать реальным инструментом для написания завершенного приложения.*

С точки зрения архитектуры важно уяснить, что процессор PL/SQL, по сути, не зависит от процессора SQL и может быть использован в других средах, например, в Oracle Forms и Oracle Reports.

Ключевой задачей проектирования для Oracle? является эффективное распределение функций между прикладным кодом и кодом, хранящимся в базе данных.

Оппишизатор по стошюсти

В версии ?.0 был также введен предложенный Oracle оптимизатор по стоимости (о котором мы упоминали выше, в разделе Выбор оптимизатора ), а также новый SQL-оператор ANALYZE, обеспечивающий сбор статистической информации. Хотя новый оптимизатор и позволил получить определенную выгоду, производительность оптимизации по стоимости не оправдала ожиданий многих пользователей Oracle и они продолжали пользоваться оптимизатором по правилам в существующих (а иногда и в новых)

Тем не менее, Стивен Фойерштейн делал с этим языком потрясающие вещи. См. Oracle PL/SQL Programming (OReilly & Associates, 1995) и Advanced Oracle PL/SQL Programming with Packages (1996).

приложениях. Оптимизатор по стоимости в Oracle версии 7.0 не учитывает распределение ключевых значений и не имеет стоимостной модели оценки выполнения условий в запросах.

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

SELECT е.employee name FROM employees е WHERE NVL(е.division, NULL) = SALES;

При использовании оптимизатора по стоимости тот же эффект достигается более рациональным способом:

SELECT /*+ FOLL Е */ е.employee name FROM employees е WHERE е.division = SALES;

Вторая форма дает существенное повыщение производительности, поскольку здесь к каждой строке таблицы не примеггяется функция NVL. Функции SQL работают достаточно эффективно, но этот язык является интерпретируемым и затрат на выполнение функций лучще избегать.

Примечание

В больщинстве книг и курсов по Oracle рекомендуют применять конкатенацию или сложение для подавления использования индекса. Например:

WHERE е.division М = SALES

WHERE e.deptno + О = 30

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

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

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

о границ ения целости ости

Помимо возможности определять триггеры на таблицах, в версии 7.0, в дополнение к ограничению NOT NULL, были реализованы Другие ограничения целостности. Это первоначально планировалось сделать в Огас1е6. Однако эта версия поддерживала только синтаксис, а его реализация отсутствовала. Одна из особенностей, которая не переставала поражать технических специалистов с момента появления Oracle?, - это явное нежелание проектировщиков и администраторов БД применять ограничения целостности, средство, которое признано как эффектным, так и эффективным.

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

Распределенная база данных

В версии ?.0 к имеющимся в SQL*Net средствам поддержки операций с распределенными базами данных были добавлены DML-операции (INSERT, UPDATE, DELETE, LOCK, SELECT FOR UPDATE). Для этого была реализована полностью прозрачная форма двухфазной фиксации (2ФФ). Несмотря на свою эффектность, эта возможность широко не использовалась, чему был целый ряд пршшн (мы обсудим их в главе 12). Проектирование сетевой топологии и распределение данных между узлами открывает совершенно новую дисциплину в проектировании БД Oracle.

Был введен новый тип объекта базы данных, снимок, и создан механизм, позволяющий переносить изменения, внесенные в таблицу на одном узле, на другие узлы (снимки) с заданным интервалом. Этот механизм обладал рядом проектных и реализационных дефектов, которые устранены в последующих версиях.

Производительность сервера

В версии ?.0 были приняты меры по устранению некоторых проблем производительности, которые проявлялись в версии 6, и внесены существенные изменения в механизм управления кэшами процессора SQL.

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

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