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

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

Подробно проектирование для систем параллельной обработки рассматривается в главе 14.

Обеспечение высокой производительности

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

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

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

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

Ключи и индексы

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

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

Что касается нашего приложения-примера, то, думается, кластеризация здесь не подходит. Однако мы создадим некоторые дополнительные индексы для наших таблиц, чтобы улучшить реакцию на запросы. Например, мы создаем индекс для столбца REGISTRATION NUMBER таблицы RENT-AL CARS (первичный ключ этой таблицы - CAR ID), чтобы автомобили можно было легко найти с помощью уникального ключа, который государство требует указывать на заднем бампере каждого автомобиля (а в большинстве стран мира - и на переднем). (Шире эта тема освещается в главе 6.)

Денормализация

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

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

В нашем приложении-примере мы создаем в таблице CUSTOMERS столбец OUTSTANDING INVOICE AMOUNT, содержащий сумму по столбцу INVOICE AMOUNT таблицы INVOICES для клиента, значение STATUS которого в данный момент не равно PAID. Это позволяет быстро проверять

задолженность клиентов, не читая счетов-фактур. Мы определяем триггеры на таблице INVOICES, которые ведут это значение. Например, если значение в столбце STATUS для данного клиента изменяется на PAID, значение INV0ICE AM0UNT вычитается из OUTSTANDING INVOICE AMOUNT в таблице CUSTOMERS.

Более подробно денормализация освещается в главе 4.

Выбор оптилшзатора

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

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

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

Принятие решения о выборе оптимизатора тесно связано со стратегией индексирования. Эта тема рассматривается в главе 6.

Методы программирования

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

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