今天不知道是什么日子，又一个震撼业界的消息，大胃王 Oracle 收购 BEA。
正在走下坡路的 BEA 算是卖出了合适的价钱。原来自己估价的 82 亿美元，倒是误差不大。不过我倒是真的看不出 Oracle 收购 BEA 有什么必要，应用服务器市场也就那么大嘛，收购 RedHat 不是更物美价廉么? 前几天我写帖子预测 Oracle 会出现财务危机，看来只能算是信口胡说了啊。
照这样下去，应用软件市场也就是能剩下几个巨头了，IBM、微软、Oracle，扳着手指头就能算过来了，对了，还有 SAP，前几天刚用 68 亿美元收购了 BO。说白了，还是有钱公司的财富游戏。
–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–