Oracle在归档模式下删除非系统文件的恢复

众所周知,我们的核心生产数据库通常都是在归档模式下运行的,更不用说还配置DG环境的了。开启归档,并保证所有归档不丢失,就能保证我们对数据库所做的任何修改不会丢失,归档日志可谓是恢复的根本,如果丢失归档,那么即使RMAN功能再强大,也无法对丢失的数据进行恢复。所以我们通常配置的RMAN策略就是全备+归档+控制文件自动备份。这里的归档不是指数据库创建以来生成的归档(那量也太大了),而是当进行RMAN非一致性备份时新产生的那部分归档日志,用来保证数据库可以前推到一致性状态,这样才能顺利open数据库。以下的测试只是想说明归档日志对恢复数据的重要性,并没有用到RMAN来进行恢复。

--------------------------------------分割线 --------------------------------------

Oracle 11G RAC 修改归档模式

Oracle手工完全恢复案例(归档模式)

Oracle手工恢复案例(非归档模式)

Oracle归档模式设置的相关指令与简要说明

Oracle 10g 归档模式下备份脚本

Oracle 归档模式与非归档模式的切换

--------------------------------------分割线 --------------------------------------

 

测试一:归档日志健全未丢失

 

--连接到Oracle,确保是运行在归档模式下

[oracle@ora10g ~]$ sqlplus / as sysdba

 

SQL*Plus: Release 10.2.0.1.0 - Production on 8 13:46:53 2014

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

 

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

 

SQL> archive log list

Database log mode              Archive Mode    --归档模式

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     172

Next log sequence to archive   174

Current log sequence           174

SQL> set lin 130 pages 130

SQL> col name for a45

SQL> select file#,name from v$datafile;

 

     FILE# NAME

---------- ---------------------------------------------

         1 /u01/app/oracle/oradata/ora10g/system01.dbf

         2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf

         3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf

         4 /u01/app/oracle/oradata/ora10g/users01.dbf

         5 /u01/app/oracle/oradata/ora10g/example01.dbf

 

--创建测试表空间、用户、表

SQL> create tablespace zlm_test datafile '/u01/app/oracle/oradata/ora10g/zlm01.dbf' size 50m;

 

Tablespace created.

 

SQL> create user zlm identified by zlm default tablespace zlm_test;

 

User created.

 

SQL> grant connect,resource to zlm; --赋权限

 

Grant succeeded.

 

SQL> select file#,name from v$datafile;

 

     FILE# NAME

---------- ---------------------------------------------

         1 /u01/app/oracle/oradata/ora10g/system01.dbf

         2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf

         3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf

         4 /u01/app/oracle/oradata/ora10g/users01.dbf

         5 /u01/app/oracle/oradata/ora10g/example01.dbf

         6 /u01/app/oracle/oradata/ora10g/zlm01.dbf    --新增了6号文件作为测试表存放的物理介质

 

6 rows selected.

 

SQL> create table zlm.test1 as select rownum as id,object_name from dba_objects where rownum<=5;

 

Table created.

 

SQL> col object_name for a15

SQL> select * from zlm.test1;

 

        ID OBJECT_NAME

---------- ---------------

         1 ICOL$

         2 I_USER1

         3 CON$

         4 UNDO$

         5 C_COBJ#

 

--查看当前online日志文件状态

SQL> select group#,status,archived from v$log;

 

    GROUP# STATUS           ARC

---------- ---------------- ---

         1 INACTIVE         YES

         2 INACTIVE         YES

         3 CURRENT          NO    --当前日志组为3,未归档

 

--归档当前日志(多次)

SQL> alter system archive log current;

 

System altered.

 

SQL> alter system archive log current;

 

System altered.

 

SQL> alter system archive log current;

 

System altered.

 

这里进行了3次归档当前日志文件的操作,目的是使online日志被刷新,强制其归档,写到归档日志中去,因为我们要测试的是归档,否则恢复文件时,会自动去online日志中查找,即便是非归档模式,只要online日志还未被刷新,依旧是可以恢复的

 

SQL> select group#,status,archived from v$log;

 

    GROUP# STATUS           ARC

---------- ---------------- ---

         1 INACTIVE         YES

         2 INACTIVE         YES

         3 CURRENT          NO    --虽然看起来和刚才上一步一致,但此时其实已经把第3组online日志刷新掉了

 

--保险起见,再归档一次(可选)

SQL> alter system archive log current;

 

System altered.

 

SQL> select group#,status,archived from v$log;

 

    GROUP# STATUS           ARC

---------- ---------------- ---

         1 CURRENT          NO

         2 INACTIVE         YES

         3 ACTIVE           YES    --现在新一轮的第3组的日志也已经归档了

 

--一致性关闭数据库,在OS级别删除测试文件datafile 6

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> !

[oracle@ora10g ~]$ cd $ORACLE_BASE/oradata/ora10g

[oracle@ora10g ora10g]$ ll -lrth

total 1.7G

-rw-r----- 1 oracle oinstall  51M Sep  5 10:13 test02.dbf

-rw-r----- 1 oracle oinstall 301M Sep  5 10:13 test01.dbf

-rw-r----- 1 oracle oinstall 201M Sep 16 16:56 temp01.dbf

-rw-r----- 1 oracle oinstall  51M Sep 18 13:49 redo02.log

-rw-r----- 1 oracle oinstall  51M Sep 18 13:51 redo03.log

-rw-r----- 1 oracle oinstall  51M Sep 18 13:51 zlm01.dbf

-rw-r----- 1 oracle oinstall  31M Sep 18 13:51 users01.dbf

-rw-r----- 1 oracle oinstall 166M Sep 18 13:51 undotbs01.dbf

-rw-r----- 1 oracle oinstall 561M Sep 18 13:51 system01.dbf

-rw-r----- 1 oracle oinstall 271M Sep 18 13:51 sysaux01.dbf

-rw-r----- 1 oracle oinstall  51M Sep 18 13:51 redo01.log

-rw-r----- 1 oracle oinstall 101M Sep 18 13:51 example01.dbf

-rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control03.ctl

-rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control02.ctl

-rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control01.ctl

[oracle@ora10g ora10g]$ rm -f zlm01.dbf 

[oracle@ora10g ora10g]$ exit

exit

 

--重启数据库

SQL> startup

ORACLE instance started.

 

Total System Global Area  285212672 bytes

Fixed Size                  1218992 bytes

Variable Size              88082000 bytes

Database Buffers          192937984 bytes

Redo Buffers                2973696 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'

 

可以看到,此时是无法open数据库的,因为数据库文件物理上已经不存在,而在控制文件中是有记录的,这里提示的是“cannot identify/lock data file 6”,而当如果仅仅是物理上存在,数据文件头中的信息与控制文件中记录的数据文件头信息不一致时,会提示xxx文件需要恢复

 

--手动创建一个datafile 6

SQL> alter database create datafile 6;

 

Database altered.

 

注意,此时仅仅是创建了一个不一致的datafile 6而已,也可以通过RMAN的restore datafile 6;命令来实现,作用是一样的

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/890dfb7716b5753121347e27a8856394.html