真的真的很急！医院数据库的问题！
我们医院HIS系统是用delphi开发的，因为新的程序刚刚更新好，这几天老是遇到收费处在输入的时候一下子死了，起他门诊的也是，用的数据库是SQL，我想问下这种情况一般是什么原因导致的！谢谢各位了！真的很急！(然后服务器重新启动就好了） 问题点数：0、回复次数：14Top
1 楼sjlxjl（夏天）回复于 2004-12-01 20:57:52 得分 0
关注,看看是软件本身的问题,还是在执行数据库操作的问题?Top
2 楼nicholashuang（）回复于 2004-12-01 21:14:52 得分 0
因为这套系统不是我编的，那个编的人也说不清楚！会不会是比如哪个地方在查询的时候窗口开了太多，然后SQL无法响应其他的查询呢？你们认为这种情况一般是有哪些问题造成的？Top
3 楼yyhyy23（只爱猪猪）回复于 2004-12-02 09:46:22 得分 0
可能有这方面的原因把Top
4 楼WYC2300（无一从）回复于 2004-12-02 09:51:59 得分 0
这个有很多可能的
叫开发的人再调试一下啊
象你说的那个也是很有可能的Top
5 楼huazf（huazf）回复于 2004-12-02 10:54:21 得分 0
专业提供SQL SERVER 修复,SQL恢复,误删除表,SQL 数据恢复,SQL SERVER 数据库恢复修复,SQL 找回业务。
QQ:386999
TEL:0576-2454863
Top
6 楼gslrq（[夜归人]http://www.west998.com/）回复于 2005-01-16 16:36:02 得分 0
应该是软件设计的问题!
可能是在事务中加了msgbox 之类的东西使表死锁造成的!Top
7 楼MonkTong（MonkTong）回复于 2005-01-16 20:22:02 得分 0
你这个问题一般来讲是锁的堵塞或者死锁问题引起的。
可以这样观察：
1、当输入费用的时候，在查询分析器中利用sp_lock，看是否存在锁;
2、如果有的话，可以通过object_id，得到当前锁住的表
select object_id(表的ID）;必须选择当前的业务数据库
3、查看当前被锁的表是否与收费的业务有关系。
4、如果没有的话，是否是大的查询引起系统响应速度慢。
建议在程序里使用显式的事务提交，即在事务开始写明begin tran，在事务结束或故障处理的时候写明commit和rollback.
Top
8 楼zhtln（学sql ）回复于 2005-01-17 10:40:32 得分 0
你说的情况应该是死锁产生的,估计此时有大数据的操作共同调用收费表,
还有就是sql server 要设置内存的使用限制.保留一部分给操作系统.Top
9 楼hglhyy（為人民币服务！）回复于 2005-01-17 17:50:04 得分 0
同前面的一样，我个人认为这应该是事务造成的死锁。
有可能同时运行几个大的查询之类的，同时又在给表写数据。
楼主可以在每次出现问题的时候，看看能不能进入企业管理器，看下进程和锁，看有没有发现！！Top
10 楼seayar（习习）回复于 2005-01-17 19:56:24 得分 0
upTop
11 楼cgsun（colin）回复于 2005-01-17 20:13:26 得分 0
识别死锁原因
例如，可以创建一个跟踪来捕获与 TSQL 和 Stored Procedure 事件类（RPC:Starting 和 SQL:BatchStarting）以及 Locks 事件类（Lock:Deadlock 和 Lock:Deadlock Chain）相关的事件。在这个跟踪内包括所有数据列并按 Event Class 分组。如果想一次只监视一个数据库，为 Database ID 事件准则指定一个值。
若要查看死锁所涉及的连接，执行下列操作之一：
打开包含捕获的数据的跟踪，按 ClientProcessID 将数据分组并展开死锁所涉及的两个连接。
将捕获的数据保存到一个跟踪文件，然后打开这个跟踪文件两次，使其显示在两个单独的 SQL 事件探查器窗口内。按 ClientProcessID 将捕获的数据分组，然后展开死锁所涉及的进程 ID；每个死锁连接都在一个单独的窗口内。平铺窗口以查看导致死锁的事件。
有沒有死锁Top
12 楼cgsun（colin）回复于 2005-01-17 20:14:07 得分 0
了解和避免阻塞
当来自应用程序的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另一个连接。
说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。
大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其它进程上等待锁。
常见的阻塞情形包括：
提交执行时间长的查询。
长时间运行的查询会阻塞其它查询。例如，影响很多行的 DELETE 或 UPDATE 操作能获取很多锁，这些锁不论是否升级到表锁都阻塞其它查询。因此，一般不要将长时间运行的决策支持查询和联机事务处理 (OLTP) 查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的计算机上运行查询。
查询运行时间长并由此导致阻塞的一个原因是这些查询不适当地使用游标。游标可能是在结果集中浏览的便利方法，但使用游标可能比使用面向集合的查询慢。
取消没有提交或回滚的查询。
如果应用程序取消查询（如使用开放式数据库连接 (ODBC) sqlcancel 函数）但没有同时发出所需数目的 ROLLBACK 和 COMMIT 语句，则会发生这种情况。取消查询并不自动回滚或提交事务。取消查询后，所有在事务内获取的锁都将保留。应用程序必须提交或回滚已取消的事务，从而正确地管理事务嵌套级。
应用程序没处理完所有结果。
将查询发送到服务器后，所有应用程序必须立即完成提取所有结果行。如果应用程序没有提取所有结果行，锁可能会留在表上而阻塞其他用户。如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做（如果无法配置它执行此操作），则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft® SQL Server™ 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
对每个查询使用查询超时。
对每个查询使用锁定超时。有关更多信息，请参见自定义锁超时。
使用绑定连接。有关更多信息，请参见使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制（并对锁负责）。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
不要使用或设计使用户得以在事务内输入内容的应用程序。
允许取消查询。
使用查询或锁定超时，防止失控查询和避免分布式死锁。
立即完成提取所有结果行。
使事务尽可能简短。
显式控制连接管理。
在所预计的并发用户全负荷下对应用程序进行应力测试。
Top
13 楼zheng518（Richard）回复于 2005-01-18 11:28:03 得分 0
我认为是程序设计的原因，一是本身设计在使用中出现bug,另外原因可能是整个系统设计的原因，就像楼上那位所说。不过具体原因就看你的分析和那位程序员的调试才能发现。Top
14 楼winternet（冬天）回复于 2005-01-18 11:37:19 得分 0
如果網絡方面沒有問題，估計是SQLServer對表操作鎖的原因引起，其次就是程序本身的循環原因造成。Top
