oracle checkponit_change,深入分析Oracle数据库中的checkpoint_change

当前位置:我的异常网» 数据库 » 深入分析Oracle数据库中的checkpoint_change

深入分析Oracle数据库中的checkpoint_change

www.myexceptions.net  网友分享于：2013-07-23  浏览：10次

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

本文地址：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: {=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;

文章评论