前不久，配置好在IDC机房托管的服务器后，回到公司，想来是可以安心工作了。
没想到过了几天经常发现程序运行不正常。
最后一查之下发现是SQL服务找不到。连上服务器后，发现在SQL服务停了，重新开启，过了几分钟又这是类似情况。反复几次，还是不能解决。只有静下心来研究一下。
结果发现定时会有不同IP向服务器的1433端口发送UDP数据包，就是这些数据包让SQL服务给停了的。
唉，不得不再次说到重庆联通IDC机房的安全问题。算了，言归正转，查了不少资料，发现这是SQL2000的一个安全漏洞，利用这个BUG，向1433发送特殊UDP数据包，可以让SQL服务DOWN了。
解决办法呢？
同样用SQL2000，打补丁了，日本MS发布的有解决些内问题的补丁，可是我偏就是个反日情绪颇高的人，才不想去用这个呢。
再查，再查，终于找到了解决办法，有点麻烦，不过想来也不错，把服务器系统换成WINDOWS2003了，直接一换，就OK了。
可是又有新问题出现了，在2003上的SQL不能远程访问，不远程访问， 我们的客户端程序不能运行呀，现在公司还采用的是B/S结构。
再查，再查，嘿嘿，打上SQL2003 SP3B就行了，注意是SP3B，不是SP3A。SP3A还是不能解决这个问题
其实我解决问题的经验很少，两个字，再查。
没想到过了几天经常发现程序运行不正常。
最后一查之下发现是SQL服务找不到。连上服务器后，发现在SQL服务停了，重新开启，过了几分钟又这是类似情况。反复几次，还是不能解决。只有静下心来研究一下。
结果发现定时会有不同IP向服务器的1433端口发送UDP数据包，就是这些数据包让SQL服务给停了的。
唉，不得不再次说到重庆联通IDC机房的安全问题。算了，言归正转，查了不少资料，发现这是SQL2000的一个安全漏洞，利用这个BUG，向1433发送特殊UDP数据包，可以让SQL服务DOWN了。
解决办法呢？
同样用SQL2000，打补丁了，日本MS发布的有解决些内问题的补丁，可是我偏就是个反日情绪颇高的人，才不想去用这个呢。
再查，再查，终于找到了解决办法，有点麻烦，不过想来也不错，把服务器系统换成WINDOWS2003了，直接一换，就OK了。
可是又有新问题出现了，在2003上的SQL不能远程访问，不远程访问， 我们的客户端程序不能运行呀，现在公司还采用的是B/S结构。
再查，再查，嘿嘿，打上SQL2003 SP3B就行了，注意是SP3B，不是SP3A。SP3A还是不能解决这个问题
其实我解决问题的经验很少，两个字，再查。
