曾经发生在身边开发过程中的灵异事件

批评得对。我的本意，是还没有牵涉到server端的日志和debug。


对于问题2,是有正解的。

问题2是不是要在begin transaction前先执行set xact_abort on呢?

已经加过了。这个选项只需设置一次。

欢迎大家继续提供案例和解决方式。
现在解释一下最初三个问题的解决方法：
一、客户无法登录系统
解决方法：清空存放php session的目录
分析原因：个人猜测这与php的session处理机制有关系。它的session会统一放在一个文件夹中，每个session对应一个文件。session失效后文件也会删除。

有可能是php的session有部分记忆功能，在session中会记录用户的IP地址，当某些IP段的用户来访问时，可能造成session管理混乱，导致无法创建正确的session文件。
这个原因我说不太具体，但是在公司的两个网站上确实每两年就出现一次。有过类似经历的可以具体指导一下。

二、数据库事务部分失效
解决方法：将所有的sql（约千条左右），拼成一个大sql（oracle不支持这种拼接方式），最终将拼接后的sql一次提交执行。数据完全入库。

分析原因：应该是sqlserver数据库本身的事务处理机制不够完善。在access数据库中也出现了类似的问题。就是说，在事务中间，执行每一条sql都没有报错，但有可能会在最后的commit过程中，由于磁盘或者网络的原因，导致某些数据没有正式写入数据库。由于sqlserver2000是继承自7.0,而7.0是微软全新开发的数据库，并不像oracle一样有一个长期的积累和完整的版本过渡。因此sqlserver7.0/2000一直不太让人放心。

友情提示：执行大数据量处理时，如果可能最好一次提交所有的sql，这样大大减少和数据库服务器的交互，也降低了出错的机率。

三、系统的查询统计速度极慢
解决方式：创建一个新的数据库，将原库中所有数据导入到新库中。使用新的数据库，查询速度恢复正常。
分析原因：磁盘性能问题，也属于sqlserver自己的问题。
sqlserver数据库，和oracle/db2不同，每一个库中的所有数据，全部保存在mdf/ldf这两个文件中，创建一个新的数据库，将在磁盘上划分一块新的空间，供新库使用。这个新的空间在最初的时候，磁盘性能是不错的。但在经常进行OLAP一段时间之后，数据库内部的检索以及和其它数据库的关联查询性能，可能会大幅降低。具体原因，可能需要去问微软的专家了。

总结一句话：sqlserver真的是不堪大用。它有优点，易用、方便。但在事务完整性上的拙劣表现，让它无法胜任关键业务。

以上全部为事实描述，希望有人可以从中，分析出更具体准确的原因来。
不过以上错误，可能很难重现。把这几个问题解决的过程中，已经把思维发散到了极限。

我看你的解决方式也够诡异的...赫赫
虽然可能不需要这么做，或者说有更好的方式；但不过不管怎么样，绕也绕过去了，实际工作中能到这个地步也不容易了。

对于2，我猜可能在sqlserver驱动中有某种参数可以设置？或者换用JTDS或SQLSERVER最新的官方驱动试试？改代码的方式实在不太好，特别是改成一个大SQL的方式。

对于3，我觉得更奇怪了。明明用SQL客户端是可以正常查询出来的，为什么你就认为是旧的数据库的磁盘性能问题呢？不明白

其实 原来的代码，运行了很久，都是正常的。所以，代码、驱动、数据库都没问题。但问题还是出现了，所以我也只能怀疑是sqlserver的事务处理机制有问题。可能出现这种问题的机率很小吧，或者是在某种特定条件下（诸如服务器硬件、操作系统、其它软件的影响）下，才会出现 。


我到现在也在疑惑呢。我怀疑是磁盘性能的原因，就是因为我新建一个库并把原有数据导入后，它就一切正常了。而在原库基础上，不论你怎么折腾，它就是慢。而且把原有的两个库文件，挪到其它分区，速度一样的慢。

要说真正的原因，估计都是一头雾水。

再补一个：
由于客户众多（几万家），所以报的错也是五花八门。
有一个表单提交(post)，有很多小数据项，大概有三四十项的数据吧。提交后台保存，一般都没什么问题。但是就是有几个客户反映，他们一提交，后台程序就报错（前台javascript并没报错），提示他们要先输入数据。

我们这边做测试，填入和客户一模一样的数据，不报错啊！由于这样的客户较少，也找不出原因来，关键是无法重现这种错误！


N久以后，才终于知道为什么。再碰到类似的问题，客服就问对方：“请问您是否安装了瑞星或者金山毒霸？”，对方回答是。客服：“请您把它卸载之后再试试”。乖的客户就听话，卸载，没问题。有比较刁的客户，就死活不干，那意思就咬定是我们的系统的问题了，人家那么有名的杀毒软件，而且以前也用它们来杀毒，都没问题，怎么现在会有问题呢？？？

原因在哪里？个人分析，这两种杀毒软件都有自动更新功能，在某个版本升级之后，可能启动了额外的防火墙机制，将提交数据大于多少K的请求给屏蔽掉。由于我们的表单中数据项比较多，因此一次提交的请求中会有约几K的数据，可能会被杀毒软件屏蔽，造成数据无法提交。国外的norton/mcafee/kapasky，都没有这样的问题

微软的windows2003server，就搞了一个这么东西，IIS6默认的上传文件最大为200K，这够干什么的啊？结果大家只好都去改配置文件。他也不事先告诉你，幸好这世界上有一个google。国内的这几个杀毒厂家，好的不跟人学，专门学这些偷偷摸摸的东西，厉害一点搞得你连网都上不了。曾经有一个大客户报告说我们的系统死活都用不了了，结果现场一看，人家刚装了一个金山网镖，会自动屏蔽所有非IE发出的对外的HTTP请求。

为啥把杀毒写成杀素 ? 看了挺别扭

是的，现在网络环境乱了，B/S想要零客户端维护是不可能了，那些流氓软件、杀毒软件、防火墙什么玩意的，都可能是你的麻烦。

运行了很久都正常不代表他们就没有隐藏的bug，这不是一回事，你不能由此就只怀疑SQLServer一个地方，所有相关的链条都应该怀疑。



所以，你搞定了这个问题，这很好；但看来还没有找到根源，这也许不是很重要；唯一我觉得不太好的地方是，不该由此总结出一个不成熟的结论，应该记住解决方案、对猜测的部分仍然保持怀疑。