最近观察到数据库服务器 $BDUMP 目录下频繁出现 Trace 文件,内容大致为:

Warning: lio_listio returned EAGAIN
Performance degradation may be seen.
Warning: lio_listio returned EAGAIN
Performance degradation may be seen.
Warning: lio_listio returned EAGAIN

搜索了一下, IBM 给的官方解释为:

If the maxreqs value is too low, then the following Oracle warning message might be returned: Warning: lio_listio returned EAGAIN. This warning message indicates a need to increase the maxreqs value. When performing file system I/O, a maxservers value that is too low can also indirectly cause this warning message

看到有 Blog 说 Oracle PL/SQL 经典图书 Oracle PL/SQL Programming 的作者 Steven Feuerstein 出了本新书, 这应该不算什么太新鲜的事情，新鲜的是: 这本图书是关于 MySQL 存储过程的! 新书的名字是 MySQL Stored Procedure Programming ， 出版商是 O'Reilly.

更值得注意的是, 第一作者是 Guy Harrison , 这位老兄是 Quest 软件的架构师(而 Quest 近年来也对 MySQL 的数据库工具推出了不少产品), 也是 Oracle SQL High-Performance Tuning 一书的作者。Oracle SQL High-Performance Tuning 在很长的一段时间内都曾经被一些 Oracle 优化专家推崇, 现在虽然有些过时, 但想起来没能被国内出版社及时引进, 仍然有些遗憾。

从 O'reilly 的宣传来看, 现在 Guy Harrison 的名头反而不如 Steven Feuerstein 响亮了(所以个别地方把 Steven 放到前面?), 也让人感慨.

同事中的几位大侠翻译了《Spring in Action》, 今天公司组织买了一些，"抢"到了一本。书是刚刚上市不久的--还热乎的呢 :)

有的同事看我也看 Java 方面的书，可能觉得比较好笑。其实，作为一个 DBA，如果要有效地与开发人员的沟通, 不熟悉系统中所用的框架, 就会吃力许多, 刚开始到目前的团队中工作的时候也偶尔会闹笑话. 自己想了解一些 J2EE 框架基本概念的念头也有好久了，正好趁着有资料，学习学习。

今天匆忙读了第四章"征服数据库", 有几点给我留下了比较深的印象.

1) 数据访问异常的划分很清晰; 应用排错的时候很容易定位到具体问题;
2) 通过一定的设置, 任何一个 SQL 都能够输出到 Log 里, 对于 DBA 的优化调试非常有帮助;
3) 对 DAO 层数据库访问很容易隔离; 一部分程序员可以不用太关心数据库层, 而把这一部分的诸如效率、稳定性交给 DBA 处理;　也的确如书中所说简化了应用系统的复杂度并能提高开发效率;
4) 可重用的 DAO. 对于 DBA 来说, 应该注意因为 DAO 重用有的时候可能会带来一些多余的 SQL 解析. 在 Tuning 的时候需要注意。

我对 Java 一窍不通, 有理解不对的地方请读者指正!

在豆瓣上创建了一个豆列: Oracle 优秀图书.

这些图书中, Practical Oracle 8i 与 Oracle8i Internal Services for Waits, Latches, Locks, and Memory 被国内的大多数出版社认为是过期的东西, 不进行引进. Oracle Insights 似乎没有引起出版社注意.

Oracle Wait Interface 与 Effective Oracle by Design 已经有了中文版. 没有阅读过中文版本,不知道翻译质量如何. Oracle Wait Interface 的电子版满天飞, 因为索引的存在, 搜索更为方便一些. 这本书的中文版如果没有索引是不可想像的.

Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions 这一本应该在翻译之中. Tom 的那本旧书就不加在这个列表中了.

昨天我提到过, The Search for Intelligent Life in the Cost-Based Optimizer 是最经典的两篇关于 CBO 的文档之一. 有朋友问我, 另外一篇是什么?

其实我说的另一篇就是 Wolfgang Breitling 的 A Look under the Hood of CBO: The 10053 Event. 这篇文档最早出现在 2002 年,如同名字暗示的,内容重点在 10053 事件的解释上.反复阅读之后, 相信对 CBO 已经有所理解的朋友都能够利用这篇文档中的信息对跟踪文件的信息进行解释了.Wolfgang Breitling 还写了很多关于 Oracle 优化器的论文. 喜欢研究的朋友不妨找找这些文章的漏洞.

"大家帮我看看这个Statspack吧!" -- 如果你去一些中文的数据库论坛,你会发现这个请求出现的非常的频繁. 一些朋友可能知道通过 Statspack 来进行数据库优化,可面对报告的各项指标却不知如何下手.
在这里介绍一点关于 Statspack 的技术资源.

Performance Diagnostics using STATSPACK data 作者是:Mary Crystal 与 Tim Gorman . (Tim Gorman 就是 The Search for Intelligent Life in the Cost-Based Optimizer 这篇经典文章的作者.这是 关于 CBO 的两篇最优秀的论文之一.) 该文档覆盖了 Statspack 的大部分内容. 并且介绍了一些如何有效挖取 Statspack 信息的技巧.

Getting fast results from Statspack: How do you apply the YAPP method on a statspack report? 这个文档介绍了如何运用 YAPP(Yet Another Performance Profiling Method) 方法快速分析 Statspack. 在上面的连接中,还可以下载 YAPP 方法的 PDF 文档.

很多 DBA 应该都记得这篇文章吧 ? Myths & Folklore About Oracle8i Performance Tuning. 这篇文章的出现, 粉碎了当时的不少图书中标榜的实际上没有什么作用的优化"技巧".

来自 OraPub 的 Craig A. Shallahamer 在一篇新的论文 Modern Performance Myths 试图定义新的 Oracle 性能神话.包括如下四条:

• Myth #1. Decreasing wait event time will always decrease Oracle response time.
• Myth #2. Decreasing wait event time will always decrease end-to-end response time.
• Myth #3. Profiling sessions is the best way to diagnose performance problems.
• Myth #4. Focusing on where most of the time is spent is always the best approach.

老实说, Craig 这篇论文写的非常"绕".完全看明白要费点时间.因为第一条和第二条 Myth, 说的都是"always", 只需要举出一个反面例子即可. 非常有趣的是第三条, Profiling sessions , 因为这是 Hotsos 的 Cary Millsap 在 Optimizing Oracle Performance 一书中 Method R 方法(参见:Oracle 数据库优化的R方法)所提倡的手段. 要反驳第三条 Myth 倒也不难, Profiling sessions 只能做到针对特定 Session(or User) 进行优化,这个优化能从全局的角度上看是否是成功的? 就不能简单的下判断. Craig 的建议是在系统级和会话级进行响应时间分析(RTA).

看到 有人提问关于授权的问题. 不由得想多说几句. Oracle 9i 以及以下版本的数据库,默认的数据库角色有些不太合理的地方. DBA 管理的过程中,如果不太注意的话,可能会带来麻烦或者潜在的隐忧. 比如最常见的 CONNECT 角色.

User => FOO has been granted the following privileges
====================================================================
        ROLE => CONNECT which contains =>
        SYS PRIV => ALTER SESSION 		grantable => NO
        SYS PRIV => CREATE CLUSTER 		grantable => NO
        SYS PRIV => CREATE DATABASE LINK 	grantable => NO
        SYS PRIV => CREATE SEQUENCE 		grantable => NO
        SYS PRIV => CREATE SESSION 		grantable => NO
        SYS PRIV => CREATE SYNONYM 		grantable => NO
        SYS PRIV => CREATE TABLE 		grantable => NO
        SYS PRIV => CREATE VIEW 		grantable => NO

这里面的 ALTER SESSION 就是一个问题. 恶意的用户很容易利用这个权限给系统带来麻烦.举两个例子,一个是 修改当前 Session 的 cursor_sharing 参数值为 FORCE ,然后提交可触发 Oracle Bug 的查询(cursor_sharing 在 FORCE 模式下 Bug 很多) , 很容易让数据库崩溃. 或者恶意用户提交 alter session set hash_area_size ... 的修改语句, 给自己设定一个超大的 HASH_AREA_SIZE , 再提交一定的查询,也会给系统性能造成很糟糕的影响.

这个 CONNECT 角色在 Oracle 10g 中已经修改了,只有 create session 的权限.