Oracle丢失归档日志文件的数据库恢复方法
Oracle数据库恢复案例
Oracle数据库恢复案例当我们在使用Oracle数据库时，突然断电，造成很多问题，致使旧数据丢失，影响了数据的正确性，破坏了数据库。
此时，用户急切需求恢复数据。
本文以此为例，讲述数据库数据恢复。
一、案例描述：数据库因突然断电，数据库启库报system01.dbf需要更多的恢复来保持一致性，数据库无法打开；数据库没有备份，归档日志也不连续。
客户提供了数据库的在线文件，急需恢复zxfg用户下的数据。
二、恢复流程：1 数据库的故障检测2 尝试挂起数据库并修复数据库3解析数据文件4验证数据5导出数据与交付数据（导入）三、恢复数据1数据库的故障检测利用DBV 命令检测数据文件的完整性结果如下：分析结果发现SYSAUX01.DBF文件数据块（Data）检测失败40页，索引页（Index)检测失败29页，说明SYSAUX01.DBF存在坏块。
结论：通过dbv对数据文件的完整性检验，SYSAUX01.DBF存在坏块，其他检测的文件完整。
2 用客户的数据库本地挂起数据库，尝试修复数据库。
2.1创建新的OS ：windows server 2008 x86，安装oracle 11.2.0.1.0 for 32-bit版本数据库，挂起数据库起库报ORA-01110错误，System01.dbf需要更多一致性恢复。
使用recover database 命令，利用在线日志做介质恢复。
数据库的控制文件已被修改，需要使用控制文件恢复数据库恢复数据库需要2016_01_19的11号归档日志。
由于归档日志丢失，使用cancel 参数进行不完全恢复。
再次执行alter database open 命令，数据库打开。
2.2 查询实例状态，数据库报ora_00600错误；进行其他查询，其中一些查询可以进行，一些查询报错，而且报错都是ora_00600错误。
2.4查看警告日志追踪文件查看内部错误代码；警告日志部分内容如下：ORA-00600: internal error code, arguments: [13013], [5001], [267], [8456009], [5], [8456009], [17], [], [], [], [], []Non-fatal internal error happenned while SMON was doing logging scn->time mapping. 进行各种尝试，查阅大量资料。
ORACLE备份和恢复方案
ORACLE数据库备份与恢复方案备份方案设计前提：数据库设置为归档模式，不使用恢复目录数据库1、一个月一次在线全库备份2、每天归档日志备份3、每周一次exp导出4、每天一次exp增量导出5、保留最近两次全备和归档日志的备份6、至少保留最近一个月exp文件7、既备份到磁盘也备份到磁带Win2000下oracle8i/9i的备份方案的实现说明：数据库实例：ora9i，备份目录为e:\backup每个月一次全备1、备份命令文件：fullbackup.batrman cmdfile=fullbackup.rcvcopy C:\oracle\oradata\ora9i\CONTROL01.CTL e:\backup\CONTROL01.CTL /y 2、RMAN参数文件：fullbackup.rcvconnect target system/manager@ora9i;run{allocate channel c1 type disk;backup full tag 'dbfull' format 'e:\backup\dbfull%u_%s_%p' database;sql 'alter system archive log current';backup archivelog all delete input format 'e:\backup\arch%u_%s_%p';release channel c1;}3、任务计划增加一个每月1号1点开始执行的任务计划fullbackup每天一次归档日志的备份1、备份命令文件：archbackup.batrman cmdfile=archbackup.rcv2、RMAN参数文件：archbackup.rcvconnect target system/manager@ora9i;run{allocate channel c1 type disk;sql 'alter system archive log current';backup archivelog all delete input format 'e:\backup\arch%u_%s_%p';release channel c1;}3、任务计划增加一个每天2点开始执行的任务计划archbackupUNIX下oracle8i/9i的备份方案的实现基本相同，但计划任务得用crontab来实现恢复方案设计Win2000下oracle8i/9i的恢复方案的实现一、故障描述：磁盘损坏，数据库彻底瘫痪处理方法：1、更换磁盘，重新安装ORACLE（如果数据库安装的磁盘也损坏的话），重新创建实例ora9i，让数据库处于shutdown状态。
几种oracle数据库恢复的练习示例
7:提示文件不存在。
8ห้องสมุดไป่ตู้还原热备的文件，令该文件脱机。
Alter database datafile ‘88888888’ offline;
9:打开数据库。
10:恢复该文件。
Recover databfile ‘88888888’;
11:alter database datafile online.
而联机日志则可以保证数据库恢复到发生事故时的状态，算是完全恢复。
如果没归档的联机日志丢失（状态为ACTIVE或者CURRENT），则只能使用归档日志恢复到最后一个归档日志的地方，是不完全恢复。
End;
/
5：切换几次日志，使所有日志都已经归档。
Alter system switch log file;
6:正常关闭数据库。Shutdown immediate;
7:恢复：
把当前数据库所有文件移动到一个临时文件夹里，模拟数据库损坏。
8：COPY最初复制的数据库的所有文件，但控制文件和日志文件要使用目前数据库的。
9：启动数据库 startup
mount 后会提示SYSTEM表空间需要恢复。并给出恢复使用的归档日志文档。
确定归档日志位置正确后，输入auto.
ORACLE将一个一个的应用归档文档。直至提示完全恢复成功。
10：打开数据库 alter database open;
11:查看user1用户及t1表中是否有刚才插入的10000条记录。
ORA-00279: ?? 84851370 (? 09/24/2003 11:16:01 ??) ???? 1 ????
ORA-00289: ??: D:\ORACLE\ORADATA\SAMPLE\ARCHIVE\TESTT001S01324.ARC
Oracle数据库RMAN恢复之数据文件的恢复详解
除了system表空间的数据文件（mount）之外，其它数据文件可以在open(mount也可以)状态下恢复。
open状态下恢复数据文件可以减少数据库停用的时间，所以应该在open状态下恢复这些数据文件。
示例一：数据文件被误删除数据库关闭状态下删除非系统表空间数据文件。
启动数据库到mount状态。
脱机丢失的数据文件，alter database datafile n offline。
打开数据库，alter database open。
转储数据文件，restore datafile n。
使用recover datafile n 应用归档日志。
联机数据文件，alter database datafile n online。
--数据库关闭状态下删除非系统表空间数据文件。
1.[oracle@localhost ~]$ rm $ORACLE_BASE/product/10.2.0/oradatabak/example01.dbf;2.SQL> select file#,error from v$recover_file;3.FILE# ERROR4.---------- -----------------------------------------------------------------5. 5 FILE NOT FOUND6.SQL> select file#,name from v$datafile where file#=5;7.FILE# NAME8.---------- --------------------------------------------------------------------------------9. 5 /oracle/10g/oracle/product/10.2.0/oradatabak/example01.dbf10.--恢复数据文件11.RMAN> run {12.startup force mount;13.sql 'alter database datafile 5 offline';14.sql 'alter database open';15.restore datafile 5;16.recover datafile 5;17.sql 'alter database datafile 5 online';18.8> }示例二：数据文件所在磁盘出现损坏数据库关闭状态下删除非系统表空间数据文件。
Oracle归档及恢复步骤
配置备份和恢复操作：
archivelog模式下运行数据库
配置快速恢复区
指定保留策略：恢复时间段、冗余
db_recovery_file_dest_size：磁盘空间
db_recovery_file_dest：文件路径
快速恢复空间管理：
保留策略设置适合的最小值
rman备份
rman的report obsolete检查已备份的数据，然后delete obsolete删除
WHERE A>97 AND VERSIONS_STARTSCN IS NOT NULL ORDER BY VERSIONS_STARTSCN DESC;
SELECT CURRENT_SCN FROM v$DATABASE;
将SCN转换成时间戳：SCN_TO_TIMESTAMP(scn_number)
backup device type disk tag 'BACKUP20121018_002' as compressed backupset archivelog all not backed up;
恢复数据库到当前的时间点：
run {
restore database;
recover database;
rman执行出现如下错误
RMAN>delete obsolete;
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
RMAN>show all;
RMAN>show default device type;
backup device type disk tag '%TAG' tablespace 'USERS' include current controlfile;
解决Oracle数据库日志文件丢失恢复方案
解决Oracle数据库日志文件丢失恢复方案由于inactive日志文件组表示已经完成了检查点(dirty数据已经被写入数据文件)。
数据库本身不会发生数据库丢失，如果在这个时候相应的redo丢失/损坏，可以通过clear重建日志文件组恢复。
一.丢失inactive日志文件组的恢复：由于inactive日志文件组表示已经完成了检查点(dirty数据已经被写入数据文件)。
数据库本身不会发生数据库丢失，如果在这个时候相应的redo丢失/损坏，可以通过clear重建日志文件组恢复。
通过命令:alter database clear logfile group n如果数据库模式是archived的，则需要强制清除alter database clear unarchived logfile group n二.丢失active或current日志文件组的恢复：丢失情况分两种:一个是正常关闭数据库(如shutdown immediate)另一个是异常关闭数据库(如shutdown abort)1.在损失当前日志时，数据库是正常关闭状态。
由于shutdown immediate会执行全面的checkpoint，所以当前日志在实例恢复时可以不需要redo在Oracle 8i中我们完全可以通过alter database clear logfile group n来进行恢复.但是在Oracle 9i中，则可能无法对current的redo日志进行clear,需要通过recover database until cancel恢复后(必须要做的) 用resetlogs选项打开。
比如：alter database clear logfile group nrecover database until cancel;alter database open resetlogs;2.在损失当前日志时，数据库是异常关闭的：这种情况下，由于没有在执行全面检查点时，数据库就已经关闭了，那么Oracle在进行实例恢复的时候必须要求当前的日志，否则Oracle数据库将无法open.这样的情况下，我们通常需要从备份中恢复数据文件，通过应用归档日志进行向前推演。
Oracle数据库备份恢复实战
Oracle数据库备份恢复实战在管理和运维Oracle数据库时，数据库备份和恢复是一项至关重要的任务。
无论是因为误操作、硬件故障还是数据丢失，数据库备份和恢复能够帮助我们从灾难中恢复并保护我们的数据。
本文将介绍一些Oracle数据库备份恢复的实战方法，帮助读者了解如何有效地进行数据库备份和恢复。
1. 数据库备份方法1.1 物理备份物理备份是指对数据库的实际物理文件进行备份，备份的内容包括数据文件、控制文件和归档日志文件。
物理备份通常使用RMAN （Recovery Manager）工具来完成。
以下是进行物理备份的一般步骤：1) 配置RMAN环境并连接到目标数据库；2) 创建备份集并指定备份文件的存储位置；3) 开始备份任务，RMAN将自动备份数据文件、控制文件和归档日志文件；4) 备份完成后，可以使用RMAN验证备份文件的完整性。
1.2 逻辑备份逻辑备份是指对数据库中的逻辑结构（如表、视图等）进行备份，备份的内容是SQL语句或者导出文件。
逻辑备份通常使用expdp（数据泵）或者exp（传统导出）工具来完成。
以下是进行逻辑备份的一般步骤：1) 配置expdp或exp环境并连接到目标数据库；2) 创建备份目录并指定备份文件的存储位置；3) 开始备份任务，expdp或exp将自动生成备份文件；4) 备份完成后，可以使用impdp或imp工具验证备份文件的完整性。
2. 数据库恢复方法2.1 物理恢复物理恢复是指将备份的物理文件还原到数据库中，并应用归档日志文件来恢复丢失的数据。
以下是进行物理恢复的一般步骤：1) 将备份文件复制到目标数据库的恢复目录；2) 启动目标数据库并将其切换到恢复模式；3) 使用RMAN工具恢复数据文件、控制文件和归档日志文件；4) 应用归档日志文件以恢复丢失的数据；5) 完成恢复后，将数据库切换回正常运行模式。
2.2 逻辑恢复逻辑恢复是指使用逻辑备份文件来还原数据库中的逻辑结构和数据。
恢复归档日志文件的常用方法
同一个RUN块中允许同时出现多个SET ARCHIVELOG命令，也就是说可以通过在不同位置设置不同的归档路径的方式，将归档恢复到不同的目录，例如：
1. RMAN> RUN{
5. 5> RESTORE ARCHIVELOG SEQUENCE BETWEEN 21 AND 30;
6. 6> SET ARCHIVELOG DESTINATION TO 'F:\ORACLE\BACKUP\ARCLOG3';
7. 7> RESTORE ARCHIVELOG SEQUENCE BETWEEN 31 AND 40;
2. 2> SET ARCHIVELOG DESTINATION TO 'F:\ORACLE\BACKUP\ARCLOG1';
3. 3> RESTORE ARCHIVELOG SEQUENCE BETWEEN 15 AND 20;
4. 4> SET ARCHIVELOG DESTINATION TO 'F:\ORACLE\BACKUP\ARCLOG2';
8. 8> }
恢复归档文件非常灵活，可以全部恢复归档文件，也可以精确指定恢复哪些备份的归档文件，
RMAN>Restore archivelog all;
2. 恢复归档序号为20到30之间的归档文件：
RMAN> RESTORE ARCHIVELOG SEQUENCE BETWEEN 20 AND 30;
恢复归档日志文件的常用方法
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Oracle丢失归档日志文件的数据库恢复方法
丢失归档日志文件的数据库恢复方法，从一个不能正常打开的数据库(由于一个/多个数据库文件与其他文件不一致)中提取数据。
场景：一个磁盘损坏了并且丢失了一个数据库文件。
从一周前的热备转储数据文件，不幸的是丢失了几个归档日志文件。
但是有问题的数据文件包含了最重要的表，如何能够挽救数据呢?
每个DBA都知道这是有问题的，一定会丢失数据，因为某些事务丢失了，问题是会丢失多少数据?Oracle 使用硬线路位置并且由于存在完整性约束问题，因此不允许正常打开数据。
但是如果使用非常规的方法让Oracle删除其硬线路属性，那么应该能够提取尽可能多的数据。
而通常这会比损失全部数据要好很多。
详细过程通常如果仅仅丢失了堆表的索引，或者某些能够很容易重建的数据，那么最好的方法应该是删除表空间并重建这些对象然后重新输入。
但是如果丢失的数据文件包含了重要数据并且很难恢复，而且只有前一次的备份却又丢失了某些归档日志，那么用户可能希望能够尽可能多的从有问题的表空间恢复数据并且删除和重建表空间。
主要的步骤如下：
1. 对当前拥有的数据进行一个冷备;
2. 转储丢失的数据库文件备份并应用可以应用的日志;
3. 设置未文档化的初始化参数，其允许你在当前状态打开数据库;
4. 执行exp并提取全部可以从有问题的表空间提取的数据;
5. 从先前的冷备转储数据库;
6. 使毁坏的数据文件offline;
7. 执行exp并提取第4步没有提取的额外数据;
8. 在一次从冷备转储;
9. 删除有问题的表空间;
10. 重建有问题的表空间;
11. 使用第四步和第七步提取的数据重建数据;
使用案例描述：ORDTAB表空间的一个数据文件ordtab03.dbf毁坏，其包含很多ORDERS表的分区，数据文件热备于July 4，2004，July 4—至今的某些归档日志丢失。
第一步：备份数据库第一步的任务是冷备当前拥有的任何数据文件，在线重做日志，和控制文件。
如果丢失了一个/多个数据文件但是数据库仍然是open的，那么对每个剩余的数据文件进行热备并确保备份期间/之后的归档被安全保存。
创建备份后，在关闭数据库之前，备份一下控制文件：ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;然后打开备份的控制文件，删除第一个#之上的所有行，并删除“RECOVER DATABASE…”到文件结尾的全部。
第二步：转储丢失的数据库文件备份并应用日志;这一步应该转储备份，并应用日志到直到无法在前向滚动，此时如果尝试正常打开数据库，将会得到ORA-01589：must use RESETLOGS or NORESETLOGS option for database open错误。
如果尝试执行ALTER DATABASE OPEN RESETLOGS，将会得到ORA-01195错误：ORA-01195：online backup of file %s needs more recovery to be consistent.这里是Oracle使用其硬线路的位置。
由于转储的数据文件不能恢复到与其他文件一致的位置，所以可能存在中断的数据并且Oracle不允许正常打开数据库。
第三步：设置未文档化的实例参数并打开数据库在初始化参数文件中首先需要将job_queue_processes 设置为0，然后设置_allow_resetlogs_corruption=TRUE，更改该参数后，切换到保存新控制文件的目录，第一步创建的位置。
然后以SYSDBA连接并运行新的控制文件创建脚本。
此时数据库可以打开了。
SQL> SELECT COUNT(*) FROM OE.orders;
第四步：执行导出并提取数据在这一步可以很容易的看到那些表导出了全部的数据。
第五步：转储备份的数据库这一步，以及下面两步可选。
这三步结合在一起允许提取更多的数据，这一步从备份的数据库转储可以高效的撤销任何由于使用_allow_resetlogs_corruption参数造成的毁坏。
因此，这一步不会恢复任何丢失的数据文件。
第六步：使毁坏的数据文件offline ALTER DATABASE DATAFILE ’/u07/oradata/PRD/ordtab03.dbf’ OFFLINE;这一步得到数据库的完全一致性状态。
第七步：执行导出并提取额外的数据这一步可能能够提取从第四步不能提取的额外数据，如索引中的数据。
第八步：转储数据库这是最后一次转储数据库，这一步正式回滚数据库到使用隐含参数前那一刻，然后将数据库返回到正常状态，如果从第五步转储以来没有更新任何数据，可以跳过这一步。
第九步：删除有问题的表空间首先需要查看是否有完整性约束限制，使用以下查询：
SELECT CR.constraint_name
FROM dba_constraints CR, dba_constraints CP, dba_tables TP, dba_tables TR
WHERE CR.r_owner = CP.owner
AND CR.r_constraint_name = CP.constraint_name
AND CR.constraint_type = ’R’
AND CP.constraint_type IN (’P’, ’U’)
AND CP.table_name = TP.table_name
AND CP.owner = TP.owner
AND CR.table_name = TR.table_name
AND CR.owner = TR.owner
AND TR.tablespace_name <> ’ORDTAB’
AND TP.tablespace_name = ’ORDTAB’;
如果有约束，可能需要创建重建脚本。
如果使用export dump重建数据，约束可以从导出文件转储。
DROP TABLESPACE ordtab INCLUDING CONTENTS CASCADE CONSTRAINTS;
第十步：重建表空间
第十一步：重建数据执行导入。