当前位置: 开发笔记 > 数据库 > 正文

数据库open阶段关于检查点的校验

作者：缘来是你明 | 来源：互联网 | 2018-06-12 00:48

关于数据库open阶段时何时需要recovery： 1. oracle通过系统checkpoint scn，datafile checkpoint scn,start scn三者之间的比较来判断数据文件是否需要进行介质恢复. 2. 在redo 线程打开的情况下，即数据库open的情况下，stop scn会被设置为无穷大，当正常关闭时，stop scn等于datafile scn. 这里需要注意的是，stop scn是存放在controlfile中的，网上部分资料说是存在datafile header中，这个说法是错误的。 3. oracle在open之前是先判断是否进行介质恢复，然后再是判断是否进行instance recovery。 4. 关于4种scn的关系如下： system checkpoint scn — 存放在controlfile中 datafile checkpoint scn –存放在controlfile中 start scn —存放在datafile header中 stop scn —存放在controlfile中


system scn，datafile checkpoint scn，start scn，这3种scn用于判断数据文件是否需要进行介质恢复。这3个相等这不需要介质恢复。

如何这4个都相等，那么就不需要进行实例恢复。stop scn是用于判断是否进行实例恢复的。
5. 如果stop scn比其他的几个scn要大，那么就需要进行instance recover，需要进行扫描redo，实例恢复的起点是low cache rba，终点

是redo log的最末端。
自己的理解：

关于上述几点小鱼测试过程中并不如此，oracle恢复是分介质恢复和实例恢复，介质恢复是需要利用备份集和归档来恢复的，而实例恢复则是自动的利用在线日志进行的。

但是试想一种情况，shutdown abort数据库，然后删除掉所有的在线日志，而此时你重启这个数据库到mount状态，可以清晰的看见如下过程：

SQL> select checkpoint_change#,name from v$datafile;
CHECKPOINT_CHANGE# NAME

------------------ --------------------------------------------------

           1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SYSTEM01.DBF

           1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\UNDOTBS01.DB

                   F
           1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SYSAUX01.DBF

           1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\USERS01.DBF
SQL> select name,checkpoint_change#,checkpoint_count from v$datafile_header;
NAME                                     CHECKPOINT_CHANGE# CHECKPOINT_COUNT

---------------------------------------- ------------------ ----------------

G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SY            1303384              112

STEM01.DBF
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\UN            1303384               75

DOTBS01.DBF
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SY            1303384              112

SAUX01.DBF
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\US            1303384              111

ERS01.DBF
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#

------------------

           1303384
SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: 'G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SYSTEM01.DBF'
看出system的checkpoint scn、控制文件中记录的数据文件的checkpoint scn和数据文件头记录的start scn是一致,
但是由于这里删除了所有的redo,open resetlogs过程中会重置所有redo序号，然后重新生成redo，但是由于缺少之前的在线redo，导致实例恢复失败，也就提示需要进一步恢复file 1
那么来说：

这里小鱼想提出并不是所谓的实例恢复就不会报出所谓的错误的，数据库在open阶段能自动实现的就是实例恢复，介质恢复是需要dba去手动执行的，
但是如果实例恢复失败了，比如缺少在线redo，那么一样会出现无法打开数据库，并不意味着实例恢复好像不影响数据库的能否正常打开，这点需要特别明确。
这里小鱼看了好几个版本的数据库何时需要恢复，整理下想法：（eygle也曾经这么说过）

1 控制文件记录的checkpoint cnt也就是检查点计数和数据文件头记录的checkpoint cnt是否一致，并不是说数据文件头的启动scn和控制文件中记录的scn一致
控制文件记录的checkpoint cnt和数据文件头的checkpoint cnt这个可以用来区分数据文件和控制文件是否来自同一版本，而不是从备份中得来。
checkpoint scn检查点计数这个主要是用于区分数据文件和控制文件是否来自同一版本，这个非常重要。
有网友做过测试即使数据文件的启动scn和控制文件中记录的数据文件的checkpint scn不一致，同样可以打开数据库。（注意控制文件中也记录了数据文件的checkpoint scn）
2 数据文件头的启动scn和控制文件的结束scn是否一致，不一致则需要进行实例恢复，实例恢复是自动的，但是并不意味不重要，如果由于缺少日志恢复失败一样无法打开数据库。
puber上面的一个网友的测试说明：

SQL> startup mount

SQL> select file#,checkpoint_change#,last_change# from v$datafile;
     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

---------- ------------------ ------------

         1             2bc309      2bc309

         2             2bc309       2bc309

         3             2bc309       2bc309

         4             2bc309       2bc309

         5             2bc309       2bc309
SQL>

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

------------------

            2bc309

            2bc309

            2bc309

            2bc309

            2bc309
SQL>

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

------------------

            2bc309
SQL> host
RMAN> restore datafile 3

2> ;
........
RMAN> recover datafile 3;
........
RMAN> exit
恢复管理器完成。
Cocuments and SettingsRequieM>exit
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

---------- ------------------ ------------

         1             2bc309      2bc309

         2             2bc309       2bc309

         3             2bc309       2bc308

         4             2bc309       2bc309

         5             2bc309       2bc309
SQL>

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

------------------

            2bc309

            2bc309

            2bc308

            2bc309

            2bc309
SQL> alter database open;
在作上述步骤同时选取几个时间点，对控制文件和数据文件头作dump。过程太长，只贴一下结果。
1、shutdown以后；

2、restore以后；

3、recover以后；

4、open db以后。
结果如下：

时间点               控制文件                                                           数据文件头

                 chk cnt      chk scn                                           chk cnt    chk scn

1               302            2bc309                                           302        2bc309

2               302            2bc309                                           264        233c60 --看出这里restore时数据文件头的启动cnt和控制文件记录cnt不一致

3               303            2bc309                                           303        2bc308 --recover后利用归档和在线日志已经达到了cnt一致，但是checkpoint scn并不一致

4               304            2bc30a                                           304        2bc30a
结论：当恢复结束时，文件头内的chk scn比控制文件中的chk scn小1，但是chk cnt是完全相同的。
因此，数据库打开时比较的是检查点计数和数据文件头的启动scn和控制文件的数据文件的结束scn，而不是比较数据文件头启动scn和控制文件的checkpoint scn。
自己做了一个测试：

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>

SQL> startup mount;
rman>restore datafile 4;
alter session set events 'immediate trace name controlf level 12';
controlfile trace：

DUMP OF CONTROL FILES, Seq # 1497 = 0x5d9

 V10 STYLE FILE HEADER:

	Compatibility Vsn = 169870080=0xa200300

	Db ID=4166494968=0xf857aaf8, Db Name='ORA10G'

	Activation ID=0=0x0

	Control Seq=1497=0x5d9, File size=432=0x1b0

	File Number=0, Blksiz=16384, File Type=1 CONTROL

 Logical block number 1 (header block)
DATA FILE #4:

  (name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

 tablespace 4, index=4 krfil=4 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:316 scn: 0x0000.001818e7 05/28/2014 17:21:16  --这个checkpoint cnt 316就是控制文件记录的检查点计数，scn: 0x0000.001818e7是控制文件记录的数据文件的checkpoint scn

 Stop scn: 0x0000.001818e7 05/28/2014 17:21:16  -- 这个Stop scn: 0x0000.001818e7就是所谓的数据文件的stop scn，注意的是这个stop scn并不是在数据文件中，而是记录在控制文件中

 Creation Checkpointed at scn:  0x0000.00002997 08/26/2008 12:33:50

 thread:0 rba:(0x0.0.0)
alter session set events 'immediate trace name file_hdrs level 10';
file_hdrs trace:

DATA FILE #4:

  (name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

 tablespace 4, index=4 krfil=4 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:316 scn: 0x0000.001818e7 05/28/2014 17:21:16       这一段并不是数据文件头的信息，而只是控制文件中关于这个数据文件的信息，这个一定要特别注意，曾几何时这个困扰了小鱼好长时间

 Stop scn: 0x0000.001818e7 05/28/2014 17:21:16

 Creation Checkpointed at scn:  0x0000.00002997 08/26/2008 12:33:50

 thread:0 rba:(0x0.0.0)
这段file header才是数据文件头的信息

 V10 STYLE FILE HEADER:

	Compatibility Vsn = 169870080=0xa200300

	Db ID=4166494968=0xf857aaf8, Db Name='ORA10G'

	Activation ID=0=0x0

	Control Seq=1474=0x5c2, File size=12000=0x2ee0

	File Number=4, Blksiz=8192, File Type=3 DATA

Tablespace #4 - USERS  rel_fn:4

Creation   at   scn: 0x0000.00002997 08/26/2008 12:33:50

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0

 reset logs count:0x3285b2bc scn: 0x0000.00093009 reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 prev reset logs count:0x2790538b scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 recovered at 05/28/2014 17:25:05

 status:0x0 root dba:0x00000000 chkpt cnt: 314 ctl cnt:313 --首先这个chkpt cnt: 314就是数据文件头的检查点计数checkpoint cnt

begin-hot-backup file size: 0

Checkpointed at scn:  0x0000.001817ee 05/28/2014 17:20:29 --而这个checkpointed at scn:  0x0000.001817ee就是数据文件头的scn，也就是我们所谓的数据文件头的启动scn
SQL> select checkpoint_change#,last_change# from v$datafile;
CHECKPOINT_CHANGE# LAST_CHANGE#

------------------ ------------

           1579239      1579239

           1579239      1579239

           1579239      1579239

           1579239      1579239
V$datafile中Last_change#就是控制文件记录的数据文件的stop scn，v$datafile的checkpoint_change#是控制文件中记录的数据文件的checkpoint scn
SQL> select checkpoint_change#,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_COUNT

------------------ ----------------

           1579239              318

           1579239              108

           1579239              318

           1578990              314
V$datafile_header中的checkpoint_change#就是数据文件头的checkpoint scn（也叫做start scn），v$datafile_header中的checkpoint_count就是数据文件头的checkpoint count
而我们查询v$datafile和v$datafile_header视图发现查询结果确实和我们上面dump controlfile和datafile header结果一致
比如这里的v$datafile_header中的checkpoint_change#是1578990正好对应于dump datafile header trace文件中的Checkpointed at scn:  0x0000.001817ee，而v$datafile_headers的checkpoint_count 314也正好对应于chkpt cnt: 314 
SQL> recover datafile 4
SQL> select checkpoint_change#,last_change# from v$datafile;
CHECKPOINT_CHANGE# LAST_CHANGE#

------------------ ------------

           1579239      1579239

           1579239      1579239

           1579239      1579239

           1579239      1579238
SQL> select checkpoint_change#,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_COUNT

------------------ ----------------

           1579239              318

           1579239              108

           1579239              318

           1579238              317
 controlfile trace:

 DATA FILE #4:

  (name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

 tablespace 4, index=4 krfil=4 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:317 scn: 0x0000.001818e7 05/28/2014 17:21:16 --这里控制文件中记录checkpoint cnt变为了317，之前控制文件中记录的是316，这个checkpoint scn没有变化

 Stop scn: 0x0000.001818e6 05/28/2014 17:21:16 --Stop scn: 0x0000.001818e7变为了Stop scn: 0x0000.001818e6，这里stop scn减少了1

 Creation Checkpointed at scn:  0x0000.00002997 08/26/2008 12:33:50

 thread:0 rba:(0x0.0.0)
 datafile header trace:

  DATA FILE #4:

  (name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

 tablespace 4, index=4 krfil=4 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:317 scn: 0x0000.001818e7 05/28/2014 17:21:16

 Stop scn: 0x0000.001818e6 05/28/2014 17:21:16

 Creation Checkpointed at scn:  0x0000.00002997 08/26/2008 12:33:50

 thread:0 rba:(0x0.0.0)        
  aux_file is NOT DEFINED

 V10 STYLE FILE HEADER:

	Compatibility Vsn = 169870080=0xa200300

	Db ID=4166494968=0xf857aaf8, Db Name='ORA10G'

	Activation ID=0=0x0

	Control Seq=1499=0x5db, File size=12000=0x2ee0

	File Number=4, Blksiz=8192, File Type=3 DATA

Tablespace #4 - USERS  rel_fn:4

Creation   at   scn: 0x0000.00002997 08/26/2008 12:33:50

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0

 reset logs count:0x3285b2bc scn: 0x0000.00093009 reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 prev reset logs count:0x2790538b scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 recovered at 05/28/2014 17:47:28

 status:0x0 root dba:0x00000000 chkpt cnt: 317 ctl cnt:316  -- checkpoint cnt从314变为了317，此时datafile header中记录的checkpoint cnt已经和controlfile中记录的checkpoint cnt一致了

begin-hot-backup file size: 0

Checkpointed at scn:  0x0000.001818e6 05/28/2014 17:21:16 --datafile header的checkpoint scn（start scn）也变为了 0x0000.001818e6和控制文件中记录的stop scn也已经一致了
此时这个数据库已经完成了检测：controlfile中记录的checkpoint cnt和datafile header中记录的checkpoint cnt一致；controlfile中记录的stop scn和datafile header中记录的checkpoint scn(也叫start scn）一致。
但是正如这个过程还有很多需要注意的地方，比如这个controlfile中记录的scn是什么，和启动数据库有什么关系，对于recovery还是要等后面借助bbed对block、recovery有深刻的认知后才能慢慢解开面纱。
其实探索这些东西短期内可能并不会为我们带来什么收益，但是正如小鱼个人认为，如果想突破所谓的瓶颈（一般人都会遇见，至少小鱼现在算是遇见了），比如在某些方面比如优化、sql tuning、troubleshooting、recovery等方面的有深入学习的探索的毅力和行为，坚持下去可能瓶颈就慢慢突破了！

原文地址：数据库open阶段关于检查点的校验, 感谢原作者分享。

推荐阅读

database
SQL Server中按特定值优先排序列

本文介绍如何在SQL Server中对Name列进行排序，使特定值（如Default Deliverable Submission Notification）显示在结果集的顶部。 ... [详细]

蜡笔小新 2024-12-24 11:42:42
mysql
MySQL启动失败：覆盖原有安装后无法正常运行，求解决方案

在尝试用另一台电脑的MySQL文件替换本地D:\xampp\mysql目录后，MySQL服务无法启动。错误提示显示MySQL意外关闭，可能是由于端口冲突、依赖缺失、权限问题或崩溃等原因引起。 ... [详细]

蜡笔小新 2024-12-24 10:29:30
sql
iBatis.NET 循环迭代：深入解析 Iterate 标签

本文详细介绍了 iBatis.NET 中的 Iterate 元素，它用于遍历集合并重复生成每个项目的主体内容。通过该元素，可以实现类似于 foreach 的功能，尽管 iBatis.NET 并未直接提供 foreach 标签。 ... [详细]

蜡笔小新 2024-12-23 18:51:40
mysql
MySQL 客户端执行 NOW() 函数时出现 8 小时时差问题及解决方案

本文介绍了一种在 MySQL 客户端执行 NOW() 函数时出现时间偏差的问题，并详细描述了如何通过配置文件调整时区设置来解决该问题。演示场景中，假设当前北京时间为2023年2月17日19:31:37，而查询结果显示的时间比实际时间晚8小时。 ... [详细]

蜡笔小新 2024-12-23 18:15:08
sql
云计算的优势与应用场景

本文详细探讨了云计算为企业和个人带来的多种优势，包括成本节约、安全性提升、灵活性增强等。同时介绍了云计算的五大核心特点，并结合实际案例进行分析。 ... [详细]

蜡笔小新 2024-12-23 13:54:13
sql
Enhancing Paragraph Configuration in Create Note/Paragraph REST API

This pull request introduces the ability to provide comprehensive paragraph configurations directly within the Create Note and Create Paragraph REST endpoints, reducing the need for additional configuration calls. ... [详细]

蜡笔小新 2024-12-23 13:32:41
database
动态SQL存储过程的创建与示例

本文介绍如何在SQL Server中创建动态SQL存储过程，并提供详细的代码实例和解释。通过这种方式，可以更灵活地处理查询条件和参数。 ... [详细]

蜡笔小新 2024-12-23 13:21:47
mysql
CentOS 6.3 64位系统下搭建LAMP环境并安装PHP 5.5.7

在成功安装和测试MySQL及Apache之后，接下来的步骤是安装PHP。为了确保安全性和配置的一致性，建议在安装PHP前先停止MySQL和Apache服务，并将MySQL集成到PHP中。 ... [详细]

蜡笔小新 2024-12-23 13:08:12
insert
C#中SQL Server与Access批量数据插入性能对比

本文探讨了使用C#在SQL Server和Access数据库中批量插入多条数据的性能差异。通过具体代码示例，详细分析了两种数据库的执行效率，并提供了优化建议。 ... [详细]

蜡笔小新 2024-12-23 13:03:32
database
【48】在flask中使用ＳＱＬＡＬｃｈｅｍｙ连接ｓｑｌｉｔｅ数据库

方法：１　配置数据库basediros.path.abspath(os.path.dirname(__file__))　　＃获取当前文件的绝对路径appFlask(__name__ ... [详细]

蜡笔小新 2024-12-23 12:51:39
join
Netflix利用Druid实现高效实时数据分析

本文探讨了全球领先的在线娱乐公司Netflix如何通过采用Apache Druid，实现了高效的数据采集、处理和实时分析，从而显著提升了用户体验和业务决策的准确性。文章详细介绍了Netflix在系统架构、数据摄取、管理和查询方面的实践，并展示了Druid在大规模数据处理中的卓越性能。 ... [详细]

蜡笔小新 2024-12-23 11:10:01
insert
SQL Server: 提取字符串中的数值（包含0-9和‘.’）的自定义函数

本文介绍了一个SQL Server自定义函数，用于从字符串中提取仅包含数字和小数点的子串。该函数通过循环删除非数字字符来实现，并附带创建测试表、存储过程以演示其应用。 ... [详细]

蜡笔小新 2024-12-23 10:16:49
sql
使用 Spring Boot 和 Groovy 实现灵活的动态计算引擎

本文介绍了如何利用 Spring Boot 和 Groovy 构建一个灵活且可扩展的动态计算引擎，以满足钱包应用中类似余额宝功能的推广需求。我们将探讨不同的设计方案，并最终选择最适合的技术栈来实现这一目标。 ... [详细]

蜡笔小新 2024-12-23 09:44:54
join
如何查询拥有多个特定BookID的单个会员

本文介绍如何从包含多个记录的会员表中，筛选出同时拥有BookID为10和14的会员。通过SQL查询语句，可以有效地获取符合条件的MemberID。 ... [详细]

蜡笔小新 2024-12-22 19:46:31
sql
解决QT交叉编译时遇到的qatomic_i386.h:132错误

在进行QT交叉编译时，可能会遇到与目标架构不匹配的宏定义问题。例如，当为ARM或MIPS架构编译时，需要确保使用正确的宏（如QT_ARCH_ARM或QT_ARCH_MIPS），而不是默认的QT_ARCH_I386。本文将详细介绍如何正确配置编译环境以避免此类错误。 ... [详细]

蜡笔小新 2024-12-22 19:19:44

缘来是你明

这个家伙很懒，什么也没留下！

Tags | 热门标签

RankList | 热门文章