База данных Oracle должна иметь больше чем одну табличную область для хранения данных?

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

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

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

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

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