1. Tuning Performance Guide
  2. Oracle Identity and Access Management
  3. Oracle Identity Governance Performance Tuning

13 Oracle Identity Governance Performance Tuning

Note:

As with any enterprise class business application, there is no simple procedure for tuning that works for all systems. The tuning sections in this chapter provide (in some cases) sample configurations and outline the principles for tuning Oracle Identity Governance. Consider your own use case scenarios to determine which settings are appropriate.

This chapter provides guidelines for tuning and sizing specific to Oracle Identity Governance (OIG). It contains these topics:

Parent topic: Oracle Identity and Access Management

About Oracle Identity Governance

Oracle Identity Governance (OIG) provides operational and business efficiency through centralized administration and complete automation of identity and user provisioning events across the enterprise, as well as extranet applications.

For more information on using Oracle Identity Governance, see the Administering Oracle Identity Governance.

Parent topic: Oracle Identity Governance Performance Tuning

Monitoring Oracle Identity Governance Performance

To identify performance bottlenecks, you can monitor real-time performance metrics for Oracle Identity Governance. For more information on how to monitor your Oracle Fusion Middleware components, see Monitoring.

For Oracle Identity Governance it is recommended that you perform the following at regular intervals:

  • Monitor real-time performance by using a performance-monitoring tool such as Oracle Enterprise Manager console or Automatic Workload Repository (AWR) in Oracle Database 11g.

    Note:

    You can use Oracle Enterprise Manager 11g Fusion Middleware Control to monitor Oracle Identity Governance. To do so:

    1. Under Identity Management, select Oracle Identity Governance to go to the home page. On the Home page, you can monitor Oracle Identity Governance.

    2. From the Oracle Identity Governance menu, select Performance to view performance metrics.

  • Collect routine statistics and report by using Oracle Database Enterprise Manager (EM), which is available in Oracle Database as a standard offering.

    • Routine Statistics Gathering

      Routine statistics gathering can be taken care by the 'Automated Maintenance Tasks', which is available in the following navigation path in Oracle Database:

      Oracle EM, the Server tab, Query Optimizer, Manage Optimizer Statistics, the Automated Maintenance Tasks link

    • Reporting requirements of statistics through Oracle Database 11g EM

      To report on the state of the currently gathered statistics, EM provides a reporting interface in the following navigation path:

      Oracle EM, the Server tab, Query Optimizer, Manage Optimizer Statistics, the Object Statistics link

      This interface can be used for the reporting purpose for All Objects (of the Schema or even the Object of choice), which have Stale, Missing, or Locked states or are already analyzed.

  • Collect complete schema statistics upon implementation of Oracle Identity Governance.

    Update OIG schema and its dependent schemas (*_MDS, *_SOAINFRA, *_OPSS and *_ORASDPM). You must consider complete schema or table statistics on mass data change events such as bulkload of users or accounts, import of a new connector, a huge reconciliation run from a new target system, or use of an archival utility. You should collect statistics regularly for OIG and also OIG dependent schemas *_MDS, *_SOAINFRA, *_OPSS and *_ORASDPM.

    This helps the CBO determine an efficient query execution plan that is based on the current state of data. The following is a sample SQL command to collect database statistics on a regular basis:

    See Also:

    Gathering routine statistics and reporting can be done by performing the automated maintenance tasks available in Oracle Database 11g. See Oracle Database Performance Tuning Guide 11g Release 1 (11.1) for details. 

    DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> schema_owner,
Exec dbms_stats.gather_schema_stats(OWNNAME=> 'OIG_OIG',ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE,degree =>DBMS_STATS.DEFAULT_DEGREE,options=>'GATHER AUTO', no_invalidate =>FALSE,cascade=>TRUE);

  • Look for relevant recommendations provided in advisory sections in the Automatic Database Diagnostic Monitor (ADDM) or Automatic Workload Repository (AWR) report, and adjust the instance configuration parameters according to the recommended settings. This is specially required after importing a new connector and completing a round of reconciliation from a new target system so that you can identify the need of any new indexes according to your matching rules.

Parent topic: Oracle Identity Governance Performance Tuning

Basic Tuning Considerations

Depending on your Oracle Identity Governance usage and performance issues, you may consider tuning the following basic parameters. See Top Performance Areas for additional tuning considerations.

Parent topic: Oracle Identity Governance Performance Tuning

Tuning and Managing Application Cache

Oracle Identity Governance allows caching of metadata, which reduces DB activities. This results in reduced network load and improved performance.

By default, caching for most of the configurations are disabled (set to false) so that the configuration changes are reflected immediately without having to restart the application servers in the development environments.

The following sections provide some recommended cache values for tuning Oracle Identity Governance:

Parent topic: Basic Tuning Considerations

Tuning Oracle Identity Governance Cache

Caching is configured in the /db/oim-config.xml configuration file, which is located in MDS where Oracle Identity Governance stores the configuration. You can use Oracle Enterprise Manager (EM) to turn on caching, or export the oim-config.xml to make changes and then import it back to turn on caching.

Oracle recommends the following settings for the production environments for optimal and better performance. Using EM, go to System Mbean > Application Defined Mbeans > oracle.iam > server:OIM_server1 > Application: OIM > XMLConfig > Config > XMLConfig.CacheConfig > Cache > XMLConfig.CacheConfig.CacheCategoryConfig, and do the following:

  • Set the caching to true for all the components except the following two sections: 

    threadLocalCacheEnabled="false"

  • For non-clustered installation, set clustered="false". For clustered installation, set clustered="true".

Note:

Changing this value gets saved into the MDS database schema used by the Oracle Identity Governance servers. Therefore, change only once for multi-node/clustered installations.

Enabling Cache Categories User_Org_Membership_And_Chain and ObjectDefinition

It is recommended that you enable the cache categories described in Table 13-1, based on your Oracle Identity Governance version. Note that you do not need to enable these, if your Oracle Identity Governance version is not same as given in "Applicable Release" column in the following table:

Table 13-1 Instructions to Enable Cache Category

Cache Category Name Applicable Release Instructions

User_Org_Membership_And_Chain

Oracle Identity Governance 12c Release (12.2.1.3.0)

You can enable this cache category using Oracle Enterprise Manager (EM) or by editing the oim-config.xml configuration file. To do this, complete the following steps:

Using EM

  1. Log in to EM.

  2. Go to mbean XMLConfig.CacheConfig under oracle.iam, and set the value of attribute Enabled to true, if not already set to true. Mbean's Object name is "oracle.iam:name=Cache,type=XMLConfig.CacheConfig,XMLConfig=Config,Application=OIM,ApplicationVersion=12.2.1.3.0".

  3. Create a new cache category using mbean's createCacheCategoryConfig operation with the following parameters:

    enabled=true

    expirationTime=3600

    name=User_Org_Membership_And_Chain

Using oim-config.xml File

  1. Go to $OIM_HOME/bin.

  2. Set the environment variable OIM_ORACLE_HOME appropriately.

  3. Open the weblogic.properties file, and set the following properties in order to export the metadata file: 

    wls_servername=OIM_server1
application_name=OIMAppMetadata
metadata_to_loc=<TMP_DIRECTORY>
metadata_files=/db/oim-config.xml

  4. Run the following command script to export the /db/oim-config.xml metadata file:

    ./weblogicExportMetadata.sh

    When prompted, enter the WebLogic credentials and the JNDI URL.

  5. Open the $TMP_DIRECTORY/db/oim-config.xml file, and add the following in the cacheCategoriesConfig tag: 

    <cacheCategoryConfig enabled="true" expirationTime="14400"
name="User_Org_Membership_And_Chain"/>

  6. Open the weblogic.properties file, and set the following properties in order to import the modified metadata file: 

    wls_servername=OIM_server1
application_name=OIMAppMetadata
metadata_from_loc=<TMP_DIRECTORY>

  7. Run the following command to import the modified /db/oim-config.xml metadata file into MDS:

    ./weblogicImportMetadata.sh

    When prompted, enter the WebLogic credentials and the JNDI URL.

ObjectDefinition

Oracle Identity Governance 12c Release (12.2.1.3.0)

You can enable this cache category using Oracle Enterprise Manager (EM). To do so, complete the following steps:

  1. Log in to EM.

  2. Go to mbean XMLConfig.CacheConfig under oracle.iam, and set the value of attribute Enabled to true for the cache category ObjectDefinition.

Note:

For more information on configuration change using Enterprise Manager, see Using Enterprise Manager for Managing Oracle Identity Governance Configuration in Administering Oracle Identity Governance.

Purging the Cache

If you want to purge the cache, use the PurgeCache utility in the OIM_HOME/server/bin/ directory. This utility purges all elements in the cache.

Note:

  • Purging is required when caching is enabled and if you make any system configuration changes. It is not required if caching is disabled.

  • Before running the PurgeCache utility, navigate to the OIM_HOME/server/bin/ directory.

Before running the PurgeCache utility, you must run the DOMAIN_HOME/bin/setDomainEnv.sh script.

To use the PurgeCache utility, run PurgeCache.bat CATEGORY_NAME on Microsoft Windows or PurgeCache.sh CATEGORY_NAME on UNIX. The CATEGORY_NAME argument represents the name of the category that must be purged. For example, the following commands purge all FormDefinition entries from a system and its clusters: 

PurgeCache.bat FormDefinition
PurgeCache.sh FormDefinition

To purge all Oracle Identity Governance categories, pass a value of "All" to the PurgeCache utility. It is recommended to clear all the categories.

Tuning the Application Server for Oracle Identity Governance

This section describes how to tune Oracle WebLogic Server for Oracle Identity Governance to improve performance. For additional Oracle WebLogic Server performance tuning information, see Tuning Performance of Oracle WebLogic Server.

Note:

  • All tuning parameter suggestions and values in this section are for reference purposes only. Values should be modified based on your requirement, application usage patterns, loads, and hardware specifications.

  • Changing any of the settings may require you to restart the server.

Parent topic: Basic Tuning Considerations

Tuning JVM Memory Settings for Oracle Identity Governance

These settings should be used in addition to those described in Tuning Java Virtual Machines (JVMs).

It is recommended to increase the heap and permgen memory for production environments as in Table 13-2 and monitor the memory usage pattern. Based on the usage, you can choose to increase or decrease the memory settings.

Table 13-2 JVM Parameters to be set for Tuning JVM Memory Settings

JVM Parameter HotSpot JVM

Min. Heap Size (Xms)

4GB

Max Heap Size (Xmx)

8GB

MetaspaceSize (-XX:MetaspaceSize

500m

MaxMetaspaceSize (-XX:MaxMetaspaceSize)

1GB

To change the JVM memory setting:

  1. Use DOMAIN_HOME/bin/setStartupEnv.sh (Unix) or set OIMDomainEnv.cmd (Windows). If not, continue to use DOMAIN_HOME/bin/setSOADomainEnv.sh (Unix) or setSOADomainEnv.cmd (Windows) to change the heap size settings.
  2. Change the value of DEFAULT_MEM_ARGS and PORT_MEM_ARGS from the default value and save.
  3. Restart the OIM Server.

Note:

For a clustered or multi-node installation, repeat the above steps on all the install locations.

Tuning the JDBC Connection Pool for Oracle Identity Governance

Oracle Identity Governance uses the ApplicationDB, oimOperationsDB and oimJMSStoreDS data sources deployed on the Oracle WebLogic Server. You may have to increase the connection pool size for each data source, based on your requirements

To increase the capacity of the JDBC connection pools:

  1. Open the WebLogic Server Administration Console.
  2. Click Services, JDBC, Data Sources, Data Source Name, and then click the Connection Pool tab.
  3. Adjust the Initial Capacity and Maximum Capacity based on requirement.
  4. Set the Inactive Connection Timeout parameter to 300.
  5. Set Seconds to Trust an Idle Pool Connection to 30.
  6. Save and activate the changes.

    Note:

    Ensure that any increase in number of connections on the application server connection pools are compensated by database configuration changes. You might have to increase the MAX SESSIONS settings on Oracle Database.

Tuning OIG-specific Work Manager Properties

This section describes some tuning options for OIG-specific Work Managers. By default, Work Managers are not optimized for production. Tuning them can help performance by prioritizing processes into a configuration more tailored to your use case.

While Oracle can recommend a few MaxThreadsConstraint values, as shown in Table 13-3, you can determine the optimal value for your system configurations using calculations also given in Table 13-3.

To calculate the optimal Maximum Threads Constraint for each Work Manager in your particular installation, you should first consult your DBA and ascertain the following values:

  • Number of database CPU available for the OIG database

  • Number of nodes in your OIG cluster

  • Number of threads used in OIG Access Policy Scheduled task "Evaluate User Policy."

Once you know these values, calculate the following values:

  1. Multiply the number of database CPU available for the OIG database by 8. The resulting number is the total number of database connections.

  2. Divide the number of database connections by the number of nodes in your OIG cluster.

  3. For the following equations in Table 13-3, replace the following variables with the values you have calculated:

    • d = the total number of database connections

    • n = the number of nodes in your OIG cluster

    • t = the number of threads used in OIG Access Policy Scheduled task "Evaluate User Policy"

Table 13-3 Recommended Max Thread Constraints for OIG Work Managers

Work Managers Role Recommended Value for Max Thread Constraint

OIMMDBWorkManager

This Work Manager applies to most OIG Message Driven Beans (MDB) and limits the number of concurrent threads/MDB-processing JMS messages for all offline activities except audit..

Round(1/3[([d-t]/n)-10])

OIMAuditWorkManager

This Work Manager applies to audit MDBs. It limits the number of concurrent threads/MDB processing audit-related JMS messages.

5

OIMWorkManager

This Work Manager applies to all OIG Enterprise JavaBeans (EJB), which implement underlying APIs. It also limits the number of concurrent threads processing incoming API calls.

Round(2/3[([d-t]/n)-10])

OIMUIWorkManager

This Work Manager limits the number of threads serving requests to and from the user interface.

10 (based on UI Concurrency)

To change the MaxThreadsConstraint value, do the following:

  1. Login to WebLogic Administrative Console.

  2. Navigate to Environment > Work Managers.

  3. Select a Worker Manager and identify the Maximum Thread Constraint.

  4. Change the count per your requirement.

For more information on how to tune Work Managers, see "Using Work Managers to Optimize Scheduled Work" in Administering Server Environments for Oracle WebLogic Server.

Disabling the Reloading of Adapters and Plug-in Configuration

By default, reloading of adapters and plug-in configuration are enabled for ease of development. These should be disabled in the production environment. To do so:

  1. Export the /db/oim-config.xml file from MDS as described in Exporting and Importing Configuration Files in Administering Oracle Identity Governance.
  2. In the oim-config.xml file, replace the following:
    <ADPClassLoaderConfig adapterReloadingEnabled="true" loadingStyle="ParentFirst" reloadInterval="15" reloadingEnabled="true">

    With:

    <ADPClassLoaderConfig adapterReloadingEnabled="false" loadingStyle="ParentFirst" reloadInterval="15" reloadingEnabled="false">
  3. Replace the following:
    <storeConfig reloadingEnabled="true" reloadingInterval="20"/>

    With:

    <storeConfig reloadingEnabled="false" reloadingInterval="20"/>
  4. Save the oim-config.xml file and import it back to MDS.
Changing the Number of Open File Descriptors for UNIX (Optional)

WebLogic limits the number of open file descriptors in the WEBLOGIC_HOME/common/bin/commEnv.sh script to 1024. In some cases, if there is a large number of concurrent users, WebLogic may throw the "TOO MANY OPEN FILES" exception. If you receive this error, then consider increasing the limit beyond 1024 in the script. Ensure that the operating system is able to handle the increase in the number of open files. To set the number of open file descriptors, see Setting the Open File Limit and Number of Processes Settings on UNIX Systems in System Requirements and Specifications.

Tuning the JVM Garbage Collection for Solaris Sparc T3 or T4

To tune the JVM garbage collection for Solaris Sparc T3 or T4:

  1. In a text editor, open the setSOADomainEnv.sh or setSOADomainEnv.cmd file in the DOMAIN_HOME/bin/ directory.
  2. Set the value of USER_MEM_ARGS similar to the following:

    Note:

    The values shown for USER_MEM_ARGS are examples. You can change the values based on your requirement.

    USER_MEM_ARGS="-Xms3048m -Xmx3048m -Xmn1648m -Xss256k -XX:PermSize=384m -XX:MaxPermSize=384m"
  3. Set the value of JAVA_OPTIONS similar to the following:

    Note:

    The values shown for JAVA_OPTIONS are examples. You can change the values based on your requirement.

    JAVA_OPTIONS="-Xnoclassgc -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90
 -XX:PermSize=350m -XX:MaxPermSize=350m -XX:+AggressiveOpts
 -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -XX:+PrintGCDetails
 -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps  -XX:ReservedCodeCacheSize=64m
 -XX:CICompilerCount=8 -XX:+AlwaysPreTouch -XX:+PrintReferenceGC
 -XX:+ParallelRefProcEnabled -XX:-UseAdaptiveSizePolicy
 -XX:+PrintAdaptiveSizePolicy -XX:+DisableExplicitGC"
  4. Save and close the file.
Increasing the LTPA Timeout Interval

If certification creation begins failing, you should increase the LTPA timeout interval. The default value is 120. The recommended value is 720 minutes.

To increase the LTPA timeout interval, do the following:

  1. Log into the WebSphere application server administrative console.

  2. Navigate to Security, then Global Security.

  3. Select LTPA.

  4. Edit the LTPA timeout parameter to be 720 minutes.

  5. Apply changes.

Tuning Database Parameters for Oracle Identity Governance

This section describes one sample configuration and outlines the principles for tuning Oracle Database for Oracle Identity Governance. For general database tuning information, see Tuning Database Parameters.

Oracle Identity Governance has many configuration options. The best way to identify bottlenecks and optimize performance is to monitor key database performance indicators in your production environment and adjust the configuration accordingly. Review the monitoring tasks described in Monitoring Oracle Identity Governance Performance and then use the guidelines in this section to help you choose the initial baseline database configuration.

Note:

It is important that you maintain the baseline database tuning parameters when working with Oracle Identity Governance. See the Oracle Database Performance Tuning Guide 11g Release 1 (11.1) for information on setting Oracle Database instance parameters.

Parent topic: Basic Tuning Considerations

Sample Instance Configuration Parameters

Table 13-4 provides information on some important performance-related database initialization parameters.

SGA,PGA size are limited by the underlying operating system restrictions on the maximum available memory in some platforms. See Support Note: Oracle Database Server and the Operating System Memory Limitations [ID 269495.1].

Note:

For the Database Instance Parameters listed in Table 13-4, following memory management approach should be used based on the Oracle Database versions.

Using Automatic Shared Memory Management (ASMM) available in Oracle Database 10g onward: Here, the SGA components can be managed by specifying the SGA_TARGET and SGA_MAX_SIZE parameters. PGA is managed separately through PGA_AGGREGATE_TARGET.

You should set the processes parameter to accommodate the following connection pool requirements and few extra connections for external programs:

  • Connection pool size of XA datasource configured in Application Server

  • Connection pool size for non-XA datasource configured in Application Server

  • Direct database connection pool size configured in xlconfig.xml

Table 13-4 Sample Configuration Parameters

Parameter Recommended Initial Settings for Oracle Database

db_keep_cache_size

800M

cursor_sharing

FORCE

open_cursors

800

session_cached_cursors

800

query_rewrite_integrity

TRUSTED

query_rewrite_enabled

TRUE

processes

Based on connection pool settings

MAX_DISPATCHERS

0

MAX_SHARED_SERVERS

0

distributed_lock_timeout

1400

filesystemio_options

SETALL

sga_target

6GB

pga_aggregate_target

2GB
Physical Data Placement

The basic installation of Oracle Identity Governance uses three physical tablespaces to store the OIG database objects:

  • Data Tablespace to store the data of tables, their indexes and other objects.

  • LOB Tablespace to store OIG Orchestration LOB data.

  • Archival Tablespace to store OOTB Archival Tables of the OIG Entities catering to the Real-time Purge feature.

Tip:

To minimize disk space consumption, Oracle recommends the following:

During the initial startup phase of the deployment, Oracle Identity Governance tablespace is expected to grow at the rate 20G for every hundred thousand users reconciled into Oracle Identity Governance. LOB tablespace grows at around 30% of the size of main Oracle Identity Governance tablespace for the same users. Depending on the usage of orchestration in Oracle Identity Governance, which affects the LOB tablespace growth, the LOB tablespace can grow at a rate of 60% to 100% of the main tablespace in scenarios where orchestration is widely used.

Database administrators must monitor the exact growth rate in the real system for efficient disk space management.

For better performance, create multiple locally managed tablespaces and store each category of database object in a dedicated tablespace. This storage optimization helps efficient data access. The tables that are frequently accessed and have potential growth are highlighted in the following sections. Oracle recommends that you place these tables in their own dedicated tablespace(s).

Note that the tables highlighted in the following sections generally grow bigger and are accessed frequently in a typical Oracle Identity Governance deployment. In addition, you can use performance metrics to identify tables that are accessed frequently (hot tables). To reduce I/O contention, move hot tables to dedicated tablespaces.

Note:

Oracle Identity Governance offers archival and purge solution in both Real-time online mode and Command Line mode to contain the data growth in most of these tables. See "Using the Archival Utilities" in Using the Archival and Purge Utilities for Controlling Data Growth for more information.

Tasks Tables

Oracle Identity Governance stores provisioning and approval task details in the following tables. These tables have lot of potential to grow big overtime. It is recommended to group these in one or more dedicated tablespaces.

  • OSI

  • OSH

  • SCH

Parent topic: Physical Data Placement

Reconciliation Tables

The reconciliation schema of Oracle Identity Governance has both static and dynamic tables. The following is a list of static tables. The dynamic tables can be identified by querying the RECON_TABLE_NAME column in the RECON_TABLES table.

  • RECON_ACCOUNT_OLDSTATE

  • RECON_BATCHES

  • RECON_CHILD_MATCH

  • RECON_EVENTS

  • RECON_EVENT_ASSIGNMENT

  • RECON_EXCEPTIONS

  • RECON_HISTORY

  • RECON_JOBS

  • RECON_TABLES

  • RECON_UGP_OLDSTATE

  • RECON_USER_OLDSTATE

  • RECON_ACCOUNT_MATCH

  • RECON_ORG_MATCH

  • RECON_ROLE_HIERARCHY_MATCH

  • RECON_ROLE_MATCH

  • RECON_ROLE_MEMBER_MATCH

  • RECON_USER_MATCH

  • RA_LDAPUSER

  • RA_MLS_LDAPUSER

  • RA_LDAPROLE

  • RA_MLS_LDAPROLE

  • RA_LDAPROLEMEMBERSHIP

  • RA_LDAPROLEHIERARCHY

If your environment generates a large amount of reconciliation data, then move these tables to one or more dedicated tablespace(s).

Parent topic: Physical Data Placement

OIG Orchestration LOB Tables

You can use the Archival and Purge Utilities to control data growth in Orchestration tables. For more information, see Using the Archival and Purge Utilities for Controlling Data Growth in Administering Oracle Identity Governance.

Parent topic: Physical Data Placement

Audit Tables

Oracle Identity Governance audits the transactions based on the audit level setting. Most of the audit levels are likely to increase data growth significantly. Oracle recommends storing audit tables in their own tablespace. Oracle Identity Governance audit tables are of two categories. Following are the tables that store audit data in XML format. In this list, UPA table is especially expected to grow big and it is important to place it in a dedicated tablespace.

  • UPA

  • GPA

The user profile audit data is stored in the following flat structured tables. These tables are used by Oracle Identity Governance historical reports for compliance reporting. It is recommended to store these tables and their indexes in a dedicated tablespace.

  • UPA_FIELDS

  • UPA_GRP_MEMBERSHIP

  • UPA_RESOURCE

  • UPA_USR

  • UPA_UD_FORMS

  • UPA_UD_FORMFIELDS

You can use the Archival and Purge Utilities to control data growth in Audit (UPA) table. For more information, see Using the Archival and Purge Utilities for Controlling Data Growth in Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Governance.

Parent topic: Physical Data Placement

Redo-Log Files

Depending on the reconciliation processes configured in Oracle Identity Governance, the volume of database transactions and commits during a reconciliation run can be high. Oracle recommends that you use multiple redo-log files. The total allocated redo-log space should be 1 GB to 2 GB.

Oracle recommends:

  1. Use at least three redo log groups with redo log members.

  2. Start with an initial size of 1GB for each redo log member and continue to monitor redo logs for contention or frequent log switches. 

  3. The multiplexing and the exact number of members and disk space for each member can be considered in accordance with the planning for failure. 

  4. Adjust the size or add more redo log files based on your findings.

Parent topic: Physical Data Placement

Keep Pool Changes

By default, Oracle Identity Governance assigns frequently referenced small tables to be cached in the database by using a keep pool buffer. See db_keep_cache_size in Table 13-4. If your installation contains more than 50,000 users, then Oracle recommends that you use the default database buffer for USR and PCQ tables instead of the keep pool buffer. You can use the following commands to put these tables in default buffer pool. 

ALTER TABLE USR STORAGE(buffer_pool default);
ALTER TABLE PCQ STORAGE(buffer_pool default);

Parent topic: Physical Data Placement

Tuning Oracle Internet Directory

To ensure that the Oracle Identity Manager is performing at the optimal level, it is important to tune the Oracle Internet Directory as described in Oracle Internet Directory Performance Tuning.

Tuning Oracle Internet Directory

To ensure that the Oracle Identity Governance is performing at the optimal level, it is important to tune the Oracle Internet Directory as described in Oracle Internet Directory Performance Tuning.

Parent topic: Basic Tuning Considerations

Tuning Application Module (AM) for User Interface

Application Module tuning is a critical setting which affects the UI performance. You must ensure that the recommended application module settings for Oracle Identity Governance are set in the setDomainEnv.sh file. These settings are already set out-of-box (OOB) in later releases of Oracle Identity Governance 11g Release 2 (11.1.2). To add the recommended application module settings for Oracle Identity Governance, do the following:

  1. Open the file $DOMAIN_HOME/bin/setDomainEnv.sh in a text editor.
  2. In the setDomainEnv.sh file, find the following lines:
    JAVA_OPTIONS="${JAVA_OPTIONS}"
export JAVA_OPTIONS
  3. Change the first line to the following:
    JAVA_OPTIONS="-Djbo.ampool.doampooling=true -Djbo.ampool.minavailablesize=1 
-Djbo.ampool.maxavailablesize=120 -Djbo.recyclethreshold=60 
-Djbo.ampool.timetolive=-1 -Djbo.load.components.lazily=true 
-Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1 
-Djbo.connectfailover=false -Djbo.max.cursors=5 
-Doracle.jdbc.implicitStatementCacheSize=5 
-Doracle.jdbc.maxCachedBufferSize=19 ${JAVA_OPTIONS}"

    Note:

    These recommended settings assume 100 concurrent users per node. If your number of concurrent users is different, use the following formula to change Djbo.ampool.maxavailablesize:

    Djbo.ampool.maxavailablesize = # of concurrent users + 20%

  4. Save the setDomainEnv.sh file.
  5. Restart the WebLogic Administration Server and the Oracle Identity Governance Managed Servers.

For more information on AM Pool tunings, see Configuring Application Module Pool Sizing.

Parent topic: Basic Tuning Considerations

JMS Tuning

It is recommended to change the defaults (-1) of Message Buffer Size and Messages Maximumproperties. Set the Message Buffer Size to 1 GB (1073741824 bytes) and Messages Maximum1000000 respectively.

Go to WebLogic Server Administration Console to change these properties.

  • Message Buffer Size:

    Services > Messaging > JMS Servers > UMSJMSServer_auto_1.

  • Messages Maximum:

    Services > Messaging > JMS Servers > UMSJMSServer_auto_1 > Thresholds and Quota.

Parent topic: Basic Tuning Considerations

Advanced Tuning Considerations

This section provides advanced tuning recommendations which may or may not apply to your environment. Review the following recommendations to determine if the changes would improve your Oracle Identity Governance performance.

Parent topic: Oracle Identity Governance Performance Tuning

Reconciliation Tuning

Three distinct process stages or functional modules come into play during the end-to-end reconciliation flow. The following are the three functional modules or stages that need to be optimized separately, but in relation to each other, to achieve complete performance optimization:

  • The Target System And The Connector

    The Connector fetches data from the target system, and invokes reconciliation create event APIs to create events and event data in reconciliation staging tables in the OIG database schema.

  • OIG Reconciliation Engine

    The OIG reconciliation engine extracts data from the staging tables and reconciles into OIG. The process includes verification, matching of data, and taking actions based on the rules. The engine uses database's bulk collection mechanism to do all of the above processing in bulk.

  • Oracle Identity Governance Post-processing for Reconciliation

    Post-processing stage kicks in after reconciliation engine has completed processing of incoming data from the target. During this stage, OIG kernel orchestrations get triggered to execute event-handlers to do things like default password generation as per policy, role assignment, resource provisioning, audit processing and so on.

This section includes the following topics:

Parent topic: Advanced Tuning Considerations

Target System And Connector Tuning

This section describes the tuning that needs to be applied on your target systems as well as Oracle Identity Governance Connectors.

Oracle Internet Directory

During a reconciliation run, all changes in the target system records are reconciled into Oracle Identity Governance. Depending on the number of records to be reconciled, this process may require a large amount of time. In addition, if the connection breaks during reconciliation, then the process would take longer to complete. It is recommended that "paged reconciliation" is configured to optimize performance.

To configure paged reconciliation, you must specify a value for the PageSize attribute of the user reconciliation scheduled task. The default value of 100 for PageSize suits for most of the scenarios.

Note:

OID LDAP Server (the target system in this case) v10.1.4 or later versions support the paged reconciliation related LDAP operations.

SAP

It is recommended that you use a reconciliation batch size of 100.

Active Directory (11.1.1.5.0 and 11.1.1.6.0 Connector)

  • Performance improvement patch

    • If you are using Active Directory 11.1.1.5.0, make sure that you apply patch # 15916848. You can download the patch from My Oracle Support. For patching instructions, refer to the Readme that is available with the patch.

    • If you are using Active Directory 11.1.1.6.0, download the patch # 15916848 from My Oracle Support. Import only the ReconAttributeMap.xml that is provided as part of the patch, using the deployment manager. You can ignore ActiveDirectory.Connector.dll provided in the patch, as it is updated in the 11.1.1.6.0 version itself. For patching instructions, refer to the Readme that is available with the patch.

  • Configuring the reconciliation engine to skip the ignore event API

    The default behavior would be to first check to create a recon event or to ignore it for each of the user records returned by the connector. This process involves comparing the values of all the attributes of the user coming in from the connector against the values stored in the OIG database. To ignore this, open the lookup definition Lookup.Configuration.ActiveDirectory and add below entry.

    • Code Key: Ignore Event Disabled

    • Decode: true

    Note:

    You must evaluate the pros and cons of disabling the ignore event API call before you make the above changes.

  • Batching

    If batching is used in the AD connector, then the result set needs to be sorted. Therefore, batching can be used when number of records to be reconciled is less than 10000. The recommended batch size is 500.

  • Paging

    • When number of records to be reconciled is more than 10000, use the Page Size Configuration property present in Lookup.Configuration.ActiveDirectory and Lookup.Configuration.ActiveDirectory.Trusted.

    • If paging is configured to be used, then you must make sure that no value is specified for the scheduled task parameters - Batch Size, Batch Start, Number of Batches, Sort By, and Sort Direction.

    • Paging splits the entire result set of a query into smaller subsets called, appropriately enough, pages. In general, it is recommended to set this value to the maximum page size for simple searches. By setting the page size to the maximum value, you can minimize the network round trips necessary to retrieve each page, which tends to be more expensive operation for simple searches. If you specify a PageSize greater than the MaxPageSize of the target system, the Active Directory server ignores it and uses the MaxPageSize instead. No exception is generated in this case. In some cases, you might need to specify a smaller page size to avoid timeouts or overtaxing the server. Some queries are especially expensive. Therefore, limiting the number of results in a single page can help avoid this. For the Active Directory Connector, use the default value 1000 for the best performance.

  • Filters

    It is recommended to use Filters and provide the value for the Search Base, if a specific set of records is to be retrieved from the target. Filter provided in the scheduled task is converted into LDAP query. The filters help narrow down the search, making the searching and processing of the data quicker. For more information about the filters, refer to the Active Directory Connector Documentation.

  • For the reconciliation in the forest topology, you can use connector for reconciling the data from the complete forest (via Global Catalog Server) or you can use the connector for reconciling the data from the specific domain or domain controller. It is recommended to use the second approach whenever the data from the specific data center is to be reconciled, instead of using first option with search base.

    For example:

    Assume that there are 10 data centers in the Active Directory forest namely DC1, DC2, … , DC10. To reconcile data from an organization (tempOrg) which is present on DC2, you have use one of the following approaches:

    1. Use Global Catalog and provide the DN of the organization in the Search Base.

    2. Use DC2 and provide the DN of the organization in the Search Base.

    It is recommended to use the second approach for better performance.

Parent topic: Reconciliation Tuning

Database Indexes For Recon Matching Rules

Reconciliation uses matching algorithm to find if the user/account/role/organization for which the change is requested, already exists in OIG. The matching algorithm compares the data in set of columns in OIG with the data in target staging table columns. The columns that contain the matching rules are defined in the reconciliation profile and they are defined at run-time. To improve the performance of the matching operation, there must be correct indexes created on the matching rule columns.

To illustrate the recommended method of identifying the appropriate indexes, a sample Active Directory (AD) user profile present in the Meta Data Store (MDS) repository is taken as an example. This example covers the following:

Note:

Starting OIG 11g Release 2 (11.1.2.1.0), the indexes are automatically created in some cases where possible. It is still recommended to follow the below procedure and make sure that all of the indexes required for reconciliation matching rule are in place.

Selecting Indexes For Trusted Source Reconciliation

To select indexes based on the matching rule criteria in trusted source reconciliation, you must complete the following steps:

  1. Open the Active Directory user profile file in a text editor. You can open Active Directory user profile using Validate Recon Profile test present in the diagnostic dashboard, or by using Validate Recon Profile MBean present in EM.

  2. Search for ownerMatchingRuleWhereClause or matchingRule for all entities:

    ownerMatchingRuleWhereClause = (((UPPER(USR.USR_LOGIN)=UPPER(RA_ADUSER7.RECON_USERID5A729570)) OR (UPPER(USR.USR_UDF_OBGUID)=UPPER(RA_ADUSER7.RECON_OBJECTGUID))))

  3. After identifying the columns constituting the matching rule in the profile, create the indexes accordingly.

    For example, following indexes are needed for matching rule in the above example.

    Table 13-5 Table Names and Columns to be Indexed

    Table Name Column to be Indexed

    USR

    UPPER(USR_LOGIN)

    USR

    UPPER(USR.USR_UDF_OBGUID)

    RA_ADUSER7

    UPPER(RECON_USERID5A729570)

    RA_ADUSER7

    UPPER(RA_ADUSER7.RECON_OBJECTGUID)

    Note:

    • It is important that the indexes are created along with functions like UPPER, SUBSTR in the matching rule. In Table 13-5, UPPER is the function used on all columns.

    • Some of the columns and functions might have been indexed already. In Table 13-5, USR table should already have function-based index on UPPER(USR_LOGIN).

Selecting Indexes For Target Source Reconciliation

To select indexes based on the matching rule criteria in target resource reconciliation, you must complete the following steps:

  1. Open the Active Directory user profile file in a text editor. You can open Active Directory user profile using Validate Recon Profile test present in the diagnostic dashboard, or by using Validate Recon profile MBean present in EM.

  2. Search for account search tag <matchingruleWhereClause>:

    <matchingruleWhereClause>((UD_ADUSER.UD_ADUSER_OBJECTGUID=RA_ADUSER7.RECON_OBJECTGUID))</matchingruleWhereClause>

  3. After identifying the columns constituting the matching rule in the profile, create the indexes accordingly.

    For example, following indexes are needed for matching rule in the above example.

    Table 13-6 Table Names and Columns to be Indexed

    Table Name Column to be Indexed

    UD_ADUSER

    UD_ADUSER_OBJECTGUID

    RA_ADUSER7

    RECON_OBJECTGUID

    Note:

    • It is important that the indexes are created along with functions like UPPER, SUBSTR in the matching rule.

    • Some of the columns and functions might have been indexed already.

Selecting Indexes For Target Source Reconciliation With Multi-Valued Data

To select indexes based on the matching rule criteria in target resource reconciliation with multi-valued data, you must complete the following steps:

  1. Open the Active Directory user profile file in a text editor. You can open Active Directory user profile using Validate Recon Profile test present in the diagnostic dashboard, or by using Validate Recon profile MBean present in EM.

  2. For entitlements, search for the <matchingruleWhereClause> tag under <childreconeventdata>:

    <matchingruleWhereClause>((UD_ADUSRC.UD_ADUSRC_GROUPNAME=RA_UD_ADUSRC.RECON_MEMBEROF))</matchingruleWhereClause>

  3. After identifying the columns constituting the matching rule in the profile, create the indexes accordingly. For example, following indexes are needed for matching rule in the above example.

    Table 13-7 Table Names and Columns to be Indexed

    Table Name Column to be Indexed

    UD_ADUSRC

    UD_ADUSRC_GROUPNAME

    RA_UD_ADUSRC

    RECON_MEMBEROF

    Note:

    • It is important that the indexes are created along with functions like UPPER, SUBSTR in the matching rule.

    • Some of the columns and functions might have been indexed already.

Parent topic: Reconciliation Tuning

Oracle Identity Governance Post-processing for Reconciliation

Table 13-8 lists some of the important out-of-the-box event handlers that are invoked during post-processing of reconciliation.

Table 13-8 Event Handlers and Their Descriptions

Event Handler Description

AccountReconAuditHandler

Responsible for Auditing account/target reconciliation changes

ReconScheduledTaskAccountHandler

Trigger workflows associated with account/target reconciliation

ReconScheduledTaskUserHandler

Trigger workflows associated with trusted reconciliation

ReconUserDisplayNameHandler

Generates custom display name for trusted reconciliation

ReconUserLoginHandler

Generates custom login during for reconciliation

ReconUserPasswordHandler

Generates custom passwords for trusted reconciliation

UserCreateLdapPostProcessHandler

Creates user in LDAP if LDAP synchronization is enabled

UserUpdateLdapPostProcessHandler

Updates user in LDAP if LDAP synchronization is enabled

You can find the rest of out-of-the-box and custom event handlers in DMS metric page of WebLogic Application Server. Use the following URL to go to the DMS metric page:

http://<servername>:<port>/dms

In this URL, port refers to the WebLogic Administration Server port. To log in, you must use the WebLogic admin credentials.

After you log into the DMS metric page, click on OIG_EventHandler to see the list of event handlers and their processing time metrics. You can use these metrics to identify event handlers that may need to be optimized.

Parent topic: Reconciliation Tuning

Tuning LDAP Synchronization

Tuning performance in Oracle Identity Governance involves the following:

Parent topic: Advanced Tuning Considerations

Increasing the Max Connection Pool for Oracle Identity Governance

To increase the max connection pool for Oracle Identity Governance:

  1. Login to Oracle Identity System Administration.
  2. On the left pane, under Configuration, click IT Resource. The Manage IT Resource page is displayed in a new window.
  3. From the IT Resource Type list, select Directory Server, and then click Search.
  4. For the Directory Server IT resource, click Edit. The Edit IT Resource Details and Parameters page is displayed.
  5. Change the value of the following configuration parameters to 500:

    • Initial pool size: 500

    • Minimum pool size: 500

    • Maximum pool size: 500

  6. Click Update.
Increasing the LDAP Synchronization Batch Size

To increase the LDAP synchronization batch size, set the batch size of the following LDAP synchronization reconciliation scheduled jobs to 1000:

  • LDAP User Create and Update Reconciliation

  • LDAP Role Create and Update Reconciliation

  • LDAP Role Hierarchy Reconciliation

  • LDAP Role Membership Reconciliation

Setting Configuration Parameters in OVD

When LDAP synchronization with OVD configured for OID is enabled in Oracle Identity Governance, the configuration parameters in OVD, as listed in Table 13-9, must be set:

Table 13-9 Configuration Parameters in OVD

Name Parameter Value

OVD general

Listeners - LDAP Endpoint

50

-

Listeners - LDAP SSL Endpoint

50

User Adapter

Max Pool Size

500

-

Operation Timeout

1500000

-

Max Pool Wait

1000

Changelog adapter

Max Pool Size

500

-

Operation Timeout

1500000
Setting Configuration Parameters in OID

When LDAP synchronization with OVD/OID is enabled in Oracle Identity Governance, the configuration parameters in OID, as listed in Table 13-10, must be set:

Table 13-10 Configuration Parameters in OID

Name Parameter Value

Max Number of DB Connections

orclmaxcc

10

Number of Processes

orclserverprocs

2 - 4

Skip Referral Process

orclskiprefinsql

1

LDAP Connection Timeout

orclldapconntimeout

60

Enable MatchDN Processing

orclmatchdnenabled

0

Enable Entry Cache

orclcacheenabled

0

To modify the attributes in Table 13-10, use the following syntax: 

ldapmodify -h HOST_NAME -p PORT_NUMBER -D cn=orcladmin -w PASSWORD -v <<EOF
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
Setting Configuration Parameters in Identity Virtualization Library (libOVD)

When LDAP synchronization with Identity Virtualization Library (libOVD) configured for OID is enabled in Oracle Identity Governance, the configuration parameters in Identity Virtualization Library (libOVD), as listed in Table 13-11, must be set:

Note:

You can manage the Identity Virtualization Library (libOVD) tuning parameter configuration by using the WLST command.

Table 13-11 Configuration Parameters in Identity Virtualization Library (libOVD)

Name Parameter Value

User Adapter

Max Pool Size

500

User Adapter

Operation Timeout

1500000

User Adapter

Max Pool Wait

1000

Changelog adapter

Max Pool Size

500

Changelog adapter

Operation Timeout

1500000

See Also:

Enabling Access Logging in Identity Virtualization Library (libOVD) in the Oracle Fusion Middleware Integration Guide for Oracle Identity Management for information about enabling access logging in Identity Virtualization Library (libOVD) to capture all requests and responses flowing through Identity Virtualization Library (libOVD), which can be very useful in triaging performance issues.

Parent topic: Increasing the Max Connection Pool for Oracle Identity Governance

Setting Configuration Parameters in WebLogic Server and JDBC

For information about setting configuration parameters in Oracle WebLogic Server and JDBC, see Tuning the Application Server for Oracle Identity Governance.