NB
У нас сейчас по четырем разным dbspace'ам разнесены самая огромная таблица, ее индексы, остальные таблицы и остальные индексы. Raw devices под все чанки, а также прикладное ПО и все логи (довольно большие файлы, которые оно пишет) находятся на одной Volume Groupe, отведенной нашей системе.

Если я правильно понимаю, что том это Volume Groupe, наверное нам стоит разнести наши dbspace'ы по разным VG? Unix Admin, который заведует массивом, говорит, что в этом нет смысла...

У нас что-то похожее... После долгой борьбы за производительность посовещавщись с Unix-админом (он поначалу тоже смысла не видел :) сделали так:
- VG он нарезал по своим соображениям, что-то там с зеркалированием и дублированием, место под чанки резал кусками по 2Гб (у нас 7.31, но 9.21 насколько помню тоже понимает не больше 2Гб на чанк);
- физические и логические журналы также в dbspace-ах на разных физ.дисках, и отдельно от dbspace-ов с данными, пока их не отделил - длинные чекпойнты задалбывали;
- большие базы я фрагментировал по dbspace-ам использующим разные физические диски, под индексы тоже отдельный dbspace, но в нем чанки на разных дисках, и индексы отвязанные от таблиц.. хотя c индексами могут быть и другие варианты;
- ну и временные пространства тоже несколько штук... при правильном сооружении запросов они могут параллельно загружаться ( а могут и не загружаться :)
... в итоге после разнесения журналов, данных и индексов на разные физ.диски с чекпойнтами удалось справиться

Неужели массив ваще неуправляем снаружи? Мож стоит потрясти сис.админа с пристрастием? В VG назначаются конкретные диски, группы дисков. Нарезать несколько VG, назначить каждой VG свой диск или группу и пользовать для разных dbspace-ов разные VG - вот и будут разные физ.диски.