DB time实时过程分析
在我们查看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)-(END_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%
和基准值差别不大,都是合理的范围之内了。
其实这个问题的根本原因就在于采样的范围,参考的基准越近,得到的误差范围就越低。打个简单的比方,就根据统计近年来的工资收入水平,我们还以解放前的标准来算,现在的误差就会很大,而且不准确,以近些年来的情况来统计,结果就会在范围之内,是一个基本可信的值了。
DB time实时过程分析的更多相关文章
- 关于跨DB增量(增、改)同步两张表的数据小技巧
有些场景下,需要隔离不同的DB,彼此DB之间不能互相访问,但实际的业务场景又需要从A DB访问B DB的情形,这时怎么办?我认为有如下常规的三种方案: 1.双方提供RESET API,需要访问不同DB ...
- 6、android 网络编程
1.基于socket的用法 服务器端: 先启动一个服务器端的socket ServerSocket svr = new ServerSocket(8989); 开始侦听请求 Socket s ...
- Android实现网络多线程断点续传下载(转)
本示例介绍在Android平台下通过HTTP协议实现断点续传下载. 我们编写的是Andorid的HTTP协议多线程断点下载应用程序.直接使用单线程下载HTTP文件对我们来说是一件非常简单的事.那么,多 ...
- Android多线程.断点续传下载
多线程,可断点续传的demo!最早写于2010.7! /** * @brief 主界面 * @author lixp */ public class HomeActivity exten ...
- Android实现网络多线程断点续传下载
本示例介绍在Android平台下通过HTTP协议实现断点续传下载. 我们编写的是Andorid的HTTP协议多线程断点下载应用程序.直接使用单线程下载HTTP文件对我们来说是一件非常简单的事.那么,多 ...
- jmeter入门系列文章二 版本号介绍
转载时请标注源自:http://blog.csdn.net/musen518 jmeter版本号公布频率一般为1年,每年会有一个版本号升级 截止2015年底,最新版本号为2.13,最新最全的更新信息一 ...
- Android网络多线程断点续传下载
本示例介绍在Android平台下通过HTTP协议实现断点续传下载. 我们编写的是Andorid的HTTP协议多线程断点下载应用程序.直接使用单线程下载HTTP文件对我们来说是一件非常简单的事.那么,多 ...
- Android多线程断点下载的代码流程解析
Step 1:创建一个用来记录线程下载信息的表 创建数据库表,于是乎我们创建一个数据库的管理器类,继承SQLiteOpenHelper类 重写onCreate()与onUpgrade()方法 DBOp ...
- andoid 多线程断点下载
本示例介绍在Android平台下通过HTTP协议实现断点续传下载. 我们编写的是Andorid的HTTP协议多线程断点下载应用程序.直接使用单线程下载HTTP文件对我们来说是一件非常简单的事.那么,多 ...
随机推荐
- poj 2480 Longge's problem 积性函数
思路:首先给出几个结论: 1.gcd(a,b)是积性函数: 2.积性函数的和仍然是积性函数: 3.phi(a^b)=a^b-a^(b-1); 记 f(n)=∑gcd(i,n),n=p1^e1*p2^e ...
- SQL Server 脚本
创建数据库: --创建数据库 CREATE DATABASE Accounting -- 新数据库的名称 ON --主文件 ( NAME = 'Accounting', --文件名 FILENAME ...
- BZOJ 4199 品酒大会
以前一直听说什么后缀数组height合并之类的 表示我这种后缀数组都敲不熟的蒟蒻怎么会写 但是做了做觉得还是很简单的嘛 这个题是有两问的,第一问是求LCP>=R的后缀对有多少个 这个就是AHOI ...
- STM32的GPIO口的输出开漏输出和推挽输出
本文来自cairang45的博客,讲述了STM32的GPIO口的输出开漏输出和推挽输出, 作者博客:http://blog.ednchina.com/cairang45 本文来自: 高校自动化网(Ww ...
- Android ListView无法触发ItemClick事件
Android ListView无法触发ItemClick事件 开发中很常见的一个问题,项目中的listview不仅仅是简单的文字,常常需要自己定义listview,自己的Adapter去继承Base ...
- 机器人学 —— 轨迹规划(Configuration Space)
之前的轨迹规划中,我们只考虑了质点,没有考虑机器人的外形与结构.直接在obstacle map 中进行轨迹规划,然而世纪情况中,机器人有固定外形,可能会和障碍物发生碰撞.此情况下,我们针对机器人自由度 ...
- OpenGL基础知识
基本概念 透视(Perspective)变换(Transformation)投影矩阵(Projection Matrix):用于将3D坐标转换为2D屏幕坐标光栅化(Rasterization): 实际 ...
- USACO Section 2.2: Subset Sums
dp题,一碰到dp我基本就是跪,搜了网上的答案分两种,一维和二维. 先讲二维,sum[i][j]表示前i个数的subset里差值为j的分法数量.当加入数字i时,有两种选择,某一个set和另外一个set ...
- 7.cadence原理图后续[原创]
一.网表输出 1.自动编号 输出网表前,不能有问号 -- 效果: ---- -- 效果: 2.DRC检查 输出网表前需要DRC检查 3.网表输出 二.生成BOM表 法1: 法2: --- 点击OK: ...
- WCF约束名称的用法
<!--<endpoint address="" binding="basicHttpBinding" bindingConfiguration=& ...