| Oracle® TimesTen In-Memory Database Operations Guide 11g Release 2 (11.2.2) E21633-12 |
|
|
View PDF |
| Oracle® TimesTen In-Memory Database Operations Guide 11g Release 2 (11.2.2) E21633-12 |
|
|
View PDF |
You can open client/server connections across a network to the TimesTen database with the TimesTen Client and TimesTen Server.
The following sections describe the TimesTen Client/Server and how to connect using them:
The TimesTen Server is a process that runs on a server system that takes network requests from TimesTen Clients and translates them into operations on databases on the server system. This enables clients to connect to databases that are located on different systems, potentially running a different platform and operating system bit level.
You can install the TimesTen Client on a separate or the same system as the TimesTen Server. If you install the TimesTen Client on the same system as the TimesTen Server, you can use it to access TimesTen databases on the local system. For example, this is useful when you want a 32-bit application to access a 64-bit database on the same system, for platforms that support both 32-bit and 64-bit applications.
Note:
You can create a client/server connection between any combination of platforms that TimesTen supports.Figure 2-1 demonstrates how the TimesTen Client and TimesTen Server communicate using their respective drivers.
Figure 2-1 Diagram of TimesTen Client and TimesTen Server
TimesTen Client: To access TimesTen databases on remote systems, link your application with the TimesTen Client ODBC driver. The application then communicates with the TimesTen Server process. Using the TimesTen Client driver, applications can connect transparently to TimesTen databases on a remote or local system that has the TimesTen Server and Data Manager installed.
You can link a client application directly with the TimesTen Client driver or with the Windows ODBC driver manager to access the TimesTen database. TimesTen supplies a driver manager for UNIX and Windows with the Quick Start sample applications. Note that there are performance considerations in using a driver manager.
Also, you can link a client application through a provided interface, like JDBC, OCI or Pro*C/C++, to access the TimesTen database.
Note:
For details on how the application can use different drivers and interfaces to access a TimesTen database, see "Connecting to TimesTen with ODBC and JDBC drivers"TimesTen Server: On the server system, the TimesTen Server uses the TimesTen Data Manager ODBC driver. The server's responsibility is to listen for requests from a client application, process the request through the Data Manager ODBC driver, and then send the results and any error information back to the client application.
Note:
For details on compiling and linking TimesTen applications, see "Compiling Java applications" in the Oracle TimesTen In-Memory Database Java Developer's Guide or "Compiling and linking applications" the Oracle TimesTen In-Memory Database C Developer's Guide.The following sections describe the restrictions and the communication protocols for client/server communication:
The following are the restrictions on client/server communication:
XLA cannot be used over a client/server connection.
On UNIX, some TimesTen utilities only work over direct connections, such as ttAdmin, ttRepAdmin, and ttBackup. The utilities that can be executed over a client/server connection on the UNIX platform are named with a suffix of CS, such as ttIsqlCS, ttBulkCpCS, ttMigrateCS and ttSchemaCS. These utilities have been linked with the TimesTen Client driver and can be used to connect to client DSNs when accessing a database over a client/server connection. Each utility listed in the Oracle TimesTen In-Memory Database Reference provides the name of the client/server version of that utility, if there is one.
The ttCacheUidPwdSet built-in procedure cannot be used over a client/server connection.
You cannot connect with an external user defined on one host to a TimesTen data source on a remote host. There are no restrictions for connecting with internal users.
Internal users can only be created or altered over a direct connection and not over a client/server connection to a TimesTen database. Thus, you can only execute the CREATE USER or ALTER USER statements using a direct connection to the TimesTen database. Once created, the user that connects from the client to the server must be granted the CREATE SESSION privilege or the connection fails. For more information on how to create the user on the TimesTen database and how the administrator grants the CREATE SESSION privilege, see "Creating or identifying users to the database" and "Granting privileges to connect to the database".
On UNIX, TimesTen does not allow a child process to use a connection opened by its parent. Any attempt from a child process using fork() to use a connection opened by the parent process returns an error.
By default, a server process is spawned at the time a client requests a connection. By setting the -serverPool option in the ttendaemon.options file on the server system, you can pre-spawn a reserve pool of server processes. See "Prespawning TimesTen Server processes" for details.
The following sections describe the communication protocols that the TimesTen Client can use with the TimesTen Server:
By default, the TimesTen Client communicates with the TimesTen Server using TCP/IP sockets. This is the only form of communication available when the TimesTen Client and Server are installed on different systems.
If both the TimesTen Client and Server are installed on the same system, applications using the TimesTen Client ODBC driver may use a shared memory segment for inter-process communication (IPC). Using a shared memory segment provides better performance than TCP/IP communication. To use a shared memory segment as communication, you must:
Configure the server options to use shared memory communication in the ttendaemon.options file. See "Using shared memory for Client/Server IPC".
Define the Network Address as ttShmHost in the logical server name. See "Defining a logical server name" for details.
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 error.On UNIX platforms, if both the TimesTen Client and Server are installed on the same system, you can use UNIX domain sockets for communication. Using a shared memory segment allows for the best performance but slightly greater memory usage. Using UNIX domain sockets allows for improved performance over TCP/IP, but with less memory consumption than a shared memory segment connection. To use domain sockets, you must define the Network Address of the logical server as ttLocalHost. See "Defining a logical server name" for more information.
Note:
Before configuring the TimesTen Client and Server, read "Connecting to TimesTen with ODBC and JDBC drivers" and "Specifying Data Source Names to identify TimesTen databases".The following sections describe how to connect an application to a TimesTen database using TimesTen Client and Server:
Before the client application can connect to a TimesTen database, the user must configure, as shown in Figure 2-2, the client DSN, optionally a logical server name, and a server DSN to uniquely identify the desired TimesTen database.
Figure 2-2 Configuring for a client/server connection
The client application refers to the client DSN when initiating a connection. With the following details, the connection request is resolved to be able to connect to the intended TimesTen database:
The client DSN is configured in either the user or system odbc.ini file with the server host name, either the logical server name or the actual server system name, and the server DSN that identifies the TimesTen database on the server.
The logical server name is an optional configuration on the client. When used, it specifies the server host name where the TimesTen database is installed. This is used when you want to hide or simplify the server host name. You must use the logical server name when using shared memory IPC or UNIX domain sockets.
The server DSN is configured in the system odbc.ini file with the TimesTen database name and its connection attributes. The connection attributes specify how the TimesTen database is loaded and configured, and how the connections to it are to be controlled or managed.
Thus, when these are configured correctly, the client application can use the client DSN to locate and connect to the TimesTen database. The client DSN defines the server system and the server DSN. The server DSN, in turn, specifies the TimesTen database on that server, how the database is to be loaded, and how connections are to be managed.
The following sections describe what you must install on which node for client/server connections:
The following sections describe how to install and configure TimesTen when the Client and Server are of the same TimesTen release:
Perform the following tasks on the system on which the TimesTen database resides. This system is called the server system.
Install the TimesTen Server. For information on how to install the TimesTen Server, see the Oracle TimesTen In-Memory Database Installation Guide.
Create and configure a server DSN corresponding to the TimesTen database. See "Defining server DSNs on a TimesTen Server system". Set TimesTen connection attributes in the server DSN. See "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
Perform the following tasks on the system where the client application resides. This system is called the client system.
Install the TimesTen Client. For information on how to install the TimesTen Client, see the Oracle TimesTen In-Memory Database Installation Guide.
If you are using JDBC to connect to the database, install the Java Developer's Kit (JDK) and set up the environment variables, such as CLASSPATH and the shared library search path. See "Setting the environment for Java development" in the Oracle TimesTen In-Memory Database Java Developer's Guide for details.
Create and configure a client DSN corresponding to the server DSN. See "Creating and configuring client DSNs on UNIX" and "Creating and configuring client DSNs on Windows".
For OCI and Pro*C/C++ client/server connections, configure the application to use either tnsnames.ora or easy connect as described in "Connecting to a TimesTen database from OCI" in the Oracle TimesTen In-Memory Database C Developer's Guide.
Link client/server applications as follows:
Link C and C++ client/server applications as described in "Linking options" in the Oracle TimesTen In-Memory Database C Developer's Guide.
Link OCI or Pro*C/C++ applications in the same manner as any OCI or Pro*C/C++ direct connect applications, which is described in "TimesTen Support for OCI" and "TimesTen Support for Pro*C/C++" in the Oracle TimesTen In-Memory Database C Developer's Guide.
A TimesTen Client can connect to a TimesTen Server from a different release and of a different bit level. A TimesTen Client 7.0 or later release may connect to a TimesTen Server 7.0 or later release of any bit level. If you are configuring for a cross-release TimesTen Client/Server connection, install and configure as directed in "Configuring Client/Server of the same TimesTen release".
The TimesTen Server loads a driver and a TimesTen database of its own release and bit level when a TimesTen Client application connects to the TimesTen database. The TimesTen Data Manager is automatically installed on the Server system.
If you are using a local client/server connection using UNIX Domain sockets through ttLocalHost, then the platforms for the client and the server must be UNIX. The bit level and the release level for the client and server hosts must be the same.
If you are using a local client/server connection over a shared memory IPC using ttShmHost, then the platforms for the client and server can be either Windows or UNIX. The bit level may be different on the client and server hosts.
Server DSNs identify TimesTen databases that are accessed by a client/server connection. A server DSN must be defined as a system DSN and has the same configuration format and attributes as a TimesTen Data Manager DSN. For a description of DSNs and instructions on creating them, see "Creating a Data Manager DSN on Windows" or "Creating a Data Manager DSN on UNIX".
Note:
You can add or configure a server DSN while the TimesTen Server is running.Because a server DSN identifies databases that are accessed by a TimesTen Server, a server DSN can be configured using the same connection attributes as a Data Manager DSN. In addition, there are connection attributes that are only allowed within the server DSN specification. These attributes enable you to specify multiple client/server connections to a single server.
Note:
Some connection attributes, including the ones described in the following sections, can be configured in the TimesTen daemon options file (
ttendaemon.options). If you have set the same connection attributes in both the server DSN and the daemon options file, the value of the connection attributes in the server DSN takes precedence.
For a description of the TimesTen daemon options see "Managing TimesTen Client/Server options".
The following sections describe the server DSN attributes in the context of the odbc.ini file or the ODBC Data Source Administrator:
Note:
For a complete description of the TimesTen Server connection attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.By default, TimesTen creates only one connection to a server per child process. However, the following Server connection attributes enable you to specify multiple client/server connections to a single TimesTen Server:
Note:
These attributes are read at first connection. Changes to TimesTen Server settings do not occur until the TimesTen server is restarted. To restart the Server, use the following command:ttDaemonAdmin -restartserver
MaxConnsPerServer: Set the maximum number of client connections that are handled by a single server process. The server is referenced by the server DSN. The server may have multiple server processes, where each process can only have the maximum number of connections as specified by this attribute.
ServersPerDSN: You can have multiple server processes serving multiple incoming connections on the server. The ServersPerDSN attribute specifies the number of server processes that are initially spawned on the server. Each new incoming connection spawns a new server process up to the ServersPerDSN. When ServersPerDSN is reached, the existing server processes handle multiple connections up to the number specified in MaxConnsPerServer.
ServerStackSize: Set the size of the stack on the Server for each connection.
The MaxConnsPerServer and ServersPerDSN attributes are related. Neither of these attributes limits the number of client connections to given DSN. Instead, they control how connections are distributed over server processes. For example, if MaxConnsPerServer is set to 2 and ServersPerDSN is set to 5, then the following occurs:
Connection 1 arrives at the server, the first server process is started for this connection. Connections 2 through 5 arrive at the server, server processes 2 through 5 are initiated where each server process services a connection.
Connection 6 arrives at the server. Since ServersPerDSN is reached, and MaxConnsPerServer is not, connection 6 is given to the first server process. Incoming connections 7 through 10 are given respectively as the second connection to server processes 2 through 5.
Connection 11 arrives at the server. Both ServersPerDSN and MaxConnsPerServer are reached, so server process 6 is started to handle connection 11.
If you anticipate having more than one connection using the server DSN, specify appropriate values for the server DSN attributes as needed. On Windows in the ODBC Data Source Administrator, these are specified on the Server tab.
Figure 2-3 Server tab in TimesTen ODBC Administrator
A logical server name is a definition for a server system on the TimesTen Client. In some cases, such as when using a communication protocol other than TCP/IP for local client/server or the TimesTen Server process is not listening on the default TCP/IP port, you must define a logical server name on the client system. In these cases, the client DSN must refer to the logical server name. However, in most cases when the communication protocol used is TCP/IP, the client DSN can refer directly to the server host name without having to define a logical server name.
The following sections demonstrate how to define a logical server name on Windows or UNIX platforms:
To create and configure a logical server name:
On the Windows Desktop from the Start menu, select Settings, Control Panel, Administrative Tools, and finally Data Sources (ODBC).
This opens the ODBC Data Source Administrator.
Click User DSN or System DSN.
Select a TimesTen client DSN and click Configure. If no client DSN exists, click Add, select TimesTen Client 11.2.2 and click Finish. This opens the TimesTen Client DSN Setup dialog.
Click Servers. This opens the TimesTen Logical Server List dialog.
Click Add. This opens the TimesTen Logical Server Name Setup dialog.
In the Server Name field, enter a logical server name.
In the Description field, enter an optional description for the server.
In the Network Address field, enter the host name or IP address of the server system. The Network Address must be one of:
| Type of connection | Network Address |
|---|---|
| Remote client/server connection | The name of the system where the TimesTen Server is running. For example, server.mycompany.com |
| Local client/server connection that uses shared memory for inter-process communication (IPC) | ttShmHost
In order to use shared memory as IPC, verify that you have configured your system correctly. See "Shared memory communication". |
In the Network Port field, TimesTen displays the port number on which the TimesTen Logical Server listens by default. If the TimesTen Server is listening on a different port, enter that port number in the Network Port field.
For example:
Click OK, then click Close in the TimesTen Logical Server List dialog to finish creating the logical server name.
On the Windows Desktop on the client system from the Start menu, select Settings, and then select Control Panel.
Double click ODBC. This opens the ODBC Data Source Administrator.
Select a TimesTen client DSN and click Configure. This opens the TimesTen client DSN Setup dialog.
Click Servers. This opens the TimesTen Logical Server List dialog.
Select a server name from the TimesTen Servers list.
Click Delete.
Define logical server names in a file named by the SYSTTCONNECTINI environment variable. This file is referred to as the ttconnect.ini file. The file contains a description, a network address and a port number.
TimesTen searches for the logical server in this order:
In the file specified by the SYSTTCONNECTINI environment variable, if it is set
In the install_dir/info/sys.ttconnect.ini file
TimesTen uses the ttconnect.ini file to define the names and attributes for servers and the mappings between logical server names and their network addresses. This information is stored on the system where the TimesTen Client is installed. By default, the ttconnect.ini file is install_dir/info/sys.ttconnect.ini.
To override the name and location of this file at runtime, set the SYSTTCONNECTINI environment variable to the name and location of the ttconnect.ini file before launching the TimesTen application.
You can define short-hand names for TimesTen Servers on UNIX in the ttconnect.ini file. The format of a TimesTen Server specification in the ttconnect.ini file is shown in Table 2-1.
Table 2-1 TimesTen Server format in the ttconnect.ini file
| Component | Description |
|---|---|
|
[ |
Logical server name of the TimesTen Server system |
|
|
Description of the TimesTen Server |
|
|
The DNS name, host name or IP address of the system on which the TimesTen Server is running. |
|
|
The TCP/IP port number where the TimesTen Server is running. Default for TimesTen release 11.2.2 is 53393 for 32-bit platforms and 53397 for 64-bit platforms. |
The Network Address must be one of the following:
| Type of connection | Network address |
|---|---|
| Remote client/server connection | The name of the system where the TimesTen Server is running. For example, server.mycompany.com |
| Local client/server connection that uses UNIX domain sockets | ttLocalHost |
| Local client/server connection that uses shared memory for inter-process communication | ttShmHost |
Example 2-1 Defining a logical server name
This example from a ttconnect.ini file defines a logical server name, LogicalServer_1122, for a TimesTen Server running on the system server.mycompany.com and listening on port 53397. The instance name of the TimesTen installation is tt1122_64.
[LogicalServer_1122] Description=TimesTen Server 11.2.2 Network_Address=server.mycompany.com TCP_Port=53397
Example 2-2 Using UNIX domain sockets for communication
If both the client and server are on the same UNIX system, applications using the TimesTen Client ODBC driver may improve performance by using UNIX domain sockets for communication.
The logical server name must also define the port number on which the TimesTen Server is listening so that multiple instances of the same version of TimesTen Server can be run on the same system. To achieve this, the logical server name definition in ttconnect.ini file might look like:
[LocalHost_1122] Description=Local TimesTen Server 11.2.2 through domain sockets Network_Address=ttLocalHost TCP_Port=53397
Example 2-3 Configuring shared memory for inter-process communication
If both the client and server are on the same system, applications can use shared memory for inter-process communication. This may result in the best performance.
The logical server name must also define the port number on which the TimesTen Server is listening in order to make the initial connection. To achieve this, the logical server name definition in ttconnect.ini file might look like:
[ShmHost_1122] Description= Local TimesTen Server 11.2.2 through shared memory Network_Address=ttShmHost TCP_Port=53397
A client DSN specifies a remote database and uses the TimesTen Client. The client DSN can be defined as a user or as a system DSN. A client DSN refers to a TimesTen database indirectly by specifying a hostname, DSN pair, where the hostname represents the server system on which TimesTen Server is running and the DSN refers to a server DSN that is defined on that host. These are configured within the client DSN connection attributes.
Note:
For a complete description of the TimesTen client connection attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.Alternatively, you can configure connection attributes at runtime in the connection string that is passed to the ODBC SQLDriverConnect function or the URL string that is passed to the JDBC DriverManager.getConnection() method. For example, you could use the TTC_Server_DSN attribute in either the connection string or the client DSN for a client to specify which DSN it should use on the server.
Note:
If you configure any of the server DSN data store or first connection attributes within the definition of the client DSN, they are ignored. However, the TimesTen Client allows most of the server DSN attributes (except for the DataStore connection attribute) to be passed in as part of the connection or URL string. These are transparently passed on to the server and overrides what is configured in the server DSN.The following sections describe how to create a client DSN and its attributes on either the Windows or UNIX platforms:
On Windows, use the ODBC Data Source Administrator to configure logical server names and to define client DSNs.
This section includes the following topics:
To define a TimesTen client DSN:
On the Windows Desktop from the Start menu, select Settings, Control Panel, Administrative Tools, and finally Data Sources (ODBC). This opens the ODBC Data Source Administrator.
Choose either User DSN or System DSN. For a description of user DSNs and system DSNs see "Specifying Data Source Names to identify TimesTen databases".
Click Add. This opens the Create New Data Source dialog.
Choose TimesTen Client 11.2.2. Click Finish. This opens the Oracle TimesTen client DSN Setup dialog.
In the Client DSN field, enter a name for the client DSN.
The name must be unique to the current list of defined DSNs on the system where the client application resides and can contain up to 32 characters. To avoid potential conflicts, you may want to use a consistent naming scheme that combines the logical server name with the name of the server DSN. For example, a corporation might have client DSNs named Boston_Accounts and Chicago_Accounts where Boston and Chicago are logical server names and Accounts is a server DSN.
In the Description field, enter an optional description for the client DSN.
In the Server Name or Network Address field, specify the logical server or network address of the server system.
The name can be a host name, IP address or logical server name. The logical server names defined on the client system can be found in the drop-down list. To define logical server names, click Servers.
If you do not specify a logical server name in this field, the TimesTen Client assumes that the TimesTen Server is running on the default TCP/IP port number. Therefore, if your Server is running on a port other than the default port and you do not specify a logical server name in this field, you must specify the port number in the ODBC connection string, using the TCP_Port attribute.
For more information on defining logical server names, see "Creating and configuring a logical server name on Windows".
In the Server DSN field, enter the server DSN corresponding to the database that the client application accesses.
If you do not know the name of the server DSN, click Refresh to obtain a list of server DSNs that are defined on the system specified in the Server Name or Network Address field. Select the server DSN from the drop-down list.
You must have a network connection to the system where the TimesTen Server is running.
For more information about customizing which server DSNs show in this list, see "ODBC Data Sources".
In the Connection Character Set field, choose a character set that matches your terminal settings or your data source. The default connection character set is US7ASCII. For more information, see "ConnectionCharacterSet" in Oracle TimesTen In-Memory Database Reference.
If you are using automatic client failover, you would configure the Failover Server Name, Failover Port Range, and Failover DSN. For details, see "Configuring automatic client failover".
You can define the user name, password and timeout interval for the client/server connection in the client DSN with the UID, PWD, and Timeout attributes. However, configuring the authentication in the client DSN is optional, since you can provide the user name and password when connecting. It is strongly discouraged to supply the password in the client DSN, since the password is stored unencrypted on the client.
For a description of the UID, PWD, and Timeout attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
To set the timeout interval and authentication:
In the User ID field of the Oracle TimesTen client DSN Setup dialog box, enter a user name that is defined on the server system.
In the Password field, enter the password that corresponds to the user ID. Alternatively, you can enter an encrypted password in the PwdCrypt field.
In the Timeout Interval field, enter the interval time in seconds. You can enter any non-negative integer. A value of 0 indicates that client/server operations should not time out. The default is 60 seconds. The maximum is 99,999 seconds.
Click OK to save the setup.
In this example, the TimesTen Client system is client.mycompany.com. The client application is accessing the server DSN on the remote server system, server.mycompany.com. The logical server name is LogicalServer_1122.
Note:
These examples reference the sample DSNs preconfigured in a fresh TimesTen installation.On the server system server.mycompany.com, use the ttStatus utility to verify that the TimesTen Server is running and to verify the port number it is listening on.
Using the procedure in "Defining server DSNs on a TimesTen Server system", verify that the server DSN, sampledb_1122, is defined as a system DSN on server.mycompany.com.
On the client system, client.mycompany.com, create a Logical Server Name entry for the remote TimesTen Server. In the TimesTen Logical Server Name Setup dialog:
In the Server Name field, enter LogicalServer_1122.
In the Network Address field, enter server.mycompany.com.
In the Network Port field, enter 53397. This is the default port number for the TimesTen Server on 64-bit platforms for TimesTen Release 11.2.2. This value should correspond to the value displayed by ttStatus in Step 1.
See "Creating and configuring a logical server name on Windows" for the procedure to open the TimesTen Server Name dialog and for more details.
On the client system, client.mycompany.com, create a client DSN that corresponds to the remote server DSN, sampledbCS_1122. In the TimesTen client DSN Setup dialog, enter the following values:
In the Client DSN field, enter sampledbCS_1122.
In the Server Name or Network Address field, enter LogicalServer_1122.
In the Description field, enter a description for the server. Entering data into this field is optional.
In the Server DSN field, enter sampledb_1122.
Run the client application from the system client.mycompany.com using the client DSN, sampledbCS_1122. The example below uses the ttIsql program installed with TimesTen Client.
ttIsql -connStr "DSN=sampledbCS_1122"
The next example describes how to access a TimesTen Server that is listening on a port numbered other than the default port number.
Consider that the network address of the TimesTen Server is server.mycompany.com and the Server is listening on Port 53397. The following methods can be used to connect to a Server DS:
Define the logical server name LogicalServer_1122 with server.mycompany.com as the Network Address and 53397 as the Network Port. Define Client_DSN as the client DSN with LogicalServer_1122 as the Server name and Server_DSN as the server DSN. Then, execute the command:
ttIsql -connStr "DSN=Client_DSN"
Alternatively, define the logical server name LogicalServer_tt1122 with server.mycompany.com as the Network Address and the default port number as the Network Port. Define Client_DSN as the client DSN with LogicalServer_1122 as the Server name and Server_DSN as the server DSN. Overwrite the port number in the command:
ttIsql -connStr "DSN=Client_DSN;TCP_Port=53397"
To test client application connections to TimesTen databases:
On the Windows Desktop from the Start menu, select Settings, and then select Control Panel.
Double click ODBC. This opens the ODBC Data Source Administrator.
Select the TimesTen client DSN whose connection you want to test and click Configure. This opens the TimesTen Client DSN Setup dialog.
Click Test TimesTen Server Connection to test the connection to TimesTen Server.
The ODBC Data Source Administrator attempts to connect to TimesTen Server and displays messages to indicate if it was successful. During this test TimesTen Client verifies that:
ODBC, Windows sockets and TimesTen Client are installed on the client system.
The server specified in the Server Name or Network Address field of the TimesTen Client DSN Setup dialog is defined and the corresponding system exists.
The TimesTen Server is running on the server system.
Click Test Data Source Connection to test the connection to the server DSN. The ODBC Data Source Administrator attempts to connect to the server DSN and displays messages to indicate whether it was successful.
During this test, TimesTen Client verifies that:
The server DSN specified in the Server DSN field is defined on the server system.
A client application can connect to the server DSN.
On UNIX, you define logical server names by editing the ttconnect.ini file; you define client DSNs by editing the user odbc.ini file for user DSN or the system odbc.ini file for system DSNs. For a description of user and system DSNs, see "Specifying Data Source Names to identify TimesTen databases".
Note:
The syntax for defining the client DSN in theodbc.ini file is described in "odbc.ini file entry descriptions".In the ODBC Data Sources section of the odbc.ini file, add an entry for the client DSN. The client DSN specifies the location of the TimesTen database with the following attributes:
ODBC client driver to use for the connection.
The server system on which the database resides on is specified in the TTC_Server attribute.
The server DSN that specifies the intended database is specified in the TTC_Server_DSN attribute.
Note:
The server DSN is defined on the server system where the database resides.For each TimesTen database with which the client connects needs to have two entries:
Define the client DSN name and provide the name of the ODBC client driver to use in the ODBC Data Sources section.
Note:
All available ODBC client drivers are listed in "Connecting using TimesTen ODBC drivers".Create an entry with the client DSN you defined in the ODBC Data Sources section. Within this section, specify the server system and the server DSN.
The following is the syntax for providing the client DSN name and the ODBC client driver to use:
[ODBC Data Sources] Client_DSN=Name-of-ODBC-driver
For example, to defined sampbledbCS_1122 as the client DSN and associate it with the TimesTen Client ODBC driver, you would make the following entry in the ODBC Data Sources section of the odbc.ini file:
[ODBC Data Sources] sampledbCS_1122=TimesTen Client 11.2.2
After the ODBC Data Sources section, you would add an entry to specify the server system and server DSN for each data source you defined. Each client DSN listed in the ODBC Data Sources section of the odbc.ini file requires a its own specification section.
The following is an example specification of the TimesTen client DSN sampledbCS_1122 where the server is configured with a logical server name of LogicalServer_1122 and the server DSN is sampledb_1122:
[sampledbCS_1122] TTC_Server=LogicalServer_1122 TTC_Server_DSN=sampledb_1122
The TTC_Server* attributes are the main attributes for a client DSN definition. There are only a few client connection attributes, each of which are for identifying the server DSN. If you provide any server connection attributes in the client definition, these attributes are ignored. General connection attributes may be specified in the client definition. For a description of all client and general connection attributes available for use in the odbc.ini file, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
Automatic client failover is for use in High Availability scenarios with a TimesTen active standby pair replication configuration. Consider a scenario where failure of the active TimesTen node has resulted in the original standby node becoming the new active node. With the automatic client failover feature, failover (transfer) to the new active (original standby) node occurs, and applications are automatically reconnected to the new active node. TimesTen provides features that enable applications to be alerted when this occurs, so they can take any appropriate action.
Note:
Automatic client failover is complementary to Oracle Clusterware in situations where Oracle Clusterware is used, but the two features are not dependent on each other. For information about Oracle Clusterware, you can refer to "Using Oracle Clusterware to Manage Active Standby Pairs" in the Oracle TimesTen In-Memory Database Replication Guide.The following sections describe how to use and enable automatic client failover:
When an application connects to the active node, the connection is registered and this registration is replicated to the standby node. If the active node fails, the standby node becomes the active node and then notifies the client of the failover. At this point, the client has a new connection to the new active node. No state from the original connection, other than the connection handle, is preserved. All client statement handles from the original connection are marked as invalid.
When failover completes, TimesTen makes a callback to a user-defined function that you register. This function takes care of any custom actions you want to occur in a failover situation.
Note:
For C developers, details of how to create the callback and to facilitate an automatic client failover are discussed in "Using automatic client failover in your application" in the Oracle TimesTen In-Memory Database C Developer's Guide.For Java developers, details are discussed in "JDBC support for automatic client failover" in the Oracle TimesTen In-Memory Database Java Developer's Guide.
The following items list the behavior of automatic client failover in particular failure scenarios:
If the client library loses the connection to the active node, it fails over and attempts to switch to the standby node.
If, for some reason, there is no active node (no failover has occurred at the server side and both servers are either standby or idle), applications cannot connect. But automatic client failover continues to alternate between both servers until it finds an active node or times out.
If a failover has already occurred and the client is already connected to the new active node, the next failover request results in an attempt to reconnect to the original active node. If that fails, alternating attempts are made to connect to the two servers until it times out.
Note:
When TimesTen attempts to recover from failure when using automatic client failover, a timeout specifies the duration for all attempts at failover recovery. The connection might be blocked while failover is attempted.This timeout defaults to 60 seconds or can be set with the value of the TTC_Timeout connection attribute. The minimum timeout is 60 seconds, regardless of the TTC_Timeout setting. Refer to "TTC_Timeout" in Oracle TimesTen In-Memory Database Reference for information about that attribute.
If the active node fails before the client registration is successfully propagated by replication to the standby node, the client does not receive a failover message and the connection registration is lost. However, the client library eventually notices (through TCP) that its connection to the original active node is lost and initiates a failover attempt.
Notes:
These features apply only to client/server connections, not direct connections.
Failover connections are created only as needed, not in advance.
Using automatic client failover results in one additional database connection per server process, which should be considered as you choose a setting for the TimesTen Connections attribute (upper limit of the number of concurrent connections to the database). The number of server processes, in turn, is affected by the setting of the MaxConnsPerServer attribute (maximum number of concurrent connections a child server process can handle). For example, if you have 12 connections and MaxConnsPerServer=3, then there are four server processes. Therefore, if some of the connections use automatic client failover, there are four additional connections.
You can only configure automatic client failover for databases that have active standby pair replication schemes. This enables the client to fail over automatically to the server on which the standby database resides.
Note:
See "Using automatic client failover in your application" in Oracle TimesTen In-Memory Database C Developer's Guide for information about connection option persistence after failover.In the Oracle TimesTen Client DSN Setup dialog, after you have configured the rest of the client DSN information as described in "Creating and configuring client DSNs on Windows", complete the following fields:
In the Failover Server Name or Network Address field, specify the logical server or network address of the server system.
The name can be a host name, IP address or logical server. The logical server names defined on the client system can be found in the drop-down list. To define logical server names, click Servers.
If you do not specify a logical server name in this field, the TimesTen Client assumes that the TimesTen Server is running on the default TCP/IP port number. Therefore, if the Server is running on a port other than the default port and you do not specify a logical server name in this field, you must specify the port number in the ODBC connection string, using the TCP_Port attribute.
For more information on defining logical server names, see "Creating and configuring a logical server name on Windows".
In the Failover Server DSN field, enter the server DSN corresponding to the standby database.
If you do not know the name of the server DSN, click Refresh to obtain a list of server DSNs that are defined on the system specified in the Failover Server Name or Network Address field. Select the server DSN from the drop-down list.
You must have a network connection to the system where the TimesTen Server is running.
Optionally, specify the Failover Port Range for the port or port range where TimesTen listens for failover notifications. This connection attribute needs to be specified as a single port number if you have firewall issues between the server hosts and the client hosts. By default, TimesTen uses a port chosen by the operating system. The failover notifications are issued from the server hosts to the client hosts. A port range is set as a lower and upper value separated by hyphen.
You only need to specify a port range if both of these conditions are true:
You have firewall issues between the server hosts and the client hosts.
You use multiple client applications configured for automatic client failover on a single client host.
Each client application configured for automatic client failover on a client host needs to listen on a distinct port for failover notifications.
On the client, configure the following:
In the odbc.ini file on the client, define the client DSNs for the standby node by configuring TTC_Server2 to the server on which the standby database resides. Set TTC_Server_DSN2 to the name of the standby database.
For example:
[MyDSN] TTC_Server=LogicalServer_1122 TTC_Server_DSN=MyDSN TTC_Timeout=60 TTC_Server2=LogicalServer2_1122 TTC_Server_DSN2=MyDSN_Standby
In the ttconnect.ini file on the client, define the logical server for the standby node by configuring the Network_Address and TCP_Port to the server on which the standby database resides.
[LogicalServer_1122] Description=TimesTen Server 11.2.2 Network_Address=server.mycompany.com TCP_Port=53397 [LogicalServer2_1122] Description=TimesTen Server 11.2.2 Network_Address=server2.mycompany.com TCP_Port=53397
Setting any of TTC_Server2, TTC_Server_DSN2, or TCP_Port2 implies the following:
You intend to use automatic client failover.
You understand that a new thread is created for your application to support the failover mechanism.
Optionally, configure the TTC_FailoverPortRange attribute to specify a port or port range where the failover thread listens for failover notifications. This connection attribute needs to be specified as a single port number if you have firewall issues between the server hosts and the client hosts. By default, a port chosen by the operating system is used. The failover notifications are issued from the server hosts to the client hosts. A port range is set as a lower and upper value separated by hyphen.
You only need to specify a port range if both of these conditions are true:
You have firewall issues between the server hosts and the client hosts.
You use multiple client applications configured for automatic client failover on a single client host.
Each client application configured for automatic client failover on a client host needs to listen on a distinct port for failover notifications.
Notes:
Like other connection attributes, TTC_Server2, TTC_Server_DSN2, and TCP_Port2 can be specified in the connection string, overriding any settings in the DSN.
If TTC_Server2 is specified but TTC_Server_DSN2 and TCP_Port2 are not, then TTC_Server_DSN2 is set to the TTC_Server_DSN value and TCP_Port2 is set to the TCP_Port value.
If the client library cannot connect to TTC_Server_DSN, it tries the standby, TTC_Server_DSN2.
TTC_Server and TTC_Server2 can have the same setting if it is a virtual IP address.
The TimesTen Server is a child process of the TimesTen daemon. If you installed the TimesTen Server, this process is automatically started and stopped when the TimesTen daemon or Data Manager service is started or stopped. You can explicitly start or shut down the daemon or service with the ttDaemonAdmin utility.
The TimesTen Server handles requests from applications linked with the TimesTen Client driver.
The default ports for TimesTen daemon and TimesTen Servers are described in the "TimesTen Installation" chapter in the Oracle TimesTen In-Memory Database Installation Guide. System administrators can change the port number during installation to avoid conflicts or for security reasons. The port range is from 1 - 65535. To connect to the TimesTen Server, client DSNs are required to specify the port number as part of the logical server name definition or in the connection string.
On Windows, the TimesTen service is run as user SYSTEM. On UNIX, the TimesTen Server is run as the instance administrator.
For instructions on modifying TimesTen Server options, see "Modifying the TimesTen Server options".
The TimesTen Server records "connect," "disconnect" and various warning, error and informational entries in log files.
On Windows, these application messages can be accessed with the Event Viewer.
On UNIX, the TimesTen Server logs messages to the install_dir/info/ttmesg.log and install_dir/info/tterrors.log files by default. Optionally, you can configure TimesTen to log messages to the syslog facility.
In this example, the TimesTen Client application system is a 64-bit Solaris system, client.mycompany.com. The client application is accessing the server DSN sampledb_1122 on the remote server system, another 64-bit Solaris system, server.mycompany.com. The logical server name is LogicalServer_1122. The instance name of the TimesTen installation is tt1122_64.
On the server system server.mycompany.com, use the ttStatus utility to verify that the TimesTen Server is running and to verify the port number on which it is listening.
Verify that the server DSN sampledb_1122 exists in the system odbc.ini file on server.mycompany.com.
There should be an entry in the odbc.ini file as follows:
[sampledb_1122] Driver=install_dir/lib/libtten.so DataStore=install_dir/server/sampledb_1122
Create a logical server name entry for the remote TimesTen Server in the ttconnect.ini file on client.mycompany.com.
[LogicalServer_1122] Network_Address=server.mycompany.com TCP_Port=53397
See "Creating and configuring client DSNs on UNIX" for information on the creating a ttconnect.ini file.
On the client system, client.mycompany.com, create a client DSN corresponding to the remote server DSN, sampledb_1122.
There should be an entry in the odbc.ini file as follows:
[sampledbCS_1122] TTC_Server=LogicalServer_1122 TTC_Server_DSN=sampledb_1122
See "Overview of user and system DSNs" for information on the location of the proper odbc.ini file.
Run the client application from the system client.mycompany.com using the client DSN, sampledbCS_1122. The example below uses the ttIsql program that is installed with TimesTen Client.
ttIsqlCS -connStr "DSN=sampledbCS_1122"
The next example describes how to access a TimesTen Server that is listening on a port numbered other than the default port number.
Let us consider the Network Address of the TimesTen Server is server.mycompany.com and the Server is listening on Port 53397. The following methods can be used to connect to a Server DS:
Define the logical server name LogicalServer_1122 with server.mycompany.com as the Network Address and 53397 as the Network Port. Define Client_DSN as the client DSN with LogicalServer_1122 as the server name and Server_DSN as the server DSN. Execute the command:
ttIsqlCS -connStr "DSN=Client_DSN"
Alternatively, define the logical server name logical_server with server.mycompany.com as the Network Address and the default port number as the Network Port. Define a client DSN with LogicalServer_1122 as the server name and Server_DSN as the server DSN. Overwrite the port number in the command:
ttIsqlCS -connStr "DSN=Client_DSN;TCP_Port=53397"
Alternatively, define the server in the connection string. In this case you do not need to define a client DSN, nor a logical server name.
ttIsqlCS -connStr "TTC_Server=server.mycompany.com;TTC_Server_DSN=Server_DSN;TCP_Port=53397"
To test client application connections to TimesTen databases:
Verify that the client system can access the server system.
Run ping from the client system to see if a response is received from the server system.
Verify that the TimesTen Server is running on the server system.
Use telnet to connect to the port on which the TimesTen Server is listening. For example:
telnet server.mycompany.com 53397
If you successfully connect to the TimesTen Server, you see a message similar to:
Connected to server.mycompany.com
If the server system responds to a command, but TimesTen Server does not, the TimesTen Server may not be running. In the case of a failed connection, you see a message similar to:
telnet: Unable to connect to remote host: Connection refused
Use the ttStatus utility on the server system to determine the status and port number of the TimesTen Server. Generally, the TimesTen Server is started at installation time. If the TimesTen Server is not running, you must start it. For information on starting the TimesTen Server, see "Modifying the TimesTen Server options".
Verify that the client application can connect to the database. If you cannot establish a connection to the database, check that the ttconnect.ini file contains the correct information.
If the information in the ttconnect.ini file is correct, check that a server DSN corresponding to the database has been defined properly in the system odbc.ini file on the system where the database resides and where the TimesTen Server is running.
|
 Copyright © 1996, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|