A general approach for Stardust database access tuning consists of the following tasks:
First, you have to identify
The appropriate means for this task in general are database specific tools. Additionally, you may set the Stardust server property:
Carnot.Engine.Tuning.DB.slowStatementTracingThreshold = 500.
This property sets the threshold duration in milliseconds for all database statements launched by Stardust . If the threshold is exceeded, the corresponding statement is logged in the Stardust log. with WARN priority, e.g.
[06.12.05 12:01:53:443] [ORB.thread.pool : 4] [ WARN] Slow query: 1085ms SELECT COUNT(*) FROM activity_instance o INNER JOIN process_instance PR_PI ON (o.processInstance = PR_PI.oid) INNER JOIN data_value PR_DV1 ON (PR_PI.rootProcessInstance = PR_DV1.processInstance AND PR_DV1.data = ?) INNER JOIN ikr_dcluster_1 PR_DVCL1 ON (PR_PI.rootProcessInstance =
PR_DVCL1.processInstance) WHERE (o.state IN (?, ?) AND (PR_DVCL1.tk_an_bereich_bs = ? AND PR_DVCL1.sval_an_bereich_bs IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)) AND (PR_DV1.type_key = ? AND PR_DV1.string_value = ?) AND (PR_DVCL1.tk_an_rolle = ? AND PR_DVCL1.sval_an_rolle = ?) AND (o.currentUserPerformer = ? OR o.currentPerformer = ?))
A useful approach is to identify categories of critical statements with:
<session-name>.UsePreparedStatements = true
and to then deactivate prepared statement to obtain the concrete parameter values for critical queries (data IDs, process OIDs).
Execution plans for critical queries are obtained with the tools provided by the DBMS in use. You may consult your database administrator for further details.
The obtained list of critical statements can be used in two ways:
(A) A statement with multiple joins on the DATA_VALUE table - especially if launched very often - is a good candidate for a cluster slot.
Data being used together in predicates
... WHERE ... Data1=? AND Data2=?
should reside in the same cluster.
Additionally, indexes on these clusters might be considered according to the following principles:
of the index definition.
(B) With or without clusters being defined, the execution path (table scans, index scans) has to be considered in detail and known database tuning mechanisms, like
on cluster and non-cluster tables have to be applied. To decide on the appropriate approach you have to obtain the UPDATE/SELECT ratio for the tables to be indexed. In any case, theses considerations are not Stardust -specific and can be recommended by your database administrator without further knowledge of the Stardust Process Engine.
The steps described below can be performed repeatedly with successively reducing the threshold for critical statements.
UPDATE-Deadlocks on data clusters caused by parallel access of two different threads on disjoint cluster slots can be avoided by splitting up the cluster. Critical clusters can be obtained from the fields listed in the corresponding log.
It might also be an approach to change the process model accordingly.
Deadlocks on other Stardust tables can be avoided by specifying additional indexes on these tables. This approach is also a standard database administration task and does not require specific knowledge of the Stardust products. Hence, you might consult your database administrator for further recommendations.
Per default, database generated keys are retrieved on non-sequence databases after the INSERT statement. To avoid this extra round trip, you can use the property AuditTrail.UseJdbcReturnGeneratedKeys. If you add this property to the carnot.properties file and set it to true, the support provided by JDBC 1.4 for retrieving database generated keys directly from the INSERT statement will be used instead.
An audit trail database containing data for a large number of processes may reach a size, where the scalability limits of the used database system are reached. Usually, a high percentage of the process instances, whose data are stored in the audit trail database are already terminated. Hence, these process data can be exported to off line data sources and access only on demand.
To increase performance, you have the option to remove process instance hierarchy entries upon process termination. If you set the server-side property Carnot.Engine.Tuning.ProcessTerminationHierarchyCleanup in your carnot.properties file to true, process instance hierarchy entries are removed from the table procinst_hierarchy upon process termination. Per default this property is set to false. For details on table procinst_hierarchy, refer to the PROCINST_HIERARCHY TABLE description in chapter The Repository Model.
To reduce the number of statements the database needs to parse and optimize you can use prepared statements. In general, any query that is meant to be used more than once should be a prepared statement.
Using Prepared SQL Statements is usually estimated to raise performance by about 10%, no additional action needed. This has to be considered of special importance for complex queries like the ones issued from the Query API implementation. Now all queries and updates on the audit trail honor the session property to use Prepared SQL Statements:
<session-name>.UsePreparedStatements = false/true/mixed
It is recommended to use the mixed mode. For example, if querying for process instances states and activity instance states, the data can be "unbalanced". Mostly there are a lot of completed and only a few non-completed states. Regarding the performance, in case such data occur, it is helpful for the database query analyzer and data access path builder to have the real values for these unbalanced data and additionally the prepared statements for general business data.
If prepared statements are used, the corresponding SQL queries will contain bound values like ? characters instead of concrete values.
Note that prepared statements are explicitly ignored for the following scenarios: