restore 9i from oradata contents only?

[elnonio]

Can a 9i database be restored when the only files available are what was in ./oradata/<SID> ?

Thanks,

A. Contreras

 

[SantaMufasa]

A.,

Dunno yet. First you must explain the nature of your need to "restore" your database. Did you have a media failure that requires a restore? Did you accidentally drop objects that you need to restore? Did something else happen that compels you to restore your database?

And additionally, there is a very big difference between a database restore (going back to a consistent point in time when the last full backup occurred) and a recovery (bringing a database current to either a previous point in time or to the present).

Let us know more, and we can give you more advice.

Mufasa
(aka Dave of Sandy, Utah, USA)

http://www.dasages.com

@ 19:58 (21Dec04) UTC (aka "GMT" and "Zulu"),
@ 12:58 (21Dec04) Mountain Time

 

[elnonio]

First of, I should point out that I haven't dealt with databases since I last installed this server (about 1.5 years ago) and I no longer work in IT.

At any rate, the server on which the database resided was compromised. The only data I was able to copy before it became totally unresponsive was the contents of oradata. That is all I have left from the database side.

I have recreated the server, including a fully functional clone of the database structure, on the same box. I am now trying to use the files to recover the data and database structure.

The default structure looks like this:
-rw-rw---- 1 oracle oinstall 1613824 Dec 21 15:10 control01.ctl
-rw-rw---- 1 oracle oinstall 1613824 Dec 21 15:10 control02.ctl
-rw-rw---- 1 oracle oinstall 1613824 Dec 21 15:10 control03.ctl
drwxr-xr-x 2 oracle oinstall 4096 Dec 21 14:10 currel2
-rw-rw-r-- 1 oracle oinstall 20979712 Dec 21 14:15 cwmlite01.dbf
-rw-rw-r-- 1 oracle oinstall 20979712 Dec 21 14:15 drsys01.dbf
-rw-rw-r-- 1 oracle oinstall 144842752 Dec 21 14:15 example01.dbf
-rw-rw-r-- 1 oracle oinstall 26222592 Dec 21 14:15 indx01.dbf
-rw-rw-r-- 1 oracle oinstall 20979712 Dec 21 14:15 odm01.dbf
drwxr-xr-x 2 oracle oinstall 4096 Dec 20 18:22 orig
-rw-rw---- 1 oracle oinstall 104858112 Dec 21 14:13 redo01.log
-rw-rw---- 1 oracle oinstall 104858112 Dec 21 14:13 redo02.log
-rw-rw---- 1 oracle oinstall 104858112 Dec 21 14:15 redo03.log
-rw-rw-r-- 1 oracle oinstall 345833472 Dec 21 14:17 system01.dbf
-rw-rw-r-- 1 oracle oinstall 41951232 Dec 20 18:54 temp01.dbf
-rw-rw-r-- 1 oracle oinstall 10493952 Dec 21 14:15 tools01.dbf
-rw-rw-r-- 1 oracle oinstall 209723392 Dec 21 14:15 undotbs01.dbf
-rw-rw-r-- 1 oracle oinstall 26222592 Dec 21 14:15 users01.dbf
-rw-rw-r-- 1 oracle oinstall 39985152 Dec 21 14:15 xdb01.dbf

In the orig directory I copied the default files, and in the currel2 I copied over the files I was able to save.

The currel2 and the orig directories look identical in terms of the files that are in them, so it looks like I left OUI create a standard database with all the default values.

If I just copy over the system01.dbf file, the database won't start, it complains the file is not the right one.
If I also copy over the 3 .ctl files, it goes further but then complains about the password files (ORA-1991).

If I recreate the password file using orapwd, I get right back to square one:

ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/usr/oracle/oraInventory/oradata/currel2/system01.dbf'
ORA-01200: actual file size of 42215 is smaller than correct size of 42240
blocks

That's where I am stuck right now.

 

[elnonio]

Dave,

I have not been able to get past this last issue. I appreciate your taking time to help me out.

Thanks,

Antonio

 

[SantaMufasa]

Antonio,

Do you have a recent full, consistent backup of your database? Is your database in ARCHIVELOG mode?

The error message you received earlier indicates that at least your SYSTEM tablespace datafile has problems. That is not a good sign. So the answers to my above questions are key. Your success in getting your database back up and running is at least a full backup that you can start with. If your database in in ARCHIVELOG mode and if you have all of your archive redo log files to the present time, then we should be able to recover your database to the most recently committed transaction. If you are not in ARCHIVELOG mode, then you can at least get your database going to the point in time that you took your last full backup.

I will be out for the next couple of hours, so I can help you again at about 2 A.M. GMT.

Mufasa
(aka Dave of Sandy, Utah, USA)

http://www.dasages.com

@ 23:36 (21Dec04) UTC (aka "GMT" and "Zulu"),
@ 16:36 (21Dec04) Mountain Time

 

[elnonio]

No, all I have left is the oradata directory. Really So no, there is no full backup to work with.

As far as I know, the database was not in archivelog mode.

Is it possible to modify system01.dbf, through some tool or another, to fix its issue?

Antonio

 

[elnonio]

Ah, interesting development (perhaps). I just found, buried in the apache directory, a dump file dated January 03. A bit old, true, but should have a large amount of structure.

All else being equal, it would be better than having to reverse engineer the entire database from the PHP files!

Fly in the ointment (another) is that it's an 8i dump, from back when the database was run on Windows:
CREATE TABLESPACE "RBS" DATAFILE 'C:\ORA81\ORADATA\CURREL\RBS01.DBF'

 

[SantaMufasa]

Antonio,

Sorry to hear the news that you do not have a recent full backup. But yes, a backup from a year ago is certainly better than nothing. As you know, you will need to use Oracle 8 executables to start up your January 2004 database.

Let us know how your restoration progresses.

Mufasa
(aka Dave of Sandy, Utah, USA)

http://www.dasages.com

@ 02:58 (22Dec04) UTC (aka "GMT" and "Zulu"),
@ 19:58 (21Dec04) Mountain Time