The TimesTen daemon starts when TimesTen is installed. The daemon runs in the background.
The TimesTen daemon performs the following functions:
Starts the TimesTen Server
Manages shared memory access
Coordinates process recovery
Keeps management statistics on what databases exist, which are in use, and which application processes are connected to which databases
Manages RAM policy for TimesTen Classic
If requested, starts replication processes and the cache agent.
Application developers do not interact with the daemon directly. No application code runs in the daemon and application developers do not generally have to be concerned with it. Application programs that access TimesTen databases communicate with the daemon transparently using TimesTen internal routines.
The following sections discuss interaction with the TimesTen daemon:
You must be the instance administrator to start and stop the TimesTen daemon.
Installing the TimesTen daemon startup scripts (the setuproot scripts) automatically starts the daemon whenever the operating system reboots.
Install the setuproot script as root.
In TimesTen Classic, the setuproot script is located in the timesten_home/bin directory:
% cd $TIMESTEN_HOME/bin % setuproot -install
For TimesTen Scaleout, the directions on how to install the setuproot script are in the "Setting instances to automatically start at system startup" section in the Oracle TimesTen In-Memory Database Scaleout User's Guide. Also, the daemon is automatically started for each data instance as part of the operations executed for the ttGridAdmin dbOpen or ttGridAdmin modelApply commands.
The root user can start the daemon by executing the daemon startup script. The following table shows the location of the daemon startup script by platform.
| Platform | Location of daemon startup script |
|---|---|
| Linux | /etc/init.d/tt_instance_name |
| AIX | /etc/init.d/tt_instance_name |
For TimesTen Classic, the instance administrator must manually start and stop the daemon, after each system reboot, unless the setuproot script has been executed. To manually start and stop the TimesTen main daemon, you can use the ttDaemonAdmin utility with the -start or -stop option.
For TimesTen Scaleout, if you need to manually start the daemon for a data instance, you can execute the ttDaemonAdmin -start or -stop options within the ttGridAdmin instanceExec command.
For more information, see "ttDaemonAdmin" and "Execute a command or script on grid instances (instanceExec)" in the Oracle TimesTen In-Memory Database Reference.
You can shut down your TimesTen application using commands described in the following sections:
A application within TimesTen Classic consists of a database that has been allocated shared memory, user connections, and possibly replication and cache agents for communication with other TimesTen or Oracle databases.
To close all active connections to the TimesTen Classic 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 you want to unload the TimesTen Classic database, see "Unloading a database from memory for TimesTen Classic" for full directions.
With TimesTen Scaleout, you can perform the following to disconnect all TimesTen applications from the database:
Close the database to user connections. The ttGridAdmin dbClose command disables new user connections to a database.
Disconnect all applications from the database. The ttGridAdmin dbDisconnect command terminates all user connections to a database.
Unload the database from memory. The ttGridAdmin dbUnload command unloads every element of the database from the memory of their respective hosts.
See "Unloading a database from memory" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information.
The timesten.conf file contains TimesTen daemon attributes.
In TimesTen Scaleout, you can import the values in the timesten.conf file by using the ttGridAdmin instanceConfigImport command. For more details, see "Import instance configuration attributes (instanceConfigImport)" in the Oracle TimesTen In-Memory Database Reference.
In TimesTen Classic, you can create or change values for the timesten.conf file through connection attributes, through editing this file by hand, or with the ttInstanceCreate or ttInstanceModify utilities.
Use the ttInstanceModify utility to make changes to the timesten.conf file for most commonly changed attributes. If you cannot use ttInstanceModify to change a particular attribute and must modify the timesten.conf file directly, stop the TimesTen daemon before you change the file. Restart the TimesTen daemon after you have finished changing the file. To change TimesTen Server attributes, it is only necessary to stop the server. It is not necessary to stop the TimesTen daemon.
For more information about the ttInstanceCreate and the ttInstanceModify utilities, see "ttInstanceCreate" and "ttInstanceModify" in the Oracle TimesTen In-Memory Database Reference.
For more information about the timesten.conf file, see "TimesTen Instance Configuration File" in the Oracle TimesTen In-Memory Database Reference.
On Linux and UNIX, the timesten.conf file is located in the daemon home directory:
timesten_home/conf
Some features that the timesten.conf file controls are:
The network interfaces on which the daemon listens
The minimum and maximum number of TimesTen subdaemons that can exist for the TimesTen instance
Whether or not the TimesTen Server is started
Whether or not you use shared memory segments for client/server inter-process communication
The number of Server processes that are prespawned on your system
The location and size of daemon log files and user log files
The duration of daemon logging to save for critical events
Backward compatibility
The maximum number of users for a TimesTen instance
Data access across NFS mounted systems. This is for Linux only.
The TNS_ADMIN value for an application using TimesTen Cache, OCI, Pro*C/C++, or ODP.NET. This option cannot be modified in this file.
Modifying the default database recovery after a fatal error
The rest of this section includes the following topics:
By default, the TimesTen main daemon, all subdaemons and agents listen on a socket for requests, using any available address. All TimesTen utilities and agents use the loopback address to talk to the main daemon, and the main daemon uses the loopback address to talk to agents.
The listen_addr attribute in the timesten.conf file tells the TimesTen daemons to listen on the specific address indicated in the value supplied. The address specified with this option can be either a host name or a numerical IP address.
The listen_addr attribute exists for situations where a server has multiple network addresses and multiple network cards. In this case it is possible to limit the network addresses on which the TimesTen daemon is listening to a subset of the server's network addresses. This is done by making entries only for those addresses on which the daemon listens. These possibilities exist:
Given a situation where a server has a "public" network address that is accessible both inside and outside the local network and a "private" address that is accessible only within the local network, adding a listen_addr attribute containing only the private address blocks all communications to TimesTen coming on the public address.
By specifying only the local host, the TimesTen main daemon can be cut off from all communications coming from outside the server and communicate only with local clients and subdaemons.
There is no relationship between TimesTen replication and the listen_addr parameter and there is no requirement for enabling the listen_addr attribute when replication is enabled. If replication is going to be used in an environment where listen_addr is enabled, then the replication nodes need to know the allowable network addresses to use. However, if no -listenaddr attribute is enabled replication still works.
To explicitly specify the address on which the daemons should listen on a separate line in the timesten.conf file, enter:
listen_addr=address
For example, if you want to restrict the daemon to listen to just the loopback address, you say either:
listen_addr=127.0.0.1
or
listen_addr=localhost
This means that only processes on the local system can communicate with the daemon. Processes from other systems would be excluded, so you would not be able to replicate to or from other systems, or grant client access from other systems.
If you have multiple ethernet cards on different subnets, you can specify listen_addr entries to control which systems can connect to the daemon.
You can enter up to four addresses on which to listen by specifying the attribute and a value on up to four separate lines in the timesten.conf file. In addition to the addresses you specify, TimesTen always listens on the loopback address.
By default, TimesTen uses the IPv4 protocol. To enable the daemon to listen on IPv6, you must enter on a separate line in the timesten.conf file:
enableIPv6=1
and
listen_6_addr=address
You can specify an IPv6 address with the listen_6_addr attribute to enable IPv6.
Specifying the enableIPv6 attribute with one or more listen_addr or listen_6_addr attributes adds the IPv6 loopback interface to the list.
If you specify the enableIPv6 attribute without specifying any addresses with the listen_addr or listen_6_addr attributes, then the daemon listens on any IPv6 interface as well as any IPv4 interface.
The address specified with this option can be either a host name or a numerical IP address. See "Determining the daemon listening address" for specifics on the listen_addr option.
If one or more listen_addr attributes are provided, the daemons listen on the specified IPv4 interfaces, with the IPv4 loopback address being added to the list if not specified. If only enableIPv6 is specified, the daemons listen on both the IPv4 ANY interface and the IPv6 ANY interface.
You can specify both listen_addr and listen_6_addr attributes. If you specify one or more listen_6_addr attributes, the daemons listen on the specified IPv4 or IPv6 interfaces, with both the IPv4 and IPv6 loopback interfaces being added if not specified. If the name resolver returns multiple IPv4 and/or IPv6 addresses for a name, the daemons listen on all of the names.
The main TimesTen daemon spawns subdaemons dynamically as they are needed. You can manually specify a range of subdaemons that the daemon may spawn, by specifying a minimum and maximum.
At any point in time, one subdaemon is potentially needed for TimesTen process recovery for each failed application process that is being recovered at that time.
By default, TimesTen spawns a minimum of 4 subdaemons and specifies the default maximum number of subdaemons at 50. However, you can change these settings by assigning new values to the min_subs and max_subs attributes in the timesten.conf file.
You can configure a range for all shared memory keys used by TimesTen with the shmkey_range daemon attribute. You can constrain shared memory keys to a specific range to prevent shared memory collisions. However, if you use this option, it is your responsibility to ensure that no other shared memory segments use shared memory keys in the specified range.
Note:
This option is only available on UNIX or Linux platforms. This option cannot be used for Windows platforms.The syntax is as follows:
shmkey_range=low-high
For example:
shmkey_range=0x4000000-0x40FFFFFF
There can be no space in the low-high clause. The range is inclusive; thus, in the preceding example, both 0x40000000 and 0x40FFFFFF are valid keys. In addition, the minimum range size is 16.
With this option, it is possible to run out of shared memory keys, especially if there multiple invalidations or there are more TimesTen databases in use than originally anticipated.
If a user provides any of the following invalid values for the shared memory keys, then the TimesTen daemon aborts the startup process.
Invalid numeric strings
Only one number is specified for the range
The first number is greater than the second number in the range specification
The range size is less than 16.
The range is specified incorrectly.
This section includes the following topics:
The TimesTen Server is a child process of the TimesTen daemon that operates continually in the background. To modify the TimesTen Server attributes, you must do the following:
Stop the TimesTen Server.
Modify the attributes in the timesten.conf file as described in the following sections.
Restart the TimesTen Server.
The server_port=portno attribute in the timesten.conf file tells the TimesTen daemon to start the TimesTen Server and what port to use. The portno is the port number on which the server listens.
Each TimesTen Client connection requires one server process. By default, a server process is spawned when a client requests a connection. In TimesTen Classic, you can prespawn a pool of reserve server processes by setting the server_pool attribute in the timesten.conf file on the server system. These server processes are immediately available for a client connection, which improves client/server connection performance.
The server_pool=number attribute in the timesten.conf file on the server system tells the TimesTen Server to create number processes. If this option is not specified, no processes are prespawned and kept in the reserve pool.
When a new connection is requested, if there are no items in the server pool, a new process is spawned, as long as you have not met the operating system limit.
If you request more process than allowed by your operating system, a warning is returned. Regardless of the number of processes requested, an error does not occur unless a client requests a connection when no more are available on the system, even if there are no processes remaining in the reserve pool.
Changes to the TimesTen Server take effect when the Server is restarted.
By default, TimesTen creates only one connection to a Server for each child server process. You can set multiple connections to a single TimesTen Server, either by using the Server connection attributes (as described in "Defining Server DSNs for TimesTen Server on a Linux or UNIX system" or the "TimesTen Server connection attributes" section in the Oracle TimesTen In-Memory Database Reference) or by setting the TimesTen daemon attributes described in this section.
Changes to TimesTen Server settings do not occur until the TimesTen Server is restarted. To restart the Server, use the following command:
% ttDaemonAdmin -restartserver
Note:
In the case that you have set both the Server connection attributes and these daemon attributes, the value of the Server connection attributes takes precedence.To run a child server process in multithreaded mode so that a single server process can service multiple client connections to a database, add the following attribute to the timesten.conf file:
max_conns_per_server=NumberOfClientConnections
See "Defining Server DSNs for TimesTen Server on a Linux or UNIX system" for more details.
To specify the number of child server processes for a particular Server DSN that will use round-robin connection distribution (when max_conns_per_server >1), add the following attribute to the timesten.conf file:
servers_per_dsn=NumberOfChildServerProcesses
By default (value=1), the first max_conns_per_server client connection to a Server DSN is assigned to a single child server process, the next max_conns_per_server connection is assigned to a second child server process and so on. See "Defining Server DSNs for TimesTen Server on a Linux or UNIX system" for a full description of how the servers_per_dsn and max_conns_per_server attributes relate to each other to control how connections are distributed over server processes.
To set the size of the child server process thread stack for each client connection, add the following attribute to the timesten.conf file:
server_stack_size=ThreadStackSize
See "Defining Server DSNs for TimesTen Server on a Linux or UNIX system" for more details.
Note:
These changes to the TimesTen Server do not occur until the TimesTen daemon is restarted.By default, TimesTen uses TCP/IP communication between applications linked with the TimesTen Client driver and the TimesTen Server.
Where the client application resides on the same system as the TimesTen Server, you can alternatively use shared memory for the inter-process communication (IPC), which can increase your performance. Before using shared memory as IPC verify that you have configured your system correctly.
See "Linux prerequisites" in the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide.
The server_shmipc attribute in the timesten.conf file tells the TimesTen Server to accept a client connection that intends to use a shared memory segment for IPC.
If this attribute is missing, add this line to the timesten.conf file to start the TimesTen Server with shared memory IPC capability when the TimesTen daemon is restarted.
If the attribute exists, change the value of the server_shmipc attribute to 0 to not use shared memory IPC. The TimesTen Server is no longer started with shared memory IPC capability when the TimesTen daemon starts.
Note:
TimesTen supports a maximum of 16 different instances of the shared memory IPC-enabled server. If an application tries to connect to more than 16 different shared memory segments it receives an ODBC error.The server_shmsize size attribute in the timesten.conf file tells the TimesTen Server to create a shared memory segment of the specified size in MB.
If this attribute is missing, the TimesTen Server creates a shared memory segment of 64MB.
An appropriate value for the shared memory segment depends on:
The expected number of concurrent client/server connections to all databases that belong to an instance of the TimesTen Server.
The number of concurrent allocated statements within each such connection.
The amount of data being transmitted for a query.
Some guidelines for determining the size of the shared memory segment include:
The maximum size allowed is 1 gigabyte.
TimesTen needs 1 MB of memory for internal use.
Each connection needs a fixed block of 16 KB.
Each statement starts with a block of 16 KB for the IPC. But this size is increased or decreased depending upon the size of the data being transmitted for a query. TimesTen increments the statement buffer size by doubling it and decreases it by halving it.
For example, if the user application anticipates a max of 100 simultaneous shared-memory-enabled client/server connections, and if each connection is anticipated to have a maximum of 50 statements, and the largest query returns 128 KB of data, use this formula to configure the server_shmsize:
server_shmsize = 1 MB + (100 * 16) KB + (100 * 50 * 128) KB
= 1 MB + 2 MB + 625 MB = 628 MB
This is the most memory required for this example. The entire memory segment would be used only if all 100 connections have 50 statements each and each statement has a query that returns 128 KB of data in a row of the result.
In this example, if you configured the server_shmsize to 128 MB, either a new shared-memory-enabled client/server connection is refused by the TimesTen Server or a query may fail due to lack of resources within the shared memory segment.
Once configured, to change the value of the shared memory segment you must stop the TimesTen Server. Stopping the server detaches all existing client/server connections to any database that is associated with that instance of the TimesTen Server. The steps for modifying the value of the server_shmsize attribute are:
The noserverlog attribute in the timesten.conf file tells the TimesTen daemon to turn off logging of connects and disconnects from the client applications.
If the TimesTen Server is installed, you can enable or disable logging of connect and disconnect messages by:
To enable logging, change the value of the noserverlog attribute to 1.
To disable logging, change the value of the noserverlog attribute to 0.
As the daemon operates, it generates error, warning, and informational messages. These messages may be useful for TimesTen system administration and for debugging applications.
By default, TimesTen messages and diagnostic information are stored in:
A user error log that contains error message information. Generally, these messages contain information on actions you may need to take. The default file is timesten_home/diag/tterrors.log.
A daemon log file containing everything in the user error log plus information used by TimesTen Customer Support. The default file is timesten_home/diag/ttmesg.log.
An invalidation file containing diagnostic information when TimesTen invalidates a database. This file provides useful troubleshooting information for TimesTen Customer Support. The invalidation file is created and named based on the value specified by the DataStore connection attribute. This connection attribute is not a file name. For example on Linux and UNIX systems, if the DataStore connection attribute is /home/ttuser/AdminData, the actual invalidation file name has a suffix, .inval, /home/ttuser/AdminData.inval. See "Critical event logging" for more details on the invalidation file.
Critical events log files contain a collection of daemon log entries at the moment of a critical event to assist when diagnosing critical failures. See "Critical event logging" for more details.
You can specify the location and size of the daemon log files and user log files, as well as the number of files to keep stored on your system in the TimesTen instance configuration file (the timesten.conf file).
You can also specify the syslog facility used to log TimesTen daemon and subdaemon messages on Linux or UNIX. On a separate line of the timesten.conf file add:
facility=name
Possible name values are: auth, cron, daemon, local0-local7, lpr, mail, news, user, or uucp.
For more information, see "TimesTen Instance Configuration File" in the Oracle TimesTen In-Memory Database Reference.
The ttDaemonLog utility enables you to control the type of events that TimesTen writes to and fetches from the TimesTen user and error logs. You can also display all messages or selected categories of messages from the log to the standard output with this utility. For more information, see "ttDaemonLog" in the Oracle TimesTen In-Memory Database Reference.
When critical events occur, TimesTen collects the daemon log entries at the moment of the critical event to assist when diagnosing critical failures. An example of critical events include database failure or a log-based catch up failure. Database invalidation occurs when TimesTen detects that the data in the database is corrupt and therefore unusable.
TimesTen generates critical event files containing a snippet of the daemon log file that was collected at the moment of the critical event. Critical event log files are created and stored in the same directory as the daemon log files (specified by supportlog configuration attribute in the timesten.conf file). Critical event log files are named with the format of ttmesg.log.ts_timestamp.gz where timestamp is the current time on the host.
When a critical event occurs, TimesTen records in the daemon log file that critical event information was collected and the name of the critical event log file.
If a database invalidation occurs, then TimesTen records in the .inval file that critical event information was collected at the time of the database invalidation and the name of the critical event log file. The .inval file is located in the same directory configured as the DataStore directory.
If more than one critical event occurs in quick succession, TimesTen collects only new information for each subsequent event in the next critical event log file.
You can configure the duration of the daemon log collection with the daemon_log_snippet_interval_in_mins configuration attribute in the timesten.conf file. As with all changes to the timesten.conf file, you must restart the main daemon for any change to take effect. See the "TimesTen Instance Configuration File" in the Oracle TimesTen In-Memory Database Reference for details on this configuration attribute.
Example 4-1 Example output in the daemon log when critical events occur
The occurrence of a critical event and the name of the critical event log file are noted in the daemon log file. The following example shows the message you would see in the daemon log file if two critical events occur in quick succession.
17:08:00.224 Err : : 12532: A critical event has happened. Saving last 600 seconds snippet of daemon log at /timesten/instance/diag/ttmesg.log.ts_1568160480.gz. 17:08:00.643 Err : : 12532: Read 543878 bytes from daemon log file and wrote into the daemon log snippet file located at /timesten/instance/diag/ttmesg.log.ts_1568160480.gz 17:11:12.657 Err : : 12532: A critical event has happened. Saving last 600 seconds snippet of daemon log at /timesten/instance/diag/ttmesg.log.ts_1568160672.gz. 17:11:12.657 Err : : 12532: Part of the daemon log snippet has already been recorded in a prior snippet file ending with timestamp 1568160480.gz 17:11:13.077 Err : : 12532: Read 2678582 bytes from daemon log file and wrote into the daemon log snippet file located at /timesten/instance/diag/ttmesg.log.ts_1568160672.gz
After which, you can evaluate the collected log records in the specified ttmesg.log.ts_timestamp.gz files.
Example 4-2 Example output in the .inval file for database invalidation
Any database invalidation event and the name of the critical event log file are noted in the .inval file. The following example shows the messages you could see in the .inval file if two critical events occur in quick succession.
2019-09-10 17:08:00.752 Hostname: myhost Invalidated data store: /timesten/instance/datastores/mydb Data store created: 2019/09/10 17:04:25 TimesTen Release 18.1.3.1.0 (Linux x86-64, 64-bit dbg) (myhost) Data store created by Release 18.1.3.1.0 (Linux x86-64, 64-bit dbg) (myhost) Source: Data store marked invalid by master daemon: grid LBCU pre-condition check failed A critical event has happened. Saving last 600 seconds snippet of daemon log at /timesten/instance/diag/ttmesg.log.ts_1568160480.gz. Read 953765 bytes from daemon log file and wrote into the daemon log snippet file located at /timesten/instance/diag/ttmesg.log.ts_1568160480.gz 2019-09-10 17:11:13.905 Hostname: myhost Invalidated data store: /timesten/instance/datastores/mydb Data store created: 2019/09/10 17:04:25 TimesTen Release 18.1.3.1.0 (Linux x86-64, 64-bit dbg) Data store created by Release 18.1.3.1.0 (Linux x86-64, 64-bit dbg) Source: Data store marked invalid by master daemon: subdaemon managing database exited or died A critical event has happened. Saving last 600 seconds snippet of daemon log at /timesten/instance/diag/ttmesg.log.ts_1568160673.gz. Part of the daemon log snippet has already been recorded in a prior snippet file ending with timestamp ts_1568160480.gz Read 781026 bytes from daemon log file and wrote into the daemon log snippet file located at /timesten/instance/diag/ttmesg.log.ts_1568160673.gz
After which, you can evaluate the collected log records in the specified ttmesg.log.ts_timestamp.gz files.