По возможности продвинутые файловые системы типа xfs, jfs или vxfs дол­жны получить предпочтение перед файловыми системами ufs. Это нужно для того, чтобы использовать усовершенствованные опции журнала и производите­льности (такие, как устранение повторной буферизации), которые придают продвинутым файловым системам дополнительные преимущества перед систе­мой ufs. Следует отметить, что если при конфигурировании системы использо­вать ufs, необходимо также конфигурировать и настраивать параметры уровня

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

При использовании файловых систем фирмы Veritas Quick I/O может обес­печить приемлемую производительность неформатированных устройств без

потери тех преимуществ, которые приходят вместе с применением файловой

системы. Дело в том, что драйвер Quick I/O прерывает запись, производимую

DBWR (когда это разрешено), тем самым обходя буферный кэш файловой систе­мы. Это обеспечивает сравнимую производительность неформатированных устройств, потому что удается уйти от ставшей уже классической проблемы по­вторной буферизации и потерянных циклов ЦП при управлении буферным кэ­шем файловой системы. При использовании других типов продвинутых файловых систем можно предпочесть использование прямого ввода/вывода, если он поддерживается ОС, так как он тоже предоставляет производитель­ность, сравнимую с производительностью неформатированных устройств. Ис­пользование неформатированных устройств не дает значительного эффекта по

сравнению с продвинутыми файловыми системами 

с 

драйверами Quick/Direct

I/O (всякий раз, когда они применимы).

Неформатированные устройства добавляют еще один уровень операционной сложности без могущего служить оправданием увеличения производительности, если сравнивать ее с продвинутыми файловыми системами, конфигурирован­ними с использованием драйверов Veritas Quick I/O или Direct I/O (поддержи-

ваемых ОС). Кроме того, они также не дают возможности размещения на одном

устройстве нескольких файлов. В подобных случаях конфигурирование и испо­льзование неформатированных устройств следует оставить для реализаций Oracle Parallel Server.

Асинхронный ввод/вывод

Было обнаружено, что Oracle, сконфигурированный асинхронным вво­дом/выводом, для большинства клонов UNIX эффективно работает только с неформатированными устройствами. Регулярные файловые системы с асинх­ронным вводом/выводом поддерживаются в некоторых операционных систе­мах типа Solaris и AIX. В зависимости от конфигурации подсистемы ввода/вывода оказывается, что драйверы Direct I/O или Quick I/O предлагают

вполне сравнимую производительность в случае использования специализиро-

ванных файловых систем типа от Veritas. Кроме того, можно иметь опцию для конфигурирования релевантных параметров экземпляра Oracle для поддер­жки нескольких процессов записи базы данных. Но обычно разрешается либо

асинхронный ввод/вывод, либо несколько процессов записи базы данных, но

не то и другое вместе. Обратитесь к главе "Настройка ОС" за подробностями, от-
носящимися к асинхронному        для Solaris, HP-UX и AIX.

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

Даже сегодня не потеряно значение того, что нельзя размещать на одном за­поминающем устройстве несколько объектов, доступ к которым возможен в од­но и то же время. Основное внимание должно быть уделено устранению узких мест ввода/вывода и "горячих точек" базы данных. Хотя основа данного вопро-

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

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

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

Отделите данные от ассоциированных с ними индексов

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