Меня всегда удивляла популярность подобных схем (отдельно то, отдельно сё). Ведь когда на СУБД идут запросы, а та, в свою очередь, осыпает диски своими запросами на чтение и запись, кажется очевидной простая стратегия, которую Oracle назвали S.A.M.E - stripe and mirroring everithing, то бишь, всё имеющееся в наличии размазать по всем дискам (возможно, за исключением транзакционных логов, которые-таки отдельная статья).

Применительно к DB2 мне ещё кажется разумным пользоваться RAID1, а не RAID10. Когда у нас есть N пар дисков, мы можем разместить по контейнеру на каждом зеркале (благо, DB2 автоматически балансирует данные по контейнерам) и задать prefetch size = N * extent size, и было обещано, что эти N кусков будут читаться одновременно. Правда, для RAID10 из тех же N пар рекомендована такая же настройка, но я-таки не понимаю, в чём будет польза в данном случае, как 10-ка справится с одновременным чтением этих кусков (куски, положим, большие, по 1м каждый, и дисков много). Для одностраничного же чтения едва ли будет разница. Но всё это надо проверять.

Если это контейнеры одного и того же tablespace, то класть их на один диск... неинтересно. Ну, положим,
extent size у нас 1м,
prefetch size 2м,
два контейнера одного табличного пространства,
tablescan
- и, как обещано, DB2 пытается выполнить два запроса по 1м одновременно. То есть передаст асинхронно операционной системе два запроса на чтение по 1 мегу.
Что произойдёт? Ну, наверное, ОС выполнит их последовательно. Точно также, как если бы prefetch size был 1м или контейнер был один.
С одностраничными запросами тем более не должно быть заметной разницы (с точки зрения нагрузки на диск) - одновременного чтения нескольких страниц не произойдёт, так и эдак надо подвести головки к участку диска и произвести I/O. Нагрузка на CPU при вычислении номера сектора... разная скорость подводки головок в разных обстоятельствах, разная плотность записи... понятия не имею, как оценивать.

И потому смысл разбивать на несколько контейнеров на одном диске непонятен. Это не Oracle, где это вынуждено - либо один большой контейнер, либо много маленьких (максимум по 32 гига при стандартной 8-килобайтовой странице), тут контейнеры довольно большие.

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

(Снова чисто теоретические рассуждения на основе чтения документации. Я, кстати, некоторое время назад занялся раскопками HammerDB на предмет адаптации квази-TPC-С и квази-TPC-H, но с моей загруженностью и темпами в этом году это может не произойти).

Есть ещё пара интересных параметров у tablespace - это INITIALSIZE и INCREASESIZE. Кажется разумным поставить их в размер побольше, чтобы было поменьше фрагментации. Но будет ли толк, зависит от файловой системы. Надо отметить, что Oracle создаёт большие tablespace очень долго (по-видимому, чем-то полностью заполняет файлы), а DB2 очень быстро. Можно ожидать, что это будет не в пользу DB2 (по крайней мере, на тех файловых системах, что поддерживают sparse allocation), но этот вопрос тоже требует дополнительного исследования (чуть ли не с HEX-редактором в руках).

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

xz321,
вопрос в sparse allocation. В каком виде это будет размещено на диске на такой файловой системе. Поэтому мне кажется разумным забить чем-то место сразу.

Хочется, чтобы фрагментации было поменьше. Хотя с большим extent size это даже может быть и неважно.

А, дошло. Если strip size - это размер блока на диске, strip size равен db2-шному extent size, DB2_PARALLEL_IO включён, то prefetch в несколько extent'ов одновременно должен читать разные диски одновременно, что и требуется. Вопрос только, чему равен strip size. Максимум читаемого блока на виндах и, вроде бы, на линухе тоже, 1м, а массив может быть создан с иными параметрами, в этом смысле набор зеркал проще.

См. также
на тему NUMBLOCKPAGES у BUFFERPOOL,

http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000912.html?cp=SSEPGG_10.5.0/2-12-7-61&lang=en
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000885.html?cp=SSEPGG_10.5.0/2-12-7-8&lang=en

http://etutorials.org/cert/dba certification/Chapter 2. Data Manipulation/The Buffer Pools/

Для raid-а получается вот как:

Положим, конкретный контроллер умеет читать со всех дисков одновременно. При этом
strip size = E килобайтов,
N дисков
=> stripe size = N*E килобайтов.

У нас есть два варианта распараллелить:

1. попытаться прочитать N кусков по E килобайтов одновременно;
DB2_PARALLEL_IO включён,
extent size = E
prefetch size = N*E

2. попытаться прочитать один кусок N*E килобайтов, считая, что операционная система передаст это драйверу контроллера, тот сам порежет запрос на N одновременных по N кусков.
DB2_PARALLEL_IO выключён,
extent size = N*E
prefetch size = N*E

Но второй вариант у нас под большим сомнением и ввиду возможностей ОС, и ввиду возможного ограничения, зашитого в DB2. К примеру, у нас E=256K, N = 4, мы ожидаем от DB2 одного 1-мегабайтного запроса к ОС, а она сделает четыре последовательных 256-килобайтных ввиду ограничения. Это совсем не то, что нужно.

Где узнать, чем обуславливается ограничение DB2 и какова его величина в тех или иных случаях? Я не нашёл. В качестве рабочей гипотезы принял, что 256К жёстко зашито для всех платформ (ну, то есть "для всех двух"), strip size массива и extent size при использовании массива должны быть строго одинаковыми и по возможности по максимуму (256К).

К этому надо прибавить какой-то способ, позволяющий обеспечить правильные смещения - чтобы экстент размером E был непрерывен и его отступ от начала диска был кратен E, т.е. чтобы весь диск можно было бы логически представить себе разбитым на экстенты размером E и наши базоданновые экстенты точно легли на них. Я не представляю, как этого добиться на "популярной" файловой системе (NTFS, ext3. ext4), хотя, быть может, я опять что-то не знаю. Такое обеспечивает ораклячий ASM (для "разумных" E), а для DB2, наверное, придётся использовать raw devices.

/sys/block/sdX/queue/max_sectors_kb
вот оно. Теперь под виндами надо такое же найти.