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

故而，一直以来我都相信，无论是 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 脚本文件：

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

随着公司业务平台不断扩大，原先数据库服务器上 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 的修复补丁，系统必须重启才能生效。

微软的产品总是非常的神奇，能让你在不经意间发现一些意料之外的事情。我一直觉得使用微软的产品有两个好处，除了它的通用性，另一点就是可以丰富我们的想象力。可见这个公司存在的必然性，除了平时给我们带来一些跨行业的新闻（即娱乐行业新闻），还有助于我们的自身建设。

今天就为了“将 expression 转换为数据类型 int 时发生算术溢出错误”这个问题折腾了一会。

下午的时候，发现我所维护的一个系统中数据存在异常，我直接联想到 SQL 代理可能又挂掉了。连上企业管理器发现它好好的活着，只是几个调度中的某几个存在异常，上次状态是失败：

查看了作业历史记录，看到日志如下：

- 阅读剩余部分 -

前几天趁着数据库维护的时间对 sa 密码做了更换，然后昨天就有人通知我，某查询后台显示的数据有异常。我看了一下那个曲线图果然变得十分难看，可见数据库的某些调度已经停掉了。我初步分析是 SQL Server Agent 挂掉所导致的，打开企业管理器连上数据库，SQL 代理果然停了。重新启动，无效；再试；无效。远程到数据库服务器上查看事件日志，发现刚才的两个操作产生日志如下：

在企业管理器中将 SQL 代理的连接方式改为“使用 Windows 身份验证”，尝试启动 SQL 代理，无效。产生日志如下：

回到刚才的 SQL Server 代理属性界面：

- 阅读剩余部分 -

SQL Server 2000 属于 SQL Server 家族的早期版本，存在较多缺陷。即便 SP4 补丁集可以缓解这个问题，但在安装过程中依然会经常感冒。比较经典的一个问题就是“以前的某个程序安装已在计算机上创建挂起的文件操作，运行安装程序之前必须重新启动计算机”：

随着 SQL Server 2005 的逐步普及、2008 释出 CTP，2000 早已成为了昨日黄花。但很多企业应用依旧部署着低版本的 SQL Server。今天在一台服务器上全新安装 SQL Server 2000，遇到一个“安装程序配置服务器失败”的问题。具体表现为安装程序在复制文件阶段一切顺利，到配置服务器阶段时出现“安装程序配置服务器失败。参考服务器错误日志和 C:\WINDOWS\sqlstp.log 了解更多信息”的提示：

对于这个问题的解决办法，网上有很多说法。我前后折腾了几次，发现这个问题一般只发生在数据文件存储路径被定义在与 SQL Server 程序文件不同目录的时候。所以我们可以这样来折腾：

1、重启服务器。若问题依旧请继续往下；
2、删除 C:\Program Files\Microsoft SQL Server\MSSQL 目录。若问题依旧请继续往下；
3、做好重要数据文件的备份，然后删除安装时定义的数据文件存储目录下的 MSSQL 目录，如 D:\Database\MSSQL。若问题依旧请继续往下；
4、打开 regedit，删除与 MSSQL 有关的数据。若问题依旧请继续往下；
5、将计算机名改为大写。若问题依旧请继续往下；
6、继续 Google，尝试不同解决方式。若问题依旧请继续往下；
7、寻求微软技术支持。若问题依旧请立即离开您的服务器，走出室内，走到一片较为空旷的地方，抬头向上发出由衷的呼唤：“上帝啊，您真神奇”。然后闭幕作祷告状，以诚挚的心感动上帝，愿真主保佑您，真主就在我们身边。