Oracle - Глава 9. Размещение и хранение объектов

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

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

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

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

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

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

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

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

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

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

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

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

Когда в процессе проектирования мы превращаем сущности в таблицы, мы используем эти значения. Однако, если соответствие сущности таблице не однозначное, то приходится выполнять ряд дополнительных расчетов. Имея таблицы, можно начинать оценку общих требований к пространству. Необходимо оценить среднюю длину строки, определив при этом, у какой части строк в столбце будет неопределенное значение и каков средний размер содержимого, например, столбца типа VARCHAR2(50). Следует также оценить степень увеличения длин строк вследствие задания значений для ранее неопределенных столбцов и увеличения длины символьных столбцов переменной длины. Ответы на эти вопросы укажут объем пространства, которое мы оставим в блоках для увеличения длин строк.

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

Проектировщик может ознакомить администратора БД с тем, какие отчеты и пакетные программы запланированы к выполнению ночью, а также проинформировать его о требованиях к сегментам отката для оперативных процессов на дневное время. Будьте осторожны, так как здесь вас тоже подстерегают опасности. Например, традиционно считают, что для OLTP-систем нужны очень маленькие сегменты отката. Однако это верно лишь для "чистой" OLTP, и как только задается "длинный" запрос, в котором используются записи, обновляемые OLTP-приложением, возникает необходимость в сегментах отката, достаточно больших для того, чтобы избежать ошибки вследствие циклической перезаписи в сегменте отката. Если нужно выяснить, как часто осуществляется переход от одного экстента к другому в сегменте отката, проследите за столбцом WRAPS в системной динамической таблице V$ROLLSTAT.

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

Oracle дает рекомендации по конфигурированию серверов и клиентов. Например, для работы загрузочного модуля Oracle Forms версии 4.5 на ПК с процессором Intel или эквивалентным необходимо минимум 8 Мбайт оперативной памяти, а рекомендуется хотя бы 12 Мбайт. На практике для большинства серьезных приложений 8 Мбайт явно недостаточно, но вопрос состоит в том, сколько же следует заказать — 12 Мбайт, 16 Мбайт или больше? Если на момент размещения заказа на оборудование степень готовности приложения не достаточна для прогона тестов на загрузку и производительность, то приходится определять объем памяти методом предположения, который, как правило, ошибочен. Опыт ничем не заменишь; в идеале это должен быть опыт работы с данным приложением, а в отсутствие оного — с очень похожим на него. Не следуйте советам продавца — если только он не дает твердую гарантию, что оплатит любую модернизацию в случае, если его совет окажется неверным.

А сейчас давайте рассмотрим требования к памяти сервера. Oracle также дает рекомендации по поводу того, сколько оперативной памяти должно приходиться на каждого из параллельно работающих пользователей. Конечно, это приблизительная цифра, поскольку она зависит от характера приложения. Например, если вы планируете использовать хранимые процедуры, манипулирующие большими PL/SQL-таблицами, то вам, возможно, нужно будет откорректировать рекомендацию Oracle с учетом непредвиденных обстоятельств. Существует эмпирическое правило, согласно которому на одного подключенного пользователя должно быть не менее 1,5 Мбайт. Вам будут говорить о многопоточном сервере Oracle, об улучшениях в потреблении памяти в версии 7.3 и приводить другие аргументы в пользу уменьшения этой величины, но опыт показывает, что уменьшить ее вряд ли возможно. При работе со сложными многофункциональными приложениями эта цифра может вырасти до 5 Мбайт на подключенного пользователя, и чем больше используется хранимых PL/SQL-процедур, тем больше должна быть SGA, чтобы кэшировать скомпилированный код. Для такого приложения возможно, придется оперировать размерами кэша свыше 100 Мбайт.

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

При создании любого объекта для хранения данных (сегмента отката кластера, таблицы или индекса) можно задавать набор физических параметров. Кроме того, эти параметры можно (и следует) указывать при создании ограничений PRIMARY KEY и UNIQUE; их действие распространяется и на индекс, созданный для поддержки этих ограничений.

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

Определяя параметры хранения, придерживайтесь следующих правил:

Дополнительные указания по этому поводу вы найдете ниже.

Следуя приведенным выше правилам, администратор БД может создавать табличные пространства для маленьких объектов (со значениями INITIAL и МЕХТ по умолчанию, равными 10 Кбайт), для средних объектов (100 Кбайт) и так далее. При этом фрагментация табличного пространства в классическом виде будет невозможна. Вероятно, не все экстенты объектов будут находиться в непрерывном пространстве, но это не имеет значения.

В версии 7.3, где число экстентов для объекта уже не ограничено размером заголовочного блока сегмента, может потребоваться установить для объекта максимальное число экстентов (MAXEXTENTS). Реже встречаются случаи, когда нужно установить минимальный размер объекта с помощью MINEXTENTS. Управление пространством в Oracle не является таким трудоемким процессом, чтобы нельзя было себе позволить добавить экстент в режиме реального времени, поэтому единственная нормальная причина использования MINEXTENTS — резервирование места для объекта на случай увеличения его в табличном пространстве, которое в противном случае переполнилось бы. Если подумать, то это нелогично, так как означает, что какой-то другой объект не сможет увеличиться в размерах, а это может оказаться не менее важной проблемой.

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

Осталось рассмотреть параметры PCTFREE и PCTUSED, которые используются незаслуженно редко. Возьмем простой случай. PCTFREE для индекса применяется только во время создания индекса и задает объем свободного пространства, которое необходимо оставить в блоках-листьях. Однако, используя этот параметр, можно существенно ускорить сопровождение индексов в приложениях, где новые и существующие значения индекса распределены случайным образом. Хороший пример такого случая - индекс по фамилиям в таблице служащих (если только принятая в организации политика найма не предполагает дискриминации по первой букве фамилии). Если у нас 10000 служащих и за период существования индекса ожидается прием на работу еще 2000, то хорошее значение для PCTFREE — 25, которое почти гарантирует, что ни один блок-лист индекса не будет разбит.

Если индекс строится для ключа, где каждое новое значение больше текущего (например, для ключа, построенного на возрастающей последовательности), то единственно приемлемое значение параметра PCTFREE - нуль.

С таблицами (и кластерами) PCTFREE используется при операциях вставки и предписывает оставить после вставки строки свободной как минимум указанную долю блока. В действительности свободным остается несколько больше пространства — как правило, PCTFREE плюс половина средней длины строки. Это пространство может использоваться находящимися в блоке строками, которые расширяются в результате операций обновления. Приведенный ниже оператор UPDATE может вызвать увеличение длины строки, так как неопределенное значение превращается в 37-символьную строку.

Для необновляемых таблиц рекомендуется установить PCTFREE равным 0 — для экономии дискового пространства (и, следовательно, для ускорения полного сканирования таблиц). Для таблиц, которые обновляются, рекомендуем определить PCTFREE на основе вероятных длин строк при создании и после обновления и сообщить предлагаемое значение администратору БД.

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

Параметр PCTUSED используется операцией DELETE (и UPDATE), для того чтобы определить, когда блок можно поместить в список свободных (т.е. когда он станет доступным для вставки строк). Как только использованное пространство в блоке становится меньше этой величины, блок вновь становится доступным для вставки. Естественно, если сумма значений PCTFREE и PCTUSED слишком близка в 100 процентам, то блоки будут включаться в список свободных и исключаться из него очень часто. Во многих версиях Oracle есть защитный код, предотвращающий это. Предполагаемая цель этого кода — сделать блоки "утерянными" для механизма свободного пространства. Трудно преувеличить вред, который может принести желание сэкономить при помощи PCTUSED, и во всех ситуациях, кроме самых неординарных, рекомендуем устанавливать этот параметр в нуль.

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

Скрипт — это файл, который пользователь запускает для того, чтобы избежать утомительной работы по вводу команд вручную. Существуют скрипты для таких средств Oracle, как SQL*Loader, SQL*Plus, SQL*DBA и Server Manage, а также скрипты для операционных систем, например, скрипты интерпретаторов команд Unix. В большинстве проектов имеется набор полезных скриптов, с помощью которых можно создавать тестовые и "живые" среды, а иногда и данные. Если используется CASE-средство, то оно должно само создавать большинство скриптов на основе информации, хранящейся в репозитарии. Многие скрипты, разработанные на этапах проектирования и генерации, используются затем при тестировании и эксплуатации системы. Вот некоторые задачи, для реализации которых требуется разработка скриптов:

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

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

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

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

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

Знаете ли Вы, что диаграмма состояний состоит
- из множества состояний объектов;
- из множества событий, сообщающих о перемещении чего-либо в новое состояние;
- из множества правил переходов, определяющих новое состояние объекта при возникновении тех или иных событий;
- из множества действий, которые должны быть выполнены объектом, когда он переходит в новое состояние.