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

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

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

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