Доброго дня коллеги,

Oracle 12c EE
Physical Standby (хотя в данном случае, вряд ли имеет значение)

Такая ситуация: ребята запустили скрипт пересоздания схемы... Его нужно было запускать под тем же пользователем, т.к. он просто удаляет таблицы, а потом их создает заново, но скрипт запустили под SYSTEM. В общем скрипт удалил кучу таблиц, вьюх и всего остального в SYSTEM. База данных в этом режиме работает 4 дня. Ничего страшного в лог не пишет. Это хорошо, по крайней мере она работает. А теперь то, что плохо: нет возможности сделать expdp, т.к. используются объекты (таблицы, вьюхи) которых нет... Экспорт хотел сделать чтобы пересоздать БД и потом импортнуть пользовательские данные туда, но не получается такой подход.

Буду очень рад любому дельному совету, как спасти ситуацию.

maverick2104WillIm,

Скрипт вручную запустили на стандбае ?

Какой размер базы ?

Не, на стэндбае ничего не запускали, стэндбай накатил архивные логи, ну и соответственно тоже "больной". Размер базы не большой, ~10Гб.

Update

После некоторого анализа удалось выяснить, что из всех таблиц в SYSTEM, скрипт сумел удалить только 5. В них содержится уникальная информация, поэтому перетянуть их с другой БД не вариант. Было решено восстановить бэкап (сделаный до происществия) на другой сервер и вытащить оттуда эти 5 таблиц. Foreign Keys у таблиц только между собой, поэтому сложностей с записями не будет. Список таблиц:


Все остальные отсутствующие объекты будут созданы. Посмотрим что из этого получится.
Также был создан SR. Первое что сказал инженер - "удаление системных объектов - это unsupported case", однако запросил детали по схемам и объектам для анализа. Но на форумах писали, что похожий случай закончился тем, что support предложил восстановить БД из бэкапа и точка. Там правда вся схема system отсутствовала...

IgorSmА FLASHBACK от шаловливых не настроен?
Настроен, но только 24 часа, а заметили 4 дня спустя.

Update + solution

И снова доброго дня!

Спасибо всем, за советы, пригодились!

Ситуацию решил, буду предельно краток для экономии времени, опишу сам подход.

Доп информация к первому посту:
При детальном анализе выснил, что по какой-то причине скрипт не смог удалить много объектов (честно говоря, так и не понял почему, т.к. при поытки симуляуции ситуации удалялось намного больше объектов, чем в оригинале)
Единственные удаленные объекты это 5 таблиц:



Итак, план решения:
1) Воспроизвести ситуцаию на другом сервере - server1.
2) Разрешить ситуацию путем: 1) восстановления бэкапа базы (сделанного до запуска скрипта) на server2, 2) копирования потерянных таблиц с данными (данные в таблицах оказались статическими)
3) Повторить решение на Prod Standby. (разрываем связь с Primary, делаем Restore Point, открывает Standby в RW режиме (activate standby), экспирементируем, возвращаемся к Restore Point, синхронизируем с Primary)
4) Применить решение на Prod Primary.

После восстановления таблиц, 185 из 195 инвалидных объектов удалось рекомпиллировать. Остальные 10 (views и synonyms) пересоздал предварительно отыскав в скриптах в $ORACLE_HOME/rdbms/admin.
На этом все!

К извечному вопросу об использовании SYS и SYSTEM для повседневных задач... Теперь все админы используют специально созданный аккаунт с ролью DBA. Если бы подобное предложение было принято двумя годами раньше, сразу после его озвучки, такой ситуации удалось бы избежать. Этой ситуации также можно было бы избежать, если бы админ взглянул что делает скрипт вендора, но он не взглянул, т.к. срипт назывался create_export_schema.sql, что звучит как звучит )) - "создание схемы". Для создания схемы нужны привилегии DBA, коими SYSTEM очень даже обладает, поэтому скрипт был живо запущен под привычнам для таких дел пользователем - SYSTEM. В реале же срипт вовсе не создает пользователя, а просто удаляет все его объекты и создает новые, запускаться должен был под уже созданным пользователем. В общем, целая цепочка факторов привела к такой ситуации.

Еще раз всем неравнодушным спасибо и пусть наш кейс останется хорошей историей без повторений.