Уважаемые дамы и господа!
Возникла тут пара вопросов. Если в файловой группе имеются несколько файлов на разных физических дисках и создаем таблицу в этой файловой группе, то она (если достаточно большая) более-менее равномерно распределится по этим дискам.
1)Если теперь делаем выборку из нее, то будет ли чтение с дисков проводится параллельно?
2)Как будут располагаться данные в случае наличия кластерного индекса в этой таблице? Внутри страниц – понятно в соответствии с этим индексом. А вот как соотносятся страницы. Будут ли соседние страницы в одном файле или нет?
3)Если разные таблицы находятся на разных физических дисках, то при их объединении будет ли возможность проведения параллельного чтения?
4)Для проведения объединения существует несколько способов. В зависимости от распределения данных, наличия индексов на столбцы объединения и ограничения эффективности предиката ограничения и т.п. более дешевым будет тот или иной способ, который и выбирается. Будет ли учитываться при расчете стоимости объединения возможность параллельного чтения c дисков?
5)Кстати, если смотреть план запроса, то видно только операция объединения, которая дальше не разбивается. Соответственно вопрос – SQL Server вообще проводит анализ для выбора того или иного метода объединения?

Или же размещение на разных дисках скажется только при параллельном выполнении разных запросов, обращающихся к разным таблицам, хранящимся на разных дисках?
Также понятно, что в первую очередь следует на разных дисках размещать журналы транзакций, и, желательно системные базы.
К сожалению, сейчас проверить сам всего этого не могу, за отсутствием нескольких физических дисков, но очень интересно.

Спасибо. Рассылку обязательно посмотрю. Но все же меня сейчас больше интересует скорее теория. Достаточно ли SQL Server "умен", чтобы учитывать возможность параллельного чтения при построении ПЛАНА или же все дается на откуп ОС и выигрыш получается только за счет простого ускорения при чтении?
Иногда данные нужно считывать в соответствии с их физической упорядоченностью в таблице (для формирования на выходе также упорядоченного набора). Насчет кэширования - значит ли это, что данные будут считываться даже если конкретно сейчас они не нужны (до их обработки еще не дошла очередь, сначала надо отработать те что в соответствии с порядком находятся раньше) в кэш для последующего использования?
Да и на 2) и 5) вопрос пока ответа нет...

"достаточно посмотреть, как будет меняться план запроса в зависимости от того, чем в данный момент занимается Ваш сервер"
Опа... А как же быть когда делаем SP? Это что ж, выходит та или иная нагрузка на сервер в момент компиляции отразится на составлении плана, хотя и ежу понятно, что в момент выпонения этой SP нагрузка будет совсем другой (ну или во всяком случае существует большая вероятность этого).
-------------------------------
"Для расчета стоимости процессор запросов учитывает две основные сущности - память и CPU "
Чего то теперь я совсем запутался Мне всегда казалось, что основная (если уж не единственная) задача - минимизация времени (сейчас речь не о разных дисках). Ваша фраза относится к разным физическим дискам, выбору стратегии выполнения Join-ов вообще или же вообще глобально к оптимизации?
5) вопрос относился к Join-у вообще (не применительно к разным дискам). (зато Вы ответили на 4) )