【恢复】临时表空间损坏的两种恢复方法

当排序在内存中无法完成时就会使用临时表空间进行排序，如果临时表空间出现了问题会严重地影响系统运行性能。
当临时表空间出现异常不可用时，该如何进行恢复呢？

常用的有两种方法，一种方法我称其为“重新启动法”，另外一种方法权且称做“新增替换法”吧。实验分解之。

1.“重新启动法”
难道当临时表空间出现故障时，仅仅通过重新启动数据库就可以搞定么？答案是喜人的：YES！
以此实验为证。
1）使用dba_temp_files视图简单查看一下临时表空间的基本信息
sys@ora10g> col TABLESPACE_NAME for a15
sys@ora10g> col FILE_NAME for a33
sys@ora10g> select tablespace_name,file_id,file_name,bytes/1024/1024 Mbytes from dba_temp_files;

TABLESPACE_NAME    FILE_ID FILE_NAME                             MBYTES
--------------- ---------- --------------------------------- ----------
TEMP                     1 /oracle/oradata/ora10g/temp01.dbf       2327

2）删除临时表空间的数据文件“temp01.dbf”，模拟临时表空间故障。
sys@ora10g> !rm -f /oracle/oradata/ora10g/temp01.dbf

3）此时如果系统出现大规模排序操作（如创建索引、创建主键或order by等操作），就会得到类似如下的报错信息。
sec@ora10g> alter table t add constraint pk_t primary key(x);
alter table t add constraint pk_t primary key(x)
*
ERROR at line 1:
ORA-01116: error in opening database file 201
ORA-01110: data file 201: '/oracle/oradata/ora10g/temp01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

4）使用“重新启动法”进行恢复
（1）关闭数据库
sec@ora10g> conn / as sysdba
Connected.
sys@ora10g> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

如果您足够细心会发现，在关闭数据库的过程中alert文件同样会记录相关错误信息，并且为此故障生成一个trace文件，trace文件内容也是简单的记录关于临时文件故障的信息。
alert文件中报错信息摘录如下（trace文件内容类似，这里省略）：
Errors in file /oracle/app/oracle/admin/ora10g/udump/ora10g_ora_12245.trc:
ORA-01110: data file 201: '/oracle/oradata/ora10g/temp01.dbf'
ORA-01116: error in opening database file 201
ORA-01110: data file 201: '/oracle/oradata/ora10g/temp01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

（2）启动数据库
sys@ora10g> startup;
ORACLE instance started.

Total System Global Area 5368709120 bytes
Fixed Size                  2080320 bytes
Variable Size             905970112 bytes
Database Buffers         4445962240 bytes
Redo Buffers               14696448 bytes
Database mounted.
Database opened.

此时在alert中记录的信息非常令人振奋：“重新创建了temp01.dbf文件”
Wed Dec  9 22:49:39 2009
Re-creating tempfile /oracle/oradata/ora10g/temp01.dbf

5）验证“重新启动法”的成果
sys@ora10g> select tablespace_name,file_id,file_name,bytes/1024/1024 Mbytes from dba_temp_files;

TABLESPACE_NAME    FILE_ID FILE_NAME                             MBYTES
--------------- ---------- --------------------------------- ----------
TEMP                     1 /oracle/oradata/ora10g/temp01.dbf         20

sys@ora10g> !ls -l /oracle/oradata/ora10g/temp01.dbf
-rw-r----- 1 oracle oinstall 20979712 Dec  9 22:49 /oracle/oradata/ora10g/temp01.dbf

临时文件已经被创建成功。
细节不容错过：原来被撑大到2G多的临时文件现在恢复到了20M的大小！（旁门左道式启发：可以使用这种先删除临时文件再重新启动数据库的方法解决临时表空间过大的问题。注意：此方法不推荐使用。）

2.“新增替换法”
顾名思义，就是全新创建一个临时数据文件，替换掉出问题的临时数据文件。
您可能要问了，既然通过简单的重新启动数据库就可以搞定的问题，有必要这么大费周折吗？绝对有必要！因为您手中的生产系统很可能是那种要求7*24小时全年无休类型。这种情况下是不会允许你轻易重新启动数据库的，影响太坏！
展示一下这种较为“周折”的“稳妥”方法。
1）同样，删除临时数据文件，模拟临时表空间损坏。
sys@ora10g> !rm -f /oracle/oradata/ora10g/temp01.dbf

2）同样的报错
sys@ora10g> conn sec/sec
Connected.
sec@ora10g> alter table t add constraint pk_t primary key(x);
alter table t add constraint pk_t primary key(x)
*
ERROR at line 1:
ORA-01116: error in opening database file 201
ORA-01110: data file 201: '/oracle/oradata/ora10g/temp01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

3）为临时表空间TEMP添加一个新的临时数据文件
sys@ora10g> alter tablespace temp add tempfile '/oracle/oradata/ora10g/temp02.dbf' size 50m;

Tablespace altered.

sys@ora10g> !ls -l /oracle/oradata/ora10g/temp*
-rw-r----- 1 oracle oinstall 52436992 Dec  9 23:12 /oracle/oradata/ora10g/temp02.dbf

4）如果此时尝试完成排序仍然是不被允许的
sec@ora10g> alter table t add constraint pk_t primary key(x);
alter table t add constraint pk_t primary key(x)
*
ERROR at line 1:
ORA-01116: error in opening database file 201
ORA-01110: data file 201: '/oracle/oradata/ora10g/temp01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

因为系统中还存在temp01.dbf的定义。
sys@ora10g> col TABLESPACE_NAME for a15
sys@ora10g> col FILE_NAME for a33
sys@ora10g> select tablespace_name,file_id,file_name,bytes/1024/1024 Mbytes from dba_temp_files;

TABLESPACE_NAME    FILE_ID FILE_NAME                             MBYTES
--------------- ---------- --------------------------------- ----------
TEMP                     1 /oracle/oradata/ora10g/temp01.dbf         20
TEMP                     2 /oracle/oradata/ora10g/temp02.dbf         50

5）需要手工将出问题的临时数据文件删除掉
sys@ora10g> alter tablespace temp drop  tempfile '/oracle/oradata/ora10g/temp01.dbf';

Tablespace altered.

确认一下系统中出问题的临时数据文件temp01.dbf已经被清除。
sys@ora10g> select tablespace_name,file_id,file_name,bytes/1024/1024 Mbytes from dba_temp_files;

TABLESPACE_NAME    FILE_ID FILE_NAME                             MBYTES
--------------- ---------- --------------------------------- ----------
TEMP                     2 /oracle/oradata/ora10g/temp02.dbf         50

6）到此，临时表空间的故障在没有重启数据库的情况下处理完成。
（1）尝试完成之前需要大量排序的动作——创建主键。
sec@ora10g> alter table t add constraint pk_t primary key(x);
alter table t add constraint pk_t primary key(x)
*
ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

（2）此时的报错原因与之前模拟的故障没有关系，是因为在增加temp02.dbf时没有允许其自动增长，分配的50M空间过小导致的。
修改临时文件temp02.dbf为自增长，为防止其无限制的扩大，限制其最大值为1G。
sys@ora10g> alter database tempfile '/oracle/oradata/ora10g/temp02.dbf' autoextend on maxsize 1g;

Database altered.

（3）处理完这个小问题之后，主键创建工作得以顺利完成
sec@ora10g> alter table t add constraint pk_t primary key(x);

Table altered.

此时临时文件被扩大到234M。
sys@ora10g> select tablespace_name,file_id,file_name,bytes/1024/1024 Mbytes from dba_temp_files;

TABLESPACE_NAME    FILE_ID FILE_NAME                             MBYTES
--------------- ---------- --------------------------------- ----------
TEMP                     2 /oracle/oradata/ora10g/temp02.dbf        234

（4）如果此时再次删除临时数据文件“temp02.dbf”，使用第一种“重新启动法”进行恢复，恢复后的临时数据文件会恢复为创建时的50M大小，并且最大还是可扩张到1G。

3.小结
处理临时文件故障时，无论是“重新启动法”还是“新增替换法”都是可以达到我们恢复的目的，但是需要具体问题具体分析。萝卜青菜各有所爱，关键是在处理故障时的冷静、沉着和果断。

Good luck.

secooler
09.12.09

-- The End --

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/519536/viewspace-622080/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/519536/viewspace-622080/