一台业务服务器，最近出现运营系统进程老是无故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。

有关更多信息，请参阅在   的帮助和支持中心。

事件类型: 错误
事件来源: MSSQLServer
事件种类: (8)
事件 ID: 19011
日期:  2008-8-28
事件:  18:27:58
用户:  N/A
计算机: FAMILY-2OPTJ9U4
描述:
SuperSocket 信息: gethostbyname(MSAFD Tcpip [TCP/IP]) : Error 11004。

有关更多信息，请参阅在   的帮助和支持中心。

        根据微软的相关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 重命名计算机名再次测试。

本文转自 苏繁 51CTO博客，原文链接：http://blog.51cto.com/goxia/220523，如需转载请自行联系原作者