в этой главе:

Ралмещетш обг,ешнов Определегте ра.гмеров объектов Задание параметров xpauemia

Соядапис скриптов Плаиироваиие реализации

Размещение и хранение объектов

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

Ниже приведен список задач, с которыми придется иметь дело на этом этапе проектирования:

принятие рещений о физических параметрах хранения информации (использование кластеров, физическое размещение файлов и т.д.);

определение размеров объектов базы данных (таблиц, индексов, сегментов отката и т.д.);

определение размера системной глобальной области (SGA);

планирование реализации и сдачи в эксплуатацию;

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

Размещение объектов

Это очень обширная тема, которая охватывает массу вопросов. Мы должны разработать план физического размещения абсолютно всех объектов системы. Вот перечень некоторых из них:

таблицы;

индексы;

кластеры (если таковые имеются);

словарь данных, включая весь хранимый PL/SQL-код (функции, пакеты, процедуры и триггеры);

сегменты отката;

журналы;

управляющие файлы;

исполняемые программы;

файлы базы данных;

файлы параметров инициализации;

журнальные файлы, генерируемые программой;

выходные данные, генерируемые программой;

скрипты;

загрузочные модули Oracle.

Для всех этих (и других) объектов нужно определить размеры (см. следующий раздел) и все их нужно разместить где-то в системе. Размещение объектов должно осуществляться так, чтобы обеспечить:

восстановимость;

оптимальную производительность;

гибкость.

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

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

Возможно, вам придется выполнить планирование размещения объектов базы данных на дисках для оптимизации производительности. Считается,

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

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

Прплтчание

Этого не произойдет, если используется технология RAID. Технология RAID подробно рассматривается в главе 14.

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

Еще один случай, когда проектировщик должен представить необходимые данные, - размещение объектов базы данных по табличным пространствам. Если администратор БД планирует отключать некоторые табличные Пространства (например, для копирования), то проектировщик может выявить зависимости между объектами в отключаемых пространствах и объектами, которые требуются для поддержки работающих в это время приложений.