概述

最近HR数据库比较慢，拿了其中一段时间的awr报告来分析，发现有一个等待事件：connection management call elapsed time，虽然占比不是很大，不过也是有点奇怪，下面继续分析一下。

AWR是我们进行Oracle性能调整的主要工具之一；一般情况而言，时间是衡量性能好坏的一个重要指标，AWR中有很多与时间相关的内容和指标。先来看一下Oracle定义的响应时间公式：

Response time = Service time + Wait time

服务时间(Service time)就是进程“真正”在cpu上运行的时间，可以简单理解为AWR中的cpu time/db cpu，服务时间包括前台进程(Server process)和后台进程(Backgroud process)消耗的时间。等待时间就是等待某种资源的时间耗费，比如等待锁资源的耗费，可以简单对应为awr中的wait time, 等待时间包括很多类型，一般最常见的是IO等待和并发等待,比如进程等待从物理磁盘读取数据块到内存中的等待。 Awr中的db time可以简单对应为Response time；

1、db time与cpu time

首先需要说明一个概念：时间片。现代操作系统(unix/Linux)将cpu资源划分成时间片(cpu slice)为单位来使用，一般是一个很小的值，一般为10ms。操作系统使用一个调度程序(比如linux的CFS调度器，来协调各个进程使用cpu资源。更详细的内容超出了本文的讨论范围，有兴趣的可以参考操作系统相关的文档。对于操作系统而言,一个进程要么在cpu中运行，要么处于等待队列中；注意这里的“等待”并不完全等同于os中的等待。

DB time是整个数据库用户进程消耗的总时间，可用于衡量一个数据库整体负载

2、Time Model Statistics

在awr中，Time Model Statistics用于回答“到底前台进程消耗了多少时间?”，“语句解析消耗了多少时间?”等诸如此类的问题

真于用于sql执行的时间(sql execute elapsed time)占到了84.06%;这个比率是稍微有点低的，作来一个相对正常的系统，这一比率不应低于90%甚至更高!我们看到用于连接管理(connection management call elapsed time)的时间为7.49%,用于sql解析(parse time elapsed)的时为7.1%，且其中硬解析sql(hard parse elapsed time)的时间为6.92%。

从这几个方面来看，我们可以作一些合理的推测：

1）系统是否存在频繁连接和断开连接的情况?如果存在这种情况，是否是网络不稳定，或者监听程序存在问题造成了这个情况？还有就是中间件到数据库服务器的连接池是否出了问题？

2）Sql语句解析不合理;这是否因为共享池设置过小？应用程序是否未使用绑定变量?还是因为开启了SGA自动管理，带来了严重的内存颠簸现象？

3、查看db time

select *
 from (select A.SNAP_ID,
 A.INSTANCE_NUMBER,
 B.BEGIN_INTERVAL_TIME + 0 BEGIN_TIME,
 B.END_INTERVAL_TIME + 0 END_TIME,
 ROUND(VALUE - LAG(VALUE, 1, '0')
 OVER(ORDER BY A.INSTANCE_NUMBER, A.SNAP_ID)) "DB TIME"
 FROM (SELECT B.SNAP_ID,
 INSTANCE_NUMBER,
 SUM(VALUE) / 1000000 / 60 VALUE
 FROM DBA_HIST_SYS_TIME_MODEL B
 WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
 AND UPPER(B.STAT_NAME) IN UPPER(('DB TIME'))
 GROUP BY B.SNAP_ID, INSTANCE_NUMBER) A,
 DBA_HIST_SNAPSHOT B
 WHERE A.SNAP_ID = B.SNAP_ID
 AND B.DBID = (SELECT DBID FROM V$DATABASE)
 AND B.INSTANCE_NUMBER = A.INSTANCE_NUMBER)
 WHERE TO_CHAR(BEGIN_TIME, 'YYYY-MM-DD') >=
 TO_CHAR(SYSDATE - 7, 'YYYY-MM-DD')
 ORDER BY BEGIN_TIME DESC;

维持在相对较高的水平。

4、查询失败登录记录

select sessionid,
 userid,
 userhost,
 comment$text,
 spare1,
 cast( /* TIMESTAMP */(from_tz(ntimestamp#, '00:00') at local) as date)
 from aud$
 where returncode = 1017
 and ntimestamp# > sysdate - 10
 order by ntimestamp# desc

这里可以直接看到错误的IP信息，联想到前段时间修改了数据库密码，到上面应用修改正确密码后就正常了。

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~