方法
在UCCX版本10.0及以上版本，请输入utils uccx数据库dbperf启动<totalHours> <interval>命令为了开始在UCCX数据库的性能追踪。在此命令的间隔参数确定跟踪收集的周期，并且totalHours参数确定追踪运行的总量时间，在是失效的前。这些参数是可选的。如果他们没有指定，当命令被执行20分钟的默认值，并且时使用10小时。
例如，请输入utils uccx开始24 30发出命令为了enable (event)在数据库的性能追踪的数据库dbperf并且收集关于性能统计数据的数据每30分钟24小时。
指令收集CLI命令得到的数据在命令输出中被打印。
在被测量的totalHours以后，数据收集自动地终止。为了手工终止数据收集，请输入stop命令utils uccx数据库的dbperf。
如果UCCX版本是版本9.0(2)或更加早期和utils 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运行的1小时表的一次复杂查询的一个示例显示得这里：
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))));
反馈