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

小e随笔：这部分主要是用户管理备份恢复方式，属于早期的恢复方式，虽然现在有了RMAN和flashback,但这种恢复方式还是值得研究和了解。

1  了解与恢复相关的信息

1.1 理解警告日志文件

警告日志文件一般记载了数据库的启动/关闭信息，归档信息，备份信息，恢复信息，常见错误信息，部分数据库修改记录等。一般命令规则为calert_.log，如我的测试数据库的警告日志文件的名称为calert_elvis.log。

警告日志文件的路径是根据初始参数

SQL> show parameter background_dump_dest;

NAME                                 TYPE        VALUE

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

background_dump_dest                 string      /u01/app/oracle/diag/rdbms/elvis/elvis/trace

我的11g数据库，我发现与10g有些许不同，在10g中警告日志应该在bdump文件夹里，但是在11g里单独有一个diag文件夹，不知道11g是不是都这样，还是单独我的环境是，初次使用11g。。。，先不管啦，总之大同小异，能找到警告日志文件就行，找不到没关系，用上面的参数先看下。

1.2  后台进程跟踪文件

后台进程跟踪文件的路径与警告日志文件的路径一致，这通常是一个服务器进程对某种异常错误条件作出响应时创建的诊断文件。在某些情况下，你可以通过后台跟踪文件的信息了解更多的需要恢复的信息。

1.3  v$recover_file和v$recovery_log

这是两个动态性能视图，可以在mount下查看，通过这两个视图，你可以了解详细的需要恢复的数据文件与需要使用到的归档日志。

2     完全脱机备份   --archivelog|noarchivelog

案例1：归档模式下一个或多个数据文件损坏，其它文件都完好

备份方案： OS冷备份

l  关闭数据库&备份文件

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@elvis elvis]$ cp sys* undotbs01.dbf users01.dbf bak/  --OS备份文件

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> create table t(id int,scn int) tablespace users;      --创建表模拟数据

Table created.

SQL> insert into t values(1,dbms_flashback.get_system_change_number);

1 row created.

SQL> commit;

Commit complete.

SQL> select group#,sequence#,archived,status from v$log;  --查看redo log

    GROUP#  SEQUENCE# ARC STATUS

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

         1          1 YES INACTIVE

         2          2 YES INACTIVE

         3          3 NO  CURRENT    --当前在第3组

SQL> alter system switch logfile;     --日志切换

System altered.

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

    GROUP#  SEQUENCE# ARC STATUS

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

         1          4 NO  CURRENT      --日志切换成功当前为第1组

         2          2 YES INACTIVE

         3          3 YES ACTIVE

重复上述动作，最终表中数据如下：

SQL> select * from t;

        ID        SCN

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

         1     904079

         2     904222

         3     904236

         4     904243

5    904251     --其中这条没有commit

l  这时模拟毁坏一个或多个数据文件

Linux操作系统可以在线删除文件，这个跟贴近于实际

Win下只能能操作系统关闭才能删除文件，但关闭的时候最好用abort

我的环境是Linux可以在线删除数据文件。

[oracle@elvis elvis]$ ll

total 1916456

drwxr-xr-x 2 oracle oinstall      4096 Oct  1 19:46 bak

-rw-r----- 1 oracle oinstall   9748480 Oct  1 20:06 control01.ctl

drwxr-x--- 4 oracle oinstall      4096 Oct  1 13:49 ELVIS

-rw-r----- 1 oracle oinstall  52429312 Oct  1 20:05 redo01.log

-rw-r----- 1 oracle oinstall  52429312 Oct  1 19:59 redo02.log

-rw-r----- 1 oracle oinstall  52429312 Oct  1 20:00 redo03.log

-rw-r----- 1 oracle oinstall 629153792 Oct  1 20:05 sysaux01.dbf

-rw-r----- 1 oracle oinstall 734011392 Oct  1 20:05 system01.dbf

-rw-r----- 1 oracle oinstall  71311360 Sep 30 11:06 temp01.dbf

-rw-r----- 1 oracle oinstall 408952832 Oct  1 20:05 undotbs01.dbf

-rw-r----- 1 oracle oinstall   5251072 Oct  1 20:05 users01.dbf

[oracle@elvis elvis]$ rm -fr sys* undotbs01.dbf users01.dbf

[oracle@elvis elvis]$ ls

bak  control01.ctl  ELVIS  redo01.log  redo02.log  redo03.log  temp01.dbf

删除后，这个地方需要注意下，数据文件损坏后，数据库不会直接宕掉。

然后关闭数据库  --这个地方要用abort，因为你正常关闭数据库会报错，因为文件缺失无法归档

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 1 - see DBWR trace file

ORA-01110: data file 1: '/u01/app/oracle/oradata/elvis/system01.dbf'

l  数据文件的恢复

模拟总共丢失4个文件，大同小异，我就一次性把丢失的文件全拷贝回来（restore过程）

SQL> select file#,checkpoint_change# from v$datafile; --它来自于控制文件

     FILE# CHECKPOINT_CHANGE#

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

         1             904249

         2             904249

         3             904249

         4             904249

SQL> select file#,checkpoint_change# from V$datafile_header; --它来自于数据文件头

      FILE# CHECKPOINT_CHANGE#

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

         1                  0

         2                  0

         3                  0

         4                  0

它俩的scn必须保持一致，才能正常开启数据库

[oracle@elvis bak]$ cp sys* undotbs01.dbf users01.dbf /u01/app/oracle/oradata/elvis/

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

     FILE# CHECKPOINT_CHANGE#

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

         1             904249

         2             904249

         3             904249

         4             904249

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

     FILE# CHECKPOINT_CHANGE#

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

         1             903863

         2             903863

         3             903863

         4             903863

查看需要恢复的数据文件和日志

SQL> col error format a5;

SQL> select * from v$recover_file;

     FILE# ONLINE  ONLINE_ ERROR    CHANGE# TIME

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

         1 ONLINE  ONLINE            903863 01-OCT-12

         2 ONLINE  ONLINE            903863 01-OCT-12

         3 ONLINE  ONLINE            903863 01-OCT-12

         4 ONLINE  ONLINE            903863 01-OCT-12

SQL> col archive_name format a50;

SQL> select * from v$recovery_log;

   THREAD#  SEQUENCE# TIME      ARCHIVE_NAME

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

         1          3 01-OCT-12 /u01/app/oracle/flash_recovery_area/ELVIS/archivel

                                og/2012_10_01/o1_mf_1_3_86m18vlk_.arc

 

         1          4 01-OCT-12 /u01/app/oracle/flash_recovery_area/ELVIS/archivel

                                og/2012_10_01/o1_mf_1_4_86m1fkbb_.arc

所需要的3和4归档日志文件都在

[oracle@elvis 2012_10_01]$ ll

total 13016

-rw-r----- 1 oracle oinstall     1536 Oct  1 13:51 o1_mf_1_1_86lctbbm_.arc

-rw-r----- 1 oracle oinstall  2892800 Oct  1 16:34 o1_mf_1_2_86lodm42_.arc

-rw-r----- 1 oracle oinstall 10380800 Oct  1 19:57 o1_mf_1_3_86m18vlk_.arc

-rw-r----- 1 oracle oinstall     8704 Oct  1 19:59 o1_mf_1_4_86m1fkbb_.arc

-rw-r----- 1 oracle oinstall     3072 Oct  1 19:59 o1_mf_1_5_86m1fxy9_.arc

-rw-r----- 1 oracle oinstall     2560 Oct  1 20:00 o1_mf_1_6_86m1g9y8_.arc

-rw-r----- 1 oracle oinstall     3072 Oct  1 13:49 o1_mf_1_79_86lcqbqr_.arc

也可以通过这个视图定位是从哪个归档日志文件开始恢复

SQL> select sequence#,first_change#,first_time,next_change#,next_time from v$archived_log where first_change#<=903863 and next_change#>=903863 ;

 SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME

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

         3        896073 01-OCT-12       904174 01-OCT-12

刚开始记得详细一些，以后可就不这样啰嗦啦！！！

开始恢复，这些归档在默认路径下，Oracle都会自动定位所需要的归档日志。

可以一个一个文件恢复

--recover datafile 1;

但我这丢失了4个文件，一个一个恢复较麻烦，可以按以下命令来。

SQL> recover database;

ORA-00279: change 903863 generated at 10/01/2012 19:38:33 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_01/o1_mf_1_3_86m18vlk_.arc

ORA-00280: change 903863 for thread 1 is in sequence #3

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

auto

ORA-00279: change 904174 generated at 10/01/2012 19:57:15 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/flash_recovery_area/ELVIS/archivelog/2012_10_01/o1_mf_1_4_86m1fkbb_.arc

ORA-00280: change 904174 for thread 1 is in sequence #4

Log applied.

Media recovery complete.

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

     FILE# CHECKPOINT_CHANGE#

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

         1             924841

         2             924841

         3             924841

         4             924841

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

     FILE# CHECKPOINT_CHANGE#

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

         1             924841

         2             924841

         3             924841

         4             924841

SCN一致了，可以正常开启数据库了，但在开启之前，还有个问题，应该强调下。

SQL> select sequence#,first_change#,first_time,next_change#,next_time from v$archived_log where sequence#>=1 and sequence#<=6;

 SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME

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

         1        852915 01-OCT-12       872923 01-OCT-12

         2        872923 01-OCT-12       896073 01-OCT-12

         3        896073 01-OCT-12       904174 01-OCT-12

         4        904174 01-OCT-12       904235 01-OCT-12

         5        904235 01-OCT-12       904242 01-OCT-12

         6        904242 01-OCT-12       904249 01-OCT-12  --恢复的924841比归档日志文件里最大的SCN都大

6 rows selected.

这是因为

--select * from v$log;

--select * from v$logfile;

因为当前三个重做日志文件，还在且没有被覆盖，所以Oracle优先使用了这几个文件SCN，且这三个文件又是当前数据库的一部分，并用到了当前重做日志文件7，所以比归档日志文件里最大的SCN大。

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

    GROUP#  SEQUENCE# ARC STATUS

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

         1          7 NO  CURRENT

         3          6 YES INACTIVE

         2          5 YES INACTIVE

l  成功恢复数据库

SQL> alter database open;

Database altered.

SQL> select * from t;

        ID        SCN

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

         1     904079

         2     904222

         3     904236

         4     904243

恢复的非常成功，除了没有提交的id=5(rollback了)的数据之外数据显然都恢复回来了。

总结：

这种备份方式，数据虽然不会丢失，但需要在数据库关闭情况下备份，这在实际业务中，很有局限性，而且直接使用操作系统的copy命令即浪费了时间又浪费了空间，除非特殊情况下，否则不建议冷备份。但完全脱机备份也有个好处就是它在归档和非归档模式下都适用，而且操作简单。

 

elvis
2012.10.2
知识共享~共同进步
转载请注明：

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