Restoring inconsistent cold backup

Question

Hello all.
Here's the scenario: I have a 9.2.0.1 database, in noarchivelog mode, running on Windoze XP. While the database is running, I took a backup of all the datafiles, control files and online logs using copy and paste on windoze. After the copy was done, I have shut down the database. I copied back into the original location the backup of the datafiles I made earlier.
My question is: How I go about to restore this database ? I dont care wether it is consistent or not, I just want to open it to make an export out of it
Things I have tried so far unsuccessfully:
allowresetlogs_corruption
allowreadonly_corruption
If you could shed some light on it on the steps I would need to make, that would be appreciated.
Thanks

Answer 1

What have you tried to far (specifics please, not general statements)?
I have done something close to what you want do a couple of years ago for an Oracle 9.2.0.4 DB on Linux and am looking for my notes. One key thing I found was to not try to change anything but just get a DB up and running that would let me get the data out. That means don't try to use different file paths or anything other changes.
It involved creating a new minimal database from scratch by hand that has the same name, paths, block size as the old one. In my case this minimal DB only had the system_01.dbf, undotbs_01.dbf and users_01.dbf data files even though I ultimately needed access to about 40 others.
The idea is to get a template DB in place that refers to the same paths, then shut it down and replace the minimal system_01.dbf file with the one from your backup. It turned out for me that Oracle could open, load and use my old system tablespace even though it referred to tablespaces that didn't exist yet in the new minimal system; obviously I couldn't use them yet but they didn't cause Oracle to fail to start.
1. You can toss the redo logs since there is nothing in them you need or can use and you will never be able to read them anyway.
2. You will need to create the instance and DB using the same version of Oracle that you had. There were key differences between the early Oracle 9 versions and I wasn't able to get around them.
3. Create an instance for the correct DB version if you don't have one. The easiest way to create a new one is to do a default installation from the original set up files but DO NOT create a database. When given choices use the same values (character set, paths, etc) as your old DB.
4. You will need a text version of the init.ora file in the same location (name and path) where it was before - the character set and block size have to match what you had before. If you have a copy of this file you can try it first. If you don't then create a minimal file; that is, no entries that are not necessary. Oracle comes with a sample with a lot entries commented out.
    a. use the same db_name= parameter in the init.ora file
    b. use a db_files= parameter that is large enough for all of the data files that you will later need access to
    c. use a compatible- parameter that is 9.2.0 and no later
5. You won't be able to use your old, copied, control files since they are binary files and the content won't match the new database; trying to use them will not get you anywhere.
6. Once you can bring up this new DB the first thing you should do is shut it down and take a cold backup.
7. Replace the new system_01.dbf and users_01_dbf files with the ones you copied from the old DB. The new control file can mount and open the old tablespace file and users file since the control file (old Oracle systems only, mind you) have NAME and PATH information but do not care about actual content (how many users, etc).
8. Make sure you can now open and access the DB with your swapped system and user tablespaces. You won't be able to access objects from the system tables that refer to data files that aren't known to the control file so don't even try to yet.
9. You can add your other data files to the DB by doing a CREATE CONTROLFILE command, when unmounted, that adds the other data files that you will want access to. Obviously don't add them all at once; add one and then test to make sure that things are ok. You won't be
It turns out that the control file has the list of datafiles including their names and paths but does not have the sizes; the system tables have the size info and physical info. So you can add a datafile to the control file by path and name without needing to know how big it was supposed to be; that size info will still be in your old system tablespace.I may have missed something and if I fiind my notes will repost with anything else I think of.