Добрый день !
Планирую проводить работы по выделению датафайлов продуктивной базы на отдельный диск, о чем спрашивал ранее в http://sapboard.ru/forum/viewtopic.php?f=14&t=95541

Алгоритм:
0. Остановить систему
1. Подключить новый диск
2. Создать табличное пространство PSAPSR3NEW такого же объема
3. Проверить ТП PSAPTEMP на достаточный объем
4. Выполнить перемещение таблиц (brspace -u / -f tbreorg -s PSAPSR3 -t "*" -n PSAPSR3NEW -p 16)
5. Проверить что в ТП не осталось таблиц типа plan_table и индексов.
5. Дропнуть старое ТП. (brspace -u / -f tsdrop -t PSAPSR3)
6. Переименовать ТП. (brspace -u / -f tsalter -a rename -t PSAPSR3NEW -n PSAPSR3)
7. Пересобрать статистику (brconnect -u / -c -f stats -t PSAPSR3 -f collect -p 4)

Это должно:
0. Датафайлы будут на отдельном диске
1. Уменьшить объем базы (на 20% по моим подсчетам)
2. Дефрагментировать ее

Все правильно, я ничего ведь не забыл ?
Ес, ноу, камелот, советы, замечания, предложения? Спасибо!

З.Ы. Конфига: VmWare + Windows + Oracle

...
А разве после 4 пункта для перемешённых таблиц индексы не развалятся ?¿?

p.s. алгоритм в целом правильный, только дефрагментация тут ни при чём, а вот для включения компрессии - самое то.

Делал на копии - объем данных в табличных пространствах упал на 20%, какие-то таблички посдувались думается...
А разве это не назвать дефрагментацией ? Ведь экстенты табличкек в новом ТП уложатся по порядку, да, скорости это не прибавит, но термин вроде употребим

Как я понимаю, индексы тоже перемещаются, бывает, застревают некоторые, но их удаляешь из database utility в SAP, пересоздаешь и они создаются не в старом в табличном пространстве, а в том, где лежит индексируемая таблица.

раньше в операционных системах надо было делать дефрагментацию вручную регулярно - они не умели разбивать файлы

Во, нашел:
Effects of a Reorganization
A reorganization can have the following positive effects on the database:

The data from one object can be merged into a single extent or into fewer extents.
The data from a tablespace with many small files can be merged into one or more larger data files.
Freespace fragments in an object are merged into larger freespace segments if reorganized into a new tablespace. This process is called “defragmentation”.
The fill level in the individual blocks is evened out, so reducing internal fragmentation.
Data chains are resolved in most cases.

тут какое дело:в нормальной системе где есть админ проводятся регулярные чистки (раз в год к примеру). И если после чистки что-то "двигать", то размер БД конечно уменьшится, но за год опять же отрастет на столько же, а скорее всего еще чуть больше (за счет неудалямых данных). То есть получается много работы в перспективе с незаметным выхлопом. Это один момент.

Другой состоит в том, что в САПе мульён таблиц из которых непустых 2 сотни и из которых 2 десятка в сумме дают 90% размера всей БД. Вот их и можно индивидуально чистить и мувать.

Более перспективно, кмк, в САПе было бы таблицы с данными секционировать - секции с данными которые уже не будут меняться переносить в отдельное ТП и делать его ридонли. В перспективе можно было бы получить что на террабайтной БД у вас 600 гиг в РО и никак не бэкапятся (только один раз) и и это сильно бы упрощало всякие миграции и создание копий. Но я не встречал, чтобы САП хотя бы упоминал об этой отдушине админа. В тренде: знай наращивай размеры полок и скоростя дисковых массивов. ((