http://blog.csdn.net/KasenHOo/archive/2009/06/30/4309257.aspx
上次这个问题,当时是解决了oracle当机,能启动了。
第二天报错,提示说 undotbs01.dbf文件找不到。
后来想想,是因为前一天我只把undotbs01 offline drop了,没有物理del掉,所以找不到文件。
但问题是,既然已经offline drop了,为什么还去找它呢?搞不懂。
后来想想既然如此,就直接del掉了。
在网上找了无数处理方法,一般都如下:
如果你是使用Oracle9i,就用SQLPLUS代替SVRMGRL执行以下的命令。
1. 数据文件存在,但是Oracle认不到它
这种情况可能是在操作系统级上数据文件被重命名了或者移动到了一个新的分区或者位置,这种情况比较简单,只是需要将数据文件恢复成原始的数据文件名字或者重新命名数据文件到一个新的位置/目录就可以解决问题了。
重新命名数据文件到一个新的位置/目录的方法:
A. 数据库是打开状态的
1)查看那个数据文件所在的表空间还包含有哪些数据文件,执行以下查询:
SELECT FILE_NAME, STATUS FROM DBA_DATA_FILES
WHERE TABLESPACE_NAME = '';
2)确定所有数据文件的状态都是可用的。
3)把表空间变成只读表空间:
ALTER TABLESPACE READ ONLY;
4)确定在数据字典中表空间是显示为只读的:
SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = '';
TABLESPACE_NAME STATUS
------------------------------ ---------
READ ONLY
5)用操作系统命令拷贝数据文件到一个新的位置,拷贝完成后把整个表空间OFFLINE,这个时候用户是不能访问这个表空间的:
ALTER TABLESPACE OFFLINE;
6)重命名这个数据文件到一个新的位置了,这个操作会自动的更新控制文件中的内容:
ALTER DATABASE RENAME FILE
'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'
TO
'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF';
7)ONLINE这个表空间:
ALTER TABLESPACE YOUR_TABLESPACE_NAME ONLINE;
8)把这个表空间置成可读写的状态:
ALTER TABLESPACE YOUR_TABLESPACE_NAME READ WRITE;
9)在操作系统级上删除原来旧的数据文件。
B.数据库是关闭状态的
1) 先正常关闭数据库。
2) 用操作系统命令拷贝数据文件到一个新的位置。
3) MOUNT数据库,这样将读取控制文件,但是不会读取数据文件:
STARTUP MOUNT
4) 重命名这个数据文件到一个新的位置了,这个操作会自动的更新控制文件中的内容:
ALTER DATABASE RENAME FILE
'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'
TO
'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF';
5) 打开数据库:
ALTER DATABASE OPEN;
2. 数据文件不存在或者对于Oracle来说是不可用的
数据文件被物理的移走了或者损坏导致Oracle不能再认到了,例如数据文件被截断或者覆盖了,一般会出现ORA-27046、ORA-1157的错误提示:
ORA-27046: file size is not a multiple of logical block size
这种情况下可以有两种选择去解决问题:
A. 重建数据文件所属的那个表空间
这种方法比较适用于USERS、TEMP、INDEX表空间,如果数据库是正常关闭的,也就是说回滚段中没有激活的表空间事务,也推荐使用这种方法。如果是SYSTEM表空间,则要重建数据库了。
具体步骤如下:
1) MOUNT数据库:
STARTUP MOUNT PFILE='';
2) OFFLINE DROP数据文件:
ALTER DATABASE DATAFILE '' OFFLINE DROP;
3) 打开数据库:
ALTER DATABASE OPEN;
4) 删除表空间:
DROP TABLESPACE INCLUDING CONTENTS;
5) 重建表空间:
CREATE TABLESPACE DATAFILE
' SIZE ;
6) 重建表空间中所有以前存在的对象:可以使用以前创建对象的脚本或者利用最近可用的EXPORT DUMP来重建以前存在的对象。
B.用正常的恢复过程去恢复数据文件
这种方法比较适用于只读表空间或者那种不能用重建表空间的方法的USERS和INDEX表空间。如果是回滚段表空间,那必须要求数据库是正常关闭的才能使用这个方法。如果是SYSTEM表空间,并且备份和所有的归档日志都全的情况下,强烈建议使用这种方法去恢复的,但是如果是非归档方式,则就只能利用当前所有的联机日志进行恢复了。
在很多的情况下,重建表空间是不可能的或者是非常费时费力的,因此,从备份和利用归档日志恢复数据文件是一种比较好的方法,尤其是对于只读表空间来说,因为没有数据的写入和更改,因此直接用备份来恢复是最快最省事的。
具体步骤如下:
1) 从备份中恢复丢失或者损坏的数据文件。
2) MOUNT数据库:
STARTUP MOUNT PFILE='';
3) 执行以下的查询:
SELECT V1.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP#;
这个查询将列出所有联机重做日志以及它们所代表的SEQUENCE和FIRST CHANGE NUMBER.
4) 如果数据库是非归档状态下的,执行以下的查询:
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
如果CHANGE#大于最小的联机重做日志文件的FIRST_CHANGE#,那么数据文件可以被恢复,记住恢复数据文件的时候要应用所有的联机重做日志文件,然后到第5步。
如果CHANGE#小于最小的联机重做日志文件的FIRST_CHANGE#,那么这个数据文件将不能被恢复了,那么只能从最近的数据库全备份恢复或者重建这个数据文件所属的表空间了。
5) 恢复数据文件:
RECOVER DATAFILE '';
6) 确认所有的归档日志都被应用了直至出现"Media recovery complete"的提示信息,如果Oracle提示有一个不存在的归档日志文件,那么就可能要应用所有的联机重做日志文件来恢复直至出现"Media recovery complete"的提示信息。
7) 打开数据库:
ALTER DATABASE OPEN;
3. 数据库临时表空间的数据文件的丢失
当数据库的临时表空间的数据文件丢失也会引起ORA-01157的错误。因为数据库对临时表空间的数据文件不会发生检查点,所以这个时候数据库照样能够打开。这种情况下的解决方法是逻辑上删除临时表空间的数据文件,并且重新增加一个新的临时表空间的数据文件。
例如:
SELECT * FROM DBA_OBJECTS ORDER BY OBJECT_NAME;
select * from dba_objects order by object_name;
* ERROR at line 1:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/Oracle/oradata/temp01.dbf'
ALTER DATABASE TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ DROP;
SELECT TABLESPACE_NAME,FILE_NAME FROM DBA_TEMP_FILES;
ALTER TABLESPACE TEMP ADD TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ SIZE 100M;