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

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

информацию для отката. В большинстве случаев они сконфигурированы

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

nologgingn 

SQL*Loader или же на уровне таблицы должен быть установлен атрибут 

nologging 

в комбинации с подсказкой /*+ APPEND */ в операторе вставки).

•        Большой процент операций сортировки выполняется в памяти, что уменьшает для временных табличных пространств как возможность их использования, так и вероятность конкуренции. Этого легко достичь, должным образом сконфигурировав параметр SORT_AREA_SIZE на уровне экземпляра или на уровне сеанса. Начиная с Oracle 7.3, параметр

' инициализации Oracle SORT_AREA_SIZE конфигурируется на уровне

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

Для приложений с высокой интенсивностью операций записи табличные пространства DATA, INDX и RBS должны быть разделены. Различные группы онлайновых журналов обновлений нужно по возможности размещать на раз­личных устройствах/томах. Далее, адрес, по которому процесс ARCH записы­вает архивированные журналы обновлений, должен отличаться от адреса, по которому размещаются онлайновые журналы обновлений. Может оказаться оправданным размещение на одном томе табличных пространств RBS и TEMP, если параметр SORT_AREA_SIZE сконфигурирован оптимальным образом и от­сутствуют доказательства неоднократной одновременной генерации операций

типа сортировки на диск (sorts on disk) и элементов отмены для отката (undo entries for rollback).

Разделение "горячих" объектов в табличном пространстве

Для отдельных приложений может оказаться, что некоторые таблицы или индексы "горячее", чем большинство остальных таблиц и индексов (т. е. обра­щения к ним происходят чаще. - 

Прим. пер.). 

Лучшим выходом в подобных об­стоятельствах будет выделение таких таблиц и/или индексов из числа остальных путем помещения их в отдельные табличные пространства, разме­щенные на новых или специально освобожденных томах RAID. Знайте, что вре­мя, потраченное на повторную балансировку ввода/вывода после

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