2. 将损坏的数据文件处于offline状态：
svrmgrl>alter database datafile‘datafile_name’ offline;
3. 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。
4. 恢复数据文件：
svrmgrl>alter database recover datafile‘file_name’;
5. 使数据库文件online：
svrmgrl>alter database datafile‘datafile_name’ online;
6. 用适当的方法进行数据库全备份。
2.3.2 system表空间的数据文件损坏：
1. 以mount方式启动数据库
svrmgrl>startup mount;
2. 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。
3. 恢复system表空间：
svrmgrl>alter database recover datafile‘datafile_name’;
4. 打开数据库：
svrmgrl>alter database open;
5. 用适当的方法进行数据库全备份。
2.4表空间损坏：
若非system表空间已经损坏，则数据库仍然可以处于打开状态可以进行操作，只是损坏的表空间不能访问。这样在数据库打开状态下可以单独对损坏的表空间进行恢复。若是system表空间损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开，然后再对表空间进行恢复。可以通过查看数据库日志文件来判断当前损坏的表空间是否是system表空间.
2.4.1非system表空间损坏：
1. 将损坏的表空间处于offline状态：
svrmgrl>alter tablespace‘tablespace_name’ offline;
2. 从相应的备份结果集中恢复关于这个表空间最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。
3. 恢复表空间：
svrmgrl>alter database recovertablespace ‘tablespace_name’;
4. 使表空间online：
svrmgrl>alter tablespace‘tablespace_name’ online;
5. 用适当的方法进行数据库全备份.
2.4.2 system表空间损坏：
1. 以mount方式启动数据库
svrmgrl>startup mount;
2. 从相应的备份结果集中恢复system表空间最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。
3. 恢复system表空间：
svrmgrl>alter database recovertablespace system;
4. 打开数据库：
svrmgrl>alter database open;
5. 用适当的方法进行数据库全备份。
3、Oracle逻辑结构故障的处理方法：
逻辑结构的故障一般指由于人为的误操作而导致重要数据丢失的情况。在这种情况下数据库物理结构是完整的也是一致的。对于这种情况采取对原来数据库的全恢复是不合适的，我们一般采用三种方法来恢复用户数据。
3.1采用exp/imp工具来恢复用户数据：
如果丢失的数据存在一个以前用exp命令的备份，则可以才用这种方式。
1. 在数据库内创建一个临时用户：
svrmgrl>create user test_user identifiedby test;
svrmgrl>grant connect，resource totest_user;
2. 从以前exp命令备份的文件中把丢失数据的表按照用户方式倒入测试用户：
$imp system/manager file=export_file_name tables=(lost_data_table_name…)fromuser=lost_data_table_owner touser=test_user constraint=n;
3. 用相应的DML语句将丢失的数据从测试用户恢复到原用户。
4. 将测试用户删除：
svrmgrl>drop user test_user cascede;
3.2 采用logminer来恢复用户数据：
Logminer是oracle提供的一个日志分析工具。它可以根据数据字典对在线联机日志、归档日志进行分析，从而可以获得数据库的各种DML操作的历史记录以及各种DML操作的回退信息。根据这些用户就可以将由于误操作而丢失的数据重新加入数据库内。
1. 确认数据库的utl_file_dir参数已经设置，如果没有则需要把这个参数加入oracle的初始化参数文件，然后重新启动数据库。下面例子中假设utl_file_dir=’/opt/oracle/db01’；
2. 创建logminer所需要的数据字典信息
假设生成的数据字典文本文件为dict.ora：
svrmgrl> executedbms_logmnr_d.build(dictionary_filename=>'dict.ora',dictionary_location=>'/opt/oracle/db01');
3. 确定所需要分析的日志或者归档日志的范围。这可以根据用户误操作的时间来确定大概的日志范围。假设用户误操作时可能的日志文件为/opt/oracle/db02/oradata/ORCL/redo3.log和归档日志’/opt/oracle/arch/orcl/orclarc_1_113.ora’。
4. 创建要分析的日志文件列表，按日志文件的先后顺序依次加入：
svrmgrl>executedbms_logmnr.add_logfile(logfilename=>'/opt/oracle/arch/orcl/orclarc_1_113.ora'，options=>dbms_logmnr.NEW);
svrmgrl>executedbms_logmnr.add_logfile(logfilename=>'/opt/oracle/db02/oradata/ORCL/redo3.log'，options=>dbms_logmnr.ADDFILE);
5. 开始日志分析，假设需要分析的时间在’2003-06-2812:00:00’和’2003-06-28 13:00:00’之间：
svrmgrl>executedbms_logmnr.start_logmnr(
dictfilename=>’/opt/oracle/db01/dict.ora’，
starttime=>to_date(’2003-06-28 12:00:00’，’YYYY-MM-