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

Ответ 1

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

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

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

Ответ 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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

Я категорически не согласен с оценкой Джастина. Производственный DBA, вероятно, будет иметь совсем другое мнение.

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

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

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

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

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

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

Ответ 5

S. Lott уже дал хороший список общих причин, по которым можно было бы разбить это на несколько табличных пространств.

Подробнее о вашей ситуации...

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

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