Entries tagged with “Database” from DBA notes

去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

--EOF--

《程序员》杂志 100 期约稿的稿件。这样比较"大"的话题我写起来并非顺手，而且只是从一个人所见的角度开写，难免贻笑方家。有所遗漏或者有失偏颇，拍砖即可。

2001 年对我自己来说，是一个比较重要的时间点--正式踏上工作岗位，也在这一年奠定了以后工作的技术方向。在 2001年，《程序员》杂志经过两期试刊后也已正式创刊。转眼间，杂志即将出版第 100 期，让人心生感慨。自己几年来持续关注数据库技术领域，《程序员》是一份很重要的参考信息来源。这里回顾一下自《程序员》创刊以来的数据库大事，算是一份纪念，或有谬误，敬请指正。

2001

就从 2001 年说起吧， 2001年6月的ORACLE OpenWorld大会中，ORACLE发布了ORACLE 9i。相比上一个主要版本，也就是 Oracle 8i来说，最大的新产品特性就是真实应用集群(Real Application Clusters, RAC）了。ORACLE 9i的RAC在TPC-C的基准测试中打破了数项记录，一时间业内瞩目。刚在上一年发布 SQL Server 2000 的微软在这一年产品上没什么更大的动作，正在积极拼抢市场。而 MySQL 在 1月份发布了 3.23 产品版，给不少开源爱好者以欣喜。

DB2 在这一年产品上没什么亮点，但是以 10 亿美金收购了 Informix 的数据库的事情震动业界。记得自己当时正好有个 Informix 项目要实施，着实看了几天 Informix 技术文档。这一年国内数据库领域的一件值得一提的小事是 ITpub.net 的创建，这个当初看似不起眼的论坛，在随后的几年中涌现出了一大批数据库技术人才，很大程度上在国内普及了 Oracle 数据库技术。

2002

IBM 推出DB2数据库V8.1的测试版，估计是还在消化 Infomix 的客户资源，几个月之后正式版才能面试。而 Oracle 与 Sun 庆祝了 20 年的合作伙伴关系。之后，Sun 不复 .com 大潮中的明星范儿，Oracle 因为全力支持 Linux 也与 Sun关系愈加微妙。Oracle Open World 第一次在国内举行，地点是北京，会议规格不低，Larry Ellison 在会上进行了主题演讲，此前，这位软件界的传奇人物已经来过中国数次了。[喜欢IT八卦的人可以搜索一下《IT江湖水也深》这篇文章。]

微软连续第二年没有对 SQL Server 发布新版本。

MySQL 发布 4.0 Beta 版。从 4.0 开始，InnoDB 正式成为 MySQL 的默认引擎。在 InnoDB 的基础上，MYSQL对于事务的处理能力有了极大提升。

2003

SQL:2003 发布。这个版本针对 SQL:99 的一些问题进行了改进，支持 XML，支持 Window 函数、Merge 语句等。随着，会看到各大数据库厂商纷纷宣布新的版本中对该标准的支持，这是他们一贯的姿态。

MySQL 4.0 正式发布。在全文索引、嵌入式应用方面得到增强。这个时候的 MySQL 仍然缺乏一些企业级数据库的关键功能。

Oracle 这一年发布了 Oracle 10g， g 代表 Grid ，网格计算。这一年中"网格计算"火爆程度不亚于现在的"云计算"，随后的几年，这个网格计算基本上还只存在于专家们的嘴里。所以，去年 Larry Ellison 在会议上对"云计算"表示不屑也是正常之举。在这一年，Oracle 也宣布针对Linux 64位环境的产品准备就绪，接下来的一年里，Oracle 宣称雇佣了近万人的 Linux 相关的开发人员，可谓不惜血本，当然，这些投入在日后得到了超值回报。从技术的角度上看，其贡献也是有目共睹的，在 I/O 能力、进程扩展能力上都作出很大贡献。

雅虎技术人何伟平的一篇《PostgreSQL 昨天,今天和明天》对于 PostgreSQL 的普及起到了很大作用。

2004

Danga Interactive 针对 LiveJournal.com 开发的Memcached 经过上一年的高频度发布，在这一年只发布了一个版本，标志着已经进入相对稳定阶段，只可惜养在深闺人未必识。关注者并不多。以此为滥觞，伴随着Web 2.0 的火热，类似的分布式对象缓存系统层出不穷，到现在已经成了各大网站标准配备。Memcached 的出现对于数据库方面相关应用设计也带来了更多思路。

这一年嵌入式数据库 SQLite 迎来了较大发展，版本3 完成开发并发布了稳定版。 这些努力为 SQLLite 获得 2005 Open Source Award 打下很好的基础。

我自己第一次给技术杂志投稿《书写历史的甲骨文》，当然是发在《程序员》。

2005

PostgreSQL 8.0 的发布宣告正式开始支持 Windows 平台，成为真正意义上的 Windows 平台数据库（Native Server）。这是 PostgreSQL 发展史上相当重要的一件大事。

微软时隔五年，终于发布了 SQL Server 新版，是为 SQL Server 2005。最大亮点在于对 XML 数据的支持，当时不少技术媒体对此都颇为关注。IBM 发布 DB2 V8.2。

Oracle发布了Oracle10g R2 版本，10g 的 R1 版本稳定性广为诟病，R2版本质量有很大增强，一部分用户终于可以放心一点从 9i 升级到 10g。10月，Oracle 抄了MySQL 后路，将 InnoDB 收归帐下。几年过去回头看，Oracle 此举对 MySQL 影响太大，直到现在，MySQL 也没能自己拥有一个超越 InnoDB 的存储引擎，当然，也不可能超出 InnoDB 的在线备份功能。历史不容假设，否则的话，或许 MySQL 最后仍将独立发展也说不定。 MySQL 在这一年发布5.0 Beta版，引入数个新特性，比如存储过程、触发器等，而这些其实是其他主流商业数据库早已实现的功能，从这个角度上看，MySQL和其竞争对手比较，仍然是追赶者，甚至也落后于开源兄弟 PostgreSQL。

2006

IBM 在这一年发布了DB2 V9 ，最大特性是加入了 PureXML 支持。IBM 对 XML 方面寄予厚望，不过时间证明，XML 对于数据库市场的影响并没有那么大。

在嵌入式数据库方面，Oracle 收购 Berkeley DB 的母公司 Sleepycat Software。到此，MySQL 两个最重要的存储引擎都控制在 Oracle 手里(Falcon 引擎开发进度遥遥无期，最后不了了之)，尽管现在来看关系并未僵化，但谁也说不好未来能怎样。Oracle也宣布推出Enterprise Linux，进军操作系统市场，开始和 Linux 厂商之间展开竞争又合作的关系。

SQL:2006发布，继续增强 XML方面的特性。Ingres，这个早期数据库流派的标识产品，以GPL版权形式开放代码。

2007

Oracle 发布 11g 数据库，引入物理 Data Guard 算是最大新功能。MySQL 的拥趸者要偷笑，其实 MySQL 的 Slave DB早就可以在恢复的同时提供查询的能力了。MySQL 宣布将对 5.0 提供两个变种，社区服务器(Community Server)与企业服务器(Enterprise Server)，后者发布周期为1月一次，而社区服务器发布周期则不固定。

随着 Firefox 的发行量增加，其内嵌的SQLite 也赢得了大量部署用户。如果单纯从部署数量来看，SQLite 倒也堪称最流行的DB。

2008

2008年数据库领域的最大的事件，是 Sun 收购 MySQL，价格 10 亿美元。一年多时间过去，回头来看，这次收购对于 MySQL 不是什么好事情。年尾，MySQL 发布 5.1 生产版，质量并不好，引起了不小争议。在这个版本中正式提供对分区(Partition)功能的支持。此外，在这一年中，开源社区对于 给MySQL 贡献的补丁和各种解决方案让人眼花缭乱，是可喜之事。Google 和 Facebook 等大站都对 MySQL 作出不小的贡献。

微软发布 SQL Server 2008，没有提供什么更扎眼的功能。其实关系数据库发展到现在，要想作出更大革新已经是几乎不可能的事情了。对于微软来说，Windows平台上 SQL Server 有其压倒性优势，可时过境迁，一方面的优势演变成了其他平台上的劣势。

PostgreSQL 8.3 发布，应该说从2008年开始，PostgreSQL 在市场上表现已经不容小视，以其为基础的集群BI系统 GreenPlum 已经引起了国内不少用户的关注。

SQL 标准SQL:2008 发布。从SQL:99 到 SQL:2009，可以看到标准修订的周期越来越短，多少也反映了对技术的需求之快。

2009

到现在为止，这篇文章还缺席 Sybase 的信息。必须要提一下的是，Sybase 将在3月份公布其列数据库(Column-based Database)的新版本：Sybase IQ 15 。说起来，Sybase 也是传统数据库厂商中唯一提供列数据库的公司。

此外，在云计算应用下涌现出的非关系型数据库(主要是Key/Value存储)产品渐欲迷人眼，有人在疑惑关系数据库已到末日。"关系数据库已死" 每隔几年就会有人跳出来喊，对关系型数据库(RDBMS)来说，百足之虫，死而不僵。

不是总结的总结

以上只是软件行业发展过程中的一个小小的阶段。如果要做点总结的话，我觉得这几年的值得探讨的一个地方就是 MySQL 的发展模式，从最初的近乎玩具的软件到现在对业界举足轻重的产品，其发展途径值得我们深思。反观国内，我们也有一些所谓的国产数据库，投入重金，多半昙花一现，恐怕技术因素不是主要问题吧?

补充1) 应该说，时间就是善于和人开玩笑。这篇文章写完不久，就传来 Sun 被 Oracle 收购的消息。尽管现在还不能断定收购一定能完成，但这毕竟宣告了有关数据库技术的一个转折点。现在无从判断 MySQL 究竟发展方向如何，也或许，MySQL 的命运掌握在广大用户的手中。

补充2) 其实我非常想写一下"国产数据库"，但出于某种原因考虑，还是放弃了。长期以来，那似乎是和我接触的数据库圈子并行的一个轨道。想来想去，还是不要徒增烦恼了吧。

补充3) 这是个变革的时代，新的数据库产品层出不穷。"乱花渐欲迷人眼"。

补充4) 这篇文章和我参与翻译的 Troubleshooting Oracle Performance 一书，似乎可以用来小声的宣布一件事，那就是我关注的技术领域重心早已不再是数据库了。再见，Database !

--EOF--

前段时间因为写稿的缘故回顾了一下过去几年来的 SQL 标准的事儿。如果不考虑太久远的 SQL/92(SQL2) 的话，那么自从 SQL:99 之后，SQL 标准一共发布了三版。

SQL:2003

这个版本针对 SQL:99 的一些问题进行了改进，支持 XML，支持 Window 函数、Merge 语句等。对于 Merge 语句，很多从事数据仓库的朋友耳熟能详了。这个东西也是先有了事实标准然后纳入规范的。且说 SQL:99 发布后，各大数据库厂商纷纷宣布新的版本中对该标准的支持，这是他们一贯的姿态。

SQL:2006

继续增强 XML方面的特性。这个版本发布后，几乎没什么动静。增强 XML 对数据处理的能力。实际上，至少在现在应用中发现 XML 多少让大家都高估了它，也或许背后有商业力量驱动吧。有几家公司不是要凭借 XML DB 超越对手来着?

SQL:2008

去年发布的。几乎没看到有技术圈子的人讨论这个事情。这个版本其实还是和 XML 较劲。从SQL:99 到 SQL:2008，可以看到标准修订的周期越来越短，多少也反映了对技术的需求变化之快。

--EOF--

此为《程序员》杂志投稿。应该刊登在 2009 年第二期。

"预测"不是件容易的事儿，"回顾"就好操作的多。2008 年发生了很多大事，相比之下，数据库技术领域的这些事儿多少有些微不足道。

0) Sun 收购 MySQL

2008 年初第一笔业界大并购，在上一波.com 大潮中 Sun 赚得盆满钵满，在这一波 Web 2.0 大潮中，Sun 还要做 Web 2.0 中的这个"点"(Dot)? 我个人对此并不看好。

这是今年数据库领域的最大的事件，但也仅此而已，一年下来，MySQL 联合创始人 David Axmark 都因为"痛恨每天都要遵守的各种制度"从而离开了 Sun ，而到目前为止也没看到 Sun 针对 MySQL有什么新东西拿出来，倒是狂推预装了各项软件的硬件盒子。前不久发布的 MySQL 5.1 GA 质量更无法让人满意，很多 MySQL 旧将纷纷抱怨，连著名的 MySQL Performance Blog 也不失时机的抛出"MySQL 质量将不再如昔"的论断，大浇冷水。

1) Amazon 推出 SimpleDB

云计算喊了一整年， Amazon 也没闲着，不停地推出新服务。SimpleDB 服务让Jeff Bezos 把手伸向数据库服务，现在仍看不到该服务有大行其道的趋势，但是"提供数据索引与查询的核心数据库功能的 Web 服务" 无疑会逐渐吸引更多潜在的用户。到了年底，Amazon 干脆打出了在一段时间内 SimpleDB 免费的服务来招徕用户，用心良苦。

最近若干分析家下了论断 "未来网络产业将仅剩亚马逊与 Google 两强相争"，的确，Amazon 的技术实力不容小视，在 2009 年相信有更多精彩。

2) 主流存储厂商试水 SSD

让人没料到的是 EMC 作为业界存储领头羊，会率先推出支持 固态硬盘(Solid-State Drives, SSD) 的存储设备，Sun 、HP 等厂商也都不甘落后，纷纷宣布将拥抱 SSD。确实，SSD 的某些特性表现是如此抢眼，很多 DBA 都等着它来解决或者缓解 I/O 问题呢，毕竟这是近年来能看到的最大的硬件领域的突破。"钱能解决的问题就不是技术问题"，可惜，目前光有钱，买回来的 SSD 可能还是解决不了问题。SSD 的可擦写次数问题仍然让很多用户心下狐疑。

相信2009 年会是 SSD 爆发的一年，主流存储厂商都会纷纷推出支持 SSD 的产品。假以时日，SSD 应该不负众望。

3) Oracle 联手 HP 进军硬件领域

今年 Oracle 整体在 DB 方面实在没什么亮点，如果非要说有，那么在 Open World 上亮相的 Exadata Storage Server 倒是值得一提。

微软和 IBM 这一年来尽管都有升级产品推出，但实际上也就是升级产品推出而已，仍看不出什么新生机。其实很多用户已经非常厌倦不停地增加新功能的软件新版本，每发布一个版本不失时机的宣布打破什么 TPC-C 记录之类的事情已经难以引起用户兴奋。如何在廉价硬件上实现大规模平滑扩展是所有的数据库厂商必须要面对的问题。

4）面向列存储的数据库技术

面向列的数据库(Column-Oriented Database)这不是什么新技术，但是非常适合某些数据分析或者统计类的应用需求。常见的RDBMS 都是面向行（Row-Oriented Database）存储的，在对某一列汇总计算的时候几乎不可避免的要进行额外的 I/O 寻址扫描，而面向列存储的DB 能够连续进行 I/O 操作，减少了 I/O 开销，从而达到数量级上的性能提升。

其实在 Google BigTable / Hadoop HBase 中很早就看到这一思想的运用，在过去这一年中，列存储数据库也更多的引起了重视。

5) GreenPlum= MapReduce + SQL

MapReduce ，让很多面向数据分析的 DBA 还是挺眼馋的，GreenPlum 的出现把 MapReduce 和 SQL 有机的衔接起来，给海量数据分析能力带来了新的可能。年末的时候， GreenPlum 又宣布进军中国市场，不知道用户实际接受程度如何。

顺便说一下，GreenPlum 背后的大东家是 Sun。

6) 从 Drizzle 到 Percona XtraDB 存储引擎

MySQL 的生命力不在大公司手中，而是来自开源技术、Web 2.0 网站的需求上。Drizzle 这个"精简 MySQL" 版本的出现多少证明了这一点。Percona XtraDB 存储引擎的推出也值得 MySQL DBA 惊喜。

除此之外，DRBD、MySQL Proxy 与 Memcached 等 MySQL 相关组件的灵活搭配与定制，给用户解决超大规模应用上带来了更大的可能。数据库市场不可能不受经济危机的影响，商业数据库厂商日子要吃紧是可以想见的事情。

7）Hadoop 的生命力

Yahoo! 公司在 2008 年表现不佳，但是 Yahoo! 支持的 Hadoop 项目可是左右逢源，再一次让我们认识到开放带来的生命力。Facebook、Amazon、AOL、阿里巴巴等公司（当然也包括 Yahoo!）都在纷纷构建 Hadoop 集群来解决大规模数据处理与分析问题!。期待在 2009 年 Doug Cutting，这位 Hadoop 项目的带头人不要被 Google 挖角。

N）2009 年会怎么样? 谁知道呢。

--EOF--

后记：这算是 2008 年末的时候数据库技术小观察吧。因为投稿的缘故，现在才发出来。在过去这短时间里，自己一些观点可能也有所变化。如有时间，再做补充或者修订。请注意该文的时效性。

补充：对于 SSD，最近一件重要的事件是 Steve Wozniak 加入了 SSD 厂商 Fusion-IO

作者：孙毓波 (AKCMS 作者)

SQLite 是一个类似Access的轻量级数据库系统，但是更小、更快、容量更大，并发更高。为什么说 SQLite 最适合做 CMS (内容管理系统)呢？并不是说其他数据库不好, Oracle、MySQL、SQLServer 也都是非常优秀的 DBS，只不过他们设计目标不同，特性不同，所以只有更适用某个应用场景，没有绝对的好坏之分。

我归纳的中小型站点的CMS的特点如下：

• 1、数据量不超过10万
• 2、日页面访问量不超过10万
• 3、 一部分网站全部生成静态页面，一部分网站实时查询数据库动态访问
• 4、 站长不懂技术，不懂得复杂的数据库维护，只会用 FTP 管理网站
• 5 、个人站点基本上是一个人管理，一般情况下只有一个人在访问后台，没有并发
• 6、 对数据库来说是读多写少，只有在站长访问后台的时候才会写入
• 7、 多运行于虚拟主机，大部分PHP主机均同时支持MySQL，小部分PHP主机需要单独购买MySQL，PHP+MySQL的主机价格较PHP主机价格高。 （以万网为例：最便宜的PHP空间780元，最便宜的PHP+MySQL的PHP空间1150元）
• 8、 多数中小站点的HTTP服务与MySQL部署在同一服务器上

SQLite 的优点在中小网站CMS应用场景下表现突出：

• 1、与MySQL相比，它更彻底的免费，并且没有任何使用上的限制
• 2、非常小巧，PHP5以上版本中无需任何配置即可支持SQLite
• 3、无需单独购买数据库服务，无服务器进程，配置成本为零
• 4、整个数据库存储在一个单个的文件中，数据导入导出备份恢复都是复制文件，维护难度为零
• 5、读速度快，在数据量不是很大的情况下速度较快，更重要的是：省掉了一次数据库远程链接没有复杂的权限验证，打开就能操作

SQLite的缺点在中小网站 CMS 应用场景下被规避：

• 1、并发低 动态访问时当访问量不超过10万PV的时候，SQLite 超过 Access 的并发能力已经绰绰有余；生成静态页后更无需考虑数据库的并发问题
• 2、在大数据量的情况下表现较差 但是中小站点一般情况下数据量不超过10万，而SQlite 在 100 万数据量之下表现还不错，因为省掉了对数据库服务器的远程连接甚至会更快
• 3、写入较慢 默认配置下的 SQlite 的写入速度比MySQL慢了很多，但是 CMS 应用场景的写入操作较少。在插入新文章的时候基本感受不到慢。集中的写数据库操作只有在安装的时候会出现，不过只出现一次，可以忽略
• 4、为已有的表加索引较慢 但是在中小站点CMS中不会有这样的需求，可以忽略
• 5、无法将 MySQL 部署到与前端机不同的服务器上，但是中小站点也没有分开部署的需求

综上所述：在中小站点 CMS 的应用场景下 SQLite 能最大限度的降低建站成本，降低维护难度，又很好得规避了自身的缺点。所以我认为未来支持 SQLite 的 CMS 系统一定会大行其道。

--EOF--

Fenng 注：这是网友来稿，转载请注明本文作者。刊载此文不代表我赞同文中所有观点。其实，我觉得 Berkeley DB 或许也不错。另外，如果一个 CMS 日访问量小于 10 万，通过一些 Web 前端优化，后端的压力就会非常之小。

RAID(Redundant Array of Independent Disks)，是现在 SAN 存储的非常核心的概念，可能很多朋友都熟悉的。这里介绍一个比较旧的新词：RAIDb 。所谓 RAIDb 也就是 Redundant Arrays of Inexpensive Databases (Db)。

RAIDb 其实是和 Sharding 技术概念有些地方是相通的。如果看概念上的验证还可以看 MySQL DRBD 的解决方案。 这个概念似乎较早见于 C-JDBC 的设计说明，不过近年来也被一些新的解决方案所引用。(比如sequoia）。

RAIDb-0

表级别. 类似数据库的分区，但 RAIDb-0 是不同表之间，RAIDb-0 不提供容错机制。RAIDb 控制器是整个 RAIDb 的核心。这一组件决定 RAIDb 的可靠性、可用性。

RAIDb-1

DB 的镜像或者复制。也是至少需要两个后端 DB 节点。具备容错机制。和 RAID-1 类似，写操作会慢一点。因为是全复制或者镜像，所以对存储空间的需求是比较大的。

RAIDb-2

部分复制，算是前两种方式的折衷。

RAIDb-1-0

RAIDb-0-1

示意图乍看起来是一样的，RAIDb-1-0 与 RAIDb-0-1 的主要差异在控制器(controller)上。

RAIDb 概念把数据库水平切分的思想抽象出来一个很好的模型。旧瓶装新酒，只要调制合理。

--EOF--

连续看到几个和 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--

偶然发现三年前的一个技术问题。当时比较匆忙，避免掉即过去了。现在 Metalink 上其实已经把这个问题作为一个 Bug 处理了。

问题描述：通过 JDBC 上来的 Java 查询应用，SQL 表现异常。表字段使用了 DATE 类型，针对该字段时间区域很小的范围查询(预期应该是走 INDEX RANGE SCAN)，在 SQL Map 上指定索引，发现无效。仍然是 FULL TABLE SCAN (FTS)。

罪魁祸首：setTimestamp() 把值绑定为 TIMESTAMP 类型，这样和 DATE 类型比较的时候，CBO 就会选择全表扫描。

通过 Trace 能观察到该异常行为。TIMESTAMP 在 Oracle 的 JDBC 9.2.0.1 上就有了，连续几个版本其实都有类似的问题。

解决办法：使用 setString() 而不是 setTimestamp() 方法。

这个故事告诉我们，Oracle 的 JDBC 驱动程序其实问题挺多的。同样，TIMESTAMP 潜在的问题也不少，尽管这个数据类型已经出现多时。

--EOF--

偶然看到 Tanel Poder 提到的一个 Metalink Note (438452.1): Performance Tools Quick Reference Guide 。这文档倒的确挺新，其中有几个工具值得关注一下。

LTOM：The Lite Onboard Monitor

Java 程序，定位是"实时诊断平台"。具有自动 Session 跟踪特性。另外具备自动 Hang 检测，自动数据收集等功能。该工具应该对于 Oracle 技能不太强的中小用户有比较大的帮助。但对于比较关键的系统，恐怕都不太放心跑一个 Java 程序在数据库上。

OPDG：Oracle Performance Diagnostic Guide

类似决策树的一个工具，访问的时候要打开个 Java 虚拟机，以我这样的网速根本访问不到(到了 22% 就停掉了) 。不知道等着着用这个工具的用户会急成什么样。

TRCANLZR：Trace Analyzer

格式化原始的 SQL Trace 数据，以 HTML 形式展现给用户。

HANGFG ：Hang file generator

用以收集系统 Hang 住时的状态信息。看来，Oracle 出问题比较多的时候还是系统 Hang 啊 :)

除了这几个，还有 STACKX ，用以分析 Core 文件的内容；还有以前大家都知道的 OS Watcher ，现在也做了一些改进。这个软件包基本上是 Unix 的那些传统的性能工具加上比较有好的图表展现脚本。

应该说随着 Oracle 开发、开放更多的性能相关的工具出来，对于有一定经验的 DBA 来说，会有个很好的辅助作用。对于经验不够丰富的用户来说，不是缺少工具，而是即使有性能数据，也不知道如何分析，如何定位。

--EOF--

偶然发现，Metalink 对于文档的关键字也是用 Hint 的方式, 哈

微软对 Yahoo! 的收购持久战可能让很多人都新闻疲劳了。但今天看到的这个关于 Yahoo！ 的技术新闻还是值得看一下的：Size matters: Yahoo claims 2-petabyte database is world's biggest, busiest 。Yahoo! 的 VP Waqar Hasan 在文中披露 Yahoo！的数据仓库当前容量为 2PB。用于分析每月5亿的用户访问行为，每天处理 240 亿次的事件，号称世界上单个最大、最忙的数据库。

尽管有的数据仓库容量要比雅虎的大。但那些 DB 或是存储非关系性数据，或是存储的压缩后的原始数据，不能进行即时分析，雅虎之前的也有数百 T 这样的数据。眼下 Yahoo！数据仓库存储的是结构化、可分析的数据。预计下一年可能膨胀到数十 PB 。eBay 号称数据总量有 6PB ， 不过根据一些消息来看，单个最大的 DB 只有 1.4 PB。

Yahoo! 在 2005 年买了一家叫 Mahat Technologies 的初创公司（就是 Waqar Hasan 操刀的)，这家公司以 PostgreSQL 数据库为基础，开发了一个新型 DB，其特点是 基于列 的而不是 基于行 的模式。不难理解，这样数据写入的速度会慢下来，但是读取的速度会快很多【去年的侠客行上，雷鸣在演讲的时候讲过他在百度的时候做的一个优化的例子。和这个思想非常相似，所以当时我说对我"有启发"】。Yahoo! 买了之后，对该产品进行了持续性的改进(内部代号: ELCARO ?) ，比如压缩，并行处理能力加强、优化查询等等特性的添加改进。而针对使用者的接口仍是 PostgreSQL 。这应该也算 PostgreSQL 在顶级企业又一个成功案例。

这么大的数据库并没有采用传统的 SMP 架构构建，而是采用普通 PC 作集群(用了不到 1000 台) 。很明显这是 Share Nothing 而不是 Share Storage 的 DB 集群。通过上述独特的设计方式，能够对此海量数据进行有效的分析，这是个不小的技术革新，也是与 Google Map Reduce 完全不同的计算模式。

让人感慨的是 关于世界上的超大数据库 一文中罗列的数据，现在看起来已经并不惊人了。以前总说信息爆炸，这个时代刚刚来临。

--EOF--

MySQL 爱好者关注的 2008 MySQL Conference & Expo 落幕后，很多文档都能看到了。今天读了一下这篇 Scaling Out MySQL: Hardware Today and Tomorrow。感兴趣的朋友也不防下载下来研究一下。

用什么样的硬件做 MySQL ，真不是三言两语能说清楚的。不过该讲座中还是能总结出来几点关键点的。

CPU 选择

首先如有可能就选择 64 位CPU，这样才可以安装 64 位操作系统，有了 64 位操作系统才能利用好更大的内存。如果非要抬杠的话，不是 64 位芯片也可以安装 64 位操作系统，也就是 Intel 的 EM64T 的解决方案(这也是文档中没提及的) 。

我个人倒是比较喜欢 AMD 64 位 CPU 的，物美价廉，性能也不错。

注意： MySQL 在多核上的 Bug 问题。

内存，来者不拒

第二点是尽可能配置比较大的内存，当然，只配置内存如果 MySQL 参数配置有问题，还是摆设，如何设置各个引擎的 Cache 相关参数，够写一本书的了。

现在市场上内存是越来越便宜了。我个人的感觉内存降价的程度比 CPU 和硬盘都夸张很多。所以，考虑到人力越来越贵，内存越来越便宜，配置服务器的时候就别太吝啬了。

硬盘--唯快不破

国内用 MySQL ，绝大多数都是直接仍在本机磁盘上的。这个磁盘的选择要慎重一点点。尽量选择 15K 而不要 10K 慢速磁盘，大多数数据库的磁盘问题都在速度上，如果只在磁盘上多花费 30%的钱而能得到总体性能的 30％收益，那么还是值得的，而容量多数情况下不会出现问题，现在的硬盘容量就是一个大。

至于选择什么类型的磁盘，SCSI 与 SAS 都可选，SATA 倒是够便宜，特定的应用再考虑吧。

这三板斧看是简单活，但是实际的应用场景下可未必就能做出更优的选择。最简单的东西也有人不知道不是?

--EOF--

一个很有意思的技术嫁接。Pythian 发布了一个 MySQL 插件，通过该插件，Oracle 10g 的 Enterprise Manager Grid Control 能够用来管理 MySQL 。

在 Oracle 10g 刚发布那会儿，EM 的地位在整个链条中倒是挺重要的，几年下来，似乎并没有占领多少市场。我个人觉得这个工具挺"重"的，倒是很少看到有 DBA 用这个工具。

尽管这个 MySQL 插件应用场景可能不多，但这还是第一次看到第三方给 Oracle EM 带来扩展能力。

比较关注即将召开的 The 2008 MySQL Conference & Expo，Sun 收购 MySQL 之后第一次大规模亮相，能带来什么? 新版本的特性基本了解了，还有呢?

Updated: InnoDB Plugin 1.0 for MySQL 5.1 也需要关注一下。

--EOF--

今天在无聊的售前演示中看完了一篇技术文档 All About Oracle's In-Memory Undo，关于 Oracle 的 In-Memory Undo (IMU)，记得几年前讨论过，大部分基于猜测，这算是看到的第一篇比较细致的东西。

Oracle 公司在 10g 推出 IMU 这个特性（已经申请了专利）。Undo 作为最重要的组成部分之一，其高效与否直接关系到整个 DB 的能力。Undo 旧有的基于 Block 的段(Segment，指存储层的概念)管理模式方式，UNDO 本身的变化要记录到 Redo Log Buffer 里，而 IMU 避免了这个操作(因为是内存而不是存储)，从而减小了生成的 Redo 量。

另外，因为读一致性开销直接到了内存里而不再依赖存储段, 整体也大大降低，CPU 的负荷也会有效降低。其应用模式应该说是适合一致读的需求量比较大的 OLTP。

Oracle 10g 默认是使用 IMU 这个特性的。通过隐含参数 _in_memory_undo 可以关闭这个特性。因为是隐含参数，也侧面反映出该特性并非那么成熟。搜索一下 Metalink，有不少关于 IMU 的 Bug，而 UNOD 的 Bug 一旦遇到，不停 DB 恐怕都很难解决。所以，对于可用性要求比较高的系统，现在起用该特性还是需要三思。

附: 全部机制在专利全文里。谁有兴趣仔细读一下吧.

--EOF--

从 Laurent Schneider 的 Blog 看到信息，Oracle 10gR2 的第三个 PatchSet 10.2.0.4 已经出来了。虽然还没有正式宣布，但是在 Metalink 上已经能够看到 Linux 平台的了。PatchSet 号码为：6810189 。

现在 Oracle 的 PatchSet 出来的顺序基本上还是 Linux 是第一个，也反应了某种趋势。若干年前都是 Solaris 平台 上最早出来的，现在都变成 Linux 了，操作系统的流行变迁可见一斑。原来传言说 2007 年年底会发布的 ，还是拖到了现在才看到，难道 Oracle 的开发力量都投入 11g 上面去了?

有意思的是，10.2.0.4 Patch Set - List of Bug Fixes by Problem Type 这个列表下仍然写着 “Please note that 10.2.0.4 has not been released on any platform , and does not have release dates available" 。可见 Oracle 内部对文档的更新也是比较乱的。

期待这个版本在修复众多 Bug 的同时不要引入新的 Bug 了，Oracle 10g 在稳定性上还是不能让人放心，淘宝的兄弟们最近就因为 ASM 的 Bug 而折腾了一回。。11g 会好一些么?

对于 DBA ，尤其是 Oracle DBA 来说，厂商发布一个新的 PatchSet 要比发布一个新的版本来的更为实惠一些，因为前者面向解决现有存在的 Bug 问题。新的版本只会引入更多的问题。

--EOF--

有句俗话说的好，”当你手里拿着锤子的时候，整个世界都成了钉子“，数据库理论专家 David DeWitt 也闹这毛病，他的这篇 MapReduce: A major step backwards 差不多快成最近几天技术圈子的一个笑料了，连久不更新的汪海都来了兴致写了一篇评论。

有的时候我怀疑是不是国外这些学院派的教授也和国内这些老学究差不多，固步自封? 估计 David DeWitt 被一群实践派的后生小子当作笑话消遣肯定很恼火，期待他后续的回击。其实话说回来，RDBMS 理论这么多年来基本上也就是搞些"老树成精"的研究，真正转入实际应用的理论怕是真不多，VLDB、BI 方面貌似繁荣，其实也就那么回事。就拿 Oracle 来说（汪海说了：千万不要对自己不熟悉的东西妄加评论），在这几年的 VLDB Endowment 上，发布的论文寥寥。实际在产品中起用的技术就更少了。

2008 年 IT 业第一个大收购: Sun 宣布 10 亿美元收购 MySQL AB, 8 亿现金加上 2 亿股票，MySQL 把自己卖掉了。

MySQL 最近几年一直喊着要 IPO 来着，谁知道突然甩手把自己卖掉了。难道 MySQL 就这么大一点志向么? 还是投资者急于套现? "LAMP" 的 "M" 以后是 Sun 家的了，Sun 能否把 “LAMP" 变成 "SAMP" ? S-Solaris，这恐怕只能是个假设而已, Solaris 在开放上慢了一步，这一步可就被 Linux 甩的太远了。

话说回来, Sun 这几年可真的是日薄西山。这笔买卖恐怕也是“驴粪蛋--表面光”，真正能带来多少收益恐怕天知道，要知道 MySQL 07 年的收入恐怕也就是 5 千万上下。Sun 一向是活雷锋, Java 造福了这么多公司，就自己不赚钱。希望能继续发扬该精神，让 MySQL 能够继续为 Web 2.0 公司提供数据支撑，要知道现在的 Web 2.0 公司至少有 9 成都在大量使用 MySQL 啊。哦，难不成 Sun 是看中了这块的硬件市场?

Sun 会继续保持 MySQL 开源，这是毫无疑问的。但我也相信众多 MySQL 用户这下子要考虑一下使用策略了。

MengYan 提醒我说 "别忘了 Sun 要做 .com 中的那个 Dot "，的确，当年的 .com 大潮中，Sun 风头无两；这么一说，Sun 的意图就比较明显了，这回Sun 要做 Web 2.0 中的这个 Dot.

--EOF--

Amazon 真是酷到家了。在 S3 和 EC2 之后又搞出来一个 SimpleDB™ 。Amazon 一手构造的计算环境中现在又加上了数据库，真是很有想象力的项目。

在 Web Service 上，Amazon 可以说是身体力行，领跑多年。S3 解决海量数据(非结构化)托管问题(虽然当下也是赔本赚吆喝)，EC2 解决企业计算问题，SimpleDB™ 则针对结构化数据查询的解决方案，目前已经能够提供数据库的一些核心功能。对用户来说，你不再需要针对数据库的复杂的维护工作，也就是可以不用数据库管理员( DBA ) 了 。当然，DBA 也不用担心，这个工种不会消失，SimpleDB™ 针对的买方是那些只需用简单的关系型数据的 Web 项目，传统的 RDBMS 功能复杂，但是很多小项目其实只是用到一些核心的功能而已，如大家常说的增、删、改、查，这或许也是帕累托法则的运用吧。

RDBMS 当然不会消亡，SimpleDB™ 是 RDBMS 的竞争对手，也是 RDBMS 的一个补充(我非常奇怪为什么不叫做 WebDB，嘿)。从这一点上说，SimpleDB™ 还是开启了一片蓝海，只是海水比较深，没有足够技术船也过不去。

--EOF--

BTW: 虽然这个消息已经被很多人写了，我还是想写一下，毕竟这也是关于 DB 的事情

Updated: 小道消息，”SimpleDB stuff is Erlang on top BerkleyDB“，如果这么说，或许 Oracle 偷着乐呢

经常要对一些新存储系统进行 I/O Benchmark 测试，每次测试又有可能针对不同的目的，但基本也都是围绕数据库转悠，心血来潮，对几个常见的工具做个比较。

(点击查看全图)

要强调的几点: ORION --Oracle I/O Numbers Calibration Tool 还是比较全面的针对数据库应用的 IO 测试工具。现在 Oracle 发布了不少平台的移植版本。该工具也比较好用。

数据库应用必需要考虑异步 I/O 的因素，否则结果会有很大偏差，当然如果只测试存储能力的话，到可以忽略。AIO 压力测试可以考虑以下 AIO-Stress

Unix 命令 dd 虽然很土，但还是一个测试 I/O 的基本手段和方法.有的时候即使没别的工具只用它也能发现很多问题。另外一个需要注意的就是字符设备和块设备的差别啦。更新: 就当我说得是 GNU dd 吧，谢谢下面留言的朋友。

有些工具因为用过很久了，记忆难免有问题，表格中会有误导。仅供参考。今天太累，等有空继续补充内容。

--EOF--

BTW: 我收集的关于 Benchmark 的书签 内容。

尽管是世界上最大的图片服务网站, Fotolog.com 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起 Flickr. 但实际上 Fotolog 也的确是很猛的, Alexa 上的排名一直在 Flickr 前面, 目前注册用户超过 1100 万. 而前不久也卖了一个好价钱, 9000 万美金. 算下来的话, 1 个注册用户大约 9 美金. Yupoo 的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.

在前不久的 MySQL Con 2007 上, Fotolog 的 DBA Farhan Mashraqi 披露了一些技术信息.（PPT下载)

与其他大多数 Web 2.0 公司普遍用 Linux 不同的是, Fotolog 的操作系统用的是 Solaris . Solaris X86 也是免费的, 估计是维护人员更熟悉 Solaris 的操作系统而作出的选择吧.

数据库当然是使用 MySQL. 有32 台之多, 最开始的存储引擎是 MyISAM ,后来转向 InnoDB. 对于 DB HA , 使用 DRBD (介绍)，在 Solaris 上用 MySQL ,有个优化技巧是关于 time(2) 系统调用的，通过调用比 gethrestime() 更快的 gethrtime(3C) 来提高性能。可以通过设置 LD_PRELOAD (32位的平台) 或 LD_PRELOAD_64 来做到。详细信息可以参考Sun 站点上的这篇 MySQL 优化文章，很有参考价值。

存储也是值得一说的，Fotolog 用的是 SAN，还是比较贵的 SAN: 3Par. 这个产品可能绝大多数 DBA 是比较陌生的，该产品原来主打金融市场，现在也有很多 Web 公司使用，一个比较典型的客户代表是 MySpace。3Par 的最大的特点就是 Thin Provisioning。Thin Provisioning 这个词有的人翻译为"自动精简配置"，在维基百科的定义：

Thin provisioningis a mechanism that applies to large-scale centralized computer disk storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.

说白了就是对空间分配能够做到"按需分配"。有些扯远了。

--EOF--

如果用关键字 "MySQL 迁移 Oracle" 在网上搜索，基本上得到的内容都是关于从 Oracle 如何迁移到 MySQL 的，而从 MySQL 迁移到 Oracle 的信息则少之又少。

抛开那些手工一点点做的方法不谈，网络上也可以找到一些第三方工具来做这个事情，免费的? 我只找到了一个，那就是 Oracle SQL Developer 了。如果采用比较傻瓜化的方法，不妨考虑这个工具。在这个工具之前，Oracle 提供了单独的 Migration Workbench 工具。在 SQL Developer 1.2 版中，Oracle 干脆把这个功能集成进来。

数据流示意图:

Source Database(MySQL/DB2 etc.) --->SQL Developer (ETL)-->Target Database (Oracle)

MySQL JDBC 下载地址：

http://dev.mysql.com/downloads/connector/j/5.0.html

配置 MySQL JDBC:

还需要注意一点就是需要调整一下迁移时候的参数:

剩下的事情就简单了，配置到不同数据库以及准备存放 Metadata 数据库的信息。然后就可以迁移了。不赘述。

这个方法只是够傻瓜化，由于运行机制的限制，速度不是非常好。对于迁移过程中产生的变化数据，也无能为力。

--EOF--