Мы - корпорация ABC - являемся "королями дисков". Не стоит беспокоиться о разделении различных файлов вашей базы данных Oracle, просто создайте один огромный логический том, куда войдут все доступные дисковые устройст­ва, и храните на нем все файлы. Это делает управление вводом/выводом очень простым и уменьшает число "горячих точек" в базе данных.

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

индексу для одной или нескольких больших таблиц базы данных, упомянутый

выше метод способен вызвать серьезные проблемы производительности вво­да/вывода.

Основной вопрос, который требует разбирательства, состоит в том, как работа-
ет операция сканирования индекса. Когда оператор SQL использует для выполнения запроса индекс, он считывает один или несколько блоков индекса в
буферный кэш базы данных, опираясь на значение индексированного столбца,
упомянутого во фразе where оператора SQL. Номера строк        соответст-

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

из конкретных блоков таблицы, к которой был задан запрос. Когда выполняет-
ся значительный объем сканирования индексов, приходится постоянно считы-
вать блоки индекса и блоки данных таблицы при помощи операции чтения
одиночного блока. Проблема, встающая перед системой ввода/вывода, состо-
ит в том, что при обслуживании запросов на        блоков индекса, дан-
ных ей, приходится отыскивать различные адреса на созданном логическом
томе, потому что физически блоки данных и блоки индекса размещаются в раз-
личных участках диска. Учитывая, что тремя компонентами запроса на
ввод/вывод являются установка (подвод время ожидания (время, в те-
чение которого заданный сектор диска подводится к головке чтения-записи. -

Прим пер.) 

и передача данных, а также, что установка является наиболее доро-
гим компонентом обслуживания ввода/вывода, конечной целью должно стать уменьшение количества установок в системе ввода/вывода. Хотя системы вво­да/вывода и достигли за последние десять лет больших успехов, компонент установки все еще составляет от 40 до 60% общего времени, требующегося для обслуживания запроса на ввод/вывод. Балансировка числа установок в системе (где одновременно производится доступ к различным блокам данных из неско­льких таблиц и индексов) должна стать вершиной усилий по устранению узких мест

Итак, если файлы данных табличных пространств INDX и DATA размещены в одном наборе физических устройств (а это как раз тот самый случай, когда один огромный логический том создан изо всех имеющихся у нас дисков), то это си­льно увеличивает конкуренцию при установке, что вызывает серьезные узкие

места ввода/вывода.

 

ID - последняя граница, к ней устремлены взоры всех АБД Oracle, которые
смело вели дела с производителями запоминающих устройств большой емкости,
знакомы с их претензиями и        оптимальной производительности вво-

да/вывода за счет применения собственного здравого смысла. Вокруг техноло­гии RAID бытует множество неправильных толкований. В этой главе мы определим, что такое RAID и чем он не является. Будет объяснено, как он рабо­тает, а также показаны различия между всеми его уровнями RAID. Затем пользо­ватели получат рекомендации по реализации для каждого из типов RAID на примерах из реальной жизни, иллюстрирующих оптимизацию ввода/вывода для очень больших баз данных (VLDB, very large databases) Oracle.

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

все-таки вы будете знать достаточно, чтобы осознанно вести разговор с админи­стратором системы/памяти. Мы намерены рассеять мифы, окружающие союз Oracle и RAID.