深入分析Oracle数据库中的checkpoint_change#

简介: 本文地址:http://wallimn.iteye.com/blog/1199561,转载请保留。
本文地址:http://wallimn.iteye.com/blog/1199561,转载请保留。 

1、系统检查点(记录在控制文件中)  
SQL> select checkpoint_change# from v$database; 

CHECKPOINT_CHANGE# 
------------------ 
            539625 


2、数据文件检查点(记录在控制文件中)  
SQL> select file#,checkpoint_change#,last_change# from v$datafile; 

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE# 
---------- ------------------ ------------ 
         1             539625 
         2             539625 
         3             539625 
         4             539625 
         5             539625 

3、数据文件头检查点(记录在数据文件中)  
SQL> select file#,checkpoint_change# from v$datafile_header; 

     FILE# CHECKPOINT_CHANGE# 
---------- ------------------ 
         1             539625 
         2             539625 
         3             539625 
         4             539625 
         5             539625 

以上三个checkpoint_change#要一致(只读、脱机表空间除外),数据库才能正常打开。否则会需要进行一步的处理。正常关库时,会生成新的检查点,写入上述三个checkpoint_change#,同时数据文件中的last_change#也会记录下该检查点,也就是说三个checkpoint_change#与last_change#记录着同一个值。 
通过以下SQL可以证明 
SQL> shutdown immediate 
SQL> startup mount 
SQL> select file#,checkpoint_change#,last_change# from v$datafile; 

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE# 
---------- ------------------ ------------ 
         1             540270       540270 
         2             540270       540270 
         3             540270       540270 
         4             540270       540270 
         5             540270       540270 

SQL> select checkpoint_change# from v$database; 

CHECKPOINT_CHANGE# 
------------------ 
            540270 

SQL> select file#,checkpoint_change# from v$datafile_header; 

     FILE# CHECKPOINT_CHANGE# 
---------- ------------------ 
         1             540270 
         2             540270 
         3             540270 
         4             540270 
         5             540270 
         
数据库成功打开后,数据文件中的last_change#会被清空。正常关库时,再重新下最后的检查点。shutdown abort关库,这个值是空的(感兴趣可自行验证),此时数据库需要进行实例恢复(不需要用户干预),恢复后数据库才正常打开。 

checkpoint_change#、last_change#实际上全部来自于SCN,可以通过下面的语句验证: 
SQL>  select dbms_flashback.get_system_change_number from dual; 

GET_SYSTEM_CHANGE_NUMBER 
------------------------ 
                  540741 
使用查询系统SCN号的函数,可以发现checkpoint_change#与之是接近的。SCN有很多触发的条件,可能不会特别接近。 

下面举几个全备后恢复的例子,以及相关场景下checkpoint_change#的情况。  

问题1:数据文件损坏的恢复  
此时控制文件中记录的checkpoint_change#比数据文件头中记录的要大,数据库需要介质或者实例恢复。 
SQL> startup        
Database mounted. 
ORA-01113: file 1 needs media recovery 
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf' 
恢复一下,数据库就可以打开了。 
SQL> recover database; 
ORA-00279: change 539624 generated at 10/18/2011 08:27:31 needed for thread 1 
ORA-00289: suggestion : /u02/oradata/orcl/arc/1_5_764840495.dbf 
ORA-00280: change 539624 for thread 1 is in sequence #5 


Specify log: {<RET>=suggested | filename | AUTO | CANCEL} 
auto 
ORA-00279: change 540768 generated at 10/18/2011 12:17:11 needed for thread 1 
ORA-00289: suggestion : /u02/oradata/orcl/arc/1_6_764840495.dbf 
ORA-00280: change 540768 for thread 1 is in sequence #6 
ORA-00278: log file '/u02/oradata/orcl/arc/1_5_764840495.dbf' no longer needed for this recovery 


Log applied. 
Media recovery complete. 
SQL> alter database open; 

Database altered. 

问题2:控制文件损坏的恢复  
如果控制文件损坏,使用备份的控制文件是无法打开数据库的, 
SQL> startup 
Database mounted. 
ORA-01122: database file 1 failed verification check 
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf' 
ORA-01207: file is more recent than controlfile - old controlfile 
会提示数据文件与控制文件新,实际上就是控制文件中记录的checkpoint_change#比数据文件头中的checkpoint_change#要小,这种情况是不能打开数据库的。但数据可以启动到mount状态,此时可以用命令 
alter database backup controlfile to trace; 
生成一个控制文件的脚本,在udump目录中。使用该脚本可以重建控制文件,进行实例恢复后或打开数据库。 

如果没有备份的控制文件,数据库只能打开的nomount状态,不能获取重建控制文件的脚本,如果也没有备份过重建控制文件脚本,那就悲剧了。如果数据库不太复杂,可以手写一个。 

问题3:数据文件、控制文件全部损坏(当然都有备份,日志是好的)  
恢复数据文件、控制文件后,数据库仍然是无法打开的。 
SQL> startup 
Database mounted. 
ORA-00314: log 1 of thread 1, expected sequence#  doesn't match 
ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log' 
提示的意思也就是日志中的检查点比较控制文件中记录的大。 

SQL> select checkpoint_change# from v$datafile; 

CHECKPOINT_CHANGE# 
------------------ 
            539624 
            539624 
            539624 
            539624 
            539624 
            
SQL> select checkpoint_change# from v$datafile_header; 

CHECKPOINT_CHANGE# 
------------------ 
            539624 
            539624 
            539624 
            539624 
            539624 
SQL>  select checkpoint_change# from v$database; 

CHECKPOINT_CHANGE# 
------------------ 
            539624 
            
SQL> select * from v$log; 

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM 
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- 
         1          1          5   10485760          1 NO  CURRENT                 539571 18-OCT-11 
         2          1          4   10485760          1 YES INACTIVE                539116 18-OCT-11 
         3          1          3   10485760          1 YES INACTIVE                537456 18-OCT-11 

此时可以使用下面的命令恢复数据库 
SQL> recover database using backup controlfile; 

恢复成功后,v$database中记录的checkpoint_change#并未发生变化。 
SQL> select checkpoint_change# from v$datafile; 

CHECKPOINT_CHANGE# 
------------------ 
            602574 
            602574 
            602574 
            602574 
            602574 

SQL> select checkpoint_change# from v$datafile_header; 

CHECKPOINT_CHANGE# 
------------------ 
            602574 
            602574 
            602574 
            602574 
            602574 

SQL>  select checkpoint_change# from v$database; 

CHECKPOINT_CHANGE# 
------------------ 
            539624 

因为不一致,所以数据库仍然打不开: 
SQL> alter database open; 
alter database open 

ERROR at line 1: 
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open 


SQL> alter database open resetlogs; 
alter database open resetlogs 

ERROR at line 1: 
ORA-01113: file 1 needs media recovery 
ORA-01110: data file 1: '/u02/oradata/orcl/system01.dbf' 

此时的情况类似于问题2,解决办法也相同。shutdown abort,startup nomount,重建控制文件,recover database,alter database open; 

问题4、数据库冷备过,新建的表空间的数据文件损坏,且无备份。  
这种情况的处理办法: 
restore备份的数据文件; 
startup; 
会提示无法定位数据文件,数据库无法打开, 
alter database create datafile '提示的无法定位的数据文件名称';--此时查看checkpoint_change#,会发现新建的与其它的不相同。 
set autorecovery on 
recover database; 
alter database open; 
目录
相关文章
|
22天前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
10天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—异常断电导致Oracle数据库数据丢失的数据恢复案例
Oracle数据库故障: 机房异常断电后,Oracle数据库启库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据库没有备份,归档日志不连续。用户方提供了Oracle数据库的在线文件,需要恢复zxfg用户的数据。 Oracle数据库恢复方案: 检测数据库故障;尝试挂起并修复数据库;解析数据文件。
|
10天前
|
Oracle NoSQL 关系型数据库
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
37 2
|
29天前
|
Oracle 安全 关系型数据库
Oracle数据恢复—Oracle数据库误删除的数据恢复方法探讨
删除Oracle数据库数据一般有以下2种方式:delete、drop或truncate。下面针对这2种删除oracle数据库数据的方式探讨一下oracle数据库数据恢复方法(不考虑全库备份和利用归档日志)。
|
14天前
|
SQL Oracle 关系型数据库
Oracle数据库管理:从入门到精通
表(Table):表是Oracle数据库中存储数据的基本结构单元,由行(Row)和列(Column)组成。每行代表一个记录,每列代表一个字段。 SQL(Structured Query Language):SQL是Oracle数据库的核心语言,用于与数据库交互,执行查询、插入、更新和删除等操作。 数据库实例与数据库:在Oracle中,数据库实例是一组后台进程和内存结构,用于管理数据库并提供服务。而数据库则是数据的物理存储,包括数据文件、控制文件、联机日志和参数文件等。
38 0
|
23天前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
25天前
|
存储 SQL 关系型数据库
使用MySQL Workbench进行数据库备份
【9月更文挑战第13天】以下是使用MySQL Workbench进行数据库备份的步骤:启动软件后,通过“Database”菜单中的“管理连接”选项配置并选择要备份的数据库。随后,选择“数据导出”,确认导出的数据库及格式(推荐SQL格式),设置存储路径,点击“开始导出”。完成后,可在指定路径找到备份文件,建议定期备份并存储于安全位置。
182 11
|
20天前
|
存储 SQL 关系型数据库
MySQL的安装&数据库的简单操作
本文介绍了数据库的基本概念及MySQL的安装配置。首先解释了数据库、数据库管理系统和SQL的概念,接着详细描述了MySQL的安装步骤及其全局配置文件my.ini的调整方法。文章还介绍了如何启动MySQL服务,包括配置环境变量和使用命令行的方法。最后,详细说明了数据库的各种操作,如创建、选择和删除数据库的SQL语句,并提供了实际操作示例。
59 13
MySQL的安装&数据库的简单操作
|
26天前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
114 14
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
1天前
|
SQL 关系型数据库 MySQL
数据库:MYSQL参数max_allowed_packet 介绍
数据库:MYSQL参数max_allowed_packet 介绍
10 2

推荐镜像

更多