0

I accidentally overwrote system.dbf in /usr/lib/oracle/xe/oradata/XE/system.dbf

Well I did not actually do it accidentally, however I overwrote it because of other failures in the database.

And when I try running the following:

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

Now I want to try to Recover the database because starting it in mounted or standard surely doesn't work.

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

How do I solve this? Is it even possible?

My "real" problem was that I ran the /etc/init.d/oracle-xe configure and it overwrote my old configuration and probably removed passwords and such so my tables were gone, however I found the mytablespace.dbf so I hope that it is possible to recover?

Please shed some light on this.

Improve this question

2 Answers 2

Reset to default
3

Do you have a backup of your database? Overwriting the SYSTEM tablespace data files would necessitate a complete restore from backup.

Improve this answer
2
  • No I did not have a Backup. However using dbviewer solved the problem, i extracted everything and just re-created it. ;)
    – Filip Ekberg
    Oct 22, 2009 at 8:58
  • 2
    That doesn't make sense. The database is not open-- it is not possible for any tool to read data from it (other than a couple of very expensive tools that extract data from the underlying data files). Do you have multiple databases on the machine? So perhaps you overwrote the SYSTEM data file on one database and are reading data from a second database?
    – Justin Cave
    Oct 22, 2009 at 13:27
1

As I have no experience of Oracle, I don't know at all if this applies. But if the file was opened by a process, and that process is still running, you would be able to recover it by accessing it in the /proc filesystem. 

# 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

Lets remove one of them!

# 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

Ok, removed, ls again:

# 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)

There it is, deleted but still held.

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

Sure enough, my dear old openvpn-status-server.log was recovered!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .