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

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

• Производительность операций ввода/вывода — каждое табличное пространство должно включать сегменты, имеющие схожие характеристики ввода/вывода (уровень параллелизма, объем) — такое разбиение упростит выбор размера сегмента чередования и емкости дискового массива. Объединение сегментов, используемых только для чтения, в табличное пространство только для чтения, снижает объем передаваемых данных при резервном копировании и восстановлении, а также снижает издержки на PCMблокировки. Разделение сегментов, в которые часто осуществляется запись, от сегментов с низкой интенсивностью записи придает больше гибкости при конструировании процедуры «горячего» резервного копирования.
• Устойчивость к отказам — малые табличные пространства позволяют минимизировать простой приложения во время работ, требующих перевода этих табличных пространств в автономный режим (offline). Табличное пространство system не может быть переведено в автономный режим, также как не может быть удалено и пересоздано, поэтому храните минимально необходимое число сегментов в этом табличном пространстве. Изоляция сегментов отката в минимально необходимом числе табличных пространств снижает частоту возникновения простоев, поскольку табличное пространство с активным (online) сегментом отката невозможно перевести в автономный режим. Хранение связанных, с помощью ссылочной целостности, сегментов в небольшой группе табличных пространств даст Вам возможность использовать процедуру восстановления на заданный момент времени («point-in-time), введенную в Oracle8.
• Управление пространством — изоляция сегментов с коротким временным жизненным циклом минимизирует влияние фрагментации свободного табличного пространства, которая может блокировать выделение новых экстентов сервером Oracle. Администраторам VLDB принесет пользу возможность использования умалчиваемых параметров хранения, определенных на уровне табличного пространства, вместо явного указания этих параметров в описании сегментов.
• Управление квотами — управление квотами пространства в сервере Oracle выполняется на уровне пользователей и табличных пространств. Поэтому размещайте сегменты одной схемы в небольшом числе табличных пространств.

5.1 Назначение сегментов табличным пространствам

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

1. В табличном пространстве system храните только сегменты словаря данных (сегменты, принадлежащие схеме sys). Перенесите таблицу aud$ в табличное пространство отличное от system, это позволит Вам управлять размером таблицы (усекать ее) не влияя на фрагментацию свободного пространства в табличном пространстве system. Некоторые эксперты рекомендуют отредактировать файл sql.bsq (только строки расположенные ниже вхождения //) с тем, чтобы изменить параметры хранения таблиц словаря данных, связанных с хранимыми процедурами и триггерами. Для полной уверенности, делайте это совместно со службой поддержки Oracle.
2. Создайте два или более табличных пространства, предназначенных исключительно для временных сегментов. Создайте программу, которая позволит быстро переключать на доступное временное табличное пространство, отличное от system, в случае недоступности стандартного временного табличного пространства [10, To (1995), 6.12].
3. Создайте одно или более табличных пространств, предназначенных исключительно для сегментов отката. Не помещайте сегменты отката в табличные пространства отличные от тех, что были специально для этого спроектированы.
4. Изолируйте короткоживущие сегменты, используя минимально возможное количество табличных пространств. Не помещайте короткоживущие прикладные таблицы и индексы в табличные пространства, отличные от тех, что были специально разработаны для короткоживущих сегментов.
5. По возможности изолируйте сегменты только для чтения (read only) в табличных пространствах, которые содержат исключительно такие сегменты. Переведите эти табличные пространства в режим «только для чтения».
6. Проведите классификацию оставшихся сегментов по их размерам. В каждом табличном пространстве храните сегменты с похожими размерами.
7. Ограничьте максимальный размер табличного пространства в пределах 10GB. Перевод небольшого табличного пространства в автономный режим (off-line) потенциально влечет лишь ограниченную недоступность базы данных. Недоступность большого табличного пространства, из-за потери файла данных, с большей вероятностью приведет к недоступности всей базы данных. Использование малых табличных пространств позволит получить преимущества от распараллеливания процедуры восстановления на заданный момент времени в Oracle8.
8. Если Вы используете чередование с малым размером сегмента, то нет необходимости разделять индексы и таблицы для распределения нагрузки на диски. Однако, если Ваш режим эксплуатации требует регулярной перестройки индексов, то Вам имеет смысл рассмотреть возможность поместить индексы в отдельное табличное пространство для минимизации возможного влияния возникающей фрагментации свободного пространства из-за применения оператора drop index.

6 Параметры хранения

Параметры хранения были долгое время горячей темой для обсуждения, поскольку многие администраторы Oracle верили, что важно пытаться разместить каждый сегмент в базе данных в не более чем одном экстенте. Многие люди были обучены тому, что наличие большого числа экстентов негативно влияет на производительность всех DML-операторов Oracle. Время, потраченное на «сжатие» таблиц и индексов в один экстент — это время, которое можно было бы потратить на что-то более стоящее ¹⁵.

6.1 Maxextents

Действительная причина того, что администраторы БД Oracle должны обращать внимание на параметры хранения, заключается в том, что в Oracle до версии 7.3 максимальное значение параметра maxextents ограничено и зависит от значения параметра db_block_buffers. Опасность того, что приложение может быть прервано из-за ошибки «max # extents reached» заставляла администраторов помещать сегменты в ограниченное количество сегментов. С возможностью maxextents unlimited, появившейся в версии Oracle 7.3, эта опасность исчезла.

Забавно, но для VLDB, параметры хранения являются важными по прямо противоположным соображениям. Для VLDB существуют несколько случаев, когда желательно, чтобы сегмент хранился в более чем одном экстенте.

• Наличие множества экстентов позволяет эффективнее использовать свободное пространство с помощью команды truncate . . . drop storage.
• Вам желательно, чтобы сегменты отката имели несколько экстентов для снижения загрузки системы из-за динамического выделения и освобождения экстентов [5, Millsap (1995b)].
• Вы хотите иметь возможность закупать новые диски с ростом системы и чтобы СУБД Oracle динамически размещала новые экстенты в соответствии с этим ростом.
• Вам желательна предварительная фрагментация во всех табличных пространствах, содержащих временные сегменты и сегменты отката для минимизации накладных расходов, связанных с выделением экстентов.

6.2 Свойства параметров хранения

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

• Кратность размеру блока данных — все размеры экстентов должны быть кратные размеру блока данных базы данных. Oracle будет всегда округлять размер экстента до размера блока данных. Например, неразумно пытаться установить значение 10KB для параметра initial в базе данных с размером блока данных 8KB. Начальный экстент с 8KB–блоком данных всегда будет занимать как минимум 16KB, в независимости от того что Вы запросите.
• Кратность размеру файла данных — все размеры экстентов должны быть кратные используемым размерам файлов данных. Это позволит наилучшим способом использовать пространство в файлах данных без возникновения потерь.
• Небольшое число размеров экстентов — число различных размеров экстентов в каждом табличном пространстве должно быть небольшим, к примеру — только один размер. Если Вы используете несколько размеров экстентов, все они должны быть кратные, либо делить друг друга нацело.

На рисунке ниже показаны два файла данных, в которых выделено по два экстента. Малые области в начале каждого файла представляют заголовки файлов ¹⁶.

На этом примере большие экстенты B1, B2 и B3 имеют такой размер, что ровно два экстента могут разместиться в каждом файле данных. Файл данных, называемый abc01.dbf содержит ровно два таких больших экстента. В abc02.dbf находится один большой экстент B3, а также небольшой экстент, обозначенный S1. Оставшееся свободное пространство, помеченное как F1, имеет большой размер, — почти половину размера файла данных, — но недостаточный для хранения еще одного большого экстента, такого как B1, B2 и B3.

Экстент S1 — причина появления неиспользуемого пространства, поскольку его размер отличен от размера больших экстентов, что порождает неиспользуемый фрагмент свободного пространства F1. Фактически, если размер больших экстентов не кратен размеру S1, то это приведет к тому что оставшееся свободное пространство в abc02.dbf не сможет быть полностью освоено.

Для понимания истинного влияния этого типа проблемы на VLDB, Вам необходимо помнить, что число файлов данных с Oracle7 ограничено несколькими сотнями, в Oracle8 — несколькими тысячами. Проблема, которая требует одного часа администратора базы данных в БД размером 5GB с 20 файлами данных, для аналогичного решения в VLDB размером в 1000GB и 600 файлами потребует более 30 часов. Комбинация возрастания размеров проблем и более жестких требований доступности в среде VLDB погубит администратора базы данных если он не сможет реализовать стандартные решения, подобные тем, что мы обсуждаем.

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

6.3 Выбор параметров хранения

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

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

   select
   blocks, bytes
   from
   dba_free_space
   where
   file_name = ’filename’;
   

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

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

2. Для каждого табличного пространства установите умалчиваемые параметры хранения в следующие значения:
   • Выберите значение initial таким, чтобы оно было кратным блоку данных БД и чтобы размер полезного пространства файла данных был кратен этому значению.
   • Установите значение next равным initial.
   • Установите pctincrease в 0.

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

3. Везде, где это возможно, используйте умалчиваемые, определенные на уровне табличного пространства, параметры хранения для сегментов. Оптимальным вариантом было бы наличие только одного набора значений initial, next и pctincrease для каждого табличного пространства. Для сегментов с индивидуальными параметрами хранения, отличными от умалчиваемых, используйте следующие правила:
   • Установите значение initial таким, чтобы оно было кратным размеру блока данных СУБД и чтобы размер полезного пространства в файле данных был кратен этому значению.
   • Установите значение next равным initial.
   • Установите значение pctincrease в 0 для больших сегментов и в 0 или 100 для малых сегментов.
4. Для каждого сегмента с параметрами хранения отличными от вышеприведенных, используйте индивидуальные значения.

Если Вы используете параметры хранения из таблицы с k = 10ⁿ и размером файла данных показанным ранее, то Вы найдете только шесть различных наборов параметров хранения при следующем запросе:

select distinct (
initial_extent||’,’||
next_extent||’,’||
pct_increase
) "initial,next,pctincrease"
from dba_segments;
initial,next,pctincrease
-----------------------16384,16384,0
212992,212992,0
2146304,2146304,0
21471232,21471232,0
214745088,214745088,0
2147467264,2147467264,0

---

15(к тексту)	Если Вы можете получить улучшение производительности DML-операторов от «сжатия» сегмента, то Вы сможете получить то же улучшение с помощью правильного управления сегмента с несколькими экстентами [5, Millsap (1995b)].
16(к тексту)	Размер заголовка равен одному блоку данных если Вы используете файловую систему и двум блокам, в случае использования линейных устройств.

---

Назад Содержание Вперёд