|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
Здравствуйте А есть ли пути сокращения размера БД в OEBS R12? за 3 года наша база со 100Гб раздулась до террабайта. а возможности сервера не безграничны. при этом делается ежедневный инстанс-клон. раньше он выполнялся по штатной ноте (rapid clone R12), т.е. с остановкой и холодным копированием. потом с ростом базы, когда ночные остановки стали слишком большие, перешли на горячее клонирование. Но база-то растёт постоянно, и что будет дальше, пока неясно. Может кто подскажет типичные решения по управлению оебсовой БД, в контексте её разрастающихся размеров. Искал информацию по чистке БД, но кроме стандартных процедур по очистке логов, старых конкарентов и т.п. ничего не нашёл. Буду благодарен за любую информацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2013, 09:57 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
Покупайте сервак. Это не ваша забота, а забота бизнеса. :) Способы уплотнения/очистки данных обычно очень геморойные и с массой ограничений. Знаю по печальному опыту с Навиженом (проект провалился главным образом именно из-за катастрофического роста базы и жоских проблем с её резервированием). "Нет ножек - нет варенья" (с) анек ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2013, 10:11 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
63, со 100 гиг до террабайта за 3 года - это вообще мелочь. Наймите нормального ДБА (можно даже не в штати, а чтобы работал время от времени) - и он решит все проблемы. Стоимость дисков сейчас - копейки. И новый сервер скорее всего не нужен. Просто грамотно сделать сегментацию больших табличек (по датам) - и все будет нормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2013, 10:34 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2013, 17:47 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
s_ustinov63, со 100 гиг до террабайта за 3 года - это вообще мелочь. Наймите нормального ДБА (можно даже не в штати, а чтобы работал время от времени) - и он решит все проблемы. Стоимость дисков сейчас - копейки. И новый сервер скорее всего не нужен. Просто грамотно сделать сегментацию больших табличек (по датам) - и все будет нормально. секционировать стандартные оебсовые таблицы? ну даже если так, как это решит проблемы с копированием? ведь проблема, скорее, не в дисковом пространстве, и не в производительности, а в необходимости ежедневного клонирования БД. одно дело лить 50Гб датафайлов, другое дело- террабайт. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2013, 15:43 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
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 как не было, так и нет, к моему глубокому сожалению. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2013, 19:07 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
63ну даже если так, как это решит проблемы с копированием? ведь проблема, скорее, не в дисковом пространстве, и не в производительности, а в необходимости ежедневного клонирования БД. одно дело лить 50Гб датафайлов, другое дело- террабайт. я чего то не понимаю - а зачем каждый день лить весь террабайт? вы пытаетесь меня уверить, что у вас за день существенно меняется весь террабайт данных? еще раз намекаю - для начала попробуйте найти грамотного ДБА. и только потом начинайте думать о новых серверах и чистке базы, так как это более сложные операции и в любом случае при их выполнении крайне желательно присутствие грамотного специалиста. то есть от поисков ДБА вам никуда не деться :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.07.2013, 01:22 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
кстати, да. На эту тему есть интересная штучка на основе ZFS, называется delphix http://marketing.delphix.com/rs/delphix/images/Delphix Accelerates Oracle EBS Upgrades.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
07.07.2013, 12:02 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
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, всевозможные чистки неиспользуемых объектов, КР и т.п. Возможно я и ошибаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2013, 16:37 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
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/ ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2013, 11:07 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
Нужно сначала определить что занимает много места Зачем пуржить все подряд, если дело возможно в 3 или 5 таблицах ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2013, 11:27 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
63Здравствуйте А есть ли пути сокращения размера БД в OEBS R12? за 3 года наша база со 100Гб раздулась до террабайта. а возможности сервера не безграничны. Грамотно секционируйте пару тройку самых "тяжелых" таблиц. Не ошибайтесь - секционирование таблицы делают только раз. Надо выбрать ключ секционирования так "чтобы не было ни мучительно больно и обидно" второй попытки не будет. С развитием базы ко-во секций должно увеличиваться - старые секции должны становиться не нужны, уходить в "тень". В таком случае их можно будет постоянно архивировать и архивировать. XLA_AE_LINES можно секционировать по AE_HEADER_ID или ACCOUNTING_DATE (по годам или даже по кварталам). Но не по APPLICATION_ID, CURRENCY_CODE, LEDGER_ID - т.к. такие секции и дают малый выигрыш и будут точно также расти как и таблица в целом и оставаться используемыми, поэтому архивировать их и не станете. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2013, 15:24 |
|
Размер базы OEBS R12
|
|||
---|---|---|---|
#18+
63секционировать стандартные оебсовые таблицы? ну даже если так, как это решит проблемы с копированием? ведь проблема, скорее, не в дисковом пространстве, и не в производительности, а в необходимости ежедневного клонирования БД. одно дело лить 50Гб датафайлов, другое дело- террабайт. Инкрементальный бэкап. Не надо будет "копировать" и вообще трогать старые заархивированные секции - поскольку в 99.9% случаев никаких изменения со вчерашнего дня в них НЕ произойдет. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2013, 15:30 |
|
|
start [/forum/topic.php?fid=29&msg=38322586&tid=1525990]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
167ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 291ms |
0 / 0 |