Oracle备份与恢复——浅析
来源：互联网 发布：js怎么给div加class 编辑：程序博客网 时间：2024/06/07 07:04
目 录
第一单元 OS崩溃后恢复... 3
一、UNIX操作系统崩溃后，进行恢复... 3
1．1．1 创建数据库实例... 3
1．1．2 配置数据库的初始化参数文件... 3
1．1．3 恢复控制文件，进入mount状态... 4
1．1．4 修复数据库（restore）... 5
1．1．5 恢复数据库(recover) 6
1．1．6 用open resetlogs方式打开数据库... 7
1．1．7 检查数据库正常后，进行全库备份... 7
二、Windows操作系统崩溃后，进行恢复... 7
1．2．1 重新安装新数据库... 7
1．2．2 恢复原数据库：... 8
第二单元 数据文件损坏后恢复... 10
一、单个数据文件损坏后，用户管理备份的恢复... 10
2．1．1 启动数据库报错后，脱机该数据文件：... 10
2．1．2 打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机: 11
2．1．3 检查恢复后的数据... 11
二、单个数据文件损坏后，RMAN备份恢复... 12
2．2．1 启动数据库，检查错误... 12
2．2．2 先打开数据库... 12
2．2．3 恢复该表空间... 12
2．2．4 检查恢复后的数据... 13
三、多个数据文件损坏后，用户管理备份的恢复... 13
2．3．1 启动数据库，检查错误... 13
2．3．2 拷贝备份回到原地点(restore)，开始恢复数据库(recover) 14
2．3．3 打开数据库... 14
2．3．4 检查恢复后的数据... 14
四、多个数据文件损坏后，RMAN备份恢复... 15
2．4．1 启动数据库，检查错误... 15
2．4．2 使用RMAN，恢复数据库... 15
2．4．3 检查恢复后的数据... 16
第三单元 用户误删数据后恢复... 16
一、数据库不完全恢复... 16
用户管理的备份（ＯＳ备份）不完全恢复：... 17
3．1．1 判断故障发生具体时间，假定删除前的时间为T1. 17
3．1．2 准备恢复到时间点T1，找回删除的表，先关闭数据库... 17
3．1．3 拷贝备份回到原地点(restore)，开始恢复数据库(recover) 18
3．1．4 打开数据库，检查数据... 18
RMAN备份不完全恢复：... 19
3．2．1 判断故障发生具体SCN，假定删除前的SCN号为S1. 19
3．2．2 准备恢复到S1，先关闭数据库，然后启动到mount下... 19
3．2．3 使用RMAN，恢复数据库... 19
3．2．4 检查恢复后的数据... 20
二、逻辑恢复... 20
3．3．1 基于时间的查询（as of timestamp）... 20
3．3．2 基于SCN的查询（as of SCN）... 21
3．3．3 使用LogMiner工具分析日志... 21
第一单元 OS崩溃后恢复
一、UNIX操作系统崩溃后，进行恢复
前提条件，必须有数据库的完整备份（包括参数文件、控制文件、数据文件、归档文件），并且保证创建的备份是一致备份。
由于恢复的难度和环境的复杂性，强烈建议使用RMAN备份集进行备份和恢复，确保在恢复过程不容易出错，减少down机时间。
1．1．1 创建数据库实例
在操作系统上安装Oracle 软件，配置环境变量，数据库目录结构最好与原库保持一致。
1．1．2 配置数据库的初始化参数文件
¨ 将备份的pfile或spfile初始化参数文件复制到$ORACLE_HOME/dbs目录下
¨ 确认原数据库目录结构与恢复后数据库目录结构保持完全一致。如果路径不一致情况下，至少要保证如下参数所指定的值正确有效：
· Control_files:控制文件路径
· Audit_file_dest:审计输出的debug日志路径
· Background_dump_dest:LGWR、DBWn之类后台进程输出的debug日志路径
· Core_dump_dest:Oracle内核输出的dump日志路径
· User_dump_dest:用户进程输出的debug日志路径
· Log_archive_dest_1:归档文件路径
如果spfile文件没有单独备份，可从RMAN备份集中恢复，具体步骤如下：
-bash-3.00$>rman
Recovery Manager: Release 9.2.0.6.0 - 64bit Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> startup force nomount
Oracle instance started
Total System Global Area 167772160 bytes
Fixed Size 1279120 bytes
Variable Size 109054832 bytes
Database Buffers 54525952 bytes
Redo Buffers 2912256 bytes
RMAN> restore spfile from '实际备份集路径';
Starting restore at 12-APR-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK
channelORA_DISK_1:autobackupfound:/u01/flash_recovery_area/ORCL/backupset/2011_04_12/o1_mf_ncsnf_TAG20110412T100010_6t7do0vn_.bkp
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 12-APR-11
1．1．3 恢复控制文件，进入mount状态
设置ORACLE_SID：
-bash-3.00$ set ORACLE_SID=实际ＩＤ
查看ORACLE_SID：
-bash-3.00$echo ORACLE_SID
登陆RMAN
-bash-3.00$>rman
Recovery Manager: Release 9.2.0.6.0 - 64bit Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> connect target /
由于此时尚无控制文件，首先指定DBID：
RMAN> set DBID=实际ＩＤ
executing command: SET DBID
指定pfile进行启动：
RMAN> startup nomount pfile=='$ORACLE_HOME/dbs/iniSID.ora'[C1] ;
ORACLE instance started.
从指定备份集中恢复控制文件：
RMAN>restore controlfile from ‘实际目录’
输出类似如下：
Starting restore at 12-APR-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=212 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:06
output filename=/u03/orcldata/control01.ctl
output filename=/u03/orcldata/control02.ctl
output filename=/u03/orcldata/control03.ctl
Finished restore at 12-APR-11
控制文件会被恢复到初始化参数control_files指定的路径下。
将数据库置为mount状态：
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
1．1．4 修复数据库（restore）
数据库结构路径一致情况下，可以直接用备份路径修复，如果不一同的话，需要通过set newname for datafile命令来为数据文件重新设定路径，用set newname必须放在run 块中执行。
RMAN>restore database;
输出结果类似如下：
Starting restore at 12-APR-11
Starting implicit crosscheck backup at 12-APR-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=211 devtype=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 12-APR-11
Starting implicit crosscheck copy at 12-APR-11
using channel ORA_DISK_1
Finished implicit crosscheck copy at 12-APR-11
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_58_6t5kndn5_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_60_6t5knkrx_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_59_6t5knl64_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_1_6t5m978b_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_1_6t5mjmsl_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_2_6t5mjo2o_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_3_6t5mjx60_.arc
File Name: /u01/flash_recovery_area/ORCL/archivelog/2011_04_11/o1_mf_1_4_6t5mwrdr_.arc
File Name: /u01/flash_recovery_area/ORCL/backupset/2011_04_11/o1_mf_ncsnf_TAG20110411T163418_6t5hconf_.bkp
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u03/orcldata/system01.dbf
restoring datafile 00002 to /u03/orcldata/undotbs01.dbf
restoring datafile 00003 to /u03/orcldata/sysaux01.dbf
restoring datafile 00004 to /u03/orcldata/users01.dbf
restoring datafile 00005 to /u03/orcldata/test1.dbf
restoring datafile 00006 to /u03/orcldata/perfstat.dbf
channel ORA_DISK_1: reading from backup piece /u01/flash_recovery_area/ORCL/backupset/2011_04_11/o1_mf_nnndf_TAG20110411T163418_6t5h8c24_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/flash_recovery_area/ORCL/backupset/2011_04_11/o1_mf_nnndf_TAG20110411T163418_6t5h8c24_.bkp tag=TAG20110411T163418
channel ORA_DISK_1: restore complete, elapsed time: 00:01:56
Finished restore at 12-APR-11
1．1．5 恢复数据库(recover)
数据库结构一致情况下，直接恢复：
RMAN>recover database;
输出结果类似如下：
Starting recover at 12-APR-11
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 1 is already on disk as file u01/flash_recovery_area/ORCL/archivelog/2011_04_12/o1_mf_1_1_6t7lwt9c_.arc
……
unable to find archive log
archive log thread=1 sequence=4
RMAN-00571: ===============================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ==
RMAN-00571: ===============================================
RMAN-03002: failure of recover command at 04/12/2011 12:07:08
RMAN-06054: media recovery requesting unknown log: thread 1 seq 4 lowscn 983420
说明：
此处报错为正常情况，因为操作系统崩溃后，数据库联机重做日志文件肯定丢失，此时数据库为不完全恢复。
1．1．6 用open resetlogs方式打开数据库
RMAN> alter database open resetlogs;
database opened
1．1．7 检查数据库正常后，进行全库备份
检查数据库及应用是否正常，确认正常后立即进行数据库全备。
RMAN> backup database;
输出结果类似如下：
Starting backup at 12-APR-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
……
省略
……
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:05
Finished backup at 12-APR-11
说明：
手工备份过程与此类似，但操作相对更为繁杂，建议采用RMAN工具进行备份和恢复。
二、Windows操作系统崩溃后，进行恢复
操作系统崩溃后，数据库安装目录理论还存在。恢复原理是先装一个一模一样的ORACLE，安装目录、数据库名称都一样，这样保证注册表里不用更改；再覆盖物理文件，最后重新实例化，打开数据库。
需要注意: 一般的ORACLE数据库的监听程序都是用电脑的名称来识别地址的，而不是127.0.0.1或者localhost。所以，如果安装系统的时候用的是不同的电脑名称，那么必须修改文件 listener.ora。
建议重装系统后，主机名与原来保持一致，避免数据库恢复过程出现错误。
1．2．1 重新安装新数据库
备份原数据库：
将原来的ORACLE文件夹改名，假如原来的路径是I:/oracle。现在暂时改成I:/oracle_old。
安装新数据库：
使用ORACLE 9I安装光盘，将ORACLE安装在原来安装的目录下（I:/oracle），这样在安装后注册表的内容不用修改。
1．2．2 恢复原数据库：
1、关闭数据库
2、关闭ORACLE的所有已经启动的项目
在“开始”—“运行”，输入services.msc 如下：
打开服务面板，找到所有Oracle服务，如下：
关闭所有Oracle服务，如下：
3、将安装目录改名。现在用的是I:/oracle。改成I:/oracle_new。再将I:/oracle_old改成I:/oracle
假如不能更改，先注销系统后，再改名。
4、启动Oracle 服务，打开数据库。
5、检查数据库是否正常恢复，数据是否正常。
说明：
如果重新安装数据库时操作出错，或安装时SID与原库不同，可以如下命令修改：
删除新安装SID（假设为NEWSID），打开“开始”——“运行”，输入cmd，如下：
进入到DOS命令环境，使用命令oradim -delete –sid NEWSID 删除NEWSID：
新建SID命令：oradim -new -sid NEWSID
第二单元 数据文件损坏后恢复
一、单个数据文件损坏后，用户管理备份的恢复
在归档方式下损坏或丢失一个数据文件，如果存在相应的用户管理备份（OS备份）与该备份以来的归档日志，恢复比较简单的，可以作到尽量少的Down机时间，并能作到数据库的完全恢复。
示例如下：
2．1．1 启动数据库报错后，脱机该数据文件：
SQL> startup
Oracle instance started.
. . . . . .
. . . . . .
Database mounted.
ORA-01157: cannot identify/lock data file *[C2] - see DBWR trace file
ORA-01110: data file *: 'Dir/*.DBF[C3] '
注：在报警文件中，会有更详细的信息
Errors in file Dir/*.TRC:
ORA-01157: cannot identify/lock data file * - see DBWR trace file
ORA-01110: data file *: 'Dir/*.DBF'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件。
也可以查看动态视图v$recover_file
SQL> select * from v$recover_file;
FILE# ONLINE ERROR CHANGE# TIME
---------- ------- ------------------ ---------- -----------
* ONLINE 1013500 2011-04-07
脱机数据文件
SQL> alter database datafile * [C4] offline drop;
Database altered.
2．1．2 打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机:
SQL> alter database open;
Database altered.
拷贝备份从备份处
copy 备份数据文件 -> 原数据库目录
恢复该数据文件
SQL> recover datafile *;
ORA-00279: change 1078469 generated at 04/07/2011 13:11:22 needed for
thread 1
ORA-00289: suggestion :
Dir/*.ARC
ORA-00280: change 1078469 for thread 1 is in sequence #159
Specify log: {<ret></ret>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 1078471 generated at 04/07/2011 13:11:35 needed for
thread 1
ORA-00289: suggestion : Dir/*.ARC
ORA-00280: change 1078471 for thread 1 is in sequence #160
ORA-00278: log file ' Dir/*.ARC ' no longer needed for this recovery Log applied.
Media recovery complete.
恢复成功，联机该数据文件
SQL> alter database datafile *[C5] online;
Database altered.
2．1．3 检查恢复后的数据
数据库完全恢复后，检查数据是否完整。
说明：
1、采用热备份，需要运行在归档模式下，可以实现数据库的完全恢复，也就是说，从备份后到数据库崩溃时的数据都不会丢失;
2、可以采用全备份数据库的方式备份，对于特殊情况，也可以只备份特定的数据文件，如只备份用户表空间（一般情况下对于某些写特别频繁的数据文件，可以单独加大备份频率）；
3、如果在恢复过程中，发现损坏的是多个数据文件，即可以采用一个一个数据文件的恢复方法（需要对数据文件一一脱机，分别恢复），也可以采用整个数据库的恢复方法；
4、如果是系统表空间的损坏，不能采用此方法。
二、单个数据文件损坏后，RMAN备份恢复
RMAN（Recovery Manage，恢复管理器）在进行备份时，需要将备份信息存储起来，这些信息将用来进行恢复。缺省的RMAN将这些信息存储在控制文件中，此时控制文件的安全极为重要。对于重要的数据库，建议将备份信息存储在目录数据库中（Catalog Database）。以下情况都是存在catalog的情况，因为只有配置catalog才能存在脚本。
2．2．1 启动数据库，检查错误
SQL> startup
Oracle instance started.
. . . . . .
. . . . . .
Database mounted.
ORA-01157: cannot identify/lock data file *[C6] - see DBWR trace file
ORA-01110: data file *: 'Dir/*.DBF[C7] '
2．2．2 先打开数据库
SQL> alter database datafile * offline drop;
Database altered.
SQL> alter database open;
Database altered.
2．2．3 恢复该表空间
恢复脚本可以是恢复单个数据文件
run{
allocate channel c1 type disk;
restore datafile 数据文件号;
recover datafile数据文件号;
sql 'alter database datafile数据文件号online';
release channel c1;
}
也可以是,恢复表空间
run{
allocate channel c1 type disk;
restore tablespace 表空间名;
recover tablespace表空间名;
sql 'alter database datafile 数据文件号online';
release channel c1;
}
过程如下：
$>rman
Recovery Manager: Release 9.2.0.6.0 - 64bit Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> connect target /
connected to target database: 数据库名(DBID=数据库ID号)
RMAN> run{
2> allocate channel c1 type disk;
3> restore datafile 数据文件号;
4> recover datafile 数据文件号;
5> sql 'alter database datafile 数据文件号 online';
6> release channel c1;
7> }
//输出内容省略--
RMAN>
2．2．4 检查恢复后的数据
数据库完全恢复后，检查数据是否完整。
说明：
1、RMAN也可以实现单个表空间或数据文件的恢复，恢复过程可以在mount下或open方式下，如果在open方式下恢复，可以减少down机时间;
2、如果损坏的是一个数据文件，建议offline并在open方式下恢复;
3、RMAN进行数据文件与表空间恢复的时候，代码都比较简单，而且能保证备份与恢复的可靠性，所以建议采用RMAN的备份与恢复.
三、多个数据文件损坏后，用户管理备份的恢复
在归档方式下损坏或丢失多个数据文件，存在用户管理的备份（OS备份）进行整个数据库的恢复：
2．3．1 启动数据库，检查错误
同上（单个数据文件损坏）,数据库在发出startup命令，进入到mount状态，提示错误信息。查看告警日志文件或v$recover_file视图，找出需要恢复的多个数据文件。
2．3．2 拷贝备份回到原地点(restore)，开始恢复数据库(recover)
restore过程:
$> copy 备份数据文件 -> 原数据库目录
Recover过程:
SQL> recover database;
ORA-00279: change ……
ORA-00289: suggestion : ……
ORA-00280: change ……
Specify log: {<ret></ret>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change ……
ORA-00289: suggestion : ……
ORA-00280: change ……
ORA-00278: log file ……no longer needed for this recovery
……
Log applied.
Media recovery complete.
2．3．3 打开数据库
SQL> alter database open;
Database altered.
2．3．4 检查恢复后的数据
数据库完全恢复后，检查数据是否完整。
说明：
1、只要有备份与归档存在，就可以实现数据库的完全恢复（不丢失数据）;
2、适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;
3、恢复过程在mount下进行，如果恢复成功，再打开数据库，down机时间可能比较长一些。
四、多个数据文件损坏后，RMAN备份恢复
2．4．1 启动数据库，检查错误
同上（单个数据文件损坏）,数据库在发出startup命令，进入到mount状态，提示错误信息。查看告警日志文件或v$recover_file视图，找出需要恢复的多个数据文件。
2．4．2 使用RMAN，恢复数据库
利用RMAN，进行全库完全恢复，过程如下：
$>rman
Recovery Manager: Release 9.2.0.6.0 - 64bit Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> connect target /
connected to target database: 数据库名(DBID=数据库ID号)
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database;
5> sql 'alter database open';
6> release channel c1;
7> }
执行后输出内容类似如下：
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: c1
RMAN-08500: channel c1: sid=23 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel c1: starting datafile backupset restore
RMAN-08502: set_count=8 set_stamp=682351721 creation_time=7-APR-11
RMAN-08089: channel c1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to ……
……
RMAN-08023: channel c1: restored backup piece 1
RMAN-08511: piece handle=……
RMAN-08024: channel c1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03022: compiling command: recover
…….
RMAN-08054: starting media recovery
……
RMAN-06050: archivelog thread 1 sequence 1252 is already on disk as file …….
RMAN-03023: executing command: recover(8)
RMAN-08515: archivelog filename=……
RMAN-08055: media recovery complete
RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database open
RMAN-03023: executing command: sql
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: c1
RMAN>
2．4．3 检查恢复后的数据
数据库完全恢复后，检查数据是否完整。
说明：
1、只要有备份与归档存在，RMAN也可以实现数据库的完全恢复（不丢失数据）;
2、同用户管理的备份（ＯＳ备份）数据库恢复，适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;
3、目标数据库在mount下进行，如果恢复成功，再打开数据库;
4、RMAN的备份与恢复命令相对比较简单并可靠，建议有条件的话，都采用RMAN进行数据库的备份。
第三单元 用户误删数据后恢复
Oracle 9i在用户误删数据后有二种恢复方式，包括数据库不完全恢复和逻辑恢复。数据库不完全恢复基于数据库的物理备份进行恢复，逻辑恢复基于闪回查询和日志查询。
一、数据库不完全恢复
由于闪回查询只针对INSERT、UPDATE、DELETE有效，在用户删除表或表结构改变时，Oracle 9i仍然只能采用不完全恢复方式，具体适用于下列情况：
¨ 介质损坏导致部分在线重做日志不可用用户
¨ 用户误删数据，无法用逻辑方式恢复
¨ 由于丢失部分归档日志，无法进行完全恢复
¨ 控制文件丢失，只能以备份的控制文件打开数据库
不完全恢复有如下几种情况：
¨ 基于时间：指定一个具体的时间点，这个时间点需要根据故障时间进行判断选取
¨ 基于SCN：指定一个具体的SCN号。比基于时间更精确
¨ 基于CANCEL：应用所有能够应用的日志文件，直到用户主动取消为止
¨ 基于日志序号：指定归档文件序号，恢复到指定日志序号后即中止恢复操作
用户管理的备份（ＯＳ备份）不完全恢复：
基于时间的恢复可以不完全恢复到现在时间之前的某一个时间，对于某些误操作，如删除了一个数据表，可以在备用恢复环境上恢复到表的删除时间之前，然后把该表导出到正式环境，避免一个人为的错误。
这里以基于时间的恢复为例子来说明不完全恢复过程：
注：进行不完全恢复操作强烈建议在测试库上操作，在恢复正确数据后，再导入到生产库。
3．1．1 判断故障发生具体时间，假定删除前的时间为T1
使用如下SQL语句，可查看当前时间，假定这一时间即为T1
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YYYY-MM-DDHH2
------------------------------
2011-04-11 15:38:48
3．1．2 准备恢复到时间点T1，找回删除的表，先关闭数据库
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
3．1．3 拷贝备份回到原地点(restore)，开始恢复数据库(recover)
restore过程:
$> copy 备份数据文件 -> 原数据库目录
启动到mount下
SQL> startup mount;
Oracle instance started.
……
Database mounted.
开始不完全恢复数据库到T1时间
SQL> recover database until time '2011-04-11 15:38:48';
ORA-00279: change 52361 generated at 04/11/2011 14:40:06 needed for thread 1
ORA-00289: suggestion : ……
ORA-00280: change ……
Specify log: {<ret></ret>=suggested | filename | AUTO | CANCEL}
AUTO
Log applied.
Media recovery complete.
3．1．4 打开数据库，检查数据
SQL> alter database open resetlogs;
Database altered.
此时可以检查数据的正确性，如果无误就可以通过exp导出数据，再imp进生产数据库，完成恢复。
说明：
1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的;
2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例;
3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后以前的备份不再有效;
4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间;
5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统.
RMAN备份不完全恢复：
上面为用户管理的备份（OS备份）基于时间点的恢复，下面用RMAN演示一个基于改变的恢复：
3．2．1 判断故障发生具体SCN，假定删除前的SCN号为S1
授予用户使用dbms_flashback包的权限：
SQL> conn / as sysdba
Connected.
SQL> grant execute on dbms_flashback to flashtest;
Grant succeeded.
使用如下SQL语句，可查看当前SCN，假定这一SCN即为S1
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
S1
3．2．2 准备恢复到S1，先关闭数据库，然后启动到mount下
SQL> shutdown immediate;
Database closed.
Database dismounted.
Oracle instance shut down.
SQL> startup mount;
3．2．3 使用RMAN，恢复数据库
$>rman
Recovery Manager: Release 9.2.0.6.0 - 64bit Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
RMAN> connect target /
connected to target database: 数据库名(DBID=数据库ID号)
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database until scn S1;
5> sql 'ALTER DATABASE OPEN RESETLOGS';
6> release channel c1;
7> }
media recovery complete, elapsed time: 00:00:09
Finished recover at 2011-04-11 17:52:48
database opened
3．2．4 检查恢复后的数据
此时可以检查数据的正确性，如果无误就可以通过exp导出数据，再imp进生产数据库，完成恢复。
说明：
1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的;
2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例;
3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后以前的备份不再有效;
4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间;
5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统.
二、逻辑恢复
当执行DML操作后，需要恢复到执行前的数状态，不仅可以使用数据库不完全恢复功能，还提供了基于回滚段的闪回查询（Flashback Query）功能，用于恢复错误的DML操作。
需要注意的是：进行闪回查询只针对INSERT、UPDATE、DELETE有效，且必须设置自动回滚段管理，在pfile或spfile设置参数UNDO_MANAGEMENT=AUTO，参数UNDO_RETENTION=n(单位秒)，决定了能往前闪回的最大时间，值越大就需要越多Undo空间。 当超过undo_retention时间或者需要获得UNDO的具体语句，那么就需要REDO日志了。由于日志采用二进制格式，所以需要使用LogMiner进行日志分析。
3．3．1 基于时间的查询（as of timestamp）
假设当前距离删除数据有3分钟左右时间，执行select查询语句，并附加as of子句，如下：
select * from falshtest as of timestamp sysdate-3/1440;
将找出3分钟前删除的记录，再利用查询结果将丢失数据导入原数据库。
说明：
sysdate-3/1440具体意思：60(分)*24=1440，计算出一天有多少分钟，sysdate为系统函数，用来取得当前的系统时间（以天为单位），sysdate-3/1440，得出距离当前时间3分钟前的记录。
3．3．2 基于SCN的查询（as of SCN）
授予用户使用dbms_flashback包的权限：
SQL> conn / as sysdba
Connected.
SQL> grant execute on dbms_flashback to flashtest;
Grant succeeded.
使用如下SQL语句，可查看当前SCN，假定这一SCN即为S1
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
S1
使用下面SQL，查询指定SCN时对象中的记录：
SQL> select * from 用户 as of SCN S1;
利用查询结果将丢失数据导入原数据库。
3．3．3 使用LogMiner工具分析日志
LogMiner 工具即可以用来分析在线，也可以用来分析离线日志文件，即可以分析本身自己数据库的重作日志文件，也可以用来分析其他数据库的重作日志文件。
¨ 安装LogMiner
¨
¨ 要安装LogMiner工具，必须首先要运行下面这样两个脚本，
¨
¨ l $ORACLE_HOME/rdbms/admin/dbmslsm.sql
¨
¨ 2 $ORACLE_HOME/rdbms/admin/dbmslsmd.sql.
¨
¨ 这两个脚本必须均以SYS用户身份运行。其中第一个脚本用来创建DBMS_LOGMNR包，该包用来分析日志文件。第二个脚本用来创建DBMS_LOGMNR_D包，该包用来创建数据字典文件。
¨
¨ 使用LogMiner工具
¨
¨ 下面将详细介绍如何使用LogMiner工具。
¨
¨ 1、创建数据字典文件（data-dictionary）
¨
¨ 前面已经谈到，LogMiner工具实际上是由两个新的PL/SQL内建包（(DBMS_LOGMNR 和 DBMS_ LOGMNR_D）和四个V$动态性能视图（视图是在利用过程DBMS_LOGMNR.START_LOGMNR启动LogMiner时创建）组成。在使用LogMiner工具分析redo log文件之前，可以使用DBMS_LOGMNR_D 包将数据字典导出为一个文本文件。该字典文件是可选的，但是如果没有它，LogMiner解释出来的语句中关于数据字典中的部分（如表名、列名等）和数值都将是16进制的形式，是无法直接理解的。例如，下面的sql语句：
¨
¨ INSERT INTO dm_dj_swry (rydm, rymc) VALUES (00005, '张三');
¨
¨ LogMiner解释出来的结果将是下面这个样子，
¨
¨ insert into Object#308(col#1, col#2) values (hextoraw('c30rte567e436'), hextoraw('4a6f686e20446f65'));
¨
¨ 创建数据字典的目的就是让LogMiner引用涉及到内部数据字典中的部分时为他们实际的名字，而不是系统内部的16进制。数据字典文件是一个文本文件，使用包DBMS_LOGMNR_D来创建。如果要分析的数据库中的表有变化，影响到库的数据字典也发生变化，这时就需要重新创建该字典文件。另外一种情况是在分析另外一个数据库文件的重作日志时，也必须要重新生成一遍被分析数据库的数据字典文件。
¨
¨ 首先在init.ora初始化参数文件中，指定数据字典文件的位置，也就是添加一个参数UTL_FILE_DIR，该参数值为服务器中放置数据字典文件的目录。如：
¨
¨ UTL_FILE_DIR = (e:Oraclelogs)
¨
¨ 重新启动数据库，使新加的参数生效，然后创建数据字典文件：
¨
¨ SQL> CONNECT SYS
¨
¨ SQL> EXECUTE dbms_logmnr_d.build(
¨
¨ dictionary_filename => ' v816dict.ora',
¨
¨ dictionary_location => 'e:oraclelogs');
¨
¨ 2、创建要分析的日志文件列表
¨
¨ Oracle的重作日志分为两种，在线（online）和离线（offline）归档日志文件，下面就分别来讨论这两种不同日志文件的列表创建。
¨
¨ （1）分析在线重作日志文件
¨
¨ A. 创建列表
¨
¨ SQL> EXECUTE dbms_logmnr.add_logfile(
¨
¨ LogFileName=>' e:Oracleoradatasxfredo01.log',
¨
¨ Options=>dbms_logmnr.new);
¨
¨ B. 添加其他日志文件到列表
¨
¨ SQL> EXECUTE dbms_logmnr.add_logfile(
¨
¨ LogFileName=>' e:Oracleoradatasxfredo02.log',
¨
¨ Options=>dbms_logmnr.addfile);（2）分析离线日志文件
¨
¨ A.创建列表
¨
¨ SQL> EXECUTE dbms_logmnr.add_logfile(
¨
¨ LogFileName=>' E:OracleoradatasxfarchiveARCARC09108.001',
¨
¨ Options=>dbms_logmnr.new);
¨
¨ B.添加另外的日志文件到列表
¨
¨ SQL> EXECUTE dbms_logmnr.add_logfile(
¨
¨ LogFileName=>' E:OracleoradatasxfarchiveARCARC09109.001',
¨
¨ Options=>dbms_logmnr.addfile);关于这个日志文件列表中需要分析日志文件的个数完全由你自己决定，但这里建议最好是每次只添加一个需要分析的日志文件，在对该文件分析完毕后，再添加另外的文件。
¨
¨ 和添加日志分析列表相对应，使用过程 'dbms_logmnr.removefile' 也可以从列表中移去一个日志文件。下面的例子移去上面添加的日志文件e:Oracleoradatasxfredo02.log。
¨
¨ SQL> EXECUTE dbms_logmnr.add_logfile(
¨
¨ LogFileName=>' e:Oracleoradatasxfredo02.log',
¨
¨ Options=>dbms_logmnr. REMOVEFILE);
¨
¨ 创建了要分析的日志文件列表，下面就可以对其进行分析了。
¨
¨ 3、使用LogMiner进行日志分析
¨
¨ （1）无限制条件
¨
¨ SQL> EXECUTE dbms_logmnr.start_logmnr(
¨
¨ DictFileName=>' e:oraclelogs v816dict.ora ');
¨
¨ （2）有限制条件
¨
¨ 通过对过程DBMS_ LOGMNR.START_LOGMNR中几个不同参数的设置（参数含义见表1），可以缩小要分析日志文件的范围。通过设置起始时间和终止时间参数可以限制只分析某一时间范围的日志。如下面的例子，仅仅分析2001年9月18日的日志，：
¨
¨ SQL> EXECUTE dbms_logmnr.start_logmnr(
¨
¨ DictFileName => ' e:oraclelogs v816dict.ora ',
¨
¨ StartTime => to_date('2001-9-18 00:00:00','YYYY-MM-DD HH24:MI:SS')
¨
¨ EndTime => to_date(''2001-9-18 23:59:59','YYYY-MM-DD HH24:MI:SS '));
¨
¨ 也可以通过设置起始SCN和截至SCN来限制要分析日志的范围：
¨
¨ SQL> EXECUTE dbms_logmnr.start_logmnr(
¨
¨ DictFileName => ' e:oraclelogs v816dict.ora ',
¨
¨ StartScn => 20,
¨
¨ EndScn => 50);
¨
¨ 表1 DBMS_LOGMNR.START__LOGMNR过程参数含义
¨
¨
¨
¨ 4、观察分析结果（v$logmnr_contents）
¨
¨ 到现在为止，已经分析得到了重作日志文件中的内容。动态性能视图v$logmnr_contents包含LogMiner分析得到的所有的信息。
¨
¨ SELECT sql_redo FROM v$logmnr_contents;
¨
¨ 如果仅仅想知道某个用户对于某张表的操作，可以通过下面的SQL查询得到，该查询可以得到用户DB_ZGXT对表SB_DJJL所作的一切工作。
¨
¨ SQL> SELECT sql_redo FROM v$logmnr_contents WHERE username='DB_ZGXT' AND tablename='SB_DJJL';
¨
¨ 需要强调一点的是，视图v$logmnr_contents中的分析结果仅在运行过程'dbms_logmrn.start_logmnr'这个会话的生命期中存在。这是因为所有的LogMiner存储都在PGA内存中，所有其他的进程是看不到它的，同时随着进程的结束，分析结果也随之消失。
¨
¨ 最后，使用过程DBMS_LOGMNR.END_LOGMNR终止日志分析事务，此时PGA内存区域被清除，分析结果也随之不再存在。
¨
¨
¨ 其他注意事项
¨
¨ 可以利用LogMiner日志分析工具来分析其他数据库实例产生的重作日志文件，而不仅仅用来分析本身安装LogMiner的数据库实例的redo logs文件。使用LogMiner分析其他数据库实例时，有几点需要注意：
¨
¨ 1. LogMiner必须使用被分析数据库实例产生的字典文件，而不是安装LogMiner的数据库产生的字典文件，另外必须保证安装LogMiner数据库的字符集和被分析数据库的字符集相同。
¨
¨ 2. 被分析数据库平台必须和当前LogMiner所在数据库平台一样，也就是说如果要分析的文件是由运行在UNIX平台上的Oracle 8i产生的，那么也必须在一个运行在UNIX平台上的Oracle实例上运行LogMiner，而不能在其他如Microsoft NT上运行LogMiner。当然两者的硬件条件不一定要求完全一样。
¨
- Oracle备份与恢复——浅析
- Oracle 备份与恢复
- Oracle 备份与恢复
- Oracle 备份与恢复
- Oracle备份与恢复
- Oracle备份与恢复
- oracle备份与恢复
- Oracle备份与恢复
- oracle备份与恢复
- Oracle 备份与恢复
- ORACLE 备份与恢复
- oracle 备份与恢复
- oracle备份与恢复
- oracle备份与恢复
- oracle备份与恢复
- ORACLE备份与恢复
- oracle 备份与恢复
- ORACLE 备份与恢复
- mode
- 移动平台中的模块复用
- c++中被忽视的隐藏
- BugFree2.0 RC1的简易安装说明
- 比较BMP和Android的RPC机制
- Oracle备份与恢复——浅析
- hit Fish Can Fly
- ExtJS学习笔记一
- 结合工具来实现敏捷开发 - 2
- 判断字符串是不是数字
- 关键路径问题
- ARM9时钟体系
- 黑马程序员----交通灯管理系统
- 如何搭建一个数据库服务器平台 .
