实验环境

操作系统 Redhat5.4 x86数据库版本 oracle 11gR2 (11.2.0.1.0)实验前已经做了RMAN全量备份包括controlfile、spfile

实验模拟

案例模拟

模拟temp表空间数据文件损坏或丢失：

[oracle@node1 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Sun May 7 10:37:29 2017 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> col tablespace_name for a30 SQL> col file_name for a60 SQL> set line 100 SQL> select tablespace_name, file_name from dba_temp_files; TABLESPACE_NAME FILE_NAME ------------------------------ ------------------------------------------------------------ TEMP1 /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf SQL> !rm /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf SQL> !ls /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf ls: /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf: No such file or directory --操作系统命令提示文件不存在。 SQL> exit

案例恢复

首先，我们尝试使用rman list failure看看能否检查到文件丢失：

[oracle@node1 ~]$ rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Sun May 7 10:39:54 2017 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: PROD (DBID=352761597) RMAN> list failure; using target database control file instead of recovery catalog no failures found that match specification RMAN> advise failure; no failures found that match specification RMAN> exit Recovery Manager complete. --RMAN 无法检测到temp表空的文件丢失或损坏情况。

其次，我们尝试直接重启数据库看看会有什么报错信息没有：

SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup; ORACLE instance started. Total System Global Area 836976640 bytes Fixed Size 1339740 bytes Variable Size 679480996 bytes Database Buffers 150994944 bytes Redo Buffers 5160960 bytes Database mounted. Database opened. SQL> !ls /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf --重启完操作系统以后发现被手动删除的文件已经自动恢复了。 SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options

接着，检查下数据库alert日志发现以下信息：

Sun May 07 10:48:27 2017 ARC3 started with pid=21, OS id=5425 Re-creating tempfile /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf --丢失的tempfile文件被re-create出来了。

以上说明，当数据库中丢失或损坏的文件是临时表空文件的时候，我们无法利用RMAN进行恢复，在重启数据库后会自动将丢失的tempfile文件re-create出来。

那如果不重启数据库是否有方法进行修复呢？

这里结合temp表空间的工作原理想想，由于temp表空中存放的是临时数据库运行过程中的SQL所产生的临时的过程中的信息，不需要永久保存的。 因此，我们可以考虑向临时表空中新增一个新的数据文件，然后将损坏的数据文件删除，详细步骤如下：

SQL> select tablespace_name, file_name,bytes/1024/1024M from dba_temp_files; TABLESPACE_NAME FILE_NAME M ------------------------------ ------------------------------------------------------------ ---------- TEMP1 /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf 50 SQL> !rm /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf SQL> !ls /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf ls: /u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf: No such file or directory SQL> alter tablespace temp1 add tempfile '/u01/app/oracle/oradata/PROD/disk4/temp1_02.dbf' size 50M; Tablespace altered. SQL> alter tablespace temp1 drop tempfile '/u01/app/oracle/oradata/PROD/disk4/temp1_01.dbf'; Tablespace altered. SQL> select tablespace_name, file_name,bytes/1024/1024M from dba_temp_files; TABLESPACE_NAME FILE_NAME M ------------------------------ ------------------------------------------------------------ ---------- TEMP1 /u01/app/oracle/oradata/PROD/disk4/temp1_02.dbf 50 SQL>

同样，也可以利用重新创建一个temp表空，然过后将默认temp表空间修改为新建的表空间，然后把有问题的temp表空间drop掉，同样可以达到修复temp表空的目的。

总结： 从上面的测试发现，当数据库中temp表空间中的数据文件损坏或丢失情况下，使用rman是无法进行恢复的。 可以通过，直接重启数据库，或者新建临时表空或者新增tempfile方法进行修复。