存档

2009年12月 的存档

大牛jonathan lewis在圣诞节出了一个小题目:Holiday Quiz
I have a table with one million rows, there are no indexes on the table. The table has a column called sortcode which has no nulls, and has been generated in a highly random way so that no value appears more than four times. Consider the following queries:

select sortcode
from t1
order by sortcode;
select  sortcode
from (
select [...]

12 30th, 2009 | Filed under 大话技术
标签:

普通PC本地磁盘,没有共享存储,如何实现HA?Dataguard挺好,但是存在数据丢失的可能性,而且很难做到应用透明切换。我们用ASM,Heartbeat和iSCSI可以实现一个廉价的HA方案,如下图:

用iSCSI将本地磁盘输出到对方的机器上,利用ASM的failgroup做mirror,保证数据mirror在两台不同的机器上,就算一台机器完全损坏,数据可以做到百分之百不丢失。用Heartbeat作HA探测,如果发现主机故障,则强行关闭DB和ASM,并在备机启动ASM和DB。如果使用Oracle 11g R2,还可以利用Preferred mirror read的特性,保证主库读自己的本地磁盘,而不是通过iSCSI读备机磁盘,这样可以达到更好的性能。
缺点:Heartbeat作为HA软件,我们并不是十分了解其探测机制,可能出现误判或者无法切换的情况。但是其实IBM hacmp这种HA软件一样有问题,比如Oracle hang住时,现在的hacmp根本无法探测,因为hacmp只是判断Oracle的进程在不在,而不管数据库是否活着。
我想不管什么HA软件,都无法处理所有的异常情况,我们只要有完善的监控和应对措施就可以了。比如我们现在所有的DB都有一个监控,就是定时模拟应用去更新数据库中的数据,如果发现超时或者报错,就认为数据库出现hang的情况,并发出报警。
–EOF–
另:之前我有一篇文章介绍用ASM和iSCSI搭建RAC的文章,在实际测试过程中,发现存在一些问题,因为在11g R2之前,voting disk和OCR都必须放在RAW devices上。因为没有共享存储,如果发生某台机器全部宕机,voting disk可能会丢失一部分,造成RAC的cluster机制发生误判。所以在11g R2之前,这个方案是有问题的,在11g R2中,Oracle几乎所有的东西都可以放在ASM中,这个方案也许可行,我还没有测试过。
在我写完这篇博文后,发现这个方案存在一些问题,通过iscsi将online redo输出到另外一个主机后,log file sync的响应时间需要40-60ms,这个响应时间肯定是无法接受的。现在两台主机的互连是四块千兆网卡直连,通过Linux的Multipath来管理多路径,为什么响应时间这么久,我们还在进一步查找问题。

12 10th, 2009 | Filed under 大话技术
标签: ,

工作十年,终于有了自己的小窝。其实租房和自己买房并没有什么区别,在中国只是租期长短的差异,但是在自己的家里还是感觉到温暖和安全。
其实家不能房价来衡量,豪华或者简朴也不重要,最重要的是在这个地球上,有一个地方是我的家,不管外面刮风下雨,那里总是温暖的,不管我多晚回家,总是有人为我开门,不管我多么疲惫,一回家就可以听到宝宝喊我爸爸。在家里,我是幸福的。
卧室什么的都没拍了,太乱。欢迎朋友们去家里玩,有个小朋友很爱热闹,最喜欢有人陪他疯。
–EOF–

12 7th, 2009 | Filed under 一地鸡毛
标签: ,

在面试时经常会问一个问题,请列举出hash在数据库内部的应用,hash的原理虽然简单,但是它在数据库中可以说是无处不在。其中hash partition是hash在数据库中一个简单的应用,虽然它没有range partition那么常用,但是我们在做数据库水平拆分时,其实就是利用了hash partition的原理,利用hash函数对某个key进行运算,然后将其分布到不同的主机上,原理很简单。
我们在设计时遇到了一个问题,当分区的数量需要变化时,基于hash的原理,数据可能会从一个分区移动到另外一个分区,因为某个key在4个分区时,可能被分布在分区3,而在8个分区时,可能被分布在分区5。这样每当分区数量变化时,就需要全部重新分布数据,代价很高。
那么Oracle是怎么做的?首先可以肯定的是Oracle的hash partition在分区增加时,不需要做全部数据的重新分布。有人告诉我Oracle的hash函数比较牛,可以保证分区数量增加时,这个hash函数可以让原来的数据还在旧的分区中,而新的数据可以分布在新的分区。Oracle的函数无非就是get_hash_value或ora_hash(10g),从hash的原理上来说,这也是不可能做到的。
我们对hash partition都有一个常识,就是partition的数量最好是2的次方,也就是2,4,8,16……,否则分区会出现不分区均衡的现象,按照hash的原理,不管是几个分区,都可以做到完全均衡的,为什么会不均衡,其实答案已经出来了,Oracle为了能够增加分区,为你预留了几个看不到的分区。
假设我们有6个分区,一共8000条数据,数据的分布如下图:

hash partition不能直接增加分区,而是split当前分区,当需要增加到8个分区时,实际上是分区3和分区4分别split产生新的分区7和分区8,如下图:

Oracle如何做到分区数量增加后,其他分区的数据不受影响呢,其实很简单,Oracle在做hash运算时,预留了分区,比如6个分区,实际上是用8个分区的hash来运算的,只不过把缺少的分区的数据合并到其他分区,这样就会出现数据不均衡的情况。Oracle的公式是这样的,用等于或者大于当前分区数量的最小的一个2的N次方,比如6个分区做8个hash bucket。我们再来考虑一下2,4,8,16(2的N次方)的情况,比如要把4个分区加为5个分区,因为已经是2的N次方,所以数据会均匀分布,而且Oracle还是使用4个hash bucket。这时新增的分区5实际上把分区1 split后产生的,这时因为有5个分区了,所以会使用8个hash bucket。这时Oracle的hash函数就比较牛了,它可以保证2,4,8,16个分区时,同一个键值分布在相同的分区或者是对应可以合并的分区,看下面的SQL:
select ora_hash(‘hellodba’,1)+1 par2,ora_hash(‘hellodba’,3)+1 par4,ora_hash(‘hellodba’,7)+1 par8,ora_hash(‘hellodba’,15)+1 par16 from dual;
PAR2 PAR4 PAR8 PAR16
———- ———- ———- ———-
[...]

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

我们常用的HA方案有几种:一是用小型机和HA软件作双机热备,这种方案始终有一台设备处于空闲状态,设备利用率很低,而且必须用IBM,HP等厂商的硬件,代价昂贵。二是用Oracle的RAC来做HA,在Linux环境下,Oracle提供了全套的解决方案,是个不错的选择,不过最低也需要一套共享的存储设备。三是用Oracle DG,这种方案成本最低,但是无法做到故障时应用透明切换,我们也曾经尝试过用heartbeat配合DG failover来作一些尝试,但是在测试中发现,在极端情况下,可能存在丢失数据或者无法切换的可能性。
自从使用MySQL数据库以来,我们就一直探索MySQL的HA方案,目前应用最广泛的是用heartbeat作HA,利用MySQL双向复制技术,达到透明切换的目的。但是heartbeat并不是十分的稳定,而且切换的过程也比较长。
是否有更好的解决方案?首先要解决故障探测的问题,如果应用可以自己探测数据库状态,发现数据库出现问题时,可以切换到另外一台备机;其二主备库之间的数据同步问题,如果我们可以解析Oracle或者MySQL的日志,还原成SQL信息并应用到备机,这样就实现了logical standby或者MySQL复制的功能。利用这两个功能,我们可以实现一个更廉价更灵活的HA方案。
目前我们正在做三个工具,第一是日志解析工具,包括Oracle和MySQL,日志解析是将日志文件中的变化还原为SQL或者日志信息;第二是数据同步工具,主要负责将日志信息打包传输,并应用到目标数据库上;第三是数据库探测与路由工具,主要负责探测数据库状态,对应用做透明故障切换。
这个方案中,由于数据库不再有primary和standby之分,仅仅是应用端来作判断连接哪个数据库,所以故障切换的时间非常快,我们测试大概只需要10秒。但是数据同步可能存在一定的延时,也就是说数据库切换后,数据可能存在一定程度的丢失,但是我们可以在切换后再对数据进行补全,这个我们是可以接受的。利用这些工具,我们可以搭建出很多灵活的解决方案,并不一定要依赖IBM,Oracle的解决方案,毕竟适合我们的才是最好的方案。
目前这个方案还在开发与验证中,欢迎大家和我探讨HA这方面的问题。
–EOF–

12 2nd, 2009 | Filed under 大话技术
标签: ,