oracle恢复没有备份的数据文件.pdf

ORACLE数据库如何恢复(邝俊标)ORACLE数据库备份与恢复与ORACLE的结构密切相关，大家先弄清ORACLE 物理结构有哪些？逻辑结构是有哪些？它们的作用是什么？弄明白这些以后，具体怎么备份、怎么恢复就需要了解下ORACLE本身是怎么管理数据库的有那些相关的ORACLE系统表？ORACLE的后台进程是怎么管理的？最后就要知道相关的ORACLE命令、语法，根据系统提示错误灵活处理了。

ORACLE 恢复主要有下面的几种问题：一、数据文件丢失恢复：二、OS备份下的基于时间的恢复三、损坏联机日志的恢复四、损坏当前联机日志恢复五损坏控制文件的恢复六、损坏回滚数据文件的恢复七、损坏临时数据文件的恢复一、数据文件丢失恢复：1、查看报警文件或动态视图v$recover_fileSQL>select * from v$recover_file;2、脱机数据文件SQL> alter database datafile 'file#' offline drop;3、打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机SQL> alter database open;4、拷贝备份从备份处copy d:\databak\ users01.dbf d:\oracle\oradata\orcl;5、恢复该数据文件SQL> recover datafile 'file#';SQL> recover database; (多个数据文件丢失，恢复整个数据库)6、恢复成功，联机该数据文件SQL> alter database datafile 'file#' online;说明：1) 采用热备份，需要运行在归档模式下，可以实现数据库的完全恢复，也就是说，从备份后到数据库崩溃时的数据都不会丢失。

2) 可以采用全备份数据库的方式备份，对于特殊情况，也可以只备份特定的数据文件，如只备份用户表空间（一般情况下对于某些写特别频繁的数据文件，可以单独加大备份频率）3) 如果在恢复过程中，发现损坏的是多个数据文件，即可以采用一个一个数据文件的恢复方法（第5步中需要对数据文件一一脱机，第6步中需要对数据文件分别恢复），也可以采用整个数据库的恢复方法。

Oracle非完整备份灾难恢复背景信息：oracle数据库故障，系统管理员误操作，删掉了所有文件。

具体情况是：删掉了所有应用程序、重要数据文件、所有控制文件。

造成全厂办公系统瘫痪，所有数据丢失。

数据库原来是归档模式，用RMAN (Recovery Manager) 备份数据，采用nocatalog备份模式，即RMAN 使用控制文件。

我们采用的备份方式：（1）首先，每天用RMAN对数据库进行全备份；（2）其次，每天用RMAN对归档日志进行全备份，备份完成后，删除日志；（3）最后，采用数据库AUTOBACKUP 方式对控制文件进行备份。

如果一切备份正常，则我们首先恢复控制文件，然后做数据库全库和LOG日志的物理恢复，最后进行逻辑恢复，在两小时内即可将数据库恢复正常，办公系统恢复正常。

到现场后，发现每天用RMAN做的全库和LOG日志备份正常，但是，数据库控制文件的备份最新的是2006年9月20日，这是由于2006年9月20日系统更改口令，造成控制文件AUTOBACKUP失败，始终没有更新。

幸运的是，我们每一次RMAN full 备份是包括了控制文件在内。

我们采用了非常规方法首先恢复了控制文件。

具体步骤如下：一、恢复步骤1、验证原始库备份是否正常2、采用NetWorker User方式恢复oracle应用程序和相应目录文件；3、非常规方法恢复controlfiles ；4、startup mount 数据库;5、restore数据文件(物理恢复);6、restore LOG日志文件(物理恢复);7、recover database 逻辑恢复数据库；8、open 数据库；9、备份数据库。

二、操作指导1、验证备份：（略）；2、通过NetWorker User 图形界面恢复oracle应用程序和相应目录文件：（略）；3、非常规方法恢复controlfiles：sqlplus /nologSQL>connect / as sysdbaSQL>startup force nomount;SQL> DECLARE2 devtype varchar2(256);3 done boolean;4 BEGIN5devtype:=sys.dbms_backup_restore.deviceAllocate(type=>'sbt_tape',ident= >'T1');6 sys.dbms_backup_restore.restoreSetDatafile;7 sys.dbms_backup_restore.restoreControlfileTo (cfname=>'e:\oracle\oradata\Control01.ctl');8sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>'test_120 8_1_5oi67e10', params=>null);9 sys.dbms_backup_restore.deviceDeallocate;10 END;11 /PL/SQL procedure successfully completed.控制文件恢复完成，将控制文件拷贝到相应位置，并以此生成三个控制文件。

ORACLE数据文件损坏,另类恢复方法。

Sam 9/23/2012 *注：此方法不能代替常规恢复场景：数据文件没有备份，也没有创建以来的所有日志，但有近期的日志（故障发生以来）SQL> host rm /u01/app/oracle/orcl/users01.dbf模拟数据文件users01.dbf丢了，此时千万不要停库！！！！！！1、找dbw 进程，查看其进程号[oracle@DBServer /]$ ps -ef|grepora_dbworacle 4656 1 0 09:53 ? 00:01:36 ora_dbw0_orcl2、到进程目录的fd 下找到删除文件[oracle@DBServer /]$ cd /proc/4656/fd[oracle@DBServerfd]$ ls -ltotal 0lr-x------ 1 oracle oinstall 64 Sep 23 16:54 0 -> /dev/nulll-wx------ 1 oracle oinstall 64 Sep 23 16:54 1 -> /dev/nulll-wx------ 1 oracle oinstall 64 Sep 23 16:54 10 ->/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4551.trcl-wx------ 1 oracle oinstall 64 Sep 23 16:54 11 ->/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4551.trmlr-x------ 1 oracle oinstall 64 Sep 23 16:54 12 ->/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/mesg/oraus. msblr-x------ 1 oracle oinstall 64 Sep 23 16:54 13 -> /dev/zerolr-x------ 1 oracle oinstall 64 Sep 23 16:54 14 -> /proc/4656/fd lr-x------ 1 oracle oinstall 64 Sep 23 16:54 15 -> /dev/zero lrwx------ 1 oracle oinstall 64 Sep 23 16:54 16 ->/u01/app/oracle/product/11.2.0/dbhome_1/dbs/hc_orcl.dat lrwx------ 1 oracle oinstall 64 Sep 23 16:54 17 ->/u01/app/oracle/product/11.2.0/dbhome_1/dbs/lkORCLlrwx------ 1 oracle oinstall 64 Sep 23 16:54 18 ->/u01/app/oracle/orcl/control01.ctllrwx------ 1 oracle oinstall 64 Sep 23 16:54 19 ->/u01/app/oracle/flash_recovery_area/orcl/control02.ctll-wx------ 1 oracle oinstall 64 Sep 23 16:54 2 -> /dev/nulllrwx------ 1 oracle oinstall 64 Sep 23 16:54 20 ->/u01/app/oracle/orcl/system01.dbflrwx------ 1 oracle oinstall 64 Sep 23 16:54 21 ->/u01/app/oracle/orcl/sysaux01.dbflrwx------ 1 oracle oinstall 64 Sep 23 16:54 22 ->/u01/app/oracle/orcl/undotbs01.dbflrwx------ 1 oracle oinstall 64 Sep 2316:54 23 -> /u01/app/oracle/orcl/users01.dbf (deleted)lrwx------ 1 oracle oinstall 64 Sep 23 16:54 24 ->/u01/app/oracle/orcl/temp01.dbflr-x------ 1 oracle oinstall 64 Sep 23 16:54 25 ->/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/mesg/oraus. msblrwx------ 1 oracle oinstall 64 Sep 23 16:54 26 ->/oradata/perfstat01.dbfl-wx------ 1 oracle oinstall 64 Sep 23 16:54 3 ->/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/log/orcl_ora _4551.trclr-x------ 1 oracle oinstall 64 Sep 23 16:54 4 -> /dev/nulllr-x------ 1 oracle oinstall 64 Sep 23 16:54 5 -> /dev/nulllr-x------ 1 oracle oinstall 64 Sep 23 16:54 6 -> /dev/nulllrwx------ 1 oracle oinstall 64 Sep 23 16:54 7 ->/u01/app/oracle/product/11.2.0/dbhome_1/dbs/hc_orcl.dat lrwx------ 1 oracle oinstall 64 Sep 2316:54 8 -> /u01/app/oracle/product/11.2.0/dbhome_1/dbs/lkins torcl (deleted)lr-x------ 1 oracle oinstall 64 Sep 23 16:54 9 -> /proc/4656/fd3、把在进程目录中的删除文件复制到原有位置(restore) [oracle@DBServerfd]$cp 23 /u01/app/oracle/orcl/users01.dbf4、恢复.(Recover)SQL> alter database datafile '/u01/app/oracle/orcl/users01.dbf' offline;SQL> recover datafile '/u01/app/oracle/orcl/users01.dbf'; Media recovery complete.SQL> alter database datafile '/u01/app/oracle/orcl/users01.dbf' online;完成恢复。

Oracle零数据丢失恢复方案ZDLRA介绍零丢失数据恢复一体机技术概览日程目前业务对数据保护的需求与面临的挑战数据恢复一体机: 基于完全不同的技术基础数据恢复一体机配置概况客户与分析师的好评总结与答疑12 3 4 5数据库保护相关的关键目标业务部门目标–任何情况下都不会丢失关键业务数据–数据保护不会影响业务处理I.T. 部门目标–确保数据库级别的可恢复性–以集中式的服务方式来保护全部数据库目前已有的备份解决方案无法实现这些目标已有的备份一体机没有为数据库做任何针对性优化数据库的数据被作为需要周期性拷贝的普通文件数据对待每天都需要备份窗口备份对生产系统的性能有巨大影响，备份窗口内系统不能全负荷工作数据被暴露在丢失的风险之下可能会丢失最后一次备份之后的所有数据变化许多彼此独立的系统需要管理只能通过添加独立的备份一体机数量的方式扩展数据库可恢复性不佳虽然保存了大量文件的拷贝，但是数据库的保护状态是未知的恢复一体机为业务和IT 提供独有的优点：最小化备份对业务的影响生产系统只需要送出变化数据. 所有备份和磁带相关的处理都可以有效减负消除数据丢失风险实时重做日志传送为时刻进行的交易提供即时的保护云规模保护能力用支持海量扩展的备份服务为全数据中心的大量数据库非常方便地提供保护确保数据库的可恢复性为数据库提供端到端的可靠性，可见性与全面控制–而不只是管理大量离散文件零丢失数据恢复一体机概述增量推送被保护数据库只需要访问和送出变化的数据最小化对生产系统的影响 ?实时重做日志传输为进行中的交易提供即时保护被保护的多个数据库为数据中心的所有数据库提供保护PB 级数据管理能力支持全部平台的10.2 到12c Oracle 数据库不需要昂贵的备份代理客户端增量存储只在磁盘上存储验证和压缩过的数据库变化数据 ?自动组合增量数据提供任意时间点的快速回复?构建于Exadata 架构的扩展性和可靠性 ?基于企业管理器提供端到端的管理和控制恢复一体机复制数据到远端的恢复一体机磁带备份卸载恢复一体机为业务和IT 提供独有的优点：最小化备份对业务的影响生产系统只需要送出变化数据. 所有备份和磁带相关的处理都可以有效减负消除数据丢失风险实时重做日志传送为时刻进行的交易提供即时的保护云规模保护能力用支持海量扩展的备份服务为全数据中心的大量数据库非常方便地提供保护确保数据库的可恢复性为数据库提供端到端的可靠性，可见性与全面控制–而不只是管理大量离散文件为所有数据库提供类似Data Guard 的保护能力基于简单数据拷贝的通用备份一体机 ?每天进行一次备份数据损失风险: 上次备份之后所有的交易数据零丢失数据恢复一体机通过Data Guard 提供的内存缓冲区实时连续日志传输机制来保护实时进行的交易数据被保护的多个数据库数据损失本来就是不好的.往往会变得更加严重..它会在数据库之间产生巨量的数据一致性及其后续问题磁带库单向数据传递双向数据传递枢纽方式远端数据中心本地数据中心针对站点级故障提供数据保护的部署方式恢复一体机之间支持远程数据同步，可以为站点失效或灾难提供公保护支持自动从本地或远程的恢复一体机直接恢复数据针对人为错误或误操作的保护能力独立的磁带归档机制可选的低成本磁带归档机制在以下意外情况下确保数据不被破坏: –黑客，内部人员或病毒软件发起的数据破坏–意外导致的数据删除（磁带作为长期归档机制）–主要数据保护系统功能异常内置独立的磁带归档机制: 只需要外接带库就可以实现–卸载磁带备份对生产系统的压力–不需要在生产系统部署大量昂贵的戒指管理软件的代理程序–磁带驱动器可以在不拖慢生产系统的情况下全天有效运行–内含Oracle Secure Backup 软件, 也可以使用其他第三方磁带管理软件支持绝大部分主流磁带库16Gb FC从数据接收开始完成校验 ?周期性进行数据重新校验 ?恢复数据时先校验再恢复接收数据时和提供恢复时都会校验数据, 同时会对磁盘上的数据周期性进行校验数据向磁带机传出和从磁带机恢复时都会进行校验磁带归档远端复制一体机生产一体机针对数据损坏的保护能力恢复一体机充分理解数据库数据的格式并且会对数据进行端到端校验恢复一体机为业务和IT 提供独有的优点：最小化备份对业务的影响生产系统只需要送出变化数据. 所有备份和磁带相关的处理都可以有效减负消除数据丢失风险实时重做日志传送为时刻进行的交易提供即时的保护云规模保护能力用支持海量扩展的备份服务为全数据中心的大量数据库非常方便地提供保护确保数据库的可恢复性为数据库提供端到端的可靠性，可见性与全面控制–而不只是管理大量离散文件全增量架构不再需要重复运行全量备份: 针对数据库优化的永远增量的备份方式增量推送增量推送在源端完成数据去重 ?快速增量备份- 永远不需要读取重复的数据块 - 从来不发送重复的数据块消除为提交过的交易备份Undo 数据块的需求 ?消除不必要的未使用数据块访问和备份管理备份数据的增量存储 ?只存储变化数据 ?在数据块级实现压缩只向复制节点传输增量变化数据被保护数据库压缩的增量存储显著节省数据库的 I/O 开销以及网络传输开销变化数据不再需要重复的全量备份,只传输变化数据灾备系统有效利用存储空间的“虚拟”全备份当完成初始的全量备份后, 后续的增量备份按天生成的虚拟数据库全备份展现为增量备份时间点的物理全备份，内部以指针的方式组织数据虚拟备份典型情况下可以提供 10 倍的存储有效性以可能的最小存储空间开销来使长期保存备份数据得以实现提供数据库保护的“时间机器” 机制增量存储被保护的数据库们第N 天增量第1天的虚拟全备第N 天的虚拟全备第1天增量第0天全备不再需要重复进行全备份: 永远增量架构快速回复到任意时间点不需要生产服务器消耗时间和资源来合并就得备份集直接恢复任意一个虚拟全备所有被虚拟全备引用到的数据块都保证高效读取消除传统方式恢复全备然后合并多个增量给生产系统带来的处理压力基于底层的 Exadata 硬件架构提供高性能与高扩展性增量存储被保护的数据库们RESTORE DATABASE TO DAY ‘N’第0天全备第1天增量第N 天增量第‘N’ 天的全备最小化备份影响: 有效提升生产系统性能卸载备份数据处理, 消除昂贵的备份代理程序, 降低网络负载如今的数据库服务器备份时性能下降磁盘 / 磁带 / 去重各种备份代理程序备份相关操作:合并, 压缩, 校验, 删除,全量备份,磁带备份卸载备份负载后性能得以显著提升有恢复一体机配合工作的数据库服务器Disk / Tape / DedupeBackup Agents Backup Operations: Merge, Compress, Validate, Delete, Full/Tape Backups增量推送恢复一体机为业务和IT 提供独有的优点：最小化备份对业务的影响生产系统只需要送出变化数据. 所有备份和磁带相关的处理都可以有效减负消除数据丢失风险实时重做日志传送为时刻进行的交易提供即时的保护云规模保护能力用支持海量扩展的备份服务为全数据中心的大量数据库非常方便地提供保护确保数据库的可恢复性为数据库提供端到端的可靠性，可见性与全面控制–而不只是管理大量离散文件3四分五裂的备份数据缺乏有效的责任管理如今现状: 四分五裂的备份流程有效管理备份与数据增长: 企业 IT 的第一大隐忧1数据库集合明确定义的Oracle 数据块格式RMAN 备份集没有意义的比特流2媒体服务器恢复一体机: 端到端保护并提供可见性基于策略的管理机制: 针对特定应用的数据保护1针对应用的数据保护策略明确定义的Oracle 数据块格式RMAN 备份集端到端进行Oracle 数据块校验2数据恢复一体机3与 EM Cloud Control 整合的管理界面。

Oracle数据库备份和恢复操作手册1ORACLE数据库数据备份和恢复操作手册1.1.ORACLE参数设置进入CMD操作界面，使用sqlplus连接数据库，图例 1 数据库连接操作连接语法：sqlplus system/Oracle2013@orcl参数说明备注sqlplus 语法命令system 数据库管理员用户名Oracle2013 system用户密码orcl 数据库连接标示符数据库安装目录的tnsnames.ora文件中可以找到Oracle11G目录：C:\app\Administrator\product\11.2.0\dbho me_1\NETWORK\ADMIN图例 2 环境变量设置1.2.数据备份备份脚本：expdp system/Oracle2013@orcl directory=file_path dumpfile=ARADMIN.dat logfile=ARADMIN.log schemas=ARADMIN参数说明备注expdp 语法命令system 数据库管理员用户名Oracle2013 system用户密码orcl 数据库连接标示符数据库安装目录的tnsnames.ora文件中可以找到Oracle11G目录：C:\app\Administrator\product\11.2.0\dbho me_1\NETWORK\ADMINdirectory 文件目录名称导出数据库文件的存放目录dumpfile 数据库文件名称导出数据库文件的文件名logfile 数据库日志文件名称导出数据库的日志文件名称schemas 数据库用户图例 3 数据库备份操作成功导出。

图例 4 成功导出1.3.数据恢复1.3.1.删除ARADMIN用户1.连接数据库sqlplus system/Oracle2013@orcl图例 5 连接数据库2.删除目标数据库中的ARADMIN用户drop user ARADMIN cascade;图例 6 成功删除目标数据库中的ARADMIN用户1.3.2.重新创建ARADMIN用户1.连接数据库sqlplus system/Oracle2013@orcl图例7 连接数据库2.创建ARADMIN用户create user ARAdmin identified by AR#Admin# default tablespace ARSYSTEM temporary tablespace ARTMPSPC quota unlimited on arsystem;图例8创建ARADMIN用户3.赋予数据库权限grant alter session,create cluster,create database link,create sequence,create session,create synonym,create table,create view,create procedure,createtrigger,query rewrite to ARAdmin;图例9 赋予数据库权限1.3.3.数据库导入导入命令：impdp system/Oracle2013@orcl directory=file_path dumpfile=ARADMIN20130606.DAT logfile= ARADMIN20130614.log schemas=ARADMIN图例10 数据库导入导入完成1.4.EXP/IMP与EXPDP/IMPDP 对比1.0.1运行位置不同1.0.2EXP/IMP不同模式原理:exp/imp 默认会是传统路径，这种模式下，是用SELECT 加数据查询出来,然后写入buffer cache,在将这些记录写入evaluate buffer. 最后传到Export客户端，在写入dump文件。

Oracle备份恢复操作说明配置要求在使用爱数备份存储柜进行备份和恢复 Oracle 数据库、表空间、控制文件和归档日志等数据之前，应检验每个要保护的 Oracle SID（数据库）是否满足下列条件：∙使用爱数备份存储柜的用户应被分配了一个可用来登录到Oracle 数据库的Oracle 用户帐户。

∙Oracle Server 的数据库日志模式设置为ARCHIVELOG。

∙Oracle Server 的自动归档在Oracle 参数初始化文件中是启用的（该文件的默认名称为Init(SID).ora，其中SID 是实例名称）。

∙在Oracle Server 上有一个Oracle 在其中生成Archived Logfiles 的目录。

创建 Oracle 用户账户必须存在具有适当数据库权限的用户帐户爱数备份存储柜才能访问 Oracle 数据库。

您可以使用具有所需权限的现有用户帐户，或者创建具有所需权限的新用户帐户。

若要创建专门用于爱数备份存储柜的 Oracle 用户帐户，请使用 Oracle 服务器管理器应用程序并从提示符处输入以下命令：create user USERNAME identified by PASSWORD;grant dba to USERNAME;请确保用分配的登录用户名替换 USERNAME，用适当的密码替换 PASSWORD。

输入以上所有命令之后，分配的用户将具有保护数据库所需的适当权限。

注意：确保您是作为DBA 连接。

检验归档日志模式在备份 Oracle 数据库之前，必须将每个数据库的 Oracle 数据库日志模式设置为ARCHIVELOG，并且必须启用每个数据库的自动归档设置。

必须启用 ARCHIVELOG，爱数备份存储柜中的 Oracle 备份模块才能在运行备份操作前将每个表空间置于备份模式。

检验数据库日志是否处于 ARCHIVELOG 模式以及是否启用了“自动归档”的具体步骤如下：∙从服务器管理器的命令提示符处键入以下命令：archive log list;您应该看到： Database Log Mode ARCHIVE LOGAutomatic Archival ENABLED如果有任一参数没有正确设置，请关闭数据库，然后正确设置它。

25、恢复没有备份的数据文件在数据文件崩溃之前没有任何备份的情况下，要恢复这个文件通常要符合如下条件：●所需恢复的数据文件不属于系统表空间或还原/回滚段表空间。

●由于介质损坏或用户错误操作导致数据文件的丢失，但是这个文件从来就没有备份过。

●在创建本次丢失的数据文件之前数据库处于归档模式下。

●从这个数据文件创建以来所有的归档日志文件都完整无损。

步骤:1、如果数据库是在打开状态，使用数据字典dba_data_files获取要恢复的数据文件所对应的表空间及它所对应的状态。

SQL>select tablespace_name,table_name,status from dba_data_file;2、如果数据库处在联机状态，使用数据库字典dba_tablespace获取要恢复的表空间信息，通过表空间V$database获取要恢复的数据文件是否处在联机状态。

3、如果表空间处于联机状态，要先将表空间脱机状态，也可以将数据文件设为脱机，打开数据库。

如果数据已经关闭，启动到mount状态将数据文件脱机，再打开数据库。

(1)如果数据库处于打开状态SQL>alter database datafile ‘c:\test.dbf’ offline;(2)如果数据库处于关闭状态SQL>startup mount;SQL>alter database datafile ‘c:\test.dbf’ offline;SQL>alter database open;4、使用v$recover_file查看数据文件的恢复状态5、在数据库打开状态下，使用alter database create datafile重建数据文件结构。

SQL>alter database create datafile ‘c:\test.dbf’ as‘c:\test.dbf’;6、再次使用v$recover_file查看数据文件的恢复状态7、使用：recover tablespace “表空间”，也可以使用recover datafile “数据文件”把数据从归档日志文件盒重做日志文件重新写入已经修复的数据文件。

ORACLE 数据库备份和恢复手册（草订版）CINtel Lunar2002. 10.21目录*热备过程 (5)*仅仅丢失一个普通用户数据文件的恢复A(联机恢复) (8)准备工作 (8)shutdown abort关闭例程，模拟数据文件丢失 (10)Mount数据库 (10)使损坏的数据文件脱机 (10)打开数据库 (10)拷贝刚才热备的数据文件（USERS01.DBF） (11)恢复损坏的数据文件 (11)使恢复完成的数据文件联机 (11)验证恢复的结果：完全恢复 (11)说明： (12)*仅仅丢失一个普通用户数据文件的恢复B(脱机恢复) (12)准备工作 (12)Shutdown immediate，然后模拟数据文件丢失 (13)模拟数据文件丢失，然后用热备覆盖这个文件 (13)mount数据库 (13)使损坏的数据文件脱机 (14)恢复数据文件 (14)使恢复的数据文件联机 (16)打开数据库 (16)这时需要重新启动数据库，并完全恢复数据库 (17)重新启动数据库， (17)用recover database再次恢复数据库 (17)重新使恢复的表空间联机 (18)验证恢复结果：完全恢复 (18)说明： (18)*shutdown immedate，恢复全部数据文件（不包括control和redo） (19)复制全部热备的数据文件过来（完全恢复成功！） (19)mount数据库 (19)完全恢复数据库 (20)打开数据库 (20)验证恢复结果：完全恢复 (21)说明： (21)*shutdown abort的情况，恢复全部数据文件（不包括control和redo） (21)复制全部热备的数据文件过来（完全恢复成功！） (22)mount数据库 (22)完全恢复数据库 (22)打开数据库 (23)验证恢复结果：完全恢复 (23)说明： (23)*shutdown immediate，丢失全部控制文件（不包括数据文件和redo），A(完全恢复) (24)用热备的控制文件恢复（把热备的控制文件拷贝回来） (24)mount数据库 (24)完全恢复和until cancel using backup controlfile都失败 (24)重建控制文件 (25)找到那个控制文件，然后编辑 (25)重建控制文件，并且恢复数据库（完全恢复成功！） (26)验证恢复结果：完全恢复 (26)说明： (27)*shutdown abort的情况，恢复全部控制文件（不包括数据文件和redo） (27)准备工作 (27)删除那个控制文件，把热备的控制文件拷贝过来 (29)mount数据库 (29)根据提示，重建口令文件 (29)用to trace;备份控制文件 (30)找到那个控制文件，然后编辑 (31)重建控制文件，并且恢复数据库(完全恢复成功！) (31)说明： (32)*shutdown immediate的情况，丢失全部控制文件和数据文件（不包括redo），方法1 (32)准备工作 (32)然后单独开启一个实例，再shutdown immediate (34)拷贝热备的所有控制文件和数据文件 (34)mount数据库 (34)根据提示，重建口令文件 (35)用to trace备份控制文件 (35)shutdown immediate关闭数据库 (35)找到那个控制文件，然后编辑： (36)重建控制文件，并且恢复数据库 (36)关闭数据库 (37)重新mount，作完全恢复（recover database;） (37)打开数据库 (39)验证恢复结果：完全恢复 (40)说明： (40)*shutdown immediate的情况，丢失全部控制文件和数据文件（不包括redo），方法2 (41)准备工作 (41)把热备的控制文件和数据文件拷贝过来 (42)mount数据库 (42)根据提示，重建口令文件 (42)尝试恢复数据库（现在恢复是不可以的） (43)试图打开数据库（现在打开是不可以的） (43)重新mount数据库 (44)备份控制文件 (44)找到那个控制文件，并且编辑它 (44)重建控制文件，并自动完全恢复数据库 (45)验证恢复结果：完全恢复 (46)说明： (46)*shutdown abort的情况，恢复全部控制文件和数据文件（不包括redo） (47)准备工作 (47)单开一个session，用来shutdow abort (48)拷贝所有的控制文件和数据文件（不包括redo） (48)mount数据库，按照提示重建口令文件 (48)这时，试图完全恢复数据库是不成功的 (49)用to trace备份控制文件 (49)找到并且编辑控制文件 (49)重建控制文件 (50)shutdown immediate，然后重新恢复数据库 (51)完全恢复数据库 (51)打开数据库 (53)说明： (54)*shutdown abort后，丢失全部文件（除了archive log和init.ora） (54)准备工作 (54)新开一个session，进行shutdown abort (56)把热备的数据文件和控制文件拷贝过来 (56)mount数据库 (56)根据提示重建口令文件 (57)用to trace备份控制文件 (57)找到这个跟踪文件并编辑它 (57)重建控制文件（这种丢失的状态重建控制文件是错误的） (58)Mount数据库 (59)用using backup controlfile进行恢复 (59)用Open Resetlog 打开数据库 (62)验证恢复结果：不完全恢复，redo里面的数据丢失了 (63)说明： (63)*丢失非系统非当前活动回滚段表空间中的一个数据文件 (64)首先是做一次热备（因为上次已经做了不完全恢复resetlogs） (64)数据准备工作1 (67)以上改动后需要作一次热备或者冷备，否则数据文件丢失后不能恢复（增加表空间，数据文件都要备份数据库） (69)数据准备工作2 (72)Shutdow abort，然后删除test01.dbf，模拟数据文件丢失 (72)删除test01.dbf，把备份的数据文件test01.dbf拷贝过来 (73)Mount数据库 (73)恢复数据文件（把最近的热备的文件拷贝过来） (73)打开数据库 (73)验证恢复结果：完全恢复 (74)*丢失系统表空间（SYSTEM） (74)*丢失一个非当前的redo log group (75)*丢失一个当前的redo log group (75)*丢失一个非当前非唯一的redo log member (75)*丢失一个非当前的唯一的redo log member (75)*丢失一个当前的非唯一的redo log member (75)*丢失一个当前的唯一的redo log member (76)*丢失一个非唯一的控制文件 (76)*丢失当前回滚段 (76)*丢失某个非系统表空间的一个数据文件 (76)附录： (76)For windowx的数据库备份脚本 (76)备份脚本（aa.sql） (76)生成的用于实际做备份的脚本（backup_ts.sql） (78)备份过程的日志（backup.log） (81)备份ops的脚本 (83)备份脚本（createbackup.sh） (83)生成的用于实际做备份的脚本（dobackup.sql） (86)用于调用这个生成的实际需要调用的脚本（dobackup.sh） (89)备份过程的日志（backup.log） (89)备份unix或者linux单台实例的数据库脚本 (92)备份脚本（createbackup.sh） (92)生成的用于实际做备份的脚本（dobackup.sql） (94)用于调用这个生成的实际需要调用的脚本（dobackup.sh） (94)备份过程的日志（backup.log） (94)*热备过程E:\>sqlplus internalSQL*Plus: Release 8.1.7.0.0 - Production on 星期日10月20 20:36:50 2002(c) Copyright 2000 Oracle Corporation. All rights reserved.连接到:Oracle8i Enterprise Edition Release 8.1.7.0.0 - ProductionWith the Partitioning optionJServer Release 8.1.7.0.0 - ProductionSQL> @e:\backupdb\other\aaTO_CHAR(SYSDATE,'''YY---------------------'2002-10-20 08:10:51'SQL>SQL> @e:\backupdb\other\backup_ts.sqlSQL> --set termout off;SQL> set echo off head off feedback off pagesize 0;20-10月-02BEGINING ARCHIVE LOG NUMBER IS :数据库日志模式存档模式自动存档启用存档终点d:\BACKUPDB\archive最早的概要信息日志序列0下一个存档日志序列 1当前日志序列 1Begin Backup Tablespace SYSTEM.'D:\BACKUPDB\SYSTEM01.DBF' ... 已复制 1 个文件。

数据文件丢失, 没有备份, 拥有文件创建以来的全部归档,使用RMAN恢复, 报错RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 726 scn 1757142927;使用sqlplus恢复, 执行 'Alter Database recover datafile ' Fails with ORA-279总结: RMAN备份没有使用catalog, controlfile默认保留7天的备份/归档信息,v$archived_log没有记录足够多的归档信息, 所以报RMAN-06102, 需要通过CATALOG命令注册.SQLPLUS 执行 'Alter Database recover datafile ' Fails with ORA-279 因为9.2.0.6版本使用这个命令不能自动执行recover. 用户版本9.2.0.1也遇到同样的问题, 使用RECOVER DATAFILE即可.处理步骤:1. 生成controlfile 备份到文本ora9roro_ora_479268.trc2. 查询该文件创建时间为Feb 21 11:10:24 2006 (查询alert.log)1.Tue Feb 21 11:10:24 20062.CREATE TABLESPACE tzgl DATAFILE 'tzgl' SIZE 100M3.Tue Feb 21 11:10:29 2006pleted: CREATE TABLESPACE tzgl DATAFILE 'tzgl' SIZE 100M5.Tue Feb 21 21:58:23 20066.Thread 1 advanced to log sequence 2777.Current log# 3 seq# 277 mem# 0: /oradata/ora9roro/redo03.log8.Tue Feb 21 21:58:23 20063. 用户说没有备份(没有确实检查是否有备份),创建空文件,因为有全部的归档文件存在,考虑建空文件, 使用归档文件恢复.1.alter database create datafile '/oracle/product/9.2.0/dbs/tzgl' as '/oracle/product/9.2.0/dbs/tzgl';或者就写alter database create datafile 12 as '/oracle/product/9.2.0/dbs/tzgl';该文件file#=12.4.rman target /1.rman> recover datafile 12; 失败2.archive log thread 1 sequence 1116 is already on disk as file /oradata/ora9roro/archive/1_1116.dbf3.archive log thread 1 sequence 1117 is already on disk as file /oradata/ora9roro/archive/1_1117.dbf4.archive log thread 1 sequence 1118 is already on disk as file /oradata/ora9roro/archive/1_1118.dbf5....6.RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 728 scn 17573570127.RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 727 scn 17573570098.RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 726 scn 17571429275. 检查归档文件是否存在, 发现从1_1.dbf直到现在, 所有的ARCHIVELOGS都存在.但RMAN-06102错误信息表明controlfile并没有记录下所有的归档信息.查看参数control_file_record_keep_time 为默认值7. 所以只保留7天的备份信息.调整control_file_record_keep_time=365以保证以后的备份可以保留更长的时间.6. 企图注册归档文件到controlfile. 但不支持, 只针对standby controlfile.1.alter database register logfile '/oradata/ora9roro/archive/1_726.dbf';2.ERROR at line 1:3.ORA-01665: controlfile is not a standby controlfile7. 尝试通过sql plus 恢复, 也失败. ---但这里并没有查看原因, 想当然认为rman恢复不行,sqlplus 执行也不行. 在step 16找到了原因.1.SQL> conn / as sysdba2.Connected.3.SQL> alter database recover datafile 12;4.alter database recover datafile 125.*6.ERROR at line 1:7.ORA-00279: change 1181419363 generated at 02/21/2006 11:10:29 needed for thread8. 19.ORA-00289: suggestion : /oradata/ora9roro/archive/1_276.dbf10.ORA-00280: change 1181419363 for thread 1 is in sequence #2768. 验证问题是否出在归档文件, 尝试移动/oradata/ora9roro/archive/1_276.dbf到其他目录, 然后进行恢复alter database recover datafile 12;错误同上.所以, 不是归档文件本身故障的问题. 继续查无法读取归档文件的原因.9. 查看是否重建过controlfile或open resetlogs操作.从2006年2月21日开始，有没有做过重建controlfile或open resetlogs之类的操作？1.select RESETLOGS_TIME from v$database;2.RESETLOGS3.---------16-APR-05结果表示, 没有resetlog过, 也没有重建过controlfile10.查看v$bakcup_piece, v$backup_datafile发现有记录, 是2006年12月29日的备份记录,备份到带库.原来并非像用户所说没有备份root身份查看#crontab -l找到备份,每天执行,可是查看/tmp/bkdb_$dt.log文件, 最后一次成功备份是bkdb_200612250100.log1.0 1 * * * /usr/tivoli/tsm/client/oracle/orabackup.sh >/dev/null#2.# cat /usr/tivoli/tsm/client/oracle/orabackup.sh3.export dt=`date +%Y%m%d%H%M`4.su - oracle -c "rman target / nocatalog cmdfile /oracle/sched/bkdb.scr msglog /tmp/bkdb_$dt.log"5.6./oracle/sched/bkdb.scr备份脚本内容: bkdb_200612290100.log7.RUN{8.ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' parms =9.'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';10.BACKUP11.FORMAT 'df_T%T_s%s_p%p_t%t'12.FILESPERSET 213.DATABASE;14.RELEASE CHANNEL ch00;15.}11. 尝试恢复:1.RMAN> RUN{2.ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' parms =3.'EN2> 3> V=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';4.4> restore datafile 12;5.5> release channel ch006.6> ;7.7> }8.ing target database controlfile instead of recovery catalog10.allocated channel: ch0011.channel ch00: sid=11devtype=SBT_TAPE12.channel ch00: Tivoli Data Protection for Oracle: version 5.2.0.013.14.Starting restore at 07-APR-0815.16.channel ch00: starting datafile backupset restore17.channel ch00: specifying datafile(s) to restore from backup set18.restoring datafile 00012 to /oracle/product/9.2.0/dbs/tzgl19.released channel: ch0020.RMAN-00571: ===========================================================21.RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============22.RMAN-00571: ===========================================================23.RMAN-03002: failure of restore command at 04/07/2008 14:20:0924.ORA-19501: read error on file "df_T20061229_s2660_p1_t610419667", blockno 1 (blocksize=512)25.ORA-27190: skgfrd: sbtread2 returned error26.ORA-19511: Error received from media manager layer, error text:27.ANS1314E (RC14) File data currently unavailable on server12. 带库有问题, 或者数据已经被覆写. 所以, 不再考虑使用备份做恢复.13. 查看v$recover_file, v$recovery_log, v$log_history,看系统状态,信息存储在recover.lst中1.set pagesize 200002.set linesize 1803.set pause off4.set serveroutput on5.set feedback on6.set echo on7.set numformat 9999999999999998.Spool recover.lst9.select substr(name, 1, 50), status from v$datafile;10.select file#,substr(name,1,50), recover, fuzzy, to_char(checkpoint_time,'dd/mm/yyyy:hh24:mi:ss') ckpt_time, checkpo11.int_change#, resetlogs_change#, to_char(resetlogs_time,'dd/mm/yyyy HH24:MI:SS')12.tm from v$datafile_header;13.select * from v$backup;14.select name, open_mode, checkpoint_change#, ARCHIVE_CHANGE# from v$database;15.select GROUP#,THREAD#,SEQUENCE#,MEMBERS,ARCHIVED,STATUS,FIRST_CHANGE# from v$log;16.select GROUP#,substr(member,1,60) from v$logfile;17.select * from v$log_history;18.select * from v$recover_file;19.select * from v$recovery_log;20.select HXFIL File_num,substr(HXFNM,1,40) File_name,FHTYP Type,HXERR Validity,21.FHSCN SCN, FHTNM TABLESPACE_NAME,FHSTA status ,FHRBA_SEQ Sequence22.from X$KCVFH;23.spool off14恢复方案:1. 1. alter database create datafile 12 as '/oracle/product/9.2.0/dbs/tzgl'; ----ÒѾ×öÁËin step32. 2. recover datafile 12;3. 3. now start applying archives from the time of creation of datafile.4. 4. once the archives are applied and redo logs are applied, you can issue the command, "alter database open".15. 注册归档文件到controlfile (和catalog db 可选)1.rman target /2.RMAN> list archivelog all; --[1_1116.dbf, 1_1164.dbf]3.RMAN> CATALOG ARCHIVELOG '/oradata/ora9roro/archive/1_1.dbf'; ---添加到v$archived_log4.RMAN> list archivelog all; --多显示1_1.dbf记录5.Key Thrd Seq S Low Time Name6.------- ---- ------- - --------- ----7.1165 1 1 A 16-APR-05 /oradata/ora9roro/archive/1_1.dbf16. 在step7中登陆sqlplus恢复失败, 查原因:1.metalink<352617.1> 'Alter Database recover datafile ' Fails with ORA-2792.Noticable difference between 9.2.0.6 and other versions is that the "recover datafile" syntax does not auotmatically3.perform auto recover, Oracle prompts for each log. On other versions this is not the case.4.This is reported as Bug: 4178579 - ALTER DATABASE RECOVER DATAFILE IS BROKEN IN 9.2.0.6解决方法:e different syntax:2.recover datafile x3.recover automatic datafile x4.alter database recover automatic datafile x文章来源：网络编辑：联动北方技术论坛（如有侵权请及时联络以便删除）。