这是一篇迟到的非标准书评。收到人邮社刘江老师寄来的《Oracle 9i & 10g 编程艺术》好久了，只不过绝大多数时间这本书都不在我手旁，也就没时间读完。好多同事抢去看，此书受欢迎程度可见一斑。

去年我就曾经写过一篇关于这本书的小道消息。Thomas Kyte 大叔 早年被引入的 Oracle Expert one-on-one(《Oracle专家高级编程》)可以算得上对国内 DBA 圈子影响最大的一本图书，在市场上也销售得不错。不过那本书的一大问题是翻译质量比较糟糕，副作用是带来了不少辞不达意的翻译术语，比如"封锁"，该书糟糕的装帧质量也让不少读者比较痛苦，好多人都是干脆把书拆开，自动分成上下两册来看。

我曾经给刘江老师出过不少馊主意，其中最馊的一个就是怂恿他干脆重新出版一次《Oracle专家高级编程》(因为那时候 Wrox 的大部分图书都到了 APress 的旗下，版权是能搞定的)，但他担心该书出版的时间太久，市场上没有后劲了，也就作罢。因为我一直订阅 Tom 的 Blog, 也算是第一时间知道他在进行新书的写作，就把这个消息通知了刘江，英文版本出版后没多久，刘老师告诉我邮电出版社拿到了 Tom 新作 Expert Oracle Database Architecture 的翻译版权。当时这本书应该也引起了不少国内出版社的注意，但最终"得手"的是邮电社，一本好书会被有眼光的编辑一直盯个好几年。下手的时候果断也是必要的。

说了这么多，还没说到这本书到底内容如何。"这本 Expert Oracle Database Architecture 是 Tom 在 《Oracle专家高级编程》 的基础之上的解构之作，内容上的变动相当大。不但加入了最新的 10g 的内容, 还作了很多技术补充" ，这里我要纠正一下这个"解构"，应该套用现在的流行技术词汇"重构"，完全是一本"重构"的图书，针对图书内容的重构。

"锁"与"并行"这两个主题分别独立成章叙述，前一章是后一章必不可少的铺垫。要我推荐章节的话，应该首推 第 8 章 事务，不只是 DBA 要看，开发人员、架构师更要看。要设计一个高可靠、可扩展的应用，架构师甚至都要比 DBA 清楚事务。把复杂的东西用人人可作的代码用例展示出来，这是 Tom 拿手的本事。所以，看起来会让你不那么累。

最大的变化是 第十二章 数据类型，这是完全新增的一个章节，这一章中关于时间相关的数据类型讲述非常精彩。另外一个有趣的话题是 LOB，尽管现在用 LOB 字段的场景可能不那么多了，但是用过的人怕是多少都吃过这东西的亏。

如果非要挑毛病的话，我觉得对 分区表的讲述可能不够那么深入，以 Tom 的功力，应该对分区多讲一点，随着计算环境的变迁，OLTP 怕是都已经纷纷采用分区功能了。

翻译上基本上没啥大毛病，很多细节注意的都比较到位，记得 "Lock" 、"Latch" 翻译做什么，还单独做过讨论来着。甚至 前言中的 "Think different" 应该怎么翻译，也做过仔细推敲。从阅读体验来看，这本书的装帧质量很不错。排版改进非常非常多，虽说没办法和英文原版比，但是相比国内技术类图书，应该是不差的了。

如果你需要一本纸版的Oracle 图书，不妨考虑一下这本《Oracle 9i & 10g 编程艺术》。如果你已经买了这本书，多读几遍。书的价值不是由定价体现出来的，而是由你从这本书里学到多少东西决定的。最后，这些话...一般人儿我不告诉他......

--EOF--

补充: 下载部分英文章节试读.

很早就答应了 Oracle 的 Jack Han 一件事情：为 OTN 中文技术网录制一份视频的讲座。因为种种原因，一拖再拖，搞到最后实在不想做了，自己感觉还挺惭愧，好在 Jack 也没怎么催促我。PPT 倒是修改了好几次，干脆放到网上来吧。

内容是关于 Oracle 安全的，其实最初的版本中的一些案例和示例倒是有些用途的，修改了之后觉得好像公关稿。

顺便整理了一下以前的一些技术文档:

• Oracle 常见错误 ORA-04031(PDF)
• Oracle 公司历史回顾 (PDF)
• 利用开源工具实现 TPC-C(PDF)
• Oracle 10g 的闪回恢复区 (PDF)

最后，附送一个《丽塔·海华丝和肖申克的救赎》. 这部小说最早出现在 D 版《肖申克的救赎》碟片中。非常佩服翻译这部小说的人，我最近买了那本《肖申克的救赎》（四季奇谭)，那个翻译版本似乎就是照抄这个网上的这个版本。

--EOF--

国内数据库技术牛人, Oracle ACE Fangxin Lou 自行开发的 AUL 最近有了一次比较重要的升级：支持压缩表。有趣的是，据他自己说是经过了 20 分钟的发呆 想到的解决方法。很多人都知道 Oracle 的 DUL(Data Unloader) 是数据恢复的最后一招，一般来说是密不可宣的，一旦给用户恢复数据则代价昂贵，而 AUL 则平民化了许多，虽然不是开源的，但是国内用户如果使用的话，基本还是不收费用的(功能还毫不逊色)。

Lou 最近也作了一次 AUL/MyDUL发展历史回顾, 这个工具都三岁了。难得的是坚持，这一点我很服气他。

关于 AUL 更多信息可以参考他为推广 AUL 而做的 英文 Blog

--EOF--

BTW: 鲜果上我的BLOG验证代码: BANG1F1D675F0C335CE77C173BA6XIANGUO

Oracle 10g 开始 引入了AWR (Automatic Workload Repository). Oracle 建议用户用这个取代 Statspack。不过这个需要注意的是使用 AWR 需要有 Diagnostic Pack License。Oracle 后来推出了一个解决方案可以禁止掉该特性。

在 Note. 436386.1 有说明:

SQL> @dbms_awr.plb

dbms_awr.disable_awr();

如果用 sys 之外的用户创建 AWR 报告，则需要进行合适的授权。否则会报告错误 PACKAGE 执行错误。

CONNECT / AS SYSDBA;
GRANT ADVISOR TO foo;
GRANT SELECT_CATALOG_ROLE TO foo;
GRANT EXECUTE ON sys.dbms_workload_repository TO foo;

要注意 Bug 4597354 在创建基线数据的时候，对性能有很大影响。在一个非常繁忙的系统上不要进行此操作。

如果结合企业管理器用 AWR 是很方便的，如果用手工方式收集性能数据，多了很多可供调整的地方，是更加方便了呢？还是更加麻烦了?

--EOF--

经常要对一些新存储系统进行 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 的书签 内容。

补充工具：VDbench 是跨平台的，也可以尝试一下。

Oracle 正式出版的技术杂志还是值得一看的。这个杂志现在也有了电子版的了，我连续收到两期了，制作得很精致。一样是PDF ，你说人家做的咋这么好呢?

这一期的杂志地址： 点击观看或者下载 PDF 版本的。

直接下载PDF(在微软共享文件夹上)

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

今天参加 AIX 的技术培训，听了一些关于 CPU 调度的算法，倒也都是些基本知识，回想讲课内容的时候倒让我想起 Linux Kernel 的 I/O Scheduler 来。

这篇 Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel 是必须的参考资料。相比 Linux 2.4 Kernel 的一种 IO 调度器，2.6 做了很多改进，共有四种 IO 调度器。

Deadline scheduler

Deadline scheduler 用 deadline 算法保证对于既定的 IO 请求以最小的延迟时间，从这一点理解，对于 DSS 应用应该会是很适合的。

Anticipatory scheduler

Anticipatory scheduler（as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是"预料的, 预想的", 这个词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的，因为那个"猜测"实际上的目的是为了减少磁头移动时间。

Completely Fair Queuing

虽然这世界上没有完全公平的事情，但是并不妨碍开源爱好者们设计一个完全公平的 IO 调度算法。Completely Fair Queuing （cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中，SuSE Linux 好像是最先默认用 cfq 的.

NOOP

Noop 对于 IO 不那么操心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。

那么如果跑数据库应用，那个更好一些呢? 我们看Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel一文中的测试结果:

对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3，整体 IO 改进还是不小的。

哪一种方式更好? 很难说，每一种方式都有特定的应用对它是最适合的。就像上面的 as 好像表现比较差，如果是 CPU 密集型的应用呢?

Tip:
Q:如何确认当前用什么 IO 调度器?
A: 过滤 /var/log/boot.msg 文件, 查找 "io scheduler", 看到了么?

在 操作系统上可以查到的相关文档：
/usr/src/linux/Documentation/block/as-iosched.txt
/usr/src/linux/Documentation/block/deadline-iosched.txt

--EOF--

更新： Ubuntu Server 使用 Deadline 而不是桌面版的 CFQ 算法。

从很多实际测试场景来看，Deadline 更适合跑 MySQL 数据库。