Tuning Oracle Business Activity Monitoring 12c

3.1 Tuning Schema Design

Oracle BAM 12c supports a star schema. It supports joins through Logical Data Objects (LDOs). An LDO allows you to join one FACT table with multiple DIM or Dimension tables, which allows you to run queries on top of the LDO.

If Active Data is used on top of an LDO with Archived Relation, some considerations need to be taken into account to achieve the best performance. These conditions are outlined as follows. Please note that these are best practices to help enhance your performance when you switch to 12c and must be treated as recommendations.

Oracle recommends that you mark your DIM table as ‘Slow Changing Dim’ if the changes to the DIM table are infrequent (once in a day or so). When you mark it with ‘slow-changing dim’, a join-memory enhancement comes into play that reduces the amount of heap required and also increases the query start up time.
Oracle recommends that you keep the DIM table size reasonable (for example, less than 10k – only used for look up) and batch updates to DIM tables to avoid frequent updates so you can mark the DIM table as ‘Slow Changing Dim’. In the case where the dim table is growing at the same pace as the fact table, it is better to keep the dimension columns in the FACT table.
Oracle recommends that you only join the FACT table with required DIMs as multiple DIMS requires complex n joins. Consolidate DIM tables to reduce number of joins.
Oracle recommends that you design an LDO with filters to reduce the amount of data returned. This reduces the TEMP tablespace required to run the archiver query.
Oracle recommends that you use Calculated Fields in your query to reduce the number of columns required in the FACT DO. Keep only what’s required as columns in the FACT table. This will help Active and CQL template queries to be more efficient as they do not need to bring additional columns into memory.
If you are using 11g Oracle DB, Oracle recommends that you use Secure Files to improve performance. See Using Secure Files for more information.
Oracle recommends that you create indexes for key fields. You can use the BAM Data Object to create indexes. See Selecting an Index Strategy for more information.

3.2 Tuning Dashboard Design and Deployment

Oracle Business Activity Monitoring 12c comes with enhanced Dashboard capabilities for optimal performance.

The following best practices are recommendations too ensure optimal performance. For optimal dashboard performance, please treat the following best practices as recommendations.

Ensure that a dashboard is designed for a specific user group. Do not try to create an all-purpose dashboard.
Create a report which is “management by exception”.
Allow the people handling various user roles to understand the health of the operations at a glance; then provide drill-down.
Use the Logical Data Object filter and dashboard parameters to filter data before dashboard is loaded.
Limit a dashboard to 4-6 views or one view with multiple tabs.
Make effective use of Dashboard Action button present in each Dashboard cell.

Use summary or aggregation as much as possible and provide drill down to detail records from there to avoid many detail records.
Table and list views have some performance limitations. Oracle recommends that you limit List View listings to 2000 records, although the Oracle BAM system has an upper limit of 10420 records. If applicable, define a dimension or time hierarchy which allows drill down until you reach the node that returns detailed records. Also ensure that you increase the memory settings (Oracle recommends up to 6GB) for the BAM server while retrieving many records.
Use Oracle Tech Network demos for design and best practices.
Choose active data interval and throttling carefully because it has memory implications.

3.3 Tuning Query Design

Active and non-active queries are subject to best practices in Oracle BAM 12c.

For optimal performance of your business queries, Oracle recommends the following best practices.

For tactical (non-active), queries, examine the query string generated by the business query and run the DB AWR report to tune the index or change your query to improve performance.
For an active query, always specify a window size (range) because these reduce amount of memory required. Also, use the output window (sliding) judiciously to collapse results and to not overwhelm the dashboards.
Use the aggregation query and bind it to a chart. Then perform drill down to detail records. This organizes the data into smaller chunks and improves performance.
Test your query with your production data set to ensure that the performance is reasonable.
Familiarize yourself with the differences between scheduled query and real time active query and use them as appropriate.

3.4 Tuning Data Archiving and Purging

Oracle BAM 12c recommends some best practices for archiving and purging data for optimal performance.

Keep only the necessary data in your Data Object. Any data that is relevant for operational monitoring and taking actions is a candidate for data object storage.
Do not keep older data for historical purposes in the same data object. If you need the historical data to be available, transfer the data to another data object that is used for specific reporting.
Schedule the Data Retention at non-peak hours using alerts. You can shut down all BAM Viewsets and Continuous Queries if you’re an administrator during this task as they hold state in memory.
If it is a requirement to archive the data prior to purging, then use an Oracle Data Integrator service with BAM 12c.
Use alerts to control filter-based purging. Custom actions can also be provided to the alert to perform more customized purging.
Use the Database Partition capability to improve performance if purging and data injections are happening concurrently. For more information, see Partitioning Concepts in the Oracle Database VLDB and Partitioning Guide.

3.5 Tuning Scalability and Performance

Oracle BAM 12c recommends some best practices for optimal performance and scalability.

Oracle BAM 12c is designed for High Availability and Scalability. High Availability and Scalability can be increased by adding additional servers. Additional servers increase High Availability by providing healthier servers to failover to in the event one server fails. As long as one BAM server is running, BAM will continue to function. Additional servers provide greater throughput as work is load-balanced across all available servers in the BAM cluster. For more information, see the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.
For input scalability, multiple EMS can be started on different servers to improve throughput.
Customers should consider using batching capabilities to improve performance. See Batching Operations to Group Multiple Events Into a Single Operation for more information.
CQL queries are load balanced using project as a base. All queries for a given project would reside on the same server. When a server crashes, CQL queries are moved onto a different server.
Limit the number of CQL queries as they tend to require large quantities of heap memory.
Ensure that Oracle BAM is in its own cluster of dedicated machines. If the solution includes BPEL or BPM, use separate machines for BPEL and its storage to avoid contention.
For High Availability solutions, make sure that your servers are on the same network.
Ensure that the application context is the same for Oracle BAM Web Services if the web service interface is used for pushing data into BAM.
Tune the database completely, including adding indexes, partition table by day, parallel execution, and use DBIM (Database In-Memory). DBIM accelerates access to the data because only the required columns (columnar storage) are visited. In addition, for cases where filtering occurs but the filter is not selective, DBIM is a little like having an index per column. For the queries that perform simple aggregations, DBIM can also accelerate aggregation.

3.6 Real-Time Data Sources for Oracle BAM

Oracle BAM provides real-time data sources that you can use in the Oracle WebLogic Server (WLS).

These data sources are as follows.

Oracle BAM Adapter
Oracle Web Services
Java Message Service
Oracle® Data Integrator
Enterprise Java Beans

3.7 Tuning Production Roll-out

Oracle recommends that you use the suggested configuration and load testing checklist before production.

The checklist outlines some configurations and load testing.

Ensure that your Java Messaging Service and Automatic Service Management configuration is in accordance with the Oracle Enterprise Deployment Guide.

Description of the illustration jms-server.gif
Ensure that the load balancer configuration is correct. Set the correct values for WebLogic Plug-In Enabled. Select Yes if the cluster receives requests from a proxy plug-in or HttpClusterServlet. A call to getRemoteAddr returns the address of the browser client from the proprietary WL-Proxy-Client-IP header, instead of the Web server. Select No to disable the weblogic-plugin-enabled parameter (weblogic-plugin-enabled=false) in the config.xml file. Select Inherit for this cluster to inherit the value selected for WebLogic Plug-In Enabled for the domain.
Check the persistence configuration on Enterprise Messaging Service (EMS). Too many threads may cause contention. Too few may reduce throughput. Oracle recommends that you start with 20 threads and tune it based on the throughput.
Check that your Application Roles are defined correctly.
Check that the JVM Parameters have been tuned properly. For more information, see the Oracle Fusion Middleware Tuning Performance of Oracle WebLogic Server guide.
Ensure that your dashboards display correctly with high production loads on different devices.

Load Testing

Use the following pointers for load testing.

Use Oracle Enterprise Single Sign-on Logon Manager to simulate users coming on board. To do this, use the following test as a ballpark:
- Start 20 virtual users in the frequency of 2 users every 30 seconds and run this for 20 minutes.
- Next, stop all virtual users in the frequency of two users every five seconds.
- Monitor this activity using the Viewset Monitoring capability.
Use EMS clients to pump data into the system. Start multiple EMS Servers. Ensure that each EMS Server is deployed to different managed servers.
Monitor throughput. Use the BAM Business Query by creating a time series on the x-axis based on the Data Object creation date column.
If you use the Java VisualVM tool, you can monitor the Heap, Memory, and CPU Usage.
Using the Automatic Workload Repository reports, check to see if there are dead locks. Also check the SQL execution time and determine if you need to create or modify indexes.
Run a Longevity Test. Run your system for a minimum of five days with EMS. Subject the system to continuous load, purge every day, and ensure that virtual users come and go.
Upon failover, bring down one server, monitor the performance, and once all performance issues are detected and fixed, bring the server back up. Manually, migrate services back to the server upon restart.