select retention from dba_tablespaces where contents='UNDO';

В общем большого выбора у тебя нет
Или прождать 10 часов, чтоб UNEXPIRED экстенты переехали в EXPIRED (да и в зависимости от версии ты можешь этого и не дождаться из-за багов)
Либо создать новое, перейти на него, а старое потом дропнуть

Естественно, стоит проверить, не выполняется ли у тебя сейчас откат какой-либо длинной транзакции

Кеклик_25Я же базу перегружаю, т.е. чужих транзакций нет.Ну если ты перегрузил когда твой страшный UPDATE еще работал (или уже отработал, но ты не закоммитил его) -- это ведь откатить надо

Кеклик_25откуда взялось 10 часов, если я пытаюсь
задать минимальное время(5мин) для undo_retention? -Ты ведь меняешь уже для новых -- для старых так и осталось то значение, которое было на момент создания

Кеклик_25SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - ProductionНавскидку, здесь уже должно быть номально (явные баги, когда экстент оставался в статусе UNEXPIRED, были полечены еще в 10.2)

Кеклик_25Зачем держать эти экстенты ПОСЛЕ перезагрузки?Да как бы ораклу фиолетово на перезагрузку -- он только темп подчищает (точнее, просто переинициализирует пул)
Зачищать UNDO, SHRINK-ать таблицы и индексы -- слишком много чести. Он даже незакомиченные транзакции лениво откатывает, а что уж говорить об отложенной очистке блоков

авторЛибо создать новое, перейти на него, а старое потом дропнуть
А даст он на новое переключиться?
И тут же вопрос - если даст, то значит ничего там "бесценного" нет и почему Oracle сам не отдает
эти экстенты активным транзакциям, там где они реально нужны?

Я так понял, если сделать PLSQL блок с update в цикле(можно по rowid, bulk...) - это тоже тут не поможет,
так как просто забито UNDO?[/quot]Переключиться даст, тут он помешать не в силах
И, может, даже старое удалить разрешит, хотя оно ему время от времени будет нужно и он будет гневно срать в alert.log
Но со временем забудет
А можно просто подождать с удалением старого

Кеклик_25Да как бы ораклу фиолетово на перезагрузку -- он только темп подчищает (точнее, просто переинициализирует пул)
Зачищать UNDO, SHRINK-ать таблицы и индексы -- слишком много чести. Он даже незакомиченные транзакции лениво откатывает, а что уж говорить об отложенной очистке блоков
Мне это непонятно - я могу переключится на другое UNDO - ведь это значит, что ничего ценного в текущем undo нет.Переключиться -- это не значит потерять старую инфу
Кеклик_25И вместо того чтобы выделить эти эктенты, для активной транзакции, Oracle рубит запрос, роняя приложение.

Кстати, я считал, что undo информация по закомиченным транзакциям может быть перезатерта
даже в нарушение undo_retention - это выходит не так?По идее должна быть и перезатерта
Вот только я подозреваю следующий сценарий:
-- стояло AUTOEXTEND (и 10 часов)
-- увидел, что слишком подросло, отменил AUTOEXTEND и начал играться с UNDO_RETENTION
Вот только те экстенты которые были выделены при AUTOEXTEND имеют жесткую привязку к UNDO_RETENTION на момент создания, в то время как при фиксированном размере UNDO_RETENTION расчитывается автоматически и наверное не столь критично к нарушению
Ну, точнее, это такая гипотеза
Кеклик_25Вроде так было в 7-8i?В 7-8 Automatic Undo Management вообще не было :-)
А вот в 9.2 я натыкался, что UNEXPECTED не освобождались и не переводились в EXPIRED

Кеклик_25авторПереключиться даст, тут он помешать не в силах
И, может, даже старое удалить разрешит, хотя оно ему время от времени будет нужно и он будет гневно срать в alert.log
Но со временем забудет
А можно просто подождать с удалением старого
Спасибо за науку, но тут явный перебор у Oracle.
Дает переключится - значит нет активных транзакций в UNDO... - и значит валом места... - нет же, хранит...
Надо аккуратнее с undo_retention.... А вдруг ты Flashback Query забабахаешь?
И будешь возмущаться -- UNDO_RETENTION еще позволяет, а мне ORA-01555 лезет

Кеклик_25Остался вопрос -
если сделать PLSQL блок с update в цикле с коммитами (можно по rowid, bulk...) - это тоже тут не поможет,
так как просто забито UNDO?
Обычно такие UPDATE в случае проблем разбивают....(но там снапшот ту олд...).Ну дык, если просто нет места в текущем UNDO

Кеклик_25Undo Management не было, но движение экстентов по кругу было, и "закомиченные" undo экстенты,
отдавались активным транзакциям, даже в нарушение UNDO_RETENTION.
Там вообще можно было длинной транзакции прицепить отдельный кусок "undo".
Что сейчас могло бы сработать.
Ты путаешь с rollback-сегментами
Которые вообще ни о каком времени удержания не знали

Нет такой опции для UNDO

Тогда уж
https://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_7003.htm#i2174630 This clause is not valid for temporary or undo tablespaces.

Он именно при NOAUTOEXTEND и работает

Как вариант отключения (точнее изменения алгоритма расчета) -- установить AUTOEXTEND и выставить MAXSIZE в текущий размер. Тогда он будет скакать от UNDO_RETENTION, а при недостатке места пытаться расширить. При достижении MAXSIZE начнет отбирать у UNEXPIRED.
About the Undo Retention Period

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