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

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

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

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

arronax63,

наблюдаю клиента, у которого база ебс за 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, всевозможные чистки неиспользуемых объектов, КР и т.п. Возможно я и ошибаюсь.