Должна ли база данных Oracle иметь более одного табличного пространства для хранения данных?

Question

Моя команда поддерживает базу данных Oracle размером ок.Размер 200 ГБ.Все данные (таблицы, индексы и т. д.) находятся внутри одного табличного пространства USERS.Это плохая идея?Какие преимущества дает наличие нескольких табличных пространств и при каких обстоятельствах мне хотелось бы добавить в свою базу данных еще больше?

Спасибо!

Answer 1

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

• Размещение объектов в разных табличных пространствах не дает никакого выигрыша в производительности.Существует старый миф о том, что разделение таблиц и индексов даст некоторый выигрыш в производительности.Существует потенциальная выгода от распределения ввода-вывода по всем доступным шпинделям, но это лучше делать с несколькими файлами данных в одном табличном пространстве, чем с несколькими табличными пространствами, поскольку Oracle выполняет циклическое распределение экстентов в разных файлах данных, предполагая, что ваша сеть SAN не Я еще ничего не делаю для выравнивания ввода-вывода.
• Если у вас есть большие статические таблицы поиска/истории, так что вы можете перенести новую копию базы данных на клиентский сайт, просто перенеся меньшие транзакционные табличные пространства, это будет поводом рассмотреть возможность создания нескольких табличных пространств.Но очень мало приложений имеют такую ​​настройку.Если вам придется взять с собой все 200 ГБ, не имеет значения, сколько у вас табличных пространств.
• Аналогичным образом, если у вас есть большие объекты, доступные только для чтения, размещение их в табличном пространстве, доступном только для чтения, может значительно сократить время и пространство, необходимые для резервного копирования.Опять же, однако, это не особенно распространено на практике за пределами хранилищ данных.
• Если ваше приложение может работать без некоторого подмножества объектов, возможно, будет полезно создать отдельные табличные пространства, чтобы вы могли отключить одно из них и выполнить восстановление на уровне табличного пространства.Опять же, немногие приложения могут работать без набора объектов — например, если вы потеряете индексное табличное пространство, приложение, скорее всего, так же мертво, как если бы вы потеряли все.
• Если у вас большое количество пустых или в основном пустых таблиц и несколько очень больших таблиц, с точки зрения использования пространства могут быть предпочтительнее отдельные табличные пространства с разными политиками выделения экстентов.Иногда это случается с упакованными приложениями, когда любая конкретная установка использует относительно небольшой процент доступных таблиц, и вы не хотите, чтобы каждой из пустых таблиц был назначен относительно большой экстент.При автоматическом управлении экстентами в локально управляемом табличном пространстве это, как правило, не является серьезной проблемой, но может вызывать больше беспокойства, если вы хотите использовать унифицированные экстенты.
• Если разные объекты имеют разные приоритеты производительности диска и у вас есть разные типы дисков, отдельные табличные пространства могут позволить вам разместить разные объекты на разных наборах дисков.Например, в хранилище данных вы можете захотеть поместить старые данные на более медленный и дешевый диск, а новые данные — на более дорогой диск.С OLTP-приложениями этого не происходит.

Если ваше приложение не попадает в один из этих особых случаев, единственным преимуществом наличия отдельных табличных пространств является обращение к чувству организации администратора базы данных.Лично я более чем счастлив, что могу избежать указания имени табличного пространства каждый раз, когда я создаю объект, или тратить циклы на перемещение объектов из «неправильного» табличного пространства, когда они неизбежно ошибочно создаются в табличном пространстве по умолчанию.Лично меня не слишком беспокоит, если несколько десятков МБ пространства будут «потрачены впустую» при использовании локально управляемых табличных пространств с автоматическим управлением экстентами вместо оптимизированного вручную набора табличных пространств с разными одинаковыми размерами экстентов.С другой стороны, хорошие администраторы баз данных, как правило, очень обеспокоены тем, чтобы все было организовано «просто так», поэтому я не выступаю категорически против того, чтобы администратор баз данных хотел иметь отдельные табличные пространства индексов и данных только потому, что это соответствует чьему-то чувству эстетики.

Answer 2

Видеть http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/tspaces.htm

Видеть http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/physical.htm

Вы можете использовать несколько табличных пространств для выполнения следующих задач:

Управляющее распределение пространства диска для данных базы данных

Назначьте конкретные пространственные квоты для пользователей базы данных

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

Выполнить частичную резервную копию базы данных или операции восстановления

Распределить хранилище данных на устройствах для повышения производительности

Answer 3

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

Answer 4

Я категорически не согласен с оценкой Джастина Кейвса.У администратора базы данных производства, скорее всего, будет совсем другое мнение.

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

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

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

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

что касается разделения данных и индексов:Традиционной причиной было размещение этих двух дисков на разных дисках, чтобы они не конкурировали друг с другом по производительности.Это не такая уж большая проблема с сегодняшними возможностями хранения данных, такими как сети SAN, где на самом деле это одна и та же область хранения, но есть все еще тот факт, что вы столкнетесь с конфликтами на уровне заголовка файла даже в локально управляемых табличных пространствах, если все ваши объекты находятся в одном табличном пространстве, где вы не можете локально отделить индексы от таблиц!Даже если вы создадите 20 файлов данных в одном табличном пространстве, вы не сможете решить, куда идти таблицы и индексы, а затем однажды вы заметите, что у вас возникли серьезные разногласия на уровне заголовка файла из-за массовой активности против таблицы, в которой находятся индексы. оказались в одном и том же файле данных!На самом деле откажитесь от этого.если у тебя только один ТС, то ты воля без сомнения, вы столкнетесь с конфликтом заголовков файлов.

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

Answer 5

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

Более конкретно для вашей ситуации...

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

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