Oracle 10.2.0.5
HP-UX 11.31 IA64

Для согласованного экспорта всей БД (expdp) не хватало места в табличном пространстве UNDO.
Было создано новое тп UNDO_BIG на основе bigfile unlimited extent 100M.
Естественно оно было указано основным и БД была перегружена.

Через некоторое время необходимость в тп UNDO_BIG отпала, к тому же размер его вырос то 2ТБ (почему это произошло мы знаем, и это ожидаемый результат). Было решено вернуться к ранее используемому тп UNDO, а UNDO_BIG удалить.
Снова сделали активным UNDO, и для чистоты эксперимента перегрузили БД (shutdown immediate).
В предыдущих случаях, когда я пересоздавал UNDO табличное пространство, я после старта БД с новым тп UNDO, старое удалял, и никаких проблем не было.
Но в этот раз из осторожности перевели тп UNDO_BIG в ofline normal. И в результате через некоторое время появились ошибки следующего содержания - файл UNDO_BIG.dbf в данный момент не может быть прочитан?? Откуда, почему??!!
Ошибка возникает совершенно в произвольных программных модулях, которые были написаны годы назад, и которые ни как не могут быть напрямую связанны с тп UNDO_BIG.
Запросы показывают что 0 блоков использовано в UNDO_BIG, при этом в нём нет ни одного активного undo сегмента.
Если перевести UNDO_BIG в online ошибка уходит.

При попытке выполнить ресайз UNDO_BIG.dbf, или при попытке изменения размера экстента или просто отмена авторасширения возникает ошибка



Ошибка возникает при попытке изменения любого из этих параметров. При этом как я уже говорил 0 блоков использовано и активных сегментов в нём нет.
Просто удалить UNDO_BIG, после таких приколов, крайне стрёмно, так как чревато восстановлением всей БД из бакапа. А базочка у нас 14ТБ...

У кого есть какие идеи почему что то ссылается на файл UNDO_BIG и как теперь от него избавиться?

VDom, А в ответ тишина ... неужели ни у кого идей нет на этот счёт? :-(

В дополнение к вышеописанному могу добавить что ТП на бигфайле было с Undo Retention Guarantee а время было 36 часов.
После возникновения проблемы Undo Retention Guarantee было отменено а время установили 12 часов.

Давно это время прошло, пробовали опять перевести это ТП в оффлине и опять пошли ошибки.

Пока проблема не решена :-((

chkp Именно это мы и хотели сделать. Но тут задача несколько изменилась. Заказчик купил новые сервера на которые надо срочно прыжками, ещё вчера, перенести БД. Уточняю с HP-UX на Linux x86_64. Главная проблема - нехватка процессорной мощности. В машинке то (Superdom 2) есть ещё неиспользуемые процессоры, но их лицензирование стоит дороже чем купить более новые и более шустрые машинки. Базочка тоже немаленькая 14ТБ. Одним словом предвидятся очень весёлые времена. Переносить думаем с помощью expdp - процедура отлаженная, так как несколько раз приходилось делать тестовые сервера - дубли основной БД. Ну под это дело избавимся заодно и от этого табличного пространства. А уж после переезда мы поиграемся с этим ТП без риска загубить БД.

vva638 Спасибо друг - у нас именно такая же проблема. Я только не понял грохнули они свой TS или нет? Мне тоже приходила в голову такая идея, и до этого я именно так и поступал, но тут уж очень БД большая и страшно на ней эксперименты ставить.