At times the Post process on target may be slow and a question may arise as to whether Shareplex is using the key (primary, other unique constraint, or other index).
Shareplex will tend to use the key if defined on the source table when the source table is activated, based on certain factors. Its order of preference is:
Primary key
Unique key
unique index
Or
In the absence of any of these, all column values are concatenated to form a key.
To find out what is currently defined as the key on a replicating table, you can dump the object cache from the source or target /$SP_SYS_VARDIR/state directory. The procedure is explained in SOL1771. The object cache file is the Shareplex's representation of the table structure and it usually corresponds to the structure as defined in Oracle. The object cache file of the latest activation has the most current definition of the table. It is identical on source and target state directory. It is a binary file and can only be read if it is dumped with the help of the utility dumpfile, hence the need for the elaborate procedure described in SOL1771. If the primary key has been changed on source table since last activation, then the change will not be propagated to the object cache since this DDL does not get replicated. So for the object cache to reflect the change, you have to activate a copy of the currently active config again. The following is a sample dump of the object cache that shows what Shareplex considers are the keys for a replicating table:
Source's dumped object cache:
ObjectID:3390
Table_Name :"USER_USER"."XYZ_USER_PAGES_TEXT"
#Column:4 #Keys: 2 Key Type:PRIMARY_KEY Status Flag:1 VP=0
--------------------------------------------------------------------------------
ColumnRecStructure Info. Number of Column= 4
Col |Length| Type |Name |Rep?|Key?|Null?|DefLen
1 22 OAT_NUMBER USER_ID Y K N 0
2 22 OAT_NUMBER PAGE_NUMBER Y K N 0
3 0 OAT_LONGRAW DATA_DICT N N 0
4 22 OAT_NUMBER UTF8_STATUS N Y 0
In the above example the fields USER_ID and PAGE_NUMBER together form a key for the table and this is reflected by a value 'Y' under the field 'Key?' for this table.
A point to be noted is that despite the key defined for the table, there may be other reasons preventing the Post process from using the key. That topic is beyond the scope of this solution.
