Определение размеров объектов

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

Определение размеров таблиц

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

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

Определение размеров сегментов отката

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

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

сегменте отката, проследите за столбцом WRAPS в системной динамической таблице V$ROLLSTAT.

Определение объемов памяти и SGA

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

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; их действие распространяется и на индекс, созданный для поддержки этих ограничений.

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

- Пример скрипта создания таблицы

CREATE TABLE rules

{ rule* NUMBER NOT NULL

CONSTRAINT rules pk PRIMARY KEY USING INDEX TABLESPACE user indexes PCTFREE 0

STORAGE (INITIAL lOOK NEXT lOOK PCTINCREASE 0) , comment VARCHAR2(1000) NOT NULL )

TABLESPACE users PCTFREE 20 PCTUSED 0 INI TRANS 1 MAXTRANS 10

STORAGE ( INITIAL IM NEXT IM PCTINCREASE 0 MINEXTENTS 10 MAXEXTENTS 100 FREELISTS 10 FREELIST GROUPS 5 );

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

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

Всегда следует устанавливать параметр PCTINCREASE в нуль, потому что любое другое значение может вызвать фрагментацию свободного табличного пространства.

Для каждого табличного пространства следует установить значения INITIAL и NEXT равными друг другу.

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