金蝶K3WISE V13产品性能稳定性优化指导手册（常见问题） - 图文(4)

金蝶K/3产品性能稳定性优化指导手册

2. 数据库服务器内存居高不下 首先明确，K/3中数据库服务器的内存只上升，不下降，不是我们的软件问题，而是SQL Server使用内存的策略造成，是正常现象，相关的内容可以在微软的技术支持网站上查到http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_config_9zfy.asp

3. 数据库服务器内存配置

数据库的物理内存一般来说越大越好，由于考虑到成本问题，需要对用户未来的业务有一个估计，业务数据量和业务的频繁度可以作为配置服务器硬件的一个依据。数据量对数据库服务器的内存配置有直接的影响，从经验的数字来说最好是物理内存要大于账套的数据文件，如果账套数据文件小于1G，应该配置至少1G内存，如果账套数据文件大于1G, 物理内存应该和数据文件大小相当，例如账套数据文件为2.4G,那么应该配置至少2-3G内存。 4．如果物理内存超过4GB，请参照附录中《SQL Server 的大内存管理》设置 4.1.1.3 数据库实例默认选择【并行】导致死锁和阻塞问题 1：由于启用了【并行】可能导致死锁。主要表现为同一功能，隔一段时间就会出现死锁，此时客户端现象为：

如果出现这样的情况时，请在SQL 查询分析器中执行dbcc traceon(1204,3605，-1)【SQL SERVER 2000跟着标记为1204，SQL SERVER 2005中为1222】，将死锁的信息记录到数据库的日志中。然后等待场景重现，再出现后这时候运行数据库的企业管理器，查看数据库的日志，将会看到类似下面的信息：

ResType:LockOwner Stype:'OR' Mode: S SPID:64 ECID:13 Ec:(0x8E0480C0) Value:0xaa

Requested By: Owner:0xa9617ba0 Mode: S Flg:0x0 Ref:1 Life:00000001 SPID:64 ECID:14 Wait List:

PAG: 16:1:319244 CleanCnt:5 Mode: IX Flags: 0x2 Node:4

Producer: Xid Slot: 7, EC = 0x8d26a0c0, SPID: 64, ECID: 16, Blocking Producer: Xid Slot: 5, EC = 0x8dffc0c0, SPID: 64, ECID: 14, Blocking Producer: Xid Slot: 4, EC = 0x8b6ae0c0, SPID: 64, ECID: 15, Blocking Producer: Xid Slot: 3, EC = 0x8e0480c0, SPID: 64, ECID: 13, Blocking Producer List::

Consumer: Xid Slot: 6, EC = 0x8b4dc0c0, SPID: 64, ECID: 2, Not Blocking Consumer: Xid Slot: 2, EC = 0x8db4e0c0, SPID: 64, ECID: 4, Not Blocking Consumer: Xid Slot: 1, EC = 0x8deb80c0, SPID: 64, ECID: 3, Not Blocking Consumer: Xid Slot: 0, EC = 0x8a00e0c0, SPID: 64, ECID: 1, Not Blocking Consumer List::Coordinator: EC = 0x8885d560, SPID: 64, ECID: 0, Not Blocking

Port: 0x800b0480 Xid Slot: 0, EC: 0x8a00e0c0, ECID: 1 (Consumer), Exchange WaiNode:3

这样可以确定是“涉及并行的死锁”，即SPID为64的进程出现了自我阻塞而导致的死

- 16 -

金蝶K/3产品性能稳定性优化指导手册

锁，该死锁主要是SQL SERVER执行的策略上的问题，SQL语句的写法上可以解决，但在不同的服务器上可能有不同表现，所以通过禁用并行来解决。如果要开启处理器支持并行计划，请确保数据库服务器的配置足够好【如16CPU【物理CPU】，32GB内存】 解决办法：

如果是早期超线程的机器，需要关闭超线程，修改CMOS

a)：开机--〉进入BIOS设置画面 b)：将HYPER-THREADING设为DISAB

取消并行执行；

sp_configure 'show advanced options', 1

RECONFIGURE GO

sp_configure 'max degree of parallelism',1 GO

sp_configure 'show advanced options', 0 RECONFIGURE

根据提示，重启数据库服务

4.1.1.4 与17883错误相关

如果出现数据库HANG，查看数据的日志文件，可以看到类似下面的信息： server 错误: 17883，严重度: 1，状态: 0

DBCC TRACEON 208，服务器进程 ID (SPID) 60。 server

进程 191:0 (8d0) UMS 上下文 0x074BECC8 似乎不是在调度程序 0 上生成的。

出现上面的问题时，可以确认是SQL SERVER本身的问题，产生该问题的原因比较多，微软提供的补丁SP4也未能解决所有的17883问题。

解决方式：（本补丁只针对SP4）

http://hotfixv4.microsoft.com/SQL Server 2000/sp4/SQL_Server2000_SP4_Hotfix2171/08.00.2171.00/free/255994_CHS_i386_zip.exe

Password: lUn)1p3h

如果SQL SERVER已经出了最新的补丁，则直接升级到最新的补丁即可。

相关17883问题描述：请查看微软网站的815056，319892，810885等文章

4.1.2 数据库维护策略不当

对于任何一个数据库系统，日常的维护是必要的，在日常的系统维护中分支机构应该引导客户的系统管理员做维护，防性能问题于未然。

但有时候不当的维护策略也对性能造成一定的影响。结合常见维护策略进行介绍，旨在防性能问题与未然。

在应用K/3时为了提升整体应用性能，数据库需要做如下的维护策略：

4.1.2.1 设置数据库故障还原模型为“简单”

在SQL Server企业管理器中选择一个数据库，右键点击弹出快捷菜单，选择“属性”,如下图界面。数据库的故障还原模型建议使用“简单”模式。

如果采用“简单”以外的故障还原模式，将可能产生大量的日志文件从而影响数据库系统性能

注意：选择简单模式后数据库将不能做事务日志备份。

- 17 -

金蝶K/3产品性能稳定性优化指导手册

4.1.2.2 取消“自动收缩”数据库选项

将数据库“属性”中的“自动收缩日志”选项取消（如2.1.2.1下图）。由于需要频繁检查数据库的空间使用情况以及自动收缩有可能发生在数据库文件自动增长之后而增加额外的开销。

4.1.2.3 定期收缩数据库

SQL Server数据库的事务日志会由于各种原因，有时候暴涨，事务日志太大有时候会引发性能问题，因此要有计划地收缩数据库来缩小事务日志。收缩数据库时不但要收缩账套数据库，同时也要收缩SQL Server自带的TEMPDB数据库。可以通过SQL Server企业管理器做一个收缩计划，在没有业务运行的时候定期做收缩，尽量不要在平时做收缩操作，因为收缩操作耗用资源很多，且需要一段时间。

在SQL Server企业管理器中选择一个数据库，右键点击弹出快捷菜单，选择“所有任务”---〉“收缩数据库”,如下图界面。

- 18 -

金蝶K/3产品性能稳定性优化指导手册

选择根据本调度来收缩数据库(收缩的频率不要过于频繁，否则容易产生更多的碎片，导致数据库性能更差)，然后点击更改按钮，如下图界面做调度安排。

4.1.2.4 定期优化帐套

在SQL Server运行一段时间后，表空间和索引的存储可能会产生碎片，这会极大的影响系统的性能。数据库表是否存在碎片可以通过在SQL查询分析器中使用下面的命令来查看：

如：dbcc showcontig(icstockbill) 显示结果为

- 19 -

金蝶K/3产品性能稳定性优化指导手册

DBCC SHOWCONTIG 正在扫描 'ICStockBill' 表... 表: 'ICStockBill'（1180583294）；索引 ID: 1，数据库 ID: 15 已执行 TABLE 级别的扫描。 - 扫描页数.....................................: 9935 - 扫描扩展盘区数...............................: 1252 - 扩展盘区开关数...............................: 8485 - 每个扩展盘区上的平均页数.....................: 7.9

- 扫描密度［最佳值:实际值］....................: 14.64%［1242:8486］ - 逻辑扫描碎片.................................: 41.35% - 扩展盘区扫描碎片.............................: 60.46% - 每页上的平均可用字节数.......................: 3763.6 - 平均页密度（完整）...........................: 53.50%

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

可以看出icstockbill表的扫描密度为14.64%，逻辑扫描碎片为41.35%；扩展盘区扫描碎片为60.46%说明存在较多的碎片，并且统计信息很多记录都未进行更新，这将严重影响使用该表时的查询速度，需要对该表进行重建索引。那么我们使用dbcc dbreindex(icstockbill)对icstockbill表重建索引，再对icstockbill表进行统计可以看到下面的结果：

DBCC SHOWCONTIG 正在扫描 'ICStockBill' 表...

表: 'ICStockBill'（1180583294）；索引 ID: 1，数据库 ID: 15 已执行 TABLE 级别的扫描。

- 扫描页数.....................................: 5444 - 扫描扩展盘区数...............................: 682 - 扩展盘区开关数...............................: 681 - 每个扩展盘区上的平均页数.....................: 8.0

- 扫描密度［最佳值:实际值］....................: 99.85%［681:682］ - 逻辑扫描碎片.................................: 0.00% - 扩展盘区扫描碎片.............................: 29.91% - 每页上的平均可用字节数.......................: 189.7 - 平均页密度（完整）...........................: 97.66% DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

可以看出icstockbill表的扫描密度为99.85%，逻辑扫描碎片为0.00%；扩展盘区扫描碎片为29.91%，数据页从原来的9935调整为5444，说明碎片已经得到了很好的整理。

可以通过两种方式进行整理，我们称之为“优化帐套”，下面介绍两种方法：

方法1：只对部分核心表进行整理，选择“账套管理” —〉“数据库” —〉“优化帐套”，缺点是账套优化功能不能做调度定时执行，需要每次手工点击执行；

方法2：在SQL Server企业管理器中做维护计划,使用企业管理器中管理—〉数据库维护计划—〉新建维护计划向导，在第三步，选择重新组织数据和索引页，如图4。

- 20 -

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库金蝶K3WISE V13产品性能稳定性优化指导手册（常见问题） - 图文(4)在线全文阅读。