Oracle Identity Manager 11gR1 Tuning Considerations
Oracle Identity Manager (OIM) is a powerful tool for organizations to manage user accounts across many systems. Because it is such a key piece of the IT/IS puzzle, it becomes critical to produce high performance from within. While Oracle provides some baseline sizing recommendations and other resource tuning steps, some of the documentation is incomplete and at times - contradictory. This guide should help clear up confusion regarding OIM performance tuning.
Sizing:
One of the most important improvements you can make for performance is allocating enough resources on your OIM servers. Based on Oracle's OIM 11g "Sizing Guide," you need 6GB of memory (minimum) on each host in your OIM cluster, and ideally a Java "Heap" size of 2GB. On the database (DB) side, the baseline requirements are 6GB memory & 500GB of disk space allocated. In both cases, a single dual core CPU is "recommended."
From these baseline numbers, you can use the sizing guide as well as pre-production testing to determine the right numbers and configurations for your particular installation. Simply put - if you don't allocate at least these minimum resources, performance will suffer greatly, even in a small scale Development or Proof of Concept (POC) environment. Aside from proper sizing, the tuning recommendations can be broken down into two functional categories: 1) OIM Application Tuning and 2) Database Tuning.
(see "Don't Shortchange Your IAM Dev Environment")
Database Tuning:
Because OIM relies heavily on Oracle Database for most of its' functionality, you will often see huge performance gains just by tweaking initialization parameters and altering various settings. Every time a user is created or provisioned a "new" resource, there are dozens of operations taking place within tables of the functional database. This dependency means the user facing performance in OIM is directly related to the performance of the database itself. While it is always recommended to check the Oracle Database Tuning reports within the database, Oracle provides recommendations of which can be found at this location:
http://docs.oracle.com/cd/E14571_01/doc.1111/e14308/tuningfordb.htm.
They are listed below for quick reference. Always check the OEM documentation for the "latest and greatest" information.
| db_block_size | 8192 |
| memory_target | 6GB |
| sga_max_size | 10 GB |
| pga_aggregate_target | Minimum value is 2 GB |
| db_keep_cache_size | 800M |
| log_buffer | 15 MB |
| cursor_sharing | FORCE |
| open_cursors | 2000 |
| session_cached_cursors | 800 |
| query_rewrite_integrity | TRUSTED |
| db_file_multiblock_read_count | 16 |
| db_writer_processes | 2 |
| processes | Based on connection pool settings |
In addition to DB initialization parameters, Oracle also provide's recommendations which are designed to enhance "bulk operations" such as reconciliation tasks. While the complete document can be found at "Oracle Metalink note ID 1484808.1," we have found the below instructions are particularly helpful:
- Create a dedicated tablespace for the ORCHESTRATION LOB in the ORCHPROCESS table
- Enable efficient allocation of LOB chunks
- Remove USR and PCQ from the KEEP pool and use the default buffer pool instead
The full list of recommendations and steps can be found in the aforementioned Metalink note.
Application Tuning:
Oracle recommends enabling the OIM Caching feature to enhance system performance. With the Caching feature enabled, OIM is enabled to store various components in memory so it doesn't have to query the DB each time the information is needed. The performance gain here is quite obvious - fewer trips to the DB means less waiting.
Oracle provides a quick guide for enabling the cache:
http://docs.oracle.com/cd/E21764_01/doc.1111/e14308/tuningappcache.htm
Aside from caching, we also recommend eliminating any unused access policies or automatic group membership(s). This reduces the processing necessary from OIMs standpoint when creating and/or modifying objects (users, groups, etc...).
Finally, use the Orchestration Process Clean-up Task to regularly sanitize the ORCHPROCESS table. This table can grow & expand considerably-very quickly. This task helps clean-up entries that are no longer needed (the orchestrations are complete). Running this task once a day (during off-peak hours or during a maintenance window) is highly recommended.
Questions, comments or concerns? Feel free to reach out to us below or at IDMWORKS