Exadata管理IO的方法(IORM)
在Exadata平台上有三种管理IO的方法:数据空间IORM、类别IORM和数据库内部IORM。这三种方法各自满足不同的IO管理需求。数据库建IORM通过数据库名分配IO资源,类别IORM通过数据库间共同的类别名分配IO资源,数据库内部IORM在数据库内部通过DBRM使用者组管理IO资源。可以选择任何一种方法去管理IO资源,或者也可以把它们结合起来实现一种更复杂的资源计划。当这些方法在一起使用时,Oracle以下面的次序对IO进行调度:1)在类别间进行分配;2)在数据库间进行分配;3)在每个数据库内部的每个类别里面按使用者组进行分配。
1、 数据库间IO资源管理
数据库间IO资源管理是指IORM根据数据库名在多个数据库间管理IO优先级的方法。数据库间IORM通在每个存储节点上配置一个IORM计划,把IO资源分配到不同的数据库上。IORM计划使用IO指令定义分配优先级别。每个存储节点基于在节点内定义的本地IORM计划管理自己的IO队列。在同个存储网格内,所有的存储节点的IORM计划已改是一模一样的。如果把所有的Exadata存储节点分割成多个存储网格,每个网格可以有不同的IORM计划,但在一个存储网格内部,所有的存储节点成员的IORM计划则应该是一致的。
数据库间IORM计划
配置数据库间IORM
数据库间的IO资源管理通过一个IORM计划进行配置。这个计划确定存储节点上数据库IO的优先级。IORM计划通过使用CellCLI命令ALTER IORMPLAN创建。每个存储节点只能有一个IORM计划,而不管有多少个ASM实例(集群或者单实例)访问这个存储节点。创建数据库间IORM计划的第一步是定义每个数据库的IO分配策略:
CellCLI> ALTER IORMPLAN - dbPlan=( - (name=SCRATCH, level=1, allocation=60), - (name=SNIFF, level=2, allocation=80), - (name=other, level=3, allocation=100)) |
注:属性LEVEL指定在计划中一个数据库相对于其他数据库被给予的优先级。属性ALLOCATION决定一个数据库在其所在级别被给予的总的可用IO的百分比。
使用CellCLI命令listiormplan detail显示IORM计划。
CellCLI> list iormplan detail name: enkcel01_IORMPLAN catPlan: dbPlan: name=SCRATCH,level=1,allocation=60 name=SNIFF,level=2,allocation=80 name=other,level=3,allocation=100 status: inactive |
注:cataPlan是空的。
一个级别上的所有数据库的分配总额不能超过100%。否则报错:
CellCLI>ALTER IORMPLAN -
dbPlan=( -
(name=SCRATCH, level=1, allocation=60), -
(name=SNIFF, level=1, allocation=80), -
(name=other, level=3, allocation=100))
CELL-00006: IORMPLAN contains an invalid allocation total.
使用CellCLR命令ALTER IORMPLAN ACTIVE进行计划IORM计划才能够管理IO资源。
2、 类别IORM
IO资源管理器IORM通过一个新属性category扩展了使用者组的含义。使用者组允许DBRM管理一个数据库内部的资源,类别则提供了多个数据库间的IO资源管理方式。
配置数据库间IORM
设置类别IORM第一步是创建DBRM的使用者组,在数据库中创建类别,并把它们赋给使用者组,最后就是创建IORM计划,以针对每个类别建立起IO资源分配与优先级策略。可以在类别IORM计划中对多定义八个级别。
创建两个心的类别APPS_CATEGORY和BATCH_CATEGORY,并把它们指派到APPS、REPORTS和MAINTENANCE使用者组。
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area();
-- Create Categories -- dbms_resource_manager.create_category( category => 'APPS_CATEGORY', comment => 'Category for Interactive Applications'); dbms_resource_manager.create_category( category => 'BATCH_CATEGORY', comment => 'Reports & Maintenance Jobs');
-- Assign Consumer Groups to Categories -- dbms_resource_manager.update_consumer_group( consumer_group => 'APPS', new_category => 'APPS_CATEGORY'); dbms_resource_manager.update_consumer_group( consumer_group => 'REPORTS', new_category => 'BATCH_CATEGORY'); dbms_resource_manager.update_consumer_group( consumer_group => 'MAINTENANCE', new_category => 'BATCH_CATEGORY'); dbms_resource_manager.submit_pending_area(); END; / |
通过产销视图DBA_RSRC_CONSUMER_GROUPS检查使用者组到类别的映射关系:
SELECT consumer_group, category FROM DBA_RSRC_CONSUMER_GROUPS WHERE consumer_group in ('APPS', 'REPORTS', 'MAINTENANCE', 'OTHER_GROUPS') ORDERBYcategory; |
创建一个IORM计划并设置这些类别IO资源的上限。
CellCLI> alter iormplan dbplan= '' CellCLI> alter iormplan catplan=( - (name=APPS_CATEGORY, level=1, allocation=70), - (name=BATCH_CATEGORY, level=1, allocation=30), - (name=OTHER, level=2, allocation=100) - ) |
注:每个存储节点维护自己的IORM计划,因此需要先在存储网格里的每个存储节点上删除原有的数据库间的IORM计划。
查看类别IORM计划:
CellCLI> list iormplan detail name: enkcel01_IORMPLAN catPlan: name=APPS_CATEGORY,level=1,allocation=70 name=BATCH_CATEGORY,level=1,allocation=30 name=OTHER,level=2,allocation=100 dbPlan: status: inactive |
注:因为创建执行删除了之前的iorm计划,所以dbPlan是空的。
3、 数据库内部IORM
数据库内部IORM通过在每个数据库上使用DBRM的管理属性MGMT_P1..8进行配置。通过吧IO分配和CPU分配绑定在一起,IORM把这些优先级规则复制到存储层,从而保持了CPU和IO之间一直的分配方案。
配置数据库间IORM
在Exadata平台上,当一个DBRM资源计划被激活时,数据库会把计划的描述,包括MGMT_Pn质量,传送给存储网格里的所有存储节点。当在存储节点上启动cellsrv时,这种情况也会发生。因此,当在存储网格上安装了一个新的节点、重启一个节点,后者重启cellsrv服务时,数据库内部资源计划都会自动被推送到存储节点上。如果IORM在存储节点上是激活的,它将产生一个数据库内部资源计划,并开始根据资源指令对IO优先级inxS管理:
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.create_plan( plan => 'daytime', comment => 'Resource plan for normal business hours'); dbms_resource_manager.create_plan_directive( plan => 'daytime', group_or_subplan => 'APPS', comment => 'High priority users/applications', mgmt_p1 => 70); dbms_resource_manager.create_plan_directive( plan => 'daytime', group_or_subplan => 'REPORTS', comment => 'Medium priority for daytime reports processing', mgmt_p2 => 50); dbms_resource_manager.create_plan_directive( plan => 'daytime', group_or_subplan => 'MAINTENANCE', comment => 'Low priority for daytime maintenance', mgmt_p3 => 50); dbms_resource_manager.create_plan_directive( plan => 'daytime', group_or_subplan => 'OTHER_GROUPS', comment => 'All other groups not explicitely named in this plan', mgmt_p3 => 50); dbms_resource_manager.validate_pending_area(); dbms_resource_manager.submit_pending_area(); END; / altersystemset resource_manager_plan='daytime'; CellCLI> alter iormplan dbplan= '',catplan='' CellCLI> alter iormplan active |
4、 IORM监控和指标
1)IORM指标
存储节点一直在后台收集和维护着IORM相关的IO性能指标信息。这些指标可以用来确定IORM计划及在环境中定义好的计划指令对数据库、类别和使用者组产生的影响。每个60s,cellsrv会收集来自IO队列的关键性能指标,并将其存储在METRICCURRENT对象中。
CellCLI> describe metriccurrent name alertState collectionTime metricObjectName metricType metricValue objectType
CellCLI> LIST METRICCURRENT - WHERE name = 'CT_IO_RQ_LG' - AND objecttype = 'IORM_CATEGORY' - ATTRIBUTES name, objecttype, metricObjectName, metricValue CT_IO_RQ_LG IORM_CATEGORY OTHER 0 IO requests CT_IO_RQ_LG IORM_CATEGORY _ASM_ 0 IO requests |
注意:对闪存(Flash Cache)、给予闪存的网格盘,还有物理磁盘(网格盘)的IO请求的指标都会被收集。不过,IORM只是对物理磁盘的IO资源进行管理。
指标的历史数据保留的天数由存储单元的属性METRICHISTORYDAYS执行(默认是7天)。
CellCLI> list cell attributes name,metricHistoryDays
cell01 7
可使用如下命令修改为期望保留的天数:
CellCLI> alter cellmetricHistoryDays='14'
Cell cell01 successfully altered
CellCLI> list cell attributes name,metricHistoryDays
cell01 14
CellCLI> list metriccurrent iorm_mode
IORM_MODE cell01 2
IORM_MODE属性可能的值如下:
l 1,IORM目标被设置为low_latency
l 2,IORM目标被设置为balanced
l 3,IORM目标被设置为high_throughput
IORM_MODE的值也可能介于1和2,2和3之间,这标示在轮询期间,优化模式发生了变化。这也代表了它与IORM优化目标的接近程度。
IORM监控指标的objectType属性通过对象METRICCURRENT里的name属性进行分类。指标的名字(name)有一些缩写拼接在一起,这些缩写代表IO使用者组的类型、存储设备的类型,还有一个描述性的名字:
{consumer_type}_{device type}_{metric}
Consumer_type代表IORM使用者组:
DB = 数据库建IORM计划
CT = 类别IORM计划
CG = 数据库内IORM计划
Device_type是服务IO请求的存储类型:
FC = 闪存
DF = 给予闪存的网格盘
'' = 如果不是上面的两种,这个指标代表物理磁盘IO
Metric是指标的描述性名字:
SM = 小IO
LG = 大IO
IORM METRICCURRENT名字熟悉的描述 | |
名字 | 描述 |
{CG,CT,DB}_IO_BY_SEC | 此IO使用者组每秒的兆字节数 |
{CG,CT,DB}_IO_LOAD | 此IO使用使用者组的平均IO负载 |
{CG,CT,DB}_IO_RQ_{SM,LG} | 此IO使用者组小/大IO请求的累计值 |
{CG,CT,DB}_IO_RQ_{SM,LG}_SEC | 此IO使用者组发出的每秒小/大IO请求的次数 |
{CG,CT,DB}_IO_WT_{SM,LG} | 此IO使用者组的IO请求等待被IORM调度的累积等待事件(以毫秒计算) |
{CG,CT,DB}_IO_WT_{SM,LG}_RQ | 从上面的{CG,CT,DB}_IO_WT_{SM,LG}计算得到。它存储过去一分钟IO请求等待IORM调度的平均等待时间(以毫秒计算)。这个值比较大则意味着此IO使用者组的IO负载超过了它的资源分配额。对于低优先级使用者,这可能是要达到的效果。对于高优先级使用者,这可能意味着必须把更多的IO资源分配给它,以满足业务目标。 |
{CG,CT,DB}_IO_UTIL_{SM,LG} | 此IO使用者组所花IO占总IO资源的百分比。 |
注明:以上所有的累计指标当满足一定条件时会被重置为0,这些条件包括cellsrv被重启、IORM被启用、IORM计划改变了此IO使用者组的资源分配。
2)后台进程
为后台进程所内建的使用者组 | |
使用者组 | 描述 |
_ASM_ | 与ASM卷管理相关的IO请求 |
_ORACLE_BG_CATEGORY_ | 来自数据库后台进程的高优先级IO请求 |
_ORACLE_MEDPRIBG_CATEGORY_ | 来自数据库后台进程的中优先级IO请求 |
_ORACLE_LOWPRIBG_CATEGORY_ | 来自数据库后台进程的低优先级IO请求 |
3)挖掘指标
Cellcli命令行可以使用=、like或者and,对搜索条件设置多个过滤条件,不过,不支持OR操作,也不支持利用括号进行运算优先级的设置。
(1) IORM数据库指标报告
CellCLI> LIST METRICCURRENT - WHERE name LIKE 'DB_IO_.*' - AND objectType = 'IORM_DATABASE' - ATTRIBUTES name, objectType, metricObjectName, metricValue, collectionTime DB_IO_BY_SEC IORM_DATABASE DBUA0028933 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA0417641 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA0435485 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA1200747 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA2441898 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA2631217 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA2944998 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA3036386 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA3220803 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA3315760 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE DBUA4752711 0 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE SRCBFIN 3 MB/sec 2012-09-13T15:41:24+08:00 DB_IO_BY_SEC IORM_DATABASE _OTHER_DATABASE_ 0 MB/sec 2012-09-13T15:41:24+08:00 |
(2) IORM类别指标报告
CellCLI> LIST METRICCURRENT - WHERE name LIKE 'CT_IO_.*' - AND metricObjectName NOT LIKE '_.*' - ATTRIBUTES name, objecttype, metricObjectName, metricValue, collectionTime CT_IO_BY_SEC IORM_CATEGORY OTHER 30 MB/sec 2012-09-13T15:42:24+08:00 CT_IO_LOAD IORM_CATEGORY OTHER 1 2012-09-13T15:42:24+08:00 CT_IO_RQ_LG IORM_CATEGORY OTHER 2,006,354 IO requests 2012-09-13T15:42:24+08:00 CT_IO_RQ_LG_SEC IORM_CATEGORY OTHER 19.6 IO/sec 2012-09-13T15:42:24+08:00 CT_IO_RQ_SM IORM_CATEGORY OTHER 7,261,528 IO requests 2012-09-13T15:42:24+08:00 CT_IO_RQ_SM_SEC IORM_CATEGORY OTHER 318 IO/sec 2012-09-13T15:42:24+08:00 CT_IO_UTIL_LG IORM_CATEGORY OTHER 0 % 2012-09-13T15:42:24+08:00 CT_IO_UTIL_SM IORM_CATEGORY OTHER 2 % 2012-09-13T15:42:24+08:00 CT_IO_WT_LG IORM_CATEGORY OTHER 0 ms 2012-09-13T15:42:24+08:00 CT_IO_WT_LG_RQ IORM_CATEGORY OTHER 0.0 ms/request 2012-09-13T15:42:24+08:00 CT_IO_WT_SM IORM_CATEGORY OTHER 0 ms 2012-09-13T15:42:24+08:00 CT_IO_WT_SM_RQ IORM_CATEGORY OTHER 0.0 ms/request 2012-09-13T15:42:24+08:00 |
(3) IORM使用者组指标报告
CellCLI> LIST METRICCURRENT - WHERE name like 'CG_IO_.*' - and objectType = 'IORM_CONSUMER_GROUP' - and metricObjectName like 'SCRATCH.*' - and metricObjectName not like 'SCRATCH\._.*' - ATTRIBUTES name, objecttype, metricObjectName, metricValue, collectionTime |
注明:本文摘录自《深入理解Oracle Exadata》