快捷搜索:

【Oracle备份恢复】3、数据库恢复案例(7)

案例3:归档日志的毁坏(不完全规复)

(1)查看归档日志文件寄放的路径

SQL> show parameter db_recover

NAMETYPEVALUE

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

db_recovery_file_deststring/u01/oracle/flash_recovery_are

a

db_recovery_file_dest_sizebig integer 4977M

SQL> show parameter archive

NAMETYPEVALUE

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

archive_lag_targetinteger0

log_archive_configstring

log_archive_deststring

log_archive_dest_1string

log_archive_dest_10string

log_archive_dest_11string

log_archive_dest_12string

log_archive_dest_13string

log_archive_dest_14string

log_archive_dest_15string

log_archive_dest_16string

NAMETYPEVALUE

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

log_archive_dest_17string

log_archive_dest_18string

log_archive_dest_19string

log_archive_dest_2string

log_archive_dest_20string

log_archive_dest_21string

log_archive_dest_22string

log_archive_dest_23string

log_archive_dest_24string

log_archive_dest_25string

log_archive_dest_26string

NAMETYPEVALUE

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

log_archive_dest_27string

log_archive_dest_28string

log_archive_dest_29string

log_archive_dest_3string

log_archive_dest_30string

log_archive_dest_31string

log_archive_dest_4string

log_archive_dest_5string

log_archive_dest_6string

log_archive_dest_7string

log_archive_dest_8string

NAMETYPEVALUE

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

log_archive_dest_9string

log_archive_dest_state_1stringenable

log_archive_dest_state_10stringenable

log_archive_dest_state_11stringenable

log_archive_dest_state_12stringenable

log_archive_dest_state_13stringenable

log_archive_dest_state_14stringenable

log_archive_dest_state_15stringenable

log_archive_dest_state_16stringenable

log_archive_dest_state_17stringenable

log_archive_dest_state_18stringenable

NAMETYPEVALUE

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

log_archive_dest_state_19stringenable

log_archive_dest_state_2stringenable

log_archive_dest_state_20stringenable

log_archive_dest_state_21stringenable

log_archive_dest_state_22stringenable

log_archive_dest_state_23stringenable

log_archive_dest_state_24stringenable

log_archive_dest_state_25stringenable

log_archive_dest_state_26stringenable

log_archive_dest_state_27stringenable

log_archive_dest_state_28stringenable

NAMETYPEVALUE

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

log_archive_dest_state_29stringenable

log_archive_dest_state_3stringenable

log_archive_dest_state_30stringenable

log_archive_dest_state_31stringenable

log_archive_dest_state_4stringenable

log_archive_dest_state_5stringenable

log_archive_dest_state_6stringenable

log_archive_dest_state_7stringenable

log_archive_dest_state_8stringenable

log_archive_dest_state_9stringenable

log_archive_duplex_deststring

NAMETYPEVALUE

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

log_archive_formatstring%t_%s_%r.dbf

log_archive_local_firstbooleanTRUE

log_archive_max_processesinteger4

log_archive_min_succeed_destinteger1

log_archive_startbooleanFALSE

log_archive_traceinteger0

standby_archive_deststring?/dbs/arch

血色部分是创建归档日志文件的款式,都代表什么含义请参考

http://blog.csdn.net/elvis_dataguru/article/details/8066954

显着发明可以指定的路径增多

根据这个路径

[oracle@elvis 2012_10_13]$ pwd

/u01/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_13

[oracle@elvis 2012_10_13]$ ll

total 2368

-rw-r----- 1 oracle oinstall 2419200 Oct 13 09:16 o1_mf_1_76_87kj7n9q_.arc

76是重做日志文件的sequence#号码

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

GROUP#SEQUENCE# ARC STATUS

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

176 YES INACTIVE

277 NOCURRENT

375 YES INACTIVE

从这个视图中可以看出,下一回归档会孕育发生77号归档文件

(2)模拟数据

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;

IDSCN

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

1751174

看看天生的归档日志文件

[oracle@elvis 2012_10_13]$ ll

total 11836

-rw-r----- 1 oracle oinstall 2419200 Oct 13 09:16 o1_mf_1_76_87kj7n9q_.arc

-rw-r----- 1 oracle oinstall 9676800 Oct 13 18:30 o1_mf_1_77_87ljppo8_.arc

继承模拟数据

SQL> select * from test;

IDSCN

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

1751174

2751225

3751232

4751239

[oracle@elvis 2012_10_13]$ ll

total 11848

-rw-r----- 1 oracle oinstall 2419200 Oct 13 09:16 o1_mf_1_76_87kj7n9q_.arc

-rw-r----- 1 oracle oinstall 9676800 Oct 13 18:30 o1_mf_1_77_87ljppo8_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 18:32 o1_mf_1_78_87ljtm43_.arc

-rw-r----- 1 oracle oinstall3072 Oct 13 18:33 o1_mf_1_79_87ljtyo6_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 18:33 o1_mf_1_80_87ljv9g2_.arc

(3)备份test01.dbf数据文件(模拟数据全在这个数据文件中)

SQL> select * from test;

IDSCN

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

1751174

2751225

3751232

4751239

5751794

6751805

7751811

7 rows selected.

SQ> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@elvis elvis]$ cp test01.dbf bak/

(4)开启数据库&继承模拟数据

SQL> startup

ORACLE instance started.

Total System Global Area598437888 bytes

Fixed Size1338140 bytes

Variable Size394265828 bytes

Database Buffers197132288 bytes

Redo Buffers5701632 bytes

Database mounted.

Database opened.

SQL> insert into test values(5,dbms_flashback.get_system_change_number);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

SQL> insert into test values(6,dbms_flashback.get_system_change_number);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

SQL> insert into test values(7,dbms_flashback.get_system_change_number);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

SQL> select * from test;

IDSCN

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

1751174

2751225

3751232

4751239

5751794

6751805

7751811

8752922

9752935

10752946

11752954

IDSCN

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

12752962

13752970

13 rows selected.

又插入了6条数据,这是在备份的数据文件中没有的,插入这么多半据也是要达到覆写重做日志组的目的。

(5)毁坏归档日志文件

从77开始是新的也便是说,刚插入的数据存在77~80号归档文件中,而根据我的实验模拟的数据,可以 77号归档文件存储id=1的数据,以此类推恰恰4条数据分手存储在归档文件中,现模拟毁坏78号文件,当然归档日志实质是为了备份规复应用,假如数据不停正常,当然不会有什么问题,但假如现在数据文件损掉或者误删除了表数据,想规复就要用到归档日志文件,这时规复有个前提便是归档日志必须继续,否则断点后(也便是说假设78号文件毁坏,在它知道的归档日志文件无法正常应用)的归档日志文件无法正常应用。这样就会导致数据部分损掉。

这种环境下只能采纳不完全规复打开数据库

但有一种环境出外,那便是及时发明,虽然归档文件损掉,但重做日志文件没有被覆写,在规复时直接应用了未覆写的重做日志文件。(包括当前和非当前)

[oracle@elvis 2012_10_13]$ ll

total 11992

-rw-r----- 1 oracle oinstall 2419200 Oct 13 09:16 o1_mf_1_76_87kj7n9q_.arc

-rw-r----- 1 oracle oinstall 9676800 Oct 13 18:30 o1_mf_1_77_87ljppo8_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 18:32 o1_mf_1_78_87ljtm43_.arc

-rw-r----- 1 oracle oinstall3072 Oct 13 18:33 o1_mf_1_79_87ljtyo6_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 18:33 o1_mf_1_80_87ljv9g2_.arc

-rw-r----- 1 oracle oinstall 135168 Oct 13 19:17 o1_mf_1_81_87lmgfgh_.arc--还原点

-rw-r----- 1 oracle oinstall3072 Oct 13 19:17 o1_mf_1_82_87lmgzkz_.arc

-rw-r----- 1 oracle oinstall2560 Oct 13 19:18 o1_mf_1_83_87lmhbo5_.arc

这个82号文件是从日志组3归档而来,而日志组3并没有被覆盖,以是可以直接从日志组3获得规复数据。但在临盆数据库中这种及时发明的可能性极小。终极归纳为还原点在近来3个归档文件之中。

正常环境

[oracle@elvis 2012_10_13]$ mv o1_mf_1_85_87lon0x7_.arc o1_mf_1_85_87lon0x7_.arc.bak

[oracle@elvis 2012_10_13]$ ll

total 13452

-rw-r----- 1 oracle oinstall 2419200 Oct 13 09:16 o1_mf_1_76_87kj7n9q_.arc

-rw-r----- 1 oracle oinstall 9676800 Oct 13 18:30 o1_mf_1_77_87ljppo8_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 18:32 o1_mf_1_78_87ljtm43_.arc

-rw-r----- 1 oracle oinstall3072 Oct 13 18:33 o1_mf_1_79_87ljtyo6_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 18:33 o1_mf_1_80_87ljv9g2_.arc

-rw-r----- 1 oracle oinstall135168 Oct 13 19:17 o1_mf_1_81_87lmgfgh_.arc

-rw-r----- 1 oracle oinstall2560 Oct 13 19:18 o1_mf_1_83_87lmhbo5_.arc

-rw-r----- 1 oracle oinstall 1473024 Oct 13 19:54 o1_mf_1_84_87lomp0q_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 19:54 o1_mf_1_85_87lon0x7_.arc.bak--85损掉

-rw-r----- 1 oracle oinstall3072 Oct 13 19:55 o1_mf_1_86_87lonr0h_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 19:55 o1_mf_1_87_87loo70s_.arc

-rw-r----- 1 oracle oinstall2048 Oct 13 19:55 o1_mf_1_88_87loon0w_.arc

-rw-r----- 1 oracle oinstall2560 Oct 13 19:55 o1_mf_1_89_87lop51n_.arc

(6)模拟毁坏数据文件

[oracle@elvis 2012_10_13]$ mv o1_mf_1_85_87lon0x7_.arc o1_mf_1_85_87lon0x7_.arc.bak

SQL> startup

ORACLE instance started.

otal System Global Area598437888 bytes

Fixed Size1338140 bytes

Variable Size394265828 bytes

Database Buffers197132288 bytes

Redo Buffers5701632 bytes

Database mounted.

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

ORA-01110: data file 5: '/u01/oracle/oradata/elvis/test01.dbf'

(7)还原数据文件

[oracle@elvis bak]$ cp test01.dbf ..

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

FILE# CHECKPOINT_CHANGE#

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

1752976

2752976

3752976

4752976

5752976

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1752976

2752976

3752976

4752976

5752720--必要规复

(8)规复数据文件

SQL> recover datafile 5;

ORA-00279: change 752720 generated at 10/13/2012 19:48:40 needed for thread 1

ORA-00289: suggestion :

/u01/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_13/o1_mf_1_84_87lomp0q_

.arc--提示从84号文件开始

ORA-00280: change 752720 for thread 1 is in sequence #84

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 752934 generated at 10/13/2012 19:54:29 needed for thread 1

ORA-00289: suggestion :

/u01/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_13/o1_mf_1_85_87lon0x7_

.arc

ORA-00280: change 752934 for thread 1 is in sequence #85

ORA-00308: cannot open archived log

'/u01/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_13/o1_mf_1_85_87lon0x7

_.arc'--提示缺掉85号文件

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

因为归档文件不继续导致后面的归档日志也无法应用,这个时刻只能尽可能的挽回数据—不完全规复

常识点弥补:

因为不完全规复只利用部分日志文件,是以必须给Oracle指定停止标志,有如下4种选项可供选择:

a.基于光阴:指定一个详细的光阴点

b.基于SCN:指定一个详细的SCN号。在Oracle中SCN可以转换成光阴,是以本选项与前一条实质相同,然则SCN加倍正确。只不过多半环境下,我们可能并不能准确记录下数据库的SCN,是以基于光阴会更常用一些。

c.基于CANCEL:利用所有能够利用的日志文件,直到用户主动取消为止。

d.基于日志序号:指定归档文件序号,规复到指定的日志序号后即中止规复操作。

留意:同时不完全规复还支持表空间或数据文件级的不完全规复,不过SYSTEM表空间和UNDO表空间就弗成以喽!!!

看完这些信托大年夜家应该明白个大年夜概了,这里我选择CANCEL要领的不完全规复。

但在履行不完全规复之前,必然要记着你必要设置一个暗藏参数,之前已经用过了,怎么设置请看小e之前不完全规复的案例,在这里只是在提一下:

SQL> show parameter _allow

NAMETYPEVALUE

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

_allow_resetlogs_corruptionbooleanTRUE

SQL> recover database until cancel;

ORA-00279: change 752934 generated at 10/13/2012 19:54:29 needed for thread 1

ORA-00289: suggestion :

/u01/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_13/o1_mf_1_85_87lon0x7_

.arc

ORA-00280: change 752934 for thread 1 is in sequence #85

Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

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/oracle/oradata/elvis/system01.dbf'

ORA-01112: media recovery not started

SQL> alter database open resetlogs;

SQL> select * from test;

IDSCN

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

1751174

2751225

3751232

4751239

5751794

6751805

7751811

8752922

8 rows selected.

可以看到数据损掉了。。。

总结:从实验中可以看出归档日志很紧张了吧!也看出了归档模式下的紧张性,除非有极特殊的场合下,否则归档模式必然要开,假如数据分外紧张,建议归档日志文件也冗余而且放在不合的磁盘上,否则中心有一个归档日志损掉导致归档日志的不继续,终局是很悲剧的,在此当心。。。

转:http://blog.csdn.net/elvis_dataguru/article/details/8068286

您可能还会对下面的文章感兴趣: