测试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



现在看来,











相关文章
|
2天前
|
SQL Oracle 关系型数据库
oracle11g SAP测试机归档日志暴增排查(二)
oracle11g SAP测试机归档日志暴增排查(二)
13 1
|
2天前
|
Oracle 关系型数据库 Shell
oracle11g SAP测试机归档日志暴增排查(一)
oracle11g SAP测试机归档日志暴增排查(一)
11 1
|
27天前
|
存储 Oracle 关系型数据库
服务器数据恢复—RAID5上层SAP+oracle数据恢复案例
**服务器存储数据恢复环境:** 某品牌服务器存储中有一组由6块SAS硬盘组建的RAID5阵列,其中有1块硬盘作为热备盘使用。上层划分若干lun,存放Oracle数据库数据。 **服务器存储故障&分析:** 该RAID5阵列中一块硬盘出现故障离线,热备盘自动激活替换故障硬盘,热备盘同步数据的过程中该raid5阵列中又有一块硬盘出现故障,RAID5阵列瘫痪,上层LUN无法正常访问。 因为本案例中存储控制器的磁盘检查策略严格,一旦某些磁盘性能不稳定,该型号存储控制器就将该块磁盘识别为坏盘,并将该块磁盘踢出RAID。一旦RAID中掉线的盘数到超过RAID级别允许掉盘的最大数量,该RAID将不可用,
服务器数据恢复—RAID5上层SAP+oracle数据恢复案例
|
2月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库误truncate table的数据恢复案例
北京某国企客户Oracle 11g R2数据库误truncate table CM_CHECK_ITEM_HIS,表数据丢失,业务查询到该表时报错,数据库的备份不可用,无法查询表数据。 Oracle数据库执行Truncate命令的原理:在执行Truncate命令后ORACLE会在数据字典和Segment Header中更新表的Data Object ID,但不会修改实际数据部分的块。由于数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不一致,所以ORACLE服务进程在读取全表数据时不会读取到已经被TRUNCATE的记录,但是实际数据未被覆盖。
Oracle数据恢复—Oracle数据库误truncate table的数据恢复案例
|
2月前
|
人工智能 前端开发 测试技术
研究人员测试:GPT-4V生成网页超一半情况比人类效果更好
【2月更文挑战第17天】研究人员测试:GPT-4V生成网页超一半情况比人类效果更好
37 4
研究人员测试:GPT-4V生成网页超一半情况比人类效果更好
|
3月前
|
存储 Oracle 关系型数据库
【数据库数据恢复】Oracle数据库ASM磁盘组掉线的数据恢复案例
oracle数据库ASM磁盘组掉线,ASM实例不能挂载。数据库管理员尝试修复数据库,但是没有成功。
【数据库数据恢复】Oracle数据库ASM磁盘组掉线的数据恢复案例
|
5月前
|
运维 Oracle 关系型数据库
服务器数据恢复-raid5故障导致上层oracle数据库故障的数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由24块FC硬盘组建的raid5磁盘阵列,linux操作系统+ext3文件系统,服务器上层部署有oracle数据库。 服务器故障&检测: raid5阵列中有两块硬盘出现故障掉线,导致服务器上层卷无法挂载,oracle数据库无法正常使用。 通过管理后台查看服务器中硬盘的状态,显示有两块硬盘处于离线状态。
|
5月前
|
Oracle 关系型数据库 数据库
oracle数据恢复—服务器断电导致Oracle数据库报错的数据恢复案例
一台Windows server操作系统的服务器上部署Oracle数据库。 服务器意外断电导致oracle数据库报错,报错信息:“system01.dbf需要更多的恢复来保持一致性”。由于该oracle数据库并没有备份,仅有一些断断续续的归档日志,无法通过备份文件恢复oracle数据库的数据。管理员联系北亚企安数据恢复中心要求修复Oracle数据库。
oracle数据恢复—服务器断电导致Oracle数据库报错的数据恢复案例
|
7月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—断电导致Oracle数据库报错的数据恢复案例
北京某公司一台运行oracle数据库的服务器,机房意外断电导致该服务器重启,重启后发现oracle数据库报错。该Oracle数据库没有备份。
数据库数据恢复—断电导致Oracle数据库报错的数据恢复案例
|
7月前
|
存储 运维 Oracle
数据库数据恢复-oracle数据库无法打开的数据恢复案例
oracle数据库数据恢复环境: 一台服务器,底层由12块硬盘组成一组磁盘阵列,上层操作系统上运行oracle数据库。 oracle数据库故障: 数据库无法打开,报错:“数据库无法打开”,管理员第一时间将服务器关机,联系我们中心恢复数据。

推荐镜像

更多