Локально управляемые табличные пространства

Источник: ln

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

Прошлое и настоящее табличных пространств

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

Этот обзор табличного пространства сразу выявляет две проблемы управления пространством. Первая - какие экстенты принадлежат данному сегменту; а вторая - какие экстенты используются, а какие - свободны. Методы решения первой проблемы не особенно изменились в последние годы, а вот для более эффективного решения второй проблемы корпорация Oracle предложила локально управляемые табличные пространства (locally managed tablespaces - LMTs) .

Прошлое

Исторически, управление свободным местом в табличном пространстве реализовывалось с помощью двух таблиц: uet$ (used extent table - таблица использованных экстентов) и fet$ (free extent table - таблица свободных экстентов).

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

Аналогично, при освобождении экстента (скажем, при удалении таблицы) сервер Oracle удалит строку из таблицы uet$ и вставит или изменит строку в таблице fet$.

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

Итак, все действия по управлению пространством для всех табличных пространств базы данных сконцентрированы на двух критических таблицах в словаре данных (отсюда и название - табличные пространства, управляемые по словарю , dictionary managed tablespaces - DMT). Если АБД не знает точно, что происходит, и не контролирует систему, это может привести к проблемам. У этих потенциальных проблем было три основных причины.

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

Во-вторых, корпорация Oracle, по сути, вынудила АБД интенсивно генерировать задачи управления пространством, добавив различные параметры хранения для сегментов (такие как initial, next, pctincrease), обещающие высокую степень точности при задании требований к пространству, но со стандартными значениями, которые гарантируют неэффективное управление пространством.

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

Настоящее

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

Рис. 1. Чистое (вверху) и частично использованное (внизу) локально управляемое табличное пространство.

Можно задать размер файла и размер чанков для данного файла. Например, рассмотрим сценарий:


create tablespace demo_01
datafile 'c:\oracle\oradata\D9202\demo_01.dbf'
size 102464k
extent management local
uniform size 1024K;

Он создает табличное пространство с одним файлом (весьма странного на вид размера), который разделен ровно на 100 чанков размером 1024 Кбайта, но с добавлением дополнительных 64 Кбайт для битовой карты файла. Если обратиться к представлению dba_free_space с запросом о свободном месте в этом табличном пространстве, мы получим ровно 104857600 байтов. Если попытаться выделить экстент, окажется, что экстент по размеру будет соответствовать ровно одному чанку - при задании uniform size один чанк соответствует одному экстенту.

Типичная проблема с локально управляемыми табличными пространствами состоит в том, что АБД задают размер файла без учета места под битовую карту; как следствие, они "теряют" почти весь экстент в конце файла, поскольку в файле не хватает 64 Кбайта для выделения последнего экстента. Если вы столкнетесь с этой проблемой, надо только увеличить размер файла файла на недостающие 64 Кбайта, и вы можете к своему удивлению обнаружить дополнительный экстент в представлении dba_free_space.

Примечание: для локально управляемых табличных пространств можно применять опцию autoallocate вместо uniform size X. В результате файл все равно делится на чанки одинакового размера (в данном случае, всегда размером 64 Кбайта), и в битовой карте используется один бит на чанк. Однако вместо сопоставления экстента одному чанку, сервер Oracle будет учитывать прежние действия и имеющиеся свободные места при выборе размера выделяемого экстента. При этом выделяется экстент одного из стандартных размеров - 64 Кбайта, 1 Мбайт, 8 Мбайт, 64 Мбайта или 256 Мбайт. Для сравнительно небольших, простых систем, в которых для определения требований к пространству недостаточно информации, это может оказаться самым простым и приемлемым механизмом; но, в общем случае, следует использовать экстенты одинакового размера.

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

Конечно, серверу Oracle по-прежнему приходится поддерживать таблицу seg$ и блок блок заголвка сегмента, а также может потребоваться изменить таблицу tsq$, но самая сложная часть операции выделения пространства выполняется намного эффективнее. Более того, вместо использования одной очереди пространственных транзакций (ST) для всей базы данных, сервер Oracle использует новый тип очереди - очередь TT - и использует по одной очереди TT для каждого табличного пространства, чтобы сократить количество конфликтов при одновременном выделении пространства в нескольких сеансах.

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

И в чем же преимущества?

Новые возможности могут давать преимущества в трех областях: (а) стратегические перспективы, (б) производительность и (в) упрощение администрирования. Я рассмотрю каждое из потенциальных преимуществ по очереди.

С учетом перспективы, необходимо переводить все системы на использование локально управляемых табличных пространств. В Oracle 9.2 мастер создания баз данных (Database Creation Assistant) по умолчанию создает базу данных с локально управляемым табличным пространством system. Если табличное пространство system является локально управляемым, вы не сможете создавать в базе данных табличные пространства, управляемые по словарю. Ясно, что корпорация Oracle предполагает всеобщий переход на локально управляемые табличные пространства в ближайшем будущем - весьма вероятно, что в Oracle 10 пространства, управляемые по словарю, вообще не будут поддерживаться, так что будет мудро завершить переход до того, как выйдет следующая версия сервера Oracle. Кстати, даже если табличное пространство system является локально управляемым, все равно можно будет использовать механизм переносимых табличных пространств (transportable tablespace mechanism) для подключения к базе данных табличного пространства, управляемого по словарю, но это табличное пространство будет доступно только для чтения.

Что же касается производительности, то она при использовании локально управляемых табличных пространств не является существенным преимуществом. Хотя 'потрясающее' повышение производительности за счет использования битовых карт считается общеизвестной причиной перехода с табличных пространств, управляемых по словарю, на локально управляемые, достаточно лишь пару минут подумать о том, когда, где и как вы можете получить это преимущество, чтобы понять, что оно практически не имеет значения. Спросите себя: "Как часто придется выделять и вскоре освобождать пространство?". Правильный ответ - крайне редко. Рассмотрим наиболее типичные случаи, когда это происходит:

Вы выделили постоянное табличное пространство вместо временного любого вида для использования в качестве temporary_tablespace для пользователя (эта возможность в версии 9 заблокирована - выдается сообщение об ошибке ORA-12911: permanent tablespace cannot be temporary tablespace). Как следствие, вся сортировка, хеширование, выделение временных больших объектов и временных таблиц выполняется в постоянных сегментах данных, а не с помощью пула экстентов сортировки (sort extent pool). Это может привести к снижению производительности, которое можно слегка компенсировать с помощью локально управляемых табличных пространств, но это не проблема выбора локально управляемого табличного пространства или табличного пространства, управляемого по словарю. Проблема в том, использовать ли постоянное или временное табличное пространство. Может оказаться, что вы выделили пользователю в качестве temporary_tablespace временное пространство, но при этом указали очень маленький размер экстента и некоторые операции сортировки требуют десятки и сотни тысяч экстентов. При следующем перезапуске сервера, процесс smon годами будет работать, загружая процессор на 100% и, по сути, блокируя большинство действий в базе данных. Это может являться причиной снижения производительности, которое можно существенно уменьшить при использовании локально управляемых табличных пространств, но проблема тут не в производительности, а в ошибке администратора. Кроме того, во временном табличном пространстве пользователя размещаются временные большие объекты, временные таблицы, данные при сортировке и хешировании, и эти варианты использования могут оказаться несовместимыми по требованиям к временному пространству. Если начинать решать эту проблему, использование в качестве временных локально управляемых табличных пространств действительно необходимо.
Вы создали несколько важных, больших по объему таблиц данных с небольшими размерами первого и последующих экстентов и значением pctincrease, равным единице (следуя хорошо известным и часто цитируемым, хотя и абсолютно неверным наставлениям). Как следствие, у вас будет много объектов, постоянно запрашивающих экстенты небольшого размера, которые тут же заполняются. Более того, каждый запрос требует выделить экстент нечетного размера и поэтому обычно требует для принятия решения о том, как его выделять, практически максимальной работы от сервера Oracle. Это может привести к снижению производительности, которое можно существенно уменьшить при использовании локально управляемых табличных пространств, но проблема тут снова не в производительности, а в ошибке администратора.
Ваше приложение часто создает и удаляет таблицы на ходу для хранения промежуточных результатов. Это создает интенсивную нагрузку на систему управления пространством. Такие действия, скорее всего, приведут к снижения производительности, но связано оно с ошибкой проектирования, а не с принципиальным недостатком системы управления пространством. Но для приложений сторонних производителей, в которых ошибку проектирования исправить нельзя, небольшое обычно повышение производительности при переходе на локально управляемые табличные пространства становится необходимым и важным средством уменьшения вреда (хотя, и краткосрочным).

Всех представленных выше "проблем производительности" можно избежать или свести их влияние к минимуму и без перехода на использование локально управляемых табличных пространств, и многие АБД годами выполняли необходимые шаги, позволяющие их избежать. Есть хорошо известная статья на эту тему, доступная через Metalink или OTN ("How to Stop Defragmenting and Start Living" - "Как перестать дефрагментировать и начать жить"), но вкратце рекомендации следующие:

Не задавайте конструкции хранения для объектов; всегда используйте стандартные значения табличного пространства.
Установите pctincrease = 0 в качестве стандартного значения для табличного пространства.
Установите стандартное значение initial = next для табличного пространства.
Установите минимальный размер экстента для табличного пространства равным initial/next.
Помещаейте объекты в табличные пространства, подходящие для них с учетом предполагаемых размеров объектов.
Не экспортируйте с указанием compress = y если планируете пересоздавать таблицы с помощью импорта.
Оцените, сколько временного пространства понадобится, объявите и выделите (несколько) временных табличных пространств в соответствии с этими оценками
Старайтесь не использовать постоянные таблицы для размещения промежуточных данных - попробуйте использовать глобальные временные таблицы.

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

Если проанализировать представленный выше список, оказывается, что шаги 2, 3 и 4 автоматически и безусловно выполняются при создании табличного пространства как локально управляемого с экстентами одного размера - размеры всех экстентов окажутся одинаковыми. Кроме того, шаги 1 и 6 становятся практически ненужными: даже при несоответствии параметров в конструкциях хранения при создании или импортировании объектов, сервер Oracle учитывает суть запроса, игнорируя детали и выделяя экстенты в соответствии с определением табличного пространства. Как следствие, большая часть стратегических решений, за реализацию которых хорошие АБД боролись годами, являются стандартными при использовании локально управляемых табличных пространств. Ключевое слово тут - "боролись". Несмотря на все усилия администраторов баз данных, при использовании табличных пространств, управляемых по словарю, проблемы могли возникать, а вот в локально управляемых табличных пространствах с экстентами одинакового размера ни один пользователь не сможет изменить заданный размер экстента.

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

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


Rem
Rem Найти размер экстента для каждого локально управляемого табличного пространства
Rem Определить, сколько объектов в каждом табличном пространстве
Rem Определить объем свободного места в каждом табличном пространстве
Rem

select tablespace_name, initial_extent 
from user_tablespaces
where extent_management = 'LOCAL'
and allocation_type = 'UNIFORM' 
-- можно также включить 'SYSTEM' 
;

select tablespace_name, count(*) 
from dba_segments 
group by tablespace_name
;

select tablespace_name, sum(bytes)
from dba_free_space
group by tablespace_name
;

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

Аналогично, можно начать с простого запроса вида:


select 
     tablespace_name, segment_name, partition_name, extents
from dba_segments

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

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

Принципы, изложенные в статье по дефрагментации, имеет смысл применять и для локально управляемых табилчных пространств. Проклассифицируйте объекты по приложениям, стилю использования и, наконец, по размеру. Обычно удается выбрать три-четыре типичных размера объектов - скажем, "маленький", "средний", "большой" и "огромный" - создайте табличное пространство, соответствующее каждому из этих размеров. (Я предпочитаю работать с размерами, кратными 8 или 16, так что для четырех "типоразмеров" я бы мог создать табличные пространства с одинаковыми экстентами размером 64 Кбайта, 512 Кбайт, 4 Мбайта и 16 Мбайт). Затем вы привязываете объекты к табличным пространствам исходя из предположения, что сравнительно статичные объекты должны содержать, скажем, от 1 до 16 экстентов, а для постоянно растущих может добавляться по одному экстенту раз в пару месяцев. В итоге применения этой стратегии база данных получается адекватного размера, и при росте объемов данных никаких сюрпризов не будет.

Конечно, возможны ошибки, и первоначальные оценки могут привести к размещению объекта не в том табличном пространстве. Перенести объекты из одного табличного пространства в другое достаточно просто, и при этом не будет никаких проблем с размещением объектов. Если для объекта достаточно свободного места в табличном пространстве, в этом месте его можно будет поместить. Вспомните те ужасные времена, когда при наличии 100 Мбайт свободного места в табличном пространстве вы не могли импортировать в него таблицу размером 51 Мбайт просто потому, что эти 100 Мбайт состояли из двух не идущих подряд кусков по 50 Мбайт каждый? Этого не бывает в локально управляемых табличных пространствах. Все дырки - одного размера, и каждый объект автоматически создается как набор кусков, размер которых в точности соответствует этим дыркам. При переносе таблицы размером 24 Мбайта из "64 Мбайтного" табличного пространства в "1 Мбайтное", ей не понадобится экстент размером 64 Мбайта (она его и не сможет получить); она автоматически разместится в 24 экстентах по 1 Мбайту.

Для пользователей хранилищ данных удобство и надежность использования пространства также упрощает разработку стратегии переноса и упаковки данных перед переводом их в режим только чтения. (А Oracle 9.2 предлагает многообещающую возможность хранения данных в таблице только для чтения со сжатием.) Непосредственно перед переводом набора данных (например, фрагментов, - " секций " - за последний месяц) в режим только для чтения можно перенести и сжать данные, перестроить индексы и усечь соответствующие файлы до минимально возможного размера. И это можно сделать настолько удобно и наждежно, как никогда ранее при использовании табличных пространств, управляемых по словарю.

Фактически, может иметь смысл перенести объекты в табличные пространства "не того" одинакового размера просто потому, что количество экстентов при этом становится оптимальным по отношению к используемым устройствам, файлам и особенностям распараллеливания. Переход на локально управляемые табличные пространства открывает очень интересные возможности стратегического управления пространством (proactive space management) и повышения производительности за счет эффективного управления пространством.

Заключение

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

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

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

Ссылки по теме