Resource Manager

  1. 云栖社区>
  2. 博客>
  3. 正文

Resource Manager

jan1990 2019-04-09 10:59:07 浏览479
展开阅读全文
  1. 什么是Resource Manager
    Oracle Database Resource Manager(RM)是Oracle用于管理负载冲突而设计的工具。RM在10g版本中已经诞生,但不完善,有很多Bug。在11g版本里已经相当成熟,我们也希望在平安的11g数据库推广。RM可以管理很多类型的负载冲突,就平安实践而言,我们主要管理CPU竞争。通过合理的设置,能将连接DB的所有session分组到若干消费组里面,为每个消费组设置最小保证CPU消耗百分比,当某个组里某个session出问题,导致CPU消耗100%的时候,RM会将影响局限在这个消费组内,其他消费组的session还是能够拿到之前设定的CPU使用量,正常运行,从而隔离CPU竞争带来的影响。
  2. RM工作机制简介
    2.1 修改连接方式,设置消费组

我们在DB上创建service,所有应用连接都通过service连数据库

然后将service es_srv_oltp1 设置到消费组 cg_1 里面。如法炮制,将其他两个service也分别对应到cg_2和cg_3两个消费组里。

service 消费组
es_srv_oltp1 cg1
es_srv_etl cg2
es_srv_other cg3

不同的应用通过不同的service连接数据库,这样所有session都会对应到上述三个消费组里的一个。

2.2设置消费组的CPU保证值
CPU保证值是指当CPU使用率冲到100%(即出现争用)的时候,每个消费组获得的CPU配额。它不是限制值,是保证值。在出现争用的时候,RM的作用才体现出来(就像消防队,没火灾的时候,是感觉不到的,火灾来了,消防队才出现)。消费组CPU使用配额用百分比来表示,其总和是100%,设置如下:
service 消费组 CPU保证量
es_srv_oltp1 cg1 60%
es_srv_etl cg2 30%
es_srv_other cg3 10%

注:CPU总量,不是主机CPU总数,而是一个Oracle参数 cpu_count。即Oracle认为本库CPU使用量达到了cpu_count的设置值,即视为CPU出现争用,可能此时主机CPU使用率并未达到100%。同一主机上多个库的cpu_count设置及隔离,请参见第3节:3. What’s More? Instance Caging

2.3 情景演示
为了描述清楚,首先假设主机上只运行一个DB,DB独享整台主机的CPU(关于一台主机上多个DB的情况,有Resource Manager的兄弟 Instance Caging 技术处理,后面再详细介绍)。其次要引入“业务负载量”的概念,即衡量业务的实际CPU需求。例如某一时刻,cg1的业务负载量是45%,意思是负载独占这个库的所有资源运行,CPU消耗是45%。业务负载量也可能超过100%,例如cg1的业务负载量是300%,那么当前主机的CPU使用率肯定会冲到100%,换句话说,假设当前主机CPU增强为当前的3倍,那么刚好能够无等待地跑完这个负载量;如果主机CPU增强为当前的6倍,那么跑完这个负载量的CPU使用率是50%。(假设都是线性的)

场景1:通常情况
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 34% 34%
cg2 30% 22% 22%
cg3 10% 8% 8%
总计 100% 64% 64%
这种情况下,业务负载总和是没有超过CPU处理能力的,各消费组实际消耗量等于负载量。

场景2:某一消费组(cg2)业务负载量增大,超过了保证量,但总体CPU没有达到100%
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 34% 34%
cg2 30% 46% 46%
cg3 10% 8% 8%
总计 100% 88% 88%
虽然cg2负载量已经超过RM设置的保证值,但因为CPU没有出现争用,因此RM不会起作用,cg2可以使用超过其配额的CPU。

场景3:cg2业务负载量持续增大,整体CPU消耗超过100%
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 34% 34%
cg2 30% 88% 58%
cg3 10% 8% 8%
总计 100% 130% 100%
CPU已经100%,RM介入,一方面保证cg1与cg3的正常CPU使用,然后把剩下的所有CPU资源给cg2(但cg2仍然是不满足的,组内session争用CPU)

场景3.1:特别地,如果cg1和cg3的业务负载量回落,CPU能够“喂饱” cg2,那么争用可能消除(同场景2),RM不介入。
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 6% 6%
cg2 30% 88% 88%
cg3 10% 2% 2%
总计 100% 96% 96%

场景4,与场景3类似,但最重要的是,cg2的业务负载量远远超过了DB的处理能力,夸张一点,例如业务负载量为400%
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 34% 34%
cg2 30% 400% 58%
cg3 10% 8% 8%
总计 100% 442% 100%
那么RM介入,不管cg2负载量如何夸张,总能保证cg1和cg2的使用量不受影响(同场景3)。当然,这种情况下,无论cg1和cg2负载量如何回落,都有CPU争用。
场景4.1 cg1和cg2负载量回落之后的情况:
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 6% 6%
cg2 30% 400% 92%
cg3 10% 2% 2%
总计 100% 408% 100%

场景4.2 极端情况是,cg1和cg3业务负载量回落到0%,CPU依然100%,此时RM还是起效的:
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 0% 0%
cg2 30% 400% 100%
cg3 10% 0% 0%
总计 100% 400% 100%

场景4.3 如果这时候cg1或者cg3又有任务了,负载量又上来了,那么RM是会保证cg1或cg3正常需求的
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 23% 23%
cg2 30% 400% 77%
cg3 10% 0% 0%
总计 100% 423% 100%

场景5,当CPU 100%且两个消费组的业务负载量均超过目前可用CPU量,RM会按两者保证量的比例来分配剩余CPU:
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 120% 62%
cg2 30% 400% 31%
cg3 10% 7% 7%
总计 100% 527% 100%
cg1和cg2的业务负载量已经远远超过主机总量,他们按照2:1的比例,瓜分剩余的93%的CPU。而cg3是完全不受影响的(在保证值10%之内,需要多少就会用多少)

场景6, 极端情况,当每个消费组业务负载量均超过最小保证值,那么可以看到最终CPU消耗量与设置值相同了
消费组 CPU保证量 业务负载量 实际CPU消耗量
cg1 60% 120% 60%
cg2 30% 400% 30%
cg3 10% 50% 10%
总计 100% 570% 100%

2.4 有无RM的情况对比
如果没有RM,当CPU出现争用的时候,我们可以理解为,各个session之间CPU的实际消耗大致是按照其“申请量”也就是业务负载量的比例来分配的。
左图是有RM的场景4,右图是相同场景下没有RM的情况
消费组 CPU保证量 业务负载量 实际CPU消耗量 消费组   业务负载量 实际CPU消耗量
cg1 60% 34% 34% cg1   34% 7.69%
cg2 30% 400% 58% cg2   400% 90.50%
cg3 10% 8% 8% cg3   8% 1.81%
总计 100% 442% 100% 总计   442% 100%
可以看到,如果没有RM,cg1只能拿到7.69%的CPU资源,而其正常负载应该需要34%,因此cg1里的session会因为CPU不足出现大量等待,这就是我们平常看到的生产库某一个session将CPU耗完时,把其他session也堵塞的情况。而RM的核心作用,在于保证每一个消费组的最低消费量,而不至于被别人抢占。

2.5 其他

启用/禁用RM很简单,只需要设置一个Oracle的系统参数:  alter system set resource_manager_plan = 'xxxx' scope=both;

设置之后立即生效,无需重启数据库。当然,启用/禁用之后,只对新的session有用,正在运行的语句不受影响。所以不能等到DB真的出现CPU争用才启用RM,必须事先就启用,防患于未然。

  1. What’s More? Instance Caging
    RM只是隔离了一个DB内部的资源竞争,而一个主机上的多个DB,是通过Instance Caging(IC)来实现类似的作用的。步骤大致有两个:
  2. 每个库都要启用RM
  3. 为每个库设置cpu_count参数,这就是该库能够消耗的CPU总量。这是个限制值,而非上述RM的保证值。当数据库CPU消耗达到cpu_count参数设置值时,Oracle即视作CPU出现争用,RM立即介入。注意,此时可能主机CPU消耗量还没有达到100%,但也可能早就100%了。
  4. 一个主机上可以有多个库,每个库都有独立的cpu_count设置。一般情况下,所有库的cpu_count之和,应该与主机真实cpu数相等(partitioned/瓜分)。当然,也可以“超分”(over-provisioning),即cpu_count数之和大于主机真实cpu数。此时,可能出现数据库cpu消耗量还没有达到cpu_count数,主机cpu使用率就已经冲到100%了,那么RM也是会介入的。这时候,各个库的cpu使用量,是按照cpu_count的比例来分配的。

注:cpu_count值可以动态在线调整,无需重启库。

场景分析:假设某主机逻辑CPU数一共是32个,上面运行了3个DB:

  1. 所有库都有启用IC ,设置为partitioned,即瓜分CPU
    DB名 版本 cpu_count

DB-X 11g 10
DB-Y 11g 10
DB-Z 11g 12
总计 32

1.1 通常情况下(没有CPU争用):
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 7 7 7/32
DB-Y 11g 10 4 4 4/32
DB-Z 11g 12 8 8 8/32

1.2某一个DB负载异常,不会影响其余两个
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 7 7 7/32
DB-Y 11g 10 50 10 10/32
DB-Z 11g 12 8 8 8/32

1.3 某两个DB负载异常,也不会影响第三个
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 7 7 7/32
DB-Y 11g 10 50 10 10/32
DB-Z 11g 12 100 12 12/32

  1. IC设置为over-provisioning,所有库都有启用IC,并且超过主机总CPU数(50>32)
    DB名 版本 cpu_count

DB-X 11g 10
DB-Y 11g 20
DB-Z 11g 20
总计 50

2.1 当整体负载偏小,每个实例都没有达到cpu_count上限,主机CPU也没有100%时,那么实际使用量是没有打折扣的。
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 7 7 7/32
DB-Y 11g 20 4 4 4/32
DB-Z 11g 20 8 8 8/32

2.2 当某一个库负载超过cpu_count,就算主机cpu还有剩余,也会打折
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 15 10 10/32
DB-Y 11g 20 4 4 4/32
DB-Z 11g 20 8 8 8/32
总计 50 27 22 22/32

2.3 也有可能每个库的CPU都没有达到cpu_count,但主机CPU使用率已经100%了(此时IC和RM是没有介入的)。此时每个库的CPU实际使用量是按照申请量的比例来分配的(暂且称为丛林法则),即谁负载高谁获得的多。
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 8 8/41*32=6.24 6.24/32=19.5%
DB-Y 11g 20 18 18/41*32=14.05 14.05/32=43.9%
DB-Z 11g 20 15 15/41*32=11.71 11.71/32=36.6%
总计 50 41 32.00 100.0%

2.4 如果DB-Z的CPU消耗持续增长,超过cpu_count时,IC/RM介入,将其实际申请量限制在20。因此,三者是以8:18:20的比例来瓜分CPU的。
DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 8 8/46*32=5.57 17.4%
DB-Y 11g 20 18 18/46*32=12.52 39.1%
DB-Z 11g 20 40 20/46*32=13.91 43.5%
总计 50 66 32.00 100.0%
业务负载量看起来是66,但实际只有46。

2.5 以2.4为基础,进一步看RM行为。DB-Y上由于IC/RM没有介入,因此各CG实际CPU使用量按照“丛林法则”分配:
DB名 消费组 CPU分配% RM保证量 业务负载量 实际使用量
DB-Y CG1 20% 2020%=4 15 12.52(15/18)=10.43

CG2    80%    20*80%=16    3    12.52*(3/18)=2.087

可以看到,虽然CG2的CPU保证量是16,但由于没有触发RM生效,就算其申请量很少,只有3个CPU,也无法满足(实际只拿到2..087个)。这个例子说明,超分的IC设置,会导致RM效果打折扣。

  1. 存在非11g库,不是所有库都能启用IC,但cpu_count没有超分。即便是这样,11g的库也会受非11g库影响(丛林法则)
    DB名 版本 cpu_count

DB-X 11g 10
DB-Y 11g 8
DB-Z 10g 14
总计 32

DB名 版本 cpu_count 业务负载量
(CPU申请量) CPU实际使用量 实际使用率
DB-X 11g 10 6 6/50*32=3.84 12.0%
DB-Y 11g 8 4 4/50*32=2.56 8.0%
DB-Z 10g 14 40 40/50*32=25.6 80.0%
总计 32 50 32 100.0%

  1. 说明
    本文描述生产库实施Resource Manager 的详细脚本。

  1. 详细步骤
    2.1 设置cpu_count

cpu_count可以在线调整,无需重启库
alter system set cpu_count=32 scope=both;
注意:按照平安规范,另一个重要参数log_buffer会受cpu_count影响,请一并考虑。
2.2 service管理
2.2.1 service创建
有两种创建Service的方式:

  1. 直接修改初始化参数 service_names
    首先检查原service_names参数:

SQL> show parameter service_names
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
service_names string srvp_x1, srvp_x2
如果要新增一个叫srvp_x3的service,直接将其加在参数后面,注意多值参数必须用逗号分隔
alter system set service_names='srvp_x1','srvp_x2','srvp_x3' scope=both;
执行之后,在数据库里添加了service的同时(从dba_services查询),这个service也自动启动了(从v$active_services)。也就是说如果DB重启,这三个service都会自动启动。

  1. 使用dbms_service.create_service 包创建service,分为两步:
    第一步仅仅创建service,但不启动(仅仅从dba_services能够查到,但v$active_services和v$parameter里没有,监听里也没有)

exec dbms_service.create_service('srvp_x3', 'srvp_x3');
第二步启动service
exec dbms_service.start_service ('srvp_x3');
这样service才算真正可用。

技术上也可以用直接修改参数service_names的方式来创建,但我们不允许这样做。因为DG结合service实现透明故障切换的话,所有service必须使用dbms包创建(不是每个库都要启动所有service,是选择性启动的。有DB startup trigger负责按条件拉起service)。详见DG规范。

2.2.2 service校验
1、 使用动态监听,以便使service立即生效 (local_listener参数设置正确)
2、 lsnrctl里查看service状态

注:默认情况下,监听里的service都带上了db_domain的后缀。我们的规范要求设置db_domain为空,这样监听里的service与设置的值就一样了。

2.2.3 service删除
exec dbms_service.stop_service ('srvp_x3');
exec dbms_service.delete_service ('srvp_x3');

2.2.4 使用service连接数据库
JDBC连接写法:jdbc:oracle:thin:@(description =(address = (protocol = tcp)(host = xxXXXXX)(port = 1534))(connect_data = (service_name = srvp_x3)))
tns_names连接写法: x3=(description =(address = (protocol = tcp)(host = xxXXXXX)(port = 1534))(connect_data = (service_name = srvp_x3)))
如果要实现TAF,连接串写法详见相关规范。
2.3 Resource Manager对象管理
使用dbms_resource_manager来管理RM对象。创建消费组以及设置配额等操作,需要整体生效,不能有中间状态。因此在正式脚本开头,需要先清空并创建一个未决区(pending area),在脚本结束需校验并提交,格式如下:
begin dbms_resource_manager.clear_pending_area(); end; --清空
begin dbms_resource_manager.create_pending_area(); end; --新建
具体脚本
begin dbms_resource_manager.validate_pending_area();end; --校验
begin dbms_resource_manager.submit_pending_area();end; --提交
clear_pending_area 的作用,是清除当前未决区,以防止之前有命令未生效,干扰本次操作。
2.3.1 全新创建Resource Manager Plan
Resource Manager作为新建库的标配,只要是新建库,都应该创建并实施RM。本节讲述首次创建Resource Manager。

begin dbms_resource_manager.clear_pending_area(); end; --清空
begin dbms_resource_manager.create_pending_area(); end; --新建
2.3.1.1 创建资源计划:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN => 'SALES_NORMAL',
COMMENT => 'Normal plan for sales');
END;

            注意,对于一个库,可以创建多个资源计划并可以随时切换。但目前我们只创建一个,命名方式是{sid}_NORMAL

2.3.1.2 创建消费组:
begin
dbms_resource_manager.create_consumer_group (
consumer_group => 'cg_sales_pub_life',
comment => 'for PSS-ESALES-LIFE and PSS-ESALES-PUB');
end;

            重复上述命令,逐个创建消费组

2.3.1.3 设置资源配额
begin
dbms_resource_manager.create_plan_directive(
plan => 'SALES_NORMAL',
group_or_subplan => 'cg_sales_pub_life',
mgmt_p1 => 75,
comment => 'CPU 75%'
);
end;
资源计划指示即设置每个消费组的CPU保证值。如法炮制,为每个消费组指定该值。注意,最后必须为OTHER_GROUPS指定保证值:
begin
dbms_resource_manager.create_plan_directive(
plan => 'SALES_NORMAL',
group_or_subplan => 'OTHER_GROUPS',
comment => 'Directives for the other users group...',
mgmt_p1 => 10
);
end;
2.3.1.4 创建映射关系
即为每一个service指定对应的消费组
begin
dbms_resource_manager.set_consumer_group_mapping
(attribute =>'service_name',
value => 'srv_sales_pss-pub-life',
consumer_group => 'cg_sales_pub_life');
end;
重复上述语句,为每个service设置映射关系。如果没有设置映射关系,则自动对应到OTHER_GROUPS里。
注:RM提供了多种方式设置映射关系,例如根据连接用户,或者客户端程序等。我们目前只用service映射到消费组。但是针对cg_admin,使用用户映射,将sys和dbmgr映射到cg_admin(以下代码不用改动):
begin
dbms_resource_manager.set_consumer_group_mapping
(attribute =>'oracle_user',
value => 'sys',
consumer_group => 'CG_ADMIN');
end;
begin
dbms_resource_manager.set_consumer_group_mapping
(attribute =>'oracle_user',
value => 'dbmgr',
consumer_group => 'CG_ADMIN');
end;
--将oracle_user的优先级提到service_name之前:
begin dbms_resource_manager.set_consumer_group_mapping_pri
( explicit =>1,
oracle_user =>2,
service_name =>3,
client_os_user =>4,
client_program =>5,
client_machine =>6,
module_name =>7,
module_name_action =>8,
service_module =>9,
service_module_action =>10,
client_id => 11);
end;

至此,RM对象创建完毕,检查提交:
begin dbms_resource_manager.validate_pending_area();end;
begin dbms_resource_manager.submit_pending_area();end;

2.3.1.5 授权
针对不同数据库用户,每个消费组都有权限控制,即不是所有用户的session都可以映射到该消费组的,必须显示授权。如果不想每个用户都授权,可以将权限授予PUBLIC用户,这也是平安目前的做法。
begin dbms_resource_manager.clear_pending_area(); end;
begin dbms_resource_manager.create_pending_area(); end;

begin
dbms_resource_manager_privs.grant_switch_consumer_group(
grantee_name => 'public',
consumer_group => 'cg_sales_pub_life',
grant_option => FALSE);
end;
也就是说允许所有用户的session都可以映射到cg_sales_pub_life(前提是session使用了对应的service连接数据库)。
重复上述语句,将每个消费组授权给PUBLIC用户。
校验并提交
begin dbms_resource_manager.validate_pending_area();end;
begin dbms_resource_manager.submit_pending_area();end;
2.3.2 在已有Resource Manager Plan里新增消费组
一个已经应用RM的库上,新增子系统,需要新增消费组。此时需要调整其他消费组的配额,然后创建新的消费组。
begin dbms_resource_manager.clear_pending_area(); end;
begin dbms_resource_manager.create_pending_area(); end;

调整消费组配额
begin dbms_resource_manager.update_plan_directive(
plan => 'SALES_NORMAL',
group_or_subplan => 'cg_sales_pub_life',
new_mgmt_p1 => 70,
new_comment => 'CPU 70%');
end;

新增消费组跟前面一致,略过。

        提交

begin dbms_resource_manager.validate_pending_area();end;
begin dbms_resource_manager.submit_pending_area();end;

更多方法,请参阅Oracle文档。

完整脚本请参见《RM演示脚本.sql》。

虽然RM相关组件设置语句繁多,但内容格式较为固定,可以使用excel生成脚本。参见《RM脚本模板.xlsx》。

2.3.3 应用资源计划
通过设置参数resource_manager_plan来应用RM,立即生效无需重新启库。当然,立即生效并不意味着RM立即介入。介入条件参见2.1.2描述。
alter system set resource_manager_plan = 'SALES_NORMAL' scope=both;
相似地,停用资源计划,只要将该参数置空即可。
2.4 校验检查
2.4.1 检查相关参数:
select vp.name, vp.display_value, vp.isdefault, vp.isses_modifiable, vp.issys_modifiable
from v$parameter vp
where vp.name in ('service_names','local_listener','parallel_max_servers','parallel_servers_target'
,'parallel_degree_policy','resource_manager_plan','cpu_count'
,'parallel_adaptive_multi_user'
,'parallel_degree_limit');
2.4.2 查看消费组映射关系和cpu设置值
select * from dba_rsrc_group_mappings rm
select * from dba_rsrc_plan_directives rd where rd.plan = 'SALES_NORMAL';
2.4.3 查看连接session 的分布
select vs.resource_consumer_group , count(1)
from v$session vs
group by vs.resource_consumer_group
带service与CG:
select vs.service_name, vs.resource_consumer_group ,count(1)
from v$session vs
group by vs.service_name, vs.resource_consumer_group

2.5 RAC环境处理
RAC环境RM设置跟单节点完全一致,只在一个节点创建即可。

2.6 性能问题调查
当主机CPU冲高,RM介入后,可以用下面方法详细调查。注意请首先备份v$rsrcmgrmetric_history, v$active_session_history 两个重要视图!否则刷出内存了就不好调查问题了。

查看消费组实时的CPU使用情况和丢弃情况:
select begin_time, rh.consumer_group_name,
(select value from v$osstat where stat_name = 'NUM_CPUS') num_cpus,
(select value from v$parameter where name = 'cpu_count') num_db_cpus,
round(sum(cpu_consumed_time) / 60000,3) avg_running,
round(sum(cpu_wait_time) / 60000,3) avg_throttled
from v$rsrcmgrmetric_history rh
group by begin_time , rh.consumer_group_name order by begin_time desc , consumer_group_name ;
上述视图是1分钟的汇总量,可能将波峰削掉,从而看不出问题。可以从ASH统计每1秒的精确数据(gmact_ash_20180730为保存的ash):
select ash.sample_time, cg.consumer_group , round(sum(cnt)/60*100,2)||'%' act_util, rd.cpu_p1||'%' plan_util
from (
select ga.sample_time, ga.consumer_group_id, sum(1) cnt
from gmact_ash_20180730 ga
where sample_time > to_date('2018/07/30 09:40:07','yyyy/mm/dd hh24:mi:ss')
and sample_time<= to_date('2018/07/30 09:41:07','yyyy/mm/dd hh24:mi:ss')
and ga.session_state = 'ON CPU'
group by ga.sample_time ,ga.consumer_group_id
) ash ,dba_rsrc_consumer_groups cg ,dba_rsrc_plan_directives rd
where cg.consumer_group_id = nvl(ash.consumer_group_id, select consumer_group_id from dba_rsrc_consumer_groups where consumer_group = 'OTHER_GROUPS')
and rd.group_or_subplan = cg.consumer_group
and rd.plan = 'RP_GMACT_NORMAL'
group by ash.sample_time, cg.consumer_group ,rd.cpu_p1
order by ash.sample_time, cg.consumer_group

从AWR历史视图,查看每个snapid的使用情况。这是15分钟的平均量,粒度就更粗了:
select begin_time, end_time, gap_sec, snap_id, cg_name , cpu_time_ms ,cpu_wait_ms
, round(cpu_time_ms/1000/gap_sec,3) cpu_consumed
, round(cpu_wait_ms/1000/gap_sec,3) cpu_throttled
from (
select s.begin_time, s.end_time, rc.snap_id, rc.consumer_group_name cg_name ,rc.consumed_cpu_time ,rc.cpu_wait_time
, rc.consumed_cpu_time - lag(rc.consumed_cpu_time,1,rc.consumed_cpu_time) over (order by rc.consumer_group_name, rc.snap_id) cpu_time_ms
, rc.cpu_wait_time - lag(rc.cpu_wait_time,1,rc.cpu_wait_time) over (order by rc.consumer_group_name, rc.snap_id) cpu_wait_ms
, min(rc.snap_id) over (partition by 1) pre_snap
, extract(minute from gap)*60 + extract(second from gap) as gap_sec
from dba_hist_rsrc_consumer_group rc
,(

select ss.snap_id, ss.begin_interval_time begin_time, ss.end_interval_time end_time, (ss.end_interval_time-ss.begin_interval_time) gap
from dba_hist_snapshot ss
where ss.begin_interval_time > to_date('20180928 05:40','yyyymmdd hh24:mi')
and   ss.begin_interval_time < to_date('20180928 06:20','yyyymmdd hh24:mi')

)s
where rc.snap_id = s.snap_id
order by rc.consumer_group_name, rc.snap_id
)
where snap_id != pre_snap
order by snap_id , cg_name

网友评论

登录后评论
0/500
评论
jan1990
+ 关注