|
锁定老帖子 主题：曾经发生在身边开发过程中的灵异事件
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-27
Lucas Lee 写道 together 写道 Lucas Lee 写道 对于2，我猜可能在sqlserver驱动中有某种参数可以设置？或者换用JTDS或SQLSERVER最新的官方驱动试试？改代码的方式实在不太好，特别是改成一个大SQL的方式。
其实 原来的代码，运行了很久，都是正常的。所以，代码、驱动、数据库都没问题。但问题还是出现了，所以我也只能怀疑是sqlserver的事务处理机制有问题。可能出现这种问题的机率很小吧，或者是在某种特定条件下（诸如服务器硬件、操作系统、其它软件的影响）下，才会出现 。 运行了很久都正常不代表他们就没有隐藏的bug，这不是一回事，你不能由此就只怀疑SQLServer一个地方，所有相关的链条都应该怀疑。 together 写道 引用 对于3，我觉得更奇怪了。明明用SQL客户端是可以正常查询出来的，为什么你就认为是旧的数据库的磁盘性能问题呢？不明白
我到现在也在疑惑呢。我怀疑是磁盘性能的原因，就是因为我新建一个库并把原有数据导入后，它就一切正常了。而在原库基础上，不论你怎么折腾，它就是慢。而且把原有的两个库文件，挪到其它分区，速度一样的慢。 要说真正的原因，估计都是一头雾水。 所以，你搞定了这个问题，这很好；但看来还没有找到根源，这也许不是很重要；唯一我觉得不太好的地方是，不该由此总结出一个不成熟的结论，应该记住解决方案、对猜测的部分仍然保持怀疑。 批评得对！ 欢迎大家发表意见 |
| 返回顶楼 | |
|
发表时间：2006-10-27
together 写道 批评得对！ 欢迎大家发表意见 together老兄的态度很正么！共勉共勉 |
| 返回顶楼 | |
|
发表时间：2006-10-27
2我们遇到过 循环更新的时候 突然数据库连接就断掉 同样的数据我们这边没问题 客户那边就有问题 因为无法去现场 所以我们就加了一些DEBUG给客户 后来客户就没回音了 不知道他们怎么处理的
3我估计是数据库文件里面的结构乱掉了 类似磁盘碎片那种东西吧 |
| 返回顶楼 | |
|
发表时间：2006-10-27
together 写道 欢迎大家继续提供案例和解决方式。
三、系统的查询统计速度极慢 解决方式：创建一个新的数据库，将原库中所有数据导入到新库中。使用新的数据库，查询速度恢复正常。 分析原因：磁盘性能问题，也属于sqlserver自己的问题。 sqlserver数据库，和oracle/db2不同，每一个库中的所有数据，全部保存在mdf/ldf这两个文件中，创建一个新的数据库，将在磁盘上划分一块新的空间，供新库使用。这个新的空间在最初的时候，磁盘性能是不错的。但在经常进行OLAP一段时间之后，数据库内部的检索以及和其它数据库的关联查询性能，可能会大幅降低。具体原因，可能需要去问微软的专家了。 总结一句话：sqlserver真的是不堪大用。它有优点，易用、方便。但在事务完整性上的拙劣表现，让它无法胜任关键业务。 以上全部为事实描述，希望有人可以从中，分析出更具体准确的原因来。 不过以上错误，可能很难重现。把这几个问题解决的过程中，已经把思维发散到了极限。 有没有考虑过数据文件被感染病毒的可能性。WORD文件也会出这样的问题，呵呵。 |
| 返回顶楼 | |
|
发表时间：2006-10-28
3我是遇到过的。而且不止一次。最后的解决方法：
1。sql profiler里面有一个记录query plan的功能，把它打开 2。看query plan，发现从application发过来的query使用的plan非常傻。 3。估计可能是application的driver影响或者是ansi_sql, ansi_null, quoted_identifier之类的古怪参数的不同导致的app和query analyzer的区别。 4。每天都重建stats，bingo。 |
| 返回顶楼 | |
|
发表时间：2006-10-28
ajoo 写道 3我是遇到过的。而且不止一次。最后的解决方法：
1。sql profiler里面有一个记录query plan的功能，把它打开 2。看query plan，发现从application发过来的query使用的plan非常傻。 3。估计可能是application的driver影响或者是ansi_sql, ansi_null, quoted_identifier之类的古怪参数的不同导致的app和query analyzer的区别。 4。每天都重建stats，bingo。 嗯，多谢。我们的这个系统，是一年左右就出现一次这样的问题。快到时间了又。等下次按你说的来试试。 |
| 返回顶楼 | |
|
发表时间：2006-10-28
sql server 的数据库文件按固定值 比如100M增长，根据实际数据调整不要太大，不要用默认百分比。
|
| 返回顶楼 | |
|
发表时间：2006-10-28
wzgme 写道 sql server 的数据库文件按固定值 比如100M增长，根据实际数据调整不要太大，不要用默认百分比。
sorry，我没说清楚。这个库是基本上不增长的，都是一些基础数据，数据量基本上不变。它只是经常参与其它数据库的统计分析操作。 |
| 返回顶楼 | |
|
发表时间：2006-10-29
jobs 写道 问题三是游标的问题。如果你是喜欢动手的人，肯定知道如何解决，否则就不要管了
好多人对这个问题乱猜啊，一看就知道缺少SQL Server应用经验，否则是不会不知道的或者没遇到过的。包括我挺佩服的ajoo，趁这个机会BS一下你  我还真是没有完全弄明白这是怎么回事．cursor也是有可能的，反正app发过来得都是opencursor的命令． 我能确信的就两点： １．app过来的query plan确实很傻． ２．重建统计就解决了问题． jobs知道这个问题的答案，何不分享出来？功德无量地！（btw, 我还是有sql server的使用经验地．google group也查了，没找到答案．于是也只知道乱猜） |
| 返回顶楼 | |
|
发表时间：2006-10-30
jobs 写道 问题三是游标的问题。如果你是喜欢动手的人，肯定知道如何解决，否则就不要管了
好多人对这个问题乱猜啊，一看就知道缺少SQL Server应用经验，否则是不会不知道的或者没遇到过的。包括我挺佩服的ajoo，趁这个机会BS一下你 我本人不是专业DBA，所以没有做过深入的数据库研究。另外本公司的DBA水平也不太强。 想到点什么，顺便再补充一点，由于这个系统主要的工作是统计分析，因此在应用中用到了大量的临时表操作，临时表在统计结束后，会被删除。那是否会是由于经常创建和drop临时表，而导致的opencursor问题呢？ PS：临时表的空间都不会大，主要作用是提高运算速度。 |
| 返回顶楼 | |
