Using partitioning rules

Partitioning rules can also reduce contention, but require a clear understanding of your transaction profile.


The transaction name rule

Do transactions have transaction names? Is the contention caused by transactions with the same name? Try setting the transaction name rule, which forces transactions with the same name to be sent to the replicate one-by-one.

If transactions are not named, you could change the application so that names are added. Then use the name rule to serialize only specified transactions. Suppose a particular type of large transaction always causes problems if the DSI executor threads attempt to process two or more in parallel. By giving the problem transactions the same name, and applying the name rule, you can ensure that the problem transactions are processed serially. Remember, however, that the name rule is applied to all transactions, and all transactions with the same name will be processed serially.


The user name rule

Setting the user name rule may help reduce contentions caused by transactions processed in parallel from the same user ID. Like the transaction name rule, the user name rule, if set, is applied to all transactions, and every transaction from the same user ID will be processed serially.


The origin begin and commit times rule

The time rule forces serial execution of transactions with nonoverlapping commit/begin times. That is, if the commit time of the first transaction comes before the begin time of the next transaction, these two transactions must execute serially.


Combining partition rules

You can combine rules. The first rule to be satisfied takes precedence. Thus, if, for example, the origin_sessid, time rule is specified, two transactions with the same origin session ID will be forced to run serially, and the time rule is not applied.