测试8——oracle数据恢复的研究

简介: 写这篇文章,源于客户的数据库因为断电后无法启动,经过从网上查看,最后联系oracle得以解决,我后续会把此次客户问题及处理过程贴上。现在我打算根据warehouse老师的试验,走一遍,研究下具体的原理:http://www.itpub.net/thread-1065138-1-1.html。

写这篇文章,源于客户的数据库因为断电后无法启动,经过从网上查看,最后联系oracle得以解决,我后续会把此次客户问题及处理过程贴上。

现在我打算根据warehouse老师的试验,走一遍,研究下具体的原理:http://www.itpub.net/thread-1065138-1-1.html。

试验环境11.2.0.3


其实一句话就可以说明白:那就是数据文件的头上不仅包含了checkpoint_change#,更重要的是它包含了这个checkpoint_change#所在的logfile的sequence#,准确的说是rba。有了rba,在恢复时就能准确的知道到底需要哪个logfile(archivelog or redo)。

1、首先,查看控制文件(control file)中记录的checkpoint_change#,这个就是做checkpoint时的scn号:

SQL> set pages 80
SQL> set lines 1500
SQL> set numwidth 20
SQL> select resetlogs_change#, to_char(resetlogs_time, 'DD-MON-YYYY HH24:MI:SS') RSLTime,
    to_char(resetlogs_change#) RSLscn, to_char(prior_resetlogs_time, 'DD-MON-YYYY HH24:MI:SS') PRSLTime, to_char(prior_resetlogs_change#) PRSLscn,
    checkpoint_change# CKPscn, controlfile_change# CTLscn,
    to_char(controlfile_time, 'DD-MON-YYYY HH24:MI:SS') CTLTime,
    current_scn, controlfile_type from v$database;

这里我多查询了一些其他的信息,比如上一次open resetlogs的时间,当时的scn;当然,我们现在关注的还是 checkpoint_change# (此处给它取了个别名CKPSCN);注意controlfile_change#是指“Last SCN in backup control file; null if the control file is not a backup”,

current_scn是指:当前系统的scn号,如果系统是没有启动的,此值为0.

2、查看当前数据文件中记录的checkpoint_change#:

select status, to_char(checkpoint_change#), to_char(checkpoint_time, 'DD-MON-YYYY HH24:MI:SS') as
   checkpoint_time, count(*)
   from v$datafile_header
  group by status, checkpoint_change#, checkpoint_time
  order by status, checkpoint_change#, checkpoint_time;


当然,我可以可以查看每个数据文件对应的检查点scn(先从数据文件里查看):


然后是从控制文件里查看:


感觉,一般来说,应该不会出现控制文件和数据文件内checkpoint_change#不一致的情况。


3、查看控制文件(control file)里记录redo的checkpoint_change# :

select groups,current_group#,sequence#,checkpoint_change#,checkpoint_time,last_redo_change#
  from v$thread;


其中last_redo_change#是指redo log里,最后的scn值(实际上也是记录在控制文件里的)。


验证恢复过程:

--输入测试数据,验证备份恢复的过程,注意仔细观查插入到tt表中的dbms_flashback.get_system_change_number和v$log中的FIRST_CHANGE#之间的关系,我们通常理解备份恢复的原理是:事务对应的scn如果落在了哪个archivelog里,那么这个archivelog在恢复时就被用到,下面的大致试验过程也会验证这一点:

1、冷备份当前数据库

2、创建测试表:

SQL> conn scott/tiger
Connected.

SQL> desc tt   
 Name                     Null?    Type
 --------------------------------------- ----------------------------
 ID    NUMBER
 NAME             VARCHAR2(20)


SQL> conn scott/tiger
Connected.
SQL> insert into tt values(dbms_flashback.get_system_change_number,'a');
1 row created.

SQL> commit;
Commit complete.


SQL> select * from tt;
ID         NAME
   ----------      --------------------
  1111433      a


--datafile header上记录的rba信息,rba的意义在下面做了详细解释,这里只需知道FHRBA_SEQ表示redo的sequence#=13对应的是当前联机日志,而该sequence#被
记录在了datafile header上



select f.member, v.thread#, v.sequence#, v.group#, v.status,v.archived,v.first_change#
from v$log v, v$logfile f where v.group# = f.group#;



下面我们插入第二条记录:
SQL> insert into tt values(dbms_flashback.get_system_change_number,'b');
1 row created.


SQL> commit;
Commit complete.

SQL> select * from tt;

ID NAME
---------- --------------------
   1111433 a
   1133720 b



现在看来,











相关文章
|
10月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
11月前
|
存储 Oracle 关系型数据库
oracle数据恢复—oracle数据库执行错误truncate命令的数据恢复案例
oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下,oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况,例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。
|
Oracle 关系型数据库 MySQL
使用崖山YMP 迁移 Oracle/MySQL 至YashanDB 23.2 验证测试
这篇文章是作者尚雷关于使用崖山YMP迁移Oracle/MySQL至YashanDB 23.2的验证测试分享。介绍了YMP的产品信息,包括架构、版本支持等,还详细阐述了外置库部署、YMP部署、访问YMP、数据源管理、任务管理(创建任务、迁移配置、离线迁移、校验初始化、一致性校验)及MySQL迁移的全过程。
|
算法 数据挖掘 测试技术
犬类癌症检测(CANDiD)研究:使用独立测试集对1000多只犬进行基于高通量测序的多癌种早期检测"液体活检"血液测试的临床验证
这项研究首次在大规模独立测试集上验证了基于NGS的液体活检在犬类多癌种检测中的应用。该方法具有很高的特异性,可以作为一种新的无创癌症筛查和辅助诊断工具。通过早期发现癌症,有望改善犬类癌症的诊断和管理模式。
324 12
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
581 11
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
存储 Oracle 关系型数据库
数据库数据恢复—Oracle ASM磁盘组故障数据恢复案例
Oracle数据库数据恢复环境&故障: Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ,ASM实例不能mount。 Oracle数据库故障分析&恢复方案: 数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏,导致磁盘组无法挂载。
|
Oracle 关系型数据库 数据库
Oracle数据恢复—异常断电导致Oracle数据库数据丢失的数据恢复案例
Oracle数据库故障: 机房异常断电后,Oracle数据库启库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据库没有备份,归档日志不连续。用户方提供了Oracle数据库的在线文件,需要恢复zxfg用户的数据。 Oracle数据库恢复方案: 检测数据库故障;尝试挂起并修复数据库;解析数据文件。

推荐镜像

更多