Заметки об преодолении фрагментации при переходе на Oracle10g

Предисловие

Эта статья является продолжением статьи Б.Шиматсингка и Дж. Лойаза "Устраните фрагментацию и начните жизнь заново: прощальное слово о фрагментации", которая публикуется в этом же выпуске журнала. В своем к ней предисловии я написал, что хотя на первый взгляд статья специалистов из корпорации Oracle уже давно устарела, поскольку относится к эпохе баз данных Oracle7.3/8.0, для того, чтобы изложить свой материал по Oracle8i/9i/10g мне бы пришлось почти полностью повторить информацию от Б.Шиматсингка и Дж. Лойаза.

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

Полностью устранять фрагментацию сегментов (то есть, приводить сегмент к одному экстенту как рекомендовалось до Oracle8) не стоит, да и вряд ли получится в виду огромных размеров современных, таблиц, индексов, LOB-сегментов. Но заботиться о правильной организации памяти табличных пространств необходимо постоянно.

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

Введение

В настоящее время большое число промышленных баз данных Oracle, использующих версии Oracle8i/9i, в массовом порядке переходят под управление Oracle10g. Миграция промышленной информационной системы, работающей под управлением СУБД Oracle, включает в себя миграцию собственно базы данных (перенос данных), построение инфраструктуры среднего слоя (middle ware) применительно к системе Oracle10g и миграцию, настройку, модернизацию (если потребуется) и тестирование промышленных приложений, обрабатывающих информацию, перемещенную в базу данных Oracle10g. [Примечание: вопросы построения инфраструктуры среднего слоя и миграции приложений в этой статье не рассмаьриваются.] В силу эволюционного развития системы Oracle, при переходе на новый релиз большинство возможностей и механизмов обработки данных предыдущего релиза СУБД сохраняются, что позволяет "по-старому" использовать унаследованные приложения с минимальной доработкой или только поднастройкой. Однако при непосредственном (прямом) переносе унаследованной системы на Oracle10g сохраняются и продолжают оказывать негативное влияние практически все допущенные при проектировании и реализации унаследованной системы ошибки и неточности, как в части программной логики, так и в построении и распределении структур данных в промышленной базе Oracle. В качестве примера, к наиболее ярким таким некорректностям (с точки зрения уже Oracle10g) можно отнести использование синтаксического анализатора (RULE) вместо стоимостного (CHOOSE) и управление экстентами сегментов (таблиц, индексов, кластеров,...) посредством словаря данных (dictionary management) вместо локального управления (local management).

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

Миграция базы данных Oracle8i/9i в базу данных Oracle10g

Миграция базы данных Oracle8i или Oracle9i под управление СУБД Oracle10g может происходить разными способами, из которых наиболее приемлемыми являются

• экспорт всех пользовательских данных из базы данных Oracle8i/9i и последующий импорт их в базу данных Oracle10g;
• использование механизма миграции (утилита Database Upgrade Assistant или скрипт $ORACLE_HOME/rdbms/admin/catupgrd.sql), предусмотренного в Oracle10g, при котором физические файлы данных и журнала непосредственно переходят под управление СУБД Oracle10g с немедленным проведением обновления содержания мигрируемой базы для Oracle10g.

В обоих случаях предварительно должна быть проинсталлирована СУБД Oracle10g с включением требуемых механизмов и опций (например, bit-mapped indexes - использование двоичных индексов, и/или partitioning - секционированные таблицы, и/или online index build (пере)построение индексов одновременно с использованием таблицы и т.д.).

Достоинства метода экспорт/импорт:

• сохранение старой базы в качестве резервной или для сохранения хронологических данных;
• возможность переопределения физических параметров памяти сегментов в табличных пространствах путем предварительного создания сегментов (и модификации определений индексов) в новой базе перед импортом данных;
• автоматическое устранение внутриблочной, межблочной, экстентной фрагментации;
• автоматическое перестроение индексов с устранением недостатков их физической структуры;
• автоматический перенос таблиц со столбцами типа LONG и LONG RAW;
• автоматическая компиляция модулей хранимой логики (функции, триггеры, процедуры, пакеты и тела пакетов,...).

Недостатки метода экспорт/импорт:

• все время проведения операции экспорт/импорт "старая" база должна быть остановлена на выполнение операций DML (insert, update, delete) и DDL (create/alter/drop/truncate), чтобы сохранить целостность экспортируемых данных. База может работать только в режиме select;
• очень большое время для проведения операций экспорта и импорта данных, а также пересоздания индексов. Время такой масштабной операции для базы данных размером в 800-1000 Гигабайтов можно оценить примерно до 10 суток даже при организации параллельной работы утилит экспорта и импорта;
• требуется дополнительная дисковая память для размещения файлов экспорта, которые затем используются для импорта данных;

Достоинства метода непосредственной миграции базы данных:

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

Недостатки метода непосредственной миграции базы данных:

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

Необходимые сведения по структурам дисковой памяти базы данных Oracle

Понятие фрагментации дисковой памяти применимо только к сегментам, для которых дисковая память выделяется в виде экстентов.

Типы сегментов в базе данных Oracle Таблица 1.

Примечание: Сегменты типов CACHE, DEFERRED ROLLBACK, TEMPORARY, TYPE2 UNDO в процессах фрагментации/дефрагментации и экспорта/импорта участия не принимают.

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

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

Размер блока определяется:

• в базе данных Oracle8i - только при создании базы (обычно 2, 4, 8 или 16К). Все блоки данных базы Oracle8i одинаковы;
• в базах данных Oracle9i/10g - при создании создании базы (параметр по умолчанию db_block_size) и конкретного табличного пространства (параметр block_size по умолчанию равен db_block_size, но может принимать значения 2, 4, 8, 16 или 32К. В этом случае в SGA (глобальная системная область) должные быть выделены пулы буферов оперативной памяти соответствующих размеров - параметры инициализации db_2k_cache_size, db_4k_cache_size, db_8k_cache_size, db_16k_cache_size, db_32k_cache_size).

Размер экстентов сегментов определяется по умолчанию из характеристик табличного пространства или явным заданием характеристик экстентов.

• В первом случае - табличное пространство поддерживает локальное управление экстентами или при управлении экстентами посредством словаря данных в предложении создания сегмента не были явно определены его физические параметры;
• Во втором случае - при управлении экстентами через словарь данных и явным заданием характеристик экстентов.

Для учета, выделения и перераспределения занятой, свободной, освобождаемой и требуемой физической памяти в табличных пространствах СУБД Oracle обладает двумя механизмами:

• управление экстентами посредством словаря данных (dictionary management) и
• локальное управление (local management) экстентами табличных пространств.

Для каждого табличного пространства при его создании явно и/или по умолчанию определяются параметры физических характеристик, размещаемых в нем сегментов, в частности:

• BLOCK_SIZE - размер блока данных для записей;
• EXTENT_MANAGEMENT определяет каким образом управляются экстенты табличного пространства:
• DICTIONARY - управление экстентами происходит по таблицам словаря базы данных;
• LOCAL - управление экстентами производится с использованием битовой карты, отображающей состояние свободной/занятой памяти данного табличного пространства;
• AUTOALLOCATE - управление экстентами производится самой системой, и пользователи не могут указывать размеры экстентов;
• UNIFORM [size nn {K|M|G}] - задает одинаковый размер экстентов в табличном пространстве.
• SEGMENT_SPACE_MANAGEMENT - отслеживание использованной и свободной памяти в табличном пространстве при помощи:
• MANUAL - списков свободных блоков данного табличного пространства;
• AUTO - битовых карт занятых/свободных блоков памяти данного табличного пространства;
• параметры INITIAL_EXTENT, NEXT_EXTENT, PCT_INCREASE и др. сохранили свои определения, но они игнорируются при установке параметров LOCAL AUTO.

Возникновение фрагментации

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

Внутриблочная фрагментация в табличных экстентах возникает, когда из таблиц исключаются записи данных и тем самым увеличивается область свободной памяти. Табличный блок открывается на вставку новых записей, когда уровень занятой памяти блока становится ниже значения параметра PCT_USED (по умолчанию 40%). Тем самым, в таблице может быть свыше 50% свободной памяти, но для вставки новых записей будут использоваться все новые и новые блоки. Это же относится и к сегментам TABLE PARTITION, CLUSTER, NESTED TABLE.

Внутриблочная фрагментация в индексных экстентах возникает, когда из таблиц исключаются записи данных и, тем самым, исключаются записи индексов из индексных блоков. При активной обработке таблицы (вставка, удаление, модификация данных) ее индексы очень активно набирают свой объем. Особенно это проявляется при использовании двоичных (bit map) индексов. (Пример реорганизации двоичного индекса см. ниже.) Это же относится и к сегменту типа INDEX PARTITION. При наличии у таблиц нескольких [иногда десятков!] индексов расходование, управление и распределение памяти может превратиться серьезную проблему.

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

Экстентная фрагментация возникает:

• если табличное пространство, управляемое словарем данных, содержит экстенты различных размеров, и свободные участки между занятыми экстентами не достаточно велики, чтобы вместить новые экстенты, запрашиваемые базой данных. В результате, суммарный объем свободной памяти в табличном пространстве может быть велик, но не может быть выделен ни один новый экстент при расширении какой-либо таблицы и/или индекса. В этом случае АБД должен или добавить к табличному пространству новый файл, или воспользоваться опцией авторасширения, или все-таки предпринять меры по реорганизации этого табличного пространства;
• если табличное пространство управляется локально, то оно может быть:
• EXTENT_MANAGEMENT LOCAL [подразумевается AUTO] - и все ответственность за фрагментацию ложится на СУБД и, который размещает в таком табличном пространстве какие-то сегменты по своему выбору и разумению. Фрагментация сегмента нарастает следующим образом:
  • до 16 экстентов по 8 блоков,
  • до 128 экстентов по 64 блока,
  • все последующие экстенты имеют размер 1024 блока.
• EXTENT_MANAGEMENT LOCAL UNIFORM [size nn {K|M|G}] - все экстенты равны по размерам, и задача АБД состоит в правильном выборе размера экстента для этого табличного пространства. Ниже будет приведен пример неправильного определения размещения, когда таблицы и индексы занимают сотни тысяч (!!!) экстентов в табличном пространстве.

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

Некоторые примеры необходимости проведения расчистки памяти табличных пространств

1) Пример плохой организации памяти в табличном пространстве, управляемом словарем

select rpad(segment_name,25),rpad(segment_type,12), count(*),sum(blocks) from dba_extents where tablespace_name='EXAMPLE' group by rpad(segment_name,25),rpad(segment_type,12)

order by sum(blocks) desc;

(Фрагмент ответа)

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

Время перестроения:
Таблица GEKTOR 03:10:19 (час.мин.сек)
Индекс первичного ключа SYS_C0035790 05:39:46 (час.мин.сек)
Обычный (B*tree) индекс I$GEKTOR$AB 05:44:23 (час.мин.сек)

Результат:

• реорганизация таблицы и ее индексов уменьшила занимаемую память более чем на 30%. Размер экстентов для таблицы GEKTOR и индекса I$GEKTOR$AB поменялся с 100КВ на 5МВ. Для индекса SYS_C0035790 остался неизменным. Поэтому в этом индексе не столь существенно уменьшилось число экстентов.

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

АБД должен увидеть, когда собственно таблица переместилась и запустить одновременно индексы на перестроение. Обращаем внимание, что при перестроении (особенно параллельном) индексов сильно повышаются требования к доступному объему временной памяти. Рекомендуется добавить один/несколько файлов к табличному пространству TEMP.

2) Пример фрагментации локально управляемого unisize табличного пространства

Количество блоков - 24737750, емкость ~ ~ 93.5 GB.
Количество распределенных файлов - 24.
Размер файлов данных - от 500 МВ до 6 GB.
Опция авторасширения (autoextend) не установлена.
Экстентная фрагментация очень высокая. Выборка результатов до и после дефрагментации с переносом в другие табличные пространства приведена в таблице.

Результат: табличное пространство должно быть реорганизовано, так как иначе изменить размер экстента нельзя. Даже несмотря на управление памятью по битовой карте табличного пространства, наличие экстентной фрагментации существенно "грязнит" функционирование базы данных. При переносе в табличное пространство с размером экстента 5МВ резко изменились характеристики хранения индексов, что следовало ожидать как результат их перестроения. Перестроение таблиц резко уменьшило число занимаемых экстентов, но общая занимаемая память несколько увеличилась. Это, вероятно, произошло по нескольким причинам, в том числе, что между измерениями прошло значительное время, в течение которого таблицы интенсивно пополнялись данными. Требуется анализ на наличие пустых и/или не достаточно наполненых блоков. Резкое снижение экстентной фрагментизации снижает нагрузку на ввод/вывод в операциях сканировая таблиц и индексов.

3) Пример эффекта при реорганизации двоичного (bitmap) индекса

select /*+ INDEX (EXAMPLE I) */ INFO_T,count(*) from EXAMPLE
group by INFO_T ;
Имя_индекса время выполнения запроса
---------------------------- ----------- ------------------
I 00:28:11.97 -- до реорганизации индекса
I 00:00:01.99 -- после реорганизации индекса
Имя_индекса к-во блоков к-во экстентов
---------------------------- ----------- ------------------
I 1136640 222 -- до реорганизации индекса
I 5120 4 -- после реорганизации индекса

Результат: реорганизация двоичного индекса уменьшила занимаемую память более чем в 200 раз, а время выполнения одного и того же запроса уменьшилось примерно в 80,000 раз. Время реорганизации самого индекса составило примерно 2-3 минуты.

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

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

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

Дефрагментация индексных сегментов и секций индексных сегментов

1) Перенос и дефрагментация индексных сегментов и секций индексных сегментов

alter index owner.index_name rebuild tabltespace new_index_local;
alter index owner.index_name rebuild { partition |subpartition} { partition_name |subpartition_name} tabltespace new_index_partition_local;

Примечание: чтобы не прерывать обработку данных, в эти команды следует добавить опцию online.

2) Перенос и дефрагментация двоичных индексов и секций двоичных индексов

alter bitmap index owner.index_name rebuild tabltespace new_index_local;
alter bitmap index owner.index_name rebuild { partition |subpartition} { partition_name |subpartition_name} tabltespace new_index_partition_local;

Примечание: двоичные индексы в режиме online не перестаиваются.

Дефрагментация таблиц и секций табличных сегментов

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

alter table owner.table_name move tabltespace new_table_local;
alter table owner.table_name move { partition |subpartition} { partition_name |subpartition_name} tabltespace new_table_partition_local;

Примечание 1: при переносе таблицы доступ к ней для изменений блокируется, все ее индексы приобретают статус UNUSABLE. Поэтому рекомендуется:

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

select ' alter index '||owner||'.'||index_name||' rebuild tabltespace new_index_local;'

from dba_indexes where dba_indexes. table_name = 'table_name';

Примечание_2: Следует еще раз напомнить, что транзакция по переносу таблицы (и любого сегмента) заканчивается только после того, как Oracle освободил все ранее принадлежащие сегменту экстенты. Поэтому если таблица или индекс занимает (в табличном пространстве, управляемым словарем) несколько десятков (сотен!!!) тысяч экстентов, то операция переноса и/или реорганизации может продолжаться несколько часов и даже суток.

Перенос вложенных таблиц и таблиц со столбцами типов LONG/LONG_RAW, rowid

1) Перенос вложенной таблицы производится командой:

alter table owner.table_name move NESTED TABLE tabltespace new_nested_table_local;

2) Перенос таблиц со столбцами типов LONG/LONG_RAW осуществляется только методом экспорт/импорт. Последовательность действий: экспорт таблицы, удаление (или переименование ее и ее индексов), создание структуры таблицы в требуемом табличном пространстве, импорт данных без создания индексов и ограничений (constraints), пересоздание индексов и включение ограничений.

Перенос таблицы со столбцами типа rowid

Если таблица содержит столбец(ы) с идентификаторами строк (rowid), то они, как правило, являются идентификаторами строк какой-то другой таблицы и, следовательно, при переносе остаются актуальными. Обновление содержания столбцов rowid должно производиться после переноса той таблицы, к которой они ранее относились.

Перенос индекс-организованной таблицы и ее табличного экстента:

1. выявление индекс-организованных таблиц

   select owner, table_name,iot_name from dba_tables where IOT_NAME is not null;

2. перенос индексной части таблицы по полученному значению table_name

   alter table owner.table_name MOVE tabltespace new_table_local;

3. перенос табличной части индекс-организованной таблицы

alter table owner.table_name MOVE OVERFLOW tabltespace table_owerfflow;

Перенос кластеров

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

Перенос LOB-сегментов

Перенос LOB-сегмента (вместе с LOB-индексом), находящегося вне таблицы, осуществляется отдельно от его таблицы по следующей команде:

alter table owner.table_name move lob (column_name) store as (tablespace lob_segments) ;

Пример для формирования набора предложений по переносу всех LOB-сегментов, кроме принадлежащих системным учетным записям:

select 'alter table '||owner||'.'||table_name||' move lob ('||COLUMN_NAME||') store as (tablespace lob_segments) ; ' from dba_lobs where owner not like 'SYS%';

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

Устранение вытесненных записей может быть осуществлено только при помощи экспорта/импорта таблицы или пересоздания таблицы командой CTAS:

create table table_new [tablespace ... ] as select * from table_old ;

с последующим переименованием, пересозданием индексов и ограничений и т.п.

Некоторые рекомендации по улучшению структуры памяти базы данных

1. Обязательный перевод всех табличных пространств в локальное управление (EXTENT MANAGEMENT LOCAL), опустошение (перенос сегментов) и удаление табличных пространств, управляемых при помощи словаря (за исключением только табличного пространства SYSTEM, если оно изначально было управляемо при помощи словаря).
2. Переход от концепции "табличного пространства по умолчанию" (default tablespace), которое обязательно определяется для каждого пользователя, к концепции "перераспределение сегментов по табличным пространствам с соответствующими размерами экстентов". Этот переход следует возложит на АБД, который отслеживая увеличение объема памяти, потребляемого сегментами, реорганизует их или переносит сегменты различных пользователей в табличные пространства с соответствующими характеристиками.
3. Внедрение новых информационных объектов, особенно сегментов, проводить только через АБД или с уведомлением и разрешением, ограничивая в этом права пользователей схем.
4. Рекомендуется в базе данных Oracle10g иметь:

• одно (несколько) табличных пространств EXTENT MANAGEMENT LOCAL AUTO с малым размером экстента (16-128К) и разместить в них таблицы и индексы всех пользователей с малым числом записей;
• одно табличное пространство EXTENT MANAGEMENT LOCAL AUTO для всех сегментов типов LOBSEGMENT и LOBINDEX, принадлежащих несистемным пользователям (системные пользователи, как правило, держат такие сегменты в SYSTEM или особых специализированных табличных пространствах);
• одно (несколько) табличных пространств EXTENT MANAGEMENT UNISIZE {1|5M}, то есть со средним размером экстента (1,0 - 5,0М), и разместить в них таблицы и индексы всех пользователей с относительно средним числом записей;
• одно (несколько) табличных пространств EXTENT MANAGEMENT UNISIZE {25|50M}, то есть с большим размером экстента (25 - 50М), и разместить в них таблицы и индексы всех пользователей с большим числом записей;
• для сегментов типа TABLE PARTITION и INDEX PARTITION создавать отдельные табличные пространства, исходя из особых требований приложений, которые их применяют.

1. Миграцию сегментов с одного уровня табличных пространств на другой уровень производить не ранее, чем число экстентов в сегменте достигнет 1000 - 4000 единиц;
2. По-прежнему рекомендуется разделять по разным табличным пространствам табличные и индексные сегменты. При этом таблицы и их индексы могут лежать в табличных пространствах с разными размерами экстентов.
3. Рекомендуется регулярно проводить анализ всех сегментов и следить за уровнем структур индексов, особенно двоичных. При достижении 3-4 уровня высоты дерева индекса необходимо провести его реорганизацию.
4. Рекомендуется существенно увеличить размер области оперативной памяти, выделяемой для операций сортировки (параметре sort_area_size) до 100 - 500 -100 Мегабайтов (если позволяет память машины), а также задать значение параметра sort_area_retained_size в половину значения sort_area_size. Это позволяет проводить многие внутренние операции по обработке и сортировке данных в оперативной памяти без промежуточного сбрасывания на диск.

   Примечание: в базе данных Oracle9i введен новый параметр инициализации запуска экземпляра - pga_aggregate_target. Если этот параметр установлен (до 400Мегабайтов) и используются выделенные (dedicated) соединения, Oracle9i и следующие релизы будут игнорировать все параметры PGA, включая sort_area_size и sort_area_retained_size. Корпорация Oracle рекомендует устанавливать значение параметра pga_aggregate_target, равное объему памяти, оставшейся свободной в сервере UNIX после запуска экземпляра (минус 20% на другие задачи ОС UNIX). Еще раз подчеркнем, что при установлении разделяемых (shared) соединений приложений с базой данных по-прежнему действуют параметры sort_area_size, sort_area_retained_size и др., а pga_aggregate_target игнорируется

5. Настоятельно рекомендуется при выполнении рекомендации п.8 увеличить размер экстента временной памяти табличного пространства TEMP до 15-20 Мегабайтов, иначе выполнение этой рекомендации приведет к отрицательным результатам.
6. Если перенос базы данных Oracle8i под управление Oracle10g был произведен методом прямой миграции, то сразу же необходимо создать табличное пространство UNDOTBS1 по примеру тестовой базы данных, возможно, с увеличением размера undo-экстентов.

Использованные источники:

1. Кевин Луни "Oracle Database 10g. Полный справочник" (в двух томах). М:., “Лори”, 720+732 стр., 2006.
2. Гринвальд Р., Крейнс Д. "Oracle. Справочник". М:., "Символ-Плюс", 976 стр., 2005.
3. Bhaskar Himatsingka, & Juan Loaiza (Oracle Corporation) "HOW TO STOP DEFRAGMENTING AND START LIVING: THE DEFINITIVE WORD ON FRAGMENTATION" www.oracle.com/technology/deploy/availability/pdf/defrag.pdf
4. Дональд K. Бурлесон (BEI Oracle Consulting) "Использование средств автоматической настройки баз данных Oracle9i" (доклад на Oracle OpenWorld, San Francisco, December 2001)
   http://www.oracle.com/pls/oow/oow_user.show_public?p_event=6&p_type=session&p_id=8851
   русский перевод: "Oracle Magazin/Русское Издание", выпуск за октябрь 2002г.