Building the Profile Parameter
Note: Allow us to help you!
If you are considering using this feature, feel free to open a OSSmessage to the BC-DB-DB4 queue and we'll work with you to build anappropriate monitoring string.
The table(s) that need to be coordinated by must be specified viaprofile parameter in:
The profile parameter has the following format:
Where: <(><<)>TableName<(>><)> is the name of the table or view to be
monitored for coordination. <(><<)>TableName<(>><)> can containwildcards ? and
*. Where ? matches any ONE single character, and * matches many. LeTeRcAsE iS iGnOrEd.
Where: <(><<)>LockGroup<(>><)> is an arbitrary name that specifies the
name of the lock. Multiple tables or views that resolve to the same<(><<)>LockGroup<(>><)> are coordinated together.
<(><<)>LockGroup<(>><)> can contain variables %n that correspond to therespective wildcard in <(><<)>TableName<(>><)>.
Would coordinate all of "MY" tables as one group, and all of "YOUR"tables as another.
Would coordinate all tables on the system, using a
<(><<)>LockGroup<(>><)> equal to the first character of every table. Sotables SFLIGHT and SVERS would both resolve to Lock_S.Table Views complicate the specification. Because the LIB_DBSL only"sees" SQL Text, views that reference "coordinated tables" must alsobe listed in the profile parameter.
Would put all tables and views that start with the same prefix and thatend either on TABLE or on VIEW into the same lock group. So MYAPPTABLEand MYAPPVIEW are coordinated together because they have a lock name ofLOCK_MYAPP.
When active, the developer trace shows (for example):
C parallel_alter_tables = LOCK_%0=*TABLE C = LOCK_%0=*VIEW
Limitation for db