[小e笔记]之一步一步学习备份恢复——第三篇 数据库恢复案例(Part 7)

小e随笔:最近一直在忙于准备投简历的材料什么的,比如证书啊,身份证啊!还有小e大三这一学年在一次享有佳绩二等奖学金+校优秀学生干部,这几天也忙于写这几份荣誉的申请材料,还有个党员的论文,谁叫我是党员呢。。。,总之虽然忙碌,但非常高兴。

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

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

SQL> show parameter db_recover

NAME                                 TYPE        VALUE

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

db_recovery_file_dest                string      /u01/oracle/flash_recovery_are

                                                 a

db_recovery_file_dest_size           big integer 4977M

SQL> show parameter archive

NAME                                 TYPE        VALUE

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

archive_lag_target                   integer     0

log_archive_config                   string

log_archive_dest                     string

log_archive_dest_1                   string

log_archive_dest_10                  string

log_archive_dest_11                  string

log_archive_dest_12                  string

log_archive_dest_13                  string

log_archive_dest_14                  string

log_archive_dest_15                  string

log_archive_dest_16                  string

NAME                                 TYPE        VALUE

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

log_archive_dest_17                  string

log_archive_dest_18                  string

log_archive_dest_19                  string

log_archive_dest_2                   string

log_archive_dest_20                  string

log_archive_dest_21                  string

log_archive_dest_22                  string

log_archive_dest_23                  string

log_archive_dest_24                  string

log_archive_dest_25                  string

log_archive_dest_26                  string

NAME                                 TYPE        VALUE

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

log_archive_dest_27                  string

log_archive_dest_28                  string

log_archive_dest_29                  string

log_archive_dest_3                   string

log_archive_dest_30                  string

log_archive_dest_31                  string

log_archive_dest_4                   string

log_archive_dest_5                   string

log_archive_dest_6                   string

log_archive_dest_7                   string

log_archive_dest_8                   string

NAME                                 TYPE        VALUE

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

log_archive_dest_9                   string

log_archive_dest_state_1             string      enable

log_archive_dest_state_10            string      enable

log_archive_dest_state_11            string      enable

log_archive_dest_state_12            string      enable

log_archive_dest_state_13            string      enable

log_archive_dest_state_14            string      enable

log_archive_dest_state_15            string      enable

log_archive_dest_state_16            string      enable

log_archive_dest_state_17            string      enable

log_archive_dest_state_18            string      enable

NAME                                 TYPE        VALUE

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

log_archive_dest_state_19            string      enable

log_archive_dest_state_2             string      enable

log_archive_dest_state_20            string      enable

log_archive_dest_state_21            string      enable

log_archive_dest_state_22            string      enable

log_archive_dest_state_23            string      enable

log_archive_dest_state_24            string      enable

log_archive_dest_state_25            string      enable

log_archive_dest_state_26            string      enable

log_archive_dest_state_27            string      enable

log_archive_dest_state_28            string      enable

NAME                                 TYPE        VALUE

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

log_archive_dest_state_29            string      enable

log_archive_dest_state_3             string      enable

log_archive_dest_state_30            string      enable

log_archive_dest_state_31            string      enable

log_archive_dest_state_4             string      enable

log_archive_dest_state_5             string      enable

log_archive_dest_state_6             string      enable

log_archive_dest_state_7             string      enable

log_archive_dest_state_8             string      enable

log_archive_dest_state_9             string      enable

log_archive_duplex_dest              string

NAME                                 TYPE        VALUE

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

log_archive_format                  string      %t_%s_%r.dbf

log_archive_local_first              boolean     TRUE

log_archive_max_processes            integer     4

log_archive_min_succeed_dest         integer     1

log_archive_start                    boolean     FALSE

log_archive_trace                    integer     0

standby_archive_dest                 string      ?/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

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

         1         76 YES INACTIVE

         2         77 NO  CURRENT

         3         75 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;

        ID        SCN

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

         1     751174

看看生成的归档日志文件

[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;

        ID        SCN

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

         1     751174

         2     751225

         3     751232

         4     751239

[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 oinstall    2048 Oct 13 18:32 o1_mf_1_78_87ljtm43_.arc

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

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

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

SQL> select * from test;

        ID        SCN

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

         1     751174

         2     751225

         3     751232

         4     751239

         5     751794

         6     751805

         7     751811

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 Area  598437888 bytes

Fixed Size                  1338140 bytes

Variable Size             394265828 bytes

Database Buffers          197132288 bytes

Redo Buffers                5701632 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;

        ID        SCN

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

         1     751174

         2     751225

         3     751232

         4     751239

         5     751794

         6     751805

         7     751811

         8     752922

         9     752935

        10     752946

        11     752954

        ID        SCN

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

        12     752962

        13     752970

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 oinstall   2048 Oct 13 18:32 o1_mf_1_78_87ljtm43_.arc

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

-rw-r----- 1 oracle oinstall   2048 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 oinstall   3072 Oct 13 19:17 o1_mf_1_82_87lmgzkz_.arc

-rw-r----- 1 oracle oinstall   2560 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 oinstall    2048 Oct 13 18:32 o1_mf_1_78_87ljtm43_.arc

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

-rw-r----- 1 oracle oinstall    2048 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 oinstall    2560 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 oinstall   2048 Oct 13 19:54 o1_mf_1_85_87lon0x7_.arc.bak  --85丢失

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

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

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

-rw-r----- 1 oracle oinstall    2560 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 Area  598437888 bytes

Fixed Size                  1338140 bytes

Variable Size             394265828 bytes

Database Buffers          197132288 bytes

Redo Buffers                5701632 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#

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

         1             752976

         2             752976

         3             752976

         4             752976

         5             752976

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

     FILE# CHECKPOINT_CHANGE#

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

         1             752976

         2             752976

         3             752976

         4             752976

         5             752720    --需要恢复

 (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: {<RET>=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

NAME                                 TYPE        VALUE

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

_allow_resetlogs_corruption          boolean     TRUE

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: {<RET>=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;

        ID        SCN

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

         1     751174

         2     751225

         3     751232

         4     751239

         5     751794

         6     751805

         7     751811

         8     752922

8 rows selected.

可以看到数据丢失了。。。

总结:从实验中可以看出归档日志很重要了吧!也看出了归档模式下的重要性,除非有极特殊的场合下,否则归档模式一定要开,如果数据特别重要,建议归档日志文件也冗余而且放在不同的磁盘上,否则中间有一个归档日志丢失导致归档日志的不连续,结局是很悲剧的,在此警戒。。。

 

elvis
2012.10.13
知识共享~共同进步
转载请注明:
http://blog.csdn.net/elvis_dataguru/article/details/8068286
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值