80%以下
数否有大数据集的操作
OR
服务器资源不足,升级

解决方案 »

  1.   

    没有大数据集,完全就是过度频繁
    有没有办法对这种情况进行优化呢?
      

  2.   

    我对大数据集的理解是返回一个记录很多的结果集或者对这样的一个结果集进行操作。
    不知道理解的对么?
      

  3.   

    下列方法有助于最大限度地降低死锁: 按同一顺序访问对象。
    避免事务中的用户交互。
    保持事务简短并在一个批处理中。
    使用低隔离级别。
    使用绑定连接。 
    按同一顺序访问对象
    如果所有并发事务按同一顺序访问对象,则发生死锁的可能性会降低。例如,如果两个并发事务获得 Supplier 表上的锁,然后获得 Part 表上的锁,则在其中一个事务完成之前,另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后,第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。避免事务中的用户交互
    避免编写包含用户交互的事务,因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度,例如答复应用程序请求参数的提示。例如,如果事务正在等待用户输入,而用户去吃午餐了或者甚至回家过周末了,则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量,因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况,访问同一资源的其它事务也会被阻塞,等待该事务完成。保持事务简短并在一个批处理中
    在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长,其持有排它锁或更新锁的时间也就越长,从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中,可以最小化事务的网络通信往返量,减少完成事务可能的延迟并释放锁。
      

  4.   

    有多少用户同时操作?
    有大量的循环/游标吗?
    有大事务?
    是否有等待现象?
      

  5.   

    没有大事务,
    等待现象是指有事务等待处理吗?怎么查看?
    可以肯定的是服务器的处理速度远远跟不上请求速度。
    我想知道的是怎么尽可能的优化