Specifying a RAM Policy

TimesTen enables you to specify a RAM policy that determines when TimesTen databases are loaded and unloaded from main memory. There is also a RAM policy that enables you to detach and leave the shared memory segment in memory instead of unloading it.

For each TimesTen database, you can have a different RAM policy.

The RAM policy options are as follows:

  • manual: The database is manually loaded and unloaded by system administrators. Once loaded, TimesTen ensures that the database stays loaded until the administrator unloads the database (using ttAdmin -ramUnload) or unless an unrecoverable error condition occurs. The database can only be explicitly loaded into system RAM by the administrator (using the ttAdmin -ramLoad option). This is the recommended RAM policy, because it avoids unnecessary database loading or unloading.

    See Perform RAM Operations in Oracle TimesTen In-Memory Database Reference for more details on ttAdmin -ramLoad and -ramUnload options. For more details on database error recovery, see Changes to RAM Policy After Automatic Recovery Fails.

  • enduring: This option should be used when you want to perform a fast upgrade.

    The database can be manually loaded and unloaded by system administrators just as you would with the manual RAM policy.

    In addition, the enduring RAM policy enables you to detach from the shared memory segment before closing the database. And when you are ready to open the database, you can attach to this same shared memory segment and start up the main subdaemon to restart the database. In addition, if a database fails because of an error, you can free the shared memory segment and recover the database from the checkpoint files. See Detaching, Attaching, and Freeing the Shared Memory Segment.

    This is useful when performing an upgrade.

    See Perform RAM Operations in Oracle TimesTen In-Memory Database Reference for more details on ttAdmin -ramLoad and -ramUnload options. See Changes to RAM Policy After Automatic Recovery Fails for more details on database error recovery.

  • inUse: The database is loaded into memory when the first connection to the database is opened, and it remains in memory as long as it has at least one active connection. When the last connection to the database is closed, the database is unloaded from memory. This is the default policy.

  • inUse with RamGrace: The database is loaded into memory when the first connection to the database is opened, and it remains in memory as long as it has at least one active connection. When the last connection to the database is closed, the database remains in memory for a grace period. The database is unloaded from memory only if no processes have connected to the database for the duration of the grace period. The grace period can be set or reset at any time. It stays in effect until the next time the grace period is changed.

    Note:

    Set the RAM policy to inUse or inUse with RamGrace if the application requires that the TimesTen database is automatically loaded with the first connection and automatically unloaded with the last disconnection. However, setting RAM policy to inUse for production systems with large databases may cause performance issues having the database unload and reload unexpectedly.

  • always: The database always stays in memory. If the TimesTen daemon is restarted, it automatically reloads the database. The database is always automatically reloaded unless an unrecoverable error condition occurs.

    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. See Changes to RAM Policy After Automatic Recovery Fails on error recovery and Preventing an Automatic Reload of the Database After Failure for what could occur when trying to reload the database.

A system administrator can set the RAM policy or manually load or unload a database in TimesTen with either the ttAdmin utility or the C API RAM policy utilities. See ttAdmin in Oracle TimesTen In-Memory Database Reference or the TimesTen Utility API chapter in Oracle TimesTen In-Memory Database C Developer's Guide.

Note:

By default, if an automatic recovery of the database is unsuccessful after a fatal error, TimesTen changes the always and manual RAM policies to InUse to prevent reoccurring failures. For more information on how to prevent the RAM policy from changing, see Changes to RAM Policy After Automatic Recovery Fails.

The following example sets the RAM policy to manual for the database identified by the ttdata DSN:

Note:

The first line shows the RAM residence policy set to manual. The rest of the output details other policies you can set with the ttAdmin utility. See ttAdmin in Oracle TimesTen In-Memory Database Reference. 

% ttAdmin –ramPolicy manual ttdata
RAM Residence Policy            : manual
Replication Agent Policy        : manual
Replication Manually Started    : False
Cache Agent Policy              : manual
Cache Agent Manually Started    : False
Database state                  : open

The following example sets the RAM policy of a TimesTen database 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