今天在无聊的售前演示中看完了一篇技术文档 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--

前几天在 Blog 里提到答应了 Piner（陈吉平) 要给他的新书《构建 Oracle 高可用环境--企业级高可用数据库架构、实战与经验总结》写篇书评。书是拿到了多日了，断断续续再看，一直没看完。

首先恭喜一下 Piner 的新书终于顺利出版，写一部书本是一件不容易的事情，也一本有质量的书就更难上加难了。也恭喜一下博文视点顺利拿下这本书，装帧质量的确不错，相信读者也会对此满意。记得好几年前 Piner 最早在 CSDN 论坛数据库版灌水，签名经常写着"弱水三千，只取一瓢饮"，灌水地移师 ITPub 后没多久我就注意到了这个家伙。那个时候他就经常发一些总结的很好的技术文档(可见写作能力早早就开始培养了)，新书的出版也是他厚积薄发的体现。

做 DBA 久了，有时也难免动一动写书的念头，可面对 Thomas Kyte 、Lewis 这些大师的书，真有些"眼前有书写不得，大师图书在上头"的感觉。但是《构建 Oracle 高可用环境》没有作无意义的重复，就内容上，可以说是独辟蹊径。有些章节堪称填补了 Oracle 技术图书的空白，比如第 10 章的 "高可用环境下数据迁移" 与第 16 章的"高可用环境监控架构设计" 都是前人所未能阐述的东西，对很多 DBA 来说，似乎是隔了一层窗户纸，可实际上，能够有功力捅破窗户纸可不是容易的事情，没有足够的经验写不出来，只有经验而没有总览全局怕是也写不出来。

身为国内最大电子商务网站的首席 DBA，"经验总结" 毫无疑问会让无数 DBA 心痒，到底淘宝的数据库是怎么维护的? (我就时不时的去偷师借鉴经验)。不只是 DBA 应该看这本书，架构师、技术经理都应该是这本书的读者。通过本书由点及面的阐述，能够树立一个以 DB 为核心的架构观，进一步理解企业信息技术体系，增强实践技能。

我会向 DBA 推荐本书(建议春节期间就买本回家看)。《构建 Oracle 高可用环境》将会是 2008 年中文图书市场比较重要的一本数据库类图书。

(最后挑个小毛病：建议批量数据更新的处理策略能够用 "Bulk Collect"方法，Piner 似乎一直不喜欢这么用。)

--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--

保存表或者相关数据对象统计信息的历史数据是个不错的习惯。万一新的分析(ANALYZE 或者 DBMS_STATS) 过后发现统计信息有问题，急于恢复的时候又找不到备份，是个比较糟糕的事情。

虽然我在维护的过程中很少使用 DBMS_STATS 来收集数据对象统计信息，不过用这个工具来进行统计信息的管理还是很方便的。

首先建立资料库, DBMS_STATS 的具体语法暂且就跳过去了, 毕竟手册上写的更清楚)：

EXECUTE  DBMS_STATS.CREATE_STAT_TABLE ('SCOTT', 'STATTAB','SYSAUX'); 

在 SYSAUX 表空间上创建 STATTAB 用以存储统计信息, 所有者是 SCOTT 用户。

导出统计信息. (在任何可能更改表的统计信息的 DDL 操作之前, 一定要导出统计信息)

EXEC dbms_stats.EXPORT_SCHEMA_STATS
(ownname=>'scott',stattab=>'stattab',STATID=>'foo_20080107');

这里建议手动设定一下 STATID. STATID 命名规则建议用 对象名(SCHEMA名)+ 时间(注意粒度).

至于导入整个 SCHEMA 的信息，一定要慎重再慎重。

在任何可能更改表的统计信息的 DDL 操作之前, 导出(备份)统计信息

EXEC dbms_stats.export_table_stats
(OWNNAME=>'scott',TABNAME=>'foo',STATTAB=>'stattab',STATID=>'foo_20080107');

恢复该表的统计信息(之前要导出当前的统计信息):

EXEC dbms_stats.import_table_stats
(OWNNAME=>'scott',TABNAME=>'foo',STATTAB=>'stattab',STATID=>'foo_20080107');

为了避免误导，需要说明的是，我只收集表和索引的统计信息。尽量不用 DBMS_STATS 收集统计信息，要问为什么? 去看看 DBMS_STATS 相关的 Bug 就知道了(比如飞龙说的这个问题)。只有在 ANALYZE 力有未逮之时才会考虑用 DBMS_STATS.

这里说的 和 ADDM 无关，建议在熟知 ADDM 之前，最好别用这玩意儿。

--EOF--

这是我的 Oracle 11g 系列的文章之一(这一篇没啥含量，算是笔记吧)。

在 11g 之前的版本中，DBMS_STATS 自动统计收集(Automatic Statistics Gathering)默认的阀值是 10%, 这个 10% 是不可以修改的。这对千变万化的企业数据库来说环境来说，有些死板，如果是个超大的表，默认的 10% 数据也是海量了，会把整个资源占死。Oracle 11g 中，这个属性可以通过修改 STALE_PERCENT 属性来修改, 有全局（DBMS_STATS.SET_GLOBAL_PREFS ）和表级别（DBMS_STATS.SET_TABLE_PREFS）两种。

例子语句:

设定:SQL>  exec dbms_stats.set_table_prefs(null,'EMP','STALE_PERCENT',1);
修改为 1％. 范围从 1-100. 
恢复:
SQL> exec dbms_stats.set_table_prefs(null,'EMP','STALE_PERCENT',null);
查询:
SQL>  select dbms_stats.get_prefs('STALE_PERCENT',null,'EMP') from dual;

虽然我很少用 DBMS_STATS 收集数据对象统计信息，不过它的有些用途还真的不错。

Refer: Metalink Note:390737.1

--EOF--

最近在 ITpub 上有几个讨论 IO 的帖子很热闹，其中一个讨论中 Biti 说"响应时间在 10ms 左右能达到的最大 IOPS 能力，是系统 IO 能力的一个最重要指标" ,下面好多网友不知道这个 10ms 怎么来的，以及为什么是 10ms .

其实如果你熟读 Oracle 手册的话，你会发现 10g 中已经涉及到这个 “10ms” 的信息了，而且，侧面透漏出很多潜在的细节。

在 Oracle 10g 中有一个新的参数： DBIO_EXPECTED ，这个参数指 DB 平均读取一个 数据库块的时间，单位是毫秒(millisecond)。由 ADDM（ Automatic Database Diagnostics Monitor）用以分析系统 IO 性能的参考值。默认是 10ms ，之所以取这个值，是因为当前企业内投入使用的硬盘（存储）一般一个 IO 时间(读取一个 DB 块)大约在 10 ms 之下，超出 10 ms 一般意味着在 IO 跑得有点费劲了。这个 10ms 是个经验值，但这个经验值是有来由的。

有些慢速硬盘，比如希捷 Barracuda® ES.2，寻道时间接近 10毫秒，一些老一点的 SATA 盘肯定更慢了；而 Cheetah® 15K.5 则大约只是 3ms-4ms 的样子（DBA没事的时候不妨看看硬盘厂商的白皮书，挺好玩的)。一个 DB 系统上线时，测试一下 IO 基准能力还是必要的。注意测试的时候出现的"拐点"，意味着这个时候的 IO 响应时间是至关重要的，因为这个时候 IO 即使有应用Cache、 数据库 Cache、（主机 Cache）、存储 Cache，也还是有大量 IO 压在了后面的磁盘上，如果磁盘的 IO 到了峰值，IO 层的能力也就到了峰值了(特定响应时间下的最大 IOPS)。多数系统上，应该在 10ms 附近。所以，你盯着 DB 上离散读的平均响应时间，到了 10ms 意味着快撑不住了。

要如实使用 ADDM 衡量 IO 状况，DBIO_EXPECTED 参数还是需要作一点调整的。要注意这个参数并不是初始化参数，如果需要重新设定，则需要提交如下语句修改：

EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('ADDM', 'DBIO_EXPECTED', 4000);

上面的数值单位是微秒。

数据库 IO 是一个非常有意思的话题，本来想写一系列的东西。结果这篇写出来发现不伦不类。权作抛砖吧。

--EOF--