前段时间公司有一仁兄购置了一台 DELL 笔记本。由于该仁兄不喜原带 Vista 系统，遂自己折腾重装成 XP。谁知 SP2、SP3 都装了个遍，不是找不到内置摄像头驱动就是找不到蓝牙设备。怒之，恢复回 Vista 又不甘心，旁人建议干脆装个 Win 7 算了。适逢 Win 7 Ultimate MSDN 发布，遂下载了镜像刻盘装之。直接光盘引导不认硬盘，辗转折腾，最后通过 PE 搞定，第三方激活。

一直以来我对于操作系统的选择只有三个。桌面：Windows 2003 Standard Edition，Win 服务器：Windows 2003 Enterprise Edition，Unix 服务器：FreeBSD。也说不出道理来，仅仅是个人喜好而已。当然你也可以是 Geek 或者传说中的高手，只用 Linux 系列做桌面；或者装一个视窗系统给服务器，却不用 RDP，只用 command shell。后来用了 x200，发现很多驱动在 2003 下面实在没法用，忍痛被 XP 强奸至今。现在有人先我做了小白鼠，没多久也就暗地关注 Win 7 的讯息了。

在这个地下工作的过程中，我发现联想 OEM 的 Win 7 Ultimate 也已发布，正好能装在 x200 上。骑驴一晚，刻盘安装。结果比我想象中的好，虽说 Win 7 花哨，但是能够感受到 M$ 在这个系统上花的功夫，尤其是细节体现上。内核、管理工具、任务栏、电池续航能力的改进，都让我决定延长尝试使用这个系统。

不幸的是，在我成功安装完联想 OEM Win 7 之后，我看到了这么一个页面。刚好我目前使用的 x200 原带系统就是 Vista，符合升级条件。一看价格也能接受，就冲动了一把。

订单提交后不久收到一封邮件：

尊敬的 XX,

感谢您的订单。

请在 7 天内提交清楚地注明型号和购买日期的购买凭证。可以按下列方法发送。

- 电邮：将本电子邮件连同购买凭证扫描件发送到 [email protected]，邮件主题中清楚地注明订单号。例如，订单号 - LENOVO0000018

- 传真：将本电子邮件连同购买凭证发传真至 +65 6896 2377。

- 信函：将本电子邮件的打印件连同购买凭证发送到：
Lenovo Windows 7 Upgrade Option Program
c/o Mentor Media Ltd
No. 1 Bukit Batok Street 22
Unit 07-01, GRP Building
Singapore 659592

订单日期：Thursday, November 12, 2009
订单号：LENOVO0800791

只有在所选语言的 Windows 7 发布或成功验证您的购买凭证后（以后者为准），才会向您的信用卡收费 RMB 86.50。显示的价格包含税收和运费。 成功付款后，将会向您发送一封电子邮件。

订单详情

升级包  符合条件的产品  语言  PC 型号  序列号
Windows® 7 Ultimate 32-BIT Windows® Vista Ultimate 32-BIT 简体中文  74574AC LVXXXXX

总额 = RMB 86.50

付款只有在11月才会开始。届时将会发送一封含有付款程序的通知邮件。

正在考虑是拍照后邮件还是传真的时候，又收到了第二封邮件（时隔半个小时）：

尊敬的 XX

兹告知您可以开始付款了。

订单号： LENOVOXXXXXXX
总金额：RMB 86.50 

请点击 https://ebiz3.mentormediacorp.com/Payment/LENOVO?Email=xxxxxx&OrderNo=LENOVXXXXXXX&Lan_Used=zh_cn，进行付款。

付款完成后，将会向您发送一封电子邮件。

于是我就鬼使神差地付款了。然后当天下午收到一封邮件，告诉你货款已收到；等到实际发货时，会再有邮件通知。

13 天后，我先收到了从上海明德信息科技有限公司通过 Fedex 发来的快递，然后晚上收到了邮件：

尊敬的 XX,

兹告知您的订单已发货，您的订单已完成。

发货详情：

发货地址：XXXX
电邮地址：[email protected]
电话号码：XXXX

产品详情：
Current Product  Upgrade Product  Language  Qty  
Windows® Vista Ultimate 32-BIT Windows® 7 Ultimate 32-BIT 简体中文 1 

您可以按下列方式追踪此订单的状态：
承运人货物追踪网站：http://cndxp.apac.fedex.com
追踪 ID：120254XXXXXX

请注意，可能要在2-3天后才可以在承运人网站上使用追踪ID。

感谢您向我们下订单。

至此，我收到了冲动的全部结果。下面放图：

- 阅读剩余部分 -

万恶的 2008 年终于寿终正寝，而同样万恶的 CNNIC 着实在 08 年末的最后几天抢了一把大家的眼球。因为它终于在 08 年的最后一天结束了长达两年的 CN 域名 1 元市场政策。各大媒体争相报道此事。09 年的市场政策如何？有人喊出了百元价格说，称 100 元附近的价格才符合市场规律。

作为新网代理商，我也接到了这样的通知：

《“CN域名1元体验活动”将于2008年12月31日结束》

推广国家域名，降低域名应用体验门槛，惠及更多网民，是“CN 域名1元体验活动”的宗旨。自2007年3月7日“CN域名1元体验活动”举办以来，广大用户踊跃参与CN域名体验，更多用户成长为我国互联网事业的建设者，体验到基于CN域名的建站、博客、邮箱等各项互联网应用。截至2008年6月，CN下的网站数占全国总网站数的比例从2007年1月的43.6%增长至71.3%，国内大多数网站已使用CN域名，网民输入CN域名访问网站的习惯也已逐步形成。

近期接CNNIC通知“CN域名1元体验活动”将于2008年12月31日24:00时如期结束。活动结束后，新网将根据市场具体情况调整CN域名价格，敬请广大用户及时安排好域名注册和续费的相关事宜。

北京新网数码信息技术有限公司
2008年12月30日 我在想，很好，CNNIC 又一次过河拆桥了。前几天就这个事情在和新网某地分公司某销售小妹妹联系的时候，都听到了“CNNIC 很坏的”这样的言论。CNNIC 你自作孽，不可活，怪不得连你的注册商都要骂你。

从 2007 年 3 月 CNNIC 开始 1 元注册活动以来，我看着 CNNIC 的软文渐渐布满大街小巷。一会是 CN 注册量超过国内注册国际域名的数量，一会又是 CN 注册量接近 800 万、直逼 .DE。最新的一个版本是 CN 注册量 1300 万，已经超越 .DE 成为全球第一大国家域名。有人不禁发问：《CN 域名怎样才能恢复理性？》。

这种掩耳盗铃的做法，恐怕只有 CNNIC 自己才沉醉在光辉灿烂的成就、业绩、大好前景以及美梦的谎言里吧。正好畸形价格策略结束，CN 应该能从中呼吸到一点点正常的空气。就让我们拭目以待 CN 的平均年度保有量和增长率吧。

元旦假期的第一天，我在新网代理商平台看到这样的消息：

《CN域名价格调整通知》

尊敬的合作伙伴：

新网定于从2009年1月1日起重新调整CN域名价格，但为了让广大客户更好的使用CN域名，推动中国域名事业发展，新网决定对2009年1月1日至2009年2月28日，新注册或在该时间段内到期首年续费的CN域名提供优惠价格。具体价格如下：

新注域名：首年价格为10元，如一次性注册多年，除首年外，其他按照正常续费价格；
域名续费：注册时间在2007年3月8日至2008年2月28日间注册，并且到期时间在2009年1月1日至2009年2月28日之间的域名，首年续费价格为5元/年，超出一年的部分按照正常价格续费。其他时间段内注册的域名续费均按照正常价格执行。同时新网保留随时根据市场具体情况调整各级别渠道价格的权力！

感谢各位合作伙伴长期以来对新网的支持！

北京新网数码信息技术有限公司
2008年12月31日 如此一来，今年 2 月底之前，新网的新开价格暂定在了 10 元。令我觉得奇怪的是，我的确还能见到依然标价 1 元的同行网站。不过 CN 肯定不会在一夜间走高，所以需要一个循序渐进的过程。

下面的截图是上面的两次引用的内容的存照：

最后有两则消息，既有老新闻，又有新新闻。从事域名投资的朋友不妨关注一下：

微软已经向域名抢注者下手，英国五家公司被起诉。相关新闻可参见这里、这里和这里。

无独有偶，Verizon 告域名抢注者的案件也获得突破性进展，一审 OnlineNic 败诉，被判赔偿 3320 万美元。相关新闻可参见这里和这里。

本文的话题是“人非圣贤，孰能无过？”。语出《左传·宣公二年》：“人孰无过？过而能改，善莫大焉。”

故而，一直以来我都相信，无论是 SYSOP 还是 DBA，无论是初学还是资深，都会有误操作的时候。事后如何补救才能使损失降低到最小，才是我们应当更为关注的内容。

虽然我没有遇到过不可挽回的误操作，但前段时间确实因为需要对 SQL Server 数据库的日志文件进行分析而接触了《Log Explorer for SQL Server》这款神奇的软件。

有关 Log Explorer 的介绍、使用方法，数据库相关介绍、数据恢复原理等，可以参见这里和这里。

由于我使用 Log Explorer 的目的只是为了分析数据库日志，因此我选择使用连接在线数据库事务日志来完成工作。其操作步骤比较简单，基本与这篇文章一致。

以下为看图说话时间。

使用数据库帐户登录：

选择库的事务日志文件：

读取日志的状态：

呵呵，这依赖数据库所在服务器的环境和网络速度：

成功连接并读取到远程的事务日志文件：

左侧操作菜单：

“Log Summary”，日志摘要：

切换到“Filter Log Records”，选择筛选条件。读取范围的起始位：

读取范围的中止位：

筛选数据库操作动作：

对表也可以进行筛选：

筛选数据库角色：

提交筛选后给出的分析结果：

切换到“Browse”下的“View Log”，查看刚才筛选条件下的日志记录：

若需要 undo 某条记录，直接右键就行了：

选择“Undo Transcation”后，导出一个 SQL 脚本文件：

由于涉及商业版权问题，该软件的下载地址请自行搜寻：）

如果要问系统管理员最痛恨的事情是什么，我敢打赌，99％的回答不是遇到棘手的问题，也不是遇到莫名其妙的情况，而是给那些该死的 Windows 系统服务器打补丁——一个一个又一个，一台一台又一台，一遍一遍又一遍……生生不息、永无止境。

不要告诉我有 WSUS 这个玩意，我知道。这个鬼东西和域控制器建在一起，那简直就是地狱。至今我依然不记得在同一台服务器上应该先安装 WSUS，还是先搭建域控制器。总之它们俩必定有一个先后顺序，不然会影响对方——我很佩服微软，真的。

幸好伟大的 M$ 公司还有一个玩意叫做批处理脚本。下面这个脚本用于批量补丁，可以帮助系统管理员节约时间，减少白头发：

FOR %%i IN (*.EXE) DO %%i /passive /norestart /nobackup 脚本需要放在那一堆补丁中间，就像羊群中的狼一样。另外参数也可以根据实际情况调整。

前几天在一台 Windows 2003 Enterprise Edition 的机器上，突然运行不了这个脚本，提示：

Windows 无法访问指定设备、路径或文件。您可能没有合适的权限访问这个项目。 我以为我在做梦，或是眼睛模糊了。再次执行，还是一样；来到 CMD 下执行，也是一样，于是我被折服了。

看了 M$ 公司伟大的帮助文档后，才知道这样的情况乃是相当罕见。应该这样解决：

回到上层目录，右键补丁和 BAT 脚本所在的目录，选择“属性”，然后“安全”选项卡，点击下面的“高级”，选择“所有者”选项卡，选中“替换子容器及对象的所有者”，然后“应用”，接着切换到“审核”选项卡，选中“允许父项的继承审核项目传播到该对象和所有子对象。包括那些在此明确定义的项目”和“用在此显示的那些可以应用到子对象的项目替代所有子对象的审核项目”，点击“应用”，确定所有对话框，一切完成。

随着公司业务平台不断扩大，原先数据库服务器上 2GB 的物理内存已显得较为吃紧。前段时间，一狠心，在 DELL 下了一个 PowerEdge 2950 架构的单，直接上到 4GB。

数据库服务器最在意的事情就是数据存储的安全可靠。为此我订购了四块 SAS 硬盘，其中一块做系统盘，其余三块组成一个 RAID5 阵列。这机器成本不算低了，好歹性能也跟上去了，于是日子就这么继续……

最近发现服务器的物理内存占用情况比较有意思。无论我何时连上去看，物理内存占用量都在 1.5GB 至 1.75GB 左右，死活超不过 2GB。当然，绝大部分都被 SQL Server 所占用，但没有完全占用所有可用的剩余物理内存。而 SQL Server 被配置为动态地使用所有物理内存选项。整个情况非常神奇，让我禁不住啧啧赞叹……

这神奇的景象就像这样：

网上有文章说只要打开 /3GB 或者 /PAE 开关就可以，这样的说法是不准确的。

首先我们要分析当前操作系统是什么版本，是否需要开启 /3GB 或者 /PAE 开关。具体可以参阅微软的帮助支持中心的这篇文章。我的操作系统是 Windows Server 2003 Enterprise Edition，其本身就支持最高 32 GB 的物理内存，所以不需要打开这些开关。

我个人的理解是：如果机器上的物理内存并未被操作系统所完全识别，则需要根据操作系统的实际情况考虑打开这些开关。

另外，同时使用 /3GB 和 /PAE 开关是没有意义的。物理内存为 3GB 的时候使用 /3GB 开关，大于等于 4GB 就使用 /PAE 开关。关于 /3GB 开关的描述请见这里，关于 /PAE 开关的描述请见这里。

一个需要开启 /PAE 开关的 boot.ini 的实例类似是这样的：

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows Server 2000 Server" /noexecute=optout /fastdetect /PAE 如微软的文章中所说，检查完系统是否支持当前的物理内存后，然后需要启用 SQL Server 的 Address Windowing Extentions（AWE）支持。

要检查 AWE 是否已启用，请从 SQL 查询分析器运行以下脚本：

sp_configure 'show advanced options', 1
go
reconfigure
go
sp_configure 'awe enabled'
go 如果 run_value 设置为 1，则服务器上启用了 AWE。如果不是，请在 SQL 查询分析器中输入：

sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'awe enabled', 1
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'max server memory', 4096
RECONFIGURE WITH OVERRIDE
GO 请注意，这里的 4096 适用 4GB 物理内存的系统。如果是 6GB，这个数字应改成 1024 * 6，其他情况依此类推。

值得特别说明的是，微软的原文介绍使用 RECONFIGURE 命令，而我将之改为强制更新的 RECONFIGURE WITH OVERRIDE 命令。其最终效果是一样的，只不过有些情况下 RECONFIGURE 无法完成工作。

到此为止，理论上 SQL Server 应该可以支持 2GB 以上的物理内存了。但某种情况下，依然不行。为何？我们再来看微软的一篇文章。

这里说到这样一个问题：启用了 AWE 支持，但单个 SQL Server 2000 实例还是只能使用计算机上最多 50% 的物理内存。

很不幸地，这个问题被我遇到了。经过一番折腾后，服务器的内存使用量还是在 1.75GB 左右徘徊。这个属于 SQL Server 早期版本中的一个漏洞，该问题只发生在具有超过 2 GB RAM 的计算机上运行于基于 x86 或基于 x64 的计算机上的 32 位版本的 SQL Server 2000 Service Pack 4 中。要查看此现象，请检查系统监视器中的“SQL Server：内存管理器 / 总的服务器内存（KB）”计数器。在运行 SQL Server Service Pack 3（SP3）的计算机上，该值最大可以为计算机上的物理内存量。在运行 SQL Server SP4 的计算机上，该值永远不会超过物理内存的 50%。

下载一个 8MB 的补丁，打了就好。

实践证明，现在的内存使用量已经达到了我们 BT 的要求了：

这样一番折腾之后，任务管理器可能会变得无法准确提供内存使用信息，原因请见这里。

最后补充，无论是打开 /3GB 或 /PAE 开关，还是开启 SQL Server 的 AWE 支持，还是打 for SQL Server SP4 的修复补丁，系统必须重启才能生效。