loading金蝶K/3产品性能稳定性案例集
2) 启用设置套打格式。
3) 纸张的设置可在客户端的打印机上设置。请检查以下设置：Management Console
——>Printer Management——>Properties——>Printers——>inherit client printer's setting for keeping printered documents是否勾选？选择该项，可延用客户端的打印设置。
2.2 数据库性能问题案例
2.2.1 通用案例1—-数据库日志文件过大 1、问题描述：
客户数据库的LOG文件非常大，达到680M（实体文件是2.6G左右），做过数据库压缩、数据库剥离，重新建了日志文件后速度变快，如此反复了两次，现在又慢了下来。导致客户端运行速度非常慢，严重时连一个客户端都进不去。
2、问题分析：
该问题是由于没有把数据库的故障还原设置为简单，导致数据库LOG文件很大，影响数据库性能，可以对数据库做一些优化设置来处理。
3、解决方法：
1) 把数据库的故障还原设置为“简单”(注意:该故障还原模式下数据库不能进行事
务日志备份)。 2) 数据库分离附加〔采用日志分离的方式减少日志文件的大小：首先在“SQL SERVER
企业管理器”分离数据库, 然后删除此数据库的日志文件(*.ldf),最后再重新附加数据库〕。
3) 数据库收缩（在数据库服务器进行数据库实体收缩）。
4) 检查二次开发的触发器和存储过程是否存在批量更新数据库不严谨造成日志文
件增大（关键）。
5) 执行下面附件的SQL，核对一下是否有的表占用的空间过大没有释放，可以优化
一下此表的索引结构，保存此表后可以把过多的空间释放出来。
2.2.2 通用案例2—-数据文件大小不正常 1、问题描述：
SQL Server的数据文件变得不正常，大小和客户的数据量从经验上很不相符，这种异常会很大地影响系统性能，还有可能引发错误。 2、问题分析：
该问题主要是由于有些表没有建立聚集索引引发，需要运行工具来分析检查。 3、解决方法：
运行下面工具：
6
金蝶K/3产品性能稳定性案例集
它可以生成一个EXCEL表格K/3DATA.xls，记载了数据库中所有表的使用空间大小，重点关注Reserved, Unused列，如果发现与记录数应有的数据量有很大的差异，可以看看这些表是否有聚集索引，如果没有,则建立聚集索引，收缩数据库，数据库的数据文件会缩小很多。注意:此工具需要在安装有K/3客户端的机器上运行。
2.2.3 通用案例3—-Tempdb日志过大 1、问题描述：
Tempdb数据库文件出现大幅度增长，甚至达到3-4GB，从而导致K/3整体功能下
降
2、问题分析：
SQL Server 2000对于TempDB的处理是采用SQL Server Cache Buffer Manager来管理，而不再是象SQL Server 7.0一样可以使用TempDB In RAM的，这样，在高并发情况下，由于SQL Server的后台进程不能及时调度，造成TempDB的容量迅速增大（由初始的8MB增长到性能测试时的800MB），从而导致 Cache Hit Ration迅速下降造成对TempDB的 Pages Reads/Sec和Pages Writes/Sec狂飙造成的。
TEMPDB增长的同时也会导致内存使用的增长，由于内存以及物理空间的资源使用，从而导致系统的整体性能下降。
3、解决方法：
收缩TEMPDB数据库，可以采用下面几种方式，最好做一个定期执行计划 方法一
? 重启SQL SERVER服务
? ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev', SIZE = 需
要收缩的大小)
? ALTER DATABASE tempdb MODIFY FILE (NAME = 'templog', SIZE =需
要收缩的大小)
方法二
? sp_spaceused @updateusage=true
? dbcc shrinkdatabase (tempdb, '百分比') 方法三
? dbcc shrinkfile (tempdev, '需要收缩的大小') ? dbcc shrinkfile (templog, '需要收缩的大小')
4、建议
1) 将tempdb 数据库文件的初始大小设置为合理的大小，以避免当需要更多空间时
文件自动扩展。如果tempdb 数据库扩展得过于频繁，性能会受不良影响。 2) 如果需要使用数据库文件按百分比增长，将文件增长增量百分比设置为合理的大
小，以避免 tempdb 数据库文件按太小的值增长。如果文件增长幅度与写入 tempdb 数据库的数据量相比太小，则 tempdb 数据库可能需要始终扩展，因而将妨害性能。
3) 最好设置数据库文件的增长方式为按指定的字节数方式，建议设置为200MB。 4) 将 tempdb 数据库放在快速 I/O 子系统上以确保好的性能。在多个磁盘上条带
化 tempdb 数据库以获得更好的性能。使用文件组将 tempdb 数据库放在除用户数据库所使用的磁盘之外的磁盘上。
2.2.4 通用案例4—-数据库服务器硬件问题
7
金蝶K/3产品性能稳定性案例集
1、问题描述：
物流的出入库单据都不能保存。 2、问题分析：
根据现场描述的情况，进行同样的操作，发现业务能正常处理，怀疑数据库服务器存在问题，让现场提供数据库服务器的事件日志和数据库日志，发现存在下面的错误信息。
事件日志： Envet id:17055 Envet id:17052
错误: 823，严重度: 24，状态: 2
I/O error (bad page ID) detected during read at offset
0x0000000224a000 in file 'E:\\DataBase\\AIS20050529165714_Data.mdf'. Event id:19011
SuperSocket 信息: ConnectionListen(Shared-Memory (LPC)) : Error 5。 事件 ID ( 4194 )的描述(在资源( COM+ )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分:
组件 Prog ID: 服务器应用程序 ID: {DAE39E2A-3C8D-49DC-9BFB-1611078F4940}服务器应用程序名称: eboK/3
该错误的严重性已导致进程终止。 异常: C0000005 地址: 0x6A388318 调用堆栈: ,
MSVBVM60!__vbaVarDup + 0x6C4E OLEAUT32!DispCallFunc + 0x15D
MSVBVM60!BASIC_CLASS_Invoke + 0x259 MSVBVM60!BASIC_CLASS_Invoke + 0x52
OLEAUT32!UserEXCEPINFO_free_local + 0x57D
Envet id :4193 Source:msdtc
资源管理器执行了恢复操作并调用了 ReenlistmentComplete，说明恢复过程已完成。 但至少一个通过资源管理器登记的事务的状态仍然是“不确定”
数据库：
2006-03-17 08:53:28.64 spid16 表错误: 对象 ID 1384001053，索引 ID 0，页 (1:41775)。测试（IS_ON (BUF_IOERR, bp->bstat) && bp
2006-03-17 08:53:28.64 spid16 表错误: 对象 ID 1384001053，索引 ID 0，页 (1:41775)。测试（IS_ON (BUF_IOERR, bp->bstat) && bp
2006-03-17 08:53:28.65 spid16 表错误: IAM 页 (1:41775)（对象 ID 1384001053，索引 ID 0）超出了此数据库的范围。 使用DBCC CHECKDB出现下面信息：
2006-03-17 12:57:55.95 spid15 表错误: 分配页 (0:67108864) 的
8
金蝶K/3产品性能稳定性案例集
IAM_PAGE 页首结构值无效。类型为 0。请检查该页上的类型、对象 ID 和页 ID。 3、解决方法：
根据上面的日志，查看微软网站相应的说明，由于使用DBCC CHECKDB存在无法修复的情况，这种情况可以排除是数据系统本身的原因，因为在硬件系统方面。建议客户将服务给硬件提供商检查，检查后发现导致该问题的原因在于硬盘系统存在问题。 微软网站关于错误的说明文档见：
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
http://support.microsoft.com/kb/q221926/
2.2.5 通用案例5—-系统整体运行速度非常慢 1、问题描述：
客户反馈，当前网速为10M，整体系统运行速度非常慢，例如审核一张单据，从查到该单据，到审核完毕，时间在5分钟左右才可以完成，中间仍会经常断掉，需要重新登陆，已经制约了部分业务的进行。 2、问题分析：
1) K/3系统数据全部都在一个数据库中，长期以来，积累了大量的数据，包括：仓
存管理业务数据、作业成本数据、财务数据等等信息，都在里面长期存放，目前数据库已有8G（包括日志文件）；
2) 网速目前为10M，可能对此有部分影响，但已满足系统运行要求；
3) 作业成本的数据表设计是否存在性能问题，账套一直在无限地增加数据量，这里
讨论是一种加速度的增加，即每年账套数据量增加呈递增状。 3、解决方法：
1) 请事先备份好数据（如果数据是完全备份，不是增量备份和日志备份），再把数
据库属性在企业管理器里的故障还原设置为“简单”； 2) 执行【BACKUP LOG 数据库名 with nolog】 截断日志； 3) 打开“企业管理器”点击右键－>所有任务－>收缩数据库；
4) 在中间层优化账套（打开“账套管理”－>数据库－>优化账套）,或者通过建立
索引维护计划进行优化账套；
5) 用户操作建议:单据查询时，设置精确的过滤条件，以提高查询效率，尽可能避
免由于大数据量的读取IO操作导致性能下降；修改序时簿的过滤条件，取消关联标志，钩稽标志等的显示，因为这块耗时过多，特别是涉及到多单据的关联字段；尽量在序时簿里把不重要的字段隐藏不显示。；
6) 检查表t_locktable是否存在主键，如果没有，请设置FinterID做为主键； 7) 执行下面附件的SQL，核对一下是否有的表占用的空间过大没有释放，可以优化
一下该类表的索引结构，把过多的空间释放出来；
8) 对于查询比较慢的单据可以把SQL跟踪出来，然后用查询分析器运行索引优化向
导，序时簿相关关联表增加索引； 9) 考虑结转新账套；
10) 增加数据库服务器硬件配置。
9