从人民邮电出版社图灵公司刘江先生处得知, 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.
给垃圾邮件分分类
我的 Gmail 信箱大约 1 周能收到 3000 封垃圾邮件. 这些邮件源源不断的发来, Gmail 的 anti-spam 系统似乎力有未逮, 经常会漏掉. 每天我大约还要手工归档 50 封．
这些垃圾邮件, 大致分个类看看:
*) 发票代开. 非常符合中国国情的垃圾邮件．大约占 10% 是这一类的邮件. 估计再过一段时间, “办证”的也通过网络宣传了.
*) 培训信息. 我这个信箱很奇怪. 经常能收到一些什么针对人力资源的培训啦,文秘的培训, 高级经理培训/ 采购经验之类的. 从这类的广告我还了解到一个词：跟单员．第一次知道有这个工种．
*) 色情信息. 很大一部分是日文的．看不懂．还有一些打擦边球的, 卖成人用品的、”自拍”的, 这个能占 10% . ”食色性也”
*) 看不懂的. 还有一类是看不懂的文字, 排版的方式也千奇百怪. 不知道是什么文字。
*) 标准的垃圾广告. 指的是在标题上注有[AD]字样的垃圾邮件. 当然, 也有 [A.D], [A/D] 这样的挖空心思钻过滤空子的. 标题上还能看到什么星号, 方块, 波浪线什么的, 感慨垃圾邮件工作者这用心良苦. 正是他们的辛苦努力, 使得反垃圾邮件技术不断进化、发展.
*) 推销”廉价”产品. 什么二手笔记本, 打折机票, 优惠价格发表论文， 低价翻译公司。
最近 6.1 节, 当当网的垃圾邮件疯了一样的发过来, 有增无减.
前一段时间看到新闻说, 全球64%垃圾邮件服务器在台湾, 从我收到的垃圾邮件来看, 繁体中文的并不多. 难道台湾的垃圾邮件服务器都是被其他地区的利用么? 还是我只是个例?
又是一个”世界第一”阿! 和 Spam 有关的另一个中国地名是 Chongqing. 专门形成了一个词:
Chongq (verb): to retaliate against spammers of wikis and blogs.
制作垃圾的同胞请继续努力, 用聪明才智积极的 anti-anti-spam ，推动 anti-spam 技术进一步发展.
–End.
的确没有那么多”迷信” [DBA工作备忘]
昨天拜读了刘润的“不要搞封建迷信活动”，深有感触． 前一段时间我在处理 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 工程师最容易”迷信”的地方. 破除迷信, 从现在开始.
SSL 2.0 真的不是很安全
前几天用 Nessus 扫描自己用的笔记本, 报告有安全漏洞:
The remote service accepts connections encrypted using SSL 2.0, which reportedly suffers from several cryptographic flaws and has been
deprecated for several years. An attacker may be able to exploit these
issues to conduct man-in-the-middle attacks or decrypt communications
between the affected service and clients
阅读了一下推荐的文档 Analysis of the SSL 3.0 protocol, SSL 2.0 果然存在不少问题.
其中一个问题是 SSL 2.0 容易受到密码组回滚攻击(CipherSuite Rollback attack). 关于 ciphersuite rollback attack:
An attack against how Secure Socket Layer version 2 (SSL v2) negotiates the cipher suite. The aim is to convince Alice and Bob to use much weaker encryption than they are capable of using.
该攻击方法通过恶意编辑在 hello 报文中发送的所支持密码组的明文列表而使得使用者被动选择弱化的出口加密算法.这几乎是 SSL 2.0 的致命缺陷.
另外一个问题是由于美国安全产品出口法的限制: 只能使用不超过 40 位的 MAC( 报文验证码, message authentication codes). SSl 2.0 使用 MAC 后添加字节的块加密模式,但是添加的长度字段是未经验证的,这给了主动攻击者会删除最后的内容的可能.
对于 SSL V2 也可能存在中间人攻击(man-in-the-middle attack). 虽然 Diffie-Hellman 是目前最为完美的公钥算法．但是在 SSL V2 的缺陷使得供给者能够巧妙伪造一个数字证书, 让客户以为他是和真正的服务器通讯. 在 SSL V3 中则对该缺陷进行了改进．
推荐文档：SSL技术详细说明
一直对 SSL 的安全性比较模糊． 唉