OLTP Database Machine with Sun FlashFire Technology

Oracle 的这个 “the World’s First OLTP Database Machine with Sun FlashFire Technology” 有些唬人。FlashFire 是个什么东西? 看名字有些像 SSD 产品。可能是 Sun 原来的 F5100 系列的产品，号称 1U 闪存阵列能达到 100 万 IOPS ，10 GB/秒吞吐，听起来足够强悍。(refer)

至于之前和 HP 合作的 Exadata 产品线看来要没戏了(因为芯片用得是 Intel 的)，个人不太看好Exadata ，总觉得会在公司角力中牺牲掉这个东西，何况技术上没有什么大的优势，尤其是 SSD 存储要起来的时候。

做个记号，等 Larry 大爷把谜底揭开后再补充…

–EOF–

更新：神秘兮兮的遮掩了好一段时间，原来还叫作 Exadata ，只不过是 Exadata 第二版。新的 Exadata 可以跑 OLTP，芯片就是 Intel Xeon (Nehalem) –我之前的猜测都不靠谱。至于软件方面，主要是 Oracle 11gR2 的新特性 Hybrid columnar 压缩有点意思，当然，这东西还不是彻底的列存储。

Jametong 同学推荐关于 Exadata 最权威的信息可以翻墙订阅：Kevin Closson’s Oracle Blog 。

更新：FlashFire 是 SLC（单层式储存）的 SSD 。可以与 ZFS 友好集成。(refer)

MySQL 大企业级应用可行性分析(之四)

如果你觉得 MySQL 不够好，那是因为你不会用。

这是以前开了头的一个话题，现在有了一点新的想法和变化，倒是可以记录一下和大家分享。

数据仓库解决方案

一般来说，一个企业随着不断快速发展，或许在数据库上的投入到后期反而不如数据仓库、商业智能上面的投入。在数据仓库解决方案上，MySQL + InfoBright (参考)是个不错的解决方案。在数据仓库亦或是海量数据处理方面，倒是有几个基于 PostgreSQL 的解决方案，其中之一就是 GreenPlum ，最近一段时间受到很多人的关注。但是总体来说，这些方案的成熟度还有待于时间的考验。

站内数据搜索友好–全文搜索引擎

这里的站内搜索友好是说数据库是否更利于技术人员开发站内搜索技术。MySQL 在这个方面还是可圈可点，因为借助于 Sphinx 之类的开源全文搜索引擎，很方便的就能搭建一个可用的站内搜索引擎，多快好省。对于 Oracle 或是 DB2 这样的产品来说，似乎没有特别好的搜索引擎。至少 Oracle 的全文搜索基本上没法开放给前台用户使用的。

MySQL 前途曲折

前两天，Oracle 面对漫天谣言悍然宣布将对 SPARC 平台和 Solaris 投入重金研发，但只字未提 MySQL ，这无疑会让人怀疑 MySQL 在 Oracle 内部是不受待见的。Oracle 会把 MySQL 剥离出去么？让其变成自己的敌人? 唯一能让我放心的是 MySQL 不会死去，毕竟有那么多的克隆已经在蓬勃发展了。

这个系列的话题，我只提供陈述，选择由你来决定。

–EOF–

Jonathan Lewis 对 TOP 一书的推荐序

Jonathan Lewis 是 Oracle RDBMS 领域的技术 Guru。
下文是他为 Troubleshooting Oracle Performance 一书所做的推荐序。提前贴出来分享一下。
这本书的中文翻译版(名字定为《Oracle性能诊断艺术》)已经排版结束，即将进入印刷厂。敬请期待。

大约在20年前我开始使用Oracle关系数据库，花费了大约3年时间我发现问题排查和优化以接近神秘莫测而著称。

有一个开发者的查询语句跑得不是很好，因此把它发送给DBA组。我在检查了执行计划、数据样本后指出可以通过对其中一个表添加一个索引而消除大多数开销。开发者的反应却是：”这是个小表，不需要索引。”（这种事情发生在使用Oracle RDBMS 6.0.36版本的那个时代，顺便提一下，那时候”短”表意味着不超过四个数据块长。）不管怎样，我还是创建了索引，查询快了30倍—-接下来的解释环节当然必不可少了。

性能排查并不需要魔法、魔术或是神话，而是依赖于理解、观察与解释。理查德•费曼曾说过，”理论再完美也没用，也和你多聪明无关。如果理论与实践不符，就是错的。”关于 Oracle 性能有太多的”理论”是错的，早就应该从你的大脑清除出去了—-Christian Antognini 就是帮你做这个事情的人。

在本书的开始，Christian Antognini描述了事物运行机制，该观察什么类型的症状，这些症状代表的含义。尤其是，他还鼓励你在观察与分析的时候要有条理并坚持相关的细节。只要采纳了这些建议，在性能问题出现的时候，你应该能够识别真正的问题，并用最合适的方式解决问题。

虽然这本书的每一页都值得仔细阅读，我还是认为不同的读者会以不同的方式从中受益。有些读者可能通过时时翻阅而获取某些特别的洞察力。比如我多年来一直试图就等高直方图这样的命名找出一个直接明确的原因，而当我读到第4章解释等高直方图的时侯，Christian的描述让我豁然开朗。

有些读者能找到某些特性的简短描述，这有助于他们理解Oracle实现该特性的缘由，并有助于推断在特定应用程序中的应用场景。第5章中的”安全视图融合(Secure View Merging)”即为一例。

其他读者可能会反复阅读本书的某一章节，以便透彻理解他们正在使用的一些特别重要的特性。我相信第9章关于分区的讨论扩展会让很多人读而再读。

这本书很有料，很值得阅读。谢谢你，Christian。

Jonathan Lewis

Jonathan Lewis 著有 Cost-based Oracle: Fundamentals，同样由Apress出版社出版。在他的Blog上http://jonathanlewis.wordpress.com 能找到更多的工作案例。

–EOF–

Oracle 11gR2 几个值得关注的新特性

读了一下 Oracle 11gR2 的新特性列表，发现几个新特性是值得关注的。
Support 4 KB Sector Disk Drives

为了更充分的利用容量，新一代的磁盘扇区趋向于用 4KB 的扇区而不是旧有的 512 byte 。如果就兼容模式，无疑会影响 I/O 性能。Oracle 11gR2 对 4KB 扇区的支持在 I/O 上是个很好的改进。以前的版本中，都是操作系统默认的大小(512 byte)。这个改进收益最大的可能就是 Redo Log 文件了，要知道 Redo 文件的写速度一直是一个潜在的 DB 瓶颈，现在终于可以指定 4K 而不是默认的 512 byte 了(通过指定 BLOCKSIZE 来替代操作系统依赖的扇区尺寸)。相信写入速度会好很多。

这个 4K ，真是个有趣的话题，还记得以前的 4K 偏移量的问题么?

ASM Cluster File System (ACFS)

Oracle 自己推 ASM 集群文件系统了。

Oracle Automatic Storage Management Storage Layers.gif

看看示意图就知道第三方的集群文件(比如Veritas)系统要受到影响.

Enable Sampling for Active Data Guard

本来 Active Data Guard 就是个很好的东西–在这一点上 Oracle 终于能做到和 MySQL 差不多了。现在 Active Data Guard 上支持了 ASH 性能采样。调查性能问题的时候，基本上不影响主生产库了。

Data Pump

对于 Data Pump ，可能做数据仓库的同学要注意了。现在Data Pump可以指定分区导出。而 Worker 进程也可以跨多个节点进行了。

另外对于 Flush Cache 的特性，我觉得成本太高了。开源的方案更靠谱一些。

走马观花了一下新特性，感觉有一些亮点，不过光有亮点如果用户不接受的话也没有用，谁让 Oracle 所有的新版本都是一堆 Bug 呢?

–EOF–

补充一个刚看到的：

IGNORE_ROW_ON_DUPKEY_INDEX Hint for INSERT Statement

这个也是 MySQL 之前有的功能…