Размер базы OEBS R12

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

А есть ли пути сокращения размера БД в OEBS R12?
за 3 года наша база со 100Гб раздулась до террабайта.
а возможности сервера не безграничны.
при этом делается ежедневный инстанс-клон. раньше он выполнялся по штатной ноте (rapid clone R12), т.е. с остановкой и холодным копированием. потом с ростом базы, когда ночные остановки стали слишком большие, перешли на горячее клонирование. Но база-то растёт постоянно, и что будет дальше, пока неясно. Может кто подскажет типичные решения по управлению оебсовой БД, в контексте её разрастающихся размеров. Искал информацию по чистке БД, но кроме стандартных процедур по очистке логов, старых конкарентов и т.п. ничего не нашёл.
Буду благодарен за любую информацию.

Покупайте сервак. Это не ваша забота, а забота бизнеса. :)
Способы уплотнения/очистки данных обычно очень геморойные и с массой ограничений. Знаю по печальному опыту с Навиженом (проект провалился главным образом именно из-за катастрофического роста базы и жоских проблем с её резервированием).

"Нет ножек - нет варенья" (с) анек

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

63,
ну почему - есть purge "функционала", правда он только чистит и не все таблички.
Есть ILM для OEBS ( но почему то у оракла нету ) от НР,ИБМ, ...
http://www.oracle.com/us/partnerships/ds-hp-dbarchiving62-ebs121-final-068346.pdf
http://cm-mitchell.com/ref/optim_brochure_iod.pdf

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

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

63,

наблюдаю клиента, у которого база ебс за 1.5 года прибавила почти 4тб. К сожалению, это вызвано тем, что клиент придерживается мнения "не сломано - не чини", а значит никто со стороны функционала о пурже не задумывается. Есть ещё косяки, вроде стремления хранить какие-то куски вэрхауса в ебс базе, но это уже не так страшно. Основная проблема даже не в физическом хранении и клонировании (снэп клоны вам в помощь), а в том, что ЕБС начинает проявлять нестабильность при очень сильно разросшихся таблицах. Какой бы сервак ни был куплен. Ещё, к примеру, оракл саппорт почти отказывается решать какие-то проблемы с конкаррент реквестами/мэнеджерами, если fnd_concurrent_requests содержит более 500к строк :)

Что есть: целая куча пурж реквестов, вы зря отмахиваетесь от "старых конкарентов", все эти Shipping Purge и прочие (по продуктам) не только хорошо чистят, но и поддерживают производительность на нормальном уровне. Более того, с их помощью вскрываются сироты, недобитки и прочие дети ошибок человеческих и ебсных. Криво закрытые ордеры из 1962 года и т.п. Возьмите документ 752322.1 и начните с него. По некоторым продуктам (GL, к примеру) нет пуржа, но есть возможность архивации и удаления данных. Определите наиболее проблемный продукт (хоть по оунеру из dba_segments) и пляшите оттуда. Как минимум, это даст возможность сдерживать рост. Может у вас вообще нерадивые разработчики устроили версионирование внутри базы и у вас *_bkp_070513 таблиц на терабайт?

Со стороны базы, как уже сказали, партицирование и компрессия. Вот вайтпэйпер http://www.oracle.com/technetwork/database/performance/storageebstwpfeb2011-351602.pdf из личного опыта: 75-гб GL_JE_LINES, партицированная и закомпрессированная по периодам (текущий период оставляется uncompressed для производительности, потом его придётся архивировать), уменьшается до ~20гб. Делается на лету с помощью редефинишна. Это хуже, чем архивация и удаление старых периодов, но хоть как. Производительность после изменения примерно можно оценить при помощи SPA, захватив нагрузку с прода и проиграв на непроде с внесёнными изменениями.

Извините за 3 абзаца, больная тема. Волшебной кнопки "не расти" (ладно уж "не ломайся") у EBS как не было, так и нет, к моему глубокому сожалению.

63
ну даже если так, как это решит проблемы с копированием? ведь проблема, скорее, не в дисковом пространстве, и не в производительности, а в необходимости ежедневного клонирования БД. одно дело лить 50Гб датафайлов, другое дело- террабайт.

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

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

кстати, да.
На эту тему есть интересная штучка на основе ZFS, называется delphix
http://marketing.delphix.com/rs/delphix/images/Delphix Accelerates Oracle EBS Upgrades.pdf

arronax

63, наблюдаю клиента, у которого база ебс за 1.5 года прибавила почти 4тб. К сожалению, это вызвано тем, что клиент придерживается мнения "не сломано - не чини", а значит никто со стороны функционала о пурже не задумывается. Есть ещё косяки, вроде стремления хранить какие-то куски вэрхауса в ебс базе, но это уже не так страшно. Основная проблема даже не в физическом хранении и клонировании (снэп клоны вам в помощь), а в том, что ЕБС начинает проявлять нестабильность при очень сильно разросшихся таблицах. Какой бы сервак ни был куплен. Ещё, к примеру, оракл саппорт почти отказывается решать какие-то проблемы с конкаррент реквестами/мэнеджерами, если fnd_concurrent_requests содержит более 500к строк :) Что есть: целая куча пурж реквестов, вы зря отмахиваетесь от "старых конкарентов", все эти Shipping Purge и прочие (по продуктам) не только хорошо чистят, но и поддерживают производительность на нормальном уровне. Более того, с их помощью вскрываются сироты, недобитки и прочие дети ошибок человеческих и ебсных. Криво закрытые ордеры из 1962 года и т.п. Возьмите документ 752322.1 и начните с него. По некоторым продуктам (GL, к примеру) нет пуржа, но есть возможность архивации и удаления данных. Определите наиболее проблемный продукт (хоть по оунеру из dba_segments) и пляшите оттуда. Как минимум, это даст возможность сдерживать рост. Может у вас вообще нерадивые разработчики устроили версионирование внутри базы и у вас *_bkp_070513 таблиц на терабайт? Со стороны базы, как уже сказали, партицирование и компрессия. Вот вайтпэйпер http://www.oracle.com/technetwork/database/performance/storageebstwpfeb2011-351602.pdf из личного опыта: 75-гб GL_JE_LINES, партицированная и закомпрессированная по периодам (текущий период оставляется uncompressed для производительности, потом его придётся архивировать), уменьшается до ~20гб. Делается на лету с помощью редефинишна. Это хуже, чем архивация и удаление старых периодов, но хоть как. Производительность после изменения примерно можно оценить при помощи SPA, захватив нагрузку с прода и проиграв на непроде с внесёнными изменениями. Извините за 3 абзаца, больная тема. Волшебной кнопки "не расти" (ладно уж "не ломайся") у EBS как не было, так и нет, к моему глубокому сожалению.

arronax, спасибо большое за ценную инфо (для меня)!
по абзацу 1 - стандартные пуржи КР и логов выполняются, fnd_concurrent_requests 140К за 2 недели (период пуржа)
По ноте 752322.1 - отлично, спасибо, похоже то что надо. Начну вникать. Если будут вопросы, можно вас подетальнее поспрашивать?
По поводу GL_JE_LINES, xla_ae_lines, headers и т.п. вы абсолютно правы, эти объекты одни из самых тяжелых, а по поводу возможного версионирования, судя по выборке самых тяжелых сегментов- не наблюдается таковых. Но попытки к организации этого на моей памяти были :)

s_ustinov
а зачем каждый день лить весь террабайт? вы пытаетесь меня уверить, что у вас за день существенно меняется весь террабайт данных? еще раз намекаю - для начала попробуйте найти грамотного ДБА

ну вот ДБА ссылается на официальные документы 406982.1 и 760772.1, согласно которым для клонирования инстанса неважно, менялся ли террабайт или байт данных.
Может он, конечно, не грамотный, но как аргументированно ему указать, что есть более оптимальные пути переноса дневных изменений, с сохранением условия полной идентичности инстансов?

s_ustinov
кстати, да. На эту тему есть интересная штучка на основе ZFS, называется delphix http://marketing.delphix.com/rs/delphix/images/Delphix Accelerates Oracle EBS Upgrades.pdf

насколько я понимаю, это сторонние решения, что-то типа Панайи?
они заточены в основном под миграцию 11->12, всевозможные чистки неиспользуемых объектов, КР и т.п. Возможно я и ошибаюсь.

63,
так по ссылке в статейке ж говорится:
With virtualization technologies, Delphix automates database provisioning and refresh in nonproduction environments by creating
virtual databases that consume less than 1/10th the amount of storage.
Насколько я понял, все как раз для клонирования ебса хорошо подходит - есть большая общая часть у всех экземпляров и небольшие
изменения для каждого в отдельности.
И в этом вот блоге все расписано про дельфикс:
http://dboptimizer.com/