新的笔记本拿到了，旧系统上的很多信息要前一到新机器上来，还要作不少配置，系统才可以用起来得心应手。这些都做完了感觉还真的做了不少操作，记录一下供大家参考。

网上有一些经验可以介绍，比如这篇《重新安装系统后要做的十件大事》，但里面有几条随着 XP 的 SP2 发布后已不适用。

备份

需要备份的有：

收藏夹内容。IE 收藏夹内容备份比较好做。Firefox 的则需要在安装目录下寻找 bookmarks.htm 的文件，拷贝到目标机器上。

证书备份 我的机器上有两个需要备份的：招行专业版的证书，支付宝证书(参考)。

Outlook 配置信息备份 通过Office工具"Microsoft Office 2003 用户设置保存向导"来做，当然还需要备份邮件的数据文件

IM 工具的历史聊天记录。阿里旺旺的聊天记录备份只需要把安装目录中的 Users 文件夹复制到远程即可。MSN Messenger 的记录在"我的文档"里面。

此外还有 Flashget 下载的历史数据文件，SecureCRT 配置信息等等，IE 的 Cookie 也有必要导出并导入到新的环境。

打开 Windows XP SP2 的防火墙

先不要接入网络，打开 Windows XP SP2 的防火墙，这是重新安装系统后的第一件事情。否则如果感染病毒的话，就要反复折腾几次才能好。

关闭恼人的媒体自动播放功能

单击"开始→运行"，在"打开"框中，键入"gpedit.msc"，单击"确定"按钮，打开"组策略"窗口；
在左窗格的"本地计算机策略"下，展开"计算机配置→管理模板→系统"，然后在右窗格的"设置"标题下，双击"关闭自动播放"；
单击"设置"选项卡，选中"已启用"复选钮，然后在"关闭自动播放"框中单击"所有驱动器"，单击"确定"按钮，最后关闭"组策略"窗口。
在"用户配置"中同样也存在这个"关闭自动播放"设置。但"计算机配置"中的设置比"用户配置"中的设置优先。

取消压缩文件夹支持

这条经验来自上面的"十件事"，运行命令：

"regsvr32 /u zipfldr.dll" ，回车，出现提示窗口"zipfldr.dll中的Dll UnrgisterServer成功"即可取消Windows XP的压缩文件夹支持。另外，输入regsvr32 shdocvw.dll可以取消"图片和传真"与图片文件的关联。

微软的 Powertoys for Windows XP 工具中的 Tweak UI 也很好用的，做个性化设置可以尝试一下。

其它需要处理的有：

• Ultraedit 语言配置文件
• 输入法词库的备份
• Firefox 插件列表备份

--EOF--

Posted by Fenng at 6:05 PM | Permalink | Comments (16)

监控 Linux 服务器的时候，经常在 /var/log/messages 文件中看到类似如下的信息：

fooServer ntpd[7250]: can't open /etc/ntp/drift.TEMP: Permission denied

快速解决：

编辑 /etc/ntpd.conf 文件，找到这一行：

driftfile /etc/ntp/drift

driftfile /var/lib/ntp/drift

这个问题最容易在 RHEL 服务器上遇到，碰上两次了，记录一下备忘。

--EOF--

Posted by Fenng at 10:32 PM | Permalink | Comments (0)

在 RHEL 4 上，默认 top 命令的显示有了一点小变化：如果是 SMP 机器 ，只显示 CPU 的概要信息。

其实很多用户还是喜欢看到 CPU 的细节数据的，要恢复旧的显示习惯，只需要输入数字 1 即可打开到 SMP 显示模式。输入大写的英文字母 I 则显示 Irix/Solaris 模式。

小技巧：在输入 1 后，再输入一个大写的 W 即可在当前用户默认路径下保存一个 .toprc 文件，下次启动 top 命令就不用费事了。

这个变化和 procps 版本有关，还不确定是否是因为 RHEL 的 Bug -- 虽然 RHEL 与 procps 相关的 Bug 挺多。

--EOF--

Posted by Fenng at 7:04 PM | Permalink | Comments (6)

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

doubanclaim9aef4c912bc2b8db (这个字串用于豆瓣认领我自己的Blog)

Posted by Fenng at 8:07 PM | Permalink | Comments (6)

公司书架上看到这本《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--

Posted by Fenng at 8:01 PM | Permalink | Comments (3)

记录一下使用 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--

Posted by Fenng at 9:23 PM | Permalink | Comments (5)

最近通过 pkBlogs.com 的服务又可以访问 BlogSpot 的内容了。看到了一篇有趣的文章。Andrew Clarke 在 How To Be A Good Guru 一文中提到了 How to Answer Questions the Smart Way 这个有趣的话题, 并且模仿 提问的智慧 给出了"回答的智慧"的 10 条准则。来看一下这 10 条(翻译了一下，并适当的作了一点注释):

• 1. Don't answer questions to which you don't know the answer( 不回答自己不知道答案的问题 )
• 2. Explain yourself ( 解释给自己 )
  如果自己是提问者，你的回答是否能让自己明白?
• 3. Give as little assistance as necessary ( 尽可能的给最少的帮助 )
  有的时候启发性的回答更为有效.
• 4. Show your workings ( 展示你的做法 )
• 5. Use humour judiciously ( 明智地使用幽默 )
  有的时候因为不同语境/语言的问题，你的俏皮话可能会让提问者更加困惑。
• 6. If you can't say something nice don't say anything at all( 如果你不能说出有用的内容，就别说 )
• 7. Avoid jargon, baffling acronyms and idiolects ( 避免行话、令人困惑的缩写词、习惯用语 )
• 8. Never never never just respond with RTFM. Not ever.( 永远永远永远不要回复 RTFM )
  这里的 RTFM 代表"Read The Fucking Manual", "去读该死的手册". 另外一个常见的是: STFW --Search The Fucking Web, "搜索该死的网络"，或者友好一点的 "Google 一下". 对于中文论坛上，我觉得还有一个尽量不要说 "RPWT" --人品问题 :)
• 9. Meditate on eternity (永远的深思熟虑)
  回答的问题，可能在不久以后会被别人搜索到，看到，甚至是被你将来的老板看到。一个欠缺思索的回答无疑会降低你在其他技术人员心目中的形象。
• 10. Keep your newbie mind (保持自己的"新手"思维)
  学无止境

保持谦卑。回答并不意味着你是"给予", 可能你也在学习. 不要认为回答了一些问题自己就成了 Guru 了.

上述 10 条应该建立在《提问的智慧》的基础上。

Andrew Clarke 的这篇文章是针对 DBA 来说的，不过对其他领域的技术人员也有借鉴意义。提问、回答都是一门艺术.

--End.

Posted by Fenng at 7:34 PM | Permalink | Comments (8)

每天和工作相关的邮件至少有几百封, 这其中又有不少是重复的, 占用了大量的空间, 查看起来也耗费精力, 如何删除这些重复的邮件呢 ?

开始以为通过配置规则可以达到, 看了半天, 似乎不行. 搜索了好一阵, 发现有一些第三方 Outlook 的插件是可以作到的.

• Duplicates Remover for Outlook 共享软件. 30天适用. 速度挺快.
• NoMoreDupes for Outlook 14 天试用.
• Duplicates Remover for Microsoft Outlook

都不是免费的. 看到一篇Blog: 用于 Outlook 2003 的删除重复邮件的插件 , 提到了两个免费的小插件, 可惜都是日文的.

--

补充: 最后使用了 RepMailDel110.lzh . 虽然日文有些看不懂, 不过是免费的. 删除的速度足够快. 这些就够了. Duplicates Remover for Outlook 应该很棒, 可是功能上有限制. 又买不起.

Outlook 2007 是在 "信任中心" 中设置的。

--EOF--

Posted by Fenng at 12:22 AM | Permalink | Comments (2)

很多时候，大多数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

有这两个结果，看来已经足够了，阅读一下...... 嗯，基本明白了一些

Continue reading "利用搜索引擎自助解决 Oracle 的技术问题" »

Posted by Fenng at 10:45 PM | Permalink | Comments (0)

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，便于支持人员迅速帮助解决问题。

Continue reading "Statspack使用中存在的几个误区" »

Posted by Fenng at 9:14 PM | Permalink | Comments (3)