背景
一个库由于需要恢复，留存的数据包括所有的数据文件和redo和controlfile
记录下恢复过程
- 修改pfile中controlfile的位置,用pfile启动到nomount
- 启动数据库到mount状态,并转储控制文件
- 根据转储的控制文件修改数据库中datafile的位置
- 打开数据库
- 根据alert来修正错误
关键点
关键点1
pfile里面主要修改的就是db_name,要和原库对应的control里面的名字对应上 修改没问题后，可以以spfile的方式启动
关键点2
转储控制文件
alter database backup controlfile to trace as '路径';
可以查看里面数据文件的位置,再对应上传到服务器的数据文件的位置进行修改
alter database rename file 'path-old-xxx' to 'path-new-xxx';
关键点3
一直打开alert日志进行追踪,在几个阶段都非常有用
startup nomount;
alter database mount;
alter database open;
关键点4
如果undo的文件找不到,会报错的,根据alter日志,在mount状态可以先将undo_tablespace修改为已经存在的undotbs2
在mount状态下可以查询select name from v$datafile;来获取相应的数据文件的位置
关键点5
默认的redo的位置可能和规划的位置不一样,可以采取先创建再删除再创建的方式进行替换
删除状态为inactive的redo
select * from v$log;
alter database drop logifle group x;
alter database add logifle group x 'path-xxxx' size xxxM ;
关键点6
临时文件的位置可能和规划的位置不一样,可以采取先添加临时数据文件再删除老的临时文件
alter tablespace temp add tempfile 'path-new-xxxx' size 10G autoextend;
alter tablespace temp drop tempfile 'path-old-xxxx';
关键点7
第一次恢复完,在打开数据库的时候报错:
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
这个说明是老的数据文件对应的数据库版本和新的数据库的版本不一致! 如果老的版本小于新的版本,那么可以更新数据字典来打开数据库;
@?/rdbms/admin/catalog.sql
@?/rdbms/admin/catproc.sql
如果老的版本大于新的版本,那么就只能装一个和老的版本的一样的库再来重复上面的恢复操作!! 否则,就算执行了上面的2个脚本,也会报如下类似的错误:
ORA-00600 [qcisSetPlsqlCtx:tzi init]
mos有个文章可以参考 : ORA-600 [qcisSetPlsqlCtx:tzi init] after Database Restart (文档 ID 362036.1)
上面说的主要是干一件事情： 查询所用到的时区的TZ file
select NAME, VALUE$ from SYS.PROPS$ where NAME like ('DST_%_TT_VERSION');
然后去 $ORACLE_HOME/oracore/zoneinfo/ 下查看否有上面提及的TZ file 当然，因为这儿是新的库的版本比老的数据文件对应的数据库版本低，所以按照上面的操作做了也没有多大的用！