Managing a TimesTen database includes the following:
For an application to be able to connect to a database, the database needs to be open. When a database is closed, any new user connection attempts fail.
By default in TimesTen Classic, the database is automatically opened and user connections can connect.
By default in TimesTen Scaleout, the database is closed until manually opened. See "Open the database for user connections" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for details.
You can close the database to reject any new user connections to a database.
TimesTen Classic: Use the ttAdmin -close
command to close the database to any new user connections.
Since the database can be automatically loaded or unloaded as set by the RAM policy, the status of a database (open or closed) is not aligned with whether the database is currently loaded into memory. Thus, the database could be in an open state as well as unloaded or in a closed state when loaded. See "Loading a database into memory for TimesTen Classic" for an example of the RAM policy.
You should close a database before manually unloading a database. When loading a closed database into memory, the database cannot be opened until the load operation completes. You can re-open the database with the ttAdmin -open
command. See "Unloading a database from memory for TimesTen Classic" for an example.
TimesTen Scaleout: Before unloading a database from memory, you must manually close the database. See "Unloading a database from memory" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for details.
Use the following to see the status of your database:
TimesTen Classic: Use the ttStatus
utility to see the status of the database. See "ttStatus" in Oracle TimesTen In-Memory Database Reference for details.
TimesTen Scaleout: Use the ttGridAdmin dbStatus
command to see the status of the database. See "Monitor the status of a database (dbStatus)" in Oracle TimesTen In-Memory Database Reference for details.
TimesTen is an in-memory database. As such, a database must first be loaded into memory from the file system to be available for connections. When a database is loaded into memory, the contents of the permanent memory region are read from checkpoint files stored on the file system. The temporary memory region is created when a database is loaded into memory and is destroyed when it is unloaded. See "Specifying the memory region sizes of a database" for more details on permanent and temporary memory.
In TimesTen Scaleout: The grid administrator controls how to load and unload the database using the ttGridAdmin
utility. See "ttGridAdmin" in the Oracle TimesTen In-Memory Database Reference for details.
In TimesTen Classic: RAM policies specify how and when a database is loaded into memory, including whether to automatically reload the database into memory if the database is unloaded unexpectedly. See "Specifying a RAM policy" for full details on the different RAM policies.
Only the instance administrator can load a database manually. By default, TimesTen automatically loads an idle database (which is a database with no connections) into memory when a first connection is made to it. See "Loading a database into memory for TimesTen Classic" for details.
After a database loads into memory, you may need to explicitly start the cache and replication agents for the database, depending on the functionality you are using and on which cache and replication policies you set with the ttAdmin
utility.
Loading and unloading the database from memory for TimesTen Classic is described in these sections:
Before you try to load the database into memory for TimesTen Classic, confirm that the TimesTen daemon is running with the ttStatus
utility. The following output shows that the TimesTen daemon is not running.
% ttStatus ttStatus: Could not connect to the TimesTen daemon. If the TimesTen daemon is not running, please start it by running "ttDaemonAdmin -start".
Start the TimesTen daemon, if necessary.
% ttDaemonAdmin -start
The RAM policy setting is important as it specifies if, how, and when the database is loaded or unloaded from memory. The default RAM policy for a TimesTen database is inUse
.
You can set the RAM policy before loading the database into memory. See "Specifying a RAM policy" for more information.
The following example sets the RAM policy of a TimesTen database to manual
:
% ttAdmin -ramPolicy manual database1 RAM Residence Policy : manual 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
Use the ttAdmin
utility to load (or reload) the database into memory, or unload the database from memory.
If the RAM policy is manual
for the database database1
, then load the TimesTen database into memory with the ttAdmin -ramload
utility. The -ramLoad
option of the ttAdmin
utility can only be used with the manual
RAM policy:
% ttAdmin -ramLoad database1 RAM Residence Policy : manual Manually Loaded In RAM : True Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database state : open
If the RAM policy is manual
, you can change it to always
to specify that the database is always reloaded.
ttAdmin -ramPolicy always database1
If the RAM policy is inUse
, then you want the grace period to be greater than 0, so that the database will be kept in memory for that time period when idle:
% ttAdmin -ramPolicy inUse -ramGrace 200 database1 RAM Residence Policy : inUse plus grace period RAM Residence Grace (Secs) : 200 Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database state : open
If the RAM policy is manual
for the database database1
and the database was previously closed to incoming connections, then you can both load and open the TimesTen database into memory with the ttAdmin -ramload -open
command.
% ttAdmin -ramLoad -open database1 RAM Residence Policy : manual Manually Loaded In RAM : True Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database state : open
If your database is configured for replication or cache for your database, run the ttAdmin
utility to start the replication and cache agents.
To start replication:
ttAdmin -repStart database1
To start TimesTen Cache:
ttAdmin -cacheStart database1
For more information on these utilities, see "ttAdmin" and "ttDaemonAdmin" in the Oracle TimesTen In-Memory Database Reference.
In TimesTen Classic, a database remains loaded in shared memory if any applications or TimesTen agents, such as the cache agent or replication agent, are connected to it. In TimesTen Classic, a database may also be kept in shared memory for particular RAM policy setting, even when no applications or agents are connected.
Before unloading the database from memory for TimesTen Classic, you must first close the database, close all active connections to the database and then set the RAM policy of the database to manual
or inUse
.
Note:
The following steps use examples wheredatabase1
is the database that is to be unloaded. It is assumed that it is the active master in a replication scheme and has been configured with TimesTen Cache. Note that a database can have both replication and cache configured, and a RAM policy other than manual.Close the database to reject any new requests to connect to the database.
ttAdmin -close database1
Disconnect all applications from the database.
To close all active connections to the database, run the ttAdmin -disconnect
command. For more information, see "Disconnecting from a database" in this book and "ttAdmin" in the Oracle TimesTen In-Memory Database Reference.
If the replication agent is running on the database, set the replication state to pause
and stop the replication agent. The example sets the replication state from the active master database1
to the standby master standbydb
to pause
, then stops the replication agent on the active master database1
.
ttRepAdmin -receiver -name database1 -state pause standbydb ttAdmin -repStop database1
If the cache agent is running on the database, stop the cache agent.
ttAdmin -cacheStop database1
Ensure that the RAM policy is set to either manual
or inUse
. Then unload the database from memory. See "Specifying a RAM policy" for more information.
If the RAM policy is set to always
, change it to manual
and then unload the database from memory with the ttAdmin -ramPolicy -ramUnload
utility options.
ttAdmin -ramPolicy manual -ramUnload database1
If the RAM policy is set to manual
, unload the database with the ttAdmin -ramUnload
utility:
ttAdmin -ramUnload database1
If the RAM policy is set to inUse
and a grace period is set, set the grace period to 0 or wait for the grace period to elapse. This results in the database being unloaded. TimesTen unloads a database with an inUse
RAM policy from memory once you close all active connections.
ttAdmin -ramGrace 0 database1
Run the ttStatus
utility to verify that the database has been unloaded from memory and the database is closed. The database is unloaded if there are no processes. The database is closed when the output shows "Closed for user connections."
See "ttStatus" in Oracle TimesTen In-Memory Database Reference for details.
Optionally, stop the TimesTen daemon.
ttDaemonAdmin -stop
For more information on the ttAdmin
utility, see "ttAdmin" in the Oracle TimesTen In-Memory Database Reference.
TimesTen Classic allows you to specify a RAM policy that determines when TimesTen Classic databases are loaded and unloaded from main memory. 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 thettGridAdmin
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 "Set database loading policies" in the 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".
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. For more details, see "ttAdmin" in the Oracle TimesTen In-Memory Database Reference or the "TimesTen Utility API" chapter in the 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 thealways
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 tomanual
. The rest of the output details other policies you can set with the ttAdmin
utility. See "ttAdmin" in the Oracle TimesTen In-Memory Database Reference for more information.% 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
If a fatal error invalidates the database and the automatic database recovery performed by TimesTen Classic is unsuccessful, the following occurs by default:
The RAM policies of manual
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.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 the Oracle TimesTen Application-Tier Database Cache User's 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 for more details.
Note:
ThettRamPolicyAutoReloadSet
built-in procedure performs the same actions as ttAdmin -noautoreload
and ttAdmin -autoreload
. See "ttRamPolicyAutoReloadSet" in the Oracle TimesTen In-Memory Database Reference for more details.Any one of the following initiates a reload and recovery of the database so that normal behavior can resume:
The TimesTen daemon restarts.
A process connects successfully.
The administrator executes 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"
You can shut down or unload the database by first disconnecting applications in an orderly fashion. The forced disconnect option asynchronously disconnects all connected applications from the database, including those that are idle or unresponsive.
Reliably disconnects and detaches from the shared memory segment for a database.
Successfully disconnects any idle or unresponsive connections.
The following sections describe how to disconnect connections from a TimesTen database:
If you are unable to individually disconnect every application from the TimesTen Scaleout database, use the ttGridAdmin dbDisconnect
command to disconnect all user connections from the database. See "Unloading a database from memory" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for full details.
You can disconnect all connections to a TimesTen Classic database with the ttAdmin -disconnect
command. However, you must first enable the capability for forced disconnect by setting the ForceDisconnectEnabled
connection attribute to 1 in the DSN definition within the sys.odbc.ini
file. See "ForceDisconnectEnabled" in the Oracle TimesTen In-Memory Database Reference for more details.
While control returns to the command prompt, the force disconnect operation may take multiple seconds (or minutes) to complete. Verify the status of the force disconnect operation with the ttStatus
utility.
While the forced disconnect operation is in process, any new connection request is rejected by the main daemon. Once the force disconnect operation completes, new connections are accepted.
You can specify how urgently you need connections to be forced to disconnect with the urgency level:
The -transactional
option waits for any open transactions to be committed or rolled back before disconnecting. Does not affect idle connections.
The -immediate
option rolls back any open transactions before immediately disconnecting. This option also disconnects idle connections.
The -abort
option aborts all direct mode application processes and client/server processes (ttcserver
) in order to disconnect.
Most of the time, you should use the transactional and immediate urgency levels. A recommended practice is to run the -disconnect
command twice, as necessary. First use the transactional urgency level. Then, after allowing some time, use ttStatus
to confirm whether connections have been closed. If not all connections have been closed yet, then use the immediate urgency level.
The abort urgency level should only be used on the rare occasion when both the transactional and immediate urgency levels fail to successfully disconnect all specified connections. The abort option could result in lost transactions, as the abort operation abruptly causes every user and ttcserver
process connected to the database to exit.
You can specify which type of connections to disconnect with the granularity level.
The -users
option (default) disconnects every user connection to the database. For example, use this granularity level when preparing to perform database maintenance.
The -unload
option disconnects every connection to the database, including subdaemon connections. For example, use this granularity level when attempting to unload the database.
Note:
Thealways
RAM policy conflicts with the unload
granularity level. Using these simultaneously returns an error.See "Force disconnect" in the Oracle TimesTen In-Memory Database Reference for more details on using the ttAdmin -disconnect
command.
Example 2-1 Disconnecting all connections and unloading a TimesTen Classic database
The following script disconnects all connections and unloads the database by first executing ttAdmin -disconnect
with the transactional urgency level. Then, the script waits a short time to evaluate if the connections disconnected before trying the immediate urgency level.
#!/bin/sh # disconnect users and unload the database with the transactional urgency level ttAdmin -disconnect -transactional -unload database1 # wait 10 seconds for the forced disconnect to finish COUNT = 0 while [ ttStatus | grep "pending disconnection" ] || [ $COUNT -ne 10 ] do sleep 1 COUNT=$((COUNT+1)) done # increase the urgency level to immediate if [ ttStatus | grep "pending disconnection" ]; then ttAdmin -disconnect -immediate -unload database1 fi
Use the ttStatus
utility to check progress. During a forced disconnect operation, the output indicates the pending disconnections:
TimesTen status report
Daemon pid 10457 port 6627 instance user1
TimesTen server pid 10464 started on port 6629
------------------------------------------------------------------------
------------------------------------------------------------------------
Data store /disk1/databases/database1
Daemon pid 10457 port 6627 instance user1
TimesTen server pid 10464 started on port 6629
There are 14 connections to the data store, ***14 pending disconnection***
Shared Memory KEY 0x0210679b ID 949092358
PL/SQL Memory KEY 0x0310679b ID 949125127 Address 0x5000000000
Type PID Context Connection Name ConnID
Process 10484 0x00007f3ddfeb4010 tt_181 1
...
TimesTen manages database space using two separate memory regions within a single contiguous memory space. One region contains permanent data and the other contains temporary data.
Permanent data includes the tables and indexes that make up a TimesTen database. When a database is loaded into memory, the contents of the permanent memory region are read from files stored on the file system. The permanent memory region is written to the file system during checkpoint operations. TimesTen stores all data in RAM to achieve exceptional performance. The database throws an error if there is no space left for a new piece of data. PermSize
can be increased with a database restart but it cannot be decreased.
Temporary data includes locks, cursors, compiled commands, and other structures needed for command execution and query evaluation. The temporary memory region is created when a database is loaded into memory and is destroyed when it is unloaded.
The connection attributes that control the size of the database when it is in memory are PermSize
and TempSize
. The PermSize
attribute specifies the size of the permanent memory region and the TempSize
attribute specifies the size of the temporary memory region.
Note:
See "PermSize" and "TempSize" in the Oracle TimesTen In-Memory Database Reference for further description of these attributes.The sizes of the permanent and temporary memory regions are set when a database is loaded into memory and cannot be changed while the database is in memory. To change the size of either region, you must unload the database from memory and then reconnect using different values for the PermSize
or TempSize
attributes. See "Loading and unloading the database from memory" for more information on unloading the database from memory.
Managing the database size is described in these sections:
Database operations cannot complete successfully without allocation of sufficient memory. First, determine appropriate sizes for the TimesTen permanent and temporary memory regions and the transaction log buffer.
Use the ttSize
utility or run the application until you can make reasonable estimates, then set these TimesTen connection attributes:
PermSize
: Size of the permanent memory region, in MB, for the database where the actual data is stored. Make sure PermSize
is sufficient to hold all the data. You can increase this value, but not decrease it for this database.
In TimesTen Classic, you can decrease the permanent memory region by re-creating the database with a smaller size. See "Reducing database size for TimesTen Classic" for more details.
Note:
ThettSize
utility is optimized for databases in TimesTen Classic. See "Determining the value of the PermSize attribute" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for details on how to evaluate an appropriate value for the PermSize
connection attribute for a TimesTen Scaleout database.TempSize
: For TimesTen Classic, TempSize
indicates the total amount of memory in MB allocated to the temporary region for the database. For TimesTen Scaleout, TempSize
indicates the total amount of memory in MB allocated to the temporary region for an element. Related database operations may fail if TempSize
is insufficient. You can change this size with a database restart.
LogBufMB
: Size of the internal transaction log buffer, in MB. By default LogBufMB
is 64 MB. See "Configure log buffer and log file size parameters" for details.
See "PermSize", "TempSize", "LogBufMB" and "LogFileSize" in the Oracle TimesTen In-Memory Database Reference for further description of these attributes.
Next, ensure that the maximum shared memory segment size of your system is large enough to contain the database. Use the maximum number of connections that you expect your database to use. All of the values are in MB (megabytes). Make it larger than the following:
PermSize + TempSize + LogBufMB + 1 + (.043 * connections)
Note:
If a TimesTen Classic database is configured for replication, reconfigure the database sizes for all replicas of the database. Once you have made the change in database size, load the database into memory and restart the cache and replication agents.If there are multiple TimesTen databases on your system, each using its own shared memory segment, the maximum shared memory segment size must be large enough to accommodate the largest database.
Next, determine the total shared memory allocation you will need (converted to appropriate units). If there are multiple TimesTen databases on your system, the total shared memory allocation must be large enough to accommodate all of them, using the above equation for each database. (Then, on Linux for example, divide this value by the page size, typically 4096 bytes, to get total memory allocation in pages.)
Note:
In TimesTen Classic, additional shared segments may be created either for PL/SQL with thePLSQL_MEMORY_SIZE
connection attribute or for Client/Server with the -server_shmsize
configuration option (in timesten.conf
). Refer to "PLSQL_MEMORY_SIZE" in Oracle TimesTen In-Memory Database Reference and for more information. If you use the default values or similarly small sizes, there should be enough unused space in shared memory to accommodate these segments.Finally, if you want to allow for database invalidations, there must be at least twice as much physical memory as the size of the largest TimesTen database. If you do not allow for this, but an invalidation does occur, you cannot reload the database into memory until all processes and connections that used the database have been found and terminated.
Also see "Linux prerequisites" in Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide.
The SYS.V$MONITOR
and SYS.GV$MONITOR
system views contains several columns that can be used to monitor usage of PermSize
and TempSize
. These columns include PERM_ALLOCATED_SIZE
, TEMP_ALLOCATED_SIZE
, PERM_IN_USE_SIZE
, PERM_IN_USE_HIGH_WATER
, TEMP_IN_USE_SIZE
, and TEMP_IN_USE_HIGH_WATER
. Each of these columns show in KB units the currently allocated size of the database and the in-use size of the database. The system updates this information each time a connection is made or released and each time a transaction is committed or rolled back.
For example, you could evaluate the temporary space usage by running a full workload and watching the high water mark (TEMP_IN_USE_HIGH_WATER
) of the temporary space usage. The high water mark can be reset using the ttMonitorHighWaterReset
built-in procedure. And if necessary, you can change TempSize
to a value of the observed TEMP_IN_USE_HIGH_WATER
value and add 10%.
Note:
You can also use the ttIsqldssize
command to provide this information. See "Using the ttIsql dssize command" and "ttIsql" in the Oracle TimesTen In-Memory Database Reference for more details.You can monitor block-level fragmentation in the database with the SYS.V$BLOCK_INFO
or SYS.GV$BLOCK_INFO
system tables or by calling the ttBlockInfo
built-in procedure.
See "SYS.GV$MONITOR", "SYS.V$MONITOR", "SYS.GV$BLOCK_INFO" or "SYS.V$BLOCK_INFO" in the Oracle TimesTen In-Memory Database System Tables and Views Reference for details on these views. For more details, see "ttBlockInfo" in the Oracle TimesTen In-Memory Database Reference.
Once a TimesTen Classic database has been defined with a particular size for the permanent region (indicated by the PermSize
DSN attribute), it cannot be reduced to a smaller size, even if tables or rows are deleted.
To reduce the allocated size of the permanent region of a TimesTen Classic database, run the ttMigrate
utility to save a copy of the database and then re-create the database with a smaller permanent region size and restore the data.
Perform these steps to reduce the permanent region size of a TimesTen Classic database:
Disconnect applications from the database with the ttAdmin -disconnect
command. For more information, see "Disconnecting from a database in TimesTen Classic" in this book and "ttAdmin" in the Oracle TimesTen In-Memory Database Reference.
Use the ttMigrate -c
option to create a data file for the database.
% ttMigrate -c database1 /tmp/database1
Unload the TimesTen Classic database from memory. See "Unloading a database from memory for TimesTen Classic" for full details for more information.
Create a new DSN definition for the new copy of the database with a smaller PermSize
value. To modify the original DSN rather than create a new one, you must destroy the original TimesTen Classic database using the ttDestroy
utility before restoring from the backup.
Recreate the TimesTen Classic database by using ttIsql with AutoCreate=1
.
ttIsql -connstr "dsn=database1;AutoCreate=1" -e "quit"
The database is empty at this point.
Restore the backup by using the ttMigrate -r
and -relaxedUpgrade
options.
% ttMigrate -r -relaxedUpgrade database1 /tmp/database1
Notes:
The permanent region size of a TimesTen Classic database cannot be reduced below the size that is required by the data currently stored in the database. This value can be determined by querying the perm_in_use_size
column of the v$monitor
system view.
You can also use this procedure to compact the TimesTen Classic database in order to reduce fragmentation caused by partially full table pages or fragmentation of the heap buffers that store index nodes and out-of-line values.
To receive out-of memory warnings, applications must call the ttWarnOnLowMemory
built-in procedure.
TimesTen Classic also provides two general connection attributes that determine when a low memory warning should be issued: PermWarnThreshold
and TempWarnThreshold
. Both attributes take a percentage value.
Storage provisioning is the process of allocating server storage space.
TimesTen installation storage allocation: A TimesTen installation includes all of the software.
Plan to allocate at least 1.5 GB for each TimesTen installation. If you run multiple instances on the same system, they can all share a single TimesTen installation. In order to incorporate software version upgrades, you should provision double that amount of space, plus some additional space.
TimesTen instance storage allocation: Each TimesTen instance runs its own set of daemon processes (with associated daemon log files).
Plan to allocate at least 256 MB for each TimesTen instance.
Checkpoint files: Each TimesTen database requires disk space for two checkpoint files, each of which is stored in the directory that is specified with the DataStore
attribute. As each checkpoint file grows on the file system, it never decreases in size. This can result in the size of each checkpoint file being equal to the maximum size that the database has ever reached in the permanent memory region. Thus, you should plan as though each checkpoint file occupies approximately the same amount of space as defined for permanent memory (as defined with the PermSize
connection attribute).
Plan to allocate twice the total permanent space of your databases plus 30%.
Note:
For TimesTen Classic, you can set thePreallocate
connection attribute to 1
to have TimesTen reserve file system space at connect time for checkpoint files. This is useful for large databases, which ensures that the file system always has room for the checkpoint files as data is added to the database. For more information, see "Preallocate" in the Oracle TimesTen In-Memory Database Reference.Transaction log files: Transaction log files are the most difficult space requirement to estimate. See "Storage provisioning for transaction log files" for how to plan for space provisioning for transaction log files.
Local space to facilitate backup or export files for repositories in TimesTen Scaleout.
When you use an SCP-attached repository, any operations are first saved locally by the target instances before copied to the repository. The target data instances initially store the backup (or export) files to the $timesten_home
/grid/admin/temp
directory. You must ensure that you provision enough storage in this directory to accommodate the maximum size for backup or export files that would end up in a repository.
Plan to allocate space of PermSize
times the number of replica sets.
Repository storage provisioning in TimesTen Scaleout.
A single backup file contains one element from each replica set. Thus, the number of backup files needed to contain all of the rows of the tables in the database corresponds to the number of replica sets in your database.
Note:
For hash distributed tables, only a portion of the rows of the tables are included in each backup file. The rows of hash distributed tables are distributed across the number of replica sets.For duplicated tables, each backup file contains all rows in each table.
Plan to allocate space of PermSize
times the number of replica sets.
Note:
You can generate a more accurate estimate of the transaction log volume within a test environment.Consider the following when estimating the necessary file system space allocation for transaction log files:
TimesTen keeps enough transaction log files to support recovering from either checkpoint file. Transaction log files may accumulate depending on the settings for background checkpoint operations (defined with the CkptLogVolume
and CkptFrequency
first connection attributes). In addition, TimesTen preallocates space for three additional transaction log files.
TimesTen uses fuzzy checkpoint operations for background operations. Transaction log files can accumulate during fuzzy checkpoint operations. The amount of time taken to create a checkpoint scales with the value assigned to the PermSize
connection attribute.
Transaction log files may accumulate between incremental backups.
In TimesTen Scaleout, each element in each replica set has its own transaction log files to store transaction log records. If a transaction modifies data in a replica set, then the changes are normally recorded in both elements of the replica set. However, if one of the elements in the replica set is down, then the changes are only recorded in the transaction log files for the active element. Transaction log files can accumulate if one element in a replica set is down for a very long time.
In TimesTen Classic, transaction log files may accumulate on the master during temporary replication outages or if the subscriber is down.
Note:
You can limit the number of transaction log files retained with theFAILTHRESHOLD
clause on the CREATE REPLICATION
and ALTER REPLICATION
statements.See "CkptLogVolume," "CkptFrequency," and "PermSize" in the Oracle TimesTen In-Memory Database Reference for more information on these connection attributes. See "CREATE REPLICATION" and "ALTER REPLICATION" in the Oracle TimesTen In-Memory Database SQL Reference for more information on these SQL statements.
The estimate of the transaction log volume depends on the peak update transaction rate and the average complexity of each transaction that modifies the database.
Consider:
B represents the transaction log volume in bytes per transaction.
C represents the number of columns updated. The minimum transaction update (which is an update of a single number column) generates 400 bytes of transaction log data. Each additional number column update generates another 250 bytes.
V represents the average size of larger data inserted or updated (columns of type CHAR
, VARCHAR2
, BINARY
, VARBINARY
or LOB
) for each write transaction.
To estimate the transaction log volume for each transaction, use this formula:
B = 400 + ((C-1) * 250) + V
Note that the first column is just 150 bytes more than all subsequent columns, as follows:
B = (C * 250) + (400-250) + V
which simplifies to:
B =(C * 250) + 150 + V
Multiply the estimated transaction log volume value (B) by the expected peak transaction rate to find the expected peak transaction log rate.
Where:
L = total storage space to provision for transaction log files in bytes.
C = average number of columns inserted or updated per write transaction.
V = average bytes of large data (CHAR
, VARCHAR2
, BINARY
, or VARBINARY
columns) inserted or updated for each write transaction.
S = time in seconds of required transaction log retention.
T = peak transaction rate per second averaged over intervals of S seconds.
f = fraction of transactions that include insert, update, or delete operations.
Lastly, increase the estimated file system space by an additional 30% for contingencies.
Taking all these factors into account, estimate provisioned transaction log file space in bytes according to this formula:
L = ((C * 250) + 150 + V) * S * T * f * 1.3
Example 2-2 Estimating storage provisioning
For example, a workload consists of 35% update transactions. Each transaction updates four columns, including two character columns each averaging 30 bytes updated total. The workload runs at 1 million transactions per second and needs enough transaction log space to hold one hour's worth of transactions.
C = 4 columns
V = 30
S = 3600
T = 1,000,000
f = 35% = 0.35
This workload requires:
L = ((4 * 250) + 150 + 30) * 3,600 * 1,000,000 * 0.35 * 1.3 = 1.9 TB
Thus, provision file system space of 1.9 TB for the transaction log files.
The ttBulkCp
utility enables you to copy data between TimesTen tables and ASCII files.
You can manage certain aspects of existing tables in the database with the ttBulkCp
utility. With the ttBulkCp
utility, you can add rows of data to an existing table, save data to an ASCII file, and load the data rows into a table in a TimesTen database.
The rows you are adding must contain the same number of columns as the table, and the data in each column must be of the type defined for that column.
Because the ttBulkCp
utility works on data stored in ASCII files, you can also use this utility to import data from other applications, provided the number of columns and data types are compatible with those in the table in the TimesTen database and that the file found is compatible with ttBulkCp
.
Run the ttBulkCp
utility with the -o
option to copy data from a TimesTen table to an ASCII file.
Note:
Ensure that your TimesTen user hasSELECT
privilege on the tables it copies information from.This example copies the data from the hr.employees
table of the database1
database to the employees.dmp
file.
% ttBulkCp -o -connstr "DSN=database1;UID=HR;PWD=hr" hr.employees > employees.dmp
For more information about the ttBulkCp
utility, see "ttBulkCp" in the Oracle TimesTen In-Memory Database Reference.
The ttBulkCp
utility enables you to copy data from an ASCII file into a database table. The ttBulkCp
utility does not copy duplicate rows into a table.
The ttBulkCp
utility with the -i
option enables you to load data from a file. This option uses standard INSERT
SQL statements to load data into a specific table of a TimesTen database.
On TimesTen Scaleout, the ttBulkCp
utility inserts each row into its corresponding element based on the distribution scheme of the table. For TimesTen Scaleout, you can populate a table from a single location or from several locations. See "Bulk loading data into a database" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information on using the ttBulkCp
utility in TimesTen Scaleout.
Note:
Ensure that your TimesTen user hasINSERT
privilege on the tables it copies information into.This example copies the data from the employees.dmp
file into the hr.employees
table of the database1
database.
% ttBulkCp -i -connstr "DSN=database1;UID=HR;PWD=hr" hr.employees employees.dmp employees.dmp: 107 rows inserted 0 duplicate rows not inserted 107 rows total
For more information about the ttBulkCp
utility, see "ttBulkCp" in the Oracle TimesTen In-Memory Database Reference.
Run the ttBulkCp
utility with the -directLoad
option to copy data from an ASCII file into a TimesTen Classic database table. The -directLoad
option loads data with standard INSERT
SQL statements. The ttBulkCp -directLoad
option can only be used by applications using direct connections, which avoids some of the overhead required when using client/server connections resulting in better performance than the -i
option.
For improved performance, consider dropping indexes before loading data with the -directLoad
option. Use the ttSchema
utility to view the definition of all the indexes that are created on the tables of a TimesTen Classic database. Once the load operation is complete, manually re-create the indexes on your table. For more information about the ttSchema
utility, see "ttSchema" in the Oracle TimesTen In-Memory Database Reference.
Note:
Ensure that your TimesTen user hasINSERT
privilege on the tables it copies information into.Example 2-5 ttBulkCp -directLoad option
This example copies the data from the employees.dmp
file into the hr.employees
table of the database1
database.
% ttBulkCp -directLoad -connstr "DSN=database1;UID=HR;PWD=hr" hr.employees employees.dmp employees.dmp: 107 rows inserted 0 duplicate rows not inserted 107 rows total
For more information about the ttBulkCp
utility, see "ttBulkCp" in the Oracle TimesTen In-Memory Database Reference.
TimesTen supports multithreaded application access to databases. When a connection is made to a database, any thread may issue operations on the connection.
Typically, a thread issues operations on its own connection and therefore in a separate transaction from all other threads. In environments where threads are created and destroyed rapidly, better performance may be obtained by maintaining a pool of connections. Threads can allocate connections from this pool on demand to avoid the connect and disconnect overhead.
TimesTen allows multiple threads to issue requests on the same connection and therefore the same transaction. These requests are serialized by TimesTen, although the application may require additional serialization of its own.
TimesTen also allows a thread to issue requests against multiple connections, managing activities in several separate and concurrent transactions on the same or different databases.
Under some circumstances, a TimesTen database may develop memory fragmentation such that significant amounts of free memory are allocated to partially filled pages of existing tables. This can result in an inability to allocate memory for other uses (such as new pages for other tables) due to a lack of free memory. In these circumstances, it is necessary to defragment the database in order to make this memory available for other uses.
A secondary table partition is created after a table has been altered with the ALTER TABLE ADD
SQL statement. Defragmentation enables you to remove the secondary table partitions and create a single table partition that contains all of the table columns. When secondary table partitions have been created, it is recommended to periodically defragment the database in order to improve space utilization and performance.
The following procedures address both types of database fragmentation:
A TimesTen Scaleout database is defragmented as part of the export and import process. Thus, to defragment a TimesTen Scaleout database, use the ttGridAdmin
dbExport
and dbImport
commands. See "Exporting and importing a database" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for details.
To defragment a TimesTen Classic database, use the ttMigrate
utility as follows:
Stop all connections to the database.
Save a copy of the database using ttMigrate
.
% ttMigrate -c ttdb ttdb.dat
As the administration user, rebuild the ttdb
database:
% ttMigrate -r -relaxedUpgrade -connstr "dsn=ttdb" ttdb.dat
Note:
You can achieve maximum table defragmentation with thettMigrate -r -relaxedUpgrade
command. The -relaxedUpgrade
option also condenses table partitions. If you do not want to condense table partitions, remove the -relaxedUpgrade
option from the ttMigrate -r -relaxedUpgrade
command.At this time:
All the users, cache groups, and the active standby pair have been restored to ttdb
.
The cache groups are in AUTOREFRESH STATE = OFF
.
The cache agent and replication agent are not running.
Table partitions can be added when columns are added to tables with the ALTER TABLE ADD
SQL statement. See the notes on "ALTER TABLE" in the Oracle TimesTen In-Memory Database SQL Reference for more information. Also see, "Avoid ALTER TABLE" for performance considerations.
For more information on ttMigrate
, see "ttMigrate" in the Oracle TimesTen In-Memory Database Reference.
Use a combination of the ttMigrate -relaxedUpgrade
and ttRepAdmin -duplicate
utilities to defragment TimesTen Classic databases (with minimal overall service downtime) that are involved in a replication scheme where TABLE DEFINITION CHECKING
is set to RELAXED
. In addition, the ttMigrate -relaxedUpgrade
option condenses partitions.
Note:
If your TimesTen Classic database uses an active standby pair replication scheme, then you can only defragment these databases if the active standby pair replication scheme either does not contain any cache groups or contains onlyREADONLY
cache groups.The following sections describe how to defragment TimesTen Classic databases that are involved in a replication scheme:
Note:
The examples provided in each section assume that you are familiar with the configuration and management of replication schemes. For more information, see "Getting Started" in the Oracle TimesTen In-Memory Database Replication Guide.Online defragmentation of TimesTen Classic databases in an active standby pair replication scheme
Online defragmentation of TimesTen Classic databases in a non active standby pair replication scheme
The following sections describe how to defragment TimesTen Classic databases that are involved in an active standby pair replication scheme:
The example in this section shows how to perform an online defragmentation with an active standby pair replication scheme where the active database is ttdb1
and the standby database is ttdb2
.
The following shows how to stop replication to the standby TimesTen database, save a copy of the standby database, and then defragment the standby database.
Note:
While the standby database is defragmented, application processing can continue on the active database.Perform the following to save a copy of the standby database:
Stop the replication agent on the standby database (ttdb2
):
% ttAdmin –repStop ttdb2
If there any subscribers, execute ttRepStateSave
on the active database to set the status of the standby to failed. As long as the standby database is unavailable, updates to the active database are replicated directly to the subscriber databases.
Coomand> call ttRepStateSave('FAILED', 'ttdb2', 'ttsrv2');
Save a copy of the standby database using ttMigrate
.
% ttMigrate -c ttdb2 ttdb2.dat
Stop the cache agent, drop any cache groups, and destroy the standby.
% ttAdmin –cacheStop ttdb2
While connected as cache manager user, drop all cache groups:
Command> DROP CACHE GROUP t_cg;
Destroy the standby database:
% ttDestroy ttdb2
Rebuild the standby database. Execute the following on the standby as the instance administrator:
% ttIsql ttdb2
Create the cache manager user and grant the user ADMIN
privileges.
Command> CREATE USER cacheadmin IDENTIFIED BY cadminpwd; Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE TO cacheadmin; Command> GRANT ADMIN TO cacheadmin;
Note:
The cache manager user requiresADMIN
privileges in order to execute ttMigrate –r
. Once migration is completed, you can revoke the ADMIN
privilege from this user if desired.
For more information on ttMigrate
, see "ttMigrate" in the Oracle TimesTen In-Memory Database Reference.
As the cache manager user, rebuild the ttdb2
database:
% ttMigrate -r -relaxedUpgrade -cacheuid cacheadmin -cachepwd cadminpwd -connstr "dsn=ttdb2;uid=cacheadmin;pwd=cadminpwd;oraclepwd=oraclepwd" ttdb2.dat
At this time:
All the users, cache groups, and the active standby pair have been restored to ttdb2
.
The cache groups are in AUTOREFRESH STATE = OFF
.
The cache agent and replication agent are not running.
As the cache manager user, start the cache agent on the standby:
% ttAdmin –cacheStart ttdb2
Load any cache groups.
Command> ALTER CACHE GROUP t_cg SET AUTOREFRESH STATE PAUSED;
Command> LOAD CACHE GROUP t_cg COMMIT EVERY 256 ROWS PARALLEL <nThreads>;
Note:
Choose nThreads
based on how many CPU cores you use to insert the data into TimesTen for this load operation.
If there are several read-only cache groups it is recommended that you run several LOAD
operations in separate sessions in parallel, if the TimesTen and Oracle Database resources are available.
After completion, verify the cache group state.
Command> cacheGroups; Cache Group CACHEADMIN.T_CG: Cache Group Type: Read Only Autorefresh: Yes Autorefresh Mode: Incremental Autorefresh State: On Autorefresh Interval: 10 Seconds Autorefresh Status: ok Aging: No aging defined Root Table: ORATT.T Table Type: Read Only 1 cache group found.
Start the replication agent on the standby database:
% ttAdmin -repStart ttdb2
Check the replication state on the standby:
% ttIsql ttdb2 Command> call ttRepStateGet; < STANDBY > 1 row found.
The standby database (ttdb2
) has been defragmented and both the active and standby databases are functional.
In order to perform the database defragmentation on the active database, switch the roles of the active and standby database. The active (ttdb1
) becomes the standby database. The original standby (ttdb2
) becomes the active database.
Stop all application processing and disconnect all application connections with the ttAdmin -disconnect
command. Any query only processing can be moved to work at the ttdb2
TimesTen database. For more information, see "Disconnecting from a database" in this book and "ttAdmin" in the Oracle TimesTen In-Memory Database Reference.
Call the ttRepSubscriberWait
built-in procedure at the current active database (ttdb1
), with the database name and host of the current standby database (ttdb2
) as input parameters. This ensures that all queued updates have been transmitted to the current standby database.
Note:
If you set thewaitTime
to -1
, the call waits until all transactions that committed before the call have been transmitted to the subscriber.
However, if you set the waitTime
to any value (this value cannot be NULL
), ensure that the return timeOut
parameter value is 0x00
before continuing. If the returned value 0x01
, call the ttRepSubscriberWait
built-in procedure until all transactions that committed before the call have been transmitted to the subscriber.
For more information about the ttRepSubscriberWait
built-in procedure, see "ttRepSubscriberWait" in the Oracle TimesTen In-Memory Database Reference.
Command> call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
Stop the replication agent on the current active database.
Command> call ttRepStop;
Call the ttRepDeactivate
built-in procedure on the current active database. This puts the database in the IDLE
state.
Command> call ttRepDeactivate; Command> call ttRepStateGet; < IDLE > 1 row found.
Promote the standby to active by calling the ttRepStateSet('ACTIVE')
built-in procedure on the old standby database. This database now becomes the active database in the active standby pair. Use the ttRepStateGet
built-on to verify that the database has become active.
Command> call ttRepStateSet('ACTIVE'); Command> call ttRepStateGet; < ACTIVE > 1 row found.
Stop the replication agent on the database that used to be the active database.
% ttAdmin -repStop ttdb1
Execute ttRepStateSave
on the new active database to set the status of the old active database to failed. As long as the standby database is unavailable, updates to the active database are replicated directly to the subscriber databases.
Command> call ttRepStateSave('FAILED', 'ttdb1', 'ttsrv1');
Restart the full application workload on the new active database (ttdb2
).
This database now acts as the standby database in the active standby pair.
Destroy and recreate the new standby using ttRepAdmin -duplicate
from the new active. During these steps, application processing can continue at the active database.
Stop the cache agent on the new standby database:
% ttAdmin –cacheStop ttdb1
As the cache manager user, drop all cache groups:
Command> DROP CACHE GROUP t_cg;
Destroy the database:
% ttDestroy ttdb1
Re-create the new standby database by duplicating the new active.
% ttRepAdmin -duplicate -from ttdb2 -host ttsrv2 –setMasterRepStart -UID ttadmin -PWD ttadminpwd -keepCG -cacheUID cacheadmin -cachePWD cadminpwd ttdb1
Start cache and replication agents on the new standby database:
% ttAdmin –cacheStart ttdb1 % ttAdmin –repStart ttdb1
This process defragments both the active and standby databases with only a few seconds of service interruption.
The following sections describe how to defragment TimesTen Classic databases that are involved in a non active standby pair replication scheme:
Note:
These sections discuss how to defragment databases that are involved in a bidirectional replication scheme. In bidirectional replication schemes, each database is both a master and subscriber.The examples in this section show how to perform an online defragmentation with bidirectional and unidirectional replication schemes with two TimesTen databases named ttdb1
and ttdb2
. For the unidirectional replication example, ttdb1
represents the master and ttdb2
represents the subscriber.
The first step in the procedure is to stop replication on one of the TimesTen Classic databases and then defragment this database.
Note:
While one of the databases is defragmented, application processing can continue on the other database.Perform the following to save a copy of the database:
Stop the replication agents on one of the databases.
On the ttdb2
database:
% ttAdmin –repStop ttdb2
Save a copy of the ttdb1
database using ttMigrate
.
% ttMigrate -c ttdb2 ttdb2.dat
Destroy the database:
% ttDestroy ttdb2
As a TimesTen user with ADMIN
privileges, rebuild the ttdb2
database:
% ttMigrate -r -relaxedUpgrade -connstr "dsn=ttdb2;uid=ttadmin;pwd=ttadminpwd" ttdb2.dat
At this time:
All the users have been restored to ttdb2
.
The replication agent is not running.
Restart the replication agent on ttdb2
:
% ttAdmin -repStart ttdb2
The ttdb2
TimesTen database has been defragmented.
In order to perform the database defragmentation on the ttdb1
database, perform the following:
Stop all application processing and disconnect all application connections with the ttAdmin -disconnect
command. Any processing can be moved to work at the ttdb2
TimesTen database. For more information, see "Disconnecting from a database" in this book and "ttAdmin" in the Oracle TimesTen In-Memory Database Reference.
Call the ttRepSubscriberWait
built-in procedure at the database that has not been defragmented (ttdb1
), with the database name and host of the defragmented database (ttdb2
) as input parameters. This ensures that all queued updates have been transmitted to both databases.
Note:
If you set thewaitTime
to -1
, the call waits until all transactions that committed before the call have been transmitted to the subscriber.
However, if you set the waitTime
to any value (this value may not be NULL
), ensure that the return timeOut
parameter value is 0x00
before continuing. If the returned value 0x01
, call the ttRepSubscriberWait
built-in procedure until all transactions that committed before the call have been transmitted to the subscriber.
For more information about the ttRepSubscriberWait
built-in procedure, see "ttRepSubscriberWait" in the Oracle TimesTen In-Memory Database Reference.
On ttdb1
:
% ttIsql ttdb1 Command> call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
If you are using a bidirectional replication scheme, skip steps 3-4 and move to step 5.
For a unidirectional replication scheme, where ttdb1
is the master and ttdb2
is the subscriber, drop the replication scheme on both TimesTen databases:
On ttdb1
:
% ttIsql ttdb1 Command> DROP REPLICATION r1;
On ttdb2
:
% ttIsql ttdb2 Command> DROP REPLICATION r1;
For a unidirectional replication scheme, drop the replication scheme on the master (ttdb1
) and subscriber (ttdb2
):
On ttdb1
:
% ttIsql ttdb1 Command> DROP REPLICATION r1;
On ttdb2
:
% ttIsql ttdb2 Command> DROP REPLICATION r1;
Start the replication agent on ttdb2
:
% ttAdmin -repStart ttdb2
Stop the replication agent on ttdb1
.
% ttAdmin -repStop ttdb1
If you modified a unidirectional replication scheme, the ttdb2
database now acts as the master database in the unidirectional scheme; the ttdb1
database acts as the subscriber database in the unidirectional replication scheme.
Destroy and recreate the TimesTen database in the replication scheme that has not yet been defragmented using ttRepAdmin -duplicate
. During these steps, application processing can continue on the defragmented database.
Destroy the database:
% ttDestroy ttdb1
Recreate the new TimesTen Classic database (ttdb1
) by duplicating the previously defragmented TimesTen Classic database (ttdb2
) involved in the replication scheme.
% ttRepAdmin -duplicate -from ttdb2 -host ttsrv2 –setMasterRepStart -UID ttadmin -PWD ttadminpwd ttdb1
Start the replication agent on the new standby database:
% ttAdmin –repStart ttdb1
This process defragments both of the TimesTen Classic databases involved in either a unidirectional or bidirectional replication scheme with only a few seconds of service interruption.
If you want to verify if you are connected to a single-instance (TimesTen Classic) database or a distributed (TimesTen Scaleout) database, call for the value of the ttGridEnable
parameter with the ttConfiguration
built-in procedure. The built-in procedure returns ttGridEnable=1
for distributed databases and returns ttGridEnable=0
for single instance databases.
Command> CALL ttConfiguration('ttGridEnable'); < TTGridEnable, 1 > 1 row found. Command>
For more information on the ttConfiguration
built-in procedure, see "ttConfiguration" in the Oracle TimesTen In-Memory Database Reference.