| 问题原因： |
由于数据库大小达到了6个多G,多个数据表中数据记录均已达到数万几十万条(例如rdrecord/s,dispatchlist/s,salebillvouch/s),且该数据库设计时没有考虑到数据量过大的情况,未设计成多文件形式的数据库(即数据库由一个主文件和多个次文件,以及一个日志文件构成,次文件可以放在不同的物理磁盘上,分别存储不同的数据表和数据,可以大大提高数据库的访问效率和操作性能.其中主文件后缀名未.mdf,次文件后缀名为.ndf,日志文件后缀名为.log),目前该数据库仅由一个主文件和一个日志文件构成. 在对数据库进行查询修改等数据交互操作时,sqlserer为了优先实现操作效率,尽可能的占用系统资源,可能会导致网络"假"中断,系统暂时性的没有响应. |
| 解决方案： |
修改操作时,点击修改按钮后,焦点转移到表体记录行时,系统需要执行现存量查询存储过程等等,与sqlserver之间进行的数据交互操作较为频繁,从而出现较长时间等待的现象.
另外效率较慢也可能与以前版本产品821的数据库结构设计有关,数据库结构设计的是否合理,数据表索引是否完善,表间关联关系是否合理,存储过程触发器是否充分优化效率,产品程序是否充分优化等等,这些都可能会影响到产品运行效率,特别是数据量较大时体现的较为明显.
提高效率问题主要涉及到两个方面，一是数据库性能优化，而是产品性能优化。
产品性能优化方面，对此类系统效率问题不大可能在821版本上给予改进,因为改进操作涉及到数据库结构设计问题,相当于重新设计产品数据架构,以及重新开发部分产品程序,耗时耗量非常巨大,不是一两个月就能解决的问题,基本上相当于开发一个新的版本.
数据库性能优化方面，目前的处理方法如下:
1.首先对数据库进行整理,删除其中的一些无效数据表,减少数据库中数据量，如temp...开头的临时表等等;
2.其次对数据库进行dbcc修复检查,操作步骤以及注意事项如下:
{
可在查询分析器中执行下面语句来对整个数据库进行修复：注：运行该语句前请不要打开可能涉及该数据库的一切程序,用实际的数据库名成代替如下所有英文脚本部分中的"database_name".
1在运行修复数据库语句之前应必须先将数据库处于单用户模式下才可以进行修复：
sp_dboption @dbname = ‘database_name‘
, @optname = ‘single user‘
, @optvalue = ‘true‘
use database_name
go
2执行修复数据库语句：须反复多次执行该修复数据库语句，直到检测结果为“CHECKDB 发现了 0 个分配错误和 0 个一致性错误在数据库datebase_name‘ 中”方可执行完毕。
DBCC CHECKDB
‘database_name‘,REPAIR_ALLOW_DATA_LOSS
3在运行修复数据库语句之后还必须将数据库还原为非单用户模式，执行下面语句：
sp_dboption @dbname = ‘database_name‘
, @optname = ‘single user‘
, @optvalue = ‘false‘
use database_name
go
注意：在全部语句执行完毕后，可再用检查数据库语句 dbcc checkdb ‘database_name‘ 对其检测，若仍存在问题，需反复执行修复数据库语句。执行修复语句后必须将数据库还原为非单用户模式。
特别提示：由于在执行该修复数据库语句的过程中存在丢失数据的风险，请慎重使用！敬请您在使用该修复语句之前一定要作好数据备份工作！！
}
3.建议使用,敬请做好数据备份对目前已有的数据库主文件ufdata.mdf限制其大小增长,从数据库属性中{数据文件}页签中修改文件属性即可.同时新增数据库文件此时新增数据库文件为次文件*.ndf,文件名可自定义,文件位置应选择放置在不同的物理磁盘空间上,分配空间按默认值即可,文件组默认选择"Primary",文件属性定义为自增长即可.
由于我们的数据库知识水平有限,更好的数据库优化方案可访问咨询微软的sqlserver技术支持和其官方网站.
4.建议尝试升级到850或者851,在850/1版本中对效率专门做了测试优化,对大数据帐套也做过专门的测试,并根据测试结果进行效率优化.从数据库结构角度而言,850/1版本与821版本改动较大,基本上是重新设计定义数据库结构的. |