Oracle 备份与恢复文摘.doc

1 Oracle远程复制和异地容灾方案分析目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：(1)基于存储层的容灾复制方案这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致，且对网络环境的要求比较高。目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。(2)基于逻辑卷的容灾复制方案这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。(3)基于oracle redo log的逻辑复制方式使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。这类产品的原理基本相同，其工作过程可以分为以下几个流程：使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制(主要在oracle9i环境中)。这种技术的技术特点和优势主要有以下几点：目标端数据库一直是一个可以访问的数据库;能保证两端数据库的事务一致性;因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小;基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力;因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差;实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活;复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。2 镜像技术优缺点大揭秘更新时间：2006-01-12 14:04关 键 词：技术阅读提示：镜像是在两个或多个磁盘或磁盘子系统上生成同一个数据的镜像视图的信息存储过程，一个叫主镜像系统，另一个叫从镜像系统。按主从镜像存储系统所处的位置可分为本地镜像和远程镜像。本地镜像的主从镜像存储系统是处于同一个RAID阵列内，而远程镜像的主从镜像存储系统通常是分布在跨城域网或广域网的不同节点上。镜像是在两个或多个磁盘或磁盘子系统上生成同一个数据的镜像视图的信息存储过程，一个叫主镜像系统，另一个叫从镜像系统。按主从镜像存储系统所处的位置可分为本地镜像和远程镜像。本地镜像的主从镜像存储系统是处于同一个RAID阵列内，而远程镜像的主从镜像存储系统通常是分布在跨城域网或广域网的不同节点上。远程镜像又叫远程复制，是容灾备份的核心技术，同时也是保持远程数据同步和实现灾难恢复的基础。它利用物理位置上分离的存储设备所具备的远程数据连接功能，在远程维护一套数据镜像，一旦灾难发生时，分布在异地存储器上的数据备份并不会受到波及。远程镜像按请求镜像的主机是否需要远程镜像站点的确认信息，又可分为同步远程镜像和异步远程镜像当企业的核心流程由于灾难的发生而无法正常进行时，将会给企业造成一定的损失。这种损失可能是可以量化的，例如单据的丢失、计算的错误而导致的直接损失；也可以是无形的损失，例如客户满意度及竞争优势的丢失。通过对可量化和不可量化损失的综合考虑，得出各种核心业务流程由于灾难受损的可容忍程度及损失的决策依据。体现在IT系统上，主要通过以下3个指标来衡量：数据恢复点目标（RPO）：体现为该流程在灾难发生后恢复运转时数据丢失的可容忍程度；恢复时间目标（RTO）：体现为该流程在灾难发生后，需要恢复的紧迫性（即：需要多久才能够得到恢复）；网络恢复目标（NRO）：即营业网点什么时候才能通过备份网络与数据中心重新恢复通信的指标。如果单单就RPO和RTO而言，同步远程镜像的得分无疑是最高的。同步远程镜像（同步复制技术）是指通过远程镜像软件，将本地数据以完全同步的方式复制到异地，每一个本地的I/O事务均需等待远程复制的完成确认信息，方予以释放。同步镜像使远程拷贝总能与本地机要求复制的内容相匹配。当主站点出现故障时，用户的应用程序切换到备份的替代站点后，被镜像的远程副本可以保证业务继续执行而没有数据的丢失。换言之，同步远程镜像的RPO值为零（即：不丢失任何数据），RTO也是以秒或分为计算单位。不过，由于往返传播会造成延时较长，而且本地系统的性能是与远程备份设备直接挂钩的，所以，同步远程镜像仅限于在相对较近的距离上应用，主从镜像系统之间的间隔一般不能超过160公里（约合100英里）。异步远程镜像（异步复制技术）则由本地存储系统提供给请求镜像主机的I/O操作完成确认信息，保证在更新远程存储视图前完成向本地存储系统输出/输入数据的基本操作，也就是说它的RPO值可能是以秒计算的，也可能是以分或小时为计算单位。它采用了“存储转化（store-and-forward）”技术，所有的I/O操作是在后台同步进行的，这使得本地系统性能受到的影响很小，大大缩短了数据处理时的等待时间。异步远程镜像具有“对网络带宽要求小，传输距离长（可达到1000公里以上）”的优点。不过，由于许多远程的从镜像系统“写”操作是没有得到确认的，当由于某种原因导致数据传输失败时，极有可能会破坏主从系统的数据一致性。同步远程镜像与异步远程镜像最大的优点就在于，将因灾难引发的数据损耗风险降低到最低（异步）甚至为零（同步）；其次，一旦发生灾难，恢复进程所耗费的时间比较短。这是因为建立远程数据镜像，是不需要经由代理服务器的，它可以支持异构服务器和应用程序。远程镜像软件和相关配套设备的售价普遍偏高，而且，至少得占用两倍以上的主磁盘空间。不过，如果贵公司的业务流程本身对数据的丢失程度（RPO）或恢复时间（RTO）相对要求较高的话，建立远程镜像将是最佳的解决之道。除了价格昂贵之外，远程镜像技术还有一个致命的缺陷，它无法阻止系统失败（rolling disaster）、数据丢失、损坏和误删除等灾难的发生。如果主站的数据丢失、损坏或被误删除，备份站点上的数据也将出现连锁反应。目前市面上只有极少数的异步远程镜像产品可做到给每一个事务盖上时间戳（timestamp），一旦发生数据损坏或误删除操作，用户可以指定数据恢复到某个时间点的状态，当然，要实现该功能，并不是仅仅安装远程镜像软件就够了，用户还需要采取其它一些必要的保护手段，比如说延迟复制技术（本地数据复制均在后台日志区进行），在确保本地数据完好无损后再进行远程数据更新。另外，远程镜像技术还存在无法支持异构磁盘阵列和内置存储组件、支持软件种类匮乏、无法提供文件信息等诸多缺点。如果用户对RPO和RTP两项指标要求较高，同时又无力承担远程镜像解决方案那么昂贵的费用，是否存在其它可行的替代方案可供选择呢？当然有，比如说基于持续性数据保护（简称CDP）、基于时间的连续快照复制、自动备份、自动复制更新数据、分布式备份等技术的产品。它们可支持异构存储系统和rollback（回卷当前事务并取消当前事务中的所有更新）功能，只不过它们的整体拥有成本（简称TCO）较远程镜像产品低一些，而且增加了“安装和管理代理服务器”这一环节。3 Oracle系统紧急故障处理方法Oracle物理结构故障的处理方法：Oracle物理结构故障是指构成数据库的各个物理文件损坏而导致的各种数据库故障。这些故障可能是由于硬件故障造成的，也可能是人为误操作而引起。所以我们首先要判断问题的起因，如果是硬件故障则首先要解决硬件问题。在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理。控制文件损坏：控制文件记录了关于oracle的重要配置信息，如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。控制文件的损坏，会导致数据库异常关闭。一旦缺少控制文件，数据库也无法启动，这是一种比较严重的错误。可以通过查询数据库的日志文件来定位损坏了的控制文件。日志文件位于?$ORACLE_BASE/admin/bdump/alert_ORCL.ora.损坏单个控制文件：1. 确保数据库已经关闭，如果没有用下面的命令来关闭数据库：svrmgrlshutdown immediate;2. 查看初始化文件?$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。3. 用操作系统命令将其它正确的控制文件覆盖错误的控制文件。4. 用下面的命令重新启动数据库svrmgrlstartup;5. 用适当的方法进行数据库全备份。损坏所有的控制文件：1. 确保数据库已经关闭，如果没有用下面的命令来关闭数据库：svrmgrlshutdown immediate;2. 从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录；对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。3. 用下面的命令来创建产生数据库控制文件的脚本：svrmgrlstartup mount;svrmgrlalter database backup controlfile to trace noresetlogs;4. 修改第三步产生的trace文件，将其中关于创建控制文件的一部分语句拷贝出来并做些修改，使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql.注意：Trace文件的具体路径可以在执行完第3）步操作后查看?$ORACLE_BASE/admin/bdump/alert_ORCL.ora文件来确定。5. 用下面命令重新创建控制文件：svrmgrlshutdown abort;svrmgrlstartup nomount;svrmgrlcreatecontrol.sql;6. 用适当的方法进行数据库全备份。重做日志文件损坏：数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏，会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志，所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员，所以在下面的分析中只考虑重做日志组损坏的情况，而不考虑单个重做日志成员损坏的情况。确定损坏的重做日志的位置及其状态：1. 如果数据库处于可用状态：select * from v?$logfile;svrmgrlselect * from v?$log;2. 如果数据库处于已经异常终止：svrmlgrstartup mount;svrmgrlselect * from v?$logfile;svrmgrlselect * from v?$log;其中，logfile的状态为INVALID表示这组日志文件出现已经损坏；log状态为Inactive：表示重做日志文件处于非激活状态；Active： 表示重做日志文件处于激活状态；Current：表示是重做日志为当前正在使用的日志文件。损坏的日志文件处于非激活状态：1. 删除相应的日志组：svrmgrlalter database drop logfile group group_number;2. 重新创建相应的日志组：svrmgrlalter database add log file group group_number （log_file_descritpion，） size log_file_size;损坏的日志文件处于激活状态且为非当前日志：1. 清除相应的日志组：svrmgrlalter database clear unarchived logfile group group_number;损坏的日志文件为当前活动日志文件：用命令清除相应的日志组：svrmgrlalter database clear unarchived logfile group group_number;如果清除失败，则只能做基于时间点的不完全恢复。打开数据库并且用适当的方法进行数据库全备份：svrmgrlalter database open;部分数据文件损坏：若损坏的数据文件属于非system表空间，则数据库仍然可以处于打开状态可以进行操作，只是损坏的数据文件不能访问。这时在数据库打开状态下可以单独对损坏的数据文件进行恢复。若是system表空间的数据文件损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开，然后再对数据文件进行恢复。可以通过查看数据库日志文件来判断当前损坏的数据文件到底是否属于system表空间。非system表空间的数据文件损坏1. 确定损坏的文件名字：svrmgrlselect name from v?$datafile where status=INVALID;2. 将损坏的数据文件处于offline状态：svrmgrlalter database datafile datafile_name offline;3. 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。4. 恢复数据文件：svrmgrlalter database recover datafile file_name;5. 使数据库文件online：svrmgrlalter database datafile datafile_name online;6. 用适当的方法进行数据库全备份。system表空间的数据文件损坏：1. 以mount方式启动数据库svrmgrlstartup mount;2. 从相应的备份结果集中恢复关于这个数据文件的最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。3. 恢复system表空间：svrmgrlalter database recover datafile datafile_name;4. 打开数据库：svrmgrlalter database open;5. 用适当的方法进行数据库全备份。表空间损坏：若非system表空间已经损坏，则数据库仍然可以处于打开状态可以进行操作，只是损坏的表空间不能访问。这样在数据库打开状态下可以单独对损坏的表空间进行恢复。若是system表空间损坏则数据库系统会异常终止。这时数据库只能以Mount方式打开，然后再对表空间进行恢复。可以通过查看数据库日志文件来判断当前损坏的表空间是否是system表空间.非system表空间损坏：1. 将损坏的表空间处于offline状态：svrmgrlalter tablespace tablespace_name offline;2. 从相应的备份结果集中恢复关于这个表空间最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。3. 恢复表空间：svrmgrlalter database recover tablespace tablespace_name;4. 使表空间online：svrmgrlalter tablespace tablespace_name online;5. 用适当的方法进行数据库全备份.system表空间损坏：1. 以mount方式启动数据库svrmgrlstartup mount;2. 从相应的备份结果集中恢复system表空间最近的备份。对于没有采用带库备份的点可以直接从磁带上恢复；对于用带库备份的点用相应的rman脚本来恢复。3. 恢复system表空间：svrmgrlalter database recover tablespace system;4. 打开数据库：svrmgrlalter database open;5. 用适当的方法进行数据库全备份。整个数据库的所有文件损坏：整个数据库所有文件的损坏一般是在共享磁盘阵列发生无法恢复的灾难时才发生，这种情况下只能对数据库进行恢复。若数据库的归档目录也已经丢失，则数据库不可能做完全恢复，会有用户数据的丢失。没采用带库备份的现场：1. 将最近的备份从磁带上把各个文件解包到相应的目录下。2. 以mount方式打开数据库：svrmgrlstartup mount;3. 恢复数据库：svrmgrlrecover database until cancel;4. 打开数据库：svrmgrlalter database open resetlogs;5. 用适当的方法进行数据库全备份。采用带库备份的现场：1. 以nomount方式打开数据库：svrmgrlstartup nomount;2. 通过相应的rman脚本进行数据库软恢复。?$rman cmdfile=hot_database_restore.rcv3. 打开数据库：svrmgrlalter database open resetlogs;4. 用适当的方法进行数据库全备份。存在最近的数据库完整冷备份前提下的一些经典紧急情况的处理：数据文件，归档重作日志和控制文件同时丢失或损坏：无新增archives 时的状况：条件和假设：自上次镜像备份以来尚未生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像（冷）拷贝恢复步骤：1. 将镜像拷贝的datafile(s) 和control file(s) 抄送回原始地点:?$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf?$ cp /backup/control1.ctl /disk1/control1.ctl2. 以mount 选项启动数据库：?$ svrmgrlsvrmgrl connect internalsvrmgrl startup mount3. 以旧的control file 来恢复数据库：svrmgrl recover database using backup controlfile until cancel;* 介质恢复完成（必须马上cancel ）4. Reset the logfiles （对启动而言不可省略）：svrmgrl alter database open resetlogs;5. 关闭数据库并做一次全库冷备份。新增archives 时的状况：条件和假设：自上次镜像备份以来已经生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像（冷）拷贝；archive log(s) 可用。恢复步骤：1. 如果数据库尚未关闭，则首先把它关闭：?$ svrmgrlsvrmgrl connect internalsvrmgrl shutdown abort2. 将备份文件抄送回原始地点：所有Database Files所有Control Files（没有archive(s) 或redo(s) 的情况下，control files 的更新无任何意义）所有On-Line Redo Logs (Not archives)init.ora file（选项）3. 启动数据库：?$ svrmgrlsvrmgrl connect internalsvrmgrl startup数据文件, 重作日志和控制文件同时丢失或损坏：条件和假设：Archivelog Mode; 有同步的所有所失文件的镜像（冷）拷贝；archive log(s) 可用恢复步骤（必须采用不完全恢复的手法）：1. 如果数据库尚未关闭，则首先把它关闭：?$ svrmgrlsvrmgrl connect internalsvrmgrl shutdown abort2. 将备份文件抄送回原始地点：所有Database Files所有Control Files所有On-Line Redo Logs(Not archives)init.ora file（选项）3. 启动数据库然而并不打开：svrmgrlstartup mount4. 做不完全数据库恢复，应用所有从上次镜像（冷）备份始积累起来的archives：svrmgrl recover database until cancel using backup controlfile;.cancel5. Reset the logfiles （对启动而言不可省略）：svrmgrl alter database open resetlogs;6. 关闭数据库并做一次全库冷备份。数据文件和控制文件同时丢失或损坏：条件和假设：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷贝；archive log(s) 可用恢复步骤：1. 将冷拷贝的datafiles(s) 和control file(s) 抄送回原始地点:?$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf?$ cp /backup/control1.ctl /disk1/control1.ctl2. 以mount 选项启动数据库：?$ svrmgrlsvrmgrl connect internalsvrmgrl startup mount3. 以旧的control file 来恢复数据库：svrmgrl recover database until cancel using backup controlfile;* 介质恢复完成（须在应用完最后一个archive log 后cancel ）4. Reset the logfiles （对启动而言不可省略）：svrmgrl alter database open resetlogs;重作日志和控制文件同时丢失或损坏时：条件和假设：Control Files 全部丢失或损坏；Archivelog Mode; 有Control Files 的镜像（冷）拷贝恢复步骤：1. 如果数据库尚未关闭，则首先把它关闭：?$ svrmgrlsvrmgrl connect internalsvrmgrl shutdown abortsvrmgrlexit2. 以Control File 的镜像（冷）拷贝覆盖损坏了的Control File:?$ cp /backup/control1.ctl /disk1/control1.ctl3. 启动数据库然而并不打开：?$ svrmgrlsvrmgrl connect internalsvrmgrl startup mount4. Drop 坏掉的redo log （排除硬件故障）：svrmgrl alter database drop logfile group 2;5. 重新创建redo log:svrmgrl alter database add logfile group 2 /orig_loc/log2.dbf size 10M;6. 以旧的control file 来恢复数据库：svrmgrl recover database until cancel using backup controlfile;（必须马上cancel ）7. Reset the logfiles （对启动而言不可省略）：svrmgrl alter database open resetlogs;8. 关闭数据库并做一次全库冷备份只发生归档重作日志丢失或损坏时：根据不同环境和情况，选择下述手段之一：a. 马上backup 全部datafiles （如果系统采用一般热备份或RMAN 热备份）b. 马上正常关闭数据库并进行冷备份（如果系统采用冷备份）c. 冒险前进！不做备份而让数据库接着跑，直等到下一个备份周期再做备份。这是在赌数据库在下一个备份周期到来之前不会有需要恢复的错误发生。注意:冒险前进的选择：如果发生错误而需要数据库恢复，则最多只能恢复到出问题archive log 之前的操作现场。从另一个角度讲，archive log(s) 出现问题时，数据库若不需要恢复则其本身并没有任何问题。Oracle逻辑结构故障的处理方法：逻辑结构的故障一般指由于人为的误操作而导致重要数据丢失的情况。在这种情况下数据库物理结构是完整的也是一致的。对于这种情况采取对原来数据库的全恢复是不合适的，我们一般采用三种方法来恢复用户数据。采用exp/imp工具来恢复用户数据：如果丢失的数据存在一个以前用exp命令的备份，则可以才用这种方式。1. 在数据库内创建一个临时用户：svrmgrlcreate user test_user identified by test;svrmgrlgrant connect，resource to test_user;2. 从以前exp命令备份的文件中把丢失数据的表按照用户方式倒入测试用户：?$imp system/manager file=export_file_name tables=(lost_data_table_name) fromuser=lost_data_table_owner touser=test_user constraint=n;3. 用相应的DML语句将丢失的数据从测试用户恢复到原用户。4. 将测试用户删除：svrmgrldrop user test_user cascede;采用logminer来恢复用户数据：Logminer是oracle提供的一个日志分析工具。它可以根据数据字典对在线联机日志、归档日志进行分析，从而可以获得数据库的各种DML操作的历史记录以及各种DML操作的回退信息。根据这些用户就可以将由于误操作而丢失的数据重新加入数据库内。1. 确认数据库的utl_file_dir参数已经设置，如果没有则需要把这个参数加入oracle的初始化参数文件，然后重新启动数据库。下面例子中假设utl_file_dir=/opt/oracle/db01；2. 创建logminer所需要的数据字典信息，假设生成的数据字典文本文件为dict.ora：svrmgrlexecute dbms_logmnr_d.build(dictionary_filename=dict.ora， dictionary_location=/opt/oracle/db01);3. 确定所需要分析的日志或者归档日志的范围。这可以根据用户误操作的时间来确定大概的日志范围。假设用户误操作时可能的日志文件为/opt/oracle/db02/oradata/ORCL/redo3.log和归档日志/opt/oracle/arch/orcl/orclarc_1_113.ora。4. 创建要分析的日志文件列表，按日志文件的先后顺序依次加入：svrmgrlexecute dbms_logmnr.add_logfile(logfilename=/opt/oracle/arch/orcl/orclarc_1_113.ora，options=dbms_logmnr.NEW);svrmgrl execute dbms_logmnr.add_logfile(logfilename= /opt/oracle/db02/oradata/ORCL/redo3.log，options=dbms_logmnr.ADDFILE);5. 开始日志分析，假设需要分析的时间在2003-06-28 12:00:00和2003-06-28 13:00:00之间：svrmgrlexecute dbms_logmnr.start_logmnr(dictfilename= /opt/oracle/db01/dict.ora，starttime=to_date( 2003-06-28 12:00:00，YYYY-MM-DD HH:MI:SS)，endtime=to_date(to_date(2003-06-28 13:00:00，YYYY-MM-DD HH:MI:SS);6. 获取分析结果：svrmgrlselect operation，sql_redo，sql_undo from v?$logmnr_contents;7. 根据分析结果修复数据。8.结束logmnr:svrmgrldbms_logmnr.end_logmnr;9. 用适当的方法对原数据库进行数据库全备份。利用备份恢复用户数据：采用这种方法时并不是在原数据库进行恢复，而是利用数据库备份在新的机器上重新建立一个新的数据库。通过备份恢复在新机器上将数据库恢复到用户误操作前，这样就可以获得丢失的数据将其恢复到原数据库。1. 在新的机器上安装数据库软件。2. 对于采用带库备份的现场，需要在新的数据库服务器上安装调试相应的备份管软件。3. 根据用户误操作的时间点进行基于时间点的数据库恢复操作。对于没有采用带库备份的现场，可以选取用户误操作前最近的备份磁带进行恢复；对于才用带库备份的点可以通过基于时间恢复点恢复的rman脚本来进行恢复。4.重新打开数据库：svrmgrlalter database open resetlogs;5. 从新的数据库中获取丢失的用户数据，通过DML操作将其恢复到原数据库中。6. 用适当的方法对原数据库进行数据库全备份。4 Oracle SCN使用方法scn号与恢复研究scn号与oracle数据库恢复过程有着密切的关系，只有很好地理解了这层关系，才能深刻地理解恢复的原理，从而才能很好地解决这方面的问题。一。SCN与CHECKPOINTCKPT进程在checkpoint发生时，将当时的SCN号写入数据文件头和控制文件，同时通知DBWR进程将数据块写到数据文件。CKPT进程也会在控制文件中记录RBA(redo block address),以标志Recovery需要从日志中哪个地方开始。与checkpoint相关的SCN号有四个，其中三个存在控制文件中，一个存放在数据文件头中。这四个分别是：1.System Checkpoint SCN当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询：select checkpoint_change# from v$database;2.Datafile Checkpoint SCN当checkpoint完成后，ORACLE将Datafile Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN号。select name,checkpoint_change# from v$datafile;3.Start SCN号ORACLE将Start SCN号存放在数据文件头中。这个SCN用于检查数据库启动过程是否需要做media recovery.我们可以通过以下SQL语句查询：select name,checkpoint_change# from v$datafile_header; 4.End SCN号ORACLE将End SCN号存放在控制文件中。这个SCN号用于检查数据库启动过程是否需要做instance recovery.我们可以通过以下SQL语句查询：select name,last_change# from v$datafile; 在数据库正常运行的情况下，对可读写的，online的数据文件，该SCN号为NULL.二。SCN号与数据库启动在数据库启动过程中，当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN号都相同时，数据库可以正常启动，不需要做media recovery.三者当中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN号为NULL，则需要做instance recovery.ORACLE在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery.三。SCN号与数据库关闭如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN号设置为相应数据文件的Start SCN号。当数据库启动时，发现它们是一致的，则不需要做instance recovery。在数据库正常启动后，ORACLE会将END SCN号设置为NULL.如果数据库异常关闭的话，则END SCN号将为NULL.四。为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号为什么ORACLE会在控制文件中记录System checkpoint SCN号的同时，还需要为每个数据文件记录Datafile Checkpoint SCN号？原因有二：1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。2.如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或END SCN号。记录这些SCN号，可以区分控制文件是否是当前的控制文件。五。Recovery database using backup controlfile当有一个Start SCN号超过了System Checkpoit SCN号时，则说明控制文件不是当前的控制文件，因此在做recovery时需要采用using backup controlfile。这是为什么需要记录SystemCheckpoint SCN的原因之一。这里需要一提的是，当重建控制文件的时候，System Checkpoint SCN为0，Datafile Checkpoint SCN的数据来自于Start SCN。根据上述的描述，此时需要采用using backup controlfile做recovery.六。示例例子背景：oracle 8iwindows采用rman做热备，在备份期间，做不少事务，同时做alter system checkpoint.RMAN run 2 allocate channel c1 type disk;3 backup database filesperset 3 format e:/full_%p_%t.bak;4 (这里需要一提的是，在这个备份角本里面我们加了filesperset 3。这样将整个数据库分成两个备份集。这样还原出来的数据文件其checkpoint_change#将不一样。否则由于数据库数据文件不多，都将包含在一个备份集中，这样即使在备份中做insert操作和alter systemcheckpoint也不会产生不同的checkpoint_change#。因为rman备份是将一个备份集中的文件同时备份的。而checkpoint_change#是存放在数据文件头部的，这样备份这些数据文件的头部的时间将是很快的。)然后RMAN run2 allocate channel c1 type disk;3 restore database;4 SQL select checkpoint_change# from v$database;CHECKPOINT_CHANGE#-2156662354SQL select file#,checkpoint_change# from v$datafile;FILE# CHECKPOINT_CHANGE#- -1 21566623552 21566623543 21566623224 21566623545 21566623546 2156662354SQL select file#,checkpoint_change# from v$datafile_header;FILE# CHECKPOINT_CHANGE# LAST_CHANGE#- - -1 21566623552 21566623493 21566623224 21566623425 21566623496 2156662342从这里可以看出，显然是需要做media recovery的。正常情况下，还需要做instance recovery.当然由于没有在线日志，所以只能做resetlogs。1.有归档日志存若有归档日志在，则只需要做一个recover database until cancel;然后即可alter database open resetlogs;SQL recover database until cancel (using backup controlfile);ORA-00279: change 2156621770 generated at 10/07/2005 14:30:06 needed for thread 1ORA-00289: suggestion : D:ORACLE8IRDBMSARC00738.001ORA-00280: change 2156621770 for thread 1 is in sequence #738Specify log: =suggested | filename | AUTO | CANCELautoORA-00279: change 2156621779 generated at 10/07/2005 14:30:51 needed for thread1ORA-00289: suggestion : D:ORACLE8IRDBMSARC00739.001ORA-00280: change 2156621779 for thread 1 is in sequence #739ORA-00278: log file D:ORACLE8IRDBMSARC00738.001 no longer needed for this recoveryORA-00308: cannot open archived log D:ORACLE8IRDBMSARC00739.001ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。SQL alter database open resetlogs;Database altered.2.无归档日志如果没有归档日志，由于restore出来是没有在线日志的。如果v$datafile_header中checkpoint_change#是相