HOWTO : Gracefully Destroy A TimesTen Database Containing Cache Groups
Last updated on SEPTEMBER 23, 2016
Applies to:Oracle TimesTen In-Memory Database - Version 184.108.40.206.0 to 220.127.116.11.1 [Release 7.0 to 11.2]
Information in this document applies to any platform.
This document affects TimesTen data stores containing cache groups. It discusses the correct way to destroy such a data store.
***Checked for relevance on 07-Dec-2014***
It is not recommended to destroy a data store which contains existing cache groups. The 'ttDestroy' utility normally will not allow a customer to destroy a data store which contains existing cache groups, although this restriction can be overridden using the '-force' option of the ttDestroy command. It is also possible for customers to manually remove a data store by deleting all of the files relevant to that data store, but this is not recommended.
If the data store contains cache groups which are autorefreshed, then removing the datastore without first removing the cache group will have bad consequences for the Oracle database where the cache base tables reside. Failing to drop an autorefreshed cache group will cause the metadata in the oracle database to remain operational. In the case of autorefreshed cache groups, this means that triggers on the cache group base tables will remain enabled and that every DML operation on each base table will cause those triggers to fire and to add rows to cache group log tables. Under normal circumstances, each cache group refresh would cause these log tables to be purged and consequently these tables would remain of a manageable size. However, since the data store holding the cache group has been destroyed, refreshes are no longer happening and the log table will grow without bound. This is potentially very dangerous for the Oracle database. Additionally, if there are other cache groups from other data stores referencing the same tables, than the join operations required for each autorefresh will take increasing amounts of time as the amount of size of the log table increases: the possibility exists that the autorefresh will not complete in the time assigned to it. Even if the refreshes do complete in a timely fashion, the amount of CPU required for each refresh will increase.
Consequently, removing a data store having autorefreshed cache groups without first dropping those cache groups is potentially a very dangerous action.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms