主题: Guidelines for Shutting Down TimesTen DataStores and Applications
文档 ID: NOTE:740819.1 类型: HOWTO
上次修订日期: 12-NOV-2008 状态: PUBLISHED
In this Document
TimesTen Data Server - Version: 5.0.0 to 126.96.36.199.0
Information in this document applies to any platform.
TimesTen IMDB, TimesTen Cache Connect to Oracle, TimesTen Replication
This document identifies the proper way to shutdown applications connected to the TimesTen In Memory Database and identifies hazards associated with improper shutdowns.
The TimesTen main daemon is different from and distinct from an active TimesTen application. The TimesTen main daemon is the master process for an instance of TimesTen and it oversees the management of all data stores mapped to the given TimesTen instance. The main daemon is responsible for handling new connection requests from applications and either re-directing them to the correct address if the data store is loaded into shared memory or allocating a subdaemon to load and manage the data store if it is not already loaded into shared memory.
A TimesTen instance will therefore contain 1 main daemon, and
An instance may contain any number of data stores and may support any number of applications. For the purpose of this Note, we will define an "application" as a single data store allocated in one shared memory segment, various client application processes which execute queries and transactions on the data in that shared memory segment, the subdaemon which supports data store administrative processing including checkpointing, log flushing, aging, etc., on that shared memory segment, and optionally additional subdaemons called "agents" if Cache Connect to Oracle and/or Replication are enabled. Client application processes may be connected to the shared memory segment remotely using TCP/IP or may be directly linked with the TimesTen libraries in which case they attach directly to the data store shared memory segment. Obviously, a TimesTen application may be designed to include multiple data stores with different sets of client application processes communicating with each data store; however for the purposes of this discussion, we will consider an application to be the set of all client application, subdaemon processes and agents acting against a single data store.
Stopping the primary TimesTen daemon and shutting down an active TimesTen application are not the same thing: they are very different.
Stopping the TimesTen daemon (especially when using the "-force" option) is a potentially impacting action: stopping the TimesTen daemon will stop all activity on all active data stores mapped to that specific instance, and will not simply stop a single application or a single data store. When a "ttDaemonAdmin -stop" command is encountered, the following actions occur:
The main daemon receives the "stop" request and passes it in turn to all of its direct child processes (subdaemons, replication and cache agents, ttcserver, webserver etc.).
Each child process receiving the "stop" command then does what is neccessary to halt itself.
The main daemon waits for a certain period (120 seconds in TimesTen Version7) in order for all child processes to complete their shutdown activities.
If after 120 seconds, not all processes have shut down, then the main daemon will go ahead & invalidate all connected data stores, kill -9 all subprocesses, and exit.
This creates potential problems if data store applications are active when the "stop" request is submitted. If the subdaemon processes do not have time to perform. all necessary housekeeping, rolling back incomplete transactions and cleaning up dropped connections, etc., and a blocking checkpoint cannot be completed before the 120-second timeout period, then the data store will be invalidated and recovery will be neccessary when the instance is restarted.
The following protocol should be followed in order to shutdown an active TimesTen application:
Shutdown all application connections gracefully using the application interface. Users may consider embedding signal handling in their application code in order that the application code respond to a predefined "shutdown signal" from a client control routine. This would enable graceful transaction rollback, memory deallocation and other shutdown housekeeping. Demo program "util.c" includes examples of signal-handling for application-level termination.
Shutdown replication and cache agents. This can be done from ttisql using the 'ttCacheStop' and 'ttRepStop' commands or from the command line using the "-RepStop" and "-CacheStop" arguments of the ttAdmin command.
Unload the data store:
If the data store RamPolicy is "inuse" then the shared memory segment will be automatically unloaded when all connections to the segment have been released.
If the RamPolicy is "manual", the shared memory segment must be manually removed using the "-ramUnload" command of ttAdmin. This should be executed only after it has been ascertained that all application and subdaemon connections to the segment have been released.
If ramPolicy is "always", then unloading the shared memory segment first requires that the ramPolicy itself be changed to "inuse" or "manual" in order to unload it from shared memory.
Stop the TimesTen main daemon using "ttDaemonAdmin -stop"
Note that the TimesTen Version7 Operations Guide (pp70-71) identifies scripts named tt_
Documentation enhancement request #7142952 has been filed in order to more clearly distinguish between stopping the primary TimesTen daemon and shutting down a TimesTen application. The requested documentation changes will be implemented in TimesTen release 11gR2.
Help us improve our service. Please email us your comments for this document. .
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/418/viewspace-514311/，如需转载，请注明出处，否则将追究法律责任。