В прошлом шаге я говорил о команде сцепления свободных экстентов. В следствии того, что табличное пространство это наиболее изменяемый объект БД, от состояния которого в первую очередь зависит скорость работы ваших запросов и получения данных из БД. Все конечно относительно. Кто-то требует высокой скорости получения данных, а для кого-то подождать минуту другую, совсем не страшно. Вот здесь и вытекает момент грамотности построения экземпляра БД. Как бы вы не старались, но ваши таблицы, процедуры и т.д. меняются с течением времени и табличное пространство неизбежно все более и более дефрагментируется. Итак, как же все-таки с этим бороться. Самое простое это использовать коэффициент FSFI и, если в результате анализа карты свободных экстентов, станет ясно, что их слияние полезно для выбранного табличного пространства их можно слить либо вручную, либо используя рабочую лошадку, фоновый процесс SMON. Чтобы заставить его это проделать, параметру pctincrease необходимо присвоить значение не равное нулю. Например, это можно сделать так:
ALTER TABLESPACE MYTABLESPACE DEFAULT STORAGE (pctincrease 1) /
При этом, если в табличном пространстве MYTABLESPACE создается объект без указания значения параметра pctincrease, то будет использовано его значение по умолчанию. В большинстве случаев небольшие значения этого параметра сравнительно точно соответствуют обычному линейному росту числа строк в вашей БД. По этому было использовано самое маленькое не нулевое значение этого параметра - 1. Замечу, что с помощью конструкции storage создаваемого объекта это значение можно переписать. Теперь давайте попробуем проделать объединение свободных экстентов вручную. Сделать это можно применив параметр COALESCE команды ALTER TABLESPACE. Вот таким образом:
ALTER TABLESPACE MYTABLESPACE COALESCE /
Например, я проделал это с моим табличным пространством USER, и вот что получилось:
ALTER TABLESPACE USERS COALESCE /
Получил:
SQL> ALTER TABLESPACE USERS COALESCE 2 / Раздел изменен.
Как это не смешно весь процесс у меня занял 0.218 секунды. Может быть, у вас будет и больше не знаю, но можете попробовать. Хотя библия Администратора БД Oracle утверждает, что в результате этой операции будут объединены свободные соседствующие экстенты. А вот, между которыми стоят барьеры, скорее всего нет! Так, что это не панацея! :) Лично, я чаще поступаю так, сливаю все содержимое БД в файл экспорта (эту большую тему мы будем рассматривать далее!). Затем полностью сношу мое табличное рабочее табличное пространство и создаю его заново. Получаю естественно чистый лист! Затем заливаю импортом все мои объекты одним экстентом и вуоля! Мои таблички начинают откликаться на запросы просто молниеносно! Это самый радикальный способ, хотя не всегда применимый. Есть еще Enterprise Manager - но это очень объемная тема и мы ее выделим отдельно. Скажу только что, Enterprise Manager может дефрагментировать любое табличное пространство на подобие программы Norton Utilites, Speed Disk - помните! Это тоже полезная функция для БД.
Так же существует такое понятие, как "сцепление строк". Как правило сцепление снижает производительность запроса, поскольку ORACLE вынужден искать одну логическую строку в нескольких физических местах. Для того, чтобы избежать этого явления необходимо следить за параметром pctfree при создании сегмента данных и устанавливать правильное значение этого параметра. Для оценки сцепления строк есть команда analyze, которая собирает некую статистику о использовании различных объектов БД. Команда analyze позволяет так же находить и записывать сцепленные строки таблиц. Например, вот так:
ANALYZE TABLE MYTABLE LIST CHAINED ROWS INTO CHAINED_ROWS /
Таблица CHAINED_ROWS создается отдельно при работе с данной командой и принимает значения анализа. Помимо сцепления строк ORACLE время от времени перемещает их. Если строка превышает доступное в блоке место она может быть включена в другой блок. Процесс перемещения строки из одного блока в другой называется "миграцией" строк. А сама строка называется "мигрирующей". В ходе самого процесса ORACLE динамически управляет местом в нескольких блоках, а так же обращается к свободному списку (free list - список блоков доступных для вставок). По своей сути мигрирующая строка не является сцепленной, но влияет на производительность транзакции в целом! Вот, такой достаточно не простой механизм использует БД при размещении объектов в табличных пространствах. А задача DBA следить за этим и корректно использовать возможности системы для повышения ее производительности. Что, я собственно и хочу до вас довести. Применяя данные инструменты можно значительно повысить скорость работы вашей БД, но все естественно зависит от вас! Дерзайте!