markovich_presentation

Bpel Dehydration Data Store: How to monitor for peak performance and still provide visibility to users

Russ Markovich

Apollo Group Inc.

Summary

This presentation touches on topics such as• The database objects of the Bpel Dehydration Data store• Useful tools such as Oracle Apex and BAM to expose data trends.• Review of stragies to control data volume.• an overview of the Oracle Bpel console configuration settings and

their impact on database performance.• Pros/Cons of the Bpel console.

Outline

• My background• Current Production Environment• Overview of the dehydration data store’s role when used in conjunction with Oracle BPEL Process

Manager• Bpel Console Domain configuration property settings that impact the Bpel Dehydration Data store

– Configuration Tab

– Administration Tab

• Database objects of the Bpel Dehydration Data store– Driving Tables

– Bpel Schema ERD (10.1.3.5)

– Views

– State columns meanings

– Status columns meanings

• Use of the Oracle supplied purge script, the Bpel Console and Bpel Java APIs to help maintain data volume

• Pros/cons of the Oracle Bpel console on Dehydration Data store performance• Use of a Bpel console read-only substitute, Oracle Apex and BAM to provide visibility into the

Dehydration Data store• Hints• Sources

Background

• Over 13 years of IT experience with 11 years directly with Oracle– Developer– Administrator– Team Lead

• Started with Oracle database 7

• Over 3 years with Oracle SOA

• Oracle Forms and Reports, Databases, Application Servers, Oracle Apex and Oracle SOA

• OCP

• Current employed with Apollo Group which is the parent company of– University of Phoenix– Western International University– College for Financial Planning– Insight Schools (national network of accredited online high schools)– Institute for Professional Development

• Contact Info: [email protected]

Current Production Environment

• Oracle Application Servers (plans to move to Weblogic)– 10.1.3.4– 2 Cluster with 2 nodes each– Solaris 10 Containers– 32 bit

• Bpel – 10.1.3.4– MLR #8

• Dehydration Database– Oracle 10g (10.2.0.4)– Oracle Apex (3.1.2)– Linux

• Tools– Oracle Enterprise Manager Grid Control 10g - Main tool to monitor the Database.– Oracle Bpel Console – Monitor the bpel instances.– Oracle Apex – Reports on the bpel instances.– Oracle Enterprise Manager 10g Application Server Control - Main tool to monitor the application servers.– Jconsole – Main tool to monitor JVM

Overview of the dehydration data store’s role

• In it’s simplest form: Oracle Bpel Process Manager utilizes a database to store metadata and instance data during runtime. This data is stored in what is known as the dehydration store, which is simply a database schema.

There are two types of processes and they impact the dehydration store database in different ways.– Transient processes (ex. synchronous): this process type does not incur any intermediate dehydration

points during process execution. If there are unhandled faults or there is system downtime during process execution, the instances of a transient process do not leave a trace in the system. Instances of transient processes cannot be saved in-flight (whether they complete normally or abnormally). Transient processes are typically short-lived, request-response style processes.

– Durable processes (ex. asynchronous): this process type incurs one or more dehydration points in the database during execution because of the following activities:

– Receive activity– OnMessage branch in a pick activity– OnAlarm branch in a pick activity– Wait activity

From Oracle® Application Server Performance Guide 10g Release 3 and Oracle® BPEL Process Manager 10g Database Schema Partitioning. See the Source section for more information.

Overview of the dehydration data store’s role

Question: What could happen when an asynchronous process calls a synchronous process?

Answer: These invokes cause the process to wait for a response from the target system and any slowness in the target system can slow down the BPEL process, thereby impacting performance due to blocked threads and longer in-memory processing.

Oracle Bpel Console Domain configuration property settings

• Domain level: enables you to configure all processes deployed in a specific domain.

• Process level: enables you to specify which processes to configure, and which not to configure, in a specific domain. If a setting at the domain level conflicts with the same setting at the process level, the process level setting take priority. Process level performance properties are set in the bpel.xml file for a specific BPEL process.


Configuration Tab

• auditDetailThreshold (Domain Level): If the size of a detail is larger than the value specified for this property, it is placed in the audit_details table. Otherwise, it is placed in the audit_trail table.

• auditLevel (Domain Level): This property sets the audit trail logging level. This process is applicable to both durable and transient processes. Affects the audit_details table.

• idempotent (Process Level - Configuration Tab>Auto-Recovery Tab): A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities.

• deliveryPersistPolicy (Domain Level): This property enables and disables database persistence of messages entering Oracle BPEL Server. By default, incoming requests are saved in the following delivery service database tables: dlv_message and invoke_message

• instanceKeyBlockSize (Domain Level): This property controls the instance ID range size.– When you have a lot of BPEL processes instances running, the BPEL PM must get the unique instance

number to create this instance, and even to store it in the dehydration store, the key is retrieved from an internal hash table. If it runs out of this table, it will be refilled. The initial size of this table is 100. Increasing this value to large number reduces contention.

Configuration Tab

• largeDocumentThreshold (Domain Level): This property sets the large XML document persistence threshold.

– Large XML documents impact the performance of the entire Oracle BPEL Server if they are constantly read in and written out whenever processing on an instance must be performed.

– By writing the variable to separate storage the performance impact is limited to times when the variable is explicitly used in a BPEL activity.

– Stored to the xml_document table.

Configuration Tab

• completionPersistLevel (Domain and Process Level when inMemoryOptimization is used): This property controls the type (and amount) of data to save after instance completion.

– This property can greatly impact database growth (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput (due to reduced I/O).

• completionPersistPolicy (Domain and Process Level when inMemoryOptimization is used): This property controls if and when to persist instances.

– This property can greatly impact database growth (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput (due to reduced I/O).

• inMemoryOptimization (Process Level): The process will run in memory without saving anything to the dehydration database unless the instance faults which then all instance data is saved.

Configuration Tab

inMemoryOptimization, completePersistLevel and CompletionPersistPolicy parameters

Configuration Tab: Auto-Recovery Sub-tab

• This kicks off on restart unless disabled.

• Has the possibility of overwhelming the system.

• Best to control the recovery and run when load is low.

Administration Tab: Recover(Invokes) Sub-tab

• Be careful on how many you kick off at once.

• Has the possibility of overwhelming the system.

• Best to control the recovery and run when load is low.

Administration Tab: Diagnostics Sub-tab

• Doesn’t really affect the database but is a good tool for debugging.

Database objects of the Bpel Dehydration Data store

Driving tables• ATTACHMENT: Attachment persistence table. Attachment parts of BPEL Message variables are stored in this

table.• ATTACHEMNT_REF: Attachment reference table. An attachment can be referenced by multiple BPEL instances.

The references to an attachment are saved in this table.• AUDIT_DETAILS: Stores audit details that can be logged through the API. Activities such as an assign activity

log the variables as audit details by default. You can set this behavior through the auditLevel property in Oracle BPEL Control. Audit details are separated from the audit_trail table due to their large size. The auditDetailThreshold property in Oracle BPEL Control is used by this table. If the size of a detail is larger than the value specified for this property, it is placed in this table. Otherwise, it is placed in the audit_trail table.

• AUDIT_TRAILS: Stores the audit trail for instances. The audit trail viewed in Oracle BPEL Control is created from an XML document. As an instance is processed, each activity writes events to the audit trail as XML. This is the table that is queried to display the audit flow from BPEL Console. Contains a column named LOG which is a Large Object RAW Column, each step in BPEL process gets logged into LOG Column in XML zipped form.



• CUBE_INSTANCE: Stores process instance metadata (for example, the instance creation date, current state, title, and process identifier). For each BPEL process instance an entry gets created in this table. This will tell you the data on which this instance started, and the last updated date of the instance. The table also contains the relationship between parent and child instances in fields: cikey, parent_id, and root_id.

• CUBE_SCOPE: Stores the scope data for an instance (for example, all variables declared in the BPEL flow and some internal objects that help route logic throughout the flow).

• DLV_MESSAGE: Stores callback messages upon receipt. This table only stores the metadata for a message (for example, current state, process identifier, and receive date).

• DLV_SUBSCRIPTION: Stores delivery subscriptions for an instance. Whenever an instance expects a message from a partner (for example, the receive or onMessage activity) a subscription is written out for that specific receive activity.

• DOCUMENT_CI_REF: Stores cube instance references to data stored in the xml_document table.

• DOCUMENT_DLV_MSG_REF: INVOKE_MESSAGE and DLV_MESSAGE have references to XML_DOCUMENT. The relationships between these tables are stored here.


• INVOKE_MESSAGE: All asynchronous invocation messages are stored in this table before being dispatched to the engine. Stores incoming (invocation) messages (messages that result in the creation of an instance). This table only stores the metadata for a message (for example, current state, process identifier, and receive date). Stores the information regarding the message that invokes a BPEL Process.

• WORK_ITEM: stores activities created by an instance ... all BPEL activities in a flow will have a work_item created for it. This work item row contains metadata for the activity ... current state, label, expiration date (used by wait activities) ... when the engine needs to be restarted and instances recovered, pending flows are resumed by inspecting their unfinished work items. This table contains the activities against the BPEL Process Instance.

• XML_DOCUMENT: Stores all large objects in the system (for example, invoke_message documents, dlv_message documents, and so on). This table stores the data as binary large objects (BLOBs). Separating the document storage from the metadata enables the metadata to change frequently without being impacted by the size of the documents.


Bpel Schema ERD (10.1.3.5)

The Main Bpel Tables and the relationships between them


ViewsUsed by the BPEL Console via the JAVA APIs.• ACTIVITY_PERF:• ADMIN_LIST_CI: Simple query on the cube_instance table.• ADMIN_LIST_CX: Simple join between cube_instance and ci_indexes tables.• ADMIN_LIST_TD:• ADMIN_LIST_TDEF: Admin list for test definitions.• ADMIN_LIST_WI: Simple query on the work_item table.• BPEL_ACTIVITY_SENSOR_VALUES:• BPEL_ERRORS:• BPEL_FAULT_SENSOR_VALUES:• BPEL_PROCESS_INSTANCES:• BPEL_VARIABLE_ANALYSIS_REPORT:• BPEL_VARIABLE_SENSOR_VALUES:• DBG_WI:• INSTANCE_PERF:• WFPRODUCTIVITY_VIEW:• WFTASKCYCLETIME_VIEW:• WFTACKPRIORITY_VIEW:• WFUNATTENDEDTASKS_VIEW:• WORK_LIST:

From Oracle® BPEL Process Manager Client Java API Reference 10g Release 3 (10.1.3.1.0). See the Source section for more information.


State columns meanings of the some of the main tables• CUBE_INSTANCE:

– STATE_INITIATED = 0– STATE_OPEN_RUNNING = 1– STATE_OPEN_SUSPENDED = 2– STATE_OPEN_FAULTED = 3– STATE_CLOSED_PENDING_CANCEL = 4– STATE_CLOSED_COMPLETED = 5– STATE_CLOSED_FAULTED = 6– STATE_CLOSED_CANCELLED = 7– STATE_CLOSED_ABORTED = 8– STATE_CLOSED_STALE = 9

• DLV_MESSAGE, DLV_SUBSCRITPION and INVOKE_MESSAGE– STATE_UNRESOLVED = 0– STATE_RESOLVED = 1– STATE_HANDLED = 2– STATE_CANCELLED = 3



• PROCESS– STATE_ON = 0– STATE_OFF = 1

– LIFECYCLE_ACTIVE = 0– LIFECYCLE_RETIRED = 1

• WORK_ITEM– STATE_INACTIVE = 0– STATE_OPEN_ACTIVE = 1– STATE_OPEN_SUSPENDED = 2– STATE_OPEN_PENDING_COMPLETE = 3– STATE_OPEN_FAULTED = 4– STATE_CLOSED_COMPLETED = 5– STATE_CLOSED_FINALIZED = 6– STATE_CLOSED_PENDING_CANCEL = 7– STATE_CLOSED_CANCELLED = 8– STATE_CLOSED_FAULTED = 9– STATE_CLOSED_ABORTED = 10– STATE_CLOSED_COMPENSATED = 11– STATE_CLOSED_STALE = 12


Status columns meaning of the some of the main tables• BPELNOTIFICATION – Holds messages for notification services

– ERROR– RETRY– SEND

• CUBE_INSTANCE - Holds user defined value; meant to allow users to keep track of current status of instance. Is a variable that keeps track of where in the process a particular process instance is. When the process is first initiated, this value is set to ‘initiated’. This value is then updated every time you enter a new scope within a process to contain the name of the scope.

• TASK– STATUS_ACTIVE = Active– STATUS_CANCELLED = Cancelled– STATUS_COMPLETED = Completed


Maintain data volume

How important is purging your data? That’s a good question and we learned the hard way. As volume increased we encountered some performance issues with the main DMLs in our database. Here are examples of the service request we submitted to Oracle Support with concerns on how data volume affected database performance.

• SR 2-2668658: DOING FULL TABLE SCAN TABLES DOCUMENT_DLV_MSG_REF AND DLV_MESSAGE. Fixed in MLR#7.

• SR 2-6008693: Query using dlv_message and document_dlv_msg_ref is very slow

Maintain data volume: Oracle supplied purge script

• Location: $ORACLE_HOME/bpel/system/database/scripts/purge_instances_oracle.sql• In its present form the purge_instances_oracle.sql deletes all cube instances and related data which were closed

before given date time.• Use of 4 temp tables and up to 37 delete statements depending on the script version.• We evolved this script into domain/date driven Oracle job regardless of state (see Figure 6). We currently run this

on a daily basis.

Maintain data volume: Oracle supplied purge script

• We’ve encountered full table scans on the bpelnotification table so we changed the script to keep only the last 24 hours of messages.

• If data volume is to large consider partitioning the large tables and dropping older partitions (10.1.3.5 and above). You can run the purge_instances_oracle.sql and partitioning in concert or partition all tables. Refer to Oracle® BPEL Process Manager 10g Database Schema Partitioning for more information.

– What if you on v.10.1.3.4 or below? • Perhaps breakup the purge_instances_oracle.sql script into several jobs and run in parallel.• If not concerned with processed instance data you can always truncate the tables. Review Sean Carey’s blog for an

updated 10.1.3.4 truncate script: http://scsoablog.blogspot.com/2008/01/purging-bpel-dehydration-store.html

http://scsoablog.blogspot.com/2008/01/purging-bpel-dehydration-store.html

Maintain data volume: Oracle supplied online rebuild index script

• Location: $ORACLE_HOME/bpel/system/database/scripts/online_rebuild_index_oracle.sql• online_rebuild_index_oracle.sql description: Whenever purge_instances_oracle.sql script is run, we delete lot of

rows from dehydration table and that may cause B*Tree indexes to get fragmented and performance may degrade. We can avoid that by rebuilding indexes online. Oracle 9i and above with enterprise edition database has the option of rebuilding indexes without shutting down the database or without affecting dml operations on the database.

• This last statement is true to a point. Rebuilding the indexes will cause a table lock which might interfere with DML. Recommend running this during a downtime.

• We evolved this script into an Oracle job. We currently run this on a weekly basis.• Creates a lock in 10g so be careful. In 11g locks are no longer an issue when rebuilding online.

Maintain data volume: Oracle Bpel Console

• Location: Administration Tab > Actions– Purge All Instances: Deletes all instances in the dehydration store belonging to this domain. This action will

remove in-flight as well as completed instances.– Purge Sensor Data: You are able to delete all the sensor data stored in the dehydration store. This

CANNOT be undone.

Maintain data volume: Oracle Bpel Java APIs

The use of the Oracle provided Java APIs to help maintain data integrity.– Package: com.oracle.bpel.client

• Class: Interface IBPELDomainHandle• Method: deleteAllInstances ():

– Deletes all the instances contained in the process domain.• Method: deleteCallbackMessages ():

– Deletes a list of callback messages from the BPEL domain.• Method: deleteInstancesByProcessId ():

– Deletes all the instances contained in the process domain for the specified BPEL process.• Method: deleteInvokeMessages ():

– Deletes a list of invocation messages from the BPEL domain.– Package: com.oracle.bpel.client

Class: Interface IInstanceHandle

Method: delete ():

Delete the instance from the process domain. After this method is invoked all the data associated with this instance in the data store will be removed. This action cannot be undone.

Maintain data volume: Other

• We evolved the purge script to delete dirty/corrupt data, based on Instance ID, usually associated with locked rows/tables.

In the event there is some corrupt data which is causing a lock in the database, maybe caused from a bounce or the system restart, purging this data is crucial to the health of your application and processes. By identifying the Instance ID via the rowid and populating the purge temp tables the existing purge script can be leveraged to clean up locked rows.

Maintain data volume: Other

• After all these deletions you might think of shrinking the data segments and reclaim space: – http://www.oracle.com/technology/oramag/oracle/05-may/o35tuning.html

Should be done in the off hours or in a maintenance window because there is a potential for locking.

http://www.oracle.com/technology/oramag/oracle/05-may/o35tuning.html

The pros/cons of the Oracle Bpel console

Pros• The BPEL Console is a web-based interface, which is basically a bunch of JSP and servlets that call the BPEL

Java APIs. This means we can easily modify the standard jsps/servlets and/or develop our own console if there is a need to handle a BPEL process in a specific way.

• Through BPEL Console we can deploy, manage, administer, and debug BPEL processes. The most important features of the BPEL Console include:

– Visual process flows– Audit trails– Debugging view of processes– Process history– Several out of the box features for searching the process instances using multiple search criteria

• The majority of these features are very well tuned and produce very little load.


Cons

Oracle Bpel Console produces many full table scans depending on where you navigate. (Top 10 Sessions in OEM)

• Just logging into the Bpel console to the Dashboard tab produces a full table scan on the cube_instance table via a couple of inline-views (see Figure 10). The admin_list_ci view is created on the cube_instance.

• Side note: The STOPKEY operation relates to the use of the ROWNUM <= n condition. By adding this condition to a SQL statement that fetches millions of rows will now return a smaller number of matching rows faster.

• Possible workaround: Logging into the Bpel Console places you in the Default domain. Navigate to the Administration tab and then go to the URL and replace the domain name with another and hit the enter key. This will send you to the domain you specified in the URL Administration tab without navigating to the Dashboard jsp.


• Navigating to the Instance tab produces two full table scans on the ci_indexes and cube_instances tables. The admin_list_cx view is created on the ci_indexes and cube_instances tables.

• Side note: The HASH JOIN operation relates to the scanning of the smaller table first and then joining it to the larger table while the RIGHT OUTER returns all rows from the right table and the matching values from the left table. If there are no matching values a NULL is returned.

• Possible workaround: modify the Instance jsp to default to a specific process and state so it won’t do a full table scan straight off.


• Navigating to the Administration tab > subtab Recover(Invokes) produces the a full table scan. • Possible workaround: modify the Recover(Invokes) jsp to default to a specific process.


• Clicking on the Tree Finder also produces a full table scan.

Use of a Bpel console read-only substitute

So after showing you the database load that the Bpel console produces how can you provide visibility to power users and support teams while producing the smallest performance impact?

Read-Only Bpel Console

Chintan Shah’s http://chintanblog.blogspot.com/2007/12/i-saw-numerous-people-asking-about-bpel_290.html

• The packaged/canned BPEL Console: Currently you can create users and roles via EM but these users will have full access to everything in the Bpel Console. It’s all or nothing.

• Using the read-only Bpel Console FilterList.txt we can restrict users to certain pages/JSPs which in turn reduces query activity in the database.

http://chintanblog.blogspot.com/2007/12/i-saw-numerous-people-asking-about-bpel_290.html

Oracle Apex and BAM

Oracle BAM (Business Activity Monitoring)

Oracle BAM enables you to build real-time operational dashboards and monitoring and alerting applications over the Web. Using this technology, you build interactive, real-time dashboards and proactive alerts to monitor business services and processes.

• We tested BAM but never went live due to license and server issues. At that time BAM ran on a Windows platform.• With BAM you can gather real-time statistical data by incorporating sensors into your processes.• Sensors

– Activity sensors: Activity sensors are used to monitor the execution of activities within a BPEL process. For example, they can be used to monitor the execution time of an invoke activity or how long it takes to complete a scope. Along with the activity sensor, you can also monitor variables of the activity.

– Variable sensors: Variable sensors are used to monitor variables (or parts of a variable) of a BPEL process. For example, variable sensors can be used to monitor the input and output data of a BPEL process.

– Fault sensors: Fault sensors are used to monitor BPEL faults.• After you define sensors for a BPEL process, you must configure sensor actions to publish the data of the sensors to an endpoint.

You can publish sensor data to the BPEL reports schema, which is located in the BPEL dehydration store, to a JMS queue or topic, or to a custom Java class.

• From BAM create data objects. These data objects reflect the business data that is captured in BAM for presentation, analysis, alerts etc. Data objects can also contain calculated or look up fields.

• In Oracle BAM’s Active Studio you develop the dashboards.

From Oracle® Business Activity Monitoring (Oracle BAM). See the Source section for more information.

Oracle Apex and BAM

Oracle Apex and BAM

Oracle Apex

The use of Oracle Apex provides a dashboard into the Bpel instance/processes trends.• In the absence of Oracle BAM we started using Oracle Apex for reporting (no licensing fee, comes with the

database 10g and up).• We collect runtime data every 2.5 minutes and on an hourly basis and house this information in reporting tables.• Provide both concurrent and historical reports, data trends, through put and timings.

Oracle Apex and BAM

Oracle Apex and BAM

Create your own console• Leverage the Bpel Java APIs.• We use Oracle Apex for a number of management administration tasks.

Hints

Due to the increased instance volume we’ve made some adjustments to our environments at all levels for stability purposes. Although a few of the following points have no direct impact on the Data store I thought it would be wise to list them just the same. You’ll need to research and test to see if any of these tips will help improve your performance.

Database• Unreleased Database Row Locks in orabpel User Table cube_instance and/or cube_scope.

Doc ID: 818633.1 – Increase Intrans for both tables and indices. • Under heavy load several threads will lock these tables for update which will cause contention. Concurrent DMLs

can cause block contention that will relieved by increasing initrans for the listed tables and indices.• Set session_cached_cursors to 300.

The session_cached_cursors specifies the number of session cursors to cache. Helps with hard parse vs. soft parse.

• Set db_file_multiblock_read_count to 8.The db_file_multiblock_read_count helps minimize I/O during table scans.

• Set pga_aggregate_target to 3.8G.The pga_aggregate_target sets the target aggregate PGA (program global area) memory.

• Set sga_target to 12.4G.The sga_target reflects the total size of the SGA (system global area).

Hints

• HW-Segment High Water Mark - Enq:HW – Contention with LOB Segments (Bug 6376915,). The HW High Water enqueue (a.k.a. enq: HW – contention) occurs when competing processing are inserting into the same table and are trying to increase the high water mark of a table simultaneously.Doc ID: 846562.1

– Also review Sean Carey’s blog that deals with moving specific table’s lob columns to a non-assm tablespace:

http://scsoablog.blogspot.com/2008/02/more-hw-contention-tuning.html

• Reduce the max-connections for the BPELPM_CONNECTION_POOL in the data-sources.xml. Performance can improve when the connection pool associated with a data source limits the number of connections. The max-connections attribute can be set to limit the database requests from Oracle Application Server to the database so that incoming requests do not saturate the database, causing contention and high CPU.

In versions prior to 10.1.3.3, it was recommended that the connection pool size must be greater than or equal to the dspMaxThreads property and in case of multiple domains it should be the sum of dspMaxThreads for all domains. In versions 10.1.3.3 and higher we usually set the max-connections to be equal to or greater than the higher of dspEngineThreads or dspInvokeThreads. But at the same time, you have to take into account hardware resource utilization and limit the total number of open database connections to a number that your database can handle and that is also an important consideration. So, both of these guidelines need to be considered collectively.

• Statistics gathering. We gather nightly.

http://scsoablog.blogspot.com/2008/02/more-hw-contention-tuning.html

Hints

Bpel• Viewing BLOBs using the Java APIs: http://forums.oracle.com/forums/thread.jspa?threadID=972210&tstart=45• ORA-02049 and Locks on DLV_SUBSCRIPTION Table After Applying Patch 8342907 [ID 1071069.1]: Patch

9041454• Bpel Throttle

Quartz job queries the dehydration database for the count of specific running processes/queue subscribers. Pushes results to a temp table local to the AQ. Dequeuing condition in the AQ adapter checks local table and dequeues if a certain condition is TRUE. For example, if only 2 processes are running but can have up to 10 running concurrently dequeue 8 more.

http://forums.oracle.com/forums/thread.jspa?threadID=972210&tstart=45

Hints

Application Server• Manage the dspEngineThreads and dspInvokeThreads. High thread counts cause greater CPU utilization due to

higher context switching costs.• Launch parallel threads to perform garbage collection. This will help improve garbage collection performance,

improving overall BPM performance. This can be done by adding the -XX:-UseParallelGC java start-parameters under process-type id "oc4j_soa".

• Set the -ms and -mx and the same value (1024m) for the process-type id "home". Dynamically growing and shrinking the heap impacts performance (and consumes valuable resources in the process) and so if you have the available memory on the server then it is always recommended to set the min and max to the same value to avoid dynamically growing and shrinking the heap.

• Increase the Java heap size from 2GB to 4GB and set the young generation heap (Eden space) to approx 60% of the total heap size. Need to be using 64 bit.

• Set the –Xmx and –Xms parameters to 4096 and –Xmn parameter to 2560. Need to be using 64 bit.• Keeping only one older version of a process. Quicker load times after a bounce.• Rotation of opmn logs: http://kaukovuo.blogspot.com/2006_02_01_archive.html• Provide access to opmn logs via Web-Dav.• Showing the server/Host Name on the BPEL Console in a clustered environment.

http://kaukovuo.blogspot.com/2006_02_01_archive.html

Sources

Sources• Oracle® Application Documentation Library 10g Release 3 (10.1.3.1.0):

http://download.oracle.com/docs/cd/B31017_01/index.htm• Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0):• http://download.oracle.com/docs/cd/B31017_01/core.1013/b28942/tuning_bpel.htm• Oracle® Business Process Management: http://www.oracle.com/technology/products/soa/bpmsuite/index.html• Oracle® BPEL Process Manager Client Java API Reference 10g Release 3 (10.1.3.1.0):• http://download.oracle.com/docs/cd/B31017_01/integrate.1013/b28986/overview-summary.html• Oracle® BPEL Process Manager Administrator’s Guide:

http://www.oracle.com/technology/products/ias/bpel/documents/bpel_admin_10.1.3.1.0.pdf• Oracle® BPEL Process Manager Developer's Guide:

http://download.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/sensors.htm• Oracle® Business Activity Monitoring (Oracle BAM):

http://www.oracle.com/technology/products/integration/bam/index.html• Oracle® BPEL Process Manager 10g Database Schema Partitioning:• http://www.oracle.com/technology/products/soa/bpel/collateral/bpel10gpartitioning.pdf• Oracle® Application Express (Oracle APEX):

http://www.oracle.com/technology/products/database/application_express/index.html

http://download.oracle.com/docs/cd/B31017_01/index.htm

http://download.oracle.com/docs/cd/B31017_01/core.1013/b28942/tuning_bpel.htm

http://www.oracle.com/technology/products/soa/bpmsuite/index.html

http://download.oracle.com/docs/cd/B31017_01/integrate.1013/b28986/overview-summary.html

http://www.oracle.com/technology/products/ias/bpel/documents/bpel_admin_10.1.3.1.0.pdf

Sources

• Oracle Support (Metalink): – Main Tables Used by the BPEL Engine– Description of the STATE values for tables in the BPEL dehydration store– Unreleased Database Row Locks in orabpel User Table cube– BPEL dehydration and tablespace growth

• Managing a BPEL Production Environment: http://www.oracle.com/technology/pub/articles/bpel_cookbook/blanvalet.html

• Antony Reynolds’ Blog: http://blogs.oracle.com/reynolds/• SOA Best Practices: The BPEL Cookbook:

http://www.oracle.com/technology/pub/articles/bpel_cookbook/index.html• James Lewis Blog: http://jameslewisblog.blogspot.com/• Anirich Pucha’s SOA Solutions: http://puchaanirudh.blogspot.com/• Clemens Utschig-Utschig Blog: http://blogs.oracle.com/soabpm/• Chintan Shah’s Blog: http://chintanblog.blogspot.com/• http://apps2fusion.com/apps/soa/bpel/280-oracle-bpel-tables-workflow• Matt’s SOA Blog: http://blogs.bpel-people.com/• Natalka Roshak “What’s blocking my lock?”: http://www.orafaq.com/node/854• Peeyush Tugnawat’s Blog: http://blogs.oracle.com/pt/• Harri Kaukovou’s Blog: http://kaukovuo.blogspot.com/• Sean Carey’s SOA Blog: http://scsoablog.blogspot.com/

markovich_presentation

Documents

oracle database

oracle bpel process

specific bpel process

bpel instances

oracle soa oracle forms

dehydration store database

process execution

oracle apex reports