Удаляю старые данные в BW из инфо-кубов.
Свободного места в таблспейсах не прибавляется. База растет бешеными темпами, учитывая частые ошибки пользователей в предоставляемых ими данных.
Подскажите, плз, есть ли утилита типа дефрагментации, чтобы высвобождалось свободное место в таблспейсах ?
Если нет, то как это сделать средствами Oracle (или sapdba) ?
Возможно ли такое вообще ?

Про утилиту типа дефрагментации не слышал.
Простое удаление данных размер таблиц не уменьшает: сколько было выделено экстентов, столько и останется, даже, если записей осталось ноль. Чтобы освободить неиспользуемые экстенты и уплотнить записи в таблицах, нужно выполнять реорганизацию (таблиц, табличных пространств). Но делать это следует, на мой взгляд, если удаляется единомоментно существенно больший объем данных, чем периодически добавляется. Например, закачка происходит ежедневно/еженедельно, и выполняется удаление записей за весь год. При сопоставимых объемах удаляемых и добавляемых записей особого эффекта от реорганизации не будет.

Огромное спасибо за совет !

А чем объясняется непомерный рост базы? Ведь заливаются килобайты, а получаются мегабайты. Или таковы особенности хранения данных?

На входе данных немного. Но BW должен переработать эти данные, сделать пригодными для просмотра в кубах (далее к специалисту по BW). Поэтому данных в БД сохраняется больше, чем передается в систему. Плюс накладные расходы на хранение - зависит от самой СУБД.

Здесь речь идет о BW, при заливке данных создаётся куча таблиц. Причем при каждой новой заливке создаются новые таблицы. Если заливка повтроряется из-за ошибочных данных то этих таблиц типа /XXX/XXXXXXXX просто немерено и они соответственно локируют место в таблеспасе. Нужно просто правильно удалять ненужные данные. К сожалению подсказать не могу где какие кнопки нажимать, потому что не помню и нет BW под рукой, но если поишешь в нотах я думаю найдешь. А реорганизацию делать не надо, при удалении этих таблиц, места в таблеспасе освободится достаточно.

небольшие уточнения, если позволите

дефрагментация, реорганизация и экспорт/импорт в контексте оракла - все это можно обозвать синонимами, ИМХО

удалить данные из таблицы так, чтобы и освободить занимаемое ею место можно - truncate table <tablename> (опять же в контексте оракла)

[quote="andivanov]
небольшие уточнения, если позволите

дефрагментация, реорганизация и экспорт/импорт в контексте оракла - все это можно обозвать синонимами, ИМХО

удалить данные из таблицы так, чтобы и освободить занимаемое ею место можно - truncate table <tablename> (опять же в контексте оракла)[/quote]

Конечно, используя средства oracle можно много наворотить. Но стандартная процедура удаления после архивации, во-первых, может удалять отнюдь не все данные (и в этом случае truncate приведет к потере данных), а, во-вторых, процедура truncate сама не выполняет.

По все видимости растёт PSA, нужно зайти в PSA и удалить ненужные данные, наверняка их там много, и наверняка это и есть те самые создающиеся при каждой закачке таблицы /XXX/XXXXXXXXXXXXX. Если удаление данных произойдёт корректно, эти таблицы будут удалены из БД, и место в таблспейсах освободится

как средством sapdba сделать реорганизацию для дефрагментации таблиц, чтоб прибавить свободного места?
удалил много данных, а места не стало больше ((

Курс ADM505
Классический путь реорганизации:
1. Экспорт таблиц
2. Удаление таблиц
3. Пересоздание таблиц/тейблспейсов
4. Импорт экпортированных таблиц

самый тупой способ (типа - для чайников;) - делать бэкап перед серьёзными закачками.
Попутно системщики до автоматизма отрабатывают навыки аварийного восстановления ))
зы впрочем, бэкап полезен перед любыми манипуляциями на уровне БД

Ужас какой то!

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

На самом деле, Вы не указали какие именно табличные пространства растут. Посмотрите PSA. Рекомендуется делать SE38 SAP_DROP_TMPTABLES (6 или 7 видов временных объектов). Применяются табличные пространства с локальным управлением сегментами/экстентами.

Экспорт-импорт таблиц кубов....
При создании того или иного куба, например базового или транзакционного система сама создает таблицы и автоматически генерирует их имена. Так же, в САп-е все констреинты вычисляются системой. Все связоки просто не возможно отследить - хлопотно это!
А ведь еще могут быть и агрегаты с кучей индексов! Так, между прочим, перестраивать сами агрегаты не пробовали?

Давно известно, что BW генерирует кучи мусора. Его можно вычищать, но очень аккуратно.
Средствами САП-а многое сделать просто не возможно. Это нужно делать средствами БД.

ЗЫ Вот так и приходится потом работать! За 3-ий год работы с САП не встретил ни одной нормально мигрированной и настроенной БД Оракл! Везде были убитые словари!!! Просто ужас! Вчера вот всю Сб. пришлось работать - переделывать за "базисными гуру" из крупной конс. компании, будь они не ладны!

из DBA в SAP как я понимаю?:)
ну... насколько я понимаю в базисе SAP не так много DBA. Так что немудрено, что с точки зрения DBA оракл не должным образом настроен.

Не могли бы вы просвятить - что именно Вы подразумеваете под убитыми словарями?

Svetlana, Вы абсолютно правы! "Из огня, да в полымя"

Для начала хотя бы так
select * from dba_objects where status != 'VALID';
и чтобы у SYS-а не было разваленных объектов. Бивишные вьюхи(тем более временные объекты) и прочая шелуха - не интересна.
Насчет миграции словарей. Единственный выход - внимательное изучение "Database migration" иначе трындец. На самом деле, при подходе ее, ДБАшной работы только прибавляется! Меня то по "объявлению набрали", а не по блату.
А если террабаййтная BW, то начинается просто ужас!
Но в прошлую Сб. "ночной кошмар" закончился.

Да, еще по поводу фрагментации. Можно восмотреть в графике, например, тулза от Embarcadero (DBArtisan). Покупайте и любуйтесь!Если таковой в нет в наличии, то можно самому набросать скриптик.
Например, так:

select * from dba_tablespaces;

--Tablespace fragmentation by dol_vv
select
'Free space' Owner, ' ' Object,
File_ID,
Block_ID,
Blocks
from DBA_FREE_SPACE
where UPPER(TABLESPACE_NAME) = UPPER('&TABLESPACE_NAME') ----'INDEXES'
union
select
SUBSTR(Owner,1,20), SUBSTR(Segment_Name,1,32),
File_ID,
Block_ID,
Blocks
from DBA_EXTENTS
where UPPER(TABLESPACE_NAME) = UPPER('&&TABLESPACE_NAME') ----'SYSTEM' --and segment_name='DPS'
order by 3,4 desc;

Соответственно, фри-спейсы - это дырки. А дыры можно склеить coalesce.
Если в 8-ке были проблемки с локальными табл. пр-ми, то в 9-ке можно делать на автомате и не заморачиваться (столбец SEGMENT_SPACE_MANAGEMENT) в вышеприведенном запросе.

PS В САП специально не напрашивался, просто так уж получилось. Если приложить руки, то система будет нормально работать. Наверно так в любом деле...

спасибо