冷备份你的数据库。因为下面的操作会对你的数据库照成 不可恢复的操作 你在服务器端,用SVRMGRL命令 SVRMGRL> connect internal; SVRMGRL> SHUTDOWN IMMEDIATE; -- or NORMAL SVRMGRL> STARTUP MOUNT; SVRMGRL> recover database until time 'YYYY-MM-DD:hh:mm:ss';--'能正常启动前的时间' SVRMGRL> ALTER DATABASE OPEN resetlogs;
查看 v$recover_file (?),看哪个文件不正常,然后 alter database datafile#n offline; 再打开试试 //如果是 SYSTEM表空间有问题当我没说
应该不是数据文件的问题, 用show parameters control_files 查看一下控制文件的文件名是否与操作系统里的控制文件的文件名相符, 若不符,则 Alter system set control_files='control_file_name' 改正确。
只能是一些建议(采用备份来恢复应该是可以的): 1、select * from v$recover_file; 2、检查跟踪日志,查看更详细的错误。(应该是在BDUMP目录里吧)如果是归档模式:试采用 recover 恢复。 如果还不行,可能只能用备份来恢复。? 如果不是归档模式:删除出错的表空间或数据文件?
ALTER DATABASE DATAFILE 8 OFFLINE; RECOVER DATAFILE 8; ALTER DATABASE DATAFILE 8 ONLINE; 看看行不行,如果不行则得用备份的该数据文件来恢复了
不可恢复的操作
你在服务器端,用SVRMGRL命令
SVRMGRL> connect internal;
SVRMGRL> SHUTDOWN IMMEDIATE; -- or NORMAL
SVRMGRL> STARTUP MOUNT;
SVRMGRL> recover database until time 'YYYY-MM-DD:hh:mm:ss';--'能正常启动前的时间'
SVRMGRL> ALTER DATABASE OPEN resetlogs;
alter database datafile#n offline;
再打开试试
//如果是 SYSTEM表空间有问题当我没说
用show parameters control_files
查看一下控制文件的文件名是否与操作系统里的控制文件的文件名相符,
若不符,则
Alter system set control_files='control_file_name'
改正确。
1、select * from v$recover_file;
2、检查跟踪日志,查看更详细的错误。(应该是在BDUMP目录里吧)如果是归档模式:试采用 recover 恢复。
如果还不行,可能只能用备份来恢复。?
如果不是归档模式:删除出错的表空间或数据文件?
RECOVER DATAFILE 8;
ALTER DATABASE DATAFILE 8 ONLINE;
看看行不行,如果不行则得用备份的该数据文件来恢复了