分类归档: Database

Sun 收购 MySQL–要做 Web 2.0 的 Dot

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–

用 DBMS_STATS 构造 STATS 环境

保存表或者相关数据对象统计信息的历史数据是个不错的习惯。万一新的分析(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 新特性: DBMS_STATS 自动统计阀值修改

这是我的 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–

关于 Oracle 的 IO 响应能力: 10 毫秒的来历

最近在 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–