方法
在UCCX版本10.0及以上版本，请输入使用情况uccx数据库dbperf启动<totalHours> <interval>命令为了开始在UCCX数据库的性能跟踪。在此命令的间隔参数确定跟踪收集的周期，并且totalHours参数确定跟踪运行的总量时间，在禁用前。这些参数可选。如果他们没有指定，当命令被执行默认值20分钟，并且时使用10个小时。
例如，请输入使用情况uccx开始24 30发出命令为了启用在数据库的性能跟踪和收集在性能统计数据的数据每30分钟24个小时的数据库dbperf。
说明收集CLI命令得到的数据在命令输出中打印。
在给的totalHours以后，数据收集自动地终止。为了手工终止数据收集，请输入stop命令使用情况uccx数据库的dbperf。
如果UCCX版本是版本9.0(2)或更加早期和使用情况uccx数据库dbperf命令不是可用的，请与进一步协助的技术支持中心(TAC)联系。
TAC将执行dbperf.sh脚本手工附加对Cisco Bug ID CSCuc68413与远程支持帐户访问。
当您什么时候确定手工开始脚本执行或者或时通过CLI命令，周期和总时间，保证uccxoninit进程消耗的CPU极大动摇或保持高在那些期限为了收集根本原因分析的必要信息。
另外，当CPU动摇为了关联dbperf跟踪脚本时，收集的日志周期地请输入load命令的show process确定。
数据分析
onstat的dbperf脚本的执行收集的日志- g ses 0显示发出UCCX数据库的活动查询。在uccxoninit进程的高CPU典型地是需要很长时间执行复杂查询的结果。目标是确定浪费多数资源，确定那些查询的来源客户端，禁用从客户端的查询立即解决方法的，并且优化永久性解决方法的长期的查询的查询。
在dbperf脚本收集的日志，请寻找在CPU的最可能原因高波动或由uccxoninit的持续的高CPU消耗处理的查询。
怀疑查询：
- 从作为uccxhruser连接的会话发出-如描述前， uccxhruser有权限选择信息在配置和历史表外面巨大数目。结果，复杂，在多个表间的长期的查询被修建并且能有在UCCX数据库的性能影响。虽然不绝对， uccxwallboard和uccxworkforce用户有对表的这样有限访问在UCCX数据库内，导致这些用户发出的性能影响是不太可能的复杂查询。另外， uccxhrcare发出的查询发出由UCCX历史报告的客户端(HRC)或Cisco Unified智能中心(CUIC) UCCX数据库。这些查询是静态的，并且不可能与相关indicies一起被修改和查询，为最小的性能影响写入，测试了和被调整了。
- 执行在历史表的密集查询-要求UCCX数据库执行在表间的多加入，选择重大数额信息或操作非被标注的字段的查询可能导致性能影响UCCX数据库。
与介入作为uccxhruser运行的一个HR表的一复杂查询的一示例显示此处：
session #RSAM total used dynamic
id user tty pid hostname threads memory memory explain
435050 uccxhrus WBBOX 836 10.16.5. 1 90112 80712 off
...................
Current SQL statement :
SELECT x.resourceName, t.eventType, x.datetime, x.extension FROM ( SELECT
t1.resourceID, t1.resourceName, t1.extension, MAX(t2.eventDateTime) AS
datetime FROM Resource AS t1, AgentStateDetail AS t2 WHERE t2.agentID
= t1.resourceID AND t1.assignedTeamID = 21 and t1.active GROUP BY
t1.resourceID, t1.resourceName, t1.extension ) AS x, AgentStateDetail AS
t WHERE t.agentID = x.resourceID AND t.eventDateTime = x.datetime
ORDER BY x.resourceName
以上示例显示一复杂查询，参与由从可能导致在UCCX数据库的性能影响的主机来源的uccxhruser WBBOX，如果经常被输入了或周期地被输入了，在上一个查询返回结果前。
虽然少见， UCCX数据库性能能也降低(和uccxoninit进程的CPU利用率动摇或保持高)由于内置的清除进程。清除进程设计删除从配置的在UCCX数据库内的数据和历史表为了维护数据库的大小。可以安排清除根据在数据库内或最旧的记录的包含的大小数据库。
当清除进程运行时，数据删除与一查询。它没有执行迭代根据相当数量记录删除。这意味着，如果清除检测必须删除的很多数据，发出单个查询为取消此数据。
清除日程或参数的修改从UCCX AppAdmin页为了安排清除取消很多数据能引起此单个查询，在其次被安排的清除，花些巨大数量的时间完成。所以，它驱动数据库实例的CPU利用率。
在dbperf脚本的输出中，清除查询能被看到。它应该是呼叫sp_purge存储过程的用户uccxuser参与的唯一的查询。
session #RSAM total used dynamic
id user tty pid hostname threads memory memory explain
5628 uccxuser - -1 CC-EXPR- 1 544768 523408 off
Current SQL statement in procedure db_cra:sp_purge
proc-counter 0x0x4ccf9260 opcode SQL
delete from contactroutingdetail
where (exists
(select 1
from contactcalldetail as ccdr
where (and (and (and (and (and (= contactroutingdetail.sessionid,
ccdr.sessionid), (= contactroutingdetail.nodeid, ccdr.nodeid)),
(= contactroutingdetail.sessionseqnum, ccdr.sessionseqnum)),
(= contactroutingdetail.profileid, ccdr.profileid)), (>= ccdr.enddatetime,
p_purgefrom)), (< ccdr.enddatetime, p_purgeto))));
反馈