1. Cache Guide
  2. Cache Performance
  3. Improving AWT Throughput
  4. Improving AWT Throughput with Parallel Propagation to the Oracle Database
  5. Manually Initiate Check for Missing Constraints for an AWT Cache Group

Manually Initiate Check for Missing Constraints for an AWT Cache Group

The ttCacheCheck built-in procedure performs the same check for missing constraints for cached tables on the Oracle database as performed automatically by TimesTen.

The ttCacheCheck provides appropriate messages about missing constraints and the tables marked for serialized propagation. With the ttCacheCheck built-in procedure, you can check for missing constraints for a given cache group or for all cache groups in TimesTen to ensure that all cache groups are not missing constraints.

Note:

Since ttCacheCheck updates system tables to indicate if DML performed against a table should or should not be serialized, you must commit or roll back after the ttCacheCheck built-in completes.

See ttCacheCheck in the Oracle TimesTen In-Memory Database Reference.

You may need to manually call the ttCacheCheck built-in procedure to update the known dependencies after any of the following scenarios:

  • After dropping a series of AWT cache groups on TimesTen with the DROP CACHE GROUP statement.

  • After adding or dropping a unique index, unique constraint, or foreign key on an Oracle Database table that is cached in an AWT cache group. If you do not call the ttCacheCheck built-in procedure after adding a constraint, you may receive a run time error on the AWT cache group. After dropping a constraint, TimesTen may serialize transactions even if it is not necessary. Calling the ttCacheCheck built-in procedure verifies whether serialization is necessary.

  • You can use this built-in procedure to determine why some transactions are being serialized.

Note:

The ttCacheCheck built-in procedure cannot be called while the replication agent is running.

If a DDL statement is being performed on an AWT cache group when ttCacheCheck is called, then ttCacheCheck waits for the statement to complete or until the timeout period is reached.

If you have not defined the CacheAwtParallelism data store attribute to greater than one or the specified cache group is not an AWT cache group, then the ttCacheCheck built-in procedure returns an empty result set.

The following example shows the user manually running the ttCacheCheck built-in procedure to determine if there are any missing constraints for an AWT cache group update_orders that is owned by cacheadmin. A result set is returned that includes the error message. The ordertab table in the update_orders cache group is marked for serially propagated transactions. 

Command> call ttCacheCheck(NULL, 'cacheadmin', 'update_orders');

< CACHEADMIN, UPDATE_ORDERS, CACHEADMIN, ORDERTAB, Foreign Key, CACHEADMIN, 
CUST_FK, 1, Transactions updating this table will be serialized to Oracle
because: The missing foreign key connects two AWT cache groups., 
table CACHEADMIN.ORDERTAB constraint CACHEADMIN.CUST_FK foreign key(CUSTID) 
references CACHEADMIN.ACTIVE_CUSTOMER(CUSTID) >
1 row found.

Whenever the cache group schema changes in either the TimesTen or Oracle databases, you can call ttCacheCheck against all AWT cache groups to verify all constraints. The following example shows the user manually running the ttCacheCheck built-in procedure to determine if there are any missing constraints for any AWT cache group in the entire TimesTen database by providing a NULL value for all input parameters. A result set is returned that includes any error messages. 

Command> call ttCacheCheck(NULL, NULL, NULL);

< CACHEADMIN, UPDATE_ORDERS, CACHEADMIN, ORDERTAB, Foreign Key, CACHEADMIN, 
CUST_FK, 1, Transactions updating this table will be serialized to Oracle
because: The missing foreign key connects two AWT cache groups., 
table CACHEADMIN.ORDERTAB constraint CACHEADMIN.CUST_FK foreign key(CUSTID) 
references CACHEADMIN.ACTIVE_CUSTOMER(CUSTID) >
1 row found.