处理的方法很简单:
1、并不是所有的地方都需要使用read commit的加锁级别,你从application中设置一句sqlcalock="RU", 使用脏读,这样就可以去掉大多数不必要的SELECT行锁。然后在一定要读最新数据的地方,把SQLCA。LOCK改为RC,用完后再改回来。
这样就避免了几乎80%的阻塞。
2、对于由于行更新,或者其他UPDATE导致的锁,一般数据库会自己协调,在事务比较长的情况下,这需要你对原来的程序做适当的修改。把长事务变为几个小的事务,在事务中做更新 *** 作,不要插入用户的交互。这是系统的设计原则。
如果你的系统对事务的要求不严格,又不想改动原来的程序,办法更简单,在前面
SQLCA。LOCK的基础上,加句SQLCA。AUTOCOMMIT=TRUE,这样每数据修改自动提交,就可以避免大多数由于更新产生的死锁和阻塞。
3、最后要对付的是刚才说的被大量应用频繁访问的表(HOT TABLE),如果你的系统允许使用RU加锁级别,那么不用太考虑,因为SELECT已经不会导致锁定了。
但是如果你不能使用RU方式(1里头提到的办法),
那么要采用这样的手段:
使用索引把更新锁,SELECT锁来分开,同时也避免SQLSERVER傻傻为了性能的原因把行锁升级为表锁。
具体办法是建立一个索引,如果可以的话使用聚集索引,因为聚集索引采用的是类似HASH的检索方式,这样当查找索引的时候,就不需要访问数据表了。
另一种办法,是将你SELECT语句中要检索的数据都加到索引中,例如你检索NAME,SEX,AGE,如果你把三个数据都加入了索引,这就意味着SELECT语句只要找到索引,就已经找到了最后要选取的数据(从索引中),这样自然不会去LOCK表了。这样做的时候要针对你的程序仔细选择索引,否则把索引变成了表的一个备份就没有意义了。
winformconfig文件连服务器数据库启动很慢,解决方法:
1、修改服务器中SQL Server可使用的最大内存。(注意,SQL Server占用的最大内存一般不要超过系统实际内存的50%、最大不要超过75%,以免导致IIS等内存不够,拖累整个OA无法正常使用。)
2、打开 SQL Server 配置管理器(点击:开始-》所有程序--》microsoft SQL SERVER 2005-->配置工具--》SQL Server Configuration Manager),
最后,重新启动SQL Server服务,终于看到了久违的光速了,一切恢复正常,登入SQL Server Management Studio,即使不加端口号,也不影响。登录点晴OA系统也恢复到了正常的速度。
以上就是关于用PB开发的一个数据库服务器多个异地客户端使用查询更新速度慢问题解决的技术方法全部的内容,包括:用PB开发的一个数据库服务器多个异地客户端使用查询更新速度慢问题解决的技术方法、winformconfig文件连服务器数据库启动很慢、等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)