Здравствуйте, уважаемые форумчане!
Вкратце постараюсь описать сложившееся положение (если заинтересует на все вопросы отвечу более детально):
Есть база 11.2.0.4 EE, которая долгое время крутилась у клиента, где нет абсолютно никакого квалифицированного в вопросах ORACLE специалиста, на обычном компьютере (ОС Windows 8.1) в крайне негативной атмосфере постоянных отключений света и перебоев питания.
База не в архив логе, бекапы делаются холодные методом копирования ручками. И с течением времени у них накопилось много блоков с "мягкой" коррупцией CHECKSUM, в основном в индексах.
Было принято стратегическое решение перевести всё это безобразия на новую платформу со стабильным контуром и перевести в архив лог с рмановскими бекапами. Но что бы сделать всё по фэн-шую необходимо избавиться от повреждённых блоков.
Что было сделано:
1. Проверка RMAN и поиск поврежденных блоков и содержащих их сегментов.
2. Пересозданы компоненты, содержащие повреждённые данные (AWR, JAVA и т.д.). Больше всего пострадало SYSAUX, которое было подозрительно маленького размера (вероятно кривая миграция с 10) и без AUTOEXTEND.
3. Пересозданы индексы и таблицы по ноте ID 28814.1

Однако после или до этих манипуляций осталась одна "кривая" таблица. Запрос говорил, что есть повреждённые индексы, однако при попытке их пересоздать, а также при любом обращении к ней (удаление ключей и индексов или их перестроение, analyze table, drop table, rename table и при простом select даже при хинте NO_INDEX) выскакивает данная ошибка:



Вот кусочек alert.log:


Ну и собственно трейс файл тоже не особо показателен:




Нота, указываемая в алерте 411.1 вообще про узлы кластеров и настройки PFILE, а по поиску (траблшутинг по 600 мне недоступен для 11 версии) не выдаёт ничего хоть отдалённо напоминающую мою проблему.

Проблемная таблица содержит отчётные данные и мне ненужна, а вот бизнес-логика на неё ссылается порядочно. Я бы мог её просто пересоздать из старого бекапа, но я абсолютно ничего не могу с ней сделать. В идеале бы как-то избавиться от битых индексов или на худой конец хотя бы просто её грохнуть. Любым способом. Буду рад конструктивным советам.

SY,

Спасибо за дельный совет, буду пробовать. Вариант хороший, если мы не пропустили блоки (validate database check logical как то уж шустро перебирает блоки для детальной проверки) и если datapump не сделает такого обращения к исключённой проблемной таблице, которое вызовет данную ошибку. И ещё, конечно, дико пугает то, что я не могу удалить пользовательскую таблицу в БД.

li_malina,
Вы просто ссылку на бывший металинк дайте, хотя бы номер доки.
Никто базу не пересоздавал - даже с мягкой коррупцией экспорт\импорт в случае неконсистентных данных привёл бы к тяжёлым последствиям. Клиент то с базой работает, причём очень эффективно. А тут я "всё работало, а он сломал" Пока был проведён анализ, исправлены повреждённые блоки путём пересоздания связанных с ними объектов и снята резервная копия для последующих тестов.


Stax, ни alter table ... rename to ... , ни rename ... to ... Эту команду я пробовал одной из первых, как и alter table ... move. Я когда понял чем пахнет, думал, переименую, подложу из бекапа, старую перемещу в новое ТБ и дропну всю ТБ ко всем чертям :)