Hello DBA

普通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来管理多路径，为什么响应时间这么久，我们还在进一步查找问题。

工作十年，终于有了自己的小窝。其实租房和自己买房并没有什么区别，在中国只是租期长短的差异，但是在自己的家里还是感觉到温暖和安全。

其实家不能房价来衡量，豪华或者简朴也不重要，最重要的是在这个地球上，有一个地方是我的家，不管外面刮风下雨，那里总是温暖的，不管我多晚回家，总是有人为我开门，不管我多么疲惫，一回家就可以听到宝宝喊我爸爸。在家里，我是幸福的。

卧室什么的都没拍了，太乱。欢迎朋友们去家里玩，有个小朋友很爱热闹，最喜欢有人陪他疯。

–EOF–

在面试时经常会问一个问题，请列举出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
---------- ---------- ---------- ----------
         2          4          4         12

上面的SQL我们看到分区的数量在2，4，8，16时，hellodba这个key分别落在在2，4，4，12号分区，虽然落在不同的分区上，但是分区4和分区12是对应可合并的，这样就保证了数据是不需要移动的。一句话总结就是hash bucket总是2的N次方，如果分区数不足，则会合并数据，产生不均衡的情况，这样增加分区时，只需要对应分区的数据做split即可。同理，减少分区也不是简单的drop，而是合并分区。

再回到我们的项目中，我们为了解决这个问题，采用了更简单的处理方案，直接就做了1024个分区，我们有8个物理数据库，每个数据库中有128个表，以后再分拆时，只要移动这些表，并修改应用中的对应关系就可以了。其实和Oracle合并再拆分的思路是一样的。

这个问题其实在大牛lewis的Practical Oracle8i中讲过，当时我并没有仔细想清楚，现在想清楚了，特此记录。有些东西，明白了就觉得它挺简单的，希望对大家有帮助。

–EOF–

我们常用的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–

SSD固态硬盘，其最大的优势在于，单块SLC的SSD就可以达到数万IOPS，想象一下，一个大型存储的IO能力也许用几块SSD就可以做到。当 然SSD也有缺点，写磨损是一个大问题，虽然可以用“冗余容量”和“均匀写”来解决，但是还是很难消除电子产品比机械产品可靠性差的疑虑（相比较SSD， 普通磁盘可以归纳为机械产品）。另外一个问题是稳定性，对于数据库这种对稳定性要求很高的应用来说，SSD还有待于实际应用的检验。

我们从两年前就开始跟踪SSD产品，并进行很多的测试与评估，目前业界SSD主要是作为二级cache来使用的，比如在存储中配置SSD或者flash 卡，用来作数据库的cache，数据库全部使用SSD的应用还非常少见。我们在今年的项目中开始尝试用PC server+SSD+MySQL来取代小型机+大型存储+Oracle，当然前提是应用做了分布式的架构，虽然SSD的价格依然很贵，但是还是可以接受 的，至少比IBM小型机，EMC存储便宜吧。

由于业界普遍缺乏SSD的使用场景，硬件厂家也很少有成熟的配置SSD的高性能PC方案，我们只好自己搞，SSD和PC都是我们采购，然后自己 DIY自己测试。在实际使用的过程中，先是发现SSD盘的故障率很高，经过厂家检测后发现有质量问题，后来又发现SSD与PC存在兼容性问题，在大压力时 会导致OS hang，以至于DB hang，目前还在与硬件厂家做进一步的检测。

在测试SSD的过程中，有一些小的发现。MLC和SLC相比，价格和性能基本上前者都是后者的三分之一，MLC宣称的写磨损次数要比SLC低很多，也就是说MLC更容易坏，数据库环境一定要用SLC的SSD。SSD如何做RAID？我们采用Solaris的ZFS来管理SSD，而没有使用通常的硬件RAID卡，因为相比较SSD巨大的IO能力来说，也许RAID卡就成为了性能瓶颈。SSD适合OLTP类型的应用，对吞吐量要求比较高的数据仓库类型不适合，因为有写磨损的问题，所以对于写密集型应用也不适合。CPU不必迷信IBM的Power，现在Intel的nehalem甚至AMD，从测试数据上看并不比IBM差，当然PC机的可靠性比小型机要差一些，这就需要应用架构去弥补了。

SSD是未来的方向，但是目前来看还不成熟，就算当前的问题解决，还是普遍存在一个疑问，“写磨损对SSD的寿命的影响有多大，会不会发生同时 SSD盘大量损坏的情况，数据库完全放在SSD上是否可靠”。但是，SSD巨大的性能优势又让我们对它充满了期待。我们还在努力，如果我们的方案成熟，证 明SSD对数据库完全可行，并且可靠性不是问题，那么SSD将迅速取代普通SAS/SATA，我们每天都在担心的IO问题，也许真不是问题了。

–EOF–

Alibaba招聘应用DBA一名，要求：

必选：

1.精通SQL，Schema设计，SQL优化。

2.精通Oracle数据库原理与性能优化。

3.学习能力，沟通能力，抗压能力。再加一条最重要的责任心 The Hurt Locker on dvd 。

可选：

1.具备一定的Java开发能力，参加过实际的项目开发。

2.熟悉MySQL数据库。

3.对海量数据处理有一定的经验。

应届生也可以，有兴趣发简历到我的邮箱：freezr@gmail.com.

–EOF–

Oracle 11g的ASM有两个有意思的特性，我们看看他们能带给我们什么？

1.Fast mirror resync

原来当diskgroup中的盘发生故障时，Oracle会将这个盘标记为offline状态，并在一定的时间内从diskgroup中drop掉这块磁盘。如果disk只是临时性的故障，那么当故障恢复时，需要同步这块盘的全部内容，尤其是当某个failure group的全部磁盘都出现问题，比如我们的存储某个节点临时性断电，这时要重新build整个failure group中的所有磁盘，这个操作会非常耗费系统的资源，而是同步的过程会很长。

fast mirror resync这个特性在发生故障时，记录数据变化，然后当磁盘恢复时，只需要同步这些变化内容，让同步的时间变得很短。DISK_REPAIR_TIME这个参数控制可以恢复的时间长短，如果故障超过这个时间，Oracle将从diskgroup中drop这块盘。

比较有意思的问题，第一个是Oracle如何记录这些变化？文档中并没有明确说明，但是我猜测是用位图方式来实现，即用位图来标识哪个extent发生了变化，然后当故障恢复时同步这个extent即可，因为位图占用的空间很小，这样就可以记录很长时间的变化。第二个是如果整个磁盘都坏掉，换了一块新的磁盘，这时必须同步这个磁盘的所有内容，fast mirror resync就失效了。

2.Preferred mirror read

ASM中mirror有primary copy和secondary copy，ASM总是读primary copy的内容，但是ASM会将不同extent的primary和secondary copy放在不同的failure group中，比如extent 1的primary在failgroup1，secondary在failgroup2，而extent2则刚好相反，用这种方式来实现负载均衡。

Preferred mirror read可以控制Oracle优先读取某个failure group上的copy，这个特性在RAC上很有用，我们可以控制RAC的节点优先读取离自己最“近”的存储，我突发奇想，设计一个两节点的RAC系统，利用iscsi来共享自己的磁盘给对方，然后利用这个特性，控制每个节点去读自己的本地磁盘。

下图这个方案，我们选用两台PC server，没有共享的存储，每台PC24块盘，如果追求吞吐量，用SAS/SATA盘，如果追求IOPS，可以用ssd盘。用iscsi将本地磁盘输出给地方节点，形成共享存储，RAC节点间互连可以用直连或交换方式。ASM中分别将两个PC的磁盘定位为单独的failgroup，利用preferred mirror read，让每个节点优先读取自己的本地failgroup中的extent copy.

以上方案未经测试，纯属虚构，如果谁有兴趣，可以搭一个验证是否可行。

将山寨进行到底。

–EOF–

三十三了，我又老了一岁，他又长大了。

–EOF–

房子终于装修好了，十一回家把宝宝接回杭州了，又要开始忙他了。

Lonely Hearts

生活不管在什么阶段都有快乐有烦恼，所以享受生活吧。我觉得马云这句话挺好：开心工作，认真生活。

–EOF–

一直想买个定焦大光圈，D40上可以搭配的定焦头并不多，喜欢适马的30mmF1.4，无奈价格太高，银子太少。

今天在淘宝上淘了一个二手的，半价，成色稍微差点，不过只要成像好，旧就旧点吧。

还好老婆对我的各种败家行为，一直非常宽容，当然我也很支持她的各种败家行为。

哥玩得不是摄影，是寂寞！

–EOF– голова болит секс The Chair trailer голова болит секс

• голова болит секс

голова болит секс