DPA在电信计费系统故障诊断案例

3月20日中午,电信客户的计费系统故障,所有操作响应缓慢,应用无法正常运行。现场DBA已经迅速将应用连接转移到RAC集群的另一节点,恢复应用服务,我们使用DPA来回看事故现场,此时离故障发生,已经一小时了…… 回溯负载情况,如下图   问题最严重时,实例堵塞了近700个连接操作…针对此时间段,进一步点击、下钻分析当时系统发生了什么 系统先是每分钟4~5次堵塞(像是咳嗽),到了13:40后,就处于长时间“梗”住的状态,对于外部业务来说,数据库实例已不可用了。   利用DPA,继续下钻,查看堵塞原因: 1654#会话导致80个会话被堵塞,这80个会话的等待事件是 sga:allocation forcing component growth,这80个会话中的一些会话又堵塞了一些其他会话,如下图 266号会话堵塞了3个会话,这三个会话的等待事件都是cursor:pin s wait on x,这个等待事件一般都是跟sql parse相关,所以,现场工程师开始查看oracle 自己的ADDM报告,说是解析有问题,建议应用分析解决问题…被误导了   至此,DPA下钻后清晰显示,堵塞的根源是1654号会话,DPA显示是MMAN进程,它堵塞了80个会话,这些会话又堵塞了更多其他会话,是一个3级的堵塞关系,幸好DPA以“树型”显示方式,把这种多层级堵塞关系显示的非常清晰。 结论:Oracle MMAN进程进行过于频繁的SGA内存组件(本例中是share pool)resize操作,导致了问题…   这张图中显示的share pool内部情况,看官能看出异常么?   “划一条线1美元,知道在哪里划线9999美元”。 至此,后续我们如何解决这个问题的就不再讨论了,解决问题从来不是难事,难的是发现问题。 后记: 从DPA的负载雷达上,我们看到在系统出现问题之前的一小段时间内,系统负载不正常的降的很低,其后负载飙升上去…… 那段时间负载异常降低,说明了什么? 应用程序发生了什么…… 这些从Database Performance Analyzing层面,就无从知晓了。

在MAC平台编译安装遇到的问题

在Unix/Linux平台编译源代码安装软件遇到的问题 Changzheng-Hes-MacBook-Pro:rems2-3.4.7-new changzhenghe$ make installCDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/changzhenghe/tmp/rems2-3.4.7-new/missing aclocal-1.14 -I m4/Users/changzhenghe/tmp/rems2-3.4.7-new/missing: line 81: aclocal-1.14: command not foundWARNING: 'aclocal-1.14' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: http://www.gnu.org/software/automake It