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

Поэтому за счет уменьшения или полного устранения фрагментации на уров-
не табличных пространств существенно уменьшается частота реорганизации
объектов (для того чтобы вернуть обратно потерянное пространство) или со-
здание в этом        пространстве новых файлов данных (в ответ на ошиб-
ки ORA-1653 или ORA-1654). Как говорится, лучший способ лечения от

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

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

памяти. - 

Прим. пер.), а 

именно: малый, средний, большой и очень большой. Так что же делают эти блоки с памятью в табличном пространстве? Многое. Чем бо­льше работы мы выполняем при определении логических блоков для объектов, тем меньше база данных будет склонна к фрагментации и реорганизации. Рас­смотрим это на реальном примере.

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

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

Фундаментальный принцип метода четырех областей памяти: если все эк­стенты в табличном пространстве имеют один размер, то по определению не возникнет проблем с фрагментацией памяти на уровне табличного пространст­ва. Так происходит потому, что все экстенты (независимо от того, свободны они или заняты) одного размера, и для Oracle не составляет труда приобрести требу­ющееся пространство для объекта внутри табличного пространства. При со­блюдении данного принципа появляется еще одно преимущество: отпадает

необходимость в периодическом объединении свободной памяти в табличном

пространстве.

Что такое объединение табличных пространств? Представьте себе ресто­ран, в котором шесть АБД хотят сидеть вместе, например во время ленча. Эти АБД не желают сидеть за тремя частично свободными столами в разных углах ресторана, за каждым из которых имеется по два свободных места. Для того что­бы разместить их, официанту придется принести три новых стола из запасни­ков

Так вот, мы скорее дождемся следующего появления кометы        чем то-

го, чтобы SMON "автоматически" объединил свободное пространство внутри

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

Подробности реализации метода четырех областей памяти при конфигурировании табличных пространств

Обрисованный ниже метод четырех областей памяти - это проверенный на местах способ группирования объектов и конфигурирования памяти, приме­ненный в начале 1998 г. для базы данных Огас1е8 размером 700 Гбайт. (Другим хорошим источником информации по предотвращению фрагментации являет­ся статья Bhaskar Himatsingka, Juan Loaiza. 

Stop Defragmenting and Start Living. 

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

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

Сгруппируйте объекты базы данных по этим четырем областям.

Определите подходящие значения по умолчанию параметров памяти для табличного пространства 

(initial и next) 

каждой области. Убедитесь, что 

initial 

и 

next 

имеют одинаковые значения. Установите параметр

распределения памяти по умолчанию для табличного пространства равным 0. Заметим, что установка 

pctincrease 

на 0 очень важна, так как это облегчает создание экстентов одного размера. Не

волнуйтесь, что SMON не сможет объединять свободное пространство,

если 

pctincrease 

= 0, потому что нам не потребуется эта возможность.

Создайте требующиеся табличные пространства с фразами памяти по умолчанию, определенными на третьем шаге.

Создайте объекты, привязанные (через фразу tablespace)

к требующемуся табличному пространству, без фразы storage.

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

6.        Сделайте исключения для объектов, к которым существует

одновременный доступ и/или которые имеют значительный размер.

7.        Повторите шаги с 1 по 6 для всех различных типов объектов вашей
среды (типа таблиц, индексов и кластеров).

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

Шаг 1: Создайте области Это говорит само за себя. В зависимости от исполь­зуемой среды необходимо создать осмысленное число областей. Почему их предлагается именно четыре? Для этого нет никаких особенных причин. Про­сто это число наиболее часто встречалось в наших реализациях. Если потребу­ется создать пять (или больше) областей памяти, как говорится, - полный

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

Шаг 2:        объекты Здесь требуется некая аналитическая работа,

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

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

Segment_Typ<B 

DBA SEGMENTS. Шаг 2 является весьма важным, поскольку он способствует собиранию объектов в соответствующие области памяти по их размерам. Приведенная ниже таблица служит примером определения областей и их предельных размеров. Подкор­ректируйте эти размеры в соответствии с требованиями вашей среды.

Область памяти        Предельное значение

Малая        Меньше 64 Мбайт

Средняя        Больше малой, но меньше 256 Мбайт

Большая        Больше средней, но меньше 1024 Мбайт

Очень большая        Больше 1024 Мбайт

■

Шаг 3: Определите параметры памяти по умолчанию табличных пространств: Initial и Next После того как на втором шаге определены облас­ти памяти, можно переходить к определению значений 

initial 

и 

next 

для таблич­ного пространства. Но прежде чем мы займемся этим, перед нами встает несколько вопросов, ответы на них объясняются средой, для которой проводят­ся действия:

•        Есть ли необходимость в создании нескольких больших/очень больших табличных пространств?

Ответ: Это очень важный вопрос, потому что может иметься несколько

очень больших объектов, доступ к которым из приложений должен быть

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

•        Как много экстентов может иметь каждый объект приусловии, что мы намереваемся хранить все объекты похожих размеров в табличном

пространстве?

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

•        Операции 

truncate table 

или 

drop table 

для таких объектов могут продолжаться многие часы. Это оказывает влияние на продолжительность реорганизации таких объектов или на их

доступность для приложения.

•        Многие тысячи экстентов создают многие тысячи элементов в таблицах управления памятью в словаре данных (например, sys.uet$ и sys.fet$). Это может снизить производительность рекурсивных SQL (операторов SQL, действующих в фоновом режиме во время
выполнения нормальных операторов        занимающихся

управлением памятью объектов в исследуемой среде.

•        Каков потенциал роста таких объектов и имеется ли в табличном пространстве достаточно свободной памяти после того, как созданы все объекты? Какие объекты растут быстрее других?

Ответ: Это очень важный вопрос, он помогает определить, какой раз­мер следует выбрать для файлов данных табличных пространств. Хотя файлы размером 2 Гбайта являются стандартными, если база данных очень велика (от нескольких сот гигабайтов до терабайтов) и операци­онная система поддерживает такие большие файлы, необходимо рас­смотреть вопрос об использовании файлов размером 4 Гбайта. Нужно в явном виде разрешить в исследуемой среде поддержку больших файлов. Необходимо знать свои приложение и базу данных, тогда не возникнет проблем при определении объектов, растущих быстрее, чем остальные.

•        Могут ли в будущем создаваться дополнительные файлы данных для таких табличных пространств и распределяться по независимым

физическим устройствам?

Ответ: И снова мы возвращаемся к вопросу о том, каким вам представля­ется рост данных. Ответ на него поможет также определить подходящие размеры экстентов для табличных пространств. Это породит другие во­просы: как много данных необходимо сохранить и как много можно вы­чистить или архивировать? Если при конфигурировании среды хранения задать адекватную память и логические тома, поддерживае­мые на нескольких устройствах (расслоенных и/или зеркалированных), возможно добавление новых файлов данных, и они будут поддерживать

большие табличные пространства. Ниже приводится таблица с примером значений параметров памяти таблич­ного пространства по умолчанию 

initial 

и 

next. 

Эти значения необходимо приве­сти в соответствие с требованиями среды.

Область памяти        Значения параметров initial и next

Малая        256 Кбайт

Средняя        1 Мбайт

Большая        4 Мбайта
Очень большая        Мбайт

Подставим в приведенный выше пример некоторые цифры, чтобы получить представление о том, каковы же на самом деле потери памяти. Давайте предпо­ложим, что мы работаем со средой, где содержится 20000 объектов. Из них

16000 объектов отнесены к малой области памяти, 2500 - к средней, 1000 объек­тов - к большой и, наконец, 500 объектов попадают в очень большую область. Если мы представим самый плохой сценарий, в котором последний экстент, распределенный для каждого объекта, всегда является пустым, то объем поте­рянной памяти для этой среды будет следующим.

4,00 Гбайта 2,44 Гбайта 3,90 Гбайта 7,81 Гбайта 18,15 Гбайта

Таким образом, при наличии 20000 объектов и самом плохом сценарии общие потери памяти составят всего 18,15 Гбайта. Даже при цене $100 за гигабайт (сред­няя рыночная цена высококлассной дисковой памяти для промышленных сис­тем) общий убыток будет равен $1815. Если поддерживать большую среду с приведенными выше характеристиками, можно говорить лишь о небольших из­менениях. По мерке сегодняшних дней мы теряем только один дисковод емко­стью 18 Гбайт. С другой стороны, давайте подумаем о преимуществах. Всего за можно получить базу данных, которая по принципам своего построения

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

службы или главный технический директор вашей организации склонят перед

вами голову зато, что эти результаты обошлись всего в 18 Гбайт (мы верим в это).

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

необходимое для выполнения контрольной точки (в результате

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

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

только DB_BLOCK_SIZE и параметры памяти уровня объекта не были сконфигурированы проактивно.

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

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

пространства от фрагментации. Крайне важно, что реорганизовывать объекты после реализации метода четырех областей памяти нужно без атрибута compress=y. Цель реорганизации заключается не в уменьшении числа экстентов, а в уменьшении или полном устранении фрагментации на уровне блоков и строк. Если объект реорганизуется с атрибутом компрессирования, то в конечном счете будут отменены все предлагаемые методом четырех областей памяти преимущества, потому что у нас снова появятся объекты с экстентами разных размеров.