解析实时的DB time过程分析(r6笔记第35天)

在我们查看awr报告的时候总是会有一个关键指标需要注意,那就是DB time,这个指标一般都是通过awr报告来看到的。 比如我们得到的awr报告头部显示的下面的信息,我们就清楚的知道DB time是1502.06 mins,相对于Elapsed time来说,将近有20倍的压力。这个问题肯定需要关注。 Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 6219 21-Jul-15 22:00:08 583 2.5 End Snap: 6220 21-Jul-15 23:00:44 639 2.4 Elapsed: 60.61 (mins) DB Time: 1,502.06 (mins) 当然我们也不大可能一下子生成几十个awr报告,然后就为了得到这个DB time值。 在之前的博客中也分享过如何来结合shell脚本抓取数据库的负载信息。 http://blog.itpub.net/23718752/viewspace-1168027/ 比如得到的结果如下: DB_NAME BEGIN_SNAP END_SNAP SNAPDATE LVL DURATION_MINS DBTIME --------- ---------- ---------- -------------------- --- ------------- ---------- XXX 93464 93465 21 Aug 2015 00:00 1 30 15 93465 93466 21 Aug 2015 00:30 1 30 5 93466 93467 21 Aug 2015 01:00 1 30 5 93467 93468 21 Aug 2015 01:30 1 30 13 93468 93469 21 Aug 2015 02:00 1 30 24 这个对于日常的使用其实也基本够用,有一个最大的缺点就是这个指标其实是基于历史快照的,比如现在是15:30分,每隔一个小时生成一次快照,那么我想看看15:30这个时间点的大致数据库负载情况就无法实现了。 这个工作其实还是有一定的使用意义的,比如我们想通过orabbix来做这种类型的监控,不能专门再等1个小时吧,或者把时间调短,但是想必会对性能还是有一定的影响,因为我们只是想知道DB time的情况,其它的信息先放一放,暂时不需要。 Oracle在10g推出的时间模型,里面有一个很重要的数据字典表是DBA_HIST_SYS_TIME_MODEL,但是里面都是历史的信息,没有最新的信息,这个时候可以借助另外一个动态性能视图 v$sys_time_model 所以对于这个监控项,自己也是信心满满,写了下面的语句,看似也能达到效果。

select 
round 
       (
    (select round(e.value / 1000000,2) dbtime 
                        FROM v$SYS_TIME_MODEL e 
                        WHERE 
                         e.STAT_NAME = 'DB time')*100/ 
      (select ((systimestamp+0)-startup_time)*24*60*60 dbtime_duartion_ 
                        from v$instance )  
   ,2)      dbtime_per                  
     from dual;

我的思路就是当前的DB time的值可以得到,但是需要找一个基准,这个时候又没有其它可参考的基准,我就想到使用数据库实例启动的时间,初始化启动的时候DB time的值会从0开始初始化,逐渐递增。 当然还是有误差的,比如数据库从nomount,mount到open阶段,db time的值就开始逐渐递增了,可能参考的基准时间会有一些误差,但是相对来说很小。 比如数据库open状态下

SQL> select value/1000000 ,t.*from v$sys_time_model t where stat_name='DB time'
VALUE/1000000    STAT_ID STAT_NAME   VALUE
------------- ---------- ---------- ----------
   130.364805 3649082374 DB time    130364805

然后停库,启动到mount阶段。
VALUE/1000000    STAT_ID STAT_NAME    VALUE
------------- ---------- ----------- ----------
     6.057183 3649082374 DB time       6057183
启动到Open阶段
VALUE/1000000    STAT_ID STAT_NAME      VALUE
------------- ---------- ---------------------
    10.063956 3649082374 DB time      10063956

可以看到DB time都是在逐渐递增的过程,大体情况下这种方式似乎还是一种不错的选择。 但是配置到orabbix监控中之后,仔细对比快照中的数据库负载,发现数据库的负载情况会有一些错误,有些库中通过快照查看负载在40%左右,但是通过实时取得的数据得到的结果负载时40%,这个时候我还是相信快照中的DB time. 自己带着疑问,手动测试了一下。 比如得到下面的信息是快照中的基准

BEGIN_SNAP   END_SNAP SNAPDATE             BEGIN_INTERVAL_TIME            END_INTERVAL_TIME              DURATION_MINS     DBTIME
---------- ---------- -------------------- ------------------------------ ------------------------------ ------------- ----------
     36202      36203 21 Aug 2015 07:00    21-AUG-15 06.00.59.625 AM      21-AUG-15 07.00.04.417 AM                 59        130
     36203      36204 21 Aug 2015 08:00    21-AUG-15 07.00.04.417 AM      21-AUG-15 08.00.09.642 AM                 60        139
     36204      36205 21 Aug 2015 09:00    21-AUG-15 08.00.09.642 AM      21-AUG-15 09.00.14.248 AM                 60        138

我们还是运行实时查看DB time的脚本来看看差别到底有多大,可以看到这个库的负载情况比较规律,不会出现大的抖动,所以这个时间点范围内的DB time应该还是在130左右。 因为根据官方文档对于v$sys_time_model的描述,有个5秒的误差或者延迟率。

V$SYS_TIME_MODEL displays the system-wide accumulated times for various operations. The time reported is the total elapsed or CPU time (in microseconds). Any timed operation will buffer at most 5 seconds of time data. Specifically, this means that if a timed operation (such as SQL execution) takes a long period of time to perform, the data published to this view is at most missing 5 seconds of the time accumulated for the operation.

我们就把测试的等待时间延长在5秒以上。 11:25:14 SQL> @aa.sql DBTIME DURATION PER ---------- ---------- ---------- 105969035 872180.533 121.498968 11:26:42 SQL> @aa.sql DBTIME DURATION PER ---------- ---------- ---------- 105969055 872180.717 121.498966 可以看到通过快照得到的负载是138/60=200%+ 但是通过这个公式算出来的结果却有些小了,在120%左右。 在其它的库中也做了相似的测试,有的库中差别小,有的库中差别大。这个时候感觉脚本的结果是飘忽不定,不准确了。 难道是v$sys_time_model用错了 查看这个视图的定义,和使用dba_hist_sys_time_model还是有关系的。

Column

Datatype

Description

STAT_ID

NUMBER

Statistic identifier for the time statistic

STAT_NAME

VARCHAR2(64)

Name of the statistic (see Table 7-4)

VALUE

NUMBER

Amount of time (in microseconds) that the system has spent in this operation

那就可能是基准不对,如果实例启动的startup_time不对,那么该找哪个基准呢,能够想到的只能是快照中的数据了。 我们可以尝试以一个历史快照为参考,通过比较最新的DB time值来进行负载的计算。 这个时候还需要依赖于dba_sys_time_model和dba_snapshots 这个时候重新改进的语句就是下面的形式。在rac下还没有测试,单实例下还是没有问题的。

select (e.value/1000000/60-temp.dbtime)/(((systimestamp+0)-(BEGIN_INTERVAL_TIME+0 ))*24*60) dbtime
from (select t.begin_interval_time,t.end_interval_time,t.snap_id,e.value/1000000/60 dbtime,e.stat_name
                        FROM DBA_HIST_SYS_TIME_MODEL e,dba_hist_snapshot t
                        WHERE
                         e.STAT_NAME = 'DB time'
                         and t.snap_id=e.snap_id
                         and t.begin_interval_time > sysdate-2/24
                         and rownum<2
                         ) temp,v$SYS_TIME_MODEL e
                         where e.STAT_NAME = 'DB time'
                         and rownum<2; 

这个语句的重要控制点就在于时间的选择,如果选择3个小时前,2个小时前就会有一些差别,但是差别很小。可以说是误差。

DB_NAME   BEGIN_SNAP   END_SNAP SNAPDATE             LVL DURATION_MINS     DBTIME
--------- ---------- ---------- -------------------- --- ------------- ----------
XXX          93464      93465 21 Aug 2015 00:00      1            30         15
               93465      93466 21 Aug 2015 00:30      1            30          5
               93466      93467 21 Aug 2015 01:00      1            30          5

比如这个库的负载比较低,在20%以内,我们来看看3个小时前,2个小时前的基准,得到的DB time的情况。 3个小时前为基准: DBTIME_WORDLOAD ---------- 18% 2个小时前为基准: DBTIME_WORDLOAD ---------- 11% 和基准值差别不大,都是合理的范围之内了。 其实这个问题的根本原因就在于采样的范围,参考的基准越近,得到的误差范围就越低。打个简单的比方,就根据统计近年来的工资收入水平,我们还以解放前的标准来算,现在的误差就会很大,而且不准确,以近些年来的情况来统计,结果就会在范围之内,是一个基本可信的值了。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-08-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

物化视图中的统计信息导致的查询问题分析和修复 (r7笔记第47天)

今天开发的同事下午反馈给我一个问题,说有操作直接卡住了,听这个描述,感觉很可能是查询慢了。 于是连接到环境中,查看了一下正在执行的sql语句情况,发现下面的语句...

35750
来自专栏维C果糖

史上最简单的 MySQL 教程(二)「关系型数据库」

关系型数据库,是一种建立在关系模型(数学模型)上的数据库。

44390
来自专栏Spark学习技巧

flink 有状态udf 引起血案一

最近在做一个画像的任务,sql实现的,其中有一个udf,会做很多事情,包括将从redis读出历史值加权,并将中间结果和加权后的结果更新到redis。

31750
来自专栏码神联盟

数据库SQL优化大总结1之- 百万级数据库优化方案

小编最近几天一直未出新技术点,是因为小编在忙着总结整理数据库的一些优化方案,特此奉上,优化总结较多,建议分段去消化,一口吃不成pang(胖)纸 ...

3.3K80
来自专栏Hadoop数据仓库

HAWQ技术解析(十二) —— 查询优化

        即便对SELECT等数据库查询语句已经很熟悉了,但HAWQ里的查询有其自己的特点,还是需要研究一下。 一、HAWQ的查询处理流程        ...

72660
来自专栏乐沙弥的世界

Oracle ADDM性能诊断利器及报告解读

性能优化是一个永恒的话题,性能优化也是最具有价值,最值得花费精力深入研究的一个课题,因为资源是有限的,时间是有限的。在Oracle数据库中,随着Oracle功能...

16720
来自专栏Flutter入门

偶遇FFmpeg(番外)——FFmpeg花样编译入魔1之裁剪大小

在偶遇FFmpeg(三)——Android集成这边文章中曾经介绍过FFmpeg和Android的交叉编译。文章中也提到过如何裁剪SO文件大小的方式。 这边文章...

52330
来自专栏更流畅、简洁的软件开发方式

利用虚拟硬盘(把内存当作硬盘)来提高数据库的效率(目前只针对SQL Server 2000)可以提高很多

      虚拟硬盘:就是把内存当作硬盘来用,比如有2G的内存,那么可以拿出来1G的内存当作硬盘来用。       自从知道了“虚拟硬盘”这个东东,我就一直在想...

52450
来自专栏一枝花算不算浪漫

[全文检索]Lucene基础入门.

45380
来自专栏架构专栏

2018最新淘宝面试出炉:分布式锁+集群+一致Hash算法+底层技术原理

1.Java基础还是需要掌握牢固,重点会问HashMap等集合类,以及多线程、线程池等。

41810

扫码关注云+社区

领取腾讯云代金券