oracle中scn与实例恢复

原创 _ All China Database Union 2023-06-06

746

从 12.2.0.1 开始，兼容性设置为 12.2，限制为 2^63，对于低于 12.2.0.1 的版本，限制为 2^48 或 281 万亿个 SCN 值。

SCN的取值算法为：SCN=(SCN_WRAP×4294967296)+SCN_BASE

在Oracle 11.2.0.2之后是默认每秒允许增长32768，这个值跟新增的隐含参数_max_reasonable_scn_rate

在任何时间点，Oracle 数据库都会根据自 1988 年以来经过的秒数乘以 16,384（16K/秒）来计算数据库可以使用的 SCN 数量的“不超过”限制。这称为数据库的当前最大 SCN 限制。
这样做可确保 Oracle 数据库随着时间的推移对 SCN 进行配给，允许使用 12.2.0.1 或更低版本的任何 Oracle 数据库进行超过 500 年的数据处理。从 12.2.0.1 开始，兼容性设置为 12.2，
即使 SCN 以 96K/秒的速率消耗，Oracle 数据库也将允许近 300 万年的数据处理。

数据库scn主要存在于控制文件、数据文件头、数据文件、redo文件

一、控制文件文件中的scn

SQL> alter session set events 'immediate trace name controlf level 4';

Session altered.

1、数据库条目

也就是查询v$database视图显示的部分

***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
12/24/2022 05:54:43
DB Name "CY"
Database flags = 0x00404001 0x00001200 0x00000080
Controlfile Creation Timestamp 12/24/2022 05:54:43
Incmplt recovery scn: 0x0000000000000000
Resetlogs scn: 0x00000000001d4fd1 Resetlogs Timestamp 12/24/2022 05:54:46
Prior resetlogs scn: 0x0000000000000001 Prior resetlogs Timestamp 04/17/2019 00:55:59
Redo Version: compatible=0x13000000
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x000000000029ab64

Incmplt recovery scn: 这个SCN表示不完全恢复（Incomplete Recovery）的SCN。如果某个点数据库进行了不完全恢复，这个SCN就表示恢复操作停止时的点。如果为0x0000000000000000，说明没有进行不完全恢复。
Resetlogs scn: 这个SCN表示重置日志（Resetlogs）操作的SCN。当数据库关闭后，你可以使用RESETLOGS选项打开，此时会创建一个新的重做日志文件。Resetlogs SCN表示最近一次resetlogs操作时的SCN值。
Prior resetlogs scn: 这个SCN表示上一次重置日志（Prior Resetlogs）操作的SCN。这可以帮助跟踪回退点，以了解在上一次重置日志操作之前的数据库更改。
Database checkpoint: 这个SCN表示数据库检查点（Database Checkpoint）的SCN。检查点SCN是一个关键的数据库属性，用于保持数据的一致性和完整性。一个检查点事件表示所有在检查点SCN之前进行的更改已经
写入到磁盘中的数据文件。检查点SCN有助于确保在数据库恢复和启动过程中的数据完整性

SQL> select RESETLOGS_CHANGE#,PRIOR_RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$database;

RESETLOGS_CHANGE# PRIOR_RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
----------------- ----------------------- ------------------
1920977 1 2730852

CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:33
low cache rba:(0x1c.12315.0) on disk rba:(0x1c.12351.0)
on disk scn: 0x0000000000b3f1fa 06/06/2023 16:32:13
resetlogs scn: 0x0000000000812a1e 04/13/2023 10:46:07
heartbeat: 1138766329 mount id: 1666573357
THREAD #2 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000000000000000 01/01/1988 00:00:00
resetlogs scn: 0x0000000000000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #3 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000000000000000 01/01/1988 00:00:00
resetlogs scn: 0x0000000000000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0

low cache rba（Low Cache Redo Buffer Address）表示当前数据库缓冲区中最低的重做日志位置。它用于表示最旧的未提交到磁盘的重做日志记录。重做日志在Oracle数据库中至关重要，
因为它们用于记录数据库中已发生的所有事务。这些信息在进行实例恢复和其他管理操作时非常有用。
当数据库进行检查点操作或需要将更改写入磁盘时，low cache rba就派上了用场。它帮助确保将记录新事务更改之前的重做日志信息提交到磁盘。这样可以确保数据库的完整性和一致性，
以防发生崩溃或由于其它原因导致的数据丢失。简而言之，low cache rba表示那些还未强制写入磁盘的重做日志记录的最旧位置，有助于确保在发生故障时成功进行实例恢复。
on disk rba：这表示已写入磁盘的重做日志（Redo Log）中的Redo Buffer Address。
on disk scn：这个SCN是最后一个写入磁盘的重做日志记录相关联的SCN。它反映了写入磁盘的最近一次重做日志记录的时间点。也就是当前系统最新RBA对应的SCN，由CKPT进程每3秒更新一次。
如果数据库异常宕机，那么CRASH RECOVER时服务器进程至少要应用到该SCN为止

SQL> select CPODS from x$kcccp where rownum<2;

CPODS
----------------------------------------
2788986

resetlogs scn：这个SCN表示resetlogs操作发生时的SCN值。当数据库关闭之后，使用RESETLOGS选项打开时，会创建一个新的重做日志文件。此SCN表示该操作的时间点。
heartbeat：这个值表示各个线程中心跳的计数。它通常用于监视和诊断。

2、数据文件条目

查询v$database

***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 7,
last-recid= 4, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 11, numrecs = 100)
DATA FILE #1:
name #9: /u01/app/oracle/oradata/CY/datafile/o1_mf_system_ktd8k9ol_.dbf
creation size=0 block size=8192 status=0xe flg=0x1 head=9 tail=9 dup=1
pdb_id 0, tablespace 0, index=2 krfil=1 prev_file_in_ts=0 prev_file_in_pdb=0
unrecoverable scn: 0x0000000000000000 01/01/1988 00:00:00
Checkpoint cnt:85 scn: 0x000000000029ab64 06/04/2023 14:28:26
Stop scn: 0xffffffffffffffff 05/23/2023 05:20:52
Creation Checkpointed at scn: 0x0000000000000009 04/17/2019 00:56:09

unrecoverable scn：这个SCN表示不可恢复的操作发生时的系统更改编号。不可恢复的操作可能导致数据丢失，因此通常需要对数据库进行备份和恢复。在示例中，它显示为0，这是因为还没有发生不可恢复的更改。
Checkpoint cnt：此值是已发生的检查点（Checkpoint）数量。检查点是数据库将修改的数据块从缓冲区写入磁盘的一个特定时间点。
scn（在Checkpoint cnt后）：这个SCN是与上述检查点计数关联的系统更改编号。它表示了在数据库中发生检查点的时间点。在这个例子中，SCN值为0x000000000029ab64，表示在06/04/2023 14:28:26发生了一个检查点。一般会和数据库scn保持一致。
Stop scn：这个SCN表示数据文件停用（脱机）前的系统更改编号或停止数据库时的SCN。在这个例子中，它的值为0xffffffffffffffff表示在线，正常关闭时和V$DATAFILE.CHECKPOINT_CHANGE#值相同，异常关闭时为0xffffffffffffffff。
Creation Checkpointed at scn：这个SCN对应数据文件创建时的检查点。在这个例子中，SCN值为0x0000000000000009，表示数据文件的创建时间为04/17/2019 00:56:09。如果数据文件被误删除，在重新创建该数据文件时，Oracle会根据该SCN值定位需要应用的第一个归档日志
thread 和 rba（这里没有SCN，但与检查点相关）：这代表了与数据文件关联的线程和 Redo Buffer Address。这些值可帮助识别数据文件所属的线程和最近重做操作的位置。

3、redo条目

查询v$log

LOG FILE #1:
name #5: /u01/app/oracle/oradata/CY/onlinelog/o1_mf_1_ktd8x63m_.log
name #6: /u01/app/oracle/fast_recovery_area/CY/onlinelog/o1_mf_1_ktd8x731_.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x64000 seq: 0x0000001c hws: 0x2 bsz: 512 nab: 0x58e76 flg: 0x1 dup: 2
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000000000280644
Low scn: 0x000000000028b825 05/28/2023 15:59:20
Next scn: 0x000000000029ab64 06/04/2023 14:28:26

Prev scn: 0x0000000000280644 - 表示前一个SCN。用于记录当前操作日志之前的最后一个操作的序列号。这有助于Oracle数据库正确地对各种数据操作进行排序并确保一致性。
Low scn: 0x000000000028b825 05/28/2023 15:59:20 - 表示日志中记录的操作的最低序号（最早的操作），以及该SCN对应的时间戳。这有助于了解日志中涵盖的操作信息范围，并在执行恢复任务时，确定需要应用的日志文件的范围。
Next scn: 0x000000000029ab64 06/04/2023 14:28:26 - 表示当前操作日志之后的第一个操作的序列号，以及该SCN对应的时间戳。这有助于了解日志中涵盖的操作信息范围，并在执行恢复任务时，确定需要应用的日志文件的范围。

二、数据文件记录的scn

SQL> select dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) blk#,t1.* from t1;

FILE# BLK# NAME
---------- ---------- ----------------------------------------
1 116185 aaa

BBED> map /v
File: /u01/app/oracle/oradata/CY/system01.dbf (7)
Block: 5390 Dba:0x01c0150e
------------------------------------------------------------
KTB Data Block (Table/Cluster)

struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub2 wrp2_kcbh @2
ub4 rdba_kcbh @4
ub4 bas_kcbh @8
ub2 wrp_kcbh @12
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18

BBED> p kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0x06
ub1 frmt_kcbh @1 0xa2
ub2 wrp2_kcbh @2 0x0000
ub4 rdba_kcbh @4 0x01c0150e
ub4 bas_kcbh @8 0x008baaf6
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x01
ub1 flg_kcbh @15 0x06 (KCBHFDLC, KCBHFCKV)
ub2 chkval_kcbh @16 0x4ce8
ub2 spare3_kcbh @18 0x0000

SQL> alter system dump datafile 1 block 116185;

System altered.

SQL> select * from v$diag_info;

1、数据文件scn

buffer tsn: 0 rdba: 0x0041fc19 (1/130073)
scn: 0xb3e809 seq: 0x05 flg: 0x02 tail: 0xe8090605
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1

scn: 0xb3e809表示该数据块在SCN为0xb3e809（也可以写作1194089，这是十进制表示法）的时间点上发生了更改。这意味着，在这个SCN之后，数据块可能已经被修改，因此这是一个重要的标识符，用于审计、跟踪或恢复相关的操作。

2、Scn/Fsc

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0017.000.00000abd 0x0080cafa.008f.11 --U- 1 fsc 0x0000.00b3e809
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x0041fc19

对于ITL 0x01：Scn为 fsc 0x0000.00b3e809，表示此事务槽最后一次修改时的SCN（十六进制表示）为0xb3e809，这意味着在这个SCN之后（十进制：1194089），数据块可能已经被修改。
对于ITL 0x02：Scn为 fsc 0x0000.00000000，表示此事务槽的SCN为0（十六进制：0x00000000），这意味着此事务槽没有发生更改，或数据块尚未分配给该事务槽。
fsc：Flashback SCN（Flashback跳转的SCN）。FSC是数据库提供的一个特性，它用于在Oracle Flashback Query中为给定时间点确定相应的SCN。Flashback Query允许用户查询或恢复数据库的历史数据，以便于在特定时间点查看数据库内容。

3、csc

Block header dump: 0x0041fc19
Object id on Block? Y
seg/obj: 0x12feb csc: 0x0000000000b3e807 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Cleanout SCN是一个重要的内部属性，用于确保多个数据库会话之间的一致性。当一份数据需要在多个会话间共享时，Oracle数据库使用清理SCN来确保返回一致性的数据。一般上，如果一个会话正在访问或修改数据，另一个会话可能在不影响第一个会话的情况下访问旧数据。这种一致性是通过比较链接表格和索引的Cleanout SCN和会话状态决定的。具体来说，这个数据块的Cleanout SCN为0xb3e807。这意味着在这个SCN之后(十进制：1193985)，可能会对该数据块进行清理（Cleanout）操作，以便在多个会话之间做到一致性。这个值通常在事务提交后更新，并在随后的会话读取时检查是否需要清理已经提交的事物产生的项。如果需要清理，Oracle会在开始读取数据前做相应处理。

三、redo中的scn

SQL> alter session set events 'immediate trace name redohdr level 3';

Session altered.

LOG FILE #1:
name #5: /u01/app/oracle/oradata/CY/onlinelog/o1_mf_1_ktd8x63m_.log
name #6: /u01/app/oracle/fast_recovery_area/CY/onlinelog/o1_mf_1_ktd8x731_.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x64000 seq: 0x0000001c hws: 0x2 bsz: 512 nab: 0x58e76 flg: 0x1 dup: 2
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000000000280644
Low scn: 0x000000000028b825 05/28/2023 15:59:20
Next scn: 0x000000000029ab64 06/04/2023 14:28:26
FILE HEADER:
Compatibility Vsn = 318767104=0x13000000
Db ID=3276910691=0xc351b063, Db Name='CY'
Activation ID=3276873571=0xc3511f63
Control Seq=4361=0x1109, File size=409600=0x64000
File Number=1, Blksiz=512, File Type=2 LOG
Format ID is 18
redo log key is 2695979b43bcfdbc34fecf1820fff874
redo log key flag is 15
descrip:"T 0001, S 0000000028, SCN 0x000000000028b825-0x000000000029ab64"
thread: 1 nab: 0x58e76 seq: 0x0000001c hws: 0x2 eot: 0 dis: 0
reset logs count: 0x4302d126
Reset Logs scn: 0x00000000001d4fd1
Low scn: 0x000000000028b825 05/28/2023 15:59:20
Next scn: 0x000000000029ab64 06/04/2023 14:28:26
Enabled scn: 0x00000000001d4fd1 12/24/2022 05:54:46
Thread closed scn: 0x000000000028b825 05/28/2023 15:59:20
Disk cksum: 0x577a Calc cksum: 0x0
Terminal Recovery Stop scn: 0x0000000000000000
Terminal Recovery Stamp 01/01/1988 00:00:00
Most recent redo scn: 0x0000000000000000
Largest LWN: 4133 blocks
Real Next scn: 0xffffffffffffffff
Previous Resetlogs scn: 0x0000000000000001
Miscellaneous flags: 0x10800000

Prev scn: 0x0000000000280644 - 前一个SCN，记录当前操作日志之前的最后一个操作的序列号。用于正确对数据操作进行排序并确保数据库一致性。
Low scn: 0x000000000028b825 05/28/2023 15:59:20 - 最低SCN，表示日志中记录的最早的操作序列号，以及该SCN对应的时间戳。有助于了解日志涵盖的操作信息范围，并在执行恢复任务时确定需要应用的日志文件范围。
Next scn: 0x000000000029ab64 06/04/2023 14:28:26 - 下一个SCN，表示当前操作日志之后的第一个操作序列号，以及该SCN对应的时间戳。有助于了解日志涵盖的操作信息范围，并在执行恢复任务时确定需要应用的日志文件范围。
“SCN 0x000000000028b825-0x000000000029ab64”：描述了日志中涵盖的操作序列号范围，从0x000000000028b825至0x000000000029ab64。有助于确定日志文件涵盖的操作范围。
Low scn: 0x000000000028b825 05/28/2023 15:59:20：最低SCN，表示日志中记录的最早操作序列号以及相应的时间戳。它有助于了解日志涵盖的操作信息范围。
Next scn: 0x000000000029ab64 06/04/2023 14:28:26：下一个SCN，表示当前操作日志之后的第一个操作序列号以及相应的时间戳。它有助于了解日志涵盖的操作信息范围。
Enabled scn: 0x00000000001d4fd1 12/24/2022 05:54:46：启用SCN，表示启用此线程的SCN及时间戳。这有助于了解历史线程中的启用时间和状态。
Thread closed scn: 0x000000000028b825 05/28/2023 15:59:20：线程关闭SCN，用于标记线程结束操作的SCN及时间戳。这有助于了解何时结束了线程活动。
Terminal Recovery Stop scn: 0x0000000000000000：终端恢复停止SCN，表示检测到状态文件恢复结束的SCN。值为0，意味着没有停止恢复操作。
Most recent redo scn: 0x0000000000000000：最近的重做SCN。表示当前处理的最新操作的SCN。值为0，表示当前没有最新操作正在处理。
Real Next scn: 0xffffffffffffffff：真实下一个SCN。表示在线日志所记录的潜在下一个操作序列号。
Previous Resetlogs scn: 0x0000000000000001：前一个重置日志SCN，记录前一次重置日志时的SCN。有助于追踪日志重置历史以及找到错误时进行故障诊断。

四、总结

当Oracle启动时，它首先会比较数据文件头中的CHECKPOINT_CHANGE#（记录在vdatafile）与Datafile Header中的CHECKPOINT_CHANGE#(vdatafile_header)。如果这两个值匹配，说明数据文件是一致的，并且可以继续进行下一步比较。

如果启动过程中发现数据文件头中的CHECKPOINT_CHANGE#与控制文件的CHECKPOINT_CHANGE#不一致，这通常意味着数据文件没有在上次检查点或实例恢复时完成同步，也预示着数据库存在数据一致性问题。

这种情况下，Oracle数据库会尝试进行实例恢复。在实例恢复的过程中，Oracle会使用重做日志（Redo Log）以便将数据文件恢复至一致状态。实例恢复包括两个阶段：Rolling Forward阶段和Rolling Back阶段。首先，在Rolling Forward阶段，数据库将重做日志的事务重新应用到数据文件，使数据文件达到一个一致的且业务可用的状态；接着，在Rolling Back阶段，任何没有提交的事务都将被回滚。

如果实例恢复失败，可能需要数据库管理员手动执行介质恢复或进行其他干预。在介质恢复过程中，需要使用有效备份文件以及对应的归档日志文件（如果启用了归档），以恢复损坏的数据文件。

接下来，Oracle会比较控制文件中的数据文件的Stop SCN与数据文件头中的LAST_CHANGE#。如果这两个值匹配，表示所有数据块已经提交，数据库不需要进行实例恢复，可以直接打开。

实例恢复分为两个阶段，即Rolling Forward阶段与Rolling Back阶段。

实例恢复阶段的Rolling Forward过程从最后一个检查点的SCN（System Change Number）开始。最后一个检查点的SCN是记录在数据文件头部和控制文件中的CHECKPOINT_CHANGE#。重做日志将从最后一个检查点的SCN开始应用，重演数据库之后的所有事务，直到最后一个可用的重做日志记录。实际上是从重做日志文件（Redo Log）中的LOW SCN（即最低SCN）开始的。这个LOW SCN通常与上次检查点的CHECKPOINT_CHANGE#相关联，但在分布式系统或其他特殊情况下，LOW SCN可能是其他数据文件的更早SCN。所以实例恢复是从low scn开始直至所有的redolog全部应用完毕。

Rolling Back阶段：在Rolling Forward阶段之后，数据库将处于一个一致的且业务可用的状态。此时，仍然需要处理在宕机时尚未提交的事务。Rolling Back阶段将从事务的起点（即事务开始的SCN）开始回滚这些未提交的事务，直到这些事务被完全回滚，以确保数据库的一致性。

实例恢复的起点是最后一次检查点SCN（Rolling Forward阶段），终点是所有重做日志应用完毕（Rolling Forward阶段结束），且未提交的事务被完全回滚（Rolling Back阶段结束）。在实例恢复完成后，数据库将处于一致且业务可用的状态，可以正常运行。

其实第一次比较的是checkpoint cnt值而不是checkpoint值，之后才会比较checkpoint值。

墨力计划

最后修改时间：2023-06-07 10:08:38

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者