从人民邮电出版社图灵公司刘江先生处得知, Thomas Kyte 的 大作 Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions的翻译已经接近尾声, 即将出版.

据我所知, Tom 当年的那本Oracle Expert one-on-one(《Oracle专家高级编程》)可以算得上 Oracle 技术图书中文市场历史上最成功的一部作品, 尽管翻译质量粗糙、术语混乱、印刷糟糕、价格昂贵, 但还是火得一塌糊涂，很多搞 Oracle 数据库的技术人员都是人手一本. 这本书的成功也让其他出版社看热不已。

我此前说过，这本 Expert Oracle Database Architecture 是 Tom 在 《Oracle专家高级编程》 的基础之上的解构之作，内容上的变动相当大。不但加入了最新的 10g 的内容, 还作了很多技术补充。很多 DBA 朋友怕是心仪已久了吧 ? 一个初级 DBA 如果期待自己对 Oracle 的理解登堂入室, 那么 Tom 的图书总是一定要看的。

很久以前就得知图灵图书拿到了 Expert Oracle Database Architecture 的翻译版权。没想到运作的速度真的很快。目前我手里有前六章的翻译草稿，初看上去，翻译中规中矩(翻译者据说是部队院校的一个老师)。术语拿捏得比较准确。下一周准备对找英文原版来中英对照"学习"一下.

人邮图书的一格弱点是排版不够好。虽然 Word 排版大大的降低了图书出版成本，但是对于一些相对比较重要的图书来说，好的排版质量会带来更好的收益的。如果 Expert Oracle Database Architecture 中文版排版能比普通的人邮书更好一点, 那么有什么理由不把现在手里的这本 《Oracle专家高级编程》 扔掉呢 ?

--
BTW：

1) 人邮图灵最近一段时期动作很大，有一些不错的手笔，比如"图灵四大名著",颇像当年的华工出版社. 技术爱好者不怕好作品多, 这是图书市场的可喜现象。

2) 翻译这个事情是个辛苦差事，一本书拿到手里，往往只是不到两个月的时间, 而急就章的交给出版社之后什么时候出版，则是另外一回事了。这个糟糕的流程如果能改进一点是最好的了。
-End.

昨天拜读了刘润的“不要搞封建迷信活动”，深有感触． 前一段时间我在处理 Data Guard 的时候, 遇到过一件怪事. "怪现象一定有原因的"． 果然, 经过仔细分析之后, 果然发现并不是灵异现象. 凡事皆有因果.

情景描述:

在一个机器上建立两个同一数据库的 Data Guard. 其中一个 Data Guard 已经建立,数据文件放在 foo 目录下.现在准备建立第二个 Data Guard, 数据文件放在 fooback 下. 初始化参数已经设置:

*.db_file_name_convert='/opt/oracle/oradata/foo/','/opt/oracle/oradata/fooback/'

其他的设置略. 用第一个 Data Guard 备份的控制文件, 启动第二个实例, 进行恢复. 开始正常, 恢复了几个文件之后,遇到如下错误:

skipping datafile 56; already restored to file /opt/oracle/oradata/fooback/user_log_04.dbf
skipping datafile 57; already restored to file /opt/oracle/oradata/fooback/user_log_05.dbf
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00058 to /opt/oracle/oradata/foo/foo_note_06.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/24/2006 11:32:48
ORA-19504: failed to create file "/opt/oracle/oradata/foo/foo_note_06.dbf"
ORA-27086: skgfglk: unable to lock file - already in use
IBM AIX RISC System/6000 Error: 13: Permission denied
Additional information: 8
Additional information: 553070

已经作了数据文件名字映射,　在第 58 个文件映射失败(应该是 fooback 目录下的文件,又跑到 foo 上去恢复了!) 怪哉!

进入第一个实例, 查询文件名字,正常．进入第二个实例, 查询文件名字, 前面 57 个都是 fooback 目录下的, 第 58 个就变成了 foo . 难道是遇到了 Bug 么 ? 为什么是 58 ?

折腾了许久, 针对这个58 ,我去查以前的数据库变动, 发现这个文件,是第一个 Data Guard 建立之后我第一次添加的数据文件.

oops, 我用的这个控制文件有问题!! 如果只在一个机器上建立一个 standby ,那么用其他 standby
备份出来的控制文件, 并且不修改文件名字映射的话, 不会出现该问题的. 而第一个 Standby 的控制文件,只从 Primary DB 控制文件带来 57 个数据文件的信息.所以, 在 58 个失败.　而 Oracle 的 Data Guard 文档中建议的标准做法是从 Primary DB 取控制文件.

Bug ,这是一个 DBA 甚至是所有 IT 工程师最容易"迷信"的地方. 破除迷信, 从现在开始.　

我要给朋友发送 Windows Live Messenger 的邀请, 但最近 Live.com 不可访问(不说大家也知道什么原因), 颇为无奈. 还好, 我们有 Tor 这个二代"洋葱"[Tor 中文介绍].

这个工具的安装与使用倒是很简单的. 首先下载当前的稳定版本(很奇怪为什么 Tor 站点没有被封掉), 参考英文的安装指导. 点击这个安装文件, 注意一共包含三个程序的, 如果不加以选择, 每个程序都是默认自动运行的, 建议取消这个．以后如果用得着就手工启动吧．

第二个步骤是设置 浏览器的 Proxy ,Localhost, 端口是 8118 . 安装指导上有图示. 然后基本上就不会有其他麻烦了． 现在开始访问 Live.com . 下载最新的 Windows Live Messenger 玩玩儿吧.

原来我用过一些其他的 Proxy 工具，这些工具都放在一个 "Out the Windows" 的目录下, 恶心的是, 都有副作用, 每次用的时候都怕别人看到, 还是 Tor 干净,以后放心的用.

"快从你的窗口冲出..."

Undo_retention Oracle 9i 开始出现新的初始化参数．Oracle 9i 的 Undo 管理特性使得 Ora-1555 错误大大减少, 但是 Undo_retention 的设置仍然会个别的时候出现问题．

Oracle 10g 有自动Automatic Undo Retention Tuning 这个特性．设置的 undo_retention 参数只是一个指导值, Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误. 通过查询　V$UNDOSTAT 的 tuned_undoretention 字段可以得到 Oracle 根据事务量(如果是文件不可扩展，则会考虑剩余空间)采样后的自作主张的 retenton 时间. 这样对于一个 事务量分布不均匀的数据库来说, 就会引发潜在的问题--在批处理的时候可能 Undo 会用光. 而且这个状态将一直持续, 不会释放.

10g 中, 如果数据文件的属性是 autoextensible , 则 undo_retention 参数必须设置. 如果 undo 表空间的文件属性是不可扩展的, 则　undo_retention 将不会起到什么作用(修正的办法是把该 Undo 表空间属性设置为GUARANTEE ).

通过如下命令(undotbs01 是undo 表空间名字)：

ALTER TABLESPACE undotbs01 RETENTION GUARANTEE;

然后可以查询 DBA_tablespaces 的 retention 列. undo 表空间的属性和普通表空间的属性是不一样的．

-End

看到有网友在问"800多W美圆" 买来的超豪华 HP 服务器如何配置的帖子, 有网友回贴 "80多万美圆" 就能买下来, 下面就有人接着说 "我们公司买的superdome，才 52G 的内存，跟这台各个方面比较都差多了，还花了200w 刀呢". 下面还有人说某地“有的中学用 EMC dmx 2000 做存储”，不由得感慨国内的一些有钱的公司和一些能烧钱的机构在 IT 硬件方面的浪费(挥霍).

说起浪费, 还有一点佐证. 前一段时间和一家供货商的销售人员聊天的时候, 销售不无感慨的说, 卖给你们东西, 利润太低,如果是国企或者政府部门, 怎么能有几十个点的利润阿. 从另一个角度上说，每年的政 府科研预算，要多花多少冤枉钱呢 ?

"收购专业户" Oracle 的收购举措总能吸引足够的眼球. 早在几年前喊出收购 PeopleSoft 的时候, 业界都认为是不可能的事情. 没想到最后居然就啃下了这块硬骨头. 现在 Oracle 放出风来准备收购一家 Linux 厂商, 估计又要有一场好戏看了。

Oracle 这个时候喊出来收购 Linux，实际似乎有点晚．SuSE　Linux 应该是 Oracle 最好的潜在目标，可惜现在是 Novell 旗下公司，买　SuSE　还要搭送一个 Novell ,这似乎不是一个好买卖．要说现在这个局面，其实也多少和 Oracle有点关系. 当年的 SuSE 在支持 Oracle　方面的力度和技术不比 红帽子差. 可 Oracle 进入这场游戏之后市场就变了, Oracle 助力红帽子, 很快一家独大． RedHat 最近又成功吃下了 Jboss, 隐隐然已经有开源软件王者之气, Oracle 要想买下红帽子,　难.

再说 SuSE, 在服务器市场可以说是起个大早,赶了一个晚集, 最后居然被没落贵族 Novell 收至麾下。Novell 倒也大张旗鼓的折腾了一阵子,　不过市场不给面子，叫好不叫座. Novell一方面想让自己的目录服务器/群件等产品在 Linux平台上起死回生, 另一方面又拼命提高 SuSE 的易用性--倒是更想在桌面市场分得一杯羹, 总让人感觉在开源上, 定位还不够准确，立场不够坚定. Oracle 如果收购　Novell, 倒也不是没有可能,不过 Oracle 看中的只是 Linux, 对于 Novell 的整条产品线未必感兴趣.

今天又遇到了一个 Oracle Bug . 数据库版本为10gR2, 详细的版本号为 10.2.0.1.0 , Oracle 之外的操作系统用户调用命令会报告:

sqlplus: error while loading shared libraries: libsqlplus.so:
cannot open shared object file: No such file or directory 

检查 $ORACLE_HOME / $LD_LIBRARY_PATH 等可能引发问题的环境变量，都是正常的．莫非又是 Bug ? 果然，Bug 4516865!．　

错误日志如下：

IMP-00020: long column too large for column buffer size (7)

Oracle手册中的错误信息参考大致是这样的:

IMP-00020long column too large for column buffer size num(x) 
Cause:  The column buffer is too small. 
This usually occurs when importing LONG data.
Action: Increase the insert buffer size 10,000 bytes at a time (for example)
up to 66,000 or greater. Use this step-by-step approach because a buffer size 
that is too large may cause a similar problem.

测试了几次 buffer size 调整还是报告同样的错误, 怀疑是 export dmp 文件坏掉了. 重新 export , imp 还是有问题. 逼得我没有办法, 不得不跑到 Metalink 上搜索(访问 Metalink 速度那叫一个慢啊! 好半天，总算看到结果了, 居然我是遇到了 Bug 2417643!