在mount状态下恢复数据文件system表空间

数据字典(包含数据库本身以及存储的所有对象的基本信息)存放在SYSTEM表空间中。当数据库处于open状态时,如果system表空间所对应的数据文件出现介质失败,当在其数据文件上进行IO时操作时,数据库会自己关闭;当数据库处于关闭状态时,如果system表空间所对应的数据文件出现介质失败,数据库将不能打开。打开时会出现如下错误:

ORA-01157: 无法标识/锁定数据文件 1 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 1: 'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF'

首先 模拟实验环境:在system表空间中建立一个test表并插入数据。

SQL> create table test (num number) tablespace system;

表已创建。

SQL> insert into test values(1);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> insert into test values(2);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> insert into test values(3);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> insert into test values(4);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> insert into test values(5);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

模拟system 表空间损坏。
SQL> host del f:\app\yang\oradata\oracl\system01.dbf
SQL> startup
ORA-32004: 指定了废弃/过时的参数
ORA-01081: 无法启动已在运行的 ORACLE - 请首先关闭它

为了重新打开数据库,就必须在mount状态下恢复该数据文件。具体步骤如下:

1)装载数据库。在执行recover database 命令或recover datafile 命令之前必须将数据库加载到mount状态。通过视图v $instance 可以查看数据库的当前状态

SQL> select status from v$instance;
STATUS
------------
MOUNTED

SQL>startup force mount
当然 如果直接使用 startup 命令 ,因数据库无法打开而加载到mount状态。

2)确定要恢复的数据文件查看视图V$recover_file 可以确定要恢复 的数据文件。

SQL> select file#,error from v$recover_file;

 FILE#    ERROR                                                               
---------- -----------------------------------------------------------------   
         1 FILE NOT FOUND
  

FILE#   用于标示数据文件号, ERROR 用于标示错误原因。文件号 1 对应 system01.dbf.                  

3)  使用cp或copy命令复制数据文件备份。在执行备份之前要复制数据文件备份到原来的地方。如果数据文件所在的磁盘没有损坏,可用如下语句:

SQL> host copy f:\system01.dbf f:\app\yang\oradata\oracl

如果其所在的磁盘损坏了,则可以先将该文件复制到其他磁盘,并使用如下语句:

alter database rename datafile f:\app\yang\oradata\oracl\system01.dbf' to 'E:\ORACLE\ORADATA\system01.dbf' ;

4) 恢复数据文件。复制数据文件后就可以使用recover 命令恢复数据库了,如果要恢复多个数据文件则可以使用recover database ,如果要恢复一个数据文件则可以使用recover datafile ,当使用recover datafile命令是可以指定数据文件名,也可以指定文件号。

SQL> recover datafile 1
ORA-00279: 更改 2281699 (在 05/08/2010 22:32:39 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\51_1_715961434.LOG
ORA-00280: 更改 2281699 (用于线程 1) 在序列 #51 中


指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 2282417 (在 05/08/2010 22:53:52 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\52_1_715961434.LOG
ORA-00280: 更改 2282417 (用于线程 1) 在序列 #52 中


ORA-00279: 更改 2319876 (在 05/09/2010 19:44:16 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\53_1_715961434.LOG
ORA-00280: 更改 2319876 (用于线程 1) 在序列 #53 中


ORA-00279: 更改 2326948 (在 05/09/2010 21:27:02 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\54_1_715961434.LOG
ORA-00280: 更改 2326948 (用于线程 1) 在序列 #54 中


ORA-00279: 更改 2328241 (在 05/09/2010 21:40:37 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\55_1_715961434.LOG
ORA-00280: 更改 2328241 (用于线程 1) 在序列 #55 中


ORA-00279: 更改 2329131 (在 05/09/2010 21:48:01 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\56_1_715961434.LOG
ORA-00280: 更改 2329131 (用于线程 1) 在序列 #56 中


ORA-00279: 更改 2329136 (在 05/09/2010 21:48:11 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\57_1_715961434.LOG
ORA-00280: 更改 2329136 (用于线程 1) 在序列 #57 中


ORA-00279: 更改 2329142 (在 05/09/2010 21:48:24 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\58_1_715961434.LOG
ORA-00280: 更改 2329142 (用于线程 1) 在序列 #58 中


ORA-00279: 更改 2329149 (在 05/09/2010 21:48:37 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\59_1_715961434.LOG
ORA-00280: 更改 2329149 (用于线程 1) 在序列 #59 中


ORA-00279: 更改 2329952 (在 05/09/2010 22:03:00 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\60_1_715961434.LOG
ORA-00280: 更改 2329952 (用于线程 1) 在序列 #60 中


ORA-00279: 更改 2329958 (在 05/09/2010 22:03:09 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\61_1_715961434.LOG
ORA-00280: 更改 2329958 (用于线程 1) 在序列 #61 中


ORA-00279: 更改 2329976 (在 05/09/2010 22:03:21 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\62_1_715961434.LOG
ORA-00280: 更改 2329976 (用于线程 1) 在序列 #62 中


ORA-00279: 更改 2329983 (在 05/09/2010 22:03:36 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\63_1_715961434.LOG
ORA-00280: 更改 2329983 (用于线程 1) 在序列 #63 中


ORA-00279: 更改 2329989 (在 05/09/2010 22:03:48 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\64_1_715961434.LOG
ORA-00280: 更改 2329989 (用于线程 1) 在序列 #64 中


ORA-00279: 更改 2330135 (在 05/09/2010 22:06:27 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\65_1_715961434.LOG
ORA-00280: 更改 2330135 (用于线程 1) 在序列 #65 中


ORA-00279: 更改 2330141 (在 05/09/2010 22:06:33 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\66_1_715961434.LOG
ORA-00280: 更改 2330141 (用于线程 1) 在序列 #66 中


已应用的日志。
完成介质恢复。
SQL> alter database open;

数据库已更改。

最后,验证数据库是否恢复成功。

SQL> select * from test;

       NUM                                                                     
----------                                                                     
         1                                                                     
         2                                                                     
         3                                                                     
         4                                                                     
         5
                                                                     

查询结果可知,数据库成功被恢复。

这里要给出一点说明 我做第一次做sytem表空间的恢复时,没有切换日志文件,执行recover datafile 1时出现;

SQL> recover datafile 1
ORA-00283: 恢复会话因错误而取消
ORA-00264: 不要求恢复

当然 如果有切换日志文件,就会和步骤4)一样了。

好了,今天就到这里了,时间不早了,我要在mount状态下恢复数据文件system表空间。。。。。。

明天见了。。。。在mount状态下恢复数据文件system表空间

上一篇:开放下载!云原生技术指南,《SOFAStack解决方案白皮书》正式发布


下一篇:Service Mesh 发展趋势(续):棋到中盘路往何方 | Service Mesh Meetup 实录