[Oracle-l] DB corruption question

Nope, no corruption of data files as far as I can see. The mount lock
(or whatever it's called now) protects Oracle from having two instances
mount the same database. There used to be a wonderful _no_mount_lock
parameter or such, but I never got it to work. You should be OK.

Mogens

Nick Wagner wrote:

-----Original Message-----
ORA-01110: data file 1: '/fs1/oradata/db1/system01_raw.dbf'
ORA-01207: file is more recent than controlfile - old controlfile

Will this corrupt the database? Will it harm/corrupt the original instance?
What happens if someone tries to recover it at this point? Does it make a
difference whether its a RAW or cooked file system?

I don't think it will corrupt anything, but you won't be able to open the
database. Apparently somebody smoked at least one control file and restored
it from a backup. So now the control file(s) is/are behind the data file.
If only one control file was smoked, and you have another that is up to
date, replace the smoked one with a copy of the good one.

If you can't do that (i.e. ALL your control files are old) AND if the
database was shut down clean (why do I have the feeling it wasn't?), then
move what control file you have off somewhere else; and see if you can
recreate a new control file; then recover the database using backup control
file. This will require an open resetlogs (You DO have a good backup of
what you currently have right?).

If the database was not shut down clean and you only have old control files,
then I think you have no choice but to restore the entire database back to
your last backup. If you are in this situation, you still might try
recreating the contol files. If the database had no activity prior to the
disruption, you might get lucky and have all your headers up to date even
without a clean shutdown. As long as you are planning a complete restore, I
don't think it would hurt to give it a try.

It's time to get out that Oracle backup and restore manual.

Try, recreate the controlfile

Original Message -----
From: Nick Wagner
To: Multiple recipients of list ORACLE-L
Sent: Wednesday, December 04, 2002 10:09 PM
Subject: DB corruption question

With Oracle 8.1.7, Solaris 8 OS.

I have a shared storage device for storing all my datafiles, control files, redo logs, archive logs, etc.. everything except for the ORACLE_HOME and Oracle binaries.

If I have the file system and database mounted to one machine, and have a fully open, available database running. What happens if someone else tries to mount the same files to another machine and start up the same database on it. (No OPS or RAC involved)

I get the following error on the on the second machine...

SVRMGR> ORACLE instance started.
Total System Global Area 272359584 bytes
Fixed Size 73888 bytes
Variable Size 88678400 bytes
Database Buffers 183427072 bytes
Redo Buffers 180224 bytes
Database mounted.
SVRMGR> ORA-00283: recovery session canceled due to errors

ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/fs1/oradata/db1/system01_raw.dbf'
ORA-01207: file is more recent than controlfile - old controlfile

SVRMGR> alter database open
*

ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/fs1/oradata/db1/system01_raw.dbf'
ORA-01207: file is more recent than controlfile - old controlfile

SVRMGR> Server Manager complete.
EXITING 1

Unable to start Oracle instance

Will this corrupt the database? Will it harm/corrupt the original instance? What happens if someone tries to recover it at this point? Does it make a difference whether its a RAW or cooked file system?

Any help is appreciated!

Nick

These errors are from the second database. It's normal to get them.
I do not think there is any corruptions.

As long the first one is running without errors then do not worry.

To make sure try to restart the database.

Regards,

Waleed

Is it possible that the data files from the first database were copied to
the second, but the control files did not get copied?

This is more of a theoretical question, rather than an actual problem that
happened. Let's assume the files were not copied, and there is no security
at the site or on the disks themselves.