RE: OCP Question

From: Goulet, Richard <>
Date: Wed, 16 Dec 2009 15:34:00 -0500
Message-ID: <>


        Now this is one I can help you with because I've seen it in real life.

        Starting point, and HP-UX server with an existing data base instance that is happily running.

        Two, a newbie dba who has never created a database on his own before.

        Three, newbie copies the init.ora and create database scripts from the original database (version 8.0)to start his new DB.

        Four, newbie forgets to change the control file parameter in inti.ora and creates new database. 5 minutes later the existing db crashes.

        Saving point, a backup controlfile to trace had been executed the night before, thank GOD.

        Problem, one datafile was moved in the morning to a larger mount point.

        Executed the create controlfile commands in the trace file to recreate the control file, but found the "missing" place holder where the moved datafile should have been, damn.

        Issued an alter database rename file x to '<new location & filename>'; Problem fixed.

        Why did this happen vs the create controlfile fail? According to the iTAR (and my failing memory), when the rdbms tried to find the renamed file in it's original location it could not, so instead of failing it marked is as missing and took it offline since it was not a critical datafile, not part of the system tablespace.

        So you get a 'no error, no foul' behavior that personally I liked. The rename succeeded & the database opened successfully.

Dick Goulet
Senior Oracle DBA/NA Team Lead
PAREXEL International

-----Original Message-----

[] On Behalf Of Blanchard, William Sent: Wednesday, December 16, 2009 3:15 PM To: Newman, Christopher;; Subject: RE: OCP Question

You people with your fancy DataGuard, OID, ASM and OEM. ;-) What's wrong with using 7.3 standards for 10g databases? :-S (Help me please, I'm stuck in the 20th century).

-----Original Message-----

From: Newman, Christopher [] Sent: Wednesday, December 16, 2009 2:07 PM To: Blanchard, William;; Subject: RE: OCP Question

We saw this once on a standby database; the primary was recreated with different datafiles, then the standby was created, but had existing files already on disk.

To make this more clear:

  1. Primary recreated and reorganized so that it contained less datafiles, ie SALES01.dbf, SALES02.dbf instead of SALES01-10.dbf's.
  2. Standby was recreated. The existing datafiles weren't removed, they were merely overwritten (and there would be extras in this case, IE SALES03-10.dbf).

With dataguard, automatic file management set up. So:

  1. Add SALES03.dbf to the primary as the need arises.
  2. SALES03.dbf physical file already exists on the standby, albeit not associated with the database. Because the file exists on disk however, it is not overwritten and you get Oracle renaming the file with the MISSING issue.

-----Original Message-----

From: on behalf of Blanchard, William Sent: Wed 12/16/2009 2:02 PM
To:; Subject: RE: OCP Question  

I believe this is because the controlfile can't find the file (someone correct me if I'm wrong). I would check the path and ensure that the controlfile is pointing to the correct location.

-----Original Message-----

[] On Behalf Of Bill Zakrzewski Sent: Wednesday, December 16, 2009 1:58 PM To:
Subject: OCP Question

Listers -

I took the Oracle 10g OCP exam and one question in the exam was something I have not come across in several years working with Oracle. I searched google, but only found someone has had this happen, but they didn't understand why - it was during a database cloning process.

It went something like - You rebuild your controlfile and open your database and discover several datafiles have been renamed to /somepath/MISSING##### (where ##### is a 5-digit number).

What might that signify?

A. Those are corrupt files?
B. Those are read-only tablespace files?
C. .....
D. .....
E. .....

I don't remember the five choices, but does anyone know why Oracle would rename datafiles to .....MISSING#####.




This email and any information, files, or materials transmitted with it are confidential and are solely for the use of the intended recipient. If you have received this email in error, please delete it and notify the sender.


-- Received on Wed Dec 16 2009 - 14:34:00 CST

Original text of this message