Depending on the type of file that is lost, there are different techniques for recovery in Software

Draw QR Code JIS X 0510 in Software Depending on the type of file that is lost, there are different techniques for recovery

A point to emphasize is that the controlfile should never be completely lost: it should be multiplexed, so that if one copy of it is lost, another copy will still be available If any copy of the controlfile is damaged, the database instance will abort immediately If you attempt a startup, the instance will go nomount mode but will stop there: it will not mount the database unless all copies of the controlfile, as specified by the CONTROL_FILES instance parameter, are valid

To confirm that the controlfile is multiplexed, when in mount mode or open mode issue this query:

select name from v$controlfile;

which will list all copies of the controlfile If this query returns only one row, the controlfile is not multiplexed Correct this situation during the next period of scheduled downtime, and if no downtime is scheduled, you should schedule a period as soon as possible The process is

Shut down the database Copy the controlfile Start up the instance in nomount mode Change the CONTROLFILES parameter to include the new copy Shut down again Start up the database in open mode

Running the query given previously will now list both copies The necessity for a shutdown is to obtain a consistent copy of the controlfile If it were copied when the database was open or mounted, the copy would not be valid If the startup stops in nomount mode because the database cannot be mounted, determine what controlfile copies it is looking for with this query:

select value from v$parameter where name='control_files';

17:

To find which copy is damaged or missing, look in the alert log This is the file alert_instancenameora in the directory specified by the BACKGROUND_ DUMP_DEST parameter The last few lines will be something like this:

ALTER DATABASE MOUNT ORA-00210: cannot open the specified control file ORA-00202: control file: 'D:\APP\ORACLE\ORADATA\ORCL11G\CONTROL02CTL' ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified Mon Fe:b 18 09:01:10 2008 Checker run found 1 new persistent data failures ORA-205 signalled during: ALTER DATABASE MOUNT

To repair the damage, copy a surviving file (one of the files listed in the query against V$PARAMETER) over the damaged file (the file mentioned in the alert log) This method of recovery, although it is manual, is usually the fastest But be absolutely certain that you do not accidentally copy the damaged file over the good one Do not laugh! It is very easy to make a mistake like that, particularly when working in a hurry

If your online redo log file groups are multiplexed, loss of a single member is not a problem As long as there is at least one valid member of each online redo log file group, the database will continue running, and if it is shut down, it will open without a problem But Oracle will not be happy: there will be many messages written out to the alert log A missing redo log file member will not be reported by the Server Alert system The situation where all members of a group are lost (in which case the instance will abort and cannot be opened) is beyond the scope of the first OCP examination, though it is tested extensively in the second examination To confirm whether the online redo log file members are multiplexed and to see the status of each file, run this query:

select * from v$logfile;

If any members have a STATUS of INVALID, you should take immediate action to correct the situation The status STALE may be reported this is not a problem;