Здравствуйте.

Нужен совет в следующей ситуации:

Система SAP BW NW7.01, SPS12, Oracle 11.2.0.2
База 6Тб.

В последнее время было стерто много информации о старых транзакциях и сейчас st04 показывает примерно 1,7 Тб свободного места. В основном в tablespace PSAPDAT.
Фрагментированные таблици были дефрагментированы, также индексы.
Задача: освободить физические диски из под свободного места в базе. (+/- 10%), база уже расти не будет.

То что нашел в документации это shrink на уровне таблиц и на уровне tablespace - coalesce и deallocate unused space.
Просба откликнутся тех кто имеет опыт таких работ - каковы примерные шаги, были ли проблемы, какие есть риски.

Спасибо !

это очень творческая задача

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

тезис первый:
resize дата-фалов оракла можно делать только с конца, с последних сегментов файла

вывод:
оконцовка урезаемого файла должна быть свободна от данных (это как с диском, чтобы отрезать кусок, надо сперва его очистить)

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

вывод:
в чистом netweaver более 40К таблиц, т.е. в последних физических блоках дата-файла окажется очень много таблиц (больших и неочень)


ну и на последок - общая концепция, исходя из опыта:

1. создать другой тейблспейс
2. реорганизовать существующие объекты тейблспейса в новый (все объекты поголовно)
3. прибить старый тейблспейс
4. переименовать новый тейблспейс

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


альтернатива - load based миграция базы средствами sapinst.

З.Ы. вроде все основные плюшки учел и описал

Большое спасибо за ответ!


Спасибо за идею с новым tablespace. Надеюсь убедить клиента насчет dwontime.
А пока....
к сожалению большого времени на downtime нет...и других 5 Tb тоже (dataceneter и storage далеко и любые маневры дорого стоят). Буду анализровать каждый датафайл и по возможности делать resize.

Удачи всем!

попробуйте..
у меня в 100мб последних блоков до 1,5к таблиц набивалось...
и так в каждом дата-файле.
отдельно каждый дата-файл реорганизовать не получится... более менее крупные объекты будут в каждом дата-файле

только прошу учесть, что в живой системе, оракл не будет спрашивать - куда писать?
он будет заполнять свободные блоки, в том числе высвобождаемые.
говоря проще - на лету в боевом проде, это нереально, к сожалению.

да, sapinst при экспорте сворачивает данные до 10раз (в среднем около 5-7 раз)....
при этом в новой инкарнации системы, Вы сможете на фазе инсталляции включить сжатие объектов базы (тейблспейсов например) средствами оракл.
НО, при таком варианте - дайнтайм будет удвоен: 1. экспорт с сжатием 2. импорт

to ШРАМ --> Привет. Не могу догнать зачем в этом плане серьёзный даунтайм ? Все объекты можно онлайн перегнать в новый ТС.
Или я что то не догоняю ?

привет!
технически можно и в онлайне, НО!
скорее всего будет ругаться словарь ABAP на расположение объекта в ином тейблспейсе (я не уверен, но память такой эпизод муссирует)
upd
а нет, щас проверил, не ругаеца...

высоко-нагруженные объекты, например таблицы интеграции - IDOC (EDIDC, EDIDS и пр.) будет очень сложно запустить в работу, т.к. они будут всегда заняты.

вот из этой логики я и упомянул даунтайм.

Да нет , я их недавно реорганизовывал всё нормуль , главное чтобы Undo хватило и место было в таблспейсе.
Даже TST03 и TST01 нормально реорганизуются, если нет дебильных select for update.
Ну в самом крайнем случае можно 99% онлайн перекачать в новый таблспейс , а всё что останется в короткий даунтайм в пару минут.
Словарь точно ни на что не ругается.

тогда надыть пробовать ТС-у...

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

migration monitor сократит время значительно
все остальные варианты - imho неплохой способ укокошить базу, что на продуктивной системе я делать бы не стала

мм.. Вы это говорите из опыта? или просто предполагаете ?

за себя скажу сразу - описанное делалось на боевой базе.

З.ы. ну а уж на совсем крайний случай, бэкап - друг админа.

из опыта, из опыта:)

R3load легальный способ, и САП его поддержит если что. Ехпорт-импорт на 16тб у меня занял около 11 часов; 3 тб удалось перегнать за 4.5 часа (от таблиц зависит, но все же)
но вы правы, конечно, зависит от степени "боевитости базы" и есть ли где потренироваться

бэкап - хорош, если он оттестирован как следует, а то они имеют склонность не восстанавливаться

Alena__
ну, с точки зрения поддержки SAP, тут все тоже честно
все работы (кроме resize) делаются средствами brtools - reorg (New Tablespace)

с позиции объектов БД, действия абсолютно безопасны, в виду самой техники реорганизации.
все что "застрянет" можно дочистить с помощью cleanup


о-даааа....


а можете озвучить данные по IOPS-ам с этой БД? Конечно, если информация не является закрытой.
так сказать "...в целях повышения образованности..."

я вот тоже все локти искусал. 16тер туда обратно это 32 за 11 часов. Более 800мб/с выходит. Даже если параллельно 400мб/с. Так это чистое копирование. А при экспорте импорте еще куча работы происходит.

sap2me
ну... в процессе экспорта/импорта активно процы задействуются для обработки сжатия/разветывания....
память не сильно критична....

в целом на мощной машине, такое возможно... но узким местом все равно будет СХД или канал до СХД

[quote="шрам] а можете озвучить данные по IOPS-ам с этой БД? Конечно, если информация не является закрытой.
так сказать "...в целях повышения образованности..." [/quote]


Мы с этой базой давно уже не вместе )