2010-02-09 Tue
最近刚看完《异类》一书:其中讲了有所成就的人士除了10,000小时定律之外很重要的(而且经常被人们忽视的)一个因素就是人口的变化。因此也额外对人口变化趋势非常关注,高巍为此做了一个星座和中国人口出生量的统计。
我看到一个人口构成数字是清议在《可预见的中国式灾难》中引用的田雪原《中国人口预测结果》(原始出处未找到)人口年龄统计:制成图表如下

原始数据表格列表如下(单位:万人):
年份 总人口 0~14岁 15~64岁 65岁以上 新增劳动人口 抚养比
2007年 132,129 25,633 95,794 10,702 2,142 37.9% 2007年实际值
2008年 132,978 24,911 96,938 11,129 2,119 37.2%
2009年 133,634 24,524 97,713 11,397 2,072 36.8%
2010年 134,279 24,289 98,301 11,688 2,076 36.6%
2011年 134,916 24,093 98,807 12,016 2,046 36.5% 抚养比谷底
2012年 135,543 23,994 99,152 12,397 1,949 36.7%
2013年 136,144 23,943 99,401 12,801 1,840 37.0%
2014年 136,706 23,941 99,465 13,300 1,776 37.4%
2015年 137,213 23,657 99,682 13,875 1,706 37.7%
2016年 137,652 23,305 99,918 14,430 1,650 37.8%
2017年 138,014 22,980 99,920 15,114 1,602 38.1% 劳动人口峰值
2018年 138,294 22,671 99,800 15,823 1,597 38.6%
2019年 138,491 22,365 99,534 16,592 1,619 39.1%
2020年 138,614 22,059 99,170 17,386 1,587 39.8%
2021年 138,668 21,735 98,852 18,080 1,597 40.3% 总人口峰值
2022年 138,658 21,390 98,466 18,803 1,608 40.8%
2023年 138,592 21,018 98,140 19,434 1,620 41.2%
2024年 138,471 20,617 98,107 19,748 1,626 41.1%
2025年 138,301 20,186 98,102 20,012 1,635 41.0%
2026年 138,082 19,722 98,349 20,011 1,641 40.4% 65岁以上超过14岁以下人口
2027年 137,813 19,228 98,220 20,365 1,648 40.3%
2028年 137,493 18,716 97,140 21,637 1,654 41.5% 抚养比之后每年上升一个百分点
2029年 137,123 18,202 96,157 22,764 1,658 42.6%
2030年 136,705 17,701 95,221 23,783 1,654 43.6%
2031年 136,239 17,228 94,226 24,786 1,654 44.6%
2032年 135,729 16,799 93,359 25,571 1,655 45.4%
2038年 131,793 15,175 85,651 30,967 1,383 53.9%
2048年 121,682 13,546 75,791 32,345 1,345 60.5%
2050年 119,163 13,116 73,701 32,346 1,331 61.7%
2060年 105,064 10,605 61,285 33,174 1,239 71.4%
2085年 71,256 7,065 40,042 24,149 898 78.0% 抚养比峰值
2100年 55,647 5,596 31,621 18,430 601 76.0%
由于种种原因,终于交了那封信。
现在的感觉,很轻松,再也不用担心有人半夜给我电话,说系统当机了,或者说系统hang了,也再也不用因为干活之外的事情被骂了。
晚上,终于可以关机了。
不用每个月一个星期的在晚上oncall,每次oncall一个星期,就要休息一个星期才能缓过来。
让我,先享受下,这种没有压力的感觉。
我曾经在"利用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
本站赞助商:豆瓣网
评论数(6)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址:http://www.dbanotes.net/review/cmbc_crash.html
DBA Notes 理念: 用简约的技术取得最大的收益...






