一. SCN 说明之前也整理过几遍Oracle SCN的文章,如下:Oracle DB 服务器系统时间修改问题 与SCN 关系的深入研究 http://www.linuxidc.com/Linux/2011-09/42704.htmOracle Blockscn/commit scn/cleanout scn 说明 http://www.linuxidc.com/Linux/2011-08/40285.htmRedoLogCheckpoint 和 SCN关系 http://www.linuxidc.com/Linux/2011-07/38002.htm
这里在稍微小总结一下。我们可以使用如下SQL 查看Oracle 的SCN:SQL> select CURRENT_SCN from v$database;CURRENT_SCN-----------3713849上述结果返回的是一串数字。但实际上,Oracle 在内部并不是用数字来存储SCN的。在Oracle内部,SCN分为两部分存储,分别称之为scn wrap和scn base。实际上SCN长度为48位,即它其实就是一个48位的整数。只不过可能是由于在早些年通常只能处理32位甚至是16位的数据,所以人为地分成了低32位(scnbase)和高16位(scn wrap)。为什么不设计成64位,这个或许是觉得48位已经足够长了并且为了节省两个字节的空间:)。那么SCN这个48位长的整数,最大就是2^48(2的48次方, 281万亿,281474976710656),很大的一个数字了。这里有一个重要的公式:SCN= (SCN_WRP * 4294967296) + SCN_BAS根据上面的公式,可以计算出SCN的数据值。在很多与我们事务相关的记录中都是记录SCN WRAP 和 SCN BASE.SQL> select START_SCNB,START_SCNW from v$transaction;
SQL> desc smon_scn_time
Name Null? Type
------------------------------------------------- ----------------------------
THREAD NUMBER
TIME_MP NUMBER
TIME_DP DATE
SCN_WRP NUMBER
SCN_BAS NUMBER
NUM_MAPPINGS NUMBER
TIM_SCN_MAP RAW(1200)
SCN NUMBER
ORIG_THREAD NUMBER包括在我们Data block 的内部,也是使用SCN WRP 和 SCN BASE的。二.测试案例我们这里用Data File 1 上的DataBlock 92967为例。BBED> show
FILE# 1
BLOCK# 92967
OFFSET 0
DBA 0x00416b27 (4287271 1,92967)
FILENAME /u01/app/oracle/oradata/dave/system.256.816661027
BIFILE bifile.bbd
LISTFILE /u01/filelist.txt
BLOCKSIZE 8192
MODE Edit
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH 80
COUNT 8192
LOGFILE log.bbd
SPOOL No BBED> p kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0x06
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x00416b27
ub4 bas_kcbh @8 0x003566cc
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x01
ub1 flg_kcbh @15 0x04 (KCBHFCKV)
ub2 chkval_kcbh @16 0xc36e
ub2 spare3_kcbh @18 0x0000Block Dump 的结果:Start dump data blocks tsn: 0 file#:1minblk 92967 maxblk 92967
Block dump from cache:
Dump of buffer cache at level 4 for tsn=0rdba=4287271
Block dump from disk:
buffer tsn: 0 rdba: 0x00416b27 (1/92967)
scn: 0x0000.003566cc seq: 0x01 flg: 0x04 tail: 0x66cc0601
frmt: 0x02 chkval: 0xc36e type: 0x06=transdata
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FBE18328A00 to0x00007FBE1832AA00
7FBE18328A00 0000A206 00416B27 003566CC04010000 [...."kA..f5.....]
7FBE18328A10 0000C36E 00000001 00012965003566B8 [n.......e)...f5.]
......
7FBE1832A9F0 0144494C 014E014E 02C1024E66CC0601 [LID.N.N.N......f]这里的SCN 是:0x0000.003566cc初看这里估计很晕,在联系一下我们上面BBED的结果,就应该明白了。ub4 bas_kcbh @8 0x003566ccub2 wrp_kcbh @12 0x0000这里的SCN 格式是: SCNWRAP.SCN BASE.我们用第一节讲的公式计算一下SCN:SQL> select to_number("3566cc","xxxxxxx") from dual;TO_NUMBER("3566CC","XXXXXXX")-----------------------------3499724--系统当前的SCN 是:SQL> select CURRENT_SCN from v$database;CURRENT_SCN-----------3715593我们的block修改时的SCN 是:SCN= (0 * 4294967296) + 3499724 = 3499724即,我们的block:92967 在修改时,对应的SCN 是3499724。更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12ORA-01506: missing or illegal database name 故障分析一例resetlogs 打开数据库时新生成日志位置问题相关资讯 Oracle scn
- Oracle 11g通过SCN做增量备份修复 (05/19/2015 16:58:43)
- Oracle数据库启动过程验证检查点 (11/26/2014 11:16:46)
- Oracle的SCN和RBA (08/10/2013 11:12:32)
| - Oracle SCN -system change number (05/06/2015 11:58:11)
- Oracle体系结构之SCN、实例恢复 (09/15/2013 07:04:43)
- Oracle scn介绍 (08/30/2012 09:01:31)
|
本文评论 查看全部评论 (0)