12c Multi-Tenancy and Exadata IORM: An Ideal Cloud Based Resource Management
Download as PPTX, PDF5 likes1,655 views
The document presents an overview of multi-tenancy management and I/O resource management (IORM) within Oracle Exadata environments, focusing on the roles of Database Resource Manager (DBRM) and IORM. It highlights the importance of resource management in optimizing database performance, ensuring critical applications receive necessary resources, while also addressing the complexities of managing resources in a multi-tenant setup. Additionally, it discusses strategies for effective consolidation, resource allocation, and performance tuning in cloud computing using Exadata.
12c Multi-Tenancy and Exadata IORM: An Ideal Cloud Based Resource Management
- 1. 12c Multi-Tenancy and Exadata IORM Presented by: Fahd Mirza Chughtai
- 2. © 2012 Pythian About Fahd Mirza ([email protected]) Oracle DBA since 2001 Oracle ACE Oracle Press Co-Author of 12c Book Frequent Oracle Conference Speaker Write Weekly Log Buffer for Pythian Australian Certified Trainer Lives in Australia @fahdmirza (Twitter) Working at Pythian Interviewed by Oracle Magazine Oracle Blogger (fahdmirza.blogspot.com) since 2005
- 3. © 2012 Pythian Recognized Leader: • Global industry-leader in remote database administration services and consulting for Oracle, Oracle Applications, MySQL and SQL Server • Work with over 200 multinational companies such as Forbes.com, Fox Sports, Nordion and Western Union to help manage their complex IT deployments Expertise: • One of the world’s largest concentrations of dedicated, full-time DBA expertise. Employ 7 Oracle ACEs/ACE Directors • Hold 7 Specializations under Oracle Platinum Partner program, including Oracle Exadata, Oracle GoldenGate & Oracle RAC Global Reach & Scalability: • 24/7/365 global remote support for DBA and consulting, systems administration, special projects or emergency response Why Pythian
- 4. © 2012 Pythian • Cloud, Exadata, Consolidation • Resource Management in Container Database • Database Resource Manager • I/O Resource Manager • Methods of IORM • Monitoring IORM • Conclusion Agenda
- 5. © 2012 Pythian Cloud Computing and Exadata •Cloud clouds the complexity of IT. •Exadata clouds the complexity of Servers, storage, operating system, and RDBMS by integrating and optimizing them. •Consolidation is the cornerstone of Cloud computing. •Consolidation in cloud is standardization and limiting the number of distinct environment. •The business objectives achieved are greater agility, less risk, and lower costs. 5
- 6. © 2012 Pythian Cloud Computing and Exadata (cont'd) •Exadata is an engineered cloud in a box. •Standardized components of Exadata facilitate flexibility, consistency, security, and scalability. •Granularity increases because engineered systems like Exadata / Exalogic support a specific functions. •Exadata offers specialization because it performs only well defined duties and its really good at them. •Capacity Planning and performance tuning are more predictable. •Rapid system stand-up and production implementation are common because its already built. •Single point of contact vendor. 6
- 7. © 2012 Pythian Oracle Exadata Two Prime Reasons to Have Exadata: • Consolidation • Performance Caution: Exadata is not a place to dump and forget data! 7
- 8. © 2012 Pythian Oracle Exadata – A Powerful Elixir, but… • Not an Infinite Black box • Common Factors behind hype • Temptation to abuse Oracle Exadata • Requires proactive planning • Requires on-going resource management • You must harness the power 8
- 9. © 2012 Pythian Resource Management Solution • Complexity of balancing resources among databases • Resource Allocation Priorities • Enablers are: • DBRM for Database Node • IORM for Cell Node 9
- 10. © 2012 Pythian Who is the Unsung Hero? Hints: • Present for a long time, but used not that often • Implementation seems daunting • People can’t believe it really works • Mostly Ignored by DBAs, Devs, Mkt and Bloggers • But things are improving now steadily 10
- 11. © 2012 Pythian Yes, It’s DBRM • DBRM requires KISS • Horses and Donkeys are same without it • Should CEO’s query to determine his next bonus run with equal priority as my query to determine my next loan installment? • Without resource management, ad-hoc queries can make critical applications suffer 11
- 12. © 2012 Pythian DBRM adds Value! DBRM is for automating resource management • DBAs address resource management within the database itself • Even during heavy load periods, critical applications get resources 12
- 13. © 2012 Pythian DBRM in Multi-Tenant Database •DBRM is multi-tenant aware. •Enables to rank the PDBs according to the business importance •DBRM decides on the CDB level and on the PDB level. •On CDB level, DBRM manages the resources between multiple PDBs. •On PDB level, DBRM manages resources within that PDB among consumers. 13
- 14. © 2012 Pythian DBRM in Multi-Tenant Database (cont'd) •DBRM limits the resource usage of different sessions connected to a single PDB •DBRM limits the CPU usage of a particular PDB •DBRM limits the number of parallel execution servers that a particular PDB can use •DBRM enables you to monitor the resource usage of PDBs 14
- 15. © 2012 Pythian CDB Plan •A CDB plan allocates resources to the PDBs. •In a CDB plan, each directive references to a single PDB. •CDB plan directive controls allocation of CPU and parallel execution servers •CDB plan deals in share values and utilization limits to for precise control over resource allocation for PDBs. •When there is no CDB resource plan, the CDB uses the DEFAULT_CDB_PLAN that is supplied with Oracle Database. 15
- 16. © 2012 Pythian Shares and Utilization Limits (caps) •Shares are like counters. •More the shares a PDB has, the more resources it would enjoy. •The utilization limit for a PDB limits resource allocation to the PDB. •By default, share value for each PDB is 1, and utilization limit is 100. 16
- 17. © 2012 Pythian Shares •For example, we have 2 databases: prod and dev. •Prod database has 2 shares, whereas Dev database has 1 share. •It means that prod enjoys double the resources of Dev database. •In terms of CPU, Prod is guaranteed to have double the CPU of Dev. •In terms of Parallel Execution, Queued parallel queries from the Prod database will be selected to be executed two times more often than the Dev. 17
- 18. © 2012 Pythian Utilization Limits (caps) •Utilization limit restrains the system resource usage of a specific PDB. •Utilization limits for CPU and parallel execution servers can be specified. •The utilization_limit parameter limits CPU usage for a PDB use. The value ranges from 0 to 100%. •Parallel_server_limit is used to limit parallel servers. •If a PDB crosses the threshold of its utilization limit, the DBRM throttles it back in terms of CPU and queued statements. •For example, if utilization limit of Prod database is 100, then it has no utilization limit. •If utilization limit of Dev database is 50, then it can use 50 % of system resources. 18
- 19. © 2012 Pythian PDB Plan •A PDB resource plan determines how the resources allocated to a specific PDB are allocated to consumer groups within that PDB. •A PDB resource plan is similar to a resource plan for a non-CDB. •A PDB resource plan allocates resource among the consumer groups within a PDB. •A PDB resource plan cannot have subplans. •A PDB resource plan can have a maximum of eight consumer groups. 19
- 20. © 2012 Pythian Create CDB Plan for PDBs 20 exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); BEGIN DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN( plan => 'cdb_plan', comment => 'CDB plan for CDB'); END; BEGIN DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan => 'cdb_plan', pluggable_database => 'Prod', shares => 2, utilization_limit => 100, parallel_server_limit => 100); END;
- 21. © 2012 Pythian Create CDB Plan for PDBs (cont'd) 21 BEGIN DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE( plan=> 'cdb_plan', pluggable_database => 'Dev', shares=> 1, utilization_limit => 50, parallel_server_limit => 50); END; exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
- 22. © 2012 Pythian CDB Plan for PDBs •Use the DBA_CDB_RSRC_PLANS view to display all of the CDB resource plans defined in the CDB. •Use the DBA_CDB_RSRC_PLAN_DIRECTIVES view to display all of the directives. •The DEFAULT_CDB_PLAN is a default CDB plan that is supplied with Oracle Database. •To enable the plan, use: • ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'cdb_plan'; •Or set parameter RESOURCE_MANAGER_PLAN = 'cdb_plan' in initialization file. 22
- 23. © 2012 Pythian Components of DBRM in PDB Consumer Group • Sessions with similar resource requirements • Resources are allocated to consumer groups Plan Directive • Resource allocations are defined in plan directives • Consumer group is assigned to plan directive Plan • Plan directives are grouped to create a resource plan • Define the holistic allocation of resources to all sessions within the database 23
- 24. © 2012 Pythian DBRM: Consumer Groups DBRM is in-play in the database automatically • SYS and SYSTEM use consumer group SYS_GROUP • Other sessions by default use OTHERS_GROUP Manage resources on the fly by dynamically changing consumer groups of sessions A session may belong to many consumer groups • A consumer group can have many sessions assigned to it All sessions in a consumer group share the resources of that group 24
- 25. © 2012 Pythian DBRM: Consumer Group Mapping Rules When a resource plan is activated, DBRM examines key attributes of all sessions in the database and assigns them to consumer groups • Assigned by mapping rules that you define Example: a set of user accounts can be mapped to a consumer group based on user name or the login machine: 25 BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.ORACLE_USER, 'SCOTT', 'FINANCE'); DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.CLIENT_PROGRAM, ‘rep.exe', ‘RPTAPP'); END;
- 26. © 2012 Pythian DBRM: Mapping Rules Session Attributes Two Types: • login attributes: used to determine which consumer group the session should initially be assigned to • Common Login Attributes are : ORACLE_USER SERVICE_NAME CLIENT_MACHINE • Runtime Attribute: the runtime attribute commonly used is MODULE_NAME DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP • explicitly switch a user to another consumer group 26
- 27. © 2012 Pythian DBRM: Plan Directives DBRM allocates database resources to consumer groups through plan directives: • Consists of one consumer group and one or more management attributes and other parameters. • In directive, these parameters are listed in a key=value format • One-to-one relationship between a plan directive and a consumer group • Contains parameters for limiting CPU, logical I/O, physical I/O, degree of parallelism(PARALLEL_DEGREE_LIMIT_Pn), concurrently active sessions(ACTIVE_SESS_POOL_Pn), undo pool (undo generated in KB i.e. undo_pool), idle time for session before its terminated etc. 27
- 28. © 2012 Pythian DBRM: Sample Plan Directive CPU can be controlled through Mgmt_Pn attributes among consumer groups on basis of levels and percentages. 28 DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( PLAN => 'my_plan', GROUP_OR_SUBPLAN => 'REPORTING', COMMENT => 'DW Sessions', MGMT_P1 => 70, MAX_UTILIZATION_LIMIT => 90 );
- 29. © 2012 Pythian MGMT_Pn for CPU on levels 29
- 30. © 2012 Pythian DBRM I/O Limits •DBRM enables you to control I/O for runaway queries. •Both physical I/O and logical I/O can be limited. •If SWITCH_FOR_CALL directive is TRUE, then I/O requests are accumulated from start of call, otherwise from start of session. •For example: • SWITCH_IO_REQS: Limits number of physical I/O requests a session can execute. • SWITCH_IO_LOGICAL: Limits number of logical I/O requests a session can execute. 30
- 31. © 2012 Pythian DBRM I/O Limits (cont'd) •After I/O Threshold is reached, a session may: • Switch to another consumer group • switch_group => ‘<Group Name>' • Or its SQL may be cancelled • switch_group => ‘CANCEL_SQL' • Or the session it self may be killed • switch_group => 'KILL_SESSION’ • Or only session info is recorded in SQL Monitoring • switch_group => ‘LOG_ONLY’ • Column RM_LAST_ACTION in V$SQL_MONITOR specified recent action taken on this SQL by DBRM like KILL_SESSION, CANCEL_SQL, LOG_ONLY 31
- 32. © 2012 Pythian DBRM I/O Limits (cont'd) 32 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( PLAN => 'LIOPLAN', GROUP_OR_SUBPLAN => 'MYGROUP', COMMENT => 'Limit the Logical IO', MGMT_P1 => 75, SWITCH_GROUP => 'OTHER_GROUP', SWITCH_IO_LOGICAL => 100, SWITCH_FOR_CALL => TRUE); END; /
- 33. © 2012 Pythian DBRM: Resource Plan • A collection of plan directives that determine how database resources are allocated • A database may have many resource plans but only one will be active • Switching between resource plans provides required allocations for particular times of the day, week, or month 33
- 34. © 2012 Pythian DBRM: Pending Area •Pending area is a staging area for resource plan 34 BEGIN DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA(); <create, modify, delete your resource plan> DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA(); DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); END;
- 35. © 2012 Pythian DBRM Limitations Limited to managing resources within the database No awareness of storage tier by itself 35
- 36. © 2012 Pythian Enter IORM 36
- 37. © 2012 Pythian IORM • Oracle strengthens presence at storage tier • Directly Manage I/O at Cell level • I/O Request by databases through iDB to cellsrv • Using iDB, the database packs additional attributes in every I/O call to the storage cells • IORM manages I/O allowances configured in cell • IORM automatically manages IO from background processes like LGWR, control file, instance recovery37
- 38. © 2012 Pythian IORM (cont'd) Intelligent I/O requests from database to cellsrv • contains three important attributes: database name, consumer group, category • Priorities can be assigned at cell level with help of these attributes • Common categories across databases share same I/O priority 38
- 39. © 2012 Pythian IORM at Work 39 Organize IO Requests in queues Queues = db, category, group etc Only manages IO when needed IO queues serviced in FIFO when cell is idle In off-peak cell gives maximum throughput In rush-hour cell IO requests are scheduled and prioritize by IORM to disks. All IO processing goes through cellsrv
- 40. © 2012 Pythian40 IORM Architecture idb IORM CELL Node Cellsrv IO Queues w.r.t DB, CG, bkgrnd procs etc Cell Disk IO Queues DB Node
- 41. © 2012 Pythian IORM Workload Optimization IORM distinguishes between small and large I/O requests • Requests less than 128K in size are small (SM) requests • Requests 128K in size or greater are large (LG) requests • SM Requests are OLTP and LG Requests are DW for IORM 41
- 42. © 2012 Pythian DB Node Knows About Request Types 42 SQL> SELECT function_name FUNCTION, filetype_name , small_read_megabytes SM_READ_MB, LARGE_READ_MEGABYTES LG_READ_MB FROM v$iostat_function_detail; FUNCTION FILETYPE_NAME SM_READ_MB LG_READ_MB -------- ------------- ---------- ---------- RMAN Control File 2219 52974 RMAN Data File 128 16467663 RMAN Archive Log 2 5956878 RMAN Other 0 0 DBWR Control File 7 0 DBWR Data File 1 0 LGWR Control File 36 0 LGWR Log File 0 0
- 43. © 2012 Pythian IORM Optimization Objectives Optimization objective attribute determines optimization mode IORM will use when managing cell disk I/O queues Low_Latency • Favors OLTP, DW Suffers. • Use this setting for critical OLTP workloads that require extremely good disk latency. This setting provides the lowest possible latency by significantly limiting disk utilization. High_Throughput • Favors DW, OLTP Suffers. Use this setting for DW workload that require high throughput. Balanced • For Mixed Workloads. This setting balances low disk latency and high throughput. Auto • Leave it to IORM. IORM continuously and dynamically determines the optimization objective, based on the workloads observed Basic • Limit the maximum SMALL I/O(< 128K) Latency 43
- 44. © 2012 Pythian Setting Objective No objective set initially ( Before Storage Server software 11.2.3.2) Use Cellcli to set IORM Objective: 44 CellCLI> alter iormplan objective = low_latency IORMPLAN successfully altered CellCLI> list iormplan attributes objective low_latency CellCLI> list iormplan detail; name: mycell catPlan: dbPlan: objective: off status: inactive
- 45. © 2012 Pythian Setting Objective (cont'd) From Exadata Storage Software 11.2.3.2 and above, the default value is ‘basic’. ‘Basic’ objective only User-defined resource manager plans are not enforced in this mode. To enable IORM for user-defined resource manager plans, the objective must be set to "auto" (or any setting other than "basic"). 45
- 46. © 2012 Pythian IORM : Methods of IO Management I/O Management among Databases • Interdatabase IORM: based on database name I/O Management by Workload Type • IORM Categories: based on categories I/O Management For a Database • Intradatabase IORM: based on consumer groups 46
- 47. © 2012 Pythian IORM Interdatabase I/O Resource Management •Manages I/O priority among multiple databases by database name •Allocates I/O resources across multiple databases by means of an IORM plan configured on each storage cell • The IORM plan defines allocation priorities using I/O directives. • Each storage cell manages its own I/O queues based on the local IORM plan defined in the cell 47
- 48. © 2012 Pythian Configuring Inter-database IORM 48 CellCLI> ALTER IORMPLAN - dbPlan=( - (name=db1, level=1, allocation=60), - (name=db2, level=2, allocation=80), - (name=db3, level=3, allocation=100)) •The LEVEL attribute specifies the priority a database should be given relative to other databases in the plan •The ALLOCATION attribute determines the percentage of I/O a database will be given out of the total I/O available on its level
- 49. © 2012 Pythian IORM Category I/O Resource Management Categories provide I/O resource management among multiple databases • It’s like sharing priorities among databases • Categories represent collections of consumer groups across all databases. • We create categories in database, assign those categories to consumer groups 49
- 50. © 2012 Pythian Configuring Category I/O Resource Management Create category: • dbms_resource_manager.create_category(category => 'APPS_CATEGORY‘,comment => 'Category for Interactive Applications'); Assign Consumer Groups to Categories: • dbms_resource_manager.update_consumer_group(consumer_group => 'APPS‘,new_category => 'APPS_CATEGORY'); To check your resource-group-to-category mappings, query the DBA_RSRC_CONSUMER_GROUPS view Then create the Category IORM plan: • CellCLI> alter iormplan catplan=((name=APPS_CATEGORY, level=1, allocation=70), (name=BATCH_CATEGORY, level=1, allocation=30), (name=OTHER, level=2, allocation=100)) Now multiple databases with the above same categories will have50
- 51. © 2012 Pythian IORM Intradatabase I/O Resource Management •Configure DBRM, and it will be pushed to cell •Intradatabase I/O resource management is configured in each database using DBRM’s management attributes, MGMT_P1..8 etc •The database transmits a description of the plan, including MGMT_Pn directives, to all cells in the storage grid •IORM will generate an Intradatabase Plan and begin managing I/O priorities according to plan directives in database 51
- 52. © 2012 Pythian Monitoring IORM Monitoring and measuring essential for tweaking resource management I/O performance metrics are collected and maintained for IORM in the storage cell Every 60 seconds, cellsrv collects key performance metrics from the I/O queues and stores them in the METRICCURRENT object 52
- 53. © 2012 Pythian Monitoring IORM (cont'd) Metric history is maintained in METRICHISTORY object • METRICHISTORY retention is controlled by METRICHISTORYDAYS attribute of cell 53 CellCLI> list cell attributes name, metricHistoryDays mycell 7 CellCLI> alter cell metricHistoryDays='30' Cell mycell successfully altered
- 54. © 2012 Pythian Monitoring IORM (cont'd) In METRICCURRENT object, the NAME of the metric is: CT_IO_RQ_R_SM_SEC 54 METRIC OBJECT TYPE CL--•Cell CD--•Cell Disk GD-- Grid Disk FC--•Flash Cache DB--•IORM Database CG-- IORM Consumer Group CT-- IORM Category IO METRIC DETAILS IO_RQ-- # requests IO_BY-- # MB IO_TM-- IO latency IO_WT--•Wait Time R--•read operation W--write operation LG--•Large IO SM-- Small IO Rate _SEC: The metric is normalized to per second _RQ: The metric is normalized to per (IO) request
- 55. © 2012 Pythian Monitoring IORM (cont'd) 55 CellCLI> describe metriccurrent name alertState collectionTime metricObjectName metricType metricValue objectType CellCLI> LIST METRICCURRENT – WHERE name = 'CT_IO_RQ_LG' – AND objecttype = 'IORM_CATEGORY' – Name objectType metricObjectName metricValue -------------- -------------- ----------------- ------------------- CT_IO_RQ_LG IORM_CATEGORY OLTP_CATEGORY 56 IO requests CT_IO_RQ_LG IORM_CATEGORY REPORTING_CATEGORY 21,111 IO requests CT_IO_RQ_LG IORM_CATEGORY OTHER 1452 IO requests
- 56. © 2012 Pythian Simple Ways to Monitor Metrics EM 12c UI displays the metrics in nice graphs For CLI, Oracle provides metric_iorm.pl script • Doc ID 1337265.1 Script is valid for all version of storage cells. Script helps in determining: • IORM effect on the database and consumer groups. • Disk I/O latency • Flash Cache hit ratio (For OLTP workloads, It should be high) • Script can be run for specific time periods, relative time periods • Script can obtain data from single cell or from multiple cells. 56
- 57. © 2012 Pythian Simple Ways to Monitor Metrics (cont'd) 57 ./metric_iorm.pl "where ageInMinutes > 60 and ageInMinutes < 120" Database: exaDB Utilization: Small=1% Large=53% Flash Cache: IOPS=1830 Disk Throughput: MBPS=902 Small I/O's: IOPS=176 Avg qtime=0.0ms Large I/O's: IOPS=885 Avg qtime=0.0ms Consumer Group: exaDW_GROUP Utilization: Small=0% Large=48% Flash Cache: IOPS=248 Disk Throughput: MBPS=814 Small I/O's: IOPS=11.3 Avg qtime=0.0ms Large I/O's: IOPS=784 Avg qtime=0.0ms CELL METRICS SUMMARY Cell Total Utilization: Small=1% Large=53% Cell Total Flash Cache: IOPS=1830 Cell Total Disk Throughput: MBPS=860.971 Cell Avg small read latency: 49.28 ms Cell Avg small write latency: 37.91 ms Cell Avg large read latency: 59.46 ms Cell Avg large write latency: 9.86 ms -- Utilization show how busy disks are --IOPS are I/O rate per second -- disk latency is in msec --avg qtime is time waited by IORM to schedule I/O
- 58. © 2012 Pythian Conclusion Maturing IT industry has become very cost conscious • Resource management is a key DBA skill Oracle offers tools that leverage resources at the database and cell level • Risk: they can be confusing and get out of control Million dollar tip: keep it very simple and straight forward • Implement a simple, single-level Resource Plan, and grow from there (most systems don't need to though) Don't be afraid of it. Use it!
- 59. © 2012 Pythian Thank you and Q&A http://www.pythian.com/news/ http://www.facebook.com/pages/The-Pythian-Group/163902527671 @pythian http://www.linkedin.com/company/pythian 1-877-PYTHIAN [email protected] To contact us… To follow us… @pythianjobs WE ARE HIRING !!!
Editor's Notes
- #4: We are a managed service AND a solution provider of elite database and System Administration skills in Oracle, MySQL and SQL Server
- #6: Cloud computing is a datacenter configuration and provisioning strategy. Cloud computing offers flexibility (the ability to move resources around), reliability (continuous operation), and elasticity (the ability to increase or decrease resources for a given application as needed)
- #19: Parallel_server-limit works with the parallel_server_target. Parallel_server_target is system wide parameter. PARALLEL_SERVERS_TARGET specifies the number of parallel server processes allowed to run parallel statements before statement queuing will be used. For example, if the PARALLEL_SERVERS_TARGET initialization parameter is set to 200 and the parallel_server_limit parameter for a PDB is set to 10%, then utilization limit for the PDB is 20 parallel execution servers (200 X .10).
- #24: http://docs.oracle.com/cd/E16655_01/server.121/e17636/dbrm.htm#ADMIN12652
- #29: MGMT_MTH: Resource allocation method for specifying how much CPU each consumer group or subplan gets. 'EMPHASIS', the default method, is for single-level or multilevel plans that use percentages to specify how CPU is distributed among consumer groups. 'RATIO' is for single-level plans that use ratios to specify how CPU is distributed.
- #30: There are two methods for CPU allocation. Default is ‘Emphasis’ which deals in percentages for the levels, whereas other one is ‘RATIO’, which is for plans for only one level.
- #32: Specifies the consumer group to which a session is switched if switch criteria are met. If the group name is CANCEL_SQL, then the current call is canceled when switch criteria are met. If the group name is CANCEL_SQL, then the SWITCH_FOR_CALL parameter is always set to TRUE, overriding the user-specified setting. If the group name is KILL_SESSION, then the session is killed when switch criteria are met. If the group name is LOG_ONLY, then information about the session is recorded in real-time SQL monitoring, but no specific action is taken for the session. If NULL, then the session is not switched and no additional logging is performed. The default is NULL. An error is returned if this parameter is set to NULL and any other switch parameter is set to non-NULL.
- #33: he following PL/SQL block creates a resource plan directive for the OLTP group that temporarily switches any session in that group to the LOW_GROUP consumer group if the session exceeds 100 logical I/O requests. The session is returned to its original group after the offending top call is complete.
- #41: First, the database sends IO requests to the Exadata storage cells. These requests are bundled in an iDB message and include metadata indicating their consumer group and optionally, resource category assigned to the IO request. The requests are sent to different CELLSRV IO queues, based on the order in which they were sent to the storage cell. The IO requests are then passed to from the CELLSRV IO queue to IORM; at which point any resource plans are also evaluated. IORM then evaluates the IO requests from each of the "input" consumer groups and databases, validates their priority against the configured resource plans, and schedules the IO into the cell disk queues.
- #44: To disable IORM, use the following CellCLI command to return IORM to the "basic" objective. Note that "alter iormplan inactive" is deprecated in versions 11.2.3.2 and above because IORM is minimally always in "basic" mode. Running "alter iormplan inactive" will result in the error message "IORMPLAN status cannot be set to inactive".
- #49: IORM only manages I/O for physical disks. I/O requests for objects in the flash cache or on flash-based grid disks are not managed by IORM.
- #52: It ties up the CPU allocations to the IO allocations. You don’t assign anything at the IORM level at cell. You just activate the IORM plan at storage cell.
- #57: These metrics can be used to answer the following, common questions: Which database or consumer group is utilizing the disk the most? Use the disk utilization metrics to answer this question. You can also use the disk IOPS metrics. However, the total number of IOPS that can be sustained by the disk is extremely dependent on the ratio of reads vs writes, the location of the I/Os within the disk, and the ratio of small vs large I/Os. Therefore, we recommend using the disk utilization metrics. Am I getting good latencies for my OLTP database or consumer group? The I/O latency, as seen by the database, is determined by the flash cache hit rate, the disk latency, and the IORM wait time. OLTP I/Os are small, so you should focus on the disk latency for small reads and writes. You can use IORM to improve the disk latency by giving high resource allocations to the OLTP databases and consumer groups. If necessary, you can also use the "low latency" objective. You can also decrease the IORM wait time by giving high resource allocations to the critical databases and consumer groups. What is the flash cache hit rate for my database or consumer group? For OLTP databases and consumer groups, you should expect the flash cache to be used for a significant number of I/Os. Since the latency of flash cache I/Os is very low, the I/O response time, as seen by the database, can be optimized by improving the flash cache hit rate for critical workloads. How much is I/O Resource Manager affecting my database or consumer group? If IORM is enabled, then IORM may delay issuing an I/O when the disks are under heavy load or when a database or consumer group has reached its I/O utilization limit, if any. IORM may also delay issuing large I/Os when it is optimizing for low latencies for OLTP workloads. These delays are reflected in the "average queue time" metrics. You can decrease the delays for critical databases and consumer groups by increasing their resource allocation.
- #58: These metrics can be used to answer the following, common questions: Which database or consumer group is utilizing the disk the most? Use the disk utilization metrics to answer this question. You can also use the disk IOPS metrics. However, the total number of IOPS that can be sustained by the disk is extremely dependent on the ratio of reads vs writes, the location of the I/Os within the disk, and the ratio of small vs large I/Os. Therefore, we recommend using the disk utilization metrics. Am I getting good latencies for my OLTP database or consumer group? The I/O latency, as seen by the database, is determined by the flash cache hit rate, the disk latency, and the IORM wait time. OLTP I/Os are small, so you should focus on the disk latency for small reads and writes. You can use IORM to improve the disk latency by giving high resource allocations to the OLTP databases and consumer groups. If necessary, you can also use the "low latency" objective. You can also decrease the IORM wait time by giving high resource allocations to the critical databases and consumer groups. What is the flash cache hit rate for my database or consumer group? For OLTP databases and consumer groups, you should expect the flash cache to be used for a significant number of I/Os. Since the latency of flash cache I/Os is very low, the I/O response time, as seen by the database, can be optimized by improving the flash cache hit rate for critical workloads. How much is I/O Resource Manager affecting my database or consumer group? If IORM is enabled, then IORM may delay issuing an I/O when the disks are under heavy load or when a database or consumer group has reached its I/O utilization limit, if any. IORM may also delay issuing large I/Os when it is optimizing for low latencies for OLTP workloads. These delays are reflected in the "average queue time" metrics. You can decrease the delays for critical databases and consumer groups by increasing their resource allocation.
- #59: In most cases, a single-level I/O resource plan is sufficient. As they do with DBRM, multi-level IORM resource plans increase the complexity of measuring the effectiveness of your allocation scheme.