我曾经在"利用BBED修改block内数据的一个例子"这篇文章里提到了一个计算block内部offset的base的计算方法，即：

BASE的计算方法为：

对于ASSM：76+（itc-1)*24

对于MSSM：68+（itc-1)*24

 

有朋友在MSN上问我说：为什么这里ASSM要比MSSM多了8个byte？

正好也有朋友在MSN上问我为啥不写一些关于block存储格式的文章，我这里就一并回答了吧。

 

首先，我觉得没有必要写block存储格式了，因为用BBED的map和print就可以精准的了解一个block的结构了，除了ASSM的segment header、L1、L2、L3用不了map和print之外，其他的基本上都可以。所以，除了写那些用BBED看不了的block的结构之外，写其他的意义并不大。

 

接着我们来回答一下第一个朋友的问题，即为什么这里ASSM要比MSSM多了8个byte？

 

要回答上述问题，我们先来看一下一个data block必然会有的三个component的大小：

SQL> select * from v$type_size where component in ('KCB','KTB');

 

COMPONENT TYPE     DESCRIPTION                       TYPE_SIZE

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

KCB       KCBH     BLOCK COMMON HEADER                      20

KTB       KTBIT    TRANSACTION VARIABLE HEADER              24

KTB       KTBBH    TRANSACTION FIXED HEADER                 48

 

从结果里我们可以看到，一个data block的cache layer的大小是20个byte，其transaction layer的固定部分的大小是48个byte（因为必然会有一个ITL），所以这里对于MSSM而言，其base的计算方法就是：20+48+（itc-1)*24，即上文中提到的68+（itc-1)*24。

 

那么对于ASSM而言，为什么会多了8个byte呢？我们继续往下看：

我们随便看一个MSSM的block：

BBED> map /v

 File: /dras21/astca/system02.dbf (125)

 Block: 1426                                  Dba:0x1f400592

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

 KTB Data Block (Table/Cluster)

 struct kcbh, 20 bytes                      @0      

    ub1 type_kcbh                           @0      

    ub1 frmt_kcbh                           @1      

    ub1 spare1_kcbh                         @2      

    ub1 spare2_kcbh                         @3      

    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     

 struct ktbbh, 96 bytes                     @20     

    ub1 ktbbhtyp                            @20     

    union ktbbhsid, 4 bytes                 @24     

    struct ktbbhcsc, 8 bytes                @28      

    b2 ktbbhict                             @36     

    ub1 ktbbhflg                            @38     

    ub1 ktbbhfsl                            @39     

    ub4 ktbbhfnx                            @40     

    struct ktbbhitl[3], 72 bytes            @44     

 struct kdbh, 14 bytes                      @116    

    ub1 kdbhflag                            @116    

    b1 kdbhntab                             @117    

    b2 kdbhnrow                             @118    

    sb2 kdbhfrre                            @120    

    sb2 kdbhfsbo                            @122    

    sb2 kdbhfseo                            @124    

    b2 kdbhavsp                             @126    

    b2 kdbhtosp                             @128    

 struct kdbt[1], 4 bytes                    @130    

    b2 kdbtoffs                             @130    

    b2 kdbtnrow                             @132    

 sb2 kdbr[32]                               @134    

 ub1 freespace[4966]                        @198    

 ub1 rowdata[3024]                          @5164   

 ub4 tailchk                                @8188

注意看这里kdbh的offset是116。

 

我们再来看一个ASSM的block：

BBED> map /v

 File: /dras21/astca/armshistemptbs_03.dbf (121)

 Block: 274445                                Dba:0x1e44300d

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

 KTB Data Block (Table/Cluster)

 struct kcbh, 20 bytes                      @0      

    ub1 type_kcbh                           @0      

    ub1 frmt_kcbh                           @1      

    ub1 spare1_kcbh                         @2      

    ub1 spare2_kcbh                         @3      

    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     

 struct ktbbh, 96 bytes                     @20     

    ub1 ktbbhtyp                            @20     

    union ktbbhsid, 4 bytes                 @24     

    struct ktbbhcsc, 8 bytes                @28     

    b2 ktbbhict                             @36     

    ub1 ktbbhflg                            @38     

    ub1 ktbbhfsl                            @39     

    ub4 ktbbhfnx                            @40     

    struct ktbbhitl[3], 72 bytes            @44     

 struct kdbh, 14 bytes                      @124    

    ub1 kdbhflag                            @124    

    b1 kdbhntab                             @125    

    b2 kdbhnrow                             @126    

    sb2 kdbhfrre                            @128    

    sb2 kdbhfsbo                            @130    

    sb2 kdbhfseo                            @132    

    b2 kdbhavsp                             @134    

    b2 kdbhtosp                             @136    

 struct kdbt[1], 4 bytes                    @138    

    b2 kdbtoffs                             @138    

    b2 kdbtnrow                             @140    

 sb2 kdbr[32]                               @142    

 ub1 freespace[4958]                        @206    

 ub1 rowdata[3024]                          @5164  

 ub4 tailchk                                @8188

注意看这里kdbh的offset是124，比MSSM多了8个byte。

 

所以上述问题的答案就是：在ASSM下，oracle改变了block内部table directory和row directory的位置，oracle把它们顺延了8个byte，所以对于ASSM而言，其base的计算方法就是：20+48+8+（itc-1)*24，即上文中提到的76+（itc-1)*24。

作者：Fenng 发布在 dbanotes.net.

虽说年底是 IT 事故多发的期间，不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号，从上午11:00到下午15:30，故障持续四个多小时，全行系统瘫痪。对外称是"核心系统维护"。

个人之所以比较关注这个事故，是因为新闻标题中的"数据库维护失误"。据说是"由于数据系统进行维护时出现了失误，造成宕机"。开始的时候，大家把关注的焦点放到灾备切换与否的问题上，据说是"没敢切换"。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关，我错过了讨论现场。

也有朋友在 Twitter 上说：民生银行上周的系统宕机事故，源于IT部门某应用系统数据库（应该是 DB2 Informix，数据库版本老旧，且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本 EOS ，无厂商实验室的工具支持无奈之下，要求重启相关系统，结果造成业务停止。事件的(后续)处理还在进行中。(via)

上述说法看起来比较可信，也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心，实施方是埃森哲(refer)。不过，"民生银行打造的新核心系统已经开发完毕，目前处于内部运用的阶段，今年上半年将会在全公司上线"，估计到时候能稳定点?

另外看到有网友说，2008 年初，民生银行的的小额支付系统也出过严重问题，由于操作失误或是程序内部控制原因，造成了几百万的重帐。

涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看，事故发生后，更多的时间都会花在决策上，而一旦选择错误或者不是做出最优的决定，灾难才刚刚开始。

--EOF--

---

最近文章|Recent Articles

• 2009年数据库技术领域回顾
• 借助 Complemento 测试 DoS 攻击风险
• Oracle Exadata 技术浅析
• 编程语言的选择并非无关紧要

本站赞助商：豆瓣网

评论数(6)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/review/cmbc_crash.html

DBA Notes 理念: 用简约的技术取得最大的收益...

造字中，
才发现，
南=冇+¥ =没钱，
难怪贵报……

...

p { text-indent:28px; } 在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。 Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。 1. 如何配置Key Cache的大小 #配置文件my.cnf key_buffer_size=50*1024*1024 另外，Key Cache的大小可以动态的改变 2. 给数据表划分单独的Key Cache 例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。 SET GLOBAL hot_cache.key_buffer_size=128*1024; CACHE INDEX t1 IN hot_cache; SET GLOBAL hot_cache.key_buffer_size=0; 3. 预先载入某些数据表的索引 LOAD INDEX INTO CACHE t1, t2 4. 关于Key Cache的使用情况观察 Flush现象 mysql> show status like "key%"; +------------------------+----------+ | Variable_name ...

p { text-indent:28px; } 本文将分为前、中、后三篇，分别介绍MyISAM Key Cache的一般机制、Mid-point strategy、状态、参数和命令。 “Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。 1. MyISAM如何使用Key Cache 当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。 如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。 2. 图解 下图展示了访问Index Block的过程：（黑色部分为磁盘中的Index文件） 3. 并发访问 Key Cache中的index Block是可以被并发访问的（Shared access ），下面是一些规则： 多个没有更新操作的session可以并发同一个block buffer 多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问 多个session如果都需要进行block replacement，是可以并发操作。（从index file中读取block更新到key cache，但是key cache已满，需要删除一些block buffer的操作叫做block replacement）   4. 补充说明 Key cache中的Block大小可能和索引文件中的Index Block大小不同，可能是大于、小于、等于中的任何一种，但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。 （未完待续）

p { text-indent:28px; } 在前篇中介绍了Key Cache的基本机制，并且介绍了Key Cache的LRU算法。作为对LRU算法的改进，MyISAM还提供了另一个缓存算法：“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。 1. 相关参数 该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold 2. 原理介绍 (1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。 (注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值) (2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。 (3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。 (4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。 (5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。 3. 如何使用Midpoint Insertion Strategy 我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。 （未完待续）