深入分析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; 
目录
相关文章
|
20天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
67 11
|
1月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
1月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
26天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
1月前
|
SQL Oracle 关系型数据库
Oracle数据库优化方法
【10月更文挑战第25天】Oracle数据库优化方法
56 7
|
1月前
|
存储 Java 关系型数据库
在Java开发中,数据库连接是应用与数据交互的关键环节。本文通过案例分析,深入探讨Java连接池的原理与最佳实践
在Java开发中,数据库连接是应用与数据交互的关键环节。本文通过案例分析,深入探讨Java连接池的原理与最佳实践,包括连接创建、分配、复用和释放等操作,并通过电商应用实例展示了如何选择合适的连接池库(如HikariCP)和配置参数,实现高效、稳定的数据库连接管理。
69 2
|
7天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
27 3
|
7天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
31 3
|
7天前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE &#39;log_%&#39;;`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
36 2

推荐镜像

更多