Perform RAM Operations

Options

ttAdmin has these options to set the RAM policy, start the database and stop the database:

Option	Description
-connStr connection_string	An ODBC connection string that specifies a database location, driver, and optionally other connection attribute settings.
DSN	An ODBC data source name of the database to be administered.
-autoreload | -noautoreload	If set to -autoreload (default), TimesTen reloads the database after an invalidation. If set to -noautoreload, TimesTen does not automatically reload the database after an invalidation.
-ramGrace secs	Only effective if -ramPolicy is inUse. If nonzero, the database is kept in RAM for secs seconds before being unloaded after the last application disconnects from the database.
-ramLoad	Valid only when -ramPolicy is manual or enduring. Causes the database to be loaded into RAM. If there is an existing database shared memory segment -ramLoad destroys it before creating the new one. This enables -ramLoad to clean up if an error is returned by ttAdmin -shmAttach. The shared memory segment must be free first so that -ramLoad can destroy it.
-ramPolicy policy	Defines the policy used to determine when the database is loaded into system RAM. manual - Specifies that the database is only to be loaded in system RAM when explicitly loaded by the user with the -ramLoad option. Using -ramUnload with -ramPolicy manual to unload the database, causes the daemon to destroy any remanent detached shared memory segment from a previous in memory database. This is the recommended RAM policy because it avoids unnecessary database loading or unloading. enduring - This RAM policy is like the RAM policy manual, except that it also enables you to use the -shmDetach and -shmAttach options to respectively stop and restart the database without destroying the shared memory segment that contains the database. This feature enables you to perform a fast patch upgrade, as you can detach from the shared memory segment instead of unloading the database. Then after the upgrade, you can attach to this shared memory segment avoiding loading the database. The RAM policy enduring also enables you to use the -shmFree option. inUse (default) - Specifies that the database is loaded in system RAM only when in use (when applications are connected). The -ramGrace option may be used to modify the behavior of this policy. always - Specifies that the database should remain in system RAM all the time.
-ramUnload	Performs a clean shutdown of the database by disconnecting the subdaemon and destroying the shared memory segment. The checkpoint file written to disk allows you to reload the database using the ttAdmin -ramLoad option. The -ramUnload option is valid only with -ramPolicy manual or -ramPolicy enduring.
-shmAttach	Enables you to reattach to a preserved shared memory segment while starting the database. The prerequisites are setting the RAM policy to enduring and having the shared memory segment previously detached with the -shmDetach option.
-shmDetach [-ckpt | -noCkpt]	Enables you to stop the database by detaching (instead of destroying) the shared memory segment. Before disconnecting from the shared memory segment, you can specify the subdaemon to perform a static checkpoint with the –ckpt option (which is the default) or to not perform a static checkpoint with the –noCkpt option. To use -shmDetach, the database must be closed and there must be no connections to the database.
-shmFree	The -shmFree option destroys a preserved shared memory segment that remained in memory after a ttAdmin -shmDetach operation. If you use the -shmDetach option but decide you do not want to re-attach the segment, you can free the segment by using the -shmFree option. After doing so, you can still load the database from the checkpoint files using the -ramLoad option.

Note:

RAM policy enduring is helpful to perform fast patch upgrades, because you do not need to unload and reload the data which can be time-consuming. The -ramPolicy enduring enables you:

1. Use -shmDetach to preserve the shared memory segment while stopping the database.
2. Perform the fast upgrade.
3. Use -shmAttach to attach to the preserved memory segment while starting the database.

For more details, see Specifying a RAM Policy and Detaching, Attaching, and Freeing the Shared Memory Segment in the Oracle TimesTen In-Memory Database Operations Guide.

For more information About Performing a Fast Patch Upgrade see the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide.

Examples

To manually control whether database1 is loaded into RAM and to load it now, use the following:

% ttAdmin -ramPolicy manual -ramLoad database1

The database1 database is typically always resident in RAM. However, it is not being used at a given time and should be loaded only when applications are connected to it. To change the RAM policy:

ttAdmin -ramPolicy inUse database1

To set the RAM policy of database1 to enduring:

$ ttAdmin -ramPolicy enduring database1
RAM Residence Policy            : enduring
Manually Loaded In RAM          : False
Replication Agent Policy        : manual
Replication Manually Started    : False
Cache Agent Policy              : manual
Cache Agent Manually Started    : False
Database state                  : open

Now assume database1 is not always in use. Permanently loading it into RAM would unnecessarily use memory. This database is idle for long periods, but when it is in use multiple users connect to it in rapid succession. To improve performance, it may be best to keep the database in RAM when applications are connected to it and to keep it in RAM for 5 minutes (300 seconds) after the last user disconnects. With this RAM policy, the database remains in RAM if applications are connected to the database. To set this policy:

% ttAdmin -ramPolicy inUse -ramGrace 300 History

Some performance-sensitive applications use a database referred to by DSN database1. So that applications do not have to wait for the database to be loaded from disk into RAM, this database must always remain in RAM. To accomplish this:

% ttAdmin -ramPolicy always database1

To display a summary of the policy settings for the database1 DSN:

% ttAdmin -query database1
RAM Residence Policy            : inUse
Replication Agent Policy        : manual
Replication Manually Started    : False
Cache Agent Policy              : manual
Cache Agent Manually Started    : False
Database State                  : Open

Notes

If you need to destroy a database, use the ttDestroy utility. If the database has a preserved shared memory segment (because it was detached with the -shmDetach utility) you must use the ttDestroy -force option. For more information on destroying a database, see ttDestroy.

Setting the RAM policy to inUse for production systems with large databases is not recommended as the database may unload or reload unexpectedly which can result in long delays and excessive overhead.

RAM policy always conflicts with forced disconnect granularity unload, described in Force Disconnect. Using both simultaneously results in an error and the disconnect request being ignored.

The always RAM policy should be used with caution. When failures occur, it may not be beneficial to have your database automatically reload. In addition, it may affect system startup performance if all databases load at the same time when your system boots.

If the shared memory segment is destroyed manually (for example by using ipcrm), -shmFree returns an error indicating that the shared memory segment is missing; however, the -shmFree command updates the database's DBI file and main daemon bookkeeping. The database can then be successfully loaded with -ramLoad, and the database RAM policy can be changed to another policy besides enduring by using ttAdmin -ramPolicy.

If you try to load a database using -ramLoad while a previously detached shared memory segment exists for that database, then the command returns an error and fails. You must either attach the segment with -shmAttach (instead of -ramLoad) or destroy it using -shmFree, and then reload the database using the -ramLoad option.