11 Tuning the SOA Infrastructure

You can tune the SOA Infrastructure to optimize its performance in managing composites and their lifecycle, service engines, and binding components in Oracle WebLogic Server, using Work Managers and other tuning parameters.

• About the SOA Infrastructure
  
• Tuning SOA Work Managers
  
• Tuning SOA Infrastructure Parameters
  
• Using Advanced Tuning Options
  
• Advanced Tuning for Work Managers
  

11.1 About the SOA Infrastructure

The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their lifecycle, service engines, and binding components. For more information, see Introduction to the SOA Infrastructure Application in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

The information presented here does not cover any diagnostic tools or methodologies that are needed for a holistic approach, but addresses isolated tuning options for isolated symptoms. For information on monitoring the SOA Infrastructure performance to pinpoint problem areas, see Monitoring the SOA Infrastructure in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

11.2 Tuning SOA Work Managers

You can perform a few simple checks and configurations to take advantage of Work Managers.

Beginning with Oracle SOA Suite 12c (12.2.1), Work Managers handle most SOA-related work threads. For more details on how Work Managers manage threads and self-tune, see Understanding Work Managers in Administering Server Environments for Oracle WebLogic Server.

Before attempting to configure Work Managers, you should have a good understanding of your environment and be able to quantify the following:

• Volume of incoming requests that you need processed

• Internal processing requirements including any SLA expectations for transactions

• An understanding of the processes you have that do not use Work Managers, such as the Event Delivery Network and most adapters

Based on the information collected above, you can take advantage of the Work Managers' self-tuning feature.

• Configuring Database Connections with the SOADataSource Property
  
• Configuring Work Managers with the SOAMaxThreadsConfig Attribute
  

11.2.1 Configuring Database Connections with the SOADataSource Property

The SOADataSource property determines the total number of concurrent database connections that are available for your SOA processes. Because SOA processes use the database for most of their activities, this is a very important setting and can create a bottleneck if not appropriately configured.

To tune this setting, it is important to understand your database resources and consult your DBA.

To tune SOADataSource, do the following:

1. Log in to the Oracle WebLogic Server Administration Console.
2. Select Services from the left-hand menu and then choose DataSources.
3. On the DataSource configuration page, select SOADataSource.
4. Select the Connection Pool tab and scroll down to find the Maximum Capacity attribute.

The default for the Maximum Capacity attribute is 50. For most practical use cases, you should set this value to 300 to increase the size of the entire SOADataSource connection pool.

Description of the illustration GUID-8960E762-EDD6-489B-B16B-FDC290FD047C-default.gif

The SOADataSource setting is leveraged by the SOAMaxThreadConfig configuration explained in Configuring Work Managers with the SOAMaxThreadsConfig Attribute. SOADataSource defines the total number of connections available to all Work Managers, while the SOAMaxThreadConfig attribute defines what percentage of those connections will be available to certain categories of Work Managers.

11.2.2 Configuring Work Managers with the SOAMaxThreadsConfig Attribute

SOA composites are associated with a group of Work Managers that handles various components and functional areas. The SOAMaxThreadsConfig attribute determines the number of threads allowed for different groups of SOA Work Managers in a domain.

The number of threads allotted to handle incoming requests, internal processes, and other SOA processes are defined as percentages of the SOADataSource property explained in Configuring Database Connections with the SOADataSource Property. The default percentage values and categories of the SOAMaxThreadsConfig attribute are listed in Table 11-1.

Table 11-1 Thread distributions for Work Managers determined by SOAMaxThreadsConfig

Group	Description
incomingRequestsPercentage Default: 20%	This parameter determines the percentage of threads that your system allocates to Work Managers that process incoming client requests.
internalBufferPercentage Default: 30%	This parameter determines the percentage of threads distributed to other SOA functions, such as EDN and adapters.
internalProcessingPercentage Default: 50%	This parameter determines the percentage of threads that your system allocates to Work Managers for internal processes.

This attribute is defined at the domain level and will apply to all the Work Managers under that domain. You can set this attribute using the SoaInfraConfig MBean in the Fusion Middleware Control MBean Browser.

To access the attribute:

1. Log in to Fusion Middleware Control.
2. Select System MBean Browser from the WebLogic Domain menu.
3. In the System MBean Browser folder structure, navigate through the following folders: Application Defined MBeans --> oracle.as.soainfra.config --> Server: AdminServerName --> SoaInfraConfig --> soa-infra
4. When you click on soa-infra, its attributes will be listed in the main pane on the right. Look for the SOAMaxThreadsConfig attribute and click on it. You should then see the parameters and values listed in Table 11-1.

   Click Apply when you are ready to make your changes.

Remember that the values you are adjusting on this screen are percentages, not the discrete number of threads. You should ascertain the total number of threads available to you by checking the value of the SOADataSource property, which is described in Configuring Database Connections with the SOADataSource Property.

In a sample scenario where SOADataSource is set to 50 connections and you kept the default SOAMaxThreadConfig percentages listed in Table 11-1, you would have the following thread allocations:

• 20% of 50 = 10 threads to process incoming request

• 30% of 50 = 15 threads for processes not using work managers

• 50% of 50 = 25 threads to process internal processes

11.3 Tuning SOA Infrastructure Parameters

Table 11-2 describes the optimal settings for parameters with the greatest impact on SOA Infrastructure performance.

Table 11-2 Essential SOA Infrastructure Tuning

Parameter	Problem	Tuning Recommendation	Trade-offs
AuditLevel Default: Production	High database CPU Contentions causing increased processing times in applications	To prevent possible performance degradation, maintain the lowest audit level possible or retain the default of Production. Avoid setting the audit level to Development whenever possible. This parameter can be set in the Enterprise Manager. You can find the Audit Level parameter page on the SOA Infrastructure Common Properties page. To find this page: Toggle the SOA folder in your left-hand Target Navigation. Right-click on the soa-infra (soa_server) you want to tune. Select SOA Administration --> Common Properties For more information about this parameter, see Configuring Oracle SOA Suite and Oracle BPM Suite Profiles in Administering Oracle SOA Suite and Oracle Business Process Management Suite.	Decreasing the audit level will cause the system to generate less audit data. Diagnosing performance issues and general troubleshooting may be more difficult.
Audit Purge Policy Default: Everyday Midnight and purges records older than 7 days	Exponential growth in database size If configured at peak hours, purging can take resources from other processes	Ensure auto purge is enabled Perform purges more often Set the auto purge to kick off at a time when there is less resource contention from other processes For information on finding the Auto Purge page in the Oracle Enterprise Manager Fusion MIddleware Control, see Deleting Large Numbers of Instances with Oracle Enterprise Manager Fusion Middleware Control in Administering Oracle SOA Suite and Oracle Business Process Management Suite.	Disabling this feature will make maintaining on-going database growth more time-consuming.

11.4 Using Advanced Tuning Options

You can optional configure additional performance tuning settings for SOA. These options are presented here in no specific order. Before changing any of these properties, you should have a holistic knowledge of your environment, SOA processes, and non-SOA processes.

It is important to understand that any advanced performance optimization should be a customized approach for individual scenarios, settings, environments, and expectations. A customized approach requires detailed capturing of diagnostic information to pinpoint and isolate bottlenecks and areas that need optimization.

For information on monitoring the SOA Infrastructure performance to pinpoint problem areas, see Monitoring the SOA Infrastructure in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

• Using Composite Lazy Loading
  
• Changing Modularity Profiles
  
• Tuning Your Database for SOA Processes
  
• Tuning Event Delivery Network Parameters
  
• Tuning the WebLogic Server
  

11.4.1 Using Composite Lazy Loading

Composite lazy loading is a new feature in 12c. It improves server startup time when there is a large number of composites deployed.

At server startup, composites are loaded minimally, meaning that they will only create in-memory java models and MBeans. Any initializing tasks, such as loading components and resources used by composite, namely WSLD and Schema file, are loaded later at first-request time when they are needed.

This greatly improves server startup times and staggers the composite startup times for when they receive requests, reducing overhead from rarely used or retired composites.

Composite lazy loading is helpful for:

• Scenarios requiring speedy disaster recovery times during a server failure

• Customers with a huge number of composites that use large WSDLS or schema files

Composite lazy loading is enabled by default and can be configured at the domain level and at the composite levels.

• Configuring Composite Lazy Loading for the Domain Level
  
• Configuring Composite Lazy Loading at the Component Level
  

11.4.1.1 Configuring Composite Lazy Loading for the Domain Level

Composite lazy loading is enabled by default at the domain level. This setting can be disabled from System MBean Browser in Enterprise Manager for Fusion Middleware Control. Changes to this setting will take affect when the server restarts.

To change the setting for lazy loading feature for the domain level:

1. After logging into Enterprise Manager, right-click on the domain you want to tune from the list of the WebLogic domains in the Target Navigation browser.
2. Select System MBean Browser from the drop-down menu.
3. In the System MBean Browser folder structure, navigate through the following folders: Application Defined MBeans --> oracle.as.soainfra.config --> Server: AdminServerName --> SoaInfraConfig --> soa-infra
4. When you click on soa-infra, its attributes will be listed in the main pane on the right. Look for the CompositeLazyLoading attribute and click on it.
5. On the CompositeLazyLoading page, you can set the value to true to enable it or false to disable it. Click Apply when you are ready to make your changes.

11.4.1.2 Configuring Composite Lazy Loading at the Component Level

By default, composites will inherit the lazy loading setting from the domain level. If there is a use case where you would like to control this behavior at specific composite level, then this can be configured in the composite.xml, which is a file generated when you create a new SOA Suite composite application.

You can find composite.xml in the home folder of the application you want to edit. You can also edit composite.xml by accessing it in JDeveloper. For more information on composite.xml, see What Happens When You Create a SOA Application and Project in Developing SOA Applications with Oracle SOA Suite.

At the beginning of the composite.xml of the application that you want to edit, you will need to add the new property lazyLoading="false" to override the default behavior at the domain level. Then redeploy the composite.

Below is a sample code snippet:

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 12.2.1.0.0 at [8/7/13 4:14 PM]. -->
<composite name="ValidatePayment"
           revision="1.0"
           label="2013-08-07_16-14-11_843"
           mode="active"
           state="on"
           lazyLoading="false"
           xmlns="http://xmlns.oracle.com/sca/1.0"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
……….
……….
</composite>

11.4.2 Changing Modularity Profiles

Modularity is another 12c feature that helps improve your memory footprint and server startup times. Some profile options are limited to only components and features that are used by your selected composites. The modularity profile you select determines what components will be loaded in memory.

12c has out-of-box profiles that can be changed after completing installation. By default, new 12c customers will have SOA_FOUNDATION as their install profile. Existing customers upgrading to 12c will have SOA_CLASSIC as their install profile by default.

Table 11-3 shows the modularity profiles in the increasing order of memory footprint size.

Table 11-3 Modularity Profiles

Profile	Components
BPEL-ONLY	BPEL Components + SOA Common Infrastructure + Partial Adapter set
ORCHESTRATION	BPEL-Only + HWF + Partial Adapter set
SOA FOUNDATION Default for new 12c customers	Orchestration + Mediator + Rules + Partial Adapter set
SOA FOUNDATION ENTERPRISE	SOA Foundation + Full Adapter Set
SOA FOUNDATION WITH B2B	SOA Foundation Enterprise + B2B
SOA FOUNDATION WITH HEALTHCARE	SOA Foundation with B2B + Healthcare UI
SOA CLASSIC Default for upgrade customers	SOA Foundation with B2B + BPM Modules

If you are using a limited set of components or features in the SOA suite, you can change your profile to optimize your memory usage and server startup times. This can free up resources for crucial processes and can improve disaster recovery.

You can change your modularity profile from the SOA dashboard in Enterprise Manager for Fusion Middleware Control.

For more information on how to change your profile, see Configuring SOA Infrastructure Properties in Administering Oracle SOA Suite and Oracle Business Process Management Suite to find the SOA Infrastructure Common Properties page.

Then see Configuring Oracle SOA Suite and Oracle BPM Suite Profiles in Administering Oracle SOA Suite and Oracle Business Process Management Suite for more information on the profiles.

11.4.3 Tuning Your Database for SOA Processes

If needed, you can adopt advanced strategies for tuning your database for SOA processes. Make sure you have already read and followed the general database tuning suggestions covered in Tuning Database Parameters of this book before progressing.

• Collecting Optimizer Statistics
  
• Tuning Temporary Tablespaces for SOA
  
• Minimizing SOA Database Contention
  
• Purging
  
• Reclaiming Space
  

11.4.3.1 Collecting Optimizer Statistics

Optimizer statistics provide details about the database and the objects in the database. The query optimizer uses these statistics to choose the best execution plan for each SQL statement. See Introduction to the Query Optimizer in Oracle Database SQL Tuning Guide for more information.

• Gathering Statistics Automatically
  
• Gathering Statistics Manually
  
• Optimizing the MDS Database Repository With Statistics
  

11.4.3.1.1 Gathering Statistics Automatically

Because objects in a database can change constantly, you must update statistics regularly so that they accurately describe these objects.

All SOA databases should use the Automatic Statistics Collection, which is enabled by default. This job runs every night. See Controlling Automatic Optimizer Statistics Collection in Oracle Database SQL Tuning Guide for more information.

11.4.3.1.2 Gathering Statistics Manually

Automatic optimizer statistics collection is sufficient for most database objects, but in a database that is close to going live or for tables that are modified/purged significantly, manual statistic gathering is needed. See Gathering Optimizer Statistics Manually in Oracle Database SQL Tuning Guide for more information.

For SOA databases that implement purging of stale data on regular basis, you should collect stats manually right after purging has completed. In these cases, use the DBMS_STATS.GATHER_TABLE_STATS procedure. See DBMS_STATS in for how to do this.

11.4.3.1.3 Optimizing the MDS Database Repository With Statistics

Ensure that automatic statistics collection is enabled. See Controlling Automatic Optimizer Statistics Collection in Oracle Database SQL Tuning Guide for more information.

In most cases, the first 32 characters of PATH_FULLNAME in the MDS_PATHS table are the same. You can prevent the database from putting them in the same section of the histogram by doing the following:

1. Drop the histogram for PATH_FULLNAME column by executing a command structured like the following as system:

   execute dbms_stats.delete_column_stats(ownname=>'mdsSchemaOwner', tabname=>'MDS_PATHS', colname=>'PATH_FULLNAME', col_stat_type=> 'HISTOGRAM');
   

2. Set table preferences to exclude collecting histogram for the PATH_FULLNAME column with a command structured like the following:

   execute dbms_stats.set_table_prefs(mdsSchemaOwner, 'MDS_PATHS', 'METHOD_OPT', 'FOR COLUMNS SIZE 1 PATH_FULLNAME');
   

11.4.3.2 Tuning Temporary Tablespaces for SOA

See Tuning Database Files for general guidelines on tuning TEMP tablespaces for Oracle Fusion Middleware before progressing to this topic.

Some SOA queries can generate a large amount of disk sorts that require high amounts of temporary space. Therefore, the use of multiple temporary tablespaces and tablespace groups is recommended to meet these requirements and assure optimal performance.

The suggested minimum size for the TEMP tablespace or tablespace group assigned to the SOA schema owner is 6 GB with auto-extend enabled. See Changing Data File Size in for more information on how to resize a tablespace and enable auto-extend.

11.4.3.3 Minimizing SOA Database Contention

Most SOA workloads generate heavy DML activity in the database and are likely to experience contention on database objects.

Wait event data in Automatic Workload Repository (AWR) reports reveal various symptoms that might be impacting performance. The most common wait events that could occur in SOA database are as follows:

• DB CPU

• Db file sequential read, db file scattered read

• log file sync

• enq: HW - contention

• enq: TX - index contention

• buffer busy waits

• gc buffer busy acquire, gc buffer busy release (RAC)

• enq: SQ - contention

Recommendations for the wait events gc buffer busy acquire and gc buffer busy release are also discussed in Creating Hash Partitioned Indexes (enq: TX - index contention).

For information on using AWR reports to identify contentions in your database, see Comparing Database Performance Over Time in .

• Tuning the Redo Log Performance (log file sync)
  
• Migrating BasicFiles to SecureFiles (enq:HW - contention)
  
• Creating Hash Partitioned Indexes (enq: TX - index contention)
  

11.4.3.3.1 Tuning the Redo Log Performance (log file sync)

In a SOA database, it is very common to see the foreground wait event log file sync with a high average wait time. This is caused by redo log performance. The possible reasons for high log file sync waits are as following:

• The database log writer (LGWR) is unable to complete writes fast enough for one of the following reasons:

  • Disk I/O performance to log files is not good enough.

  • LGWR is starving for CPU resources.

• LGWR is unable to post the processes fast enough due to excessive commits.

• LGWR is suffering from other database contentions, such as enqueue waits or latch contention.

Tuning the redo log performance can improve performance for applications running in an Oracle Fusion Middleware environment.

See Tuning Database Files for general guidelines on tuning redo logs for Oracle Fusion Middleware before using the strategies here to tune for SOA processes.

Finding LGWR wait events

The first step in identifying the root cause is to find and break down LGWR wait events. You can query for LGWR wait events using its SID, as shown in the following example:

SQL> SELECT sid, event,  time_waited, time_waited_micro
    FROM v$session_event
    WHERE sid IN 
       (SELECT SID FROM v$session WHERE type!='USER' AND program LIKE '%LGWR%' )
ORDER BY time_waited;

Sizing online redo logs to control the frequency of log switches and minimize system waits

The suggested minimum setting for redo logs is to have at least 3 log groups of 2 GB each. Monitor the redo log performance periodically. Then adjust the number of redo log groups and size of each member as appropriate to control the frequency of log switches and minimize system waits.

Size the redo log files according to the amount of redos the system generates. A rough guide is to switch logs at most once every 20 minutes.

For example, if your online redo logs switches once every 5 minutes during peak database activity, the logs would each need to be 4 times larger then their current size to achieve the 20 minute guideline. The calculation for this is 20min / 5min = 4x.

Optimizing the redo log disk to prevent bottlenecks

A SOA database is highly write-intensive, which generates massive amount of redo per second and per transaction. Sometimes no amount of disk tuning may relieve redo log bottlenecks, because Oracle must push all updates for all disks into a single redo location.

If I/O bandwidth is an issue, doing anything other than improving I/O bandwidth is not useful. One way to relieve redo bottlenecks is to use faster redo storage. It is recommended to use Solid State Disk (SSD) redo log files. SSD has greater bandwidth than platter disk.

Determining the optimal sizing of the log_buffer

SOA applications insert, modify, and delete large volumes of data. Most of these operations are committed in a row-by-row fashion rather than in batch mode. Frequent commits cause a significant overhead on the redo performance, so sizing the log_buffer optimally is important for performance.

The statistic REDO BUFFER ALLOCATION RETRIES from your AWR reports and/or from V$ views reflects the number of times a user process waits for space in the redo log buffer. You can obtain this statistic through the dynamic performance view V$SYSSTAT with the following query:

SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME = 'redo buffer allocation retries';

The value of redo buffer allocation retries should be near zero over an interval. If this value increments consistently, then processes have had to wait for space in the redo log buffer. The wait can be caused by the log buffer being too small or by check pointing. You can improve this wait by attempting the following:

• Increase the size of the redo log buffer, if necessary, by changing the value of the initialization parameter LOG_BUFFER. The value of this parameter is expressed in bytes. A good starting rule of thumb for a write intensive workload is to configure the log buffer to 100mb. Use caution while increasing log_buffer setting, because excessive redo size can also cause high log file sync waits.

• Improve the check pointing or archiving process.

You can also check to see if the log buffer space wait event is a significant factor in the wait time for the instance. If not, the log buffer size is most likely adequate.

Tuning the LGWR Process

For most SOA workloads, the commit rate is very high, and decreasing commits is not an option. If previous strategies to address high log file sync did not improve redo log performance, try increasing the priority of LGWR or increasing the priority class of LGWR to RT from the command line.

Using Smart Flash Logging for ExaData

If your database is on ExaData machine, it should have a minimum of Bundle Patch 11 (BP11) installed to take advantage of the Smart Flash Logging feature.

Exadata Smart Flash Logging is an additional feature implemented in Exadata Storage software 11.2.2.4.2 and database version 11.2.0.2 + BP11. With this feature, 512MB of flash storage is reserved for redo writes and the LGRW process adopts a different pattern of behavior.

In a system which does not use this feature, LGWR writes in parallel to multiplexed copies of the redo logs and then waits for all writes to complete. This means that the time taken to perform these writes (indicated by the Oracle wait interface statistics log file parallel write) is the time taken for the slowest disk to complete the write.

With Exadata Smart Flash Logging, the redo log files remain on disk, but the additional reserved 512MB of space is created on flash storage. When issuing a write call, LGWR writes to the redo logs on disk as usual but will also make a parallel write to the flash area. LGWR then waits for whichever of these writes completes first to post it, after which it continues without waiting for the other.

11.4.3.3.2 Migrating BasicFiles to SecureFiles (enq:HW - contention)

The High Water enqueue contention (enq:HW - contention) occurs when competing processes are inserting into the same table and are trying to increase the high water mark of a table simultaneously.

In a SOA database, this issue is experienced by tables that have large object (LOB) columns, such as CUBE_SCOPE, XML_DOCUMENT, AUDIT_DETAILS, etc. Under a heavy load, LOB segments in these tables experience contention, which is seen in an AWR report as the wait event enq: HW contention.

The default storage for LOBs in an Oracle database is BasicFiles. Frequently allocating extents or reclaiming chunks may cause contention for the LOB segment high water marks. This contention can also occur for LOB segments that are ASSM-managed, since space allocation only acquires one block at a time.

This contention can be eliminated by switching LOB storage from BasicFiles to SecureFiles. SecureFiles is a LOB storage architecture that provides performance benefits over traditional BasicFiles. See About LOB Storage in Database SecureFiles and Large Objects Developer's Guide for more information on these two architectures.

Migrating BasicFiles to SecureFiles can be done using one of the following methods:

• Set the database parameter SECURE_FILES = ALWAYS.

  This method is applicable for new installations prior to creating SOA tables using RCU. Once this parameter is set at the instance level, any new LOB segments created will use SecureFiles automatically.

• Use the online redefinition method.

  This method is applicable for installations that already have SOA tables created in them. In such cases, LOB segments from tables in a SOA database experiencing enq: HW contention can be migrated to SecureFiles.

  Using the online redefinition method to migrate to SecureFiles can be done with very little downtime. See Using DBMS_REDEFINITION in for how to use the lob_storage_as parameter to reassign a LOB store.

• Set the database event value to 44951 using the following script:

  ALTER SYSTEM SET EVENT='44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024? scope=spfile;
  

  This method will help a SOA installation using an Oracle version older than 11g to avoid enq:HW contentions on LOB segments.

You can use your AWR and Automatic Database Diagnostic Monitor (ADDM) reports to identify which LOB objects are suffering from enq:HW - contentions. For most systems, however, it is highly recommended to move the LOB columns listed in the following table to SecureFiles.

Table Name	Column Name	Recommended LOB Storage Attributes
ATTACHMENT	ATTACHMENT	COMPRESS CACHE
AUDIT_DETAILS	BIN	COMPRESS CACHE
CUBE_SCOPE	SCOPE_BIN	COMPRESS CACHE

11.4.3.3.3 Creating Hash Partitioned Indexes (enq: TX - index contention)

In most SOA scenarios, multiple database sessions will insert thousands of rows into SOA tables. In these situations, the number of index keys is constantly increasing, particularly the primary key indexes.

Though the number of primary key indexes increases over time, B-tree structure indexes only target a few database blocks for key insertions. These B-tree index insertions can become problematic in a Real Application Cluster (RAC). This issue is seen in an AWR report as high buffer busy waits.

B-tree indexes create other contentions for RAC environments that show in an AWR as gc buffer busy acquire and gc buffer busy release wait events. These occur when a transaction inserting a row in an index has to wait for the end of a different transaction's index block split, forcing the session to wait as well. When many concurrent inserts lead to excessive index block splits, performance decreases.

The solution for these contentions is to create global, hash partitioned indexes. This forces a random distribution of index keys across many database blocks to avoid these contentions or hot spots.

Hash partitioning has proven to be the best tuning method to address index contention. You should use your AWR and ADDM reports to identify indexes that need to be partitioned. Once you have identified hot indexes, consider hash partitioning them to reduce or avoid index contention.

For information on hash partitioning, see Creating Hash Partitioned Tables and Global Indexes in .

11.4.3.4 Purging

The need for aggressive and continuous purging is a key aspect to improving performance and controlling disk space in SOA.

Managing auto purge feature, enabled by default to help manage on-going database growth in 12c, is described in Table 11-2. SOA installations that accumulate a lot of data should also implement a purging strategy to clean up redundant data, to help of SQL query performance, and to save disk space.

To create a purging strategy, see Developing a Purging and Partitioning Methodology in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

11.4.3.5 Reclaiming Space

SOA installations that implement frequent purging of unwanted data from SOA tables are more likely to experience disk space issues.

This problem occurs even with ASSM and locally managed tablespaces. When automatic purge scripts delete rows from database tables and indexes to release space within the data blocks for reuse, space is not released immediately after rows are deleted. This causes fragmentation, with some space too small for reuse, particularly when the tables contain LOB columns.

To alleviate fragmentation and consolidate disk space, you should manually shrink tables and LOB columns to reclaim space on a routine basis.

Use the Segment Advisor to identify segments that would benefit from online segment shrink. Note that most SOA segments should be candidates for online segment shrink operations after constant purging. See Using the Segment Advisor in for more information on how to use the Segment Advisor.

Once you have identified the database tables and indexes that need shrinking, use the following commands to reclaim space manually:

ALTER TABLE CUBE_SCOPE ENABLE ROW MOVEMENT;
ALTER TABLE CUBE_SCOPE SHRINK SPACE;
ALTER TABLE CUBE_SCOPE MODIFY LOB (SCOPE_BIN) (SHRINK SPACE);
ALTER TABLE CUBE_SCOPE DISABLE ROW MOVEMENT;

This shrink operation consolidates free space below the high water mark and compacts the segment. Then it moves the high water mark and de-allocates space above the high water mark.

11.4.4 Tuning Event Delivery Network Parameters

The Event Delivery Network (EDN) delivers events published by Oracle Mediator, Oracle BPEL Process Manager, and external publishers such as Oracle Application Development Framework entity objects. See Introduction to the Event Delivery Network and JMS Provider Types in Administering Oracle SOA Suite and Oracle Business Process Management Suite for a more detailed description.

Table 11-4 lists parameters that you can find in the Fusion Middleware MBean Browser and tune for improved event delivery.

Table 11-4 Event Delivery Network Tuning

Parameter	Problem	Tuning Recommendation	Trade-offs
numberOfPollerThreads Default: -1	Out-of-resource issues, e.g. out of memory, system overload, transaction issue, etc. Contention with other SOA threads	The default value of -1 means that the system will use ThreadsPerSubscriber to determine a poller thread count. This is optimal for most configurations. However, if you have a high number of subscribers, the default setting will try to assign a thread to each subscriber. This will slow your system down. You should define a positive integer to limit the amount of poller threads created for this task. See Updating the Local numberOfPollerThreads Value at the Service Component Level in Administering Oracle SOA Suite and Oracle Business Process Management Suite for how to change this parameter's value in the Fusion Middleware MBean Browser.	If the value is too low for your system, then poller threads can cause event backlogs and long latencies between event publishing and composite instance creation. If the value is too high, then excess poller threads will consume server resources needlessly.
ThreadsPerSubscriber Default: 1 thread	Out-of-resource issues, e.g. out of memory, system overload, transaction issue, etc. Contention with other SOA threads	Typically, the default of 1 thread per subscriber is optimal. Note that numberOfPollerThreads should be adjusted first, since that parameter takes precedence over this value. See Updating the ThreadsPerSubscriber Attribute in the System MBean Browser in Administering Oracle SOA Suite and Oracle Business Process Management Suite for how to change this parameter's value in the Fusion Middleware MBean Browser.	If the value is too low for your system, then poller threads can cause event backlogs and long latencies between event publishing and composite instance creation. If the value is too high, then excess poller threads will consume server resources needlessly.

Table 11-5 lists the parameters you can modify for individual business events in JDeveloper. To modify these attributes, right-click on the event you want to edit to bring up the pop-up menu. From this menu, select Edit Subscribed Events... or Edit Published Events..., depending on the parameter you are trying to edit.

For descriptions of the subscribed event parameters you can edit, see How to Subscribe to a Business Event in Developing SOA Applications with Oracle SOA Suite.

Table 11-5 Business Event Tuning

Parameter	Problem	Tuning Recommendation	Trade-offs
Consistency for a Subscribed Event Default: oneAndOnlyOne	You are experiencing either one or both problems with business event delivery. Unfulfilled delivery guarantee requirements to event subscribers Unnecessary system overhead from global transactions	Set the level for a selected business event to guaranteed in JDeveloper. A guaranteed delivery is performed in a local transaction with only one trip to the main queue. You can also edit this parameter on the Subscriptions page in the Oracle Enterprise Manager Fusion Middleware Control. See Viewing Business Event Subscribers in Administering Oracle SOA Suite and Oracle Business Process Management Suite for details.	oneAndOnlyOne guarantees delivery by taxing resources. If a guaranteed delivery fails, then there are no local retries and a system failure message is generated. Message duplication could occur in the event that the calling global transaction rolls back and retries since the message delivery is outside of that transaction.
Durability for a Subscribed Event Default: Yes	You are experiencing either one or both problems with business event messages. Multiple dropped events Unnecessary retention of messages in the system	Set the value under the Durable column to No to disable durability for a subscribed event using JDeveloper. This will free the system from having to persist messages to storage.	No will cause the system to drop events if the subscriber is not running when events are published. Yes will retain events in the JMS server and incur overhead.
Persistent Delivery for a Published Event Default: yes	Unreliable messaging High overhead	Set this value to No to disable persistent delivery. This will reduce overhead.	No will cause less reliable messaging following an event publish since there is no persistence. Yes will incur overhead by guarding against a JMS server crash.
Time to Live for a Published Event Default: 0 ms	Non-expired and unconsumed messages are occupying system resources and requiring manual cleanup. Messages are deleted before subscribers can read them.	Specify a positive integer so that expired messages are automatically removed from the system and not consumed by the subscribers. The integer represents milliseconds. The best value depends on your system and can be determined by monitoring metrics. Note that the default value of 0 means that messages will never expire.	If the message expiration duration value is too low, published messages can expire before an intended subscriber can read it. Once it is gone, it cannot be retrieved. If the value is too high, then lingering messages can occupy system resources.

• Adding JMS Topics with Mapping
  

11.4.4.1 Adding JMS Topics with Mapping

By default, all events are mapped to a single WLS topic.

If you have a large backlog of events or are experiencing latency or slowness in event processing due to single or limited JMS topics, you should create additional JMS topics and modify events to JMS mapping so that event types of different performance characteristics may be grouped or managed separately.

However, if you do this, the system will have additional JMS topics and JMS artifacts to manage, and you will have mapping changes to consider.

• Choosing a JMS Topic Type
  
• Creating JMS Topics
  
• Mapping Events to JMS Topics
  

11.4.4.1.1 Choosing a JMS Topic Type

You can create either a WLSJMS topic or an AQJMS topic.

WLSJMS is the default JMS topic type. It does not provide database indexing, LOB streaming, embedded rules engines, and lock management as well as AQJMS.

AQJMS will typically not be faster than WLSJMS, but if your system has high concurrences, AQJMS works well because it is single-threaded. AQJMS can also get constrained by lower and storage nodes in Exalogic.

11.4.4.1.2 Creating JMS Topics

You can create a new WLSJMS topic under the SOAJMSModule in the WebLogic Administration Console if you are logged in as an Administrator. See "Create topics in a system module" in the Oracle WebLogic Server Administration Console Online Help for details on navigating to the Create a New JMS System Module Resource and creating a JMS topic.

You can create an AQJMS topic using the Database Navigator in JDeveloper or SQL Developer as soainfra user by running the following script:

define edn_user=your_soainfra_schema_username
define topic=your_custom_aqjms_topic_name, e.g. 'EDN_AQJMS_TOPIC_2'
define topic_table=your_custom_aqjms_topic_table, e.g. 'EDN_AQJMS_TOPIC_TABLE_2'
 
begin
  DBMS_AQADM.stop_queue(queue_name => '&edn_user..&topic');
  DBMS_AQADM.drop_queue(queue_name => '&edn_user..&topic');
  DBMS_AQADM.drop_queue_table(queue_table => '&edn_user..&topic_table');
end;
/
begin
  dbms_aqadm.create_queue_table(queue_table => '&edn_user..&topic_table', 
                                queue_payload_type => 'SYS.AQ$_JMS_MESSAGE', 
                                multiple_consumers => true);
  dbms_aqadm.create_queue(queue_name => '&edn_user..&topic', 
                          queue_table => '&edn_user..&topic_table', 
                          max_retries => 256);
  dbms_aqadm.start_queue(queue_name     =>   '&edn_user..&topic');
end;
/
commit;

You can reference Create a JMS Queue or Topic in Administering JMS Resources for Oracle WebLogic Server for information about AQ JMS topics.

11.4.4.1.3 Mapping Events to JMS Topics

When you have created new JMS topics, you can map business events to specific topics. Note that one event type can be mapped to only one JMS topic, whereas one JMS topic can store multiple event types.

For more information on using the Enterprise Manager for Fusion Middleware Control to map events, see Mapping Business Events to JMS Topic Destinations on the Business Events Page in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

11.4.5 Tuning the WebLogic Server

The performance of the SOA Infrastructure depends on the WebLogic Server. Though tuning the WebLogic Server is a separate task not thoroughly addressed in this book, you can use Table 11-6 to check the tuning knobs that affect the SOA Infrastructure.

Table 11-6 Essential WebLogic Server Tuning for SOA Infrastructure

Parameter	Tuning Recommendation	Resource
ProductionModeEnabled Default: The mode you set during domain creation.	Production mode maximizes performance. You should enable this if you are not developing applications. You can enable the ProductionModeEnabled MBean in Oracle Fusion Middleware Control.	See Configure General Settings in Administering Oracle WebLogic Server with Fusion Middleware Control. Changing the domain mode will also change certain security and autodeployment settings. See Development vs. Production Mode Default Tuning Values in Tuning Performance of Oracle WebLogic Server for more information on domain modes.
WebLogic Server Logging Levels Default: Notification	To reduce the volume of logging requests, use the lowest acceptable logging level, such as ERROR or WARNING whenever possible. You can set log levels for handlers and loggers in a variety of ways.	See Using Log Severity Levels in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server for these methods.
HTTP Access Logging Default: Enabled	By default, the HTTP subsystem keeps a log of all HTTP transactions in a text file. Turn off HTTP access logging to improve performance. You can disable this property using the Oracle WebLogic Server Administration Console.	See "Enable and configure HTTP logs" in the Oracle WebLogic Server Administration Console Online Help.
JMS Persistence and Persistence Storage Default: Enabled	Ensure that the right persistence level is set for the Java Message Service (JMS) destinations. For persistent JMS scenarios, there are two choices: File Store and JDBC Store. Typically, operations on a File Store perform better than JDBC Store. If there are multiple JMS servers involved, create each store on a separate disk to lower I/O contention. For non-persistent JMS scenarios, turn off persistence at the JMS server level by un-checking the Store Enabled flag from the Advanced section of the General tab for the JMS server in the WebLogic Server console. You can also override the persistence mode at the JMS destination level.	See Using Custom File Stores and JDBC Stores in Tuning Performance of Oracle WebLogic Server for more information on creating and managing persistent JMS stores.
Connection Backlog Buffering	You can tune the Accept Backlog parameter when dealing with a large number of concurrent clients. The Accept Backlog parameter specifies how many TCP connections can be buffered in a wait queue. You can tune the number of connection requests that a WebLogic Server instance will accept before refusing additional requests.	For more information, see Tuning Connection Backlog Buffering in Tuning Performance of Oracle WebLogic Server.

11.5 Advanced Tuning for Work Managers

Work Managers are mapped to SOA projects and specific components, and you can use some advanced configuration options to fine-tune Work Manager performance.

When SOA Suite is installed, it creates a set of default Work Managers, global Work Managers, and application Work Managers to manage various areas of the SOA Infrastructure.

High priority composites can be associated with a Work Manager group that has been configured for higher priority. Table 11-7 lists the set of Work Managers that are created when SOA is installed and describes the work area they manage.

Table 11-7 Work Manager Descriptions

Work Manager Name	Responsible Area
SOA_Request_WM	SOA synchronous request clients, such as the following: Facade invocation WebService client requests Direct/ADF/Rest requests B2B
SOA_Notification_WM	All SOA notification requests.
WorkManagerName_dspSystem	BPEL-specific system dispatcher messages.
WorkManagerName_dspInvoke	BPEL-specific engine process invocation dispatcher messages
WorkManagerName_dspEngine	BPEL engine process dispatcher messages
WorkManagerName_dspNonBlocking	BPEL engine process non-blocking invocation dispatcher messages
WorkManagerName__Analytics	BPEL analytics
WorkManagerName_MediatorParallelRouting	Mediator parallel routing
WorkManagerName_MediatorErrorHandling	Mediator error handling
WorkManagerName_bpmnSystem	BPM system dispatcher messages
WorkManagerName__bpmnInvoke	BPM engine process invocation dispatcher messages
WorkManagerName__bpmnEngine	BPM process engine dispatcher messages
WorkManagerName__bpmnNonBlocking	BPM process non-blocking invocation dispatcher messages
SOA_DataSourceBound_WM	All SOA backend processing services that access SOADataSource, including Workflow Enterprise JavaBeans (EJBs).
SOA_Default_WM	All SOA services that do not access the SOADataSource connection pool. It also handles Case Management.
SOA_EDN_WM	Event Delivery Network (EDN)
WorkManagerName_Adapter	Adapter framework

The SOAMaxThreadsConfig property, discussed in Configuring Work Managers with the SOAMaxThreadsConfig Attribute, determines the number of connections that will be used by Work Managers to process incoming requests, internal processes, and other processes. This configuration determines the optimal usage for each of these processing categories when the system is functioning at its full potential.

Minimum and Maximum Constraints can also be set on Work Managers to control upper and lower limit of connections for Work Managers. A Fair Share Request class for a Work Manager can be created to determine the relative priority assigned to a Work Manager. The constraints and request class mentioned here are the ones most commonly configured for SOA Work Managers.

All SOA Work Managers are pre-configured with request classes and constraints that make most sense. It is strongly recommended to run with the default settings and make any essential changes after an evaluation period.

For information on all Work Manager constraints and request classes you can create and their default behaviors, refer to Managing Work Manager Groups in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

• Configuring Fair Share Request Class for SOA Work Managers
  
• Creating a New Work Manager Constraint
  

11.5.1 Configuring Fair Share Request Class for SOA Work Managers

A Fair Share Request Class allows you specify the relative priority of a given Work Manager. All SOA Work Managers managing internal process have been configured to one of the two Fair Share Classes that are created by default: soa_fairShare_20 and soa_fairShare_80, with fair share values set to 20 and 80 respectively. A Fair Share value is a relative value from 1 to 1000.

If you want to further tune SOA Work Manager priorities, you will need to create new Fair Share classes. For more information on how to do this, see Viewing and Creating Work Manager Groups in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

11.5.2 Creating a New Work Manager Constraint

In addition to the default categories available in SOAMaxThreadConfig, you can create new categories to address specific scenarios.

Some processes in SOA do not require database connections. These processes do not depend on SOA Data Source allocation and hence will not have wait for available connections.

The SOA Infrastructure automatically creates Work Managers that manage most of your processes and allocate resources accordingly. For most cases, performance can be improved by leveraging existing Work Managers and tuning their performance using some of the knobs described above.

If you have special scenarios where you would like to handle uniquely, you can create a new Work Manager and configure it to meet special circumstances. You will be either creating a new application or a web application Work Manager. See Viewing and Creating Work Manager Groups in Administering Oracle SOA Suite and Oracle Business Process Management Suite for detailed procedures.