一台业务服务器,最近出现运营系统进程老是无故100%的CPU占用,导致系统执行效率低下。经过厂商排错确认是由于服务器上的 SQL Server 2000 引起的,停止与 SQL Server 2000 的挂接,运营系统故障消失。那么,接下来的工作就是要对 SQL Server 2000 作 Troubleshooting 。
        可用的参考信息非常少,因为日志中始终只有如下两个日志:

事件类型: 警告
事件来源: MSSQLServer
事件种类: (8)
事件 ID: 19011
日期:  2008-8-28
事件:  18:27:58
用户:  N/A
计算机: FAMILY-2OPTJ9U4
描述:
SuperSocket 信息: (SpnRegister) : Error 1355。
有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
事件类型: 错误
事件来源: MSSQLServer
事件种类: (8)
事件 ID: 19011
日期:  2008-8-28
事件:  18:27:58
用户:  N/A
计算机: FAMILY-2OPTJ9U4
描述:
SuperSocket 信息: gethostbyname(MSAFD Tcpip [TCP/IP]) : Error 11004。
有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。

        根据微软的相关KB及搜索出来的其它资料均进行了测试,结果都以失败告终。SQL Server 也重新进行了安装。经过一番测试,发现 SQL Server 2000 始终无法套接到 TCP/IP 上,自然也就无法绑定 TCP1433,经过两天的摸索最终重点放在了 SuperSocket 信息: (SpnRegister) : Error 1355 ,这条警告日志经常出现在工作组环境之下,微软就此问题已经证实属于产品问题。由于另外一个日志中也提到了有关主机名的问题“gethostbyname”,那么可以断定由于 SQL Server 无法正常获取注册到的 SPN 而导致最终的失败,继续详细检查系统,发现当前计算机名与 SQL Server 下连接的名称不符,即当前计算机名是 NS4,而 SQL Server 连接的是 FAMILY-2OPTJ9U4,难道问题出在这里。随即将 SQL Server 安全卸载,并将计算机名重新进行命名。故障消失……
        回忆这个问题起因,让人费解,因为在修改计算机名是很早以前做的,而之后 SQL Server 运行也一直良好,不过总算问题得到了最终的解决!计算机名在本场景中不属于必要的,所以恢复旧计算机名不会对运营系统造成干扰。有机会,我将使用 netdom 重命名计算机名再次测试。