Specifying a RAM Policy

TimesTen Classic enables you to specify a RAM policy that determines when TimesTen Classic 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 Classic database, you can have a different RAM policy.

Note:

TimesTen Scaleout supports the manually loading and unloading of the database through the ttGridAdmin utility by system administrators.

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 Classic 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 Classic 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

Changes to RAM Policy After Automatic Recovery Fails

Certain procedures automatically occur by default when a fatal error invalidates the database and the automatic database recovery performed by TimesTen Classic is unsuccessful.

• The RAM policies of manual, enduring, and always remain unchanged.

• The replication and cache agents are not restarted.

• After several failed attempts to reload the database, TimesTen Classic sets the policyInactive mode, which prevents any more attempts at loading the database.

Note:

Reloading a large database into memory when an invalidated database still exists in memory can fill up available RAM. See Preventing an Automatic Reload of the Database After Failure on how to stop automatic reloading of the database.

Preventing an Automatic Reload of the Database After Failure

After a fatal error that causes the database to be invalidated, TimesTen Classic attempts to reload and recover the database, as long as it is consistent with the settings for the RAM policy, cache agent policy, and replication agent policy.

However, user processes could still be connected to the invalidated database if they do not know that the original database has been invalidated. In this case, the invalidated database exists in memory until all user processes close their connections. Thus, the invalidated database could coexist in memory with the newly reloaded database. This can be an issue if the database is large.

Note:

Not only does the RAM policy determines whether the database is reloaded and recovered, but the cache agent and replication agent policies also factor into whether the database is reloaded after invalidation. If the cache agent and replication agent policies are set so that the daemon automatically restarts the agent after a failure, the agent initiates a connection to the database. If this is the first connection, the daemon reloads the database and performs a recovery.

For more information on cache agent and replication agent policies, see Starting and Stopping the Replication Agents in the Oracle TimesTen In-Memory Database Replication Guide, Set a Cache Agent Start Policy in TimesTen Classic in the Oracle TimesTen In-Memory Database Cache Guide, and ttAdmin in the Oracle TimesTen In-Memory Database Reference.

You can prevent the database from being automatically reloaded after an invalidation using the ttAdmin -noautoreload command. You can reset to the default automatic database reload behavior with the ttAdmin -autoreload command. See ttAdmin in the Oracle TimesTen In-Memory Database Reference.

Note:

The ttRamPolicyAutoReloadSet built-in procedure performs the same actions as ttAdmin -noautoreload and ttAdmin -autoreload. See ttRamPolicyAutoReloadSet in the Oracle TimesTen In-Memory Database Reference.

Any one of the following initiates a reload and recovery of the database so that standard behavior can resume:

• The TimesTen daemon restarts.

• A process connects successfully.

• The administrator runs a ttAdmin command for the database that changes the RAM policy, performs a RAM load, or starts either the cache or replication agents.

If you set the behavior to prevent automatic reloads of the database, you may receive the following error when connecting to a database that was not reloaded.

Error 707, "Attempt to connect to a data store that has been manually unloaded from RAM"