We have one database which is at noarchivelog mode.
we had a database crash.
we have full export backup
and os backup which is taken when the database is up.
So when i use the os backup and start the database it gives me the following error
ORA-00214 controlfile 'string' version string inconsistent with file 'string' version string
Cause: An inconsistent set of control files, datafiles, and redo log files was used.
Action: Use a consistent set of control files, datafiles, and redo log files. That is, all the files must be for the same database and from the same time period.
i just need to open the database.
Is there anyway i can open the database and then apply the full export or
i should just use the fullback up. If so how do i proceed.
1. Make sure the database is down
2. Backup your existing database in case you have to get back to ground 0 again.
3. edit your init.ora file to use only one of your control files.
4. startup mount
5. alter database recover until cancel using backup controlfile
6. alter database recover cancel
7. alter database open resetlogs
8. Shutdown immediate
9. Start a backup
With any luck, you will be able to recover to some consistent point. Otherwise, you will have to re-create your database. If this doesn't work, restore the backup that was taken with the database open and try the same steps.
Running in noarchivelog mode, you have esentially given yourself no option to recover. Backing up the database while it is open did not help you either.
You might want to consider re-vamping your backup strategy sometime in the near future.
You can't take a full backup of the database files while the database is running if the database is in noarchivelog mode. To take a backup of the files, you either take a "cold" backup, which is when the database is shut down, or a "hot" backup which is when the database is open, but only when it is in archivelog mode and you follow the correct procedure. If you try to take a hot backup in noarchivelog mode, it won't work as you found out the hard way (which is typically the best, although not the most fun way to learn)
Do you have your control file backed up to trace? If not do you know enough about the database to create the "CREATE CONTROLFILE" statement? If so you *might* be able to get away with just creating new controlfiles, but if your backup is what I think it is you're probably out of luck.
In this case I think your only chance is to import the full export dump.
As far as I know the easiest way to do this is to create a fresh database (check technet documentation for how to create a new database), create the preliminary tablespaces you wish, run catalog.sql, catproc.sql, and catexp.sql, then you can import and everything should be ok.
Just make sure that your old datafiles are moved to a location ohter than their original location because import will re-create the files in the original location. Also make sure that the new system tablespace you create is the same size or larger than the original. Make sure you log the import so you can check for errors later.
Since you have a full export file.
Why don't you recreate your database and import it?
I am not sure about this , so I am afraid of recommanding this. but. if you have the test machine, try this one.
1.restore all datafile except control file.
2.svrmgrl connect internal
4.create controlfile reuse database "your db name" noresetlogs noarchivelog(since you said that your db is not in archivelog mode?)
group1 'xxxxx' size x,
group1 'xxxxx' sizse x,
group2 'xxxxx' size x
...... your datafiles ;
5. recover database
6. alter database open
7. shutdown and full backup.
It looks like you lost one of your controlfiles.
1) Make backup copy of your current controlfiles (all control files!!!)
2) Copy one of the controlfiles to another one
3) Startup database
4) If it is started you are lucky
5) if not, try to restore another control file and copy it to the rest locations
6) goto 3
If you know all the redo log files and datafiles in your database you can create by hand sql script to recreate controlfiles.
I dont want to worry you but I am almost sure the only way is to recreate a database and do a full import.
The OS backup you have is nothing but useless files since you backed them up when the database is running, none of them is syncronized, even if you are in archived log mode and you do this you will not be able to recover a database with these kinds of backups.
If your backup is taken while the db is up and your db is not in archivelog mode, as pando told , the only way to recover is from importing. I didn't notice that your cold backup was taken while the db is up.
PLEASE, PLEASE check to see if one of your controlfiles is corrupt first. As the prior poster mentioned, please change your init to use each control file in turn. If it works, then shutdown, and copy that one over the other two, and restart.
Then if that fails, recreate your DB and do a full import as the others mentioned.
Taking backup of DB does not mean that, just copying all the files physically when the Database is up and running. So is the problem you are facing when you want to recover it. Only the way is recreate it and import. But atleast make sure that you follow the procedure to have a nice backup right from now.
Like having a clean cold backup, or having a hotbackup which needs to be done with systematic procedure. If you want I will post you some sample script