My Oracle Support Banner

Recommended Patches for Exadata I/O Resource Manager (Doc ID 1340181.1)

Last updated on SEPTEMBER 24, 2021

Applies to:

Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Schema Service - Version N/A and later
Information in this document applies to any platform.

Details

This document applies to Oracle RDBMS Enterprise Edition, versions 11.1.0.7, 11.2.0.1, 11.2.0.2, 11.2.0.3, 11.2.0.4, 12.1.0.1 and 12.1.0.2.  Information in this document applies only to Exadata, since I/O Resource Manager is an Exadata-specific feature.  

I/O Resource Manager provides a mechanism for managing how multiple databases or Consumer Groups (workloads) share Exadata disks.

Below is a list of the most critical, known bugs for I/O Resource Manager. These bug fixes are recommended for all customers that are either evaluating or using I/O Resource Manager. If possible, we recommend customers to upgrade to the Exadata version that contains a fix for the issue or to use the suggested workaround. 

For other recommended bug fixes, monitoring scripts, and other tips for Resource Manager, see the Primary Note for Oracle Database Resource Manager MOS <Document 1339769.1>.

Bug Bug Description Affected Releases
14835705
PERFORMANCE DEGRADATION WHEN LIMIT PARAMETER IS USED WITH IORM
This bug causes additional throttling of disk I/Os when the limit parameter is specified in IORM plans even when the actual disk utilization is below the limit. Workaround is to create IORM plans without the limit parameter.
Cellsrv issue fixed in 11.2.3.2.2, 11.2.3.3.
One-off patch available for 11.2.3.2.0 and 11.2.3.2.1.
16694632
CELLS RUN OUT MEMORY WHEN IORM PLAN IS ENABLED
This issue is typically seen when lots of databases (over 100) are accessing cellsrv. The issue is also seen if a category IORM plan is set with lots of databases. 'IORM plansubheap' is the largest consumer of memory if you are hitting this bug. If you see this error when using a category IORM plan, the workaround is to disable the category IORM plan.
Cellsrv issue fixed in 11.2.3.3.
16371635
ORA-600 [KGKPLOALLOC1] IN CELLSRV
This bug is seen when RATIO intra-database plans are set on the database and sent to the cells. The workaround is to set EMPHASIS intra-database plans instead of RATIO plans. RATIO plans are created using dbms_resource_manager.create_plan by specifying the mgmt_mth to 'RATIO'. This is not a common method of creating resource plans. Most customers create resource plans by specifying the mgmt_mth to 'EMPHASIS'.
Cellsrv issue fixed in 11.2.3.3.
Workaround recommended for all prior releases.
10142882
PERFORMANCE DEGRADATION IF IORM STATUS IS CHANGED WITH ACTIVE WORKLOADS
This bug can cause disk I/Os to be dropped when IORM is being activated or deactivated (i.e. "alter iormplan active" or "alter iormplan inactive"). The workaround is to avoid activating or deactivating IORM while running any workloads.
Cell-side issue, fixed in 11.2.2.2.
Workaround recommended for version 11.2.2.1 and before.   
9924349 /
12580529
DBMV2: ORA 600 [RESPLAN:TRYADD_3] IN THE CELL SIDE WITH GE/DBFS WORKLOAD
This bug can cause cell server to fail with the error, ORA 600 [RESPLAN:TRYADD_3], leading to a cell restart. This bug only occurs when a resource plan with subplans is enabled, e.g. "default_plan" or "default_maintenance_plan". Both a database-side and cell-side fix are required. The workaround is to avoid using resource plans with subplans and to disable the "default_maintenance_plan" during the maintenance windows.  When the default maintenance plan is disabled in this manner, the automated maintenance tasks will continue to run.
To disable the default_maintenance_plan during the maintenance windows, use these SQL commands:
exec dbms_scheduler.set_attribute_null( -
name => 'MONDAY_WINDOW', -
attribute => 'RESOURCE_PLAN'); 
exec dbms_scheduler.set_attribute_null( -
name => 'TUESDAY_WINDOW', -
attribute => 'RESOURCE_PLAN'); 
exec dbms_scheduler.set_attribute_null( -
name => 'WEDNESDAY_WINDOW', -
attribute => 'RESOURCE_PLAN'); 
exec dbms_scheduler.set_attribute_null( -
name => 'THURSDAY_WINDOW', -
attribute => 'RESOURCE_PLAN'); 
exec dbms_scheduler.set_attribute_null( -
name => 'FRIDAY_WINDOW', -
attribute => 'RESOURCE_PLAN'); 
exec dbms_scheduler.set_attribute_null( -
name => 'SATURDAY_WINDOW', -
attribute => 'RESOURCE_PLAN'); 
exec dbms_scheduler.set_attribute_null( -
name => 'SUNDAY_WINDOW', -
attribute => 'RESOURCE_PLAN');
Database AND cell-side issue.
Database-side issue, fixed with 9924349 in 11.2.0.3.
Patch or workaround recommended for these database versions:
11.1.0.7
11.2.0.1 (fixed in BP12)
11.2.0.2 (fixed in BP3)
Cell-side issue, fixed with 12580529 in 11.2.2.4.
Workaround recommended for cell versions 11.2.2.3 and before.
12601518
CELLSRV HUNG AND RESTARTED DURING IORM SET & CLEAR PLAN
This bug occurs when the Exadata storage cell is (a) being used by a large RAC database or many databases and (b) their resource plans are being changed frequently.  This bug can cause the cell to hang.  Use the same workaround listed above for bug 12580529 to avoid changing resource plans to often.  Note that this bug can also occur when IORM is disabled. 
Cell-side issue, fixed in 11.2.2.4.
Workaround recommended for cell versions 11.2.2.3 and before.
11769664
STARTUP DATABASES,HIT ORA-600[DISKIOSCHED::GETDEFAULTINTERDBPLAN:NUMENTRY],[32]
This bug causes cell server to fail with the error above. It occurs when more than 32 databases share an Exadata storage cell. The workaround is to avoid using more than 32 databases on a single Exadata storage cell or setting the cell parameter "_cell_iorm_enable" to false on every Exadata storage cell. The side-effect of setting this parameter is that IORM cannot be enabled.
Cell-side issue, fixed in 11.2.2.3.
Workaround recommended for cell versions 11.2.2.2 and before.
11818623
ORA-600 [KGKPLOPICKNEXT1] IN CELLSRV SOFTWARE
This bug causes cell server to fail with the error above. It is an intermittent bug that may occur when a resource plan contains directives for more than 10 consumer groups or databases. The workaround is to limit database resource plans and IORM resource plans to 10 directives.
Cell-side issue, fixed in 11.2.2.3.
Workaround recommended for cell versions 11.2.2.2 and before.
12582331
CELLSRV CRASHES WITH ORA-07445: EXCEPTION ENCOUNTERED: CORE DUMP
This bug occurs when IORM is enabled, the objective is set to "auto", and the resource plan heavily prioritizes one consumer group or database. The workaround is to use single-level database and IORM resource plans or to not use the "auto" objective.
Cell-side issue, fixed in 11.2.2.4.
Workaround recommended for cell versions 11.2.2.2 and before.
14505249
IORM OBJECTIVE BALANCED AND LOW_LATENCY DON'T KICK IN FOR SOLO WORKLOAD MODE
If only one database or consumer group is issuing disk I/Os, then the "balanced" and "low latency" IORM objectives are not enforced.  This issue applies to databases that are issuing both latency-sensitive I/Os and throughput-oriented SQL operations (e.g. parallel queries or smart scans).  The workaround is to configure a consumer group for the latency-sensitive workload.
Cell-side issue.
Fixed in 11.2.3.3. Workaround recommended for older releases.
12557253
IORM INTERDATABASE PLAN UTILIZATION NOT BEING LIMITED WHEN HIGH WRITES
Utilization limits in an inter-database or intra-database plan do not sufficiently throttle disk writes.
Cell-side issue, fixed in 11.2.3.2.
14218148
IORM PLAN REPUSH BROKEN FOR MULTI-LEVEL PLANS
Multi-level database resource plans are not enabled on the cell after a cell restart.  The workaround is to explicitly reset the plan, using "alter system set resource_manager_plan".
Database issue for 11.2.0.2 BP15-16.
Fixed in 11.2.0.2 BP17, 11.2.0.3 BP9
12591543
INTRA-DB PLAN NOT PUSHED DOWN TO CELLS IF Primary Note for Oracle Database Resource Manager DISKMON RESTARTED
If the diskmon process on the Exadata server crashes followed by a cell restart, the database resource plans are not enabled on the cell.  The workaround is to explicitly reset the plan, using "alter system set resource_manager_plan".
Database issue for 11.2.0.2 and 11.2.0.3
Fixed in 11.2.0.4, 12.1.0.1.
One-off patch available for 11.2.0.3 BP20 and BP21.
17390553
IORM LIMIT PARAMETER CAUSES OVER THROTTLING FOR SMART SCAN READS
In 11.2.3.2.0 and 11.2.3.2.1, smart scans use deferred buffer allocation which results in the IORM 'limit' parameter over-throttling smart scan reads. The workaround is to enable I/O Resource Manager plans without the 'limit' parameter and simply use shares and allocations.
Cell-side issue impacting 11.2.3.2.0 and 11.2.3.2.1.
Fixed in 11.2.3.3.0.
19597895
ORA-00600 [DiskIOSched::UpdateIOCounts2:pendingioc] in CELLSRV SOFTWARE
This bug causes cellsrv to fail with the above ORA-600. This is an latent issue seen only on 11.2.3.3.1 when smart scans are issued to flash cache. It is recommended that customers running on 11.2.3.3.1 apply the one-off patch.
Cell-side issue impacting 11.2.3.3.1.
One-off available on top of 11.2.3.3.1
19211091
ORA-600 [DISKIOSCHED::GETCATINDEX:2], [4294967295] in CELLSRV SOFTWARE
This bug causes cellsrv to fail with the above ORA-600. This issue is seen when database resource manager plans contain sub-plans and OTHER_GROUPS is present in the sub-plan instead of the top plan. The workaround is to modify the plan and add OTHER_GROUPS to the top plan. The following SQL can be used to identify resource plans that can trigger this problem when enabled. This SQL should be run prior to an upgrade to 12.1.1.1.* so resource plans can be identifed and the workaround can be enforced prior to upgrade.
select unique name from v$rsrc_plan_history where name not in (select plan from dba_rsrc_plan_directives where plan in (select unique name from v$rsrc_plan_history) and GROUP_OR_SUBPLAN = 'OTHER_GROUPS');

Cell-side issue impacting 12.1.1.1.0 and 12.1.1.1.1.

Fixed in 12.1.2.1.0.

Actions

 

Contacts

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.