存档

2009年4月 的存档

上周,同事作了一个关于undo internal的技术分享,发现我对这些技术细节都忘得七七八八了,这也证明我当初并没有真正理解其中的原理,今天又重温了一下,发现还是有一些问题没有想清楚。
这里我尽量用简单的语言描述其实现原理,内容涉及到itl,undo,cleanout,consistent read,ORA-1555等内容。
1.一致读产生的一般性原理:
构造一致读的过程实际上是一个递归的过程,用data block+undo构造出一个CR block,如果发现这个CR block还不够旧,就继续用这个CR block+undo来构造,直到构造出的小于query scn的CR block或者报1555错误。data block如何找到相应的undo,就要用到ITL,因为在构造CR block的过程中,不仅仅回滚了data block中的数据,ITL也同时回滚了(因为在undo entries中不仅仅包含数据的before image,也包括ITL的before image),这样不管要构造多少次,只要UNDO信息没有被覆盖掉,都可以通过block上的ITL找到相应的undo。
2.undo segment header上的control SCN
这个SCN是这个undo segment中的任意一个slot被覆盖时,这个slot的上一个事务的提交scn,就是这个undo segment可以回滚的最小SCN,如果查询的scn小于control scn,那么Oracle将直接返回1555,因为回滚也必然是失败的。这个control SCN的另外一个重要用途是,在delay cleanout时,如果对应的slot被覆盖,则用这个control SCN作为upper bound SCN作为事务的commit SCN,因为用这个SCN是安全的。
3.undo entries chain
我们把undo block中具体的undo信息称为undo entries,由于一个事务可能包含很多操作,在回滚时必须从最后一个entries向前回滚。首先我们通过undo segment header上的事务表找到undo block的地址,在这个undo block中记录了最后一个undo entries的位置(偏移量),每个undo entries中又记录了上一个的地址,这样就形成了一个undo entries chain。
4.undo segment header
回滚段头的主要结构是事务表,事务号是由undo segment number+slot number+sequence组成,当slot重用时,sequence number会增加一,用来唯一的标识一个事务。通过事务表可以找到最后一个undo entries所在的undo block。
我这里有几个疑问:
1.从一些资料上看到undo segment header上有一致性读,什么情况下undo segment header上需要一致性读?作用是什么?
2.在我的测试中,就算slot被重用,但是undo entries是不会被覆盖的。但是当slot被覆盖后,进入这些undo entries的入口没有了,这些undo entries会在什么情况下被使用?难道是flashback?
3.data block中的ITL中不仅记录了undo [...]

4 28th, 2009 | Filed under 大话技术
标签:

最近感觉没有什么动力,Blog也不知道写点什么。试着开一个ask jacky的栏目,大家可以问我各种问题,我来回答,如果我也不知道,那我就再问问身边的牛人,顺便也是个学习的过程。
与其说是“问”,不如说是大家一起讨论有关DBA的话题,可以是有关于数据库,架构,主机,存储,数据中心等技术问题,也可以和我探讨DBA职业生涯,打听DBA小道消息,甚至有关摄影,汽车,电影等海阔天空的话题。但请不要问有关个人隐私和公司机密方面的问题。
我也没什么影响力,有人问就问,没人问就拉倒。我的email:freezr@gmail.com
友情提醒:对于有价值的问题,我可能会选择发表在我的blog上。
–EOF–
Play Dead ipod

4 22nd, 2009 | Filed under IT江湖
标签:

SUN被收购的传闻一直没断过,昨天终于尘埃落定,Oracle以74亿美金收购SUN。
我们来看看Oracle得到了什么?Sun的硬件产品,Java,Solaris和MySQL数据库。前三个产品对Oracle来说应该是非常有价值的,只有MySQL前景不明。因为Oracle的CEO Larry Ellison有句名言,与对手最好的竞争方式就是收购它。
对MySQL唯一的利好消息是,InnoDB也在Oracle手中,不用再担心存储引擎的问题了。关键是Oracle对MySQL的态度如何?作为一个竞争产品打入冷宫,继续发展走商业化路线,还是保持现在的开源身份,让我们拭目以待吧。
–EOF–The Negotiator release

4 21st, 2009 | Filed under IT江湖
标签: ,

“XX公司的数据中心位于中国甘肃玉门,数据中心的电力全部来自于风力发电,用祁连山融化的雪水冷却数据中心产生的热量,它是中国第一个绿色环保的数据中心“。

在大多数人的脑海中,只考虑CPU够不够快,处理能力够不够,却从来不考虑”电“的问题。而当数据中心到一定的规模时,”电“的问题就凸显出来了。我们一般的机房,驱动1W的计算能力,就需要额外1.4-1.5W的电力去驱动网络设备和空调等设备,这个指标可以用PUE值来表示,普通机房的PUE(Power Usage Effectiveness)值在2.4左右。
我们现在的机房就面临严重的电力短缺问题,老大们说我们不差钱,机器不够就买,但是却没人考虑电的问题,直到它成为阻碍我们发展的一个重要因素。现在CPU越来越强大,但是功耗和发热量也越来越大,必须配备更大功率的电源和空调,传统的机房用空调产生的空气对流来制冷,效率并不高。去过机房工作的人都知道,在机房里在不同的位置,要不就被冻死,要不就被热死。而且电力在直流和交流转换时又损耗了好大一部分,所以我们使用电力的效率是很低的。这还不算那些闲置的计算资源,白白消耗能源。
节能的典范,不得不提Google,他通过很多节能的方法,包括自制的服务器,低功耗的CPU(或者是更耐热的CPU),有效的制冷方式等等,他的平均PUE值可以达到1.2甚至更低。虽然大家都在说,Google做一次搜索相当于产生了多少二氧化碳的排放量,但是它确实非常重视节能和环保。Google一直在探索绿色清洁的数据中心,最近就听说要在海上搞一个数据中心,用海水来冷却机器,当然现在还只是构想。
如果我们要用集中式的数据中心,首先要解决网络的问题。而现在的中国,网络拥堵是很大的问题,尤其是电信和网通的互联的问题,现在的解决方案是通过遍布全国各地的CDN,提高用户的访问速度。而集中式的数据中心,必须要求高速的基础网络,这个在短时间内还很难解决。靠电信和网通,还不如靠自己,虽然我们现在建立了自己的骨干传输网,虽然现在的规模仅仅是互联公司内部的一些机房,但是也许某天我们成为中国第三大网络运营商也不是没可能。
–EOF-
声明:本篇文章的所有内容均属虚构,如有雷同,纯属巧合。不经过作者同意,不允许转载。

4 16th, 2009 | Filed under 大话技术

试着招一个DA(数据架构师),今年最后一个名额。如果不明白是干嘛的,请看我的帖子:DBA未来的发展方向。
要求如下:
1.懂数据库,尤其是数据库原理以及优化的概念;
2.有项目开发经验,但不会要求你来做coding的工作;
3.有项目管理经验,实际参与过中型大型项目开发;
4.具备软件架构的思想,对技术有自己的想法;
4.非常好的沟通能力和学习能力。
这是一个超越普通开发DBA的职位,也是一个非常有挑战性的工作。我知道这个职位有些过于理想化,但是这才是我们真正想要的。如果有兴趣,请发邮件或者Gtalk聊。
–EOF–
补充一下,这个职位的主要工作职责:
1.与架构师团队紧密合作,推进数据库优化相关的项目(比如Amoeba)。
2.Review所有开发DBA跟进的项目,对工作进度和质量进行检查。
2.项目评估,开发DBA的资源管理。
4.过程改进,内部工具设计与开发。

4 10th, 2009 | Filed under IT江湖
标签:

设想以下的一个问题:有一个keyword的集合,我们需要快速判定某个keyword是否包含在其中。最简单的方法是遍历,但是效率很差。我们马上想到了hash的方法,因为在Oracle内部,hash无处不在。比如在cache buffer中找到某个block,在shared pool中找到某个SQL等等。我们可以把keyword的集合build成一个hash table,然后根据keyword计算hash值,通过是否落在相应的hash bucket中,这样就可以实现快速查找的目的。这个方法不错,但是当keyword过多时,hash table会占用大量内存,效率也会随之下降。
今天公司的架构师介绍了一个新的方法给我:Bloom Filter。它是一种基于随机数(或Hash)的数据结构,它支持对成员使用较少空间来存储,却能得到较高效率的查询。换句话说:在Bloom Filter 可以用于检索一个元素是否在一个集合中。其原理如下:
建立一个容量为500万的Bit Array结构(Bit Array的大小和keyword的数量决定了误判的几率),将集合中的每个keyword通过32个hash函数分别计算出32个数字,然后对这32个数字分别用500万取模,然后将Bit Array中对应的位置为1,我们将其称为特征值。简单的说就是将每个keyword对应到Bit Array中的32个位置上,见下图:

当需要快速查找某个keyword时,只要将其通过同样的32个hash函数运算,然后映射到Bit Array中的对应位,如果Bit Array中的对应位全部是1,那么说明该keyword匹配成功。
Bloom filter 是一个集合的有损编码,所以它不是一种“保险”的方案,存在一定的误判率。
有人问:这个对DBA有什么用?虽然我们不直接开发应用,但是开阔视野和思路对我们同样重要。难道我们碰到这种问题就只能用like或者in去解决吗?
–EOF–
后记:要深入了解Oracle,hash的原理和实现是必须要掌握的。有一次面试一个技术专家,高精尖的技术谈得头头是道,但是连hash的基本原理都说不清楚。对于一个技术专家来说,不能只懂“高精尖”,没有基础的知识,任何“高精尖”都只是空中楼阁,对于DBA,尤其如此。

4 8th, 2009 | Filed under 大话技术
标签:

shareplex是Quest公司出品的软件,专门用来做Oracle数据库之间的同步,他的原理是通过解析Oracle的redo log,然后解析成SQL语句同步到其他的数据库中,它最大的好处在于,同步时目标数据库可以读写。类似shareplex的软件有很多,比如国内的厂商DSG,他们虽然实现的细节上有差异,但是基本原理都是一样的。
我很奇怪Oracle为什么一直不推出自己的解决方案,据Oracle的顾问说,他们从来没有将redo log的格式公开给其他任何一个公司,包括Quest公司(但我对此表示怀疑,因为Oracle logical standby据说就是Quest给OEM的)。Oracle从10g开始,推出了自己的产品Stream,但是目前我们对其并不看好,虽然redo的格式Oracle最清楚,但是要形成一个成熟的产品还有很长的路要走,毕竟还没有经过大规模应用的检验。
我们同样面临很多数据同步的问题,通常的做法是:用trigger记录变化,然后通过程序定期同步数据。但是这种方法需要在数据库中建立大量的trigger,严重影响性能,且实时性很差。
去年部门来了一位对Oracle internal和C语言很精通的同事范鑫,我们也有想法自己做Oracle redo解析。我们的目标很简单,并不是要做一个类似shareplex这种大而全的商业软件,而是通过Oracle redo解析出变化的PK,将其记录到数据库(MySQL)或者文件中,然后程序根据这些PK再去同步数据(其实可以看成是替换了数据库中用来记录变化的trigger)。因为目标简单,通过大半年的努力,现在已经在数据仓库得到了应用。原来数据仓库抽取数据必须依赖于每个表上的修改时间字段,非常不可靠,而且每天只能取一次。现在通过redo解析(可以解析online redo),可以基本做到准实时同步。解决了多年困扰数据仓库的数据抽取问题。
这套系统我们还在不断的完善中,包括DDL的支持,CLOB等特殊数据类型,直接SQL解析,并行apply等等。接下来,我们要将其逐步应用到数据库站点之间的同步上。不仅如此,这套系统给我们更多的遐想,包括Oracle和MySQL数据库的数据同步,Oracle与搜索引擎,memcache之间的数据同步等等。
地球人都知道我们“不差钱”,那为啥不用成熟的商业软件,自己费半天劲做的能比shareplex好?就象我们自己用PC机搭建的山寨存储,可能比某些公司用跳楼价卖给我们的存储还要贵。有些人说:让专业的人做专业的事,言下之意,DBA就应该只管好数据库。我承认山寨存储永远也做不到象EMC那样专业,自己的redo解析工具肯定不会比shareplex更强大。我们也没想过要做一个东西来替代它们,我们的目标是适用于我们自己的环境,简单可靠,而且技术掌握在自己手中有很大的灵活性,比如redo解析工具加以修改就可以演化出很多小工具,给DBA的工作带来了便利。另一方面,除了结果,我们更看重创新的过程,如果连想都不敢想,创新从何谈起。
通过这个Oracle redo解析的工具和一系列同步的应用程序,我们就可以搭建一个山寨版的Oracle数据库同步方案。”能解决问题的方案就是好方案,就是有技术含量的方案“,我现在非常推崇用简单的技术搭建复杂的系统,用搭积木的方式解决工作中的问题,请各位大牛不要总拿技术含量说事。
在这个项目中,我只是个旁观者,从最初的怀疑态度到现在的坚定支持者,我的观点发生了很大的改变。感谢大师,感谢范鑫,感谢团队的共同努力,让不可能成为可能,而不是总停留在想法的阶段。
借用发哥一句话:成功?我才刚上路呢。
–EOF–

4 3rd, 2009 | Filed under 大话技术
标签: