Случайно перезаписал system.dbf - что теперь?

Question

Случайно перезаписал system.dbf - что теперь?

Я случайно переписал system.dbf в /usr/lib/oracle/xe/oradata/XE/system.dbf

Ну, я на самом деле не сделал это случайно, однако я перезаписал это из-за других сбоев в базе данных.

И когда я пытаюсь запустить следующее:

SQL> shutdown
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  289406976 bytes
Fixed Size                  1258488 bytes
Variable Size              92277768 bytes
Database Buffers          192937984 bytes
Redo Buffers                2932736 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

Теперь я хочу попытаться восстановить базу данных, потому что запуск ее в смонтированном или стандартном режиме точно не работает.

SQL> recover database using backup controlfile;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 1: '/usr/lib/oracle/xe/oradata/XE/system.dbf'
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/usr/lib/oracle/xe/oradata/XE/system.dbf'
ORA-01206: file is not part of this database - wrong database id

Как мне это решить? Это вообще возможно?

Моя "настоящая" проблема заключалась в том, что я запустил конфигурацию /etc/init.d/oracle-xe, и она перезаписала мою старую конфигурацию и, возможно, удалила пароли и тому подобное, поэтому мои таблицы исчезли, однако я нашел mytablespace.dbf, так что я надеюсь, что можно восстановить?

Пожалуйста, пролите немного света на это.

0

database oracle data-recovery disaster-recovery oracle10g

Источник

Filip Ekberg 21 окт '09 в 08:04

2 ответа

Другие вопросы по тегам database oracle data-recovery disaster-recovery oracle10g

Justin Cave 21 окт '09 в 18:32 2009-10-21 18:32 · Answer 1 · 2009-10-21 18:32

У вас есть резервная копия вашей базы данных? Перезапись файлов данных табличного пространства SYSTEM потребует полного восстановления из резервной копии.

3

Источник

Justin Cave 21 окт '09 в 18:32

3molo 13 апр '12 в 19:48 2012-04-13 19:48 · Answer 2 · 2012-04-13 19:48

Поскольку у меня нет опыта работы с Oracle, я вообще не знаю, применимо ли это. Но если файл был открыт процессом, и этот процесс все еще выполняется, вы сможете восстановить его, обратившись к нему в файловой системе /proc.

# ls -l /proc/13646/fd
total 0
lrwx------ 1 root root 64 Apr 13 21:43 0 -> /dev/null
lrwx------ 1 root root 64 Apr 13 21:43 1 -> /dev/null
lrwx------ 1 root root 64 Apr 13 21:43 2 -> /dev/null
lrwx------ 1 root root 64 Apr 13 21:43 3 -> socket:[38094]
l-wx------ 1 root root 64 Apr 13 21:43 4 -> /var/log/openvpn-status-server.log
lrwx------ 1 root root 64 Apr 13 21:43 5 -> /etc/openvpn/ipp.txt
lrwx------ 1 root root 64 Apr 13 21:43 6 -> socket:[38099]
lrwx------ 1 root root 64 Apr 13 21:43 7 -> /dev/net/tun

Давайте удалим один из них!

# rm /var/log/openvpn-status-server.log
# ls /var/log/openvpn-status-server.log
ls: cannot access /var/log/openvpn-status-server.log: No such file or directory

Хорошо, удалил, снова ls:

# ls -l /proc/13646/fd/4 
l-wx------ 1 root root 64 Apr 13 21:43 /proc/13646/fd/4 -> /var/log/openvpn-status-    server.log (deleted)

Там он удален, но все еще удерживается.

# cp /proc/13646/fd/4 myrecover.txt
# ls -l myrecover.txt 
-rw------- 1 root root 359 Apr 13 21:45 myrecover.txt

Конечно же, мой дорогой старый openvpn-status-server.log был восстановлен!