Лично мне отделение индексов от таблиц и использование разных буферных пулов совсем не кажется таким уж очевидно хорошим делом.

Например, пусть у нас два дисковых массива - на одном данные, на другом индексы. При сканировании таблицы будет простаивать один массив, при index only access - другой.

Что касается разных буферных пулов для разных типов таблиц, то если у вас мелкие таблицы используются часто, а крупные (с фуллсканом) - редко, то, по идее, мелкие таблицы не должны вымываться из пула?

Буферные пулы: надо ж учитывать не только состав данных, но и нагрузку. Частые сканирования больших таблиц - выгодна одна конфигурация, но если редкие - то другая.

Разнесение данных и индексов. Аналогично, надо учитывать нагрузку. В чем выгода raid'а для чтения? В одновременном доступе к нескольким дискам. Надо полагать, что чем больше дисков мы задействуем, тем больше общая скорость обмена. Таким образом, выделив отдельные диски под индекс и имея главным образом index only access, мы выделим под это меньшее количество дисков, чем если держать данные и индексы вместе. Здесь тоже предполагаются определенные условия, которые необязательно выполняются. Короче, настоящий ответ может дать только тестирование с реальными данными и реальной нагрузкой.

RAID 0 на N дисках и N контейнеров на N дисках - я думаю, что логически это примерно одно и то же.

"мешает для индексного tablespace иметь столько контейнеров/дисков, сколько надо" - а сколько надо? Я так подозреваю, что кашу маслом не испортишь (к сожалению, нет возможности заниматься тестированием так, как мне бы хотелось).

"если часть данных и индексов попадает на один диск - метания головок обеспечены" - как будто они и так не обеспечены. Базы то (как правило) многопользовательские.

2. То есть деньгами и техническими возможностями сервера вы совсем не лимитированы? Круто.

3. Пусть N клиентов запустили одновременно N запросов, производящих фуллсканы на M разных таблицах. Вы утверждаете, что все эти запросы будут выстроены в очередь и выполнены последовательно, то есть K-й в очереди клиент будет ждать, когда выполнятся K-1 чужих запросов, прежде чем начнетсы выполнение его запроса?

2. Ну значит, для кого как. В нашей конторе мы сильно лимитированы. Поэтому-то я и проверить толком ничего не могу. А тесты могут длиться неделями и месяцами, чтобы проверить все аспекты.

3. При делении имеющейся пачки дисков на две - диски для индексов и диски для данных - наверняка одна будет недогружена (в зависимости от данных, индексов и нагрузки). Для того, чтобы мысль была яснее, я привел предельный пример - "N клиентов запустили одновременно N запросов, производящих фуллсканы на M разных таблицах". Пачка (то есть массив) дисков с индексами простаивает. А ведь чем больше дисков используется, тем больший можно ожидать суммарный трансфер?

(Реально у меня обратная картина - многие запросы index only).

Теперь вернемся к "N клиентов запустили одновременно N запросов, производящих фуллсканы на M разных таблицах". Индексная пачка дисков простаивает (или не простаивает, другие K клиентов делают что-то с index only access). Будут ли метаться головки дисков с данными? Думаю, что будут все равно.

Такая же картина с модификациями данных - выгода разделения индексов и данных мне совсем не очевидна. В этом вопросе я могу поверить только тестам.