使用当前可用的操作系统功能和sql*plus命令来完成用户管理的备份。
1.以非归档日志模式备份
当以非归档日志模式运行时必须备份那些文件呢？控制文件，和整个数据文件集，并且必须首先干净地关闭数据库。
可以在操作系统提示符上执行这些生成命令来进行完整的备份：
select 'cp' || name || '/u01/backups' from v$controlfile;
select 'cp' || name || '/u01/backups' from v$datafile;
select 'cp' || name || '/u01/backups' from v$tempfile;
select 'cp' || number || '/u01/backups' from v$logfile;
2.归档日志模式备份
启用和禁用表空间备份模式命令
alter tablespace <tablespace_name> begin backup;
alter tablespace <tablespace_name> end backup;
一次性为所有表空间启用备份模式
alter database begin backup;
alter database end backup;
备份用户数据的表空间和备份system，sysaux，undo表空间之间没有区别：只需当表空间处于备份模式时复制数据文件。但是不能备份临时表空间：甚至不能将他们置于备份模式。
alter tablespace exl81 begin backup;
unxi:cp /u01/app/oracle/oradate/orcl/exl81.dbf /tmp/exl81.dbf.bak
windows: ocopy c:\app\oracle\oradate\orcl\exl81.dbf c:\temp\exl81.dbf.bak
注意：在这里使用了ocopy.exe实用程序：这是oracle提供的一个程序（可以在%ORACLE_HOME%\BIN中找到它），与一些标准的windows使用程序不同，它可以复制打开的文件。
alter tablespace exl81 end backup;
对控制文件创建二进制备份，指定任何适当的目标
alter database backup controlfile to '/tmp/cf.bin';
创建控制文件的逻辑备份，指定任何适当的目标
alter databsae backup controlfile to trace as 'c:\temp\cf.log'
在丢失多路复用的控制文件后进行恢复
只要有一个幸存（未受损）的多路复用的控制文件的副本，在丢失控制文件后进行恢复就很简单。只需使用未受损的控制文件副本来替换它。在这些情况下，从备份中还原受损或丢失的控制文件副本是没有用的，因为控制文件的所有副本必须时相同的；显然，还原的副本与未受损的副本不能同步，与数据库的其余部分也不同步。
有三种选择：
第一种：可以编辑参数文件删除到丢失或受损的控制文件副本的引用。
startup force
alter system set control_file='' scope=spfile;
startup force
第二种：使用从幸存的副本中创建的副本来替换受损的文件。
第三种：更改control_file初始化参数以便使用一个指向全新的文件的引用来替换到受损文件的引用，这个新文件是在完全关闭实例时创建的一个幸存的控制文件副本。
在丢失多路复用的联机重做日志文件后进行恢复
只要联机重做日志文件时多路复用的，丢失一个成员不会造成任何停机时间，但是警报日志中会提醒您出现问题的消息。如果能容忍停机时间，那么可以关闭数据库并将该日志组中的一个幸存的成员复制到受损或丢失成员上，但是如果数据库仍然时打开的，那么显然不能这样做。
对于打开恢复，使用alter database clear logfile命令删除现有的文件并创建新的文件。只有当日志文件未激活的情况下才能完成此操作。如果试图清除当前的日志文件组或者以前仍激活的日志文件，就会收到错误消息。另外，如果数据库处于归档日志模式，则必须已经归档了日志文件组。
丢失临时文件后进行恢复
为了使用临时文件修复问题：向临时的表空间中添加另一个临时文件并删除原有的临时文件。
alter tablespace temp add tempfile '' size 50m;
alter tablespace temp drop tempfile '' size 50m;
丢失数据文件后进行恢复
介质失败导致一个或多个数据文件受损要求使用还原和恢复例程：必须还原数据文件备份，然后对它应用归档重做日志以使它与数据库的其余部分同步。
在所有情况下，必须确定文件受损的程度，通过查询V$RECOVER_FILE视图可以完成此任务，该视图将列出所有受损或丢失的数据文件。
1.以非归档模式恢复数据文件
在非归档日志模式下，没有什么支持恢复的技术，因为恢复所需的归档日志文件不存在。因此，只能进行还原。但如果通过应用归档重做日志文件，还原的数据文件与数据库的其余部分不同步，则不能打开它。
那么非归档日志模式下的唯一选择时还原整个数据库：所有数据文件和控制文件。假定所有这些文件时从全部脱机备份中还原的，那么在还原后将有一个其所有这些文件都同步的数据库，因此是个可打开的数据库。
但会丢失备份创建后所做的所有工作。
在执行了完整还原后，数据库仍会缺失其联机重做日志文件，因为他们没有被备份。由于这个原因，还原后的启动将失败，数据库处于加载模式，在加载模式下，发出alter database clear logfile group
<group number>命令重新创建所有日志文件组，然后打开数据库。如果通过DATABASE CONTROL 的RMAN接口执行还原，该过程将是完全自动的。
在非归档日志模式下，如果丢失了数百个数据文件，则只能通过最后一次备份的完整还原来纠正。必须立即回退整个数据库，丢掉用户所有的工作。而且，最后一次的备份必须时全部脱机备份，这将导致停机时间。
显然，使数据库在非归档日志模式下运行的决定不应该轻率作出。
2.
（1）以归档日志模式恢复非关键的数据文件
使受损的文件脱机
还原文件
恢复文件
将恢复的文件联机
（2）以归档日志模式恢复关键的数据文件
恢复必须在加载模式下执行，因为数据库已经崩溃并且无法打开。恢复过程没有必要将受损文件脱机，因此采取的步骤如下
a.加载数据库
b.还原文件
c.恢复文件
d.打开数据库
只能在加载模式下执行完整恢复的另一种情境是需要恢复整个数据库的时候。如果损害很严重以至于必须还原大部分数据文件，则需要这样做。在加载模式下执行此操作
recover database;
该命令将并行前滚所有还原的数据文件，并根据需要提示归档日志文件。
1.以非归档日志模式备份
当以非归档日志模式运行时必须备份那些文件呢？控制文件，和整个数据文件集，并且必须首先干净地关闭数据库。
可以在操作系统提示符上执行这些生成命令来进行完整的备份：
select 'cp' || name || '/u01/backups' from v$controlfile;
select 'cp' || name || '/u01/backups' from v$datafile;
select 'cp' || name || '/u01/backups' from v$tempfile;
select 'cp' || number || '/u01/backups' from v$logfile;
2.归档日志模式备份
启用和禁用表空间备份模式命令
alter tablespace <tablespace_name> begin backup;
alter tablespace <tablespace_name> end backup;
一次性为所有表空间启用备份模式
alter database begin backup;
alter database end backup;
备份用户数据的表空间和备份system，sysaux，undo表空间之间没有区别：只需当表空间处于备份模式时复制数据文件。但是不能备份临时表空间：甚至不能将他们置于备份模式。
alter tablespace exl81 begin backup;
unxi:cp /u01/app/oracle/oradate/orcl/exl81.dbf /tmp/exl81.dbf.bak
windows: ocopy c:\app\oracle\oradate\orcl\exl81.dbf c:\temp\exl81.dbf.bak
注意：在这里使用了ocopy.exe实用程序：这是oracle提供的一个程序（可以在%ORACLE_HOME%\BIN中找到它），与一些标准的windows使用程序不同，它可以复制打开的文件。
alter tablespace exl81 end backup;
对控制文件创建二进制备份，指定任何适当的目标
alter database backup controlfile to '/tmp/cf.bin';
创建控制文件的逻辑备份，指定任何适当的目标
alter databsae backup controlfile to trace as 'c:\temp\cf.log'
在丢失多路复用的控制文件后进行恢复
只要有一个幸存（未受损）的多路复用的控制文件的副本，在丢失控制文件后进行恢复就很简单。只需使用未受损的控制文件副本来替换它。在这些情况下，从备份中还原受损或丢失的控制文件副本是没有用的，因为控制文件的所有副本必须时相同的；显然，还原的副本与未受损的副本不能同步，与数据库的其余部分也不同步。
有三种选择：
第一种：可以编辑参数文件删除到丢失或受损的控制文件副本的引用。
startup force
alter system set control_file='' scope=spfile;
startup force
第二种：使用从幸存的副本中创建的副本来替换受损的文件。
第三种：更改control_file初始化参数以便使用一个指向全新的文件的引用来替换到受损文件的引用，这个新文件是在完全关闭实例时创建的一个幸存的控制文件副本。
在丢失多路复用的联机重做日志文件后进行恢复
只要联机重做日志文件时多路复用的，丢失一个成员不会造成任何停机时间，但是警报日志中会提醒您出现问题的消息。如果能容忍停机时间，那么可以关闭数据库并将该日志组中的一个幸存的成员复制到受损或丢失成员上，但是如果数据库仍然时打开的，那么显然不能这样做。
对于打开恢复，使用alter database clear logfile命令删除现有的文件并创建新的文件。只有当日志文件未激活的情况下才能完成此操作。如果试图清除当前的日志文件组或者以前仍激活的日志文件，就会收到错误消息。另外，如果数据库处于归档日志模式，则必须已经归档了日志文件组。
丢失临时文件后进行恢复
为了使用临时文件修复问题：向临时的表空间中添加另一个临时文件并删除原有的临时文件。
alter tablespace temp add tempfile '' size 50m;
alter tablespace temp drop tempfile '' size 50m;
丢失数据文件后进行恢复
介质失败导致一个或多个数据文件受损要求使用还原和恢复例程：必须还原数据文件备份，然后对它应用归档重做日志以使它与数据库的其余部分同步。
在所有情况下，必须确定文件受损的程度，通过查询V$RECOVER_FILE视图可以完成此任务，该视图将列出所有受损或丢失的数据文件。
1.以非归档模式恢复数据文件
在非归档日志模式下，没有什么支持恢复的技术，因为恢复所需的归档日志文件不存在。因此，只能进行还原。但如果通过应用归档重做日志文件，还原的数据文件与数据库的其余部分不同步，则不能打开它。
那么非归档日志模式下的唯一选择时还原整个数据库：所有数据文件和控制文件。假定所有这些文件时从全部脱机备份中还原的，那么在还原后将有一个其所有这些文件都同步的数据库，因此是个可打开的数据库。
但会丢失备份创建后所做的所有工作。
在执行了完整还原后，数据库仍会缺失其联机重做日志文件，因为他们没有被备份。由于这个原因，还原后的启动将失败，数据库处于加载模式，在加载模式下，发出alter database clear logfile group
<group number>命令重新创建所有日志文件组，然后打开数据库。如果通过DATABASE CONTROL 的RMAN接口执行还原，该过程将是完全自动的。
在非归档日志模式下，如果丢失了数百个数据文件，则只能通过最后一次备份的完整还原来纠正。必须立即回退整个数据库，丢掉用户所有的工作。而且，最后一次的备份必须时全部脱机备份，这将导致停机时间。
显然，使数据库在非归档日志模式下运行的决定不应该轻率作出。
2.
（1）以归档日志模式恢复非关键的数据文件
使受损的文件脱机
还原文件
恢复文件
将恢复的文件联机
（2）以归档日志模式恢复关键的数据文件
恢复必须在加载模式下执行，因为数据库已经崩溃并且无法打开。恢复过程没有必要将受损文件脱机，因此采取的步骤如下
a.加载数据库
b.还原文件
c.恢复文件
d.打开数据库
只能在加载模式下执行完整恢复的另一种情境是需要恢复整个数据库的时候。如果损害很严重以至于必须还原大部分数据文件，则需要这样做。在加载模式下执行此操作
recover database;
该命令将并行前滚所有还原的数据文件，并根据需要提示归档日志文件。
