|
как бы жрать меньше UNDO?
|
||
|---|---|---|
Участник
Откуда: Middlebury, CT USA
Сообщения: 10 588 |
||
| 10.09.2016, 15:27:23 |
|
|
|
|
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
есть процедура меняющая дохрена данных (допустим, 2 млн записей) если произошла ошибка - надо откатить всё проблема в том, что если не коммитить, будет плохо с UNDO есть какие варианты выкрутиться из этой ситуации ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 11:09:30 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
grok, менять обратно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 11:47:56 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
grokесть какие варианты выкрутиться из этой ситуации ? Засунуть ещё один диск в дисковую полку. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 12:25:28 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
grokесли не коммитить Не секрет, что роллбэк нужно делать по-реже, Нужно делать по-чаще коммит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 14:48:10 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
проходил мимо...Нужно делать по-чаще коммит. Ага, особенно когда "если произошла ошибка - надо откатить всё" или когда другие сессии выдают долгоиграющие селекты из изменяемой таблицы . SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 15:27:23 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
1. Постараться писать так, чтобы ошибок все-таки не было или только если совсем попа типа диск/сеть отвались. 2. Смотря какой характер носит сама обработка данных и насколько действительно большие объемы, но например как вариант: попытаться новые данные писать в отдельную патицию или временную таблицу, если вылезла ошибка, то дропаем патицию или транкейтим темповую таблицу. В общем смотря что делает процедура ), если ошибок не вылезло, то при необходимости кладем "хорошие" данные в рабочие таблицы. Понятно, что двойная работа и совсем негуд, если таблиц в обработке много, зато быстрый "откат" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 17:54:51 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Я пробовал такой вариант: завести 2 undo и переключать на время тяжёлой транзакции на запасной, а потом возвращать обратно, чтобы другие транзакции не споткнулись. ......оракл при таких динамических переключениях undo глючил, зараза, не по детски. В общем, не завелось, на 11.2.0.4, по крайней мере. Другой вариант в близком направлении - олдскульное ручное управление роллбэк сегментами вместо автоматического undo. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2016, 22:36:04 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
И как это поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2016, 04:56:16 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Это защищает сторонние транзакции от переполнения undo. Если сессия с очень большим размером транзакции не вписалась в имеющееся дисковое пространство, отведённое под undo, то она сама себе злобное буратино. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2016, 17:00:17 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Nobody1111Это защищает сторонние транзакции от переполнения undo.Как? Тем более, что:Nobody1111Если сессия с очень большим размером транзакции не вписалась в имеющееся дисковое пространство, отведённое под undo, то она сама себе злобное буратино. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 01:31:01 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровNobody1111Это защищает сторонние транзакции от переполнения undo.Как? Тем более, что:Nobody1111Если сессия с очень большим размером транзакции не вписалась в имеющееся дисковое пространство, отведённое под undo, то она сама себе злобное буратино. Ключевое слово - сторонние. Если некая сессия запустила транзакцию размером 100500 Gb, то остальные не виноваты и по возможности не должны испытывать проблем. 123ййSY, Нужно делать почаще коммит Он, возможно, не в курсе, что был в свое время мультфильм с очень популярной песенкой: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 10:53:27 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
SYпроходил мимо...Нужно делать по-чаще коммит. Ага, особенно когда "если произошла ошибка - надо откатить всё" или когда другие сессии выдают долгоиграющие селекты из изменяемой таблицы . Ну про сценарии загрузки - все вроде понятно, надо так или иначе помечать вливаемые данные и по необходимости удалять. Варианты: - грузим в отдельную табличку, при успехе - exchange partition с целевой, при неудаче - truncate - грузим с fk на запись о задании, выборка данных - join с заданием в статусе "успех", зачистка - неспешный delete. А вот в сценарии "меняет много данных" (с кучей update во многих таблицах) - то можно лишь по возможности разделить большую транзакцию на целостные куски и выполнять по частям. В биллинге, к примеру, можно оперировать группами лицевых счетов. Из паллиативов - можно попробовать отключить ненужные данной конкретной мегатранзакции индексы на задействованных таблицах, пересмотреть используемые update на тему исключения ненужных (необязательных) set a=..., заменить delete на update set del_flag='Y' (включить в PK), само удаление выполнить отдельной транзакцией по факту успеха первой. Ну и так далее в общем направлении - избегать лишних модификаций, делить на части, фиксировать промежуточные непротиворечивые итоги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 13:09:54 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Nobody1111Вячеслав Любомудровпропущено... Как? Тем более, что:пропущено... Ключевое слово - сторонние. Если некая сессия запустила транзакцию размером 100500 Gb, то остальные не виноваты и по возможности не должны испытывать проблем. вах шайтан!!1 взломал ядро оакл и научился выделять для каждой сессии свое андо ??! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 13:28:44 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Nobody0000вах шайтан!!1 взломал ядро оакл и научился выделять для каждой сессии свое андо ??! Ну, положим, ломать для этого ничего не надо - ядро не просто умеет назначать сессии сегмент отката, но предоставляет штатную рукоятку для этого: Код: plsql 1. Более того, во времена, когда трава была зеленее... Короче, когда вместо слова UNDO ораклоиды пользовались буквосочетанием RBS - таки рекомендовалось иметь один-два больших сегмента отката для толстых транзакций, назначаемых посредством set transaction. В современных версиях для этого пришлось бы отключить automatic undo management, но сам функционал-то никуда не делся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 13:37:25 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Еще раз спрошу -- зачем? От ORA-01555 это никак не спасает Транзакция, сколько бы она UNDO не просила, запускается не от скуки, а чтоб все-таки отработать. Поэтому как не вертись, место в UNDO ей и остальным предоставить все равно надо. Единственный разумный довод -- держать этот сегмент в отдельном ТП, которое можно будет по завершению грохнуть. Но если это действо на регулярной основе, то придется повторять это постоянно (новое ТП, отдельный сегмент, дропнуть ТП) -- не проще уж предоставить сразу достаточно места. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 13:48:02 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЕще раз спрошу -- зачем? От ORA-01555 это никак не спасает Сегодня - "низачем". Когда-то было полезно. Избавляло не от 1555, а от исчерпания места в rbs. И не в ТП rbs-ы лежали, не в ТП... ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 13:54:02 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Ога, в воздухе болтались ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 14:19:28 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЕще раз спрошу -- зачем? От ORA-01555 это никак не спасает Транзакция, сколько бы она UNDO не просила, запускается не от скуки, а чтоб все-таки отработать. Поэтому как не вертись, место в UNDO ей и остальным предоставить все равно надо. Единственный разумный довод -- держать этот сегмент в отдельном ТП, которое можно будет по завершению грохнуть. Но если это действо на регулярной основе, то придется повторять это постоянно (новое ТП, отдельный сегмент, дропнуть ТП) -- не проще уж предоставить сразу достаточно места. Спасает другие сессии, выполняющие свои транзакции DML, от ORA-30036. Однако топикстартер не обозначил ошибку ORA-, с которой он хочет бороться в ситуации, когда большая транзакция должна откатиться. И не обязательно сегмент, можно alter system set undo_tablespace=<резервное анду> при автоматическом undo_management. Правда, глючит это, я уже писал. А от ORA-1555 при таком варианте помогло бы undo_retention иметь индивидуальный для каждого undo ТП, а не общесистемный. Но этого нет (или пока нет). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 14:52:01 |
|
||
|
как бы жрать меньше UNDO?
|
|||
|---|---|---|---|
|
#18+
Nobody1111А от ORA-1555 при таком варианте помогло бы undo_retention иметь индивидуальный для каждого undo ТП, а не общесистемный. Но этого нет (или пока нет).Вот, именно этого я и ждал (просто раньше был распространен миф, что отдельный большой ROLLBACK-сегмент для длительной транзакции помогает от 1555). Теперь расскажи, чем помогло бы индивидуальное UNDO_RETENTION ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2016, 14:59:35 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=39307089&tid=1887479]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
33ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 194ms |
| total: | 291ms |
| 0 / 0 |
