Наша ERP растет поненмогу и назрела ситуация, что основной Tablespace нужно уменьшать (разделять).
Было принято решение создать несколько дополнителных Tablespace, которые бы содержали в себе определенные модули.
Например:
PSAPR3FICO, PSAPR3HR, PSAPR3RET, а в основном Tablespace PSAPR3 останутся общие таблицы.

Как можно составить такие списки по модулям?

Как вариант - разделить по пакетам.
В таблице TADIR есть инфа, какая таблица в каком пакете.

А на чем основывается такое желание ? И чем вам это поможет если не секрет ?
Может проще заняться архивированием и дефрагментированием ?
На сколько велика ваша база ? Базисника как обычно нет ?

База уже скоро будет 7,5 ТБ, вернее только этот Tablespace.
А поможет это тем, что уже сейчас, а тем более в будущем проще будет, ну хотя бы реорганизацию Tablespace при очередном архивировании делать. Да и если руководство купит нам новую дисковую систему без tiering, то будет проще раскидать файловые системы на разные по быстродействию дисковые пулы. Да и в периоды отчетности проще будет требуемый модуль, например, на SSD пул скинуть.
Ну почему же сразу базисника нет, все есть

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

дело в том, что очень странный вопрос при наличии базисника.
Если подумать, можно придумать как дата-файлы между дисковыми пулами распределить.
Ну а "модули" - это скорее логическое деление, чем физическое.

Ну вот мы и подумали и придумали сделать так. В BW-отделе уже сделали подобное деление, но их решение нам не подходит, т.к. у нас ERP.

По моему это бред чистой воды, у нас системы и побольше вашей (11-16ТБ) что то не возникало таких мыслей.
На счет раскидывания на разные диски , тут может быть 2-ой эффект, лучше просто все иметь на быстрых дисках если нет автоматического перекидывания.
Зачем реорганизовывать таблспейс ? У вас какой оракл ?
Возвращаетесь в прошлое ? 355771 - Oracle: Explanation of the new tablespace layout
Сейчас все затыки в основном связаны с кривым кодом , лучше подумать как с ним бороться, ну еще если сервер БД справляется сам (CPU , Memory).

Ваши слова да нашему руководству в уши.

Всем известно, что одинаковых систем нет! А значит к каждой системе применяется свой подход. У кого-то нет проблем с финансированием, у кого-то начальство не слушает своих администраторов, у кого-то начальтво закупает то, что оно считает лучшим на рынке, но не очень подходит для решения его задач или просто скидки были хорошие А у кого-то все это слилось вместе

В общем, в нашем случае делать реорганизацию одного Tablespace 8-14 часов и при этом нужно временно изыскивать эти 7 ТБ - является проблеммой. Вот и зреет какое-нибудь рациональное решение.

Кстати, в свое время, когда фирмы начали поголовно переходить на дисковые подсистемы корпоративного и бизнес класса, действительно отпала необходимость делить Tablespace на данные и индексы.

И если, к примеру, у вас есть SSD дисковый пул 10ТБ, а база весит 18 ТБ, то около половины в ней занимают индексы и если их переложить в отдельные Tablespace и разместить на SSD дисковый пул, то я думаю тут и рассказывать ничего не надо, что будет. Но, это решение скорее от безысходности.

При наличии tiering все это теряет смысл.

Вы немного не правильно рассуждаете, зачем реорганизовывать таблспейс целиком? Я этого не понимаю . Какое время изыскивать? какие 8-14 часов , для чего?
С теми СХД что сейчас, если они настроенны правильно, протблем не должно быть с дисковой нагрузкой, по крайней мере вы не решите ее таким способом. Если сервер БД справляется с нагрузкой , то лечите ваши SQL запросы, я много систем видел, сложилось такое мнение. Создав дополнительные таблспейсы вы только проблем себе наберете (можете набрать) во время апгрейда и если мигрировать решите куда нибудь.

Вы видимо меня не правильно понимаете. У нас стоит 2-а дисковых массива IBM DS8100. Общий объем 40 ТБ, а свободных осталось всего 3 ТБ на все системы. К быстродействию дисковых систем притензий нет и не может быть. Проблема в том, что у нас всего 3 ТБ свободного места. А 4-e инстанции уже имеют Tablespace по размеру больше чем 4 ТБ каждый. Конечно можно реорганозовывать отдельно таблицы, но тут, тоже есть подводные камни (дефрагментация самого Tablespace, большее колличество операций с таблицами по сравнению с реорганизацией одного-двух Tablespace).
А вот, как раз, проблем с Upgrade/Update при большем количестве Tablespace не возникнет.

Да и проблемма это временная, пока нам не купят другую дисковую систему, тогда вернем все к оригиналу.

Вопрос можно закрывать, решили 30-40 самых больших таблиц раскидать по другим Tablespace, а модульщики подскажут какая таблица к какому модулю принадлежит.

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