oracle.html

log</font><font face="TIMES">" prompt.</font></font>
<p><font face="TIMES"><font size=-1>If there isn't enough space for all
of the archived redo logs to be uncompressed, a little creativity may be
required. Uncompress as many as possible, and then hit enter each time
it suggests the next file. (Hitting enter tells Oracle that the file that
it is suggesting is available. If it finds that it is <i>not</i> available,
it prompts for the same file again.) Once it has finished with one archive
log, compress that log, and uncompress a newer log, since it will be needed
it shortly. (Obviously, a second window is required, and a third window
wouldn't hurt!)</font></font>
<p><font size=-1><font face="TIMES">At some point, it may ask for an archived
redo log that is not available. This could mean some of the archived redo
logs or online redo logs are damaged. If the file cannot be located or
restored, enter </font><font face="Courier">CANCEL</font><font face="TIMES">.</font></font>
<p><font face="TIMES"><font size=-1>More detail on media recovery is available
in Oracle's documentation.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If the database did not open, proceed
to Step 11 after reading the preceding notes. If it did open, proceed to
Step 15.</font></font></dir>
</dir>
<a NAME="Step11"></a><b><font face="TIMES"><font size=+1>Step 11: Damaged
System File?</font></font></b>
<p><font size=-1><font face="TIMES">If the damaged file is part of the
</font><font face="Courier">SYSTEM</font><font face="TIMES">
tablespace, an offline recovery is required. All other missing data files
can be recovered with the database online. Unfortunately, Oracle only complains
that the data file is missing -- without saying what <i>kind </i>of data
file it is. Fortunately, even if Oracle is down, there is an easy way to
determine which files belong to the </font><font face="Courier">SYSTEM
</font><font face="TIMES">tablespace.
(Finding out if the data file contains a rollback segment is a little more
difficult, but it is still possible.) To find out which data files are
in the </font><font face="Courier">SYSTEM</font><font face="TIMES"> tablespace,
run the following command on the mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > select name from v$datafile
where status = 'SYSTEM' ;</font></font>
<p><font face="Courier"><font size=-2>NAME</font></font>
<p><font face="Courier"><font size=-2>--------------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/system01.dbf</font></font>
<p><font face="Courier"><font size=-2>1 row selected.</font></font></dir>
<font size=-1><font face="TIMES">This example report shows that the only
file that is a member of the </font><font face="Courier">SYSTEM</font><font face="TIMES">
tablespace is <i>/db/Oracle/a/oradata/crash/system01.dbf</i>. In your configuration,
however, there may be multiple data files in the </font><font face="Courier">SYSTEM
</font><font face="TIMES">tablespace.</font></font>
<dir>
<dir><font size=-1><font face="TIMES">If any of the damaged data files
is a member of the </font><font face="Courier">SYSTEM </font><font face="TIMES">tablespace,
proceed to Step 12. If none of them is a member of the </font><font face="Courier">SYSTEM
</font><font face="TIMES">tablespace,
then proceed to Step 13.</font></font></dir>
</dir>
<a NAME="Step12"></a><b><font face="TIMES"><font size=+1>Step 12: Restore
All Data Files in the SYSTEM Tablespace</font></font></b>
<p><font face="TIMES"><font size=-1>Unlike other tablespaces, the SYSTEM
tablespace must be available in order to open the database. Therefore,
if any members of the system tablespace are damaged, they must be restored
now. Before doing this, make sure that the database is not open. (It is
okay if it is mounted.) To make sure, run the following command on the
mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select status from v$instance;</b></font></font>
<p><font face="Courier"><font size=-2>STATUS</font></font>
<p><font face="Courier"><font size=-2>-------</font></font>
<p><font face="Courier"><font size=-2>MOUNTED</font></font>
<p><font face="Courier"><font size=-2>1 row selected.</font></font></dir>
<font face="TIMES"><font size=-1>(The example above shows that this instance
is mounted, not open.)</font></font>
<p><font face="TIMES"><font size=-1>If the database is not open, restore
the damaged files from the most recent backup available. Once all damaged
files in the system tablespace are restored, run the following command
on the mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<p><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>recover tablespace system;</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > media recovery complete</font></font></dir>
<font face="TIMES"><font size=-1>Once this command has completed, the system
tablespace will be recovered to the time of failure.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If it does complete successfully,
and no other data files are damaged, return to Step 10. For more information
about the <i>recover tablespace</i> command, read the earlier section "How
Media Recovery works" at the end of Step 10. If there are other data files
to recover, proceed to Step 13.</font></font></dir>
</dir>
<a NAME="Step13"></a><b><font face="TIMES"><font size=+1>Step 13: Damaged
Non-System Data File?</font></font></b>
<p><font size=-1><font face="TIMES">So far, we have mounted the database,
which proves that the control files are okay. It may have taken some effort
if one or more of the control files were damaged, but it succeeded. We
have also verified that the </font><font face="Courier">SYSTEM</font><font face="TIMES">
tablespace is intact, even if it required a restore and recovery. Most
of the rest of this procedure concentrates on disabling damaged parts of
the database so that it may be brought online as soon as possible. The
process of elimination will identify all damaged data files once the database
is opened successfully. They can then be easily restored.</font></font>
<dir>
<dir><font size=-1><font face="TIMES">If there are damaged data files that
are not part of the </font><font face="Courier">SYSTEM </font><font face="TIMES">tablespace,
proceed to Step 14. If there are no more damaged data files, then proceed
to Step 17.</font></font></dir>
</dir>
<a NAME="Step14"></a><b><font face="TIMES"><font size=+1>Step 14: Take
Damaged Data File Offline</font></font></b>
<p><font face="TIMES"><font size=-1>To open a database with a damaged,
non-system data file, take the data file offline. (If the file that is
taken offline is part of a tablespace that contains rollback segments,
there will be one other step, but we'll cross that bridge when we come
to it.)</font></font>
<p><font size=-1><font face="TIMES">If this instance is operating in </font><font face="Courier">ARCHIVELOG</font><font face="TIMES">
mode, just take the data file offline. It can later be restored and recovered
after the instance has been brought online. The command to do this is:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter database datafile
'filename' offline;</b></font></font></dir>
<font size=-1><font face="TIMES">If the instance is operating in </font><font face="Courier">NOARCHIVELOG</font><font face="TIMES">
mode, that's a different problem. Oracle does not allow the data file to
be taken offline, because it knows it can't be brought back online without
media recovery. Without </font><font face="Courier">ARCHIVELOG</font><font face="TIMES">
mode, there is no media recovery. The only thing Oracle does allow is to
drop the data file entirely. This means, of course, that the tablespace
that contains this file will have to be rebuilt from scratch. This is but
one of the many reasons why a production instance should not be operating
in no archive log mode. The command to do this is:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter database datafile
'filename' offline drop;</b></font></font>
<dir><font face="TIMES"><font size=-1>Once any damaged files are taken
offline, return to Step 10 and attempt to open the database again.</font></font></dir>
</dir>
<a NAME="Step15"></a><b><font face="TIMES"><font size=+1>Step 15: Were
Any Data Files Taken Offline?</font></font></b>
<br>&nbsp;
<br>&nbsp;
<dir>
<dir><font face="TIMES"><font size=-1>Perform this step only if the database
has been opened.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>This step is really a very simple question!</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If the database was opened without
taking any data files offline, proceed to Step 29. If some data files were
taken offline to open the database, proceed to Step 16. If unsure, proceed
to Step 16.</font></font></dir>
</dir>
<a NAME="Step16"></a><b><font face="TIMES"><font size=+1>Step 16: Bring
Data File(s) Back Online</font></font></b>
<p><font face="TIMES"><font size=-1>First find out which data files were
taken offline. To do this, run the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select name from v$datafile
where status = 'OFFLINE' ;</b></font></font>
<p><font face="Courier"><font size=-2>NAME</font></font>
<p><font face="Courier"><font size=-2>------------------</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/temp01.dbf</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/tools01.dbf</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/users01.dbf</font></font></dir>
<b><font face="TIMES"><font size=-1>Restore the damaged datafiles</font></font></b>
<p><b>Once the names of the data files that need to be restored are determined,
restore them from the latest available backup. Once they are restored,
recovery within Oracle can be accomplished in three different ways. These
ways vary greatly in complexity and flexibility. Examine the following
three media recovery methods and choose whichever one is best for you.</b>
<p><b>Datafile recovery</b>
<p><b>If there is a small number of data files to recover, this may be
the easiest option. As each file is restored, issue the <i>recover data
file </i>command against it and then bring it online:</b>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>recover datafile '<i>datafile_name'</i>
;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter database datafile
'<i>datafile_name</i>' online ;</b></font></font>
<br><font face="Courier"><font size=-2>Statement processed.</font></font></dir>
<font face="TIMES"><font size=-1>The downside to this method is that media
recovery may take a while for each data file. If recovering multiple data
files within a single tablespace, this is probably wasting time.</font></font>
<p><b><font face="TIMES"><font size=-1>Tablespace recovery</font></font></b>
<p><font face="TIMES"><font size=-1>This method is the hardest of all methods,
but it may work faster than the previous method if there are several damaged
data files within a tablespace. If forced to leave the partially functional
database open while recovering the damaged data files, and there are several
of them to recover, this is probably the best option.</font></font>
<p><font face="TIMES"><font size=-1>First find out the names of all data
files, and the tablespace to which they belong. Since the database is now
open, this can be done in one step, demonstrated in Figure G:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select file_name, tablespace_name
from dba_data_files;</b></font></font>
<br><font face="Courier"><font size=-2>Statement processed.</font></font>
<p><font face="Courier"><font size=-2>FILE_NAME</font></font>
<p><font face="Courier"><font size=-2>TABLESPACE_NAME</font></font>
<p><font face="Courier"><font size=-2>--------------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>------------------------------</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/users01.dbf</font></font>
<p><font face="Courier"><font size=-2>USERS</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/tools01.dbf</font></font>
<p><font face="Courier"><font size=-2>TOOLS</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/temp01.dbf</font></font>
<p><font face="Courier"><font size=-2>TEMP</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/rbs01.dbf</font></font>
<p><font face="Courier"><font size=-2>RBS</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/system01.dbf</font></font>
<p><font face="Courier"><font size=-2>SYSTEM</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/test01.dbf</font></font>
<p><font face="Courier"><font size=-2>TEST</font></font>
<dir>
<center><i><font face="TIMES"><font size=-1>Figure G: Listing of dba_data_files</font></font></i></center>
</dir>
</dir>
<i>The only problem with this output is that it's not very easy to read,
and could be impossible to read if there are hundreds of data files. One
way to make it easier to read is to modify the command, as shown in Figure
H:</i>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl &lt;&lt;EOF |sed 's/
*/ /' |sort >/tmp/files.txt</b></font></font>
<p><b><font face="Courier"><font size=-2>connect internal;</font></font></b>
<p><b><font face="Courier"><font size=-2>select file_name, tablespace_name
from dba_data_files;</font></font></b>
<p><b><font face="Courier"><font size=-2>quit;</font></font></b>
<p><b><font face="Courier"><font size=-2>EOF</font></font></b>
<p><font face="Courier"><font size=-2>$ <b>grep '^/' /tmp/files.txt</b></font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/rbs01.dbf
RBS</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/system01.dbf
SYSTEM</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/temp01.dbf
TEMP</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/test01.dbf
TEST</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/tools01.dbf
TOOLS</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/users01.dbf
USERS</font></font>
<dir>
<center><i><font face="TIMES"><font size=-1>Figure H: Readable listing
of data files</font></font></i></center>
</dir>
</dir>
<i>This way, the files are sorted in alphanumeric order, making it easy
to find the necessary file(s).</i>
<p><i>Once all of the data files are restored, and the names of all the
tablespaces that contain these data files have been determined, issue the
recover tablespace command against each of those tablespaces. Before doing
so, however, each of those tablespaces must be taken offline, as shown
in Figure I.</i>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter tablespace <i>tablespace_name1
</i>offline;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>recover tablespace <i>tablespace_name1
</i>;</b></font></font>
<p><font face="Courier"><font size=-2>ORA-00279: change 18499 generated
at 02/21/98 11:49:56 needed for thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00289: suggestion : /db/Oracle/admin/crash/arch/arch.log1_481.dbf</font></font>
<p><font face="Courier"><font size=-2>ORA-00280: change 18499 for thread
1 is in sequence #481</font></font>
<p><font face="Courier"><font size=-2>Specify log: {&lt;RET>=suggested
| filename | AUTO | CANCEL}</font></font>
<p><font face="Courier"><font size=-2>Auto</font></font>
<p><font face="Courier"><font size=-2>Log applied</font></font>
<p><font face="Courier"><font size=-2>Media Recovery Complete</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter tablespace <i>tablespace_name1
</i>online;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter tablespace <i>tablespace_name2
</i>offline;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>recover tablespace <i>tablespace_name2
</i>;</b></font></font>
<p><font face="Courier"><font size=-2>ORA-00279: change 18499 generated
at 02/21/98 11:49:56 needed for thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00289: suggestion : /db/Oracle/admin/crash/arch/arch.log1_481.dbf</font></font>
<p><font face="Courier"><font size=-2>ORA-00280: change 18499 for thread
1 is in sequence #481</font></font>
<p><font face="Courier"><font size=-2>Specify log: {&lt;RET>=suggested
| filename | AUTO | CANCEL}</font></font>
<p><font face="Courier"><font size=-2>Auto</font></font>
<p><font face="Courier"><font size=-2>Log applied</font></font>
<p><font face="Courier"><font size=-2>Media Recovery Complete</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter tablespace <i>tablespace_name2
</i>online;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<dir>
<center><i><font face="TIMES"><font size=-1>Figure I: Tablespace-based
recovery</font></font></i></center>
</dir>
</dir>
<i>It's obvious that this method is quite involved! It's not pretty, it's
not easy, but it allows recovery of multiple tablespaces while the instance
continues to operate. If a partially functioning database is of any value
to the users, this method may be their best friend.</i>
<p><b><i>Database recovery</i></b>
<p><i>This method is actually the easiest method, but it requires that
the database be shut down to perform it. After restoring all the database
files that were taken offline, close the database and issue the recover
database command.</i>
<p><i>Once all the database files are restored, issued commands shown in
Figure J.</i>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter database close
;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>recover database ;</b></font></font>
<p><font face="Courier"><font size=-2>ORA-00279: change 18499 generated
at 02/21/98 11:49:56 needed for thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00289: suggestion : /db/Oracle/admin/crash/arch/arch.log1_481.dbf</font></font>
<p><font face="Courier"><font size=-2>ORA-00280: change 18499 for thread
1 is in sequence #481</font></font>
<p><font face="Courier"><font size=-2>Specify log: {&lt;RET>=suggested
| filename | AUTO | CANCEL}</font></font>
<p><b><font face="Courier"><font size=-2>Auto</font></font></b>
<p><font face="Courier"><font size=-2>Log applied</font></font>
<p><font face="Courier"><font size=-2>Media Recovery Complete</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter database open</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<dir>
<center><i><font face="TIMES"><font size=-1>Figure J: Normal database recovery</font></font></i></center>
</dir>
</dir>
<i>To make sure that all tablespaces and data files have been returned
to their proper status, run the commands shown in Figure K.</i>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select name, status from
v$datafile</b></font></font>
<p><font face="Courier"><font size=-2>NAME</font></font>
<p><font face="Courier"><font size=-2>STATUS</font></font>
<p><font face="Courier"><font size=-2>--------------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>-------</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/system01.dbf</font></font>
<p><font face="Courier"><font size=-2>SYSTEM</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/rbs01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/temp01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/tools01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/users01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/test01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>6 rows selected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select member, status
from v$logfile</b></font></font>
<p><font face="Courier"><font size=-2>NAME</font></font>
<p><font face="Courier"><font size=-2>STATUS</font></font>
<p><font face="Courier"><font size=-2>--------------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>-------</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/system01.dbf</font></font>
<p><font face="Courier"><font size=-2>SYSTEM</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/rbs01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/temp01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/tools01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/users01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/test01.dbf</font></font>
<p><font face="Courier"><font size=-2>ONLINE</font></font>
<p><font face="Courier"><font size=-2>6 rows selected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR> select * from v$controlfile;</font></font>
<p><font face="Courier"><font size=-2>STATUS NAME</font></font>
<p><font face="Courier"><font size=-2>------- ------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>--------</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/a/oradata/crash/control01.ctl</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/b/oradata/crash/control02.ctl</font></font>
<p><font face="Courier"><font size=-2>/db/oracle/c/oradata/crash/control03.ctl</font></font>
<p><font face="Courier"><font size=-2>3 rows selected.</font></font>
<dir>
<center><i><font face="TIMES"><font size=-1>Figure K: Obtaining the names
of all data files, control files, and log files</font></font></i></center>
</dir>
</dir>
<i>The example above shows that all data files, control files, and log
files are in good condition. (In the case of the log files and control
files, no status is good status.)</i>
<dir>
<dir><i>Once any data files that were taken offline have been restored
and recovered, proceed to Step 29.</i></dir>
</dir>
<a NAME="Step17"></a><b><font face="TIMES"><font size=+2>Step 17: Is There
a Damaged Log Group?</font></font></b>
<p><font face="TIMES"><font size=-1>When we refer to a damaged log group,
we mean that all members of a log group are damaged. If at least one member
of a mirrored log group is intact, Oracle opens the database and simply
put an error message in the alert log. However, if all members of a log
group are damaged, the database will not open, and the error will look
something like this:</font></font>
<dir><font face="Courier"><font size=-2>ORA-00313: open failed for members
of log group 2 of thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/b/oradata/crash/redocrash02.log'</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/a/oradata/crash/redocrash03.log'</font></font>
<dir><font face="TIMES"><font size=-1>If there is no error like this, there
is no damaged log group. Proceed to Step 18.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>The first thing that must be determined
is the status of the damaged log group. The three possibilities are current,
active, and inactive. To determine the status of the damaged log group,
run the following command on the mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select group#, status
from v$log;</b></font></font></dir>
<font face="TIMES"><font size=-1>The output looks something like this:</font></font>
<dir><font face="Courier"><font size=-2>GROUP# STATUS</font></font>
<p><font face="Courier"><font size=-2>---------- ----------------</font></font>
<p><font face="Courier"><font size=-2>1 INACTIVE</font></font>
<p><font face="Courier"><font size=-2>2 CURRENT</font></font>
<p><font face="Courier"><font size=-2>3 ACTIVE</font></font>
<p><font face="Courier"><font size=-2>3 rows selected.</font></font></dir>
<font face="TIMES"><font size=-1>The example above shows that log group
1 is inactive, group 2 is current, and group 3 is active. What follows
is an explanation of the different statuses, and how they affect the recovery.</font></font>
<p><font face="TIMES"><font size=-1>Current</font></font>
<dir><font face="TIMES"><font size=-1>The current log group is the one
to which Oracle was writing when the failure occurred. It will still be
listed as active until the server is brought online and a log switch occurs.</font></font></dir>
<font face="TIMES"><font size=-1>Active</font></font>
<dir><font face="TIMES"><font size=-1>An active log group is usually the
log group that Oracle just finished writing to. However, until a checkpoint
occurs, this group is still needed for media recovery. Since a log switch
always forces in checkpoint, a status of active is actually very rare.
In fact, the only way to see this (before the system crashed) is to run
the above command while a checkpoint is in progress. (In a properly tuned
database, this is a very short period of time.)</font></font></dir>
<font face="TIMES"><font size=-1>Inactive</font></font>
<dir><font face="TIMES"><font size=-1>An inactive log group is one that
is not being used by Oracle in any way.</font></font></dir>
<font size=-1><font face="TIMES">To determine what action to take next,
first gave the number of the log group whose log files are damaged. In
the example error above, it reads </font><font face="Courier">open failed
for members of log group </font><font face="TIMES">2</font><font face="Courier">.</font><font face="TIMES">
Reference this number against the log groups listed by the <i>select *
from v$log</i> command. In the example above, log group 2 was current at
the time the database crashed.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If the damaged log group was current,
proceed to Step 22. If it was active, proceed to Step 25. If it was inactive,
proceed to Step 27.</font></font></dir>
</dir>
<a NAME="Step18"></a><b><font face="TIMES"><font size=+1>Step 18: Are Any
Rollback Segments Unavailable?</font></font></b>
<p><font face="TIMES"><font size=-1>If a rollback segment is damaged, Oracle
will complain when attempting to open the database. The error looks like
the following:</font></font>
<dir><font face="Courier"><font size=-2>ORA-01545: rollback segment 'USERS_RS'
specified not available</font></font>
<p><font face="Courier"><font size=-2>Cannot open database if all rollback
segments are not available.</font></font>
<dir><font face="TIMES"><font size=-1>If you haven't already read the note
about damaged rollback segments in Step 10, do so now.</font></font>
<p><font face="TIMES"><font size=-1>If the preceding error is displayed
when attempting to open the database, proceed to Step 19. If not, return
to Step 10.</font></font></dir>
</dir>
<a NAME="Step19"></a><b><font face="TIMES"><font size=+1>Step 19: Does
the Database Need to be at Least Partially Up ASAP?</font></font></b>
<p><font face="TIMES"><font size=-1>Because of the unique nature of damaged
rollback segments, there are two choices for recovery. The first is to
get the database open sooner, but that may leave it only partially functional
for a longer period of time. The second choice takes a little longer to
open the database, but once it is open it will not have data files that
are needed for this rollback segment. Which is more important: getting
even a partially functional database open as soon as possible, or not opening
the database until all rollback segments are available? The latter is more
prudent, but the former may be more appropriate to the environment.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If the database needs to be partially
open ASAP, proceed to Step 21. If it's more important to make sure all
rollback segments are available prior to opening the database, proceed
to Step 20.</font></font></dir>
</dir>
<a NAME="Step20"></a><b><font face="TIMES"><font size=+1>Step 20: Recover
Tablespace Containing Unavailable Rollback Segment</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Perform this step only if directed
to do so by Step 19.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>The first thing that must be determined
is which tablespace the damaged rollback segment is in. Unfortunately,
there is no fixed view that contains this information. That means that
it will have to be discovered through common sense and deduction. First,
remember that this error is not displayed unless a data file has been taken
offline. To get a complete list of files that were taken offline, run the
following command on a mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select TS#, name from
v$datafile where status = 'OFFLINE' ;</b></font></font>
<p><font face="Courier"><font size=-2>NAME</font></font>
<p><font face="Courier"><font size=-2>--------------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>5 /db/oracle/a/oradata/crash/test01.dbf</font></font>
<p><font face="Courier"><font size=-2>1 row selected.</font></font></dir>
<font face="TIMES"><font size=-1>Then find out the name of the tablespace
that contains this data file:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select name from v$tablespace
where TS# = '5' ;</b></font></font>
<p><font face="Courier"><font size=-2>NAME</font></font>
<p><font face="Courier"><font size=-2>--------------------------------------------------------------------------------</font></font>
<p><font face="Courier"><font size=-2>TEST</font></font>
<p><font face="Courier"><font size=-2>1 row selected.</font></font></dir>
<b><font face="TIMES"><font size=-1>That was too easy!</font></font></b>
<p><b>Admittedly, the previous example was easy. There was only one data
file that was offline, which made finding its tablespace pretty easy. What
if there were multiple data files that were contained within multiple tablespaces?
How do we know which one contains the rollback segment? Unfortunately,
there is no way to be sure while the database is closed. That is why it
is very helpful to put the rollback segments in dedicated tablespaces that
have names that easily identify them as such. It's even more helpful if
the data files are named something helpful as well. For example, create
a separate tablespace called </b><font size=-1><font face="Courier">ROLLBACK_DATA</font><font face="TIMES">,
and call its data files <i>rollback01.dbf</i>, <i>rollback02.dbf</i>, etc.
That way, anyone that finds himself in this scenario will know exactly
which data files contain rollback data.</font></font>
<p><font face="TIMES"><font size=-1>The rest of this step is simple. Restore
any files that were taken offline, and use either the <i>recover data file</i>
or <i>recover tablespace</i> commands to roll them forward in time. If
there are only one or two damaged data files, it's probably quicker to
use the <i>recover data file</i> command. If there are several damaged
data files, especially if they are all in one tablespace, the <i>recover
tablespace</i> command is probably easiest. Either way will work.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>Once any data files that contain
rollback segments have been restored and recovered, return to Step 10 and
attempt to open the database again.</font></font></dir>
</dir>
<a NAME="Step21"></a><b><font face="TIMES"><font size=+1>Step 21: Comment
Out Rollback Segment Line(s) in the init.ora File</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Perform this step only if directed
to do so by Step 19.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>There is a quicker way to open the database
with damaged rollback segments. In order for Oracle to know what rollback
segments to look for, the following line is inserted into the <i>initORACLE_SID.ora</i>
file:</font></font>
<dir><font face="Courier"><font size=-2>rollback_segments = (r01,r02,r03,r04,users_rs)</font></font></dir>
<font size=-1><font face="TIMES">(The <i>initORACLE_SID.ora</i> file is
usually found in <i>$ORACLE_HOME/dbs</i>.) Since the example error above
says that it is the </font><font face="Courier">USERS_RS</font><font face="TIMES">
rollback segment that is unavailable, simply delete that part of the line.
It is wise, of course, to comment out and copy the original line. First,
shut down Oracle completely (this includes un-mounting it as well). Then
copy and comment the rollback segment line in the <i>initORACLE_SID.ora</i>
file:</font></font>
<dir><font face="Courier"><font size=-2>#rollback_segments = (r01,r02,r03,r04,users_rs)</font></font>
<p><font face="Courier"><font size=-2>rollback_segments = (r01,r02,r03,r04)</font></font>
<dir><font face="TIMES"><font size=-1>Once this change has been made in
the <i>initORACLE_SID.ora</i> file, return to Step 1 to mount the database.</font></font></dir>
</dir>
<a NAME="Step22"></a><b><font face="TIMES"><font size=+1>Step 22: Is the
Current Online Log Damaged?</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Performing this step only if instructed
to do so by Step 17. If not, return to Step 17 now.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>If the current online log group is damaged,
there would be a message like the following when attempting to open the
database:</font></font>
<dir><font face="Courier"><font size=-2>ORA-00313: open failed for members
of log group 2 of thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/b/oradata/crash/redocrash02.log'</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/a/oradata/crash/redocrash03.log'</font></font></dir>
<font size=-1><font face="TIMES">In the example above, a <i>select group#,
status from v$log</i> command would have also showed that log group 2 was
</font><font face="Courier">CURRENT</font><font face="TIMES">
at the time of failure.</font></font>
<p><font face="TIMES"><font size=-1>This is the worst kind of failure to
have because there will definitely be data loss. That is because the current
online log is required to restart even a fully functioning database. The
current control file knows about the current online log and will attempt
to use it. The only way around that is to restore an older version of the
control file. Unfortunately, you can't restore only the control file because
the data files would then be more recent than the control file. The only
remaining option is to restore the entire database.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>For the procedure to restore the
entire database, proceed to Step 23.</font></font></dir>
</dir>
<a NAME="Step23"></a><b><font face="TIMES"><font size=+1>Step 23: Recover
All Database Files from Backup</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Warning! There are only two reasons
to perform this step. The first is if instructed to do so by Step 22. The
other is if there was an unsuccessfull attempt to open the database after
performing either Steps 26 or 28. This step is the most drastic method
of recovery, and should not be performed unless absolutely necessary.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>Perform this step only after verifying
(or rebuilding or restoring) the control files, and verifying that all
members of the current online log group are damaged. This step is relatively
easy. Simply determine the names and locations of all of the data files
and restore them from their latest backup.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>Warning! Restore only the data files,
not the control files. Do not restore or overwrite the control files unless
instructed to do so by Step 9!</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>To determine the names of all the data
files, run the following command on the mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select name from v$datafile
;</b></font></font>
<dir><font face="TIMES"><font size=-1>Once all data files are restored,
proceed to Step 24.</font></font></dir>
</dir>
<a NAME="Step24"></a><b><font face="TIMES"><font size=+1>Step 24: Alter
Database Open reset logs</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Warning! Perform this step only if
instructed to do so by Step 23. This is another drastic step that should
only be performed if necessary!</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>This command causes Oracle to open the
database after clearing all contents of the online redo log files. Since
there is no way to undo this step, it is a good idea to make copies of
the online redo log files now. To find out all their names, run the following
command on a mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>select member from v$logfile
;</b></font></font></dir>
<font face="TIMES"><font size=-1>To create an "undo" option, copy each
of these files to <i>filename.bak</i>.</font></font>
<p><font face="TIMES"><font size=-1>After making a backup of the online
redo log files, run the following command on a mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter database open resetlogs
;</b></font></font>
<br><font face="Courier"><font size=-2>Statement processed.</font></font></dir>
<font face="TIMES"><font size=-1>If the database opens, congratulations!</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>Make a backup of this database <i>immediately</i>,
preferably with the database shut down. That is because Oracle cannot roll
through this point in time using the redo logs. Oracle <i>must</i> have
a full backup taken after using the <i>open resetlogs</i> command in order
to restore this database using any logs that are made after the <i>open
resetlogs</i> was performed.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>Once that backup is completed, you're
done!</font></font>
<p><a NAME="Step25"></a><b><font face="TIMES"><font size=+1>Step 25: Is
an Active Online Redo Log Damaged?</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Perform this step only if instructed
to do so by Step 17. If not, return to Step 17 now.</font></font></dir>
</dir>
<font size=-1><font face="TIMES">If an </font><font face="Courier">ACTIVE</font><font face="TIMES">
online log group is damaged, there will be a message like the following
when attempting to open the database:</font></font>
<dir><font face="Courier"><font size=-2>ORA-00313: open failed for members
of log group 2 of thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/b/oradata/crash/redocrash02.log'</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/a/oradata/crash/redocrash03.log'</font></font></dir>
<font size=-1><font face="TIMES">In the example above, a <i>select group#,
status from v$log</i> command would have also shown that log group 2 was
</font><font face="Courier">ACTIVE</font><font face="TIMES">
at the time of failure.</font></font>
<p><font size=-1><font face="TIMES">Remember that an </font><font face="Courier">ACTIVE</font><font face="TIMES">
log is one that is still needed for recovery. The reason that it is still
needed is because a checkpoint has not flushed all changes from shared
memory to disk. Once that happens, this log will no longer be needed.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>To perform a checkpoint, proceed
to Step 26.</font></font></dir>
</dir>
<a NAME="Step26"></a><b><font face="TIMES"><font size=+1>Step 26: Perform
a Checkpoint</font></font></b>
<p><font face="TIMES"><font size=-1>The way to attempt to recover from
the scenario in Step 25 is to perform a checkpoint. If it is successful,
the database should open successfully. To perform a checkpoint, issue the
following command on the mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter system checkpoint
local ;</b></font></font>
<br><font face="Courier"><font size=-2>Statement processed.</font></font></dir>
<font size=-1><font face="TIMES">Be patient. The reason that there is an
</font><font face="Courier">ACTIVE</font><font face="TIMES">
log group is that the checkpoint took a long time in the first place. Wait
for Oracle to say that the checkpoint succeeded or failed. If it succeeded,
Oracle will simply say, "</font><font face="Courier">Statement processed.</font><font face="TIMES">"
If it fails, there could be any number of Oracle errors.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>After issuing the checkpoint, even
if it was unsuccessful, return to Step 10 and attempt to open the database.
If this attempt fails, return to Step 23 and recover the entire database.</font></font></dir>
</dir>
<a NAME="Step27"></a><b><font face="TIMES"><font size=+1>Step 27: Is an
Inactive Online Redo Log Damaged?</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Perform this step only if instructed
to do so by Step 17. If not, return to Step 17 now.</font></font></dir>
</dir>
<font size=-1><font face="TIMES">If an </font><font face="Courier">INACTIVE</font><font face="TIMES">
online log group is damaged, there would be a message like the following
when attempting to open the database:</font></font>
<dir><font face="Courier"><font size=-2>ORA-00313: open failed for members
of log group 2 of thread 1</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/b/oradata/crash/redocrash02.log'</font></font>
<p><font face="Courier"><font size=-2>ORA-00312: online log 2 thread 1:
'/db/Oracle/a/oradata/crash/redocrash03.log'</font></font></dir>
<font size=-1><font face="TIMES">In the example above, a <i>select group#,
status from v$log</i> command would have also shown that log group 2 was
</font><font face="Courier">INACTIVE</font><font face="TIMES">
at the time of failure.</font></font>
<p><font size=-1><font face="TIMES">In comparison, this one should be a
breeze. An </font><font face="Courier">INACTIVE</font><font face="TIMES">
log is not needed by Oracle. If it is not needed, simply drop it and add
another in its place.</font></font>
<dir>
<dir><font size=-1><font face="TIMES">To drop and add an </font><font face="Courier">INACTIVE</font><font face="TIMES">
log group, proceed to Step 28.</font></font></dir>
</dir>
<a NAME="Step28"></a><b><font face="TIMES"><font size=+1>Step 28: Drop/Add
a Damaged, INACTIVE Log Group</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Perform this step only if instructed
to do so by Step 27.</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>In all the above examples, the damaged
log group was group 2. Before we drop that group, we should make sure that
we can add it back easily. Ensure that all the original redo log locations
are still valid. To do this, get the names of all of the members of that
log group:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > select member from v$logfile
where GROUP# = '2 ;</font></font></dir>
<font face="TIMES"><font size=-1>For this example, Oracle returned the
values:</font></font>
<dir><font face="Courier"><font size=-2>/logs1redolog01.dbf</font></font>
<p><font face="Courier"><font size=-2>/logs2redolog01.dbf</font></font>
<p><font face="Courier"><font size=-2>/logs3redolog01.dbf</font></font></dir>
<font face="TIMES"><font size=-1>Verify that all these files' locations
are still valid. For this example, assume <i>/logs3 </i>is completely destroyed,
and we are relocating all its contents to <i>/logs4</i>. Therefore, the
future members of log group 2 will be <i>/logs1redolog01.dbf</i>, <i>/logs2redolog01.db</i>,
and <i>/logs4redolog01.dbf</i>.</font></font>
<p><font face="TIMES"><font size=-1>To drop log group 2, issue the following
command on a mounted, closed database:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > alter database drop logfile
group 2<b> ;</b></font></font>
<br><font face="Courier"><font size=-2>Statement processed.</font></font></dir>
<font face="TIMES"><font size=-1>Once that command completes successfully,
add the log group back to the database. To do this, issue the following
command (Remember that we have replaced <i>/logs3redolog01.dbf </i>with
<i>/logs4redolog01.dbf</i>.):</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<br><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > alter database add logfile
group 2 ('<b><i>/logs1redolog01.dbf'</i>, '<i>/logs2redolog01.dbf</i>',
'<i>/logs4redolog01.dbf'</i>) size 500K ;</b></font></font>
<br><font face="Courier"><font size=-2>Statement processed.</font></font>
<dir><font face="TIMES"><font size=-1>Once this command completes successfully,
return to Step 10 and attempt to open the database.</font></font></dir>
</dir>
<a NAME="Step29"></a><b><font face="TIMES"><font size=+1>Step 29: Were
Any Rollback Segment Lines Changed in init.ora?</font></font></b>
<p><font face="TIMES"><font size=-1>There was an option in Step 19 to comment
out rollback segments from the <i>initORACLE_SID.ora</i> file. If that
option was taken, there should be a line in that file that looks like the
following:</font></font>
<dir><font face="Courier"><font size=-2>#rollback_segments = (r01,r02,r03,r04,users_rs)</font></font>
<p><font face="Courier"><font size=-2>rollback_segments = (r01,r02,r03,r04)</font></font>
<dir><font face="TIMES"><font size=-1>If any rollback segments were taken
offline, proceed to Step 30. If there were not, back up the database now.
You're done!</font></font></dir>
</dir>
<a NAME="Step30"></a><b><font face="TIMES"><font size=+1>Step 30: Return
Offline Rollback Segments to Normal Condition.</font></font></b>
<br>&nbsp;
<br>&nbsp;
<p><font face="TIMES"><font size=-1>To check which rollback segments are
offline, run the following command:</font></font>
<dir><font face="Courier"><font size=-2>SVRMGR> <b>select segment_name
from dba_rollback_segs where status = 'OFFLINE' ;</b></font></font>
<p><font face="Courier"><font size=-2>SEGMENT_NAME</font></font>
<p><font face="Courier"><font size=-2>------------------------------</font></font>
<p><font face="Courier"><font size=-2>USERS_RS</font></font>
<p><font face="Courier"><font size=-2>1 rows selected.</font></font></dir>
<font face="TIMES"><font size=-1>Since all data files and redo log files
should be recovered by now, just return the offline rollback segments to
an online status:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>svrmgrl</b></font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>connect internal;</b></font></font>
<p><font face="Courier"><font size=-2>Connected.</font></font>
<p><font face="Courier"><font size=-2>SVRMGR > <b>alter rollback segment
<i>users_rs
</i>online
;</b></font></font>
<p><font face="Courier"><font size=-2>Statement processed.</font></font>
<br>&nbsp;
<br>&nbsp;</dir>
<font face="TIMES"><font size=-1>Once this has been completed, make sure
that any commented lines in the <i>initORACLE_SID.ora</i> file are put
back to their original condition. The example in Step 29 used the suggested
method of commenting out the original line, and changing a copy of it.
Return the line in <i>initORACLE_SID.ora</i> to its original condition:</font></font>
<dir><font face="Courier"><font size=-2>rollback_segments = (r01,r02,r03,r04,users_rs)</font></font></dir>
<font size=-1><font face="TIMES">This step ensures that the next time this
database is opened, the </font><font face="Courier">USERS_RS</font><font face="TIMES">
rollback segment will be used.</font></font>
<p><a NAME="Step31"></a><b><font face="TIMES"><font size=+1>You're done!</font></font></b>
<dir><font face="TIMES"><font size=-1>If you've made it this far, you're
done! All data files, control files, and log files should be online. Take
a backup of the entire database immediately, preferably a cold one with
the database down. If that can't be done, then perform a hot backup.</font></font></dir>

</body>
</html>