sybase性能调优
问题:SYBASE数据库运行一段时间后,系统运行很慢?
可以isql登录ASE 执行
select @@version
go
查看数据库版本。
如果你使用的是ASE12.0，建议使用ASE12.5以上版本，因为自从sybase在数据库市场被ORACLE反超后，sybase推新产品的速度非常快，ASE12.5算是比较可靠的产品。
在使用上，ASE12.5也比较方便，尤其对高速内存的配置可以动态实现，不需要重新启动数据库。这对企业级用户来说比较有利。
ASE对资源的使用设计的比较精简，浪费的资源很少。在安装完ASE后其中的所有参数default 是比较低的，不能满足企业级用户的需要，做做demo还行。
第一步，你必须要根据数据量和用户数，还有应用的特点对ASE的参数做出合理的调整。
通常的做法是：
max memory = physical memory * 70-80%
default data cache = max memory * 50%
procedure cache size = max memory * 20-30%
number of user connections = n (default = 25)
number of lock = n * 单个用户所需的最大锁数 * 120%
（一般这个比较难估计，syabse的资深工程师给我的参考值：有用户配到180万，对于你的10G的数据量我估计先配 100000）
number of open objects = 10000
number of open indexed = 10000
这样的配置基本能正常使用了，具体怎么配置可以到sybase官方网站下载手册，英文好的看洋文，也有中文的。
然后，如果发现性能不如你预期的好，就需要发挥你的DBA才能来调优了。对于调优，我也没有独门秘笈，这里需要运用的知识较多，这次就不细说了。
ASE提供有一些工具可以帮助你找到影响性能的瓶颈：
用法很简单：
sp_sysmon "00:03:00"
这会显示3分钟内所有的计数信息，有四大类 18 项。
其中第一项'kernel'信息，显示这段时间内cpu的使用率，io的繁忙度。这很有帮助。
我再费点口舌：以后sp_configure的输出信息不需要发出来了，没什么大用。给sp_sysmon信息就行了。
提醒一下：对数据库的大小安排，tempdb大小，log的大小分配都可以通过利用并行io提高ASE性能。
给的通常的公式：
数据库大小=DB
tempdb = DB * 20% (经验值)
log size = DB * 20%
sp_sysmon详解
本篇文章采摘自时代朝阳数据库（原晓通数据库）培训部 Sybase 技术资料库。
本篇文章描述了通过sp_sysmon对Adaptive Server系统运行情况有一个全面系统了解，有利于更好地熟悉系统性能，更为有效地进行系统管理，合理地利用和配置系统资源，达到系统性能调优的目的。
sp_sysmon可以从18个方面了解在用系统性能状况，并在适当的时候利用环境参数进行性能调优：
1、内核管理（kernal） 2、应用管理（appmgmt） 3、数据缓存管理（dcache）
4、ESP管理（esp） 5、索引管理（indexmgmt） 6、锁管理（locks）
7、内存管理（memory） 8、元数据高速缓存管理（mdcache）9、任务管理（taskmgmt）
10、监视器访问SQL的执行（monaccess） 11、网络I/O管理（netio）
12、并行查询管理（parallel）13、过程缓存管理（pcache）14、恢复管理（recovery）
15、事务管理（xactmgmt）16、事务概要（xactsum） 17、磁盘I/O管理（diskio）
18、工作进程管理（wpm）
括号后英文短词是该模块参数。
环境： 1、用户数据库中有练习所用数据表auths和article
2、数据表各有10万行数据
3、用户具有查询、修改、删除等基本的数据库表操作权限
步骤：执行sp_sysmon “00:10:00”（server级系统存贮过程，不需要打开某个数据库），或者执行如下格式的过程，查看具体操作批命令对应系统性能情况：
sp_sysmon begin_sample
SQL语句或者存贮过程
sp_sysmon commit_sample
本实验采用 sp_sysmon “hh:mm:ss”,性能模块名。
通过sp_sysmon，可了`解当前系统在各方面的系统运行状况，性能出现什么问题和不平衡不协调之处，学会使用相应的参数和措施进行解决和调优，不断比较对照调整前后的性能状况，最终改善系统性能。
说明：1、该命令执行结果集的开头相同如下，各分块实验不再一一列示：
======================================================================
Sybase Adaptive Server Enterprise System Performance Report
======================================================================
Server Version: Adaptive Server Enterprise/11.9.2/1031/P/NT (IX86)/OS 3.
Server Name: Server is Unnamed
Run Date: May 28, 2001
Statistics Cleared at: 15:57:27
Statistics Sampled at: 16:07:28
Sample Interval: 00:10:00
2、执行结果集的每列信息提示：
per sec ： 采样期间每秒的平均值
per xact： 采样期间每提交一个事务的平均值
count ： 采样期间每秒的总计值
% of total： 占总数的百分比，根据不同情况各有不同
3、结果集对应给出性能情况描述、分析以及可调性说明
4、本练习只给出部分模块的监视结果（可能有删节），用sp_sysmon “hh:mm:ss”可看全部详细情况。
单元一：监视内核利用情况
命令行：sp_sysmon “00:10:00”,kernal
结果：
Kernel Utilization （内核利用）
------------------
Engine Busy Utilization
Engine 0 1.8 %
引擎繁忙程度应在80%-90%之间，如果长期在90%以上，应考虑增加引擎数来改善性能。因为此时内部管理进程无法向磁盘写入，则检查点需要将许多页写回磁盘，而检查点进程很可能将CPU的利用率提高到100%，导致响应时间明显增加。
CPU Yields by Engine per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Engine 0 6.6 0.6 3949 100.0 %
引擎放弃CPU次数：% of total=1个引擎放弃次数/所有引擎放弃次数，如果显示引擎利用率较低，可通过放弃数判断是否真实反映引擎的停止情况。增加“runnable process search count”（引擎放弃CPU给OS之前一个引擎循环查找可执行任务的次数）参数可增加CPU的驻留时间，而如果想减少引擎在空闲时检查I/O的时间，可减少该参数的值。
Network Checks
Total Network I/O Checks 0.0 0.0 0 n/a
引擎发送或接收网络包的次数。引擎空闲时频繁检查网络包，如果该值很低而“CPU Yields by Engine”的值高，表明引擎可能被频繁放弃。
可能包括阻塞和非阻塞两种检查方式。非阻塞方式不管有无I/O等待都对网络进行I/O检查。如果引擎已被放弃并正执行阻塞网络检查，则在网络包到达以后仍保持一段睡眠时间（潜伏期）。此时增加“runnable process search count”（缺省2000）参数可减少潜伏期，保持引擎有较长的循环检查时间，而不是过早被放弃。
Disk I/O Checks磁盘I/O检查情况：
Total Disk I/O Checks 693.2 58.8 415939 n/a
Checks Returning I/O 469.9 39.9 281921 67.8 %
引擎对I/O情况的有效检查（I/O完成次数），如过高或过低，用“i/o polling process count”（Server的调度程序在检查磁盘I/O或网络I/O之前可执行的最大进程数）参数增加或减少检查频率。通常说增加该值可增加有大量磁盘或网络I/O的应用的吞吐量，反之，减少该值有可改善其响应时间。
Avg Disk I/Os Returned n/a n/a 0.03020 n/a
增加引擎在检查期间的等待时间可改善吞吐量，因为减少引擎检查I/O时间相应增加执行进程的时间。
可以isql登录ASE 执行
select @@version
go
查看数据库版本。
如果你使用的是ASE12.0，建议使用ASE12.5以上版本，因为自从sybase在数据库市场被ORACLE反超后，sybase推新产品的速度非常快，ASE12.5算是比较可靠的产品。
在使用上，ASE12.5也比较方便，尤其对高速内存的配置可以动态实现，不需要重新启动数据库。这对企业级用户来说比较有利。
ASE对资源的使用设计的比较精简，浪费的资源很少。在安装完ASE后其中的所有参数default 是比较低的，不能满足企业级用户的需要，做做demo还行。
第一步，你必须要根据数据量和用户数，还有应用的特点对ASE的参数做出合理的调整。
通常的做法是：
max memory = physical memory * 70-80%
default data cache = max memory * 50%
procedure cache size = max memory * 20-30%
number of user connections = n (default = 25)
number of lock = n * 单个用户所需的最大锁数 * 120%
（一般这个比较难估计，syabse的资深工程师给我的参考值：有用户配到180万，对于你的10G的数据量我估计先配 100000）
number of open objects = 10000
number of open indexed = 10000
这样的配置基本能正常使用了，具体怎么配置可以到sybase官方网站下载手册，英文好的看洋文，也有中文的。
然后，如果发现性能不如你预期的好，就需要发挥你的DBA才能来调优了。对于调优，我也没有独门秘笈，这里需要运用的知识较多，这次就不细说了。
ASE提供有一些工具可以帮助你找到影响性能的瓶颈：
用法很简单：
sp_sysmon "00:03:00"
这会显示3分钟内所有的计数信息，有四大类 18 项。
其中第一项'kernel'信息，显示这段时间内cpu的使用率，io的繁忙度。这很有帮助。
我再费点口舌：以后sp_configure的输出信息不需要发出来了，没什么大用。给sp_sysmon信息就行了。
提醒一下：对数据库的大小安排，tempdb大小，log的大小分配都可以通过利用并行io提高ASE性能。
给的通常的公式：
数据库大小=DB
tempdb = DB * 20% (经验值)
log size = DB * 20%
sp_sysmon详解
本篇文章采摘自时代朝阳数据库（原晓通数据库）培训部 Sybase 技术资料库。
本篇文章描述了通过sp_sysmon对Adaptive Server系统运行情况有一个全面系统了解，有利于更好地熟悉系统性能，更为有效地进行系统管理，合理地利用和配置系统资源，达到系统性能调优的目的。
sp_sysmon可以从18个方面了解在用系统性能状况，并在适当的时候利用环境参数进行性能调优：
1、内核管理（kernal） 2、应用管理（appmgmt） 3、数据缓存管理（dcache）
4、ESP管理（esp） 5、索引管理（indexmgmt） 6、锁管理（locks）
7、内存管理（memory） 8、元数据高速缓存管理（mdcache）9、任务管理（taskmgmt）
10、监视器访问SQL的执行（monaccess） 11、网络I/O管理（netio）
12、并行查询管理（parallel）13、过程缓存管理（pcache）14、恢复管理（recovery）
15、事务管理（xactmgmt）16、事务概要（xactsum） 17、磁盘I/O管理（diskio）
18、工作进程管理（wpm）
括号后英文短词是该模块参数。
环境： 1、用户数据库中有练习所用数据表auths和article
2、数据表各有10万行数据
3、用户具有查询、修改、删除等基本的数据库表操作权限
步骤：执行sp_sysmon “00:10:00”（server级系统存贮过程，不需要打开某个数据库），或者执行如下格式的过程，查看具体操作批命令对应系统性能情况：
sp_sysmon begin_sample
SQL语句或者存贮过程
sp_sysmon commit_sample
本实验采用 sp_sysmon “hh:mm:ss”,性能模块名。
通过sp_sysmon，可了`解当前系统在各方面的系统运行状况，性能出现什么问题和不平衡不协调之处，学会使用相应的参数和措施进行解决和调优，不断比较对照调整前后的性能状况，最终改善系统性能。
说明：1、该命令执行结果集的开头相同如下，各分块实验不再一一列示：
======================================================================
Sybase Adaptive Server Enterprise System Performance Report
======================================================================
Server Version: Adaptive Server Enterprise/11.9.2/1031/P/NT (IX86)/OS 3.
Server Name: Server is Unnamed
Run Date: May 28, 2001
Statistics Cleared at: 15:57:27
Statistics Sampled at: 16:07:28
Sample Interval: 00:10:00
2、执行结果集的每列信息提示：
per sec ： 采样期间每秒的平均值
per xact： 采样期间每提交一个事务的平均值
count ： 采样期间每秒的总计值
% of total： 占总数的百分比，根据不同情况各有不同
3、结果集对应给出性能情况描述、分析以及可调性说明
4、本练习只给出部分模块的监视结果（可能有删节），用sp_sysmon “hh:mm:ss”可看全部详细情况。
单元一：监视内核利用情况
命令行：sp_sysmon “00:10:00”,kernal
结果：
Kernel Utilization （内核利用）
------------------
Engine Busy Utilization
Engine 0 1.8 %
引擎繁忙程度应在80%-90%之间，如果长期在90%以上，应考虑增加引擎数来改善性能。因为此时内部管理进程无法向磁盘写入，则检查点需要将许多页写回磁盘，而检查点进程很可能将CPU的利用率提高到100%，导致响应时间明显增加。
CPU Yields by Engine per sec per xact count % of total
------------------------- ------------ ------------ ---------- ----------
Engine 0 6.6 0.6 3949 100.0 %
引擎放弃CPU次数：% of total=1个引擎放弃次数/所有引擎放弃次数，如果显示引擎利用率较低，可通过放弃数判断是否真实反映引擎的停止情况。增加“runnable process search count”（引擎放弃CPU给OS之前一个引擎循环查找可执行任务的次数）参数可增加CPU的驻留时间，而如果想减少引擎在空闲时检查I/O的时间，可减少该参数的值。
Network Checks
Total Network I/O Checks 0.0 0.0 0 n/a
引擎发送或接收网络包的次数。引擎空闲时频繁检查网络包，如果该值很低而“CPU Yields by Engine”的值高，表明引擎可能被频繁放弃。
可能包括阻塞和非阻塞两种检查方式。非阻塞方式不管有无I/O等待都对网络进行I/O检查。如果引擎已被放弃并正执行阻塞网络检查，则在网络包到达以后仍保持一段睡眠时间（潜伏期）。此时增加“runnable process search count”（缺省2000）参数可减少潜伏期，保持引擎有较长的循环检查时间，而不是过早被放弃。
Disk I/O Checks磁盘I/O检查情况：
Total Disk I/O Checks 693.2 58.8 415939 n/a
Checks Returning I/O 469.9 39.9 281921 67.8 %
引擎对I/O情况的有效检查（I/O完成次数），如过高或过低，用“i/o polling process count”（Server的调度程序在检查磁盘I/O或网络I/O之前可执行的最大进程数）参数增加或减少检查频率。通常说增加该值可增加有大量磁盘或网络I/O的应用的吞吐量，反之，减少该值有可改善其响应时间。
Avg Disk I/Os Returned n/a n/a 0.03020 n/a
增加引擎在检查期间的等待时间可改善吞吐量，因为减少引擎检查I/O时间相应增加执行进程的时间。
