AWR中的时间模型
AWR是咱们进行Oracle性能调整的主要工具之一；通常状况而言，时间是衡量性能好坏的一个重要指标，AWR中有不少与时间相关的内容和指标。先来看一下Oracle定义的响应时间公式：
Response time = Service time + Wait timehtml
服务时间(Service time)就是进程“真正”在cpu上运行的时间，能够简单理解为AWR中的cpu time/db cpu，服务时间包括前台进程(
Server process)和后台进程(Backgroud process)消耗的时间。等待时间就是等待某种资源的时间耗费，好比等待锁资源的耗费，能够简单对应为awr中的wait time, 等待时间包括不少类型，通常最多见的是IO等待和并发等待,好比进程等待从物理磁盘读取数据块到内存中的等待。 Awr中的db time能够简单对应为Response time；
l db time与cpu time
首先须要说明一个概念：时间片。现代操做系统(unix/Linux)将cpu资源划分红时间片(cpu slice)为单位来使用，通常是一个很小的值，通常为10ms。操做系统使用一个调度程序(好比linux的CFS调度器，来协调各个进程使用cpu资源。更详细的内容超出了本文的讨论范围，有兴趣的能够参考操做系统相关的文档。对于操做系统而言,一个进程要么在cpu中运行，要么处于等待队列中；注意这里的“等待”并不彻底等同于os中的等待。
DB time是整个数据库用户进程消耗的总时间，可用于衡量一个数据库总体负载,这有一些相似unix/linux系统中的平均负载(average load)指标。咱们来看一份awr:
|
Snap Id
|
Snap Time
|
Sessions
|
Cursors/Session
|
|
|
Begin Snap:
|
9820
|
13-2月 -12 08:00:17前端 |
735
|
89.3
|
|
End Snap:
|
9821
|
13-2月 -12 09:00:13linux |
965
|
92.3
|
|
Elapsed:
|
59.93 (mins)
|
|||
|
DB Time:
|
437.53 (mins)
|
咱们能够看到这一个awr的间隔时间为60分钟，而db time达到了437分钟，比率大体为7.3，咱们这一个系统为16 core cpu 的小型机，那么在60分钟能够提供的cpu time为16*60=960分钟的cpu time；若是咱们的db time所有都由cpu time来构成(固然是不可能的，Oracle总会有一些等待)，cpu的占用率为46%；cpu资源仍是足够的；考虑到db time还包括一部分wait time,咱们的cpu占用率会远远低于46%。
Db time主要用于对比同一系统的不一样时段，或同一时段的不一样系统来获得总体负载的初步映象，对比法是性能调整中，屡试不爽的重要法门！
|
Snap Id
|
Snap Time
|
Sessions
|
Cursors/Session
|
|
|
Begin Snap:
|
571
|
31-May-10 08:00:16
|
472
|
56.9
|
|
End Snap:
|
572
|
31-May-10 09:00:17
|
307
|
50.1
|
|
Elapsed:
|
60.02 (mins)
|
|||
|
DB Time:
|
1,139.42 (mins)
|
这一样是一个16 core的系统，不一样医院同一时段的系统，咱们能够看到在会话数(sessions)与每一个会话的平均cursor数量(Cursors/Session)都小于前一个系统的状况下(能够简单的理解为医院的规模和应用范围都小于前一个系统)，db time大幅增长；总的db time达到了1139分钟，据此咱们初步认为从总体来看第二个系统的性能是比较差的。
接下来咱们来讨论一下cpu time，cpu time在awr中也表示为db cpu，同时cpu time也是一个空闲等待事件，但这三者没有太大区别，时间值也是相同的。cpu time是Oracle对操做系统而言真正意义上的cpu消耗。那如何计算一个Oracle实例对操做系统的时间占比呢？很简单,公式以下:
Cpu time/ (Elapsed time * CPU cores)sql
在AWR中的top 5 waits或Time Model Statistics均可以找到 cpu time:
|
Event
|
Waits
|
Time(s)
|
Avg Wait(ms)
|
% Total Call Time
|
Wait Class
|
|
latch: cache buffers chains
|
76,560
|
33,283
|
435
|
48.7
|
Concurrency
|
|
CPU time
|
23,129
|
33.8
|
|||
|
log file sync
|
28,057
|
2,754
|
98
|
4.0
|
Commit
|
|
db file sequential read
|
312,477
|
2,169
|
7
|
3.2
|
User I/O
|
|
log file parallel write
|
24,580
|
633
|
26
|
.9
|
System I/O
|
l Time Model Statistics
在awr中，Time Model Statistics用于回答“到底前台进程消耗了多少时间?”，“语句解析消耗了多少时间?”等诸如此类的问题,咱们来看一个例子：数据库
|
Statistic Name
|
Time (s)
|
% of DB Time
|
|
connection management call elapsed time
|
21,708.46
|
15.22
|
|
sql execute elapsed time
|
21,596.44
|
15.14
|
|
parse time elapsed
|
17,648.50
|
12.37
|
|
hard parse elapsed time
|
9,081.89
|
6.37
|
|
hard parse (sharing criteria) elapsed time
|
4,158.48
|
2.92
|
|
hard parse (bind mismatch) elapsed time
|
3,189.62
|
2.24
|
|
PL/SQL execution elapsed time
|
2,362.21
|
1.66
|
|
DB CPU
|
2,311.28
|
1.62
|
|
PL/SQL compilation elapsed time
|
145.25
|
0.10
|
|
failed parse elapsed time
|
89.78
|
0.06
|
|
sequence load elapsed time
|
69.16
|
0.05
|
|
repeated bind elapsed time
|
0.21
|
0.00
|
|
DB time
|
142,622.31
|
|
|
background elapsed time
|
4,871.65
|
|
|
background cpu time
|
22.41
|
咱们看到，真于用于sql执行的时间(sql execute elapsed time)只占到了15.14%;这个比率是很是低的，做来一个相对正常的系统，这一比率不该低于90%甚至更高!咱们看到用于链接管理(connection management call elapsed time)的时间为15%,用于sql解析(parse time elapsed)的时为12.37%，且其中硬解析sql(hard parse elapsed time)的时间为6.37%。从这几个方面来看，咱们能够做一些合理的推测：缓存
1. 系统是否存在频繁链接和断开链接的状况?若是存在这种状况，是不是网络不稳定，或者监听程序存在问题形成了这个状况？还有就是中间件到数据库服务器的链接池是否出了问题？
2. Sql语句解析不合理;这是否由于共享池设置太小？应用程序是否未使用绑定变量?仍是由于开启了SGA自动管理，带来了严重的内存颠簸现象？
能够看到，经过对时间模型的分析，能够帮助咱们结合等待事件、latch信息等内容而对性能问题做出更为准确的判断。
4、操做系统相关的信息
Awr中也采集了部分操做系统的信息，特别是到了11g，更进一步的帮咱们计算出了cpu占用率，很是方便; awr中的Operating System Statistics部分：
|
NUM_LCPUS
|
0
|
|
NUM_VCPUS
|
0
|
|
AVG_BUSY_TIME
|
149,127
|
|
AVG_IDLE_TIME
|
211,742
|
|
AVG_IOWAIT_TIME
|
40,260
|
|
AVG_SYS_TIME
|
14,015
|
|
AVG_USER_TIME
|
135,004
|
|
BUSY_TIME
|
2,387,903
|
|
IDLE_TIME
|
3,389,758
|
|
IOWAIT_TIME
|
646,085
|
|
SYS_TIME
|
225,900
|
|
USER_TIME
|
2,162,003
|
|
LOAD
|
0
|
|
OS_CPU_WAIT_TIME
|
2,474,600
|
|
RSRC_MGR_CPU_WAIT_TIME
|
0
|
|
PHYSICAL_MEMORY_BYTES
|
49,123,688,448
|
|
NUM_CPUS
|
16
|
|
NUM_CPU_CORES
|
8
|
从图中，咱们能够获得cpu数量、busy_time、idle_time、iowait_time、物理内存等信息，对于咱们了解系统级的性能信息颇有帮助。好比我能够透过以下公式来计算awr采集期间的平均cpu占用率：
BUSY_TIME/( BUSY_TIME+ IDLE_TIME) * 100%
具体到咱们的例子，2,387,903/(2,387,903+3,389,758)*100%=41.33%。固然这里的cpu占用率，是从操做系统层面来看的，并非Oracle实例的cpu占用状况，由于主机能够运行了其余Oracle实例、或者中间件之类的其余软件系统。同时，咱们也能够经过IOWAIT_TIME来初步判断咱们的系统是否存在io瓶颈。
l 5、多关注平均时间
“平均”是一个颇有意思的话题，你们对平均的最直观的感觉就是统计局发布“XX地区平均收入已经突破XX元”，不少人都会发出“拖伟大祖国的后腿了！”这样的感叹。根据平均理论：即便咱们的头被火烧，脚浸泡在冰水里，也不会感到难受！这种状况在AWR的分析中也是须要注意的。
Awr采集的是一段时间总体性能数据，可能平均数据看起来没有问题，但前端用户可能仍是感受慢,由于某些次数的长时间等待被其余较短期的等待给“平均”掉了！这就须要咱们区别不一样的类型的问题，可能这些问题并不适合awr来诊断，而应该选用更合适的ash、sql trace等工具进行诊断。但这并说明“平均”的时间没有任何价值，只是须要具体问题具体分析。
咱们这里谈一下等待事件的平均等待时间:
Top 5 Timed Events
|
Event
|
Waits
|
Time(s)
|
Avg Wait(ms)
|
% Total Call Time
|
Wait Class
|
|
CPU time
|
17,217
|
54.5
|
|||
|
db file sequential read
|
1,155,423
|
8,422
|
7
|
26.6
|
User I/O
|
|
db file scattered read
|
30,541
|
660
|
22
|
2.1
|
User I/O
|
|
gc current block 2-way
|
900,865
|
538
|
1
|
1.7
|
Cluster
|
|
gc cr grant 2-way
|
467,627
|
244
|
1
|
.8
|
Cluster
|
对于IO类型的等待事件来讲，好比常见的db file sequential read平均等待时间通常不要超过10ms,这是根据当前硬盘的机械结构、转速等得出的一个经验值，由于单块10000转的普通磁盘，寻道时间在7-10ms左右。固然,若是考虑存储缓存、文件系统缓存、IO大小等状况，这个值通常在4-7ms之间;同时必须是IO系统在正常的iops（每秒的io次数，用于衡量存储并发吞量）下才有意义。若是超过经验值不少，就要分析具体的缘由了，多是存储的缓存功能没有启用、raid组中的磁盘损坏、不合理的raid级别等各类缘由;固然也有多是系统io负载过大，存储的负担较重，若是是这种状况就须要给合应用的io量(物理读与逻辑读)，特别是sql的io状况来分析了。服务器
咱们再来看一个真实的案例：
Top 5 Timed Foreground Events
|
Event
|
Waits
|
Time(s)
|
Avg wait (ms)
|
% DB time
|
Wait Class
|
|
db file sequential read
|
561,555
|
37,163
|
66
|
34.73
|
User I/O
|
|
read by other session
|
405,945
|
20,251
|
50
|
18.92
|
User I/O
|
|
log file sync
|
30,655
|
15,101
|
493
|
14.11
|
Commit
|
|
direct path read
|
171,963
|
12,254
|
71
|
11.45
|
User I/O
|
|
DB CPU
|
9,907
|
9.26
|
咱们看到整个系统的等待事件主要集中在IO上。db file sequential read的平均等待时间为66ms，而log file sync达到了惊人的493ms，也就是近0.5秒。log file sync通常由事务提交引发，也就是说一个事务光在提交上，就须要花费0.5s！请记住，这仍是一个平均数，还有不少事务，是远远大于这个时间的！最终检查出来的缘由是医院的存储使用了7200转的sata硬盘构建的RAID5,这样的配置对于ZLHIS这样的oltp系统来讲，无疑就是灾难！
l 也说一下次数
前面谈的都是“时间”，下面咱们来谈一下次数，同时做为本文的结束。首先，一些latch相关的等待事件，与latch中的sleep的次数相一致！好比library cache lock/pin、latch:shared pool等。好比：网络
|
Event
|
Waits
|
%Time -outssession |
Total Wait Time (s)架构 |
Avg wait (ms) |
Waits /txn |
| rdbms ipc reply |
1,622
|
0.00
|
1
|
0
|
0.05
|
| latch: cache buffers chains |
3,941
|
0.00
|
1
|
0
|
0.12
|
这里咱们能够看到,等待事件latch: cache buffers chains的等待次数为3941次，相应的latch统计信息以下：
| Latch Name |
Get Requests |
Misses
|
Sleeps
|
Spin Gets |
Sleep1
|
Sleep2
|
Sleep3
|
| cache buffers chains |
3,686,756,120
|
7,504,592
|
3,941
|
7,505,392
|
0
|
0
|
能够看到二者确实是相等的，也就是说只有latch获取过程当中，sleep的操做才会产生一次对应的等待事件。
最后仍是回到咱们的时间模型上来,若是咱们的系统只运行了一个数据库实例，则cpu time与busy time扣除io wait time后，应该是基本一致,来看一下案例:
Top 5 Timed Events
|
Event
|
Waits
|
Time(s)
|
Avg Wait(ms) |
% Total Call Time |
Wait Class |
| CPU time |
|
17,217
|
|
54.5
|
|
| db file sequential read |
1,155,423
|
8,422
|
7
|
26.6
|
User I/O |
| db file scattered read |
30,541
|
660
|
22
|
2.1
|
User I/O |
| gc current block 2-way |
900,865
|
538
|
1
|
1.7
|
Cluster
|
| gc cr grant 2-way |
467,627
|
244
|
1
|
.8
|
Cluster
|
Operating System Statistics
|
Statistic
|
Total
|
|
NUM_LCPUS
|
0
|
|
NUM_VCPUS
|
0
|
|
AVG_BUSY_TIME
|
149,127
|
|
AVG_IDLE_TIME
|
211,742
|
|
AVG_IOWAIT_TIME
|
40,260
|
|
AVG_SYS_TIME
|
14,015
|
|
AVG_USER_TIME
|
135,004
|
|
BUSY_TIME
|
2,387,903
|
|
IDLE_TIME
|
3,389,758
|
|
IOWAIT_TIME
|
646,085
|
|
SYS_TIME
|
225,900
|
|
USER_TIME
|
2,162,003
|
|
LOAD
|
0
|
|
OS_CPU_WAIT_TIME
|
2,474,600
|
|
RSRC_MGR_CPU_WAIT_TIME
|
0
|
|
PHYSICAL_MEMORY_BYTES
|
49,123,688,448
|
|
NUM_CPUS
|
16
|
|
NUM_CPU_CORES
|
8
|
cpu time为17,217s,也就是17,217000ms;
busy_time-iowait_time为:1741818ms(387,903-646,085)
能够看到二者基本相近;若是二者相差过大，就表示服务器上可能运行了其余程序或者其余的Oracle实例。
7、RAC性能
若是使用了RAC架构，须要特别关注RAC相关的时间要素,仍是经过一个案例来讲明：
|
Avg global enqueue get time (ms):
|
2.5
|
|
Avg global cache cr block receive time (ms):
|
172.2
|
|
Avg global cache current block receive time (ms):
|
6.6
|
|
Avg global cache cr block build time (ms):
|
0.0
|
|
Avg global cache cr block send time (ms):
|
0.0
|
|
Global cache log flushes for cr blocks served %:
|
13.6
|
|
Avg global cache cr block flush time (ms):
|
0.8
|
|
Avg global cache current block pin time (ms):
|
0.2
|
|
Avg global cache current block send time (ms):
|
0.0
|
|
Global cache log flushes for current blocks served %:
|
0.3
|
|
Avg global cache current block flush time (ms):
|
3.2
|
这些值的官方数字从几ms到10ms不等，但咱们这里的Avg global cache cr block receive time (ms)达到了惊人的172.2ms，这个指标表示，Oracle实例接收全局的CR块(一致性读数据块)的平均时间，这表示RAC中，各个节点间的热块急用是至关严重，须要在底层打散IO或者调整应用，减小总的IO量，并下降各个节点访问相同数据块的机率。具体的打散IO热点的技术，请参照其余文档。
8、总结
最后须要说起一点的就是awr中使用“时间”对SQL做出较多的分类，以便于咱们找到消耗某类”时间”最多的sql语句，主要包括：
好比，咱们能够经过SQL ordered by Elapsed Time来找到执行时间最慢的sql,经过SQL ordered by CPU Time最消耗cpu的sql等等。
还有就是IO部分，awr也提供了表空间与数据文件的io响应时间，也对于咱们分散IO热点区域，在存储底层进行性能调整提供了有价值的参考。
透过前面对awr时间模型的讨论，咱们能够看到awr提供给咱们的不少数据，之间有很是紧密的联系；这就要求咱们在对awr做分析时，不能孤立的看待某些指标，须要结合不一样的内容来相互映证，同时结合应用的特色、环境变动、硬件条件等方面来做出正确的判断。
相关文章
- 1. Flink---时间模型
- 2. Python中的ARIMA模型、SARIMA模型和SARIMAX模型对时间序列预测
- 3. 算法模型---时间序列模型
- 4. 时间序列模型（ARIMA模型）
- 5. python 中的时间模块
- 6. python中的时间模块
- 7. day6：时间序列模型
- 8. 时间序列ARIMA模型
- 9. Task03：时间序列模型
- 10. 时间管理模型
- 更多相关文章...
- • SQLite 日期 & 时间 - SQLite教程
- • XSD 日期和时间数据类型 - XML Schema 教程
- • 委托模式
- • C# 中 foreach 遍历的用法
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. Flink---时间模型
- 2. Python中的ARIMA模型、SARIMA模型和SARIMAX模型对时间序列预测
- 3. 算法模型---时间序列模型
- 4. 时间序列模型（ARIMA模型）
- 5. python 中的时间模块
- 6. python中的时间模块
- 7. day6：时间序列模型
- 8. 时间序列ARIMA模型
- 9. Task03：时间序列模型
- 10. 时间管理模型