案例2:非归档模式下一个或多个数据文件损坏,其它文件都完好
备份方案: OS冷备份
l 开启数据库&改为非归档模式
第二篇已经介绍了归档和非归档包括如何开启和关闭归档,什么?忘了?算了,还是在小复习下吧!!!更详细的还请同学们回顾第二篇内容。
SQL> startup mount;
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1339796 bytes
Variable Size 494931564 bytes
Database Buffers 343932928 bytes
Redo Buffers 5144576 bytes
Database mounted.
SQL> alter database noarchivelog;
Database altered.
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 6
Current log sequence 8
l 关闭数据库&备份文件
SQL> shutdown immediate
[oracle@elvis elvis]$ cp users01.dbf bak/
因为模拟的数据都是存储在users表空间中,所以为了方便起见,这备份这一个数据文件
l 开启数据库&模拟数据
与上一个案例相同,在做一遍吧!一起加深印象
SQL> startup
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1339796 bytes
Variable Size 494931564 bytes
Database Buffers 343932928 bytes
Redo Buffers 5144576 bytes
Database mounted.
Database opened.
SQL> select * from test;
no rows selected
SQL> insert into test values(1,dbms_flashback.get_system_change_number);
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
重复上述步骤,最终插入数据如下:
SQL> select * from test
ID SCN
---------- ----------
1 947010
2 947042
3 947054
4 947063
5 947071 --没commit
l 模拟损坏users数据文件
[oracle@elvis elvis]$ rm -f users01.dbf
[oracle@elvis elvis]$ ll
total 1911316
drwxr-xr-x 2 oracle oinstall 4096 Oct 2 19:32 bak
-rw-r----- 1 oracle oinstall 9748480 Oct 2 19:39 control01.ctl
drwxr-x--- 4 oracle oinstall 4096 Oct 1 13:49 ELVIS
-rw-r----- 1 oracle oinstall 52429312 Oct 2 19:39 redo01.log
-rw-r----- 1 oracle oinstall 52429312 Oct 2 19:36 redo02.log
-rw-r----- 1 oracle oinstall 52429312 Oct 2 19:36 redo03.log
-rw-r----- 1 oracle oinstall 629153792 Oct 2 19:36 sysaux01.dbf
-rw-r----- 1 oracle oinstall 734011392 Oct 2 19:36 system01.dbf
-rw-r----- 1 oracle oinstall 71311360 Sep 30 11:06 temp01.dbf
-rw-r----- 1 oracle oinstall 408952832 Oct 2 19:36 undotbs01.dbf
然后关闭数据库
SQL> shutdown abort
ORACLE instance shut down.
l 开启数据库
SQL> startup
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1339796 bytes
Variable Size 494931564 bytes
Database Buffers 343932928 bytes
Redo Buffers 5144576 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/u01/app/oracle/oradata/elvis/users01.dbf'
l 数据文件的恢复
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 947062
2 947062
3 947062
4 947062
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 947062
2 947062
3 947062
4 0
[oracle@elvis bak]$ cp users01.dbf ..
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 947062
2 947062
3 947062
4 946879 --这个就是刚还原回来的数据文件的文件头
因为是在非归档模式,所以恢复只能是不完全恢复
还有这个参数一定要注意,这个参数是个隐藏参数,之前我就因为这个参数困扰了我好长时间
SQL> show parameter _allow_
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_allow_resetlogs_corruption boolean TRUE
设置这个参数
--alter system _allow_resetlogs_corruption=true scope=spfile;
重启后生效。
这个参数一定要设置为true,据君三思介绍,这个参数可以在resetlogs的时候跳过一些一致性的检查。
SQL> recover database until cancel;
ORA-00279: change 946879 generated at 10/02/2012 19:31:02 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_02/o1_mf_1_9_%u_.ar
c
ORA-00280: change 946879 for thread 1 is in sequence #9
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-10879: error signaled in parallel recovery slave
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/elvis/system01.dbf'
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [0], [946887], [0],
[946906], [4194432], [], [], [], [], [], []
Process ID: 5744
Session ID: 125 Serial number: 5
但你会发现报了一个ora-00600错误,先不管这个,先退出sqlplus然后重新连接在正常开启数据库
SQL> startup
ORACLE instance started.
Total System Global Area 845348864 bytes
Fixed Size 1339796 bytes
Variable Size 494931564 bytes
Database Buffers 343932928 bytes
Redo Buffers 5144576 bytes
Database mounted.
Database opened.
SQL> select * from test; --数据全部丢失
no rows selected
总结:这种非归档的模式在OLTP中是非常罕见,在我认知里可能只有在OLAP中由于数据量非常庞大,归档的数据文件也非常可观,为了减少空间的压力,会选择非归档,但有几个前提条件:
1. 数据不是特别重要,允许少量丢失
2. 表空间都只为只读表空间,只为报表所用
。。。。。。。。
可能处于这些情况之下,这个模式可用,也就是说具体情况得具体分析,根据业务的需求而架设方案。
在来谈谈刚才的ora-00600错误,有关这错误请参考eygle大师的文章:
http://www.eygle.com/archives/2005/10/ora00600_2262ii.html
对于这个模式下的恢复的善后处理,以下内容引自“君三思《涂抹三思》一书”:
这种恢复方式(非归档为了保持scn一致只能resetlogs了)是没有办法中的办法,通过这种方式恢复,有可能会导致数据库中数据的不一致,如已提交的数据未写入数据文件,而未提交的数据倒是被写入了数据文件。即使数据库被打开,也能够访问其中的表和数据,也只是看起来正常,如果你注意关注数据库的Alert文件(我的11g不用找告警文件内容,直接就报出来错误了,这估计就是版本不同结果也不同吧!!!)ORA-00600错误。因此,如果数据库能够顺利打开,强烈建议马上通过EXPORT逻辑导出的方式执行一次FULL EXPORT。然后新建数据库,再通过IMPORT导入之前导出的二进制文件。
elvis
2012.10.2
知识共享~共同进步
转载请注明:
http://blog.csdn.net/elvis_dataguru/article/details/8045002