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

写这篇文章,源于客户的数据库因为断电后无法启动,经过从网上查看,最后联系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

现在看来,

时间: 2024-09-17 00:12:34

测试8——oracle数据恢复的研究的相关文章

Oracle数据恢复顾问(Data Recovery Advisor)

Oracle数据恢复顾问用于当数据发生错误或故障时,进行自动收集数据故障信息,并生成恢复脚本,用于完成数据恢复.数据恢复顾问也可以主动检查故障. 在这种模式下,它可以在数据库进程发现数据损坏并发出错误之前进行潜在的检测并分析数据故障.数据故障可能非常严重. 例如,如果您当前的日志文件丢失,则无法启动你的数据库. 一些数据故障(如数据文件中的块损坏)不是灾难性的他们不会将数据库关闭或阻止您启动Oracle实例. 数据恢复顾问处理这两种情况:当您无法启动数据库时(因为某些情况)所需的数据库文件丢失,

关于Oracle数据恢复的两个临界点

有的网友对我之前写的一篇技术博文中的描述提出了疑问,http://blog.itpub.net/23718752/viewspace-1436965/ 其中的主要意思是:oracle中采用了undo+redo机制来作为数据恢复的基石,数据的恢复是通过前后台结合来实现的,在缓存级别,通过dbwr,能够把修改后的数据块刷入数据文件,这是一个异步的过程,不会因为发生数据变更就马上写入数据文件,同时存在log buffer,能够通过log buffer生成redo日志,最后通过lgwr把这部分变更刷到r

对Oracle Commit的研究

Oracle还是比较常用的,于是我研究了一下Oracle COMMIT,在这里拿出来和大家分享一下,希望对 大家有用.只有当SQL语句影响的所有行所在的最后一个块被读入DB BUFFER并且重做信息被写入REDO LOG BUFFER之后,用户才可以发出COMMIT,Oracle COMMIT触发LGRW,但并不强制立即DBWN来释放所有 相应的DB BUFFER块上的锁,但在随后的一段时间内DBWN还在写这条语句涉及的数据块的情形,表头部 的行锁,并不是在COMMIT一发出就马上释放,实际上要

oracle 数据库字符集研究 下篇

整理自:http://blog.itpub.net/519536/viewspace-615379/ 自从选用了AL32UTF8字符集做为生产数据库字符集之后,就一直奔走于"乱码"与"转码"之间. 如果想要搞清楚Oracle的字符系统,需要紧紧地抓住三个因素:一."客户终端字符集"二."NLS_LANG"环境变量三."数据库字符集" 如果"NLS_LANG"等于"数据库字符集&

oracle 数据库字符集研究 上篇

一.什么是Oracle字符集        Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系.ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储,处理,检索数据.它使数据库工具,错误消息,排序次序,日期,时间,货币,数字,和日历自动适应本地化语言和平台.   影响Oracle数据库字符集最重要的参数是NLS_LANG参数. 它的格式如下: NLS_LANG = language_territory.charset 它有三个组成部分(语言.地域和字符集),

Oracle数据恢复:kcbz_check_objd_typ_3 错误处理

在一次数据恢复之后,遇到了ORA-00600 kcbz_check_objd_typ_3错误,在此记录一下. 首先 kcbz_check_objd_typ_3 这个错误的含义是: 当Oracle在检查内存中的数据块时,发现数据块上的对象号是错误的,随之抛出kcbz_check_objd_typ_3 这个异常. 通常这个错误意味着存在着数据损坏. 在我们遇到的案例中,用户首先是由于存储损坏引入的问题,我们修复后出现这个错误,这个错误在后台执行AWR采样时触发,临时性的,我们可以禁用AWR采样,从而

记一次Oracle数据恢复过程_oracle

事情的起因是,一个应用升级后,某一个操作导致一个表的几个列全部被更新为同一值(忍不住又要唠叨测试的重要性).这样的错误居然出现在应用代码中,显然是重大的BUG.那个是罪魁祸首的SQL,UPDATE语句,其WHERE条件仅仅只有一个where 1=1. 系统的维护人员称是星期五出的错,发现出错是在星期天,也就是我恢复数据的日期,与声称的出错时间已经隔了将近2天.开始尝试用flashback query恢复数据,报ORA-01555错误,此路不通.维护人员说,星期五之前的RMAN备份已经被删除了(又

Oracle数据恢复: 50TB ASM crash例子

某客户50 TB的ASM发生故障,经过合力拯救,恢复正常,在此简单记录一下!实际上最后发现比我想象中的简单的多.如下是关于该故障的详细描述情况. –db alert log信息 Mon Jul  6 15:17:43 2015 Errors in file /oraclehome/admin/xxxx/udump/xxxx_ora_262606.trc: ORA-27063: number of bytes read/written is incorrect IBM AIX RISC Syste

oracle 数据库字符集研究 中篇

四.EXP/IMP 与 字符集 4.1 EXP/IMP    Export 和 Import 是一对读写Oracle数据的工具.Export 将 Oracle 数据库中的数据输出到操作系统文件中, Import 把这些文件中的数据读到Oracle 数据库中,由于使用exp/imp进行数据迁移时,数据从源数据库到目标数据库的过程中有四个环节涉及到字符集,如果这四个环节的字符集不一致,将会发生字符集转换. EXP     ____________ _________________ ________