当前位置:Gxlcms > mysql > SCN与数据恢复关联

SCN与数据恢复关联

时间:2021-07-01 10:21:17 帮助过:24人阅读

一、各种SCN简介:如图,控制文件中有系统SCN号,针对每个数据文件还有文件SCN号、结束SCN号(如四个数据文件就有4个对应的文件SCN号、结束SCN号)数据文件头部

一、各种SCN简介:

180920251.jpg

如图,控制文件中有系统SCN号,针对每个数据文件还有文件SCN号、结束SCN号(如四个数据文件就有4个对应的文件SCN号、结束SCN号)

数据文件头部有开始SCN号。都是为了保证数据文件的一致性

正常情况下:系统SCN、文件SCN、文件头部的开始SCN应该一样,结束SCN为null

系统SCN:

SQL> select checkpoint_change# from v$database;


CHECKPOINT_CHANGE#

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

617242


文件SCN:

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


NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/jiagulun/system01.dbf 617242

/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 617242

/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 617242

/u01/app/oracle/oradata/jiagulun/users01.dbf 617242

/u01/app/oracle/oradata/jiagulun/example01.dbf 617242

/u01/app/oracle/oradata/jiagulun/data1_01_dbf 617242


结束SCN:

SQL> select name,last_change# from v$datafile;


NAME LAST_CHANGE#

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

/u01/app/oracle/oradata/jiagulun/system01.dbf

/u01/app/oracle/oradata/jiagulun/undotbs01.dbf

/u01/app/oracle/oradata/jiagulun/sysaux01.dbf

/u01/app/oracle/oradata/jiagulun/users01.dbf

/u01/app/oracle/oradata/jiagulun/example01.dbf

/u01/app/oracle/oradata/jiagulun/data1_01_dbf


数据文件头部开始SCN:

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


NAME CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/jiagulun/system01.dbf 617242

/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 617242

/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 617242

/u01/app/oracle/oradata/jiagulun/users01.dbf 617242

/u01/app/oracle/oradata/jiagulun/example01.dbf 617242

/u01/app/oracle/oradata/jiagulun/data1_01_dbf 617242


183112512.jpg

每一条日志都有SCN,每个日志组文件的头部有两个SCN first SCN和next SCN

first SCN:即这个文件组中第一条日志的SCN,等于上一组的next SCN。

next SCN:即这个文件组中最后一条日志的SCN,等于下一组的first SCN。

183534919.jpg



二、SCN如何保证数据库文件一致性(如何确认需要恢复)?

正常关闭:将所有buffer cache脏块写到磁盘,同时更新系统SCN、文件SCN,,数据头部开始SCN,同时结束SCN写上与系统SCN、文件SCN、数据头部开始SCN都一样的时间点(关闭时间)

非正常关闭:结束SCN为null,未正常写上。开启数据库时检测到结束SCN为null,则需要实例恢复。

数据文件丢失:例如当1号DBF文件丢失了,从备份中拷贝一个备份的1号DBF文件过来,此时文件头部的SCN比较旧,与控制文件系统SCN号对比,oracle则发现需要做恢复。则用跑日志将其SCN跑到与控制文件中文件SCN一样。

控制文件丢失:控制文件和数据文件都换成旧的,此时光对比控制文件中的SCN号和数据文件头部的SCN号还不能确认需不需要恢复,oracle还要对比on disk rba scn,如果on disk rba scn比控制文件中的SCN号和数据文件头部的SCN号都新,则要实例恢复。


用SCN号确认使用哪些日志组来恢复实例:

目前系统SCN号为617242:

SQL> select checkpoint_change# from v$database;


CHECKPOINT_CHANGE#

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

617242

此时日志组1first SCN为617242,则需要日志组1恢复即可;

184908561.jpg


试着经过两次日志组切换:

SQL> alter system switch logfile;


System altered.


SQL> alter system switch logfile;


System altered.


此时系统当前最新的文件SCN仍然是617242

SQL> select checkpoint_change# from v$database;


CHECKPOINT_CHANGE#

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

617242

那么这时候数据库实例崩溃使用哪些日志组恢复呢?

185506178.jpg

此时617242在日志组1,按照序列号8-10,日志组3是最新日志,此时需要日志组1、2、3恢复。

日志中active代表组中存在日志对应的脏块还没有写到磁盘中。

执行

SQL> alter system flush buffer_cache;


System altered.

后,日志组active变为inactive:

202439967.jpg

而此时控制文件中的SCN也更新为:

SQL> select checkpoint_change# from v$database;


CHECKPOINT_CHANGE#

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

628825

此时如果数据库实例非正常关闭,则需要日志组3来恢复。


三、总结:

控制文件中系统SCN,文件SCN等于最旧的active日志文件组的first SCN,实例恢复需要active和current日志组。

控制文件中的系统SCN,文件SCN用于确认数据恢复的所需要的重做日志文件组。

确认文件组后根据控制文件中的LRBA地址去跑日志跑到on disk rba地址。

CKPT进程只是将LRBA地址写到控制文件中,而控制文件中的系统SCN,文件SCN和数据头部SCN的更新是当一个日志组由active变为inactive时更新的,结束SCN则是关闭数据库时候更新的。

人气教程排行