恢复控制文件
在进行介质恢复时，如果存在当前控制文件，就使用当前控制文件，如果当前控制文件在出现介质故障时丢失，那么可以用控制文件的备份拷贝，或者创建一个新的控制文件，创建控制文件的语法如下：
STARTUP NOMOUNT;
CREATECONTROLFILE REUSE DATABASE "LYJ" NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 8
MAXLOGHISTORY 907
LOGFILE
GROUP 1 '/u3/oradata/lyj/redo01.log' SIZE 500K,
GROUP 2 '/u3/oradata/lyj/redo02.log' SIZE 500K,
GROUP 3 '/u3/oradata/lyj/redo03.log' SIZE 500K
DATAFILE
'/u3/oradata/lyj/system01.dbf',
'/u3/oradata/lyj/tools01.dbf',
'/u3/oradata/lyj/rbs01.dbf',
'/u3/oradata/lyj/temp01.dbf',
'/u3/oradata/lyj/users01.dbf',
'/u3/oradata/lyj/indx01.dbf'
CHARACTER SETUS7ASCII;
RECOVERDATABASE
ALTER SYSTEMARCHIVE LOG ALL;
ALTER DATABASEOPEN;
Createcontrolfile命令只能在nomount选项启动数据库后发出，执行该命令之前，创建一个新的控制文件并自动安装数据库，然后新的控制文件在需要时可以用于恢复。
从丢失的数据文件中恢复
通常由磁盘错误引起的数据文件的丢失，是用户经常遇到的情况。如果正在ARCHIVELOG模式下运行，那么可只还原丢失的文件，把它们还原到出错的那一刻，而进行这些操作时除非system表出错，其它的文件正在运行。
使丢失的数据文件脱机
如果驱动器错误导致丢失了一个数据文件，那么oracle已经将这个文件脱机，可以用下列查询检查数据库中文件的状态：
SQL> selectstatus,name from v$datafile ;
STATUS NAME
--------------------------------------------------
SYSTEM /u3/oradata/lyj/system01.dbf
ONLINE /u3/oradata/lyj/tools01.dbf
ONLINE /u3/oradata/lyj/rbs01.dbf
ONLINE /u3/oradata/lyj/temp01.dbf
ONLINE /u3/oradata/lyj/users01.dbf
OFFLINE /u3/oradata/lyj/indx01.dbf
在这种情况下，indx01.dbf文件是脱机的，如果已丢失的文件还没有脱机，可以通过下列命令使其脱机：
alter databasedatafile‘/u3/oradata/lyj/indx01.dbf’offline；
只有文件安全脱机后，才能继续还原并恢复它。其它未脱机的数据文件可以照常工作。
还原丢失的数据文件
在恢复文件前，使用操作系统级的复制命令还原数据文件，否则执行一条alter database rename file命令在数据库文件中记录新的位置。
1恢复丢失的数据文件（2种方法）
以sysdba或system或internal身份登录后，执行recover database命令使得oracle检查所有文件并对任何需要恢复的文件进行恢复。
recover datafile ‘/u3/oradata/lyj/indx01.dbf’
如果归档日志文件仍然联机，它们需要在archive_log_dest指向的文件夹中。
2将已恢复的文件重新重新联机
恢复完文件后是将文件重新联机，可以通过alter database命令实现。E.g:
SQL>alterdatabase datafile‘/u3/oradata/lyj/indx01.dbf’online ;
OK!文件已被恢复，已被重新联机，可以正常使用了。
执行一个不完全恢复
在介质故障恢复中，不丢失数据的数据库恢复称为完全恢复。如果在数据库恢复之后丢失某些数据，则称为不完全恢复。一般情况下，当所有需要的重作日志文件和备份数据文件以及当前有效的控制文件都可以使用时，应该采用完全恢复。只有当丢失了一个归档或联机重作日志文件和控制文件时采用不完全恢复。不完全恢复还可以恢复到过去的某个时间点。
不完全恢复并不总是代表一个从进程错误中恢复的理想办法，因为如果联机事务正在发生而同时一个批处理进程正在运行，如果用户运行一个不完全恢复来重新运行批处理进程，那些数据就将丢失。在不完全恢复前，需要将某一次文件的全备份进行还原，然后就可以进行不完全恢复了。
不完全恢复有几个选项可供选择：
until cancel指定一个基于取消的恢复；
until change指定恢复到一个指定的SCN；
until time指定恢复到某一时间；
datetime指定用户希望恢复数据库的日期和时间。
SVRMGR>connectinternal；
SVRMGR>startupmount
SVRMGR>recoverdatabase until time ‘2001－02－21：
10：30：00’；
SVRMGR>alterdatabase open resetlogs；
因为在打开数据库时始用了resetlogs选项，oracle抛弃恢复中没有运用的重作纪录，并且确保永远不再运用，同时重新初始化控制文件中有关联机日志文件和重作线程的信息，可以有效地预防使用一个已存在的归档和redo日志来再次恢复，所以最好在运行完不完全恢复后立即执行数据库的另一个脱机或联机的全备份。
从导出文件中还原数据库
可以使用imp应用程序从导出文件来还原一个数据库。
从导出文件中还原数据库比从一个文件系统的备份中还原数据库要容易，但是它具有以下一些不利因素：
还原进程时间长；
不能还原个别文件；
不能执行介质恢复，故不能恢复导出后所做的变化
例子：
数据文件恢复的一般过程是：
====================
做任何恢复之前，先备份目前的系统，以防恢复过程中，系统遭到更大的损坏
首先取得最后一次备份（脱机冷备份），并确保没有损坏，
然后判断系统是否运行在归档模式，
如果是非归档模式，则只能用最后一次全备份来恢复，
删除所有的数据文件、控制文件、联机日志文件，
将备份的数据文件、控制文件、联机日志文件全部拷回原目录。
重新启动数据库
====================
如果是归档模式，再判断是否可以shut