Tag Archives: Oracle

日落西山 – Oracle 收购 Sun

真是一种嘲讽，就在刚才，收到一封广告信，标题是 "Sun为企业发展提供更多动力"

对于 IT 产业来说，这是最好的时代，这是最坏的时代。Sun 要做 Web 2.0 中的这个 Dot 没做成，74 亿美金把自己卖掉了。

尽管我不是 Sun 的粉丝，还是感觉不太痛快。这次收购意味着又有若干产品有可能被打入冷宫。而大家比较关心的 MySQL 可谓命运不济，被 Sun 折腾一年多，在开源社区里面一点好没讨到，这回在 Oracle 新的产品线里面如何定位呢? will be an addition to Oracle’s existing suite of database products… 当然，InnoDB 这回和 MySQL 算是破镜重圆了。是否有其它变数，比如被原 MySQL 团队赎身出来? 难!

对于 Oracle 来说，这次自己终于有了硬件(SPARC)和操作系统(Solaris)这两块王牌，其实 Oracle 和 Sun 算是多年的合作伙伴了(超过 25 年)，相信整合起来可能问题不大。这次收购比较失败的可能就是 IBM 了，Oracle 这次给了竞争对手 IBM 以更大的压力。难道蓝色巨人出不起这个价格麽? 还是觉得足够鸡肋? Sun 手里的 Java 技术对于 IBM 的小型机是个很好的补充，想不通。再过几年，这可能就是 IBM 犯过的最大错误。

不痛快的除了 IBM ，恐怕还有 RedHat。不过别着急，没准儿哪天 Oracle 也把 RedHat 也一并收了，我相信 RedHat 手里的 JBoss 至少让 Oracle 眼馋不已。有 JBoss 在，其他中间件就不可能赚到更多。

一切皆有可能。其他事情不好确定，但有件事情还是能基本肯定，拉里·埃里森大叔这回又有机会体验一下世界首富的滋味了…

–EOF–
延伸阅读：

Troubleshooting Oracle Performance 一书翻译进展

近期在和几位同事一起翻译这本 Troubleshooting Oracle Performance (TOP)，这是2008 年国外 Oracle 相关书籍中唯一一本值得期待的作品。

本来撺掇同事童家旺写书，不过他谦虚到底，说宁愿翻译，而且一般的图书看不上，只对这本 TOP 感兴趣，家旺慧眼识珠，我也只得勉为其难，助他完成这事儿(其实我对这书也非常感兴趣)。翻译图书是吃力不讨好的活，考虑到各自工作也比较繁重，又拉来同事胡怡文，三个人乐观估计可以拿下这本厚达 600 页的大作。没想到几个月过去，还是耽误了进度不少–出版社估计已经准备扣稿费了 :)

这本书的作者Christian Antognini，对 Oracle 数据库的理解精深，凭借此书已经奠定 Oracle Guru 地位。其人也是 OakTable 的成员，说起 Oak Table ，这是一群 Oracle “科学家(Scientist)” 的圈子，没有几手绝活只凭忽悠那是不能位列其中的。

目前这本书已经倒了后期校稿阶段，近期准备放点样章上来供大家参考。翻译得是否得体，亦或佶屈聱牙，还请各位别吝惜手里的板砖，尽管拍来。

–EOF–

探析 Oracle 的 Exadata Storage Server

数据库巨头 Oracle 一向不怎么涉足硬件领域，但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ，另外一个叫做 HP Oracle Database Machine 。

Exadata Storage Server 架构分析

该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗，所以比较唬人。

如上图，是基于所谓的 Cell 的，每个 Cell 就是一个存储模块，乍看上去好像 HP 的 MSA 系列的东西，考虑到这东西能扩展能大柜子，又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式)，不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC，莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下，居然就是个 PC 服务器 ……

从上图大致能看出来，Oracle 主要的还是想卖软件，企业管理器、念念不忘的 Automatic Storage Management(ASM)，还有山寨版 RHEL –OEL 也在这个框架内。

名词解释：iDB

iDB – the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现，直接映射操作到存储，减小不必要的开销。如果 iDB 真的能有效提升 IO 能力，那这个产品还是值得一用的。每个 Cell 是有计算能力的，实际上相当于 DB 把 SQL 扔给 Cell， Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。

InfiniBand

Oracle 的 RAC 集群是 “Share Storage” 的，DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力，只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力，而 InfiniBand 交换机成了核心的组件。

实际上，InfiniBand 交换机的数量会是问题，只用一个，可靠性不高，用两个，成本又上去了。这个无疑会让用户左右摇摆。

HP Oracle Database Machine

相当于一个打包好了的产品，预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件，面向数据仓库环境。假想敌是 Teradata ?

结论

流水帐写了这么多，最后我个人认为该产品是否能被市场接受还要看定价，如果足够便宜，那么会有用户拿来做中低端的应用，如果 Oracle 必须要把内置的软件卖出价钱来，那恐怕竞争力并不是很强。

这并非一个会让人多么激动的产品。

–EOF–

附加：价格列表

Oracle CBO 的 _sort_elimination_cost_ratio 参数

连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。

如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询，会发现很多和该参数有关的 Bug ，执行计划的出错特征是也走了索引，但是走了索引全扫描(INDEX FULL SCAN)，如果做 10053 Trace ，会发现有个烦人的 Recost for ORDER BY 步骤，然后就会引到错误的执行计划上。

在 9i 升级到 10g 最容易遇到这个问题(原来好好的，到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发，更多的时候优化器模式是 FIRST ROWS — 这样 Oracle 会尽量消除排序，默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题：

ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5

其它可能的解决办法：对索引里面的排序保持和 SQL 里的 ORDER by 一致。

其实说白了，很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的，因为不具备普遍性，所以在某些版本中作为隐含参数出现。在生产数据库上，个别的时候启用隐含参数倒也不是不行的，只要明白了相应的隐含参数到底是干啥的就成了。

题外话：_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现，倒是感觉和 Oracle 内部代码管理有关，本来应该消除掉的，怎么后面的版本又跑了出来?

目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ，有中文译本：《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。

–EOF–