Сжатие UNDO типичная задача.
Например по какой либо причине хочется уменьшить размер UNDO, благо вроде места свободного в нём полно.
Тем не менее шринк ругается что где-то в свободном месте есть что-то что не даёт как следует шринкнуть табличное пространство.

Самая что ни на есть тривиальная задача.
Главное не наделать глупостей.

Вот правильный алгоритм уменьшения размеров UNDO :
1) смотрим время удержания
show parameter undo_retention
, запоминаем
2) делаем маленький undo_retention (секунд 10)
alter system set undo_retention=10 SCOPE=MEMORY SID='*' ;
3) создаём новое маленькое табличное пространство например UNDO2
делаем его рабочим
alter system set undo_tablespace=UNDO2 SCOPE=BOTH SID='*' ;
4) ждём 10 секунд :-) и останавливаем базу
shutdown immediate ;
5) стартуем БД
6) спокойно и без проблем истребляем старое UNDO
7) возвращаем старое время удержания

На самом деле достаточно просто создать новое маленькое UNDO, сделать его рабочим, перестартовать БД, после чего грохнуть старое UNDO.

Самое сложное в этом процессе договориться с руководством об остановке БД.
Иногда это очень сложно, но лучше это, чем страсти описанные автором темы.

Неоднократно без всяких проблем выполнял подобные действия.
Надеюсь что эта рекомендация предотвратит у начинающих вышеописанные ужасы.

Если бы я это многократно не делал, и не был уверен в том, что это безопасно, я бы поостерёгся такие советы давать. undo_retenshen просто подстраховка, можно его и не менять. Идея состоит в том что старое undo перестанет использоваться по прошествии этого времени, а все новые транзакции будут использовать новое undo.

На самом деле можно не менять undo_retenshen, а просто перестартовать БД (естественно с immediate), а после старта просто удалить старое undo.

C этим алгоритмом у меня проблем не было, а проблема возникла при переводе старого undo в offline normal. БД большая, и решили поосторожничать, не сразу грохнуть старый undo, а подождать, посмотреть может оно кому то нужно. И таки да :-( пошли злобные ругательства на то что данный файл не может быть рид в данный момент от совершенно разных задач, которые никак не связанны с этим undo. Пришлось вернуть в online. Эта опупея мной в другой ветке описана, и как мне в ней подсказали, не я первый наступил на эти грабли.

Кстати, если кто то не согласен с предложенным мной алгоритмом - предложите свой вариант. С удовольствием ознакомлюсь, не исключено что он будет лучше моего. Вперёд коллеги, жду лучшего варианта.

Как не крути, а время от времени с undo приходится сталкиваться. Я рад за тех кто создал undo какого то размера и забыл о нём. И я был бы счастлив если бы у меня была такая ситуация. К сожалению на практике всё несколько иначе. Например в один прекрасный момент к тебе приходит, разработчик или пользователь и говорит что ему надо сделать какой то экзотический запрос и который валится с ошибкой снапшот ту олд. Увеличиваем undo до тех пор? пока проблема не рассосётся (ну конечно сначала смотрим что это за запрос и почему ему нужно столько undo). И так несколько раз. Затем выясняется что работа была разовая и больше undo такого размера в обозримом будущем вам не понадобится, а с местом как назло всё не очень хорошо, а может оказаться что даже совсем плохо. И вот тут возникает желание посжимать всяческие ТП и первый кандидат на это огромный пустой undo. Сценарии могут быть разные, у меня был и такой вариант.

На счёт отсутствия активных сегментов в старом undo.
Вот именно так я и делал - создал новое undo изменил время удержания, проверил что нет активных сегментов и перевёл старое undo в ofline normal. И через некоторое время пощли ошибки что файл старого undo не может быть рид. Пришлось вернуть в online. Более того прошло уже недели 2, мы 2 раза БД перегружали, а попытка перевести старое undo в ofline по прежнему вызывает ошибку.

А вот с алгоритмом описанном мной ни разу никаких проблем не было.

DВА
Ну не надо нас маленьких дурить
А с чем же по вашему связан снапшот ту олд если не с undo? :-)

И ещё, поясните если такой грамотный, почему Oracle ругается на файл переведённого в oofine undo, если у него активных сегментов нет и 0 использованного места?

andrey_anonymousORA-1555 возникает в следствие неудовлетворенной потребности в undo-векторах зафиксированных транзакций.
Потому после штатного (по завершении всех активных транзакций) удаления undo ts могут пострадать только запросы, точка синхронизации которых находится ранее даты фиксации последней транзакции, хранившей свои undo в удаляемом ts.
Ну и ретроспективные запросы (as of scn/timestamp).


И что по вашему мнению это говорит что снапшот ту олд не связан с undo?

Ещё раз утверждаю, что начиная с версии Oracle в которой появилось TS undo, все ошибки типа снапшот ту олд связанны исключительно с размером undo. Бороться с этим можно разными способами - смотреть почему запрос так долго работает что данные устаревают, или просто увеличить размер undo - личное дело конкретного DBA. Далее эту тему я развивать не намерен.

DOMundo_retention если оно не guarantee, принципиально на целостность данных не влияет
Когда вы корректно удалили undo-тп и если совершенно случайно стартанутой до начала манипуляций с андо сессии понадобятся данные из старого андо, или флэшбэк-запрос захочет их увидеть,то получит snapshot too old, если сессия наступит на отложенную очистку блоков, то сочтет транзакции закомиченными.
А вот если вы перевели тп в офлайн, то ядро считает что у вас андо еще на месте и в перечисленных случаях ломанется его читать, на что вы и получите соответствующие ошибки.
Как будет с undo_retention guarantee - не знаю, советую проверить и поделиться )
Скорее всего просто до его истечения не сможете удалить тп.

Вы я вижу не в состоянии понять смысл заданного мной вопроса. То что ядро почему то считает что это файл ему нужен, это и ёжику понятно. Это равносильно утверждению что вода мокрая.
Я спрашиваю почему оно так считает, не смотря на то что всяческие ретеншены давно истекли и нет активных сегментов, при 0 использованного пространства. И главное как с этим бороться.

Если вы не можете ответить на данные вопросы, то не надо флудом заниматься. Я жду конкретных предложений.