在 RHEL 4 上，默认 top 命令的显示有了一点小变化：如果是 SMP 机器 ，只显示 CPU 的概要信息。
其实很多用户还是喜欢看到 CPU 的细节数据的，要恢复旧的显示习惯，只需要输入数字 1 即可打开到 SMP 显示模式。输入大写的英文字母 I 则显示 Irix/Solaris 模式。
小技巧：在输入 1 后，再输入一个大写的 W 即可在当前用户默认路径下保存一个 .toprc 文件，下次启动 top 命令就不用费事了。
这个变化和 procps 版本有关，还不确定是否是因为 RHEL 的 Bug -- 虽然 RHEL 与 procps 相关的 Bug 挺多。
--EOF--
安装 Office 2007 试用了几天，新版本用户体验倒的确不错，可就是在我的机器上不够稳定，经常"停止响应"，无奈何，删掉 Microsoft Office 2007, 重新安装 Office 2003，启动 Outlook 2003 的时候遇到如下问题：
无法启动 Microsoft Office Outlook。MAPI32.DLL 损坏或版本不对。可能是由于安装其他邮件软件造成的。请重新安装 Outlook。
重新安装一遍，问题依旧，搜索到了微软一篇支持文档，当您尝试启动 Outlook 2003 错误信息： "MAPI 32.DLL 已损坏或版本不对"，其说明的原因是:
如果安装 Microsoft Office Outlook 2007 ，然后卸载，再安装 Outlook 2003 就会发生此问题。(原因是)当卸载 Outlook 2007的时候，没有从计算机上除 Outlook 2007 版本的 MSMapi32.dll 文件,该文件位置： C:\ProgramFiles\Common Files Files\System\Msmapi\1033
(Office 删除的时候连自己的文件都弄不干净，唉。另外，微软页面上这段话是机器翻译的，2007 都翻译成 2007 年，我给擅自校订了一下)
这个 MSMapi32.dll 位置似乎是有问题的，我的机器上实际的位置在:
C:\Program Files\Common Files\System\MSMAPI\2052
把该文件重新命名后，再打开 Outlook 2003 就 OK 了.
--EOF--
公司书架上看到这本《Web安全、隐私与电子商务》就借回来看了一下，读到电子支付这一章，还真的发现一点很有意思的内容。
有一节介绍了支付卡校验位算法，记录一下算法：
1. 对卡号上的每位数字乘以权重。其规则是，如果卡号数字个数是偶数，则第一位乘以2，否则就乘以1，然后以后分别是,1,2,1,2,1,2;
2. 如果每位数字乘以权重后超过9 ,则需要减去 9;
3. 将所有的处理过的加权数字求和，用 数字 10 求模运算;
4. 余数应该是0，否则可能是输入错误。也可能是一个假号。
更为详细的例子参考O'Reilly 台湾站点样章对校验位的介绍。
书中介绍这个算法是公开在 ISO 2894 中的，搜索了一下，这个算法叫做 The Luhn Mod-10 Method。
有的网友可能会动起脑筋，那么是否可以伪造一个信用卡号码呢,嘿嘿嘿,不要忘了还有用户卡上的名字和三位验证码呢, 重要的是，书中告诉我们: 盗用信用卡号码是犯罪行为.
顺便说一下，附录一的内容很适合初创公司的CEO阅读一下。
--EOF--
记录一下使用 cURL 时的一个小技巧.
比如上次举的这个备份 del.icio.us 书签的例子中，因为该页面需要验证， --user YourUserName:YourPassword ，需要提供用户名字和密码，我上次说:
如果想定期备份，又怕密码出现在命令行上，可以考虑把这个命令写到一个脚本里，能提高一点点安全。
其实通过 -K 参数就可以很好的避免这个问题，创建一个文本文件 .pass ,内容如下
--user YourUserName:YourPassword
(把具体的用户名字替换一下) 然后通过:
curl https://api.del.icio.us/v1/posts/all -K .pass
cURL 的功能足够丰富，官方站点的文档也足够全，如何在实际工作中方便、灵活的用到这些功能，需要慢慢磨练。
cURL 也是我 Windows 上安装的命令行小工具之一.
--EOF--
最近通过 pkBlogs.com 的服务又可以访问 BlogSpot 的内容了。看到了一篇有趣的文章。Andrew Clarke 在 How To Be A Good Guru 一文中提到了 How to Answer Questions the Smart Way 这个有趣的话题, 并且模仿 提问的智慧 给出了"回答的智慧"的 10 条准则。来看一下这 10 条(翻译了一下，并适当的作了一点注释):
保持谦卑。回答并不意味着你是"给予", 可能你也在学习. 不要认为回答了一些问题自己就成了 Guru 了.
上述 10 条应该建立在《提问的智慧》的基础上。
Andrew Clarke 的这篇文章是针对 DBA 来说的，不过对其他领域的技术人员也有借鉴意义。提问、回答都是一门艺术.
--End.
每天和工作相关的邮件至少有几百封, 这其中又有不少是重复的, 占用了大量的空间, 查看起来也耗费精力, 如何删除这些重复的邮件呢 ?
开始以为通过配置规则可以达到, 看了半天, 似乎不行. 搜索了好一阵, 发现有一些第三方 Outlook 的插件是可以作到的.
都不是免费的. 看到一篇Blog: 用于 Outlook 2003 的删除重复邮件的插件 , 提到了两个免费的小插件, 可惜都是日文的.
--
补充: 最后使用了 RepMailDel110.lzh . 虽然日文有些看不懂, 不过是免费的. 删除的速度足够快. 这些就够了. Duplicates Remover for Outlook 应该很棒, 可是功能上有限制. 又买不起.
Outlook 2007 是在 "信任中心" 中设置的。
--EOF--
很多时候，大多数IT类的技术问题完全可以自行去解决它，相对于答案来说，我们更需要一个方法．下面就一个例子来说说一些Oracle问题的解决途径(途径？如果可以这么说的话)。
问：关于x$ktuxe表的疑问？？
本人在电子杂志(注：www.itpub.net 的电子杂志)第五期第29页看到这条语句，但我不清楚其具体含义，能否帮忙解释一下？另外，这里的kluxescnw和kluxescnb又是什么意思?select max(ktuxescnw*power(2,32)+ktuxescnb) scn from x$ktuxe;
答：说点题外话，类似如下的问题，如果是我怎么去找答案。
首先，这样的问题我先看看有没有必要要弄明白，x$ktuxe，第一眼看上去，是Oracle的一个内部视图，既然是这样，可以知其然，不继续深入的了解他......
什么?这样的习惯不太好? %$#@.....
那好，如果不是这样，我偏要了解一下这个视图是做什么的．怎么办? 到 OTN 上寻找文档？不太可能，这样类似的视图一般Oracle不会详加说明的。 对了，Metalink上也许会有，哦，没有Metalink 的帐号...
还好，我们有搜索引擎 Google，输入 x$ktuxe. Search it , OK ,共有 116 项查询结果,稍加审视．第一项结果是：
Rollback Segment Scripts
... the rollback segment header blocks. The rollback segment header block transaction tables can be read via X$KTUXE, however the number of undo blocks in use is not always accurately reflected here until release 9i. Prior to that, it is necessary ...
http://www.ixora.com.au/scripts/rbs.htm
第三项结果是：
Speculation of X$ Table Names
... x$ksulop, kernel service, user long operation, x$ksupr, kernel service, user process, x$ksuse, kernel service, user session, x$ktuxe, kernel transaction, undo transaction entry, x$kzsro, kernel security, system role, used in many SQL scripts in ?/rdbms/admin. x$le, lock element, x$le_stat, lock element status, ...
http://www.stormloader.com/yonghuang/computer/x$table.html - 16k
有这两个结果，看来已经足够了，阅读一下...... 嗯，基本明白了一些
Statspack 是 Oracle 提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行数据库的优化调 整。不过在交流中发现很多朋友对这个工具的的运用还有一些 问题。下面就其中比较容易出问题的几个方面进 行一下简单的分析。
我们知道，Statspack的report实际上也就是对比两个快照 (Snapshot，也就是数据库当前状态 ) 得出的结 果。
一般情况下，专家建议生成Statspack报告的快照时间间隔为15-30分钟。
试想，一个人去医院看病，医生对其测量体温，一般也就是5-10分钟左右就可以了， 为什么是这麽长的时间？ 因为5-10分钟这段时间基本可以近似的得到你的体温。如果时间过短，可能达不到既定的目的，测到的体温会 偏低，时间过长，甚至长达几 个小时的话(假设有这种情况)，病人可能都昏迷几次了 ;) 。
对生成Statspack报告的快照时间间隔也是这样，如果两个Snap Time时间过短，数据 库的一些主要周期性 事务可能还没有运行，信息收集不完全。如果间隔过长，数据一样会有偏差。
假设如下的情况：系统一直正常，但是最近几天有用户反映，在A时间段应用程序执行 很慢。B时间段正常，而 A时间段有一个主要的事务X运行（也是用户使用到的事务）。 B时间段有另外一个比较消耗资源的事务Y在运 行。A和B时间段的跨度比较大。本来你的 快照如果覆盖A时间段内就已经能够的收集到比较准确的数据了，但 不巧的是，你的Report 所用的两个Snap ID的时间跨度太长，从而把B时间段内的统计数据也收集了进来。 Statspack 经过比较，“认为”事务Y是对系统有主要影响(这也会在Report上体现出来)，而你，经过分析，认 为Y才是罪魁祸首，接下来，你不遗余力的对Y进行了tuning......
问题出现了！调整了B之后，用户继续报告，A时间段内系统不但没有变快，反而变得更慢，甚至不可忍受。这 种情况是很危险 的，可能会对系统造成不同程序的损害。在比较严格的环境中，这已经构成了一次比较严重的 事故。
或许你也要承认，Statspack的快照的采样时间间隔还真需要重视呢......
这是一个Oracle 8.1.7.0.1 版本下的Statspack报告：
Snap Id Snap Time Sessions
------- ------------------ --------
Begin Snap: 637 04-Aug-03 11:59:33 25
End Snap: 646 04-Aug-03 16:29:06 25
Elapsed: 269.55 (mins)
从中可以看到快照637和快照646之间为269.55 (mins)。这么长的时间跨度，即使数据库在一定时间间隔内
有问题，在这里的体现也会有偏差。
下面的这个Statspack 报告的时间有点不靠谱了：
Snap Length
Start Id End Id Start Time End Time (Minutes)
-------- -------- -------------------- -------------------- -----------
314 1053 11-Dec-03 18:07:13 19-Dec-03 10:53:02 11,085.82
11,085.82分钟? 这么长时间内的数据采集分析，怕是绝大部分内容都是不能相信的了。
还要注意的是，我们说的时间间隔，是Begin Snap和End Snap之间的间隔，而不是相邻两个Snap 之间的 间隔。对于Snap收集的间隔，建议以不要影响性能为准，收集的太过于频繁，会对性能和 存储都造成压力。 对于所谓的15-30分钟，不能墨守成规。具体的环境下应该加以调整。
Statspack从本质上说，是对系统的性能统计数据进行采样，然后进行分析，采样，就会有偏差。如何消除偏 差？统计学指出差值随样品个数的增加而降低。所以，只凭借一个Report文档就断定数据库的性能问题出 在某处，是比较武断的做法（个别情况除外）。需要DBA创建多个Report，包括不同时间段，对比进行分析， 这样才会起到很好的效果。在寻求技术支持的时候也最好能够多提交几份Report，便于支持人员迅速帮助解决问题。
