9 Performance Tuning

This chapter provides information about the relationship management performance tuning. The relationship management application project automatically creates the default Oracle database table spaces, database indexes, and Oracle TopLink cache configuration. The settings service as base for you to tune the relationship management application based on the actual resources and environments.

9.1 Oracle Database Tuning

For more information on how to manage and tune database tablespaces, see Managing Tablespaces of Oracle Database 12c Administrator's Guide.

9.1.1 Managing the Relationship Management Database Tablespaces

The RM project automatically creates the default three tablespaces with the following settings:

SMALLFILE tablespace
Datafile is created at $ORACLE_HOME
Tablespace size is 100M and is auto extendable

The OHMPI_RM tablespace is created for all the relationship management database tables. The OHMPI_RM_TEMP tablespace is created for the temporary database tables. The OHMPI_RM_AUDIT tablespace is created for the audit database tables.

To customize these settings according to the actual requirements and platforms, modify the create-ohmpi-rm.sql or create-ohmpi-rm-audit.sql script directly using a text editor.

9.1.2 Creating a BIGFILE Tablespace

Modify the table creation statement by specifying the BIGFILE keyword. For example:

CREATE BIGFILE TABLESPACE OHMPI_RM
DATAFILE 'OHMPI_RM.DBF'
SIZE 100M REUSE
AUTOEXTEND ON;

9.1.3 Storing the DATAFILE on Different Storage Location

Modify the tablespace creation statement by specifying different DATAFILE path. For example:

For Linux:

CREATE TABLESPACE OHMPI_RM
DATAFILE '/users/tablespace/OHMPI_RM.DBF'
SIZE 100M REUSE
AUTOEXTEND ON;

For Windows:

CREATE TABLESPACE OHMPI_RM
DATAFILE 'C:\users\tablespace\OHMPI_RM.DBF'
SIZE 100M REUSE
AUTOEXTEND ON;

9.1.4 Increasing the Default Initial Tablespace Size

Modify the tablespace creation statement by changing the default initial size of the tablespace. For example:

CREATE TABLESPACE OHMPI_RM
DATAFILE 'OHMPI_RM.DBF'
SIZE 200M REUSE
AUTOEXTEND ON;

9.1.5 Managing the Relationship Management Database Indexes

The RM project automatically creates the database script for creating default database indexes and constraints on all the RM database tables to provide faster access to data for operations. You can create application-specific indexes based on the business use cases by modifying the create-ohmpi-rm.sql script. For more information, see Using Indexes in Database Applications of Oracle Database 12c Advanced Application Developer's Guide.

The RM project also creates the default database text indexes. The text indexes are only enabled for customer-defined attributes of entity type and relationship type. By default, the text index is disabled. To enable the text index:

Define the user-defined attribute of entity type or relationship type indexable using the RM data manager or the RM metadata REST APIs.
Set relationship.management.text.index property to true in ohmpi_rm.properties.
Rebuild and redeploy the RM application.

For information on how to build and deploy the RM application, see Chapter 2, "Creating the Relationship Management Project".

For information on text index, see Text Application Developer's Guide of Oracle Database 12c.

9.1.6 Managing the Relationship Management Database Partition

The database partitioning enhances the performance, manageability, and availability of the RM applications. Partitioning is entirely transparent to the application. Partitioned tables are identical to non-partitioned tables in perspective of the SQL queries and the DML statements. The RM follows the generic Oracle Database partitioning best practice and rules. For example, partition a table when:

Tables which are greater than 2 GB should always be considered as candidates for partitioning.
Tables containing historical data, in which new data is added into the newest partition. For example, a historical table where you can only update the current month's data and the other 11 months are read only.

The supported partitioning strategies include Range partitioning, Hash partitioning, List partitioning, Range-Range composite partitioning, and Range-Hash composite partitioning.

Partitioning is use cases and data related. You must analyze and understand the data and the use cases as well to determine what partitioning strategies are used. Generally, you can use the hash partitioning for the RM_ENITITY table to distribute the entity rows among partitions by the ENTITY_TYPE_ID partitioning key.

You can use the hash partitioning and range partitioning for the RM_RELATIONSHIP table. RELATIONSHIP_TYPE_ID is the candidate partitioning key for the hash partitioning or composite partitioning to distribute relationships rows in its own partitions. Based on the search criteria of the use cases, CREATED_DATE, MODIFIED_DATE, EXPIRATION_DATE, and EFFECTIVE_DATE are the candidate partitioning keys for the date range partitioning or composite partitioning. The date range partitioning can be by months or by weeks based on the data.

For more information, see Partitioning Guide of Oracle Database 12c.

9.2 Oracle TopLink JPA Tuning

The RM project creates the default JPA tuning parameters in persistence.xml. By default,

Session cache is enabled.

<property name="eclipselink.cache.size.default" value="5000"/>

Maximum number cached objects are set to 5000.

<property name="eclipselink.cache.shared.default" value="true"/>

You can add more JPA performance tuning parameters in persistence.xml, and then redeploy the RM application.

For more information, see Oracle TopLink (EclipseLink) JPA Performance Tuning.

9.3 Oracle WebLogic Server Tuning

The RM application is Java EE standard-based and execute in the WebLogic server. The RM application also supports clustering. The tuning techniques of the WebLogic application are applicable to the RM application, such as:

Tune pool sizes
Use the prepared statement cache
Use logging last resource optimization
Tune connection backlog buffering
Tune the chunk size
Use optimistic or read-only concurrency
Use local interfaces
Use eager-relationship-caching
Tune HTTP sessions
Tune messaging applications

For more information, see Performance Tuning for WebLogic Server 12c.