Зравствуйте

ОС: Linux RHEL 3 Update 4

Старое UNDOTBS сильно разрослось. Т.к. оно состояло из 9 файлов по 2 гига (а реально нужно только 4 гига что понял в процессе мониторинга) решил создать новое а старое грохнуть.

Было создано новое UNDOTBS (старое называлось UNDOTBS1). Сделал его активным. После этого попытался убить старое но в результате нарвался на ошибку о том что оно ещё используется.
Сделал

Прождал время UNDO_RETENTION но всё равно не давало удалить старое...

В связи с этим попытался перевести это старое табличное пространство в офлайн. Не получилось...Тогда решил попробывать переводить пофайлово...два файла перевелись...после чего начались проблемы. Перевелись эти файлы офлайн коряво (переводил к сожалению с помощью OEM) и получилось что сессии ОЕМ-а остались а из самого ОЕМ-а выбросило...и часть файлов перевело а часть нет...Причём обратно в онлайн вернуть переведённые файлы не удавалось.....После этого начались плодиться сессии с пустым юзером а у сессии от ОЕМ постоянно увеличивался serial# в представлении v$session...Её даже засечь нельзя было чтоб кильнуть...В результате получилось что количество сесии достигло порога и в базу можно было подконектиться только как sysdba из под консоли...Пытался отстреливать эти "новоявленные" сессии но оракл их ставил как-бы в очередь на отстрел и реально ни одну не отстрелил. Они как бы ждали доступа к предидущему undotbs1, в частности - к этим вот офлайновым файлым.

После всяких тщетных попыток оставалось только одно - тушить базу....Перед этим пытался сделать rman-ом полный бэкап.....Не получилось, выдавало "Segmentation failed" (по-моему так....)....на многие запросы даже к системным представлениям выпадали ошибки рекурсивного SQL и прочей лажи.....Потушил лисенер в надежде что некоторые соединения отваляться и всё-таки отпустит старый undo.....Оказалось что все соединения внутренние и ничего не отвалилось....Стал на свой страх и риск перезапускать базу...На иммедиат не тушилось (ну понятно...хочет же откатить транзакции....) - пришлось делать аборт. База перезапустилась....при этом ролбэксегменты предидущего undo пометила как требующие востановления...

Удалять этот UNDO всё равно не давало! пришлось перезапукать инстанс и прописывать в файл параметров инициализации следующее:


После чего всё-таки дало удалить бывшее undo_tablespace....Если убрать эти параметры после удаления и рестартануть то база при открытии обваливается....Поэтому параметры пока оставил.

Но теперь ещё осталась проблема следующего характера:

Причём undo segment 2 и undo segment 6 принадлежали предидущему (старом UBDOTBS1) и были уже удаленны...Но почему-то оракл всё-таки пытается их востанавливать...хотя и прописаны они в _OFFLINE_ROLLBACK_SEGMENTS

Почитал чуть-чуть и решил добавить ещё в инит.ора ещё:

и рестартануть базу.

Рестартанул. Но всё равно:
Хотя ora-600 покаместь не видно.

При этом id сегментов нового undotbs начинаются с 11 и в системных представлениях этих сегментов не видно! Их даже не получиться убить потому что их не видно...а SMON их видит:

Сорри, забыл сказать самое главное:

ПОМОГИТЕ ПЛИЗ!!!!!!

Спасибо, Ааз, что откликнулся :) В какой раз меня уже спасаешь!

авторЕсли в ARCHIVELOG, то

База в архивлогах....но в связи с тем что в последние несколько дней катастрофически не хватало места - эти архивлоги чистились.. каждые 10 минут...была временная мера..ввиду этого и за undo взялся...нужно было освободить место. Каждый день делается RMAN-вский бэкап (вернее раз в месяц полный, раз в неделю инкрементальный, и каждый день над ним ещё одного уровня...)...Но и полный почистили ввиду нехватки места!!!
(база 300 гиг)...надеюсь ты не плюнешь от злости и всё-таки будешь со мной дальше разговаривать....я сейчас уже перед таким фактом!!! Не думал я что будут такие проблемы с пересозданием undo иначе полюбэ сделал бы бэкап :(

1. _corrupted и _offline убери
2. Смонтируй БД
3. Файлы UNDOTBS1 переведи в online (file#,status from v$datafile)

эх...их и тогда не получалось перевести в онлайн ....ту-ту уже эти файлы!! понимаешь...про них база уже забыла думать!!! и про это табличное пространство!! оно было удалено!!! Нигде ни про эти сегменты ни про это бывшее табличное пространство инфы уже нету!!!!!! Ни в одном системном представлении!! Всё облазил!!! И табличное пространство и сегменты удалены! А SMON почему-то про них помнит...

>4. Выполни recover database

не получится :(

Vadim_Maximov, со всем уважением и пониманием происходящего....но не могу...

База 300 гиг...в продакшене.... (даже за 2 суток не уверен что перекинусь), с утра в понедельникс ней придут пользователи и будут хотеть работать...За простой меня кастрируют через повешанье :-(

Итак из-за shutdown abort все задания которые оставили выполнять на выходные отвалились :-(

Всё-таки надеюсь что может быть кто-нить подскажет как сказать SMON-у забыть про старый удалённый tablespace и как-то разрешить этот конфликт...понимаю что это тяжко в связи с тем что в системных представлениях глухо...но...а вдруг....

Ааз Сначала бы открыться. Ты бы еще job'ы пока тормознул и aq_ фсякое. Будут под ногами путаться


Ааз....базу открыл...всё нормально!!! С ней можно работать!!! Старый undo она сама снесла через команду drop после открытия (но в этот момент чтобы открыться был выставлен OFFLINE_ROLLBACK_SEGMENTS, но не был выставлен _corrupted_rollback_segments )....База с этим параметром открылась!! Даже после шутдаун аборт!! Потому как использовала уже новый undotbs и прождал период undoretention....А когда она открылась только тогда я уже попытался снести старый undo через команду drop!!! Удалилось старое UNDOTBS1....но всё время вспоминает про два сегмента из этого старого таблспейса который сама же и удалила!!! Вот в чём проблема....Как бы сделать чтобы оракля про них забыли??? Непонятно почему они от них чего-то хотят....

авторevent = '10510 trace name context forever, level 10'
event = '10511 trace name context forever, level 10'
event = '10512 trace name context forever, level 10'

А вот это что такое, можешь объяснить?

а вот это

автор_OFFLINE_ROLLBACK_SEGMENTS=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)

._corrupted_rollback_segments = (_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)

убирать там же???

З.Ы. Джобы уже до этого отключил...

пусто...нет у меня распределённых транзакций


АазУ тебя как эта проблема проявляется? Job какой падает, или экземпляр ложиться? Поскольку простанство в offline передавать тебе не давали (перед shutdown abort), то были активные транзакции. Че не посмотрел-то? А теперь всю базу перекапывать, блинк.У тебя как эта проблема проявляется? Job какой падает, или экземпляр ложиться? Поскольку простанство в offline передавать тебе не давали (перед shutdown abort), то были активные транзакции. Че не посмотрел-то? А теперь всю базу перекапывать, блинк.

Проблема проявляется в следующем:
1) без указания параметра _OFFLINE_ROLLBACK_SEGMENTS база подымается и сразу же падает.
2) без указания параметра ._corrupted_rollback_segments каждые пол-часа в алерт идёт крик о


посмотрел трассировочный файл,покопался в базе и нашёл что это запускается job quest-овского продукта который собирает статистику...все джобы выключил - больше эта ошибка пока не повторялась. Но и параметр пока не убирал

3) вне зависимости от всяких параметров постоянно, каждые 5 минут (интересно...может это smon каждые 5 мин запускается...потому как job-ы все отключены) валиться в алерт сообщение:


хотелось бы от них избавиться...


Насчёт активных транзакций:

я в самом первом сообщении описал как всё произошло (OEM поучавствовал)...И я начал с того OEM-ом стал переводит файлы поочереди в оффлайн...тоесть если он уже не нужен этот файл для активных транзакций - тогда его отпустит...Вот и наотпускало....в результате сессии забились (тоесть каким-то чудом резко наплодилось много сессий с пустым юзеров в поле username в представлении V$session), подключиться кроме как с консоли "/as sysdba" просто не получалось....поле serial# у сессии от OEM-ма изменялось в сторону увелечения каждые 5 секунд...shutdown abort делал не потому что хотелось..чест слово...а потому что сессии забились...и не одна не откатывалась...ни одна ни килялась...даже когда лисенер потушил перед тем как аборт делать...думал может всё-таки попустит и хоть что-то да отвалиться...нет...все ждали чего-то от этого анду который при попытке перевода с помощью OEM его датафайлов в офлайн встал в непонятную позу...поэтому смотрел бы я или не смотрел...всё равно я ничего сделать не мог!!! база ни на что не реагировала...даже на кил сессион...на половину запросов от сиса выдавало ошибку рекурсивного sql

АазНаташа, привет
nata1111В итоге сейчас задача - заставить забыть оракл о существовании этих ролбэков - путем установки event пока ничего не получается - SMON честно каждые 5 минут вспоминает о них.
Я бы проверил:
1. Видны ли несуществующие undo DBA_ROLLBACK_SEGMENTS
Всего

Так в том то и дело что нет их там!!! Вот в чём проблема!!! Я про что и рассказаваю - НИ В ОДНОМ СИСТЕМНОМ ПРЕДСТАВЛЕНИИ НЕТ!!! А ТАК БЫ Я ИХ СНЁС И ЖИЛ СПОКОЙНО

stdio PartosКак бы сделать чтобы оракля про них забыли???Пересоздать базу

я тока ЗА!! Но.....

stdio
PartosНепонятно почему они от них чего-то хотят....Восстановить из UNDO тебе чего-то хотят.


Так а что востановить??? И откуда??? Если база сама же и грохнула это UNDOTBS1 после открытия базы!!!!!!!!!!!!!!!!!! Undoretention прошло на момент abort!! И использовалось совсем другое undo (новое) всё это время...Благодаря этому и поднялась база....

stdio
[quot nata1111]Undo пересоздан - единственная проблема осталась именно с SMON'ом,
который пенриодически пытается восстановить не подлежащий восстановлению ролбэк Это как?
[quot stdio]

Слюшай!! Я тебя очень уважаю!! Но нельзя ж быть таки непонятливым: Ната повторила такую же ситуацию как у меня и у нас обоих НИ В ОДНОМ !!!системном представлении нет упоминания про старые RBS....НУ КАК ИХ ТОГДА МОЖНО ВОСТАНОВИТЬ ЕСЛИ ИХ УЖЕ НЕТУ??? ЕСЛИ БАЗА САМА ИХ СНЕСЛА!

Пардон!

undo$ -единственное место где я действительно нашёл инфу обо всех (в том числе и о бывших и удалённых) RBS!!!!!

При этом у тех rBS на которые матюкается -статус "5", у удалённых статус "3", остальные, которые боевые - статус "1".

Вот чешуться ручки подправить им статус :)

Люди, как думаете, стоит? Ведь всё-таки словарь!!

Прикладываю результат запроса к undo$