4 TimesTen Scaleout Utilities

This chapter provides reference information for utilities that are only supported with TimesTen Scaleout, beginning with the following introductory sections:

For information about utilities that are only supported in TimesTen Classic or supported in both TimesTen Classic and TimesTen Scaleout, see Chapter 5, "Utilities".

Overview

The options for TimesTen utilities are generally not case sensitive, except for single character options. You can use -timeout or -TimeOut interchangeably. However -v and -V are each unique options.

All utilities return 0 for success and nonzero if an error occurs.

Note:

The utility name and options listed in this chapter are case-insensitive. They appear in mixed case to make the examples and syntax descriptions easier to read.

Required authentication and authorization for utilities

The following sections describe the authentication and authorization required for utilities:

Required user authentication for utilities

All utilities that require a password prompt for one.

If TimesTen prompts for a password, input is not displayed on the command line.

Generally, when no user is specified, the user is assumed to be the user name identified by the operating system, and TimesTen does not prompt for a password.

When a utility accepts a DSN, connection string or database path as a parameter, specify the value at the end of the command line.

Note:

For security reasons, we do not recommend setting a a value for PWD on the command line.

Required privileges for executing utilities

Certain TimesTen command-line utilities require privileges. Each utility in this chapter describes the privilege required for execution. You may receive a database not loaded error if you try to execute any utility with a user other than the instance administrator and the database is not loaded into memory. In this case, TimesTen cannot determine the privileges of the user.

Thus any utilities requiring privileges have to be run either as the instance administrator or executed while the database is loaded.

Utilities list

Utilities listed in Table 4-1 are described in this chapter.

Utilities listed in Table 4-2 are described in Chapter 5, "Utilities".

Table 4-1 Utilities supported only in TimesTen Scaleout descriptions

Name Description

ttGridAdmin

Administers a TimesTen Scaleout grid.

ttGridRollout

Creates a new grid and database.


Table 4-2 Utilities supported in both TimesTen Scaleout and TimesTen Classic descriptions

Name Description

ttInstallationCheck

Examines all files in an installation of TimesTen and generates a signature for the installation,

ttInstallDSN

Generates a Windows client DSN for one or more entries listed in the provided input file and installs them into the ODBC Panel as a System DSN.

ttInstanceCreate

Create a new TimesTen instance.

ttInstanceDestroy

Destroys an existing TimesTen instance.

ttInstanceModify

Modifies certain attributes of an instance.

ttIsql

Executes SQL statements interactively.

ttMigrate

Saves and restores TimesTen objects.

ttSchema

Prints out the schema, or selected objects, of a database.

ttSize

Estimates the amount of space that a given table, including any views in the database will consume when the table grows to include a specified number of rows.

ttStats

Monitors database metrics or takes and compares snapshots of metrics.

ttVersion

lists the TimesTen release information.


ttGridAdmin

Description

Use the ttGridAdmin utility for all aspects of administering a grid, such as creating a grid, adding or removing data instances or management instances, creating databases, and redistributing data to new data instances. The grid and database configuration resulting from these operations is stored in the grid model, which is distributed to instances of the grid. (See "Grid model" for an introduction to the model.)

Important:

In TimesTen Scaleout, do not update configuration files manually (such as timesten.conf, sys.odbc.ini, and tnsnames.ora).

Required privilege

Instance administrator of the management instance from which ttGridAdmin is run. The user then becomes the instance administrator of all instances created with ttGridAdmin.

Usage with TimesTen Scaleout

This utility is specifically for use with TimesTen Scaleout, with commands that perform any operations on a grid.

Syntax

For general syntax (help options and options that apply to all commands), see "Help and general options". For syntax for individual commands, see the relevant sections under "ttGridAdmin operations".

Grid model

TimesTen Scaleout maintains a central configuration of the grid within a model that describes the desired structure of the grid. The model represents the desired logical topology of the grid and contains objects that represent components of the grid, such as installations, hosts, instances, and database definitions. Each time you use ttGridAdmin to add a grid component, a corresponding object is added to the model.

When you use ttGridAdmin to apply the model, TimesTen Scaleout attempts to implement it into the operational grid, such as by creating the desired physical installations and instances.

Grid objects and object naming

Each entity in a grid—such as each host, instance, installation, physical group, and repository—is defined as a named object.

Each object type, representing these types of entities, has its own namespace. You can have a host named xyz and a physical group named xyz without conflict. In addition, instance namespaces and installation namespaces are per host. You can have an instance named instance1 on host1 and an instance named instance1 on host2 without conflict.

Object-naming hierarchies such as this can be expressed in ttGridAdmin syntax using fully qualified names, toplevelobject.nextlevelobect. For example, host1.instance1 and host2.instance1. To specify an instance or installation in ttGridAdmin syntax, you need only specify hostname (instead of hostname.instancename or hostname.installname) if there is only one instance or installation (as applicable) on the host.

Operations on grid entities through ttGridAdmin, such as creating or removing an instance or installation, are managed through the corresponding objects in the model. The physical entities themselves are not created or removed until the model is applied through the ttGridAdmin modelApply command. For example, to remove an instance named host1.instance1, the instanceDelete command removes the object named host1.instance1 from the model, then the modelApply command removes the physical instance (the instance home directory and everything under it).

Be aware of these limitations in object naming in the grid model:

  • Names must use only ASCII characters.

  • Allowed characters are alphabetic, numeric, hyphen (-), and underscore (_).

  • Database definition names and connectable names are limited to 32 characters (due to ODBC limitations).

  • All other object names are limited to 256 characters.

  • Object names are case-insensitive (so you cannot have an instance instance and an instance Instance on the same host), but are represented and shown as specified in ttGridAdmin commands. If you specify MyInstance in the instanceCreate command, that is how it will be shown.

  • You cannot name anything All or Default, which are reserved names.

Address formats

Some ttGridAdmin commands, such as gridCreate and hostCreate, have options to specify the address or addresses used for internal and external communications. You can specify addresses as DNS names or IP addresses, although use of DNS names is more typical. IP addresses can be in either IPv6 or IPv4 format. For example:

  • DNS name: myhost.example.com

  • IPv6 address: 2606:b400:2000:834:26:3eff:fe07:5b83

  • IPv4 address: 92.68.0.1

Database management operations

In a Grid environment, database management operations—dbCreate/dbDestroy, dbLoad/dbUnload, dbOpen/dbClose—are performed asynchronously by default. This is generally advisable, as such operations are not atomic and may take a long time. In a large grid, loading a database may succeed immediately on many hosts, take a little longer on others, and much longer on others. Some hosts may, in fact, be down when the operation was executed, so cannot perform the operation until they are back up.

By default, commands for these database operations return without waiting for completion, but they can optionally wait, with or without a timeout. With wait and a timeout, a command does not return until it has completed on all instances or reaches the timeout. With wait and no timeout, a command will never return if any instances are down. There are advantages and disadvantages to each approach, depending on factors such as how large the grid is. For a large grid, you may choose to proceed before the operation has completed on all instances, while on a small grid it may be more sensible to wait until it has completed on every instance.

TimesTen Scaleout tracks the state of a database, including each element of the database, and it is up to the user to check status of an operation (through the dbStatus command, optionally using the -all option for further details) to see how many instances have completed the operation. In particular, after loading the database, you can use the status information to determine if it has been loaded on enough instances for the database to be opened and users to start accessing it.

No command is provided to cancel an operation on any or all instances.

Command timeouts and waits

Note that as ttGridAdmin executes a command, it may run operating system commands as well. Using the top-level -timeout option, you can specify that ttGridAdmin will wait for the specified number of seconds for such operations to complete. If an operation does not complete within the specified number of seconds, the ttGridAdmin command being executed fails.

In addition, the ttGridAdmin database management commands dbCreate, dbDestroy, dbload, dbUnload, dbOpen and dbClose have a –nowait/-wait option. Each of these commands initiates a state change that is recorded in the active management instance of the grid. With a setting of –nowait (the default), the commands return immediately without waiting for the state change to complete. If –wait with a timeout value n is specified, ttGridAdmin will wait for up to n seconds for the state change to complete. If –wait is specified without a timeout, ttGridAdmin will wait without limit for the state change to complete.

Help and general options

These options work with any ttGridAdmin command or, for help, at the top level without any command.

ttGridAdmin [-h | -help | -?] [command] 

ttGridAdmin [-o json] [-timeout n] command [-command_option] ...

Options

ttGridAdmin has the general options:

Option Description
-h

-help

-?

Display help information.

If specified by itself, this option categorizes and lists ttGridAdmin commands. For example:

ttGridAdmin -h

if specified with a command, this option displays syntax and option descriptions for the given command. For example:

ttGridAdmin -h dbCreate
-o json Choose JSON output.

Output for the command will be in JSON format. (Otherwise, output is in human-readable format.)

Important: There is no guarantee of JSON output compatibility between TimesTen releases.

-timeout n Maximum number of seconds to wait for a long-running operation to complete. The default is 600.

Note that as ttGridAdmin executes a command, it may run operating system commands as well. It will wait for the specified number of seconds for such operations to complete. If an operation does not complete within the specified number of seconds, the ttGridAdmin command being executed fails.


Return values

This section describes error or status values and JSON data elements returned by ttGridAdmin commands.

Error and status return codes

ttGridAdmin commands returns error codes to note success or failure, including these general codes:

Code Description
0 Success
255 Internal error
254 Syntax error

JSON data elements returned

When JSON output is specified, the stdout of the command includes at least these name/value pairs. (Refer to http://www.json.org/ for general information about JSON output.)

Return Type Description
"status" number Return code

See the preceding section, "Error and status return codes".

"errno" number Error number, if an error occurred
"errmsg" string Error message, if an error occurred

Note:

Additional, command-specific JSON data elements may also be returned.

Backup and restore operations

Use ttGridAdmin commands in this section to back up and restore databases, display the status of those operations, or delete a backup.

Also see "Migrating, Backing Up and Restoring Data" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Back up a database (dbBackup)

The dbBackup command initiates a backup of the specified database.

ttGridAdmin dbBackup dbname 
                     -repository reponame 
                     [-name backupname]

In some cases you must use dbExport instead. This would be the case, for example, if the grid topology at the restore location has fewer replica sets than the backed up database, or the restore location is running a version of TimesTen that is not patch-compatible with the version of the backed up database. See "Migrating, Backing Up and Restoring Data" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.

Important:

Be aware of the following if the specified repository was created with -method scp:

When an element is backed up, the backup file is stored on the local disk where the element is located before being copied to the remote repository.

A backup is stored as a collection under a repository. You first must create the repository. See "Repository operations".

Options

The dbBackup command has the options:

Option Description
dbname Name of the database to back up.
-repository reponame Name of the repository where the backup will be located.
-name backupname Specifies a name for the backup. The default is the letter "B" followed by the date and time of the backup, in the format:
Byyyymmddhhmmss

Examples

This example backs up database1 into repository repo1. It uses the default name for the backup, according to the current timestamp (2/22/17 at 14:55:44).

% ttGridAdmin dbBackup database1 -repository repo1
dbBackup B20170222145544 started

You can then use dbBackupStatus to check progress, as shown in the example in "Display the status of a database backup (dbBackupStatus)". The backup is finished when each element and the database as a whole are indicated as complete.

Notes

  • The backup is performed asynchronously. Use the dbBackupStatus command to check progress.

  • One element from each replica set is backed up.

  • Each replica set is stored as a sub-collection.

  • For disk space requirements, see "Backing up and restoring a TimesTen Scaleout database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Delete a database backup (dbBackupDelete)

The dbBackupDelete command deletes the specified database backup.

ttGridAdmin dbBackupDelete -repository reponame 
                           -name backupname

Options

The dbBackupDelete command has the options.

Option Description
-repository reponame Name of the repository where the backup is located.
-name backupname Name of the backup to delete.

Examples

This example deletes the backup created in the example in "Back up a database (dbBackup)".

% ttGridAdmin dbBackupDelete -repository repo1 -name B20170222145544
Backup B20170222145544 deleted

Notes

This command is typically used to delete old or failed backups.

Display the status of a database backup (dbBackupStatus)

The dbBackupStatus command shows the status of a database backup or backups previously started.

ttGridAdmin dbBackupStatus dbname 
                           [-name backupname]

Options

The dbBackupStatus command has the options:

Option Description
dbname Name of the database being backed up.
-name backupname Name of the backup to check. The default is all backups of the specified database.

Examples

This example shows status upon completion of the backup from the example in "Back up a database (dbBackup)".

% ttGridAdmin dbBackupStatus database1 -name B2017022245544
Database  Backup          Repository Host  Instance  Elem State     Started                Finished
--------- --------------- ---------  ----- --------- ---- --------- ---------------------- --------
database1 B20170222145544 repo1                           Completed 2017-02-22T14:55:44.000Z Y
                                     host3 instance1    1 Complete
                                     host4 instance1    2 Complete
                                     host5 instance1    3 Complete

Notes

  • When you believe the backup is complete, confirm that dbBackupStatus shows that the backup as a whole and for each instance is shown as complete. If there were any failures, see "Check the status of a backup" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

  • Y in the Finished column indicates that the command has finished executing, regardless of state—that each instance has succeeded or failed.

  • The metadata associated with a database backup is deleted when the database is deleted. After a database is deleted, you can use the repositoryList command to see existing backups.

Restore a database (dbRestore)

The dbRestore command restores a database backup into a new database.

ttGridAdmin dbRestore dbname
                      -repository reponame
                      -backup backupname

Options

The dbRestore command has the options:

Option Description
dbname Name of the database to be created, then restored from the backup.
-repository reponame Name of the repository where the backup is located.
-backup backupname Name of the backup to use for the restore.

Examples

This example creates and restores a database res_db1 from a backup mybkup.

% ttGridAdmin dbRestore res_db1 -repository repo1 -backup mybkup
dbRestore mybkup started

You can then use dbRestoreStatus to check progress, as shown in the example in "Display the status of a database restore (dbRestoreStatus)". The restore is finished when each element and the database as a whole are indicated as complete.

Notes

  • This database must already be defined (with dbdefCreate) but not yet created.

  • The restore is performed asynchronously. Use the dbRestoreStatus command to check progress.

  • The restored database is loaded into memory when dbRestore completes, but not opened.

  • You can restore to the original database definition or to a newly created database definition.

  • You cannot restore to a database with fewer replica sets than what was backed up. (If the number of data instances on hosts in each data space group is not sufficient to support the number of replica sets in the database that was backed up, you must use dbExport and dbImport instead.)

  • If you restore to a database with more replica sets than what was backed up, only the number of replica sets that were backed up will be added to the database distribution map. For example, if you back up a database with two replica sets and restore to a database with four replica sets, only the elements in two replica sets will be added to the distribution map. You would then have to redistribute data with dbDistribute to get four replica sets.

  • For disk space requirements, see "Backing up and restoring a TimesTen Scaleout database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Display the status of a database restore (dbRestoreStatus)

The dbRestoreStatus command shows the status of a database restore previously started.

ttGridAdmin dbRestoreStatus dbname

Options

The dbRestoreStatus command has the option:

Option Description
dbname Name of the database where the restore is being checked.

Examples

This example shows status upon completion of the restore from the example in "Restore a database (dbRestore)".

% ttGridAdmin dbRestoreStatus res_db
Database Restore Repository Host  Instance  Elem State                   Started           Finished
-------- ------- ---------- ----- --------- ---- ------------------------------------------------ -
res_db1  mybkup  repo1                           Restore_Finale_Complete 2017-03-03T13:19:39.000Z Y
                            host3 instance1      Restore_Instance_Complete
                            host4 instance1      Restore_Instance_Complete
                            host5 instance1      Restore_Finale_Complete

Notes

  • When you believe the restore is complete, confirm that dbRestoreStatus shows Restore_Finale_Complete for the restore as a whole and Resore_Instance_Complete or Restore_Finale_Complete for each instance. If there were any failures, see "Check the status of a restore" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

  • Y in the Finished column indicates that the command has finished executing, regardless of state—that each instance has succeeded or failed.

Connectable operations

Use ttGridAdmin commands in this section to create, delete, modify, export, or list connectable objects, used in connecting to a TimesTen Scaleout database. A connectable specifies a set of connection attribute settings and thereby defines an underlying DSN and tnsnames.ora file entry.

There are two types of connectables: direct connectables for direct mode access, and client/server connectables for client/server access.

You can have multiple connectables for a database to use different sets of connection attribute settings. For example, if you have one application designed to receive ASCII data from the database and another designed to receive Unicode data, then create two connectables, each with the appropriate ConnectionCharacterSet attribute setting.

Note:

A direct connectable, with the same name as the database, is created automatically when you define a database with the dbdefCreate command.

See "Connecting to a database" and its subsections in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information about connectables.

Create a connectable (connectableCreate)

The connectableCreate command creates a connectable object in the model, defining connection attribute settings.

ttGridAdmin connectableCreate -dbdef name
                               [-cs [-only hostname[.instancename]]]
                               filepath

Options

The connectableCreate command has the options:

Option Description
-dbdef name The name of the database definition object that the connectable references (which is the name of the database to connect to).
-cs Specifies that the connectable will be for client/server access to the database. If this is not specified, the connectable will be for direct mode access.
-only hostname[.instancename] For client/server connections, optionally specifies that applications connecting through this connectable should connect to the indicated instance. By default, all data instances in the grid are available and connections are distributed among them.

You need to specify the instance name only if there is more than one instance on the host. (See "Grid objects and object naming".)

You can specify multiple -only options, in which case client/server applications can connect to any instance listed in the -only settings.

filepath Path and name of the connectable file, which contains the connection attribute settings for the connectable. The file name must be of the form connname.connect, where connname defines the name of the connectable.

Also see the example below.


Examples

The example creates a client/server connectable using this connectable file, database1client.connect:

ConnectionCharacterSet=AL32UTF8
UID=ttclient

Create the connectable:

% ttGridAdmin connectableCreate -dbdef database1 -cs 
/sw/tten/grid/conndefs/database1client.connect
Connectable database1client created.

Notes

  • The connectable file must be in odbc.ini format, as shown in the example, with attribute=value on each line. A DSN name, in [name] format such as [database1client] here, is optional. If provided, it must match the connectable name determined by the connectable file name.

  • The default value is used for any connection attribute not set in the connectable.

  • When you apply the model after creating a connectable, new versions of all necessary configuration files are written to each data instance. This makes the connectable available for use. (Never edit configuration files manually. They are overwritten each time the model is applied.)

  • You cannot set data store (creation time) attributes or first connection attributes in the connectable file. Those must be set in the database definition file for the dbdefCreate or dbdefModify command.

  • Any settings for TTC_SERVER, TTC_SERVER_DSN, or TCP_PORT are ignored. Appropriate values for the grid topology are automatically used.

  • The connectable that is defined is usable through all APIs supported by TimesTen.

Delete a connectable (connectableDelete)

The connectableDelete command deletes an existing connectable object from the model.

ttGridAdmin connectableDelete name

Options

The connectableDelete command has the option:

Option Description
name The name of the connectable object to delete.

Examples

% ttGridAdmin connectableDelete database1client
Connectable database1client deleted from Model.

Notes

When you apply the model after deleting a connectable, new versions of all necessary configuration files are written to each data instance, with the connectable entry removed. (Never edit configuration files manually. They are overwritten each time the model is applied.)

Export a connectable (connectableExport)

The connectableExport command exports a connectable object and its connection attribute settings, typically to a specified file.

ttGridAdmin connectableExport name 
                              [filepath]

Options

The connectableExport command has the options:

Option Description
name Name of the connectable object to export.
filepath Path and name of the connectable file to create, typically a .connect file for use with connectableCreate or connectableModify. If no file is specified, the export goes to stdout.

Important: If you specify an existing file, it will be overwritten.


Examples

This example exports the connectable created in the connectableCreate example to the file database1client.connect.

% ttGridAdmin connectableExport database1client /sw/tten/grid/conndefs/database1client.connect
Connectable database1client exported

Resulting contents of database1client.connect:

# Connectable GUID 3210288C-DF44-447D-ADB6-BDC8F7CFE17C Exported 2017-11-14 17:53:25
[database1client]
ConnectionCharacterSet=AL32UTF8
UID=ttclient

Notes

A typical use case is if you want to modify a connectable, but the original connectable file is no longer available.

List connectables (connectableList)

The connectableList command lists the connectable objects that have been created in the specified version of the model.

ttGridAdmin connectableList [-latest|-current|-version n]
                            [-dbdef]

Options

The connectableList command has the options:

Option Description
-latest Lists connectable objects in the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Lists connectable objects in the current model—the model most recently applied to the grid.
-version n Lists connectable objects in the specified version number of the model.
-dbdef Also lists the name of the database definition associated with each connectable object.

Examples

This example lists connectables and the associated database definitions from the model most recently applied to the grid.

% ttGridAdmin connectableList -current -dbdef
Connectable     DbDef
--------------- -----------
database1       database1
database1client database1

Only database1client was created by the user. A direct connectable is also automatically defined for each user-created database definition.

Modify a connectable (connectableModify)

The connectableModify command modifies a connectable object.

ttGridAdmin connectableModify [-only hostname[.instancename]]
                              filepath

Options

The connectableModify command has the options:

Option Description
-only hostname[.instancename] For connectables created for client/server connections (as determined by the -cs option of connectableCreate), optionally specifies that applications connecting through this connectable should connect to the indicated instance. By default, all data instances in the grid are available and connections are distributed among them.

You need to specify the instance name only if there is more than one instance on the host.

You can specify multiple -only options, in which case client/server applications can connect to any instance listed in the -only settings.

Note: Instances specified with connectableModify -only replace any instances specified with connectableCreate -only.

filepath Path and name of the connectable file, which contains the new set of connection attribute settings. The file name must be of the form connname.connect, where connname is the name of the connectable.

Examples

The example modifies the client/server connectable created in the connectableCreate example, editing database1client.connect to add a PermWarnThreshold setting:

ConnectionCharacterSet=AL32UTF8
UID=ttclient
PermWarnThreshold=80

Modify the connectable:

% ttGridAdminttGridAdmin connectableModify /sw/tten/grid/conndefs/database1client.connect
Connectable database1client modified.

Notes

  • All connection attribute settings from the previous connectable file are replaced with the connection attribute settings in the specified file.

  • You cannot modify a connectable to change from client/server use to direct mode use, or from direct mode use to client/server use. Instead, delete the connectable and create a new one.

  • When you apply the model after modifying a connectable, new versions of all necessary configuration files are written to each data instance, with the connectable entry modified according to the new settings. (Never edit configuration files manually. They are overwritten each time the model is applied.)

Data space group operations

Use the ttGridAdmin command in this section to get recommendations for assignments of hosts to data space groups.

Get recommendations for data space group assignments (dataSpaceGroupSuggest)

The dataSpaceGroupSuggest command recommends data space group assignments for hosts, based on the physical topology of the grid as defined in the model. Recommendations in the form of appropriate hostModify commands are output to a shell script (or to stdout).

ttGridAdmin dataSpaceGroupSuggest [filepath]

Options

The dataSpaceGroupSuggest command has the option:

Option Description
filepath Path and name of the script to contain the recommended actions.

If no file is specified, the script is written to stdout.


Examples

This example shows a ttGridAdmin dataSpaceGroupSuggest command that writes its recommendations to recommendations.sh. (The output is abbreviated.) If you then execute this file, it will run ttGridAdmin hostModify commands to assign hosts to the recommended data space groups.

% ttGridAdmin dataSpaceGroupSuggest /tmp/recommendations.sh
% more /tmp/recommendations.sh
#!/bin/sh
# Recommendations generated by ttGridAdmin -dataSpaceGroupSuggest at Wed Aug  8
17:40:35 PDT 2018
 
TIMESTEN_HOME=/sw/tten/grid/ttinstances/grid1_mgmt
export TIMESTEN_HOME
. $TIMESTEN_HOME/bin/ttenv.sh > /dev/null 2>/dev/null
 
# Number of possibilities evaluated:     126
#
# Number of usable possibilities found:  10
# (A 'usable' possibility is one that is compatible with pre-existing
# assignments of Hosts to DataSpaceGroups)
#
# Number of 'ideal' possibilities found: 1
# (An 'ideal' possibility is one where no PhysicalGroups span multiple
# DataSpaceGroups)
#
# Possibilities evaluated (best 10 displayed):
# ...
#
# This script, if executed, would implement the only 'ideal' configuration found.
# Even though this recommendation was 'ideal', you should carefully evaluate it
# prior to running this script.
# Host mysys1host is already in DataSpaceGroup 1
ttGridAdmin hostModify mysys7host -dataSpaceGroup 1
ttGridAdmin hostModify mysys8host -dataSpaceGroup 1
# Host mysys3host is already in DataSpaceGroup 1
# Host mysys4host is already in DataSpaceGroup 1
# Host mysys5host is already in DataSpaceGroup 2
ttGridAdmin hostModify mysys9host -dataSpaceGroup 2
ttGridAdmin hostModify mysys10host -dataSpaceGroup 2
ttGridAdmin hostModify mysys2host -dataSpaceGroup 2
# Host mysys6host is already in DataSpaceGroup 2

If you decide to accept these recommendations, execute the provided shell script, recommendations.sh. Once the script is executed, all hosts are assigned to the designated data space groups.

% sh /scratch/gridsetup/misc/recommendations.sh
Host mysys7host modified in Model
Host mysys8host modified in Model
Host mysys9host modified in Model
Host mysys10host modified in Model
Host mysys2host modified in Model

Notes

  • Run the command after you have created physical groups, hosts, and installations for the grid and defined how hosts will correspond to physical groups (which you can accomplish through the hostCreate -physicalgroup option or the hostModify -physicalgroup or -addphysicalgroup option).

  • This command is for hosts not yet assigned to a data space group, and returns an error if all hosts are already assigned. (Once a host is assigned to a data space group and modelApply is executed, you cannot change the assignment.)

  • Hosts that do not have any instances are not included in the output.

  • Recommendations are based on separating hosts among data space groups in an effort to avoid single points of failure, according to shared physical resources. In addition to the hostModify commands, the script has comments explaining the rationale behind the recommendations.

  • If there is not enough difference in physical locations for dataSpaceGroupSuggest to make meaningful suggestions, it will output a message to that effect:

    Error 33: Not enough differentiation to make suggestions
    
  • For additional information, see "Assigning hosts to data space groups" and "Propose data space group assignments" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Database definition operations

Use ttGridAdmin commands in this section to create, delete, export, or modify a database definition, or to display a list of existing database definitions.

A database definition specifies the characteristics of a database, consisting of settings for data store attributes (set at database creation) and first connect attributes.

Create a database definition (dbdefCreate)

The dbdefCreate command creates a database definition object in the model, defining characteristics of the database according to attribute settings in the specified file. It also creates a direct connectable object with the same name as the database, for direct connections.

ttGridAdmin dbdefCreate filepath

Once a database definition is added to the model, it can be used to create a database.

Options

The dbdefCreate command has the option:

Option Description
filepath Path and name of the database definition file, which contains the attribute settings for the database definition.

The file name must be of the form dbname.dbdef, where dbmame defines the name of the database.


Examples

The example uses database definition file database1.dbdef:

DataStore=/disk/databases/database1
LogDir=/disk2/logs
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=US7ASCII
PermSize=256
TempSize=128

Typical settings in a database definition file include the following, as shown in the example.

  • Data store attributes: DataStore (required) LogDir, and DatabaseCharacterSet (required)

    Directories are created on each host as necessary for the DataStore and LogDir locations.

  • First connection attributes: PermSize (required) and TempSize

  • General connection attribute: ConnectionCharacterSet

  • As necessary, PL/SQL first connection attributes and server connection attributes

Create the database definition object:

% ttGridAdmin dbdefCreate  /sw/tten/grid/dbdefs/database1.dbdef
Database Definition database1 created.

Data store attributes and first connection attributes go in the resulting database definition. From the example, this consists of DataStore, LogDir, DatabaseCharacterSet, PermSize, and TempSize. In addition, a default connections setting and a default durability setting are added to the definition automatically.

[database1]
DataStore=/disk/databases/database1
DatabaseCharacterSet=AL32UTF8
LogDir=/disk2/logs
PermSize=256
TempSize=128
connections=100
durability=0

General connection attributes go in the resulting connectable definition that is automatically created. In the example, this consists of ConnectionCharacterSet:

[database1]
ConnectionCharacterSet=US7ASCII

For additional information, see "Creating a database definition file" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Notes

  • The database name cannot be the same as any existing database or connectable name.

  • The database definition file must be in odbc.ini format, as shown in the example, with attribute=value on each line.

  • A dbdef file supports the following substitution strings for DataStore and LogDir entries. They are replaced as appropriate when the model is applied:

    • !!HOST_NAME!! is replaced on each host by the host name as specified in the model.

    • !!INSTANCE_NAME!! is replaced in each instance by the instance name as specified in the model.

    A scenario for using !!HOST_NAME!! and !!INSTANCE_NAME!!, for example, would be if you use a Storage Area Network device shared between the hosts of the grid. Setting DataStore to /shared/datastores/!!HOST_NAME!!/!!INSTANCE_NAME!! gives each host its own data storage area.

  • It is best practice to specify LogDir and have it be on a different file system from DataStore. The DataStore and LogDir paths and directories will be created wherever necessary.

  • You can create additional connectables as described in "Create a connectable (connectableCreate)".

  • Some connection attributes cannot be set in a dbdef file, although they could be set for additional connectables that you create. For example, because the initial connectable that is created during database definition must be usable by the instance administrator, the UID and PWD connection attributes cannot be specified in a dbdef file.

  • When you apply the model after creating a database definition, new versions of all necessary configuration files are written to each data instance, with an entry added according to the dbdef settings. (Never edit configuration files manually. They are overwritten each time the model is applied.)

Delete a database definition (dbdefDelete)

The dbdefDelete command removes a database definition object from the model.

ttGridAdmin dbdefDelete name
                        [-cascade|-nocascade]

Options

The dbdefDelete command has the options:

Option Description
name The name of the database definition object to delete.
-cascade Also remove any additional connectable objects that were created for this database. This is the default.
-nocascade Do not remove connectable objects.

Examples

This example deletes the database definition object database2, showing database definition object listings before and after.

% ttGridAdmin dbdefList
database1
database2

% ttGridAdmin dbdefDelete database2
Database Definition database2 deleted.

% ttGridAdmin dbdefList
database1

Notes

  • The database itself must have already been destroyed (or not yet been created).

  • When you apply the model after deleting a database definition, new versions of all necessary configuration files are written to each data instance, with the database definition removed. (Never edit configuration files manually. They are overwritten each time the model is applied.)

  • The connectable object that was automatically created when the database definition object was created is also removed, regardless of the -cascade/-nocascade setting.

Export a database definition (dbdefExport)

The dbdefExport command exports an existing database definition object from the model, typically to a specified file.

ttGridAdmin dbdefExport name 
                        [filepath]

Options

The dbdefExport command has the options:

Option Description
name Name of the database definition to export.
filepath Path and name of the database definition file to create, typically a .dbdef file for use with dbdefCreate or dbdefModify. If no file is specified, the export goes to stdout.

Important: If you specify an existing file, it will be overwritten.


Examples

This example exports the database definition created in the dbdefCreate example above to the file database1.dbdef.

% ttGridAdmin dbdefExport database1 /sw/tten/grid/dbdefs/database1.dbdef

Resulting contents of database1.dbdef:

# DbDef GUID BCC6AB97-FDC2-4453-AEBC-5BFCAA57EA52 Exported 2017-12-06 19:05:03
[database1]
DataStore=/disk/databases/database1
DatabaseCharacterSet=AL32UTF8
LogDir=/disk2/logs
PermSize=256
TempSize=128
connections=100
durability=0

Notes

  • The database definition is exported in odbc.ini format, as shown in the example, with attribute=value on each line.

  • A typical use case is if you want to modify a database definition, but the original database definition file is no longer available.

List database definitions (dbdefList)

The dbdefList command lists the database definition objects that exist in the specified version of the model.

ttGridAdmin dbdefList [-latest|-current|-version n]

Options

The dbdefList command has the options:

Option Description
-latest Lists database definition objects in the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Lists database definition objects in the current model—the model most recently applied to the grid.
-version n Lists database definition objects in the specified version number of the model.

Examples

List database definition objects in the latest model (default) after the database1 database definition object was created (as shown in "Create a database definition (dbdefCreate)").

% ttGridAdmin dbdefList
database1

Modify a database definition (dbdefModify)

The dbdefModify command modifies an existing database definition object in the model, defining characteristics of the database according to attribute settings in the specified file.

ttGridAdmin dbdefModify filepath

Options

The dbdefModify command has the option:

Option Description
filepath Path and name of the file containing the database definition that will modify the database definition object.

The file name must be of the form dbname.dbdef, where dbname is the name of the database.


Examples

This example modifies database1, created in "Create a database definition (dbdefCreate)". The database definition file database1.dbdef was updated to change the PermSize and TempSize:

% cd /sw/tten/grid/dbdefs
% more database1.dbdef
DataStore=/disk/databases/database1
LogDir=/disk2/logs
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=US7ASCII
PermSize=512
TempSize=256

Modify the database definition object:

% ttGridAdmin dbdefModify  /sw/tten/grid/dbdefs/database1.dbdef
Database Definition database1 modified.

Notes

  • Database definition files are in odbc.ini format, as shown in the example, with attribute=value on each line. See "Create a database definition (dbdefCreate)" for additional discussion.

  • Data store attributes, as listed in Table 2-1 (for example, DataStore, DatabaseCharacterSet, LogDir, and Durability), are frozen once a database is created. Trying to change them using dbdefModify will have no effect on the database.

  • If the database exists and is loaded, changes by the dbdefModify command to first connection attributes do not take effect until you unload (dbUnload) and load (dbLoad) the database.

  • This command does not modify the database itself, only the database definition object.

  • The connectable object that was automatically created when the database definition object was created is also modified appropriately.

  • When you apply the model after modifying a database definition, new versions of all necessary configuration files are written to each data instance, with the applicable entry modified according to the dbdef settings. (Never edit configuration files manually. They are overwritten each time the model is applied.)

  • The specified definition completely replaces the previous definition, deleting previous attribute settings for the database definition and connectable definition. Attributes that were set previously but are not set in the new definition will take their default settings.

Database operations

Use ttGridAdmin commands in this section to perform operations on databases, including creating, destroying, loading, unloading, opening, closing, importing, and exporting a database; setting the distribution scheme of a database; determining status of a database; and forcing the termination of connections to the database.

Close a database (dbClose)

The dbClose command closes the database so that applications can no longer connect to it.

ttGridAdmin dbClose name 
                    [-nowait | -wait [timeout]]

Options

The dbClose command has the options:

Option Description
name Name of the database to close.
-nowait | -wait [timeout] The command initiates a state change that is recorded in the active management instance of the grid.

The -nowait option causes the command to return immediately without waiting for the state change. This is the default behavior.

The -wait option causes the command to wait for the state change to complete, when the database element has been closed on each instance in the grid. You can optionally subject the wait to a limit of timeout seconds. Otherwise, or if timeout is set to 0, there is no limit.

In a large grid, it is not typical or generally advisable to use -wait. If you do, it is advisable to set a timeout. (See "Database management operations".)


Examples

This example closes a database without waiting for the elements to be closed on all instances, then checks status (after the database was successfully closed):

% ttGridAdmin dbClose database1
Database database1 close started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 19:27:48 PST 2017
 
created,loaded-complete,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 2 (of 2)
Completely loaded replica sets: 2 (of 2)
 
Open elements: 0 (of 4)

Notes

  • After the command has completed, the database is still loaded but is closed to connections. Only the instance administrator can connect to a closed database.

  • If you run dbClose asynchronously (without waiting), you can use the dbStatus command to see when the database is closed.

  • The command does not close existing database connections. Any previously open connections must be terminated independently.

  • If a database has been closed with dbClose, attempting to close it again typically results in an error. However, if any element is in "close failed" state, you can retry dbClose. Doing so will change any element in "close failed" state to "opened" state, which will result in TimesTen Scaleout trying to close it again.

Create a database (dbCreate)

The dbCreate command creates a database in the grid according to the specified database definition.

ttGridAdmin dbCreate name 
                     [-instance hostname[.instancename]]
                     [-nowait | -wait [timeout]]

Options

The dbCreate command has the options:

Option Description
name Name of the database definition to use in creating the database. This becomes the name of the database.
-instance hostname[.instancename] If specified, database element(s) will be created only on the specified instance(s), instead of on all instances of the grid. Any element previously created successfully on any of the specified instances must first be destroyed.

This is typically used to recover after a failure in the grid or after database elements were not successfully created on one or more instances in a previous execution of dbCreate.

The hostname is required. The instancename is required only if there is more than one instance on the host. (See "Grid objects and object naming".)

You can use this option only once, specifying a single instance, in a single command.

-nowait | -wait [timeout] The command initiates a state change that is recorded in the active management instance of the grid.

The -nowait option causes the command to return immediately without waiting for the state change. This is the default behavior.

The -wait option causes the command to wait for the state change to complete, when the database element has been created on each instance in the grid. You can optionally subject the wait to a limit of timeout seconds. Otherwise, or if timeout is set to 0, there is no limit.

In a large grid, it is not typical or generally advisable to use -wait. If you do, it is advisable to set a timeout. (See "Database management operations".)


Examples

This example creates a database without waiting for the elements to be created on all instances, then checks the status, first while database creation is still in progress, then after it is complete.

% ttGridAdmin dbCreate database1
Database database1 creation started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 18:38:39 PST 2017
 
creating,loading-partial,closed
Completely created elements: 1 (of 4) (3 in progress)
Completely loaded elements: 1 (of 4) (3 in progress)
Completely created replica sets: 0 (of 0)
Completely loaded replica sets: 0 (of 0)
 
Open elements: 0 (of 4)
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 18:39:16 PST 2017
 
created,loaded,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 0 (of 0)
Completely loaded replica sets: 0 (of 0)
 
Open elements: 0 (of 4)

In the following example, element creation on one instance (assume mysys5host.griddata3) fails. The example tries again to create the element on that instance after the problem is resolved.

% ttGridAdmin dbCreate database1
Database database1 creation started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Sat Nov 11 14:23:05 PST 2017
 
created-partial,loaded,closed
Completely created elements: 3 (of 4)(1 failed)
Completely loaded elements: 3 (of 4)
Completely created replica sets: 0 (of 0)
Completely loaded replica sets: 0 (of 0)

Open elements: 0 (of 4)

(Resolve the problem with mysys5host.griddata3.)

% ttGridAdmin dbCreate database1 -instance mysys5host.griddata3
Database database1 creation started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 13:44:12 PST 2017
 
created,loaded,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 0 (of 0)
Completely loaded replica sets: 0 (of 0)
 
Open elements: 0 (of 4)

Notes

  • Each instance creates its element of the database, loads the element into memory, and records the state of the element.

  • If you run dbCreate asynchronously (without waiting), you can use the dbStatus command to see when the database is created.

  • The database is marked as "existing" as soon as the dbCreate command returns. If you run the command in the default -nowait mode, you can unload the database while its creation is still in progress.

  • The database is not available for connections from users other than the instance administrator until you define the database distribution map with dbDistribute and open the database with dbOpen.

  • A typical use case for the -instance option is when an element of the database had previously failed, been evicted or removed from the database distribution map, and been destroyed. (Then also use dbDistribute to add the element to the distribution map.)

Destroy a database (dbDestroy)

The dbDestroy command destroys the specified database. All data and schema contained in the database are irretrievably lost.

ttGridAdmin dbDestroy name 
                      [-instance hostname[.instancename]]
                      [-nowait | -wait [timeout]]

Options

The dbDestroy command has the options:

Option Description
name Name of the database to destroy.
-instance hostname[.instancename] If specified, database element(s) will be destroyed only on the specified instance(s), but elements will remain on all other instances of the grid. The elements to destroy must have been previously evicted or removed from the database distribution map or never added to the distribution map.

The hostname is required. The instancename is required only if there is more than one instance on the host.

You can use this option only once, specifying a single instance, in a single command.

-nowait | -wait [timeout] The command initiates a state change that is recorded in the active management instance of the grid.

The -nowait option causes the command to return immediately without waiting for the state change. This is the default behavior.

The -wait option causes the command to wait for the state change to complete, when the database element has been destroyed on each instance in the grid. You can optionally subject the wait to a limit of timeout seconds. Otherwise, or if timeout is set to 0, there is no limit.

In a large grid, it is not typical or generally advisable to use -wait. If you do, it is advisable to set a timeout. (See "Database management operations".)


Examples

This example destroys a database without waiting for the elements to be destroyed on all instances. A subsequent attempt to check status indicates that the database was successfully destroyed.

% ttGridAdmin dbDestroy database1
Database database1 destroy started
...
% ttGridAdmin dbStatus database1
Error 2: Database database1 does not exist

This example destroys two of the four elements in the database. Both elements are from the same replica set and had previously been evicted.

% ttGridAdmin dbDestroy database1 -instance mysys3host.griddata1
Database database1 instance mysys3host.griddata1 destroy started
% ttGridAdmin dbDestroy database1 -instance mysys4host.griddata2 
Database database1 instance mysys4host.griddata2 destroy started
% ttGridAdmin dbStatus database1
Database database1 summary status as of Tue Jan  9 16:04:16 PST 2018
 
created,unloaded,closed
Completely created elements: 2 (of 4)
Completely loaded elements: 0 (of 4)
Completely created replica sets: 1 (of 1)
Completely loaded replica sets: 0 (of 1)
 
Open elements: 0 (of 4)

Notes

  • The database must be unloaded or unloading.

  • If you run dbDestroy asynchronously (without waiting), you can use the dbStatus command to see when the database is removed.

  • A typical use case for the -instance option is after an element of the database failed and was evicted or removed from the database distribution map. Then using dbDestroy with -instance recovers the disk space of the failed element.

Force all connections to disconnect (dbDisconnect)

The dbDisconnect command forces all user connections to the specified database to be disconnected. This is useful, for example, prior to maintenance operations. Closing connections is mandatory to ensure a smooth shutdown and no data loss.

ttGridAdmin dbDisconnect name
                         -transactional|-immediate|-abort
                         [-nowait | -wait [timeout]]

No new transactions are allowed before the command executes.

A disconnection request is sent to each data instance in the grid.

See "Unloading a database from memory" in Oracle TimesTen In-Memory Database Scaleout User's Guide for related information.

Note:

The dbDisconnect command does not affect subdaemon connections.

Options

The dbDisconnect command has the options:

Option Description
name Name of the database.
-transactional|-immediate|-abort Specify the mode for the disconnection process. You must specify one of the following modes (there is no default):
  • Transactional: Allow any open transactions to be committed or rolled back before disconnecting.

  • Immediate: Roll back any open transactions before immediately disconnecting.

  • Abort: Abort all direct mode application processes and client/server agents in order to disconnect.

A recommended best practice is to run dbDisconnect twice, as necessary. First run it in transactional mode. Then, after allowing some time, if not all connections have been closed yet, run it in immediate mode. Use dbStatus -connections to confirm whether connections have been closed.

Use abort mode only as a last resort if transactional and immediate levels do not result in all connections being closed. Abort may result in loss of data. Abort abruptly causes every user and ttcserver process connected to the database to exit. This may result in lost transactions.

Note: Execution in immediate mode also disconnects idle connections. Execution in transactional mode does not.

-nowait | -wait [timeout] Specifies whether the command should return immediately (the default) or wait until all disconnections finish. With -wait, you can optionally limit the wait time to timeout seconds.

Database management commands initiate a state change that is recorded in the active management instance of the grid. More specifically, the -nowait option causes the command to return without waiting for the state change. Use dbDisconnectStatus to check status of the disconnection process.

The -wait option causes the command to wait for the state change to complete, when all disconnections are complete. Without timeout or if timeout is set to 0, there is no limit.

If there is a large number of connections, it may not be advisable to use -wait. If you do, it is advisable to set a timeout. If disconnections have not completed in the specified wait time and you are using transactional mode, consider using immediate mode.

Note: Even when using -wait, it is advisable to use dbStatus -connections afterward to confirm connections are closed.


Examples

This example:

  1. Uses dbStatus to show existing connections.

  2. Closes the database and confirms.

  3. Disconnects in transactional mode (without wait).

  4. Checks status of the dbDisconnect command with dbDisconnectStatus and the status of the connections with dbStatus. (The dbDisconnect command is in progress and the connections still exist.)

  5. Disconnects in immediate mode (without wait), to be sure connections are closed.

  6. Again checks status of the dbDisconnect command with dbDisconnectStatus and the status of the connections with dbStatus. (The dbDisconnect command has completed and the connections are gone.)

% ttGridAdmin dbStatus database1 -connections
Host       Instance  ConnId Name      Pid   Type   CHost CAddr CPid
---------- --------- ------ --------- ----- ------ ----- ----- ----
mysys5host instance3      1 database1 20233 Direct
mysys4host instance2      1 database1 26529 Direct
mysys3host instance1      1 database1  1600 Direct
mysys6host instance4      1 database1  1678 Direct

% ttGridAdmin dbClose database1
Database database1 close started
 
% ttGridAdmin dbStatus database1
Database database1 summary status as of Tue Nov 27 16:12:16 PST 2018
 
created,loaded-complete,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 2 (of 2)
Completely loaded replica sets: 2 (of 2)
 
Open elements: 0 (of 4)

First try disconnecting in transactional mode:

% ttGridAdmin dbDisconnect database1 -transactional
Database database1 dbDisconnect started

Let some time pass, then check status—connections still exist:

% ttGridAdmin dbDisconnectStatus database1
Database  Host       Instance  Elem State         Started
--------- ---------- --------- ---- ------------- ------------------------
database1                           Disconnecting 2018-11-27T16:12:55.000Z
          mysys5host instance3    1 Disconnecting
          mysys4host instance2    2 Disconnecting
          mysys3host instance1    3 Disconnecting
          mysys6host instance4    4 Disconnecting
 
% ttGridAdmin dbStatus -connections
Database database1:
 
Host       Instance  ConnId Name      Pid   Type   CHost CAddr CPid
---------- --------- ------ --------- ----- ------ ----- ----- ----
mysys5host instance3      1 database1 20233 Direct
mysys4host instance2      1 database1 26529 Direct
mysys3host instance1      1 database1  1600 Direct
mysys4host instance4      1 database1  1678 Direct

Try again in immediate mode:

% ttGridAdmin dbDisconnect database1 -immediate
Database database1 dbDisconnect started

Check status again—now the connections are gone.:

% ttGridAdmin dbDisconnectStatus database1
Database  Host       Instance  Elem State        Started
--------- ---------- --------- ---- ------------ ------------------------
database1                           Complete     2018-11-27T16:14:03.000Z
          mysys5host instance3    1 Disconnected
          myshs4host instance2    2 Disconnected
          mysys3host instance1    3 Disconnected
          mysys6host instance4    4 Disconnected
 
% ttGridAdmin dbStatus database1 -connections
Host Instance ConnId Name Pid Type CHost CAddr CPid
---- -------- ------ ---- --- ---- ----- ----- ----
%

Notes

  • The database must be in a closed state before you execute this command. (Closing a database does not affect existing connections, but does prevent new connections.)

  • In TimesTen Scaleout, the capability to force disconnections is always enabled and the forceDisconnectEnabled connection attribute is ignored.

Check status of forced disconnection (dbDisconnectStatus)

The dbDisconnectStatus command reports the status of the executing or most recently executed dbDisconnect command.

ttGridAdmin dbDisconnectStatus name

Any of these states may be reported for the overall status of the dbDisconnect command:

  • Defined: Disconnect has been requested but not yet initiated.

  • Disconnecting: Disconnect is still in progress on at least one element.

  • Failed: Disconnect failed on at least one element.

  • Complete: Disconnect completed successfully on all elements.

Any of these states may be reported for the status of the disconnect on any given instance:

  • Disconnecting: Disconnect is in progress on the instance.

  • Failed: Disconnect failed on the instance.

  • Disconnected: Disconnect completed successfully on the instance.

Options

The dbDisconnectStatus command has the option:

Option Description
name Name of the database.

Examples

A dbDisconnectStatus example is included in the dbDisconnect example in the preceding section.

Set or modify the distribution scheme of a database (dbDistribute)

The dbDistribute command can add, remove, evict, and replace elements of a database in the distribution map of the database, then distribute or redistribute data among elements. You must always use -apply to apply changes and redistribute data. You can do this either in the same command or in a separate command.

ttGridAdmin dbDistribute name 
         [-list]
         [-add all | hostname[.instancename]]
         [-remove hostname[.instancename] [-replaceWith hostname[.instancename]]]
         [-evict hostname[.instancename] [-replaceWith hostname[.instancename]]]
         [-apply|-reset|-resync]

Wait until the elements are loaded on all instances on which you will perform operations before using dbDistribute. You can use the dbStatus command to confirm this.

See "Define the distribution map of the database" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.

Options

The dbDistribute command has the options:

Option Description
name Name of the database for data distribution changes.
-add all | hostname[.instancename] Adds elements to the distribution map, either all currently existing elements in the grid or elements on the specified instances. (If an element was not created because an instance is down, there would be no attempt to add it with -add all. It is not currently existing.)

Specify one instance per usage, but you can use -add more than once on a command line.

When the additions are applied, data will be distributed evenly across the grid.

Notes:

  • If you use -add all, you must use -apply in the same command.

  • Until you issue -apply, the element is marked to be added but is not actually added yet.

Also see Notes below for this and other options taking hostname[.instancename].

-remove hostname[.instancename] Use this option in any circumstance where you want to remove, and optionally replace, an element, such as to replace an older host system with a newer one. Also see Notes below.

Specify one instance per usage, but you can use -remove more than once on a command line.

It is typical to use -replaceWith to replace the element. The -remove option without -replaceWith results in redistribution of data.

If you have a grid with k=2 and you remove one element of a replica set, you must either replace it or also remove the other element of the replica set.

Note: Until you issue -apply, the element is marked for removal but is not actually removed yet.

Also see "Redistributing data in a database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

-evict hostname[.instancename] Use this option if all elements of a replica set (one element if k=1, two elements if k=2) have unrecoverable failures and you cannot repair them.

Important: Using the -evict option inevitably results in data loss. Use this only as a last resort.

Specify one instance per usage, but you can use -evict more than once on a command line.

If you use -evict, you must evict all elements in the replica set.

You can use -replaceWith to replace the element.

Notes:

  • Do not issue or apply -evict together with -add or -remove.

  • Until you issue -apply, the element is marked for eviction but is not actually evicted yet.

  • Eviction results in the element being forcibly unloaded.

Also see Notes below for additional considerations.

For additional information, see "Redistributing data in a database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

-replaceWith hostname[.instancename] Optionally use this with -evict or -remove to have the specified replacement contain the same data. The element on the replacing instance must not have previously been added to the distribution.

The -replaceWith option must immediately follow the corresponding -remove or -evict option on the command line.

-list Displays the current and pending distribution map of the database ("Holds Data" and "Will Hold Data", respectively).
-apply Applies the new distribution to the database. You can use this option by itself to apply settings from previous commands, or in the same command line with the settings.
-reset Discards all distribution settings that have not yet been applied. This option cannot be combined with any other option.

Note: You cannot use -reset while distribution (-apply) is in progress. You can try -resync instead, as appropriate.

-resync Attempts to resynchronize metadata in the user database with metadata in the active management instance in case the state of a dbDistribute -apply command is unknown. For example, the user database and management instance may not have matching states due to some failure or loss of communication. In some cases, the management instance may not know about the success or failure of a dbDistribute operation on the data instances and is left in an intermediate state.

This option cannot be used with any other dbDistribute options.

See "Recovering from a data distribution error" in Oracle TimesTen In-Memory Database Scaleout User's Guide for related information.

Note: The -resync option results in metadata in the management instance being read to see if there is a dbDistribute operation that is in progress but was neither committed nor rolled back. Resynchronizing may involve committing or rolling back the metadata changes of the dbDistribute operation (which are intended to be recorded in the management instance).


Examples

This example adds all elements in the grid to the distribution map then distributes data among the elements:

% ttGridAdmin dbDistribute database1 -add all -apply
Distribution map updated

You can then use the -list option to show the distribution map of elements in the grid (elements able to hold data):

% ttGridAdmin dbDistribute database11 -list
Distribution Map version: 1
RS Host        Instance  Holds Data Will Hold Data Removed Evicted
-- ----------- --------- ---------- -------------- ------- -------
 1  mysys3host griddata1          Y              Y       N       N
 1  mysys4host griddata2          Y              Y       N       N
 2  mysys5host griddata3          Y              Y       N       N
 2  mysys6host griddata4          Y              Y       N       N

Now remove both elements in replica set 1, then look at the -list output again, which indicates the two elements removed from the grid and therefore unable to hold data:

% ttGridAdmin dbDistribute database1 -remove mysys3host.griddata1
Element mysys3host.griddata1 is removed
Distribution map change enqueued
% ttGridAdmin dbDistribute database1 -remove mysys4host.griddata2
Element mysys4host.griddata2 is removed
Distribution map change enqueued
% ttGridAdmin dbDistribute database1 -apply
Distribution map updated

% ttGridAdmin dbDistribute database1 -list
Distribution Map version: 3
RS   Host        Instance  Holds Data Will Hold Data Removed Evicted
---- ----------- --------- ---------- -------------- ------- -------
NULL  mysys3host griddata1          N              N       Y       N
NULL  mysys4host griddata2          N              N       Y       N
   1  mysys5host griddata3          Y              Y       N       N
   1  mysys6host griddata4          Y              Y       N       N

The following is a new example that evicts two elements (from the same replica set) then looks at the -list output, which shows the two elements evicted from the grid and therefore unable to hold data.

% ttGridAdmin dbDistribute database1 -evict mysys3host.griddata1 -evict
mysys4host.griddata2 -apply
Distribution map updated
 
% ttGridAdmin dbDistribute database1 -list
Distribution Map version: 2
RS   Host       Instance  Holds Data Will Hold Data Removed Evicted
---- ---------- --------- ---------- -------------- ------- -------
NULL mysys3host griddata1          N              N       N       Y
NULL mysys4host griddata2          N              N       N       Y
   1 mysys5host griddata3          Y              Y       N       N
   1 mysys6host griddata4          Y              Y       N       N

This example shows where the -resync option successfully completed a data distribution operation:

% ttGridAdmin dbDistribute database1 -apply
...

(Process fails or is interrupted.)

% ttGridAdmin dbDistribute database1 -resync
Distributiom map updated

And this example shows where the -resync option rolled back a data distribution operation:

% ttGridAdmin dbDistribute database1 -apply
...

(Process fails or is interrupted.)

% ttGridAdmin dbDistribute database1 -resync
Distributiom map Rolled Back

Notes

  • You can use -list and -resync while distribution is in progress. Other operations will fail if distribution is in progress.

  • To specify an element, express its instance as hostname[.instancename]. The host name is required. The instance name is required only if there are multiple instances on the host. (See "Grid objects and object naming".)

  • If you need to confirm which elements are in each replica set, use the dbStatus command with the -replicaSet option.

  • Once an element has been removed or evicted from the distribution, the only possibility is to eliminate it with dbDestroy -instance. It is advisable to do that as soon as possible to reclaim the disk space that it used. If you want to be able to use the instance again later, you must recreate the element with dbCreate -instance, then add it to the distribution.

  • If k=2 and one element of a replica set has an irrecoverable failure, use -remove and -replaceWith to make the replica set fully operational again. Do not use -evict when an active replica is available.

  • If all elements of any replica set are down, you cannot perform global operations. If you cannot recover any element of the replica set, evicting the elements of the replica set will allow you to perform global operations again, but there will be permanent loss of data.

  • It is valid to use -add instead of -replaceWith to replace the elements of an evicted replica set, but in either case data on the evicted replica set is lost. Also note that -add results in redistribution of data while -replaceWith (used with either -evict or -remove) does not. See "Recovering when the replica set has a permanently failed element" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.

  • See "Recovering from Failure" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information and considerations regarding failure modes.

List databases (dbList)

The dbList command lists the databases that have been created in the grid and indicates whether they have been loaded or opened.

ttGridAdmin dbList

Examples

% ttGridAdmin dbList
Database                       Loaded Opened
database1                        Y      Y
testdb                           Y      N

Load a database into memory (dbLoad)

The ttGridAdmin dbLoad command loads the specified database into memory. A database must be loaded and opened before it is used by applications.

ttGridAdmin dbLoad name 
                   [-nowait | -wait [timeout]]

Options

The dbLoad command has the options:

Option Description
name Name of the database to load.
-nowait | -wait [timeout] The command initiates a state change that is recorded in the active management instance of the grid.

The -nowait option causes the command to return immediately without waiting for the state change. This is the default behavior.

The -wait option causes the command to wait for the state change to complete, when the database element has been loaded on each instance in the grid. You can optionally subject the wait to a limit of timeout seconds. Otherwise, or if timeout is set to 0, there is no limit.

In a large grid, it is not typical or generally advisable to use -wait. If you do, it is advisable to set a timeout. (See "Database management operations".)


Examples

This example loads a database without waiting for the elements to be loaded on all instances, then checks status (after the database was successfully loaded):

% ttGridAdmin dbLoad database1
Database database1 load started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 18:58:53 PST 2017
 
created,loaded,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 0 (of 0)
Completely loaded replica sets: 0 (of 0)
 
Open elements: 0 (of 4)

Notes

  • Before loading a database, it is advisable to run dbStatus with the -loadReadiness option to confirm all replica sets can be loaded.

  • After the command has completed, the database is loaded but closed. (Use dbOpen to open it.)

  • It is not necessary to run dbLoad after dbCreate, because dbCreate loads the database automatically.

  • If you run dbLoad asynchronously (without waiting), you can use the dbStatus command to see when the database is loaded.

Open a database (dbOpen)

The dbOpen command opens the database so that applications can connect to it.

ttGridAdmin dbOpen name 
                   [-nowait | -wait [timeout]]

Options

The dbOpen command has the options:

Option Description
name Name of the database to open.
-nowait | -wait [timeout] The command initiates a state change that is recorded in the active management instance of the grid.

The -nowait option causes the command to return immediately without waiting for the state change. This is the default behavior.

The -wait option causes the command to wait for the state change to complete, when the database element has been opened on each instance in the grid. You can optionally subject the wait to a limit of timeout seconds. Otherwise, or if timeout is set to 0, there is no limit.

In a large grid, it is not typical or generally advisable to use -wait. If you do, it is advisable to set a timeout. (See "Database management operations".)


Examples

This example opens a database without waiting for the elements to be opened on all instances, then checks status (after the database was opened successfully):

% ttGridAdmin dbOpen database1
Database database1 open started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 19:24:39 PST 2017
 
created,loaded-complete,open
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 2 (of 2)
Completely loaded replica sets: 2 (of 2)
 
Open elements: 4 (of 4)

Notes

  • The database must be loaded or loading (performed automatically by dbCreate).

  • The database must have a distribution map (dbDistribute -apply).

  • If you run dbOpen asynchronously (without waiting), you can use the dbStatus command to see when the database is open.

  • If a database has been opened with dbOpen, attempting to open it again typically results in an error. However, if any element is in "open failed" state, you can retry dbOpen. Doing so will change any element in "open failed" state to "loaded" state, which will result in TimesTen Scaleout trying to open it again.

Monitor the status of a database (dbStatus)

The dbStatus command reports the status of a database or databases or the status of specified components of the database or databases, using information from the active management instance. This includes the status of any pending command to create, destroy, load, unload, open, or close the database. You can also request additional details, or request information about the state of each instance regarding whether its element can be loaded.

ttGridAdmin dbStatus [name]
                     [-summary]
                     [-element]
                     [-replicaSet]
                     [-dataSpaceGroup]
                     [-all]
                     [-details]
                     [-loadReadiness]
                     [-epochs]
                     [-connections [-proxy] [-system]]

You can also refer to dbStatus discussion and examples in "Recovering from Failure" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Options

The dbStatus command has the options:

Option Description
name Name of the database for which to display status. The default is to display status of all databases in the grid.
-summary Shows an overall summary of database status. (This is the default mode.)
-element Shows the status of each element of the database.
-replicaSet Shows the status of each replica set of the database.
-dataSpaceGroup Shows the status of each data space group of the database.
-all Shows summary, element, replica set, and data space group status (equivalent to -summary -element -replicaSet -dataSpaceGroup).
-details Shows daemon state information in addition to the status information from the active management instance. You can use this option in addition to any of the preceding options.
-loadReadiness Shows information, including up/down status, indicating whether instances in each replica set are in a state where their elements can be loaded.

It is advisable to use this option before trying to load a database. You can also use it while a load is in progress.

-epochs Shows the most recent epochs available for each element of the grid, and the most recent epoch that could be used for recovery.

An epoch is a transaction that marks a globally consistent point in time across all elements of the database. See "Epoch transactions" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

-connections Displays information for existing connections to the specified database. Without the -proxy or -system suboptions, only application connections are shown.
-proxy Used with the -connections option, this also displays information for all proxy connections associated with existing application connections.

Note: This option cannot be used without the -connections option.

-system Used with the -connections option, this also displays TimesTen internal connections, such as those used by subdaemons and TimesTen utilities.

Note: This option cannot be used without the -connections option.


Overall database status

The dbStatus command indicates the status of the database as a whole with a line showing overall created/destroyed, loaded/unloaded, and opened/closed states. (For example: "created,loaded-complete,closed".)

The states of created, creating, destroyed, loading, loaded, unloaded, unloading, opening, opened, closing, and closed indicate that the corresponding database management command is in progress or has finished, as stated.

In addition:

  • created-partial or creating-partial: Some elements of the database are in the process of being created or have successfully been created, but others could not be created.

  • createFailed: Creation of the database failed. This occurs when no elements could be created, such as when every TimesTen instance is down.

  • loaded-partial or loading-partial: The dbDistribute command has not yet been executed on the database (so no replica sets have been defined) and at least one element could not be created or loaded.

  • loaded-incomplete or loading-incomplete: At least one replica has no elements that finished loading successfully.

  • loaded-functional or loading-functional: At least one element from each replica set is loaded.

  • loaded-complete or loading-complete: Every element loaded successfully.

  • notLoaded: Loading of the database failed—none of the elements is loaded or loading.

These states can help you determine if the grid is usable even if it is not fully operational. For example, you can execute dbOpen before all the elements have been loaded.

Element status values

The dbStatus command returns these database element status values:

Note:

See "Troubleshooting distributed transactions" in Oracle TimesTen In-Memory Database Scaleout User's Guide for recommendations regarding these status values.
Status Description
close failed The attempt to close the element failed.
closing The element is in the process of closing.
create failed The attempt to create the element failed.
creating The element is being created.
destroy failed The attempt to destroy the element failed.
destroyed The element has been destroyed.
destroying The element is being destroyed.
down The data instance where this element is located is not running.
evicted The element was evicted or removed through dbDistribute and has been unloaded from RAM.
evicted (loaded) The element was evicted or removed through dbDistribute but unloading it from RAM has not yet begun.
evicted (unloading) The element was evicted or removed through dbDistribute and is being unloaded from RAM.
load failed The attempt to load the element into RAM failed.
loaded The element is loaded into RAM.
loading The element is being loaded into RAM.
opened The element is open.
open failed The attempt to open the element failed.
opening The element is in the process of opening.
uncreated The element should be created, but creation has not yet started.
unloaded The element has been unloaded from RAM.
unloading The element is being unloaded from RAM.
waiting for seed The element will be loaded into RAM, but not until after the other element in its replica set is loaded.

Connections status

This section describes information displayed by the -connections, -proxy, and -system options that show existing connections.

Connection status item Description
Host For the target of the connection, name of the host object in the model for the host where the data instance resides.
Instance For the target of the connection, name of the instance object in the model for the data instance.
ConnId Connection ID of the connection to the data instance.
Name Name of the connection as indicated by the TimesTen ConnectionName connection attribute. (See "ConnectionName" for information about that attribute.)
Pid Operating system process ID of the process that established the connection.

For direct mode applications, this is the process ID of the application. For client/server applications, this is the process ID of the client/server ttcserver process acting on behalf of the application.

Type The type of connection. One of the following:
  • Direct for connections from direct mode applications.

  • C/S for connections from client/server applications.

  • Proxy for connections created by TimesTen that work on behalf of application connections, such as a connection to a different grid element that is necessary to access some of the data.

  • GCW for TimesTen internal connections from grid connection workers.

  • Subdaemon for TimesTen internal connections from TimesTen subdaemons.

  • TTStats for TimesTen internal connections for collection of statistics.

CHost For client/server connections, the host name of the client where the application is running.

Note: This item is not shown when the -proxy option is used.

CAddr For client server connections, the IP address of the client where the application is running.

Note: This item is not shown when the -proxy option is used.

CPid For client/server connections, the operating system process ID of the application.

Note: This item is not shown when the -proxy option is used.

PHost For proxy connections, the name of the host where the proxy connection is established.
PInstance For proxy connections, the name of the TimesTen instance where the proxy connection is established.
PPid For proxy connections, the operating system process ID of the process that established the connection.
PConnId For proxy connections, the connection ID.

Examples

Database status examples

Key for these examples:

  • RS: Identifying number of the replica set that each element belongs to.

  • DS: Identifying number of the data space group that each element belongs to.

  • Elem: Element number for each element.

  • Status: Status of the operation on each element. See "Status values" above for the list of element states that can be returned.

This example shows complete dbStatus output after a database has had its distribution specified, but the database is closed.

% ttGridAdmin dbStatus database1 -all
Database database1 summary status as of Thu Nov 17 13:28:16 PST 2016
 
created,loaded-complete,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 4 (of 4)
Completely created replica sets: 2 (of 2)
Completely loaded replica sets: 2 (of 2)
 
Open elements: 0 (of 4)
 
Database database1 element level status as of Thu Nov 17 13:28:16 PST 2016
 
Host        Instance     Elem Status Date/Time of Event  Message
----------- ------------ ---- ------ ------------------- -------
 mysys3host griddata1       3 loaded 2016-11-16 17:36:39
 mysys4host griddata2       1 loaded 2016-11-16 17:36:40
 mysys5host griddata3       4 loaded 2016-11-16 17:36:39
 mysys6host griddata4       2 loaded 2016-11-16 17:36:41
 
Database database1 Replica Set status as of Thu Nov 17 13:28:16 PST 2016
 
RS DS Elem Host        Instance  Status Date/Time of Event  Message
-- -- ---- ----------- --------  ------ ------------------- -------
 1  1    3 mysys3host  griddata1 loaded 2016-11-16 17:36:39      
    2    1 mysys4host  griddata2 loaded 2016-11-16 17:36:40      
 2  1    4 mysys5host  griddata3 loaded 2016-11-16 17:36:39      
    2    2 mysys6host  griddata4 loaded 2016-11-16 17:36:41      
 
Database database1 Data Space Group status as of Thu Nov 17 13:28:16 PST 2016
 
DS RS Elem Host        Instance  Status Date/Time of Event  Message
-- -- ---- ----------- --------- ------ ------------------- -------
 1  1    3 mysys3host  griddata1 loaded 2016-11-16 17:36:39      
    2    4 mysys5host  griddata3 loaded 2016-11-16 17:36:39      
 2  1    1 mysys4host  griddata2 loaded 2016-11-16 17:36:40      
    2    2 mysys6host  griddata4 loaded 2016-11-16 17:36:41      

This example shows load readiness with all instances up, then with one instance in a replica set down, then with both instances in a replica set down. If all instances in a replica set are down, the database cannot be loaded.

% ttGridAdmin dbStatus database1 -loadReadiness
Data Elements:
RS DS Instance             State
-- -- -------------------- --------
 1  1 mysys3host.griddata1 Unloaded
 1  2 mysys4host.griddata2 Unloaded
 1                         Loadable
 2  1 mysys5host.griddata3 Unloaded
 2  2 mysys6host.griddata4 Unloaded
 2                         Loadable
 
database1 load state: Loadable
Total Elements Loaded:0/4
...

% ttGridAdmin dbStatus database1 -loadReadiness
Data Elements:
RS DS Instance             State
-- -- -------------------- --------
 1  1 mysys3host.griddata1 Down
 1  2 mysys4host.griddata2 Unloaded
 1                         Loadable
 2  1 mysys5host.griddata3 Unloaded
 2  2 mysys6host.griddata4 Unloaded
 2                         Loadable
 
database1 load state: Loadable
Total Elements Loaded:0/4
...

% ttGridAdmin dbStatus database1 -loadReadiness
Data Elements:
RS DS Instance             State
-- -- -------------------- -------------
 1  1 mysys3host.griddata1 Down
 1  2 mysys4host.griddata2 Down
 1                         Not Loadable
 2  1 mysys5host.griddata3 Unloaded
 2  2 mysys6host.griddata4 Unloaded
 2                         Loadable
 
database1 load state: Not Loadable
Total Elements Loaded:0/4

This example shows the epochs of the database. The important point is that if durability=0 and no recovery epoch is shown, the database is not recoverable.

% ttGridAdmin dbStatus database1 -epochs
Database database1 element level status as of Tue Jan  9 16:49:39 PST 2018
 
Host       Instance  Elem Status Recent Epochs
---------- --------- ---- ------ ------------------------------------------------------------
mysys4host griddata2    1 loaded 286.3 288.1 290.2 292.4 294.3 296.1 298.2 300.1 302.2 304.4
mysys6host griddata4    2 loaded 286.3 288.1 290.2 292.4 294.3 296.1 298.2 300.1 302.2 304.4
mysys3host griddata1    3 loaded 286.3 288.1 290.2 292.4 294.3 296.1 298.2 300.1 302.2 304.4
mysys5host griddata3    4 loaded 286.3 288.1 290.2 292.4 294.3 296.1 298.2 300.1 302.2 304.4
 
Most recent recovery epoch: 304.4

Connection status examples

Examples are shown for the -connections option by itself, -connections with -proxy, -connections with -system, and -connections with both -proxy and -system.

% ttgridadmin dbstatus database1 -connections
Host   Instance  ConnId Name        Pid  Type   CHost  CAddr         CPid
------ --------- ------ ----------- ---- ------ ------ ------------- ----
mysys1 instance1      1 database1   8631 Direct                          
mysys1 instance1      2 con1        8631 Direct                          
mysys1 instance1      3 con2        8631 Direct                          
mysys2 instance2      1 database1cs 8653 C/S    mysys2 10.90.137.240 8637
mysys2 instance2      2 con1        8666 C/S    mysys2 10.90.137.240 8637

% ttgridadmin dbstatus database1 -connections -proxy
Host   Instance  ConnId Name        Pid  Type   PHost  PInstance PPid  PConnId
------ --------- ------ ----------- ---- ------ ------ --------- ----- -------
mysys1 instance1      1 database1   8631 Direct                               
mysys1 instance1      2 con1        8631 Direct                               
mysys1 instance1      2 con1        8631 Proxy  mysys2 instance2 31210       4
mysys1 instance1      3 con2        8631 Direct                               
mysys1 instance1      3 con2        8631 Proxy  mysys2 instance2 31210       3
mysys2 instance2      1 database1cs 8653 C/S                                  
mysys2 instance2      2 con1        8666 C/S                                  

% ttgridadmin dbstatus database1 -connections -system
Host   Instance  ConnId Name                       Pid   Type      CHost    CAddr         CPid
------ --------- ------ -------------------------- ----- --------- -------- ------------- ----
mysys1 instance1      1 database1                   8631 Direct                               
mysys1 instance1      2 con1                        8631 Direct                               
mysys1 instance1      3 con2                        8631 Direct                               
mysys1 instance1    128 Grid Epoch Generator(TM=2) 31183 GCW                                  
mysys1 instance1    129 ttStats Collector          31183 GCW                                  
mysys1 instance1    130 ttStats Collector          31871 TTStats                              
mysys1 instance1    131 Garbage Collector          30876 Subdaemon                            
mysys1 instance1    132 Grid Watch Remote TM       30876 Subdaemon                            
mysys1 instance1    133 Grid Rem Elem Mon          30876 Subdaemon                            
mysys1 instance1    134 XactId Rollback            30876 Subdaemon                            
mysys1 instance1    135 Grid Epoch Generator       30876 Subdaemon                            
mysys1 instance1    136 Grid Seq Batch             30876 Subdaemon                            
mysys1 instance1    137 GCW Watcher                30876 Subdaemon                            
mysys1 instance1    138 HistGC                     30876 Subdaemon                            
mysys1 instance1    139 Log Marker                 30876 Subdaemon                            
mysys1 instance1    140 IndexGC                    30876 Subdaemon                            
mysys1 instance1    141 Grid Task                  30876 Subdaemon                            
mysys1 instance1    142 Deadlock Detector          30876 Subdaemon                            
mysys1 instance1    143 Flusher                    30876 Subdaemon                            
mysys1 instance1    144 Monitor                    30876 Subdaemon                            
mysys1 instance1    145 Checkpoint                 30876 Subdaemon                            
mysys1 instance1    146 Rollback                   30876 Subdaemon                            
mysys1 instance1    147 Manager                    30876 Subdaemon                            
mysys2 instance2      1 database1cs                 8653 C/S       mysys2 10.90.137.240   8637
mysys2 instance2      2 con1                        8666 C/S       mysys2 10.90.137.240   8637
mysys2 instance2      3 con2                       31210 GCW                                  
mysys2 instance2      4 con1                       31210 GCW                                  
mysys2 instance2    128 Grid Epoch Generator(TM=1) 31210 GCW                                  
mysys2 instance2    129 ttStats Collector          31210 GCW                                  
mysys2 instance2    130 ttStats Collector          31878 TTStats                              
mysys2 instance2    131 Grid Watch Remote TM       30950 Subdaemon                            
mysys2 instance2    132 HistGC                     30950 Subdaemon                            
mysys2 instance2    133 GCW Watcher                30950 Subdaemon                            
mysys2 instance2    134 Grid Epoch Generator       30950 Subdaemon                            
mysys2 instance2    135 Grid Seq Batch             30950 Subdaemon                            
mysys2 instance2    136 XactId Rollback            30950 Subdaemon                            
mysys2 instance2    137 Garbage Collector          30950 Subdaemon                            
mysys2 instance2    138 Grid Task                  30950 Subdaemon                            
mysys2 instance2    139 Log Marker                 30950 Subdaemon                            
mysys2 instance2    140 Grid Rem Elem Mon          30950 Subdaemon                            
mysys2 instance2    141 Flusher                    30950 Subdaemon                            
mysys2 instance2    142 IndexGC                    30950 Subdaemon                            
mysys2 instance2    143 Checkpoint                 30950 Subdaemon                            
mysys2 instance2    144 Deadlock Detector          30950 Subdaemon                            
mysys2 instance2    145 Monitor                    30950 Subdaemon                            
mysys2 instance2    146 Rollback                   30950 Subdaemon                            
mysys2 instance2    147 Manager                    30950 Subdaemon                            

% ttgridadmin dbstatus database1 -connections -proxy -system
Host   Instance  ConnId Name                       Pid   Type      PHost  PInstance PPid  PConnId
------ --------- ------ -------------------------- ----- --------- ------ --------- ----- -------
mysys1 instance1      1 database1                   8631 Direct                                  
mysys1 instance1      2 con1                        8631 Direct                                  
mysys1 instance1      2 con1                        8631 Proxy     mysys2 instance2 31210       4
mysys1 instance1      3 con2                        8631 Direct                                  
mysys1 instance1      3 con2                        8631 Proxy     mysys2 instance2 31210       3
mysys1 instance1    128 Grid Epoch Generator(TM=2) 31183 GCW                                     
mysys1 instance1    129 ttStats Collector          31183 GCW                                     
mysys1 instance1    130 ttStats Collector          31871 TTStats                                 
mysys1 instance1    130 ttStats Collector          31871 Proxy     mysys2 instance2 31210     129
mysys1 instance1    131 Garbage Collector          30876 Subdaemon                               
mysys1 instance1    132 Grid Watch Remote TM       30876 Subdaemon                               
mysys1 instance1    133 Grid Rem Elem Mon          30876 Subdaemon                               
mysys1 instance1    134 XactId Rollback            30876 Subdaemon                               
mysys1 instance1    135 Grid Epoch Generator       30876 Subdaemon                               
mysys1 instance1    135 Grid Epoch Generator       30876 Proxy     mysys2 instance2 31210     128
mysys1 instance1    136 Grid Seq Batch             30876 Subdaemon                               
mysys1 instance1    137 GCW Watcher                30876 Subdaemon                               
mysys1 instance1    138 HistGC                     30876 Subdaemon                               
mysys1 instance1    139 Log Marker                 30876 Subdaemon                               
mysys1 instance1    140 IndexGC                    30876 Subdaemon                               
mysys1 instance1    141 Grid Task                  30876 Subdaemon                               
mysys1 instance1    142 Deadlock Detector          30876 Subdaemon                               
mysys1 instance1    143 Flusher                    30876 Subdaemon                               
mysys1 instance1    144 Monitor                    30876 Subdaemon                               
mysys1 instance1    145 Checkpoint                 30876 Subdaemon                               
mysys1 instance1    146 Rollback                   30876 Subdaemon                               
mysys1 instance1    147 Manager                    30876 Subdaemon                               
mysys2 instance2      1 database1cs                 8653 C/S                                     
mysys2 instance2      2 con1                        8666 C/S                                     
mysys2 instance2      3 con2                       31210 GCW                                     
mysys2 instance2      4 con1                       31210 GCW                                     
mysys2 instance2    128 Grid Epoch Generator(TM=1) 31210 GCW                                     
mysys2 instance2    129 ttStats Collector          31210 GCW                                     
mysys2 instance2    130 ttStats Collector          31878 TTStats                                 
mysys2 instance2    130 ttStats Collector          31878 Proxy     mysys1 instance1 31183     129
mysys2 instance2    131 Grid Watch Remote TM       30950 Subdaemon                               
mysys2 instance2    132 HistGC                     30950 Subdaemon                               
mysys2 instance2    133 GCW Watcher                30950 Subdaemon                               
mysys2 instance2    134 Grid Epoch Generator       30950 Subdaemon                               
mysys2 instance2    134 Grid Epoch Generator       30950 Proxy     mysys1 instance1 31183     128
mysys2 instance2    135 Grid Seq Batch             30950 Subdaemon                               
mysys2 instance2    136 XactId Rollback            30950 Subdaemon                               
mysys2 instance2    137 Garbage Collector          30950 Subdaemon                               
mysys2 instance2    138 Grid Task                  30950 Subdaemon                               
mysys2 instance2    139 Log Marker                 30950 Subdaemon                               
mysys2 instance2    140 Grid Rem Elem Mon          30950 Subdaemon                               
mysys2 instance2    141 Flusher                    30950 Subdaemon                               
mysys2 instance2    142 IndexGC                    30950 Subdaemon                               
mysys2 instance2    143 Checkpoint                 30950 Subdaemon                               
mysys2 instance2    144 Deadlock Detector          30950 Subdaemon                               
mysys2 instance2    145 Monitor                    30950 Subdaemon                               
mysys2 instance2    146 Rollback                   30950 Subdaemon                               
mysys2 instance2    147 Manager                    30950 Subdaemon                               

Unload a database (dbUnload)

The dbUnload command unloads the specified database from memory.

ttGridAdmin dbUnload name 
                     [-nowait | -wait [timeout]]
                     [-force]

Important:

If a dbUnload command is issued while a transaction is in progress, the command will not wait for the transaction to complete. Data may be lost as a result.

Options

The dbUnload command has the options:

Option Description
name Name of the database to unload.
-nowait | -wait [timeout] The command initiates a state change that is recorded in the active management instance of the grid.

The -nowait option causes the command to return immediately without waiting for the state change. This is the default behavior.

The -wait option causes the command to wait for the state change to complete, when the database element has been unloaded on each instance in the grid. You can optionally subject the wait to a limit of timeout seconds. Otherwise, or if timeout is set to 0, there is no limit.

In a large grid, it is not typical or generally advisable to use -wait. If you do, it is advisable to set a timeout. (See "Database management operations".)

-force If Durability=0 and at least one replica set is completely down, this option allows the unload to proceed anyway.

Important: Using this option will likely result in data loss.

(Normally, to prevent data loss, a database with Durability=0 cannot be unloaded unless at least one element from every replica set is loaded.)


Examples

This example unloads a database without waiting for the elements to be unloaded on all instances, then checks status (after the database was successfully unloaded).

% ttGridAdmin dbUnload database1
Database database1 unload started
...
% ttGridAdmin dbStatus database1
Database database1 summary status as of Mon Nov 13 18:52:47 PST 2017
 
created,unloaded,closed
Completely created elements: 4 (of 4)
Completely loaded elements: 0 (of 4)
Completely created replica sets: 0 (of 0)
Completely loaded replica sets: 0 (of 0)
 
Open elements: 0 (of 4)

Notes

  • Do not begin any transactions after issuing a dbUnload command.

  • All connections to the database must be closed.

  • The database must be closed.

  • If you run dbUnload asynchronously (without waiting), you can use the dbStatus command to see when the database is loaded.

Grid operations

Use the ttGridAdmin commands in this section to create a grid in the model, configure passwordless SSH for the grid, gather information about the grid, and make changes to the grid. There is also a command to produce a sys.odbc.ini file for use by clients outside of the grid.

Export sys.odbc.ini for client/server connections outside grid (gridClientExport)

The gridClientExport command produces a sys.odbc.ini file that can be used by TimesTen instances that are not part of the grid to access databases in the grid.

ttGridAdmin gridClientExport [filepath]

The resulting file contains definitions of all client/server connectables defined in the grid. You must manually copy this file to any TimesTen client instances outside of the grid from which you want to connect to databases in the grid.

Options

The gridClientExport command has the option:

Option Description
filepath Path and name of the file where the sys.odbc.ini entries are written.

If no file is specified, the entries are output to stdout.


Examples

This example exports the sys.odbc.ini entries to the file sys_export.odbc.ini, then shows the contents of that file.

% ttGridAdmin gridClientExport /sw/tten/grid/clients/sys_export.odbc.ini
% cd /sw/tten/grid/clients
% more sys_export.odbc.ini
[ODBC Data Sources]
database1client=TimesTen 18.1 Client Driver
 
[database1client]
TTC_SERVER_DSN=database1
# External address/port info for mysys3host.instance1
TTC_SERVER1=mysys3.example.com/21000
# External address/port info for mysys4host.instance1
TTC_SERVER2=mysys4.example.com/21000
ConnectionCharacterSet=AL32UTF8
UID=ttclient

Notes

This command uses the external address of the host.

Create a grid (gridCreate)

The gridCreate command creates a grid and the initial version of the model.

ttGridAdmin gridCreate name 
                        -k n
                        -membershipConfig filepath
                       [-address addr]
                       [-internalAddress addr]
                       [-externalAddress addr]
                       [-mgmtPort n]
                       [-host name]
                       [-retainDays numdays]
                       [-retainVersions n]
                       [-warnThresh percent]
                       [-noDataSpaceGroup]
                       [-walletDir path]

The instance from which the command is run becomes the initial management instance of the new grid. Additional instances (data instances and a second management instance) can then be created and joined to the grid later.

Options

The gridCreate command has the options:

Option Description
name Specifies the name for the grid in the model.
-k n Specifies the degree of K-safety that this grid provides. Specify a value of 1 or 2.
-membershipConfig filepath Path and name of the membership client configuration file, which contains the host name and port of each membership server.

The contents of this file will be automatically provisioned in every instance in the grid.

Sample contents:

Servers zk1.example.com!2181,zk2.example.com!2181,
zk3.example.com!2181

Note: Either colons or exclamation marks can be used between host and port. (Always use exclamation marks with IPv6 addresses, which themselves include colons.)

Also see "Membership operations" for information about exporting or importing the membership client configuration file and "Configure a grid as a membership service client" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.

-internalAddress addr DNS name or IP address of the local system for internal communications, inside the grid. Use this together with -externalAddress.

This option takes one name or address only, and a specified name must resolve to one IP address or to multiple IP addresses on the same network segment.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Also see Notes below and "Address formats".

-externalAddress addr DNS name or IP address of the local system for external communications, outside the grid, for client/server connections. Use this together with -internalAddress.

This option takes one name or address only, but a name may resolve to one or more IP addresses.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Also see Notes below and "Address formats".

-address addr DNS name or IP address of the local system for both external and internal communications, if a single address is used. Setting -address xxx is exactly equivalent to setting -internalAddress xxx and -externalAddress xxx.

This option takes one name or address only, and a specified name must resolve to one IP address or to multiple IP addresses on the same network segment.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Note: Using a single address is not recommended for production environments.

Also see Notes below and "Address formats".

-mgmtPort n Port number used by the initial management instance for replication when management data on the active management instance is replicated. This is required if there will be two management instances. The default is 3754.
-host name Specifies the name that will be given to the host object in the model for the initial host in the grid. If not specified, the first component of the operating system host name is used (the host name up to but not including the first ".", such as myhost).
-retainDays numdays Specifies that old versions of the model should be retained for numdays days, then automatically deleted. If numdays is 0, then old versions of the model are not automatically deleted based on their age. The default is 30.

Also see Notes below.

-retainVersions n Specifies that n old versions of the model should be retained. Anything older than the newest n versions are deleted. If n is 0, then old versions of the model are not automatically deleted based on the number of versions. The default is 10.

Also see Notes below.

-warnThresh percent Management instances store metadata for the grid and model. If the metadata on the active management instance fills beyond this percentage of capacity, ttGridAdmin commands result in warnings. The default is 90% full.
-noDataSpaceGroup Specifies that the initial host in the grid is not assigned to a data space group. If this option is not specified, the first host is assigned to data space group 1.

Do not set this option if the first host will contain a data instance as well as the management instance.

-walletDir path Path to the directory where the Oracle Wallet with cryptographic information for this instance will be stored. The default is timesten_home/info.

Wallets for multiple instances can be stored in the same directory, which can be shared between the instances, such as through NFS.


Examples

% ttGridAdmin gridCreate grid1 -k 2 -membershipConfig 
/sw/tten/grid/zkcfg/membership.conf -internalAddress intmysys1.example.com 
-externalAddress extmysys1.example.com -host mysys1host
Grid grid1 created

Notes

  • You cannot execute this command from an instance that is or has ever been part of another grid.

  • You cannot retry gridCreate if it fails. You must remove and recreate the management instance with ttInstanceDestroy and ttInstanceCreate. See "Destroying a grid" and "Creating the initial management instance" in Oracle TimesTen In-Memory Database Scaleout User's Guide for examples. See "ttInstanceDestroy" and "ttInstanceCreate" for reference information.

  • Hosts in the grid may be configured with either one or two network addresses, depending on system topology. If configured with two addresses, one is used for communications with systems inside the grid (internal) and one is used for client/server access to databases inside the grid from systems outside the grid (external). If configured with one address, which is not recommended for production environments, it is used for both internal and external communications. You must either set -address or set -internalAddress and -externalAddress.

  • You can specify both -retainDays and -retainVersions, in which case old versions of the model are automatically deleted if they are older than numdays days old and there are more than n old versions. If one option is specified as zero, then only the other option takes effect. If both are zero, old versions of the model are not automatically deleted.

  • Creating a grid creates version 1 of the grid model.

Display information about the grid (gridDisplay)

Use the gridDisplay command to display information about the grid.

ttGridAdmin gridDisplay

Examples

Grid name:                  grid1
Grid GUID:                  9D049059-1BF2-47E4-AEFA-D3ABA03F609E
Created:                    2017-10-30 19:05:47.000000
Major Release:              18.1
Created Release:            18.1.3.1.0
K:                          2
Admin Userid:               ttuser1
Admin UID:                  126
Admin Group:                timesten
Admin GID:                  59031
Retain Days:                30
Retain Versions:            10
Warn Threshold:             90
Perm In Use Pct:            8
Temp In Use Pct:            14

Get diagnostic information about the grid (gridDump)

The gridDump command outputs diagnostic information about the grid to the specified file. This command outputs a very large amount of information and is intended for use by Oracle Support.

ttGridAdmin gridDump [filepath]

Options

The gridDump command has the option:

Option Description
filepath Path and name of the file where diagnostic information is written.

If no file is specified, the information is written to stdout.


Examples

This example outputs to the file griddumpout. (When the dump goes to a file, the command has no visible output.)

% ttGridAdmin gridDump /sw/tten/grid/misc/griddumpout

Collect log information about the grid (gridLogCollect)

The gridLogCollect command collects daemon logs and other diagnostic information along with TimesTen configuration files from all instances in the grid. The aggregation of all of this is a collection.

ttGridAdmin gridLogCollect -repository reponame 
                           [collection]

Options

The gridLogCollect command has the options:

Option Description
-repository reponame Name of the repository where the collection of logs, diagnostic information, and configuration files is stored.

See "Create a repository (repositoryCreate)".

collection Name of the collection created to store the logs, diagnostic information, and configuration files.

If not specified, the name will be a timestamp in the format Lyyyymmddhhmmss.


Examples

This example creates a repository then creates a collection of logs, diagnostic information, and configuration files in that repository. (See "Create a repository (repositoryCreate)" for information about the repositoryCreate command.)

% ttGridAdmin repositoryCreate repocollection -path /repositories 
-method scp -address mysys1.example.com
Repository repocollection created

% ttGridAdmin gridLogCollect -repository repocollection mycollection 
Logs copied to collection mycollection in repository repocollection

In the repocollection directory, the repository.json file has information about the repository.

The mycollection directory contains logs and configuration files for each instance. (See "Collecting grid logs" in Oracle TimesTen In-Memory Database Scaleout User's Guide for information about the log files.)

Notes

These are automatically included in the collection:

  • Contents of the diag directory on each instance (or other diagnostics directory according to the supportlog setting in timesten.conf), such as daemon logs and core files

  • TimesTen configuration files from the conf directory on each instance.

  • Any .inval and .trace files from the DataStore directory of each element, as specified in the database definition

Modify grid settings (gridModify)

The gridModify command modifies properties of the grid, such as how long previous models of the grid will be retained or how many previous models of the grid will be retained.

ttGridAdmin gridModify [-retainDays numdays]
                       [-retainVersions n]
                       [-warnThresh percent]

Options

The gridModify command has the options:

Option Description
-retainDays numdays Specifies that old versions of the model should be retained for numdays days, then automatically deleted. If numdays is 0, then old versions of the model are not automatically deleted based on their age. The default is 30.

Also see Notes below.

-retainVersions n Specifies that n old versions of the model should be retained. Anything older than the newest n versions are deleted. If n is 0, then old versions of the model are not automatically deleted based on the number of versions. The default is 10.

Also see Notes below.

-warnThresh percent Management instances store metadata for the grid and model. If the metadata on the active management instance fills beyond this percentage of capacity, ttGridAdmin commands result in warnings. The default is 90% full.

Examples

This example shows selected output from gridDisplay before and after executing gridModify to change the number of days to retain old versions of the model.

% ttGridAdmin gridDisplay
Grid name:                  grid1
...
Retain Days:                30
Retain Versions:            10
...

% ttGridAdmin gridModify -retainDays 20
Grid Definition modified.

% ttGridAdmin gridDisplay
Grid name:                  grid1
...
Retain Days:                20
Retain Versions:            10
...

Notes

You can specify both -retainDays and -retainVersions, in which case old versions of the model are automatically deleted if they are older than numdays days old and there are more than n old versions. If one option is specified as zero, then only the other option takes effect. If both are zero, old versions of the model are not automatically deleted.

Configure SSH (gridSshConfig)

The gridSshConfig command configures a set of TimesTen Scaleout hosts for passwordless SSH connection, as needed or as specified.

ttGridAdmin gridSshConfig [ [-mgmtAddress addr1 [addr2]]
                          [-dataAddress addr1 [addr2 [addr3...]]]
                          [-repoAddress addr1 [addr2 [addr3...]]] ] |
                          [-internalAddress addr1 [addr2 [addr3...]]] 

Either use the -mgmtAddress option, -dataAddress option, and -repoAddress option (as applicable) or use the -internalAddress option, which cannot be used with any other option. Each address can be an IPv4 address, an IPv6 address, or (typically) a DNS name. Also see "Address formats".

You are prompted for the operating system password of the operating system user executing the command. That user must exist with the same password, UID, and group membership on every host to be configured.

Choose one of these modes of operation for the gridSshConfig command:

  • Run ttGridAdmin from outside a TimesTen instance, where TIMESTEN_HOME is not set, using the -mgmtAddress option (to specify management instance hosts), the -dataAddress option (to specify data instance hosts), and, as needed, the -repoAddress option (to specify repository hosts). Run ttGridAdmin from the TimesTen installation bin directory in this case. Passwordless SSH will be configured between hosts only as needed for TimesTen Scaleout to function.

  • Run ttGridAdmin from inside a TimesTen instance, where TIMESTEN_HOME is set. None of the options is necessary in this case. TimesTen determines from the grid model what each host is used for (management, data, or repository) and configures passwordless SSH between hosts only as needed for TimesTen Scaleout to function.

  • Run ttGridAdmin from outside a TimesTen instance, where TIMESTEN_HOME is not set, using the -internalAddress option to specify all-to-all passwordless SSH between all specified hosts, regardless of how the hosts are used (management, data, or repository). Run ttGridAdmin from the TimesTen installation bin directory in this case, but this mode of operation is NOT recommended, for security reasons.

After the gridSshConfig command is executed by a user, that user should be able to connect between hosts through SSH as needed without specifying a password (for example, between management hosts or from management hosts to data hosts). The ttGridAdmin utility will confirm this in its output after execution of the command.

Note:

You may choose to manually configure passwordless SSH between the hosts of your grid, as needed, without using gridSshConfig.

Options

The gridSshConfig command has the options:

Option Description
-mgmtAddress addr1 [addr2 ] Addresses of hosts with management instances to configure for passwordless SSH access, as necessary.
-dataAddress addr1 [addr2 [addr3...]] Addresses of hosts with data instances to configure for passwordless SSH access, as necessary.
-repoAddress addr1 [addr2 [addr3...]] Addresses of hosts with repositories to configure for passwordless SSH access, as necessary.
-internalAddress addr1 [addr2 [addr3...]] Addresses of hosts to configure for all-to-all passwordless SSH access.

Use of this option is NOT recommended, for security reasons.

You cannot use this option with any other option.


Examples

This example is run on mysys1.example.com, outside of any TimesTen instance, from the installation bin directory. It is run for four hosts (two management and two data).

% ./ttGridAdmin gridSshConfig -mgmtAddress mysys1.example.com mysys2.example.com -dataAddress 
mysys3.example.com mysys4.example.com
Enter password:
Setup ssh configuration on local system.................................................OK
Setup ssh configuration on mysys1.example.com...........................................OK
Setup ssh configuration on mysys2.example.com...........................................OK
Setup ssh configuration on mysys3.example.com...........................................OK
Setup ssh configuration on mysys4.example.com...........................................OK
Setup passwordless ssh from local system to mysys1.example.com..........................OK
Setup passwordless ssh from local system to mysys2.example.com..........................OK
Setup passwordless ssh from local system to mysys3.example.com..........................OK
Setup passwordless ssh from local system to mysys4.example.com..........................OK
Setup passwordless ssh from mysys1.example.com to mysys1.example.com....................OK
Setup passwordless ssh from mysys1.example.com to mysys2.example.com....................OK
Setup passwordless ssh from mysys1.example.com to mysys3.example.com....................OK
Setup passwordless ssh from mysys1.example.com to mysys4.example.com....................OK
Setup passwordless ssh from mysys2.example.com to mysys1.example.com....................OK
Setup passwordless ssh from mysys2.example.com to mysys2.example.com....................OK
Setup passwordless ssh from mysys2.example.com to mysys3.example.com....................OK
Setup passwordless ssh from mysys2.example.com to mysys4.example.com....................OK

Passwordless ssh working between hosts:

From\To            mysys1.example.com mysys2.example.com mysys3.example.com mysys4.example.com
---------          ------------------ ------------------ ------------------ ------------------
*us*               Yes                Yes                Yes                Yes
mysys1.example.com Yes                Yes                Yes                Yes
mysys2.example.com Yes                Yes                Yes                Yes
mysys3.example.com N/A                N/A                N/A                N/A
mysys4.example.com N/A                N/A                N/A                N/A

Notes

  • In specifying host addresses, for each host use the same format—fully qualified domain name, simple host name, or IP address—that is used in the -internalAddress or -address option of the hostCreate (or gridCreate) command. For example, do not specify mysys1 for gridSshConfig then mysys1.example.com for hostCreate.

  • You can run gridSshConfig multiple times without harm. If you want to enable passwordless SSH on additional hosts later, you can run the command again for those hosts without impacting the hosts already configured.

  • In the event of any failure during execution, the command will continue to complete the configuration on as many hosts as it can.

  • "Permission denied" errors in the error logs may indicate the password you provided was incorrect or that there is another permissions issue that prevents the command from completing successfully (for example, inappropriate permissions for the user home directory, where the .ssh directory is placed).

Host operations

Use ttGridAdmin commands in this section to define a host in the model, modify a host, delete a host, execute commands on all hosts, or list all hosts.

Create a host (hostCreate)

The hostCreate command defines a host in the model.

ttGridAdmin hostCreate [name]
                       [-address addr]
                       [-internalAddress addr]
                       [-externalAddress addr]
                       [-dataspacegroup n]
                       [-nodataspacegroup]
                       [-physicalgroup group1 [group2 [group3 [...]]]]
                       [-nophysicalgroup]
                       [-like name [-cascade]]
                       [-comment comment]

Options

The hostCreate command has the options:

Option Description
name Specifies the name for the host object in the model. The default is the first component of the operating system host name (the host name up to but not including the first ".", such as myhost).

If this option is omitted, the host system must be accessible through passwordless SSH at the time hostCreate is executed.

-internalAddress addr DNS name or IP address of the host for internal communications, inside the grid. Use this together with -externalAddress. The host must be accessible by passwordless SSH at the specified address.

This option takes one name or address only, and a specified name must resolve to one IP address or to multiple IP addresses on the same network segment.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Also see Notes below and "Address formats".

-externalAddress addr DNS name or IP address of the host for external communications, outside the grid, for client/server connections. Use this together with -internalAddress. The host must be accessible by passwordless SSH at the specified address.

This option takes one name or address only, but a name may resolve to one or more IP addresses.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Also see Notes below and "Address formats".

-address addr DNS name or IP address of the host for both external and internal communications, if a single address is used. The host must be accessible by passwordless SSH at the specified address.

This option takes one name or address only, and a specified name must resolve to one IP address or to multiple IP addresses on the same network segment.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Note: Using a single address is not recommended for production environments.

Also see Notes below and "Address formats".

-dataspacegroup n Specifies that this host will belong to data space group number n. The number of data space groups a grid has is determined by the k value set for the grid.

A host with a data instance must belong to a data space group.

Also see -nodataspacegroup and Notes below.

Note: Once a host is assigned to a data space group and modelApply is executed, you cannot change the assignment.

-nodataspacegroup Specifies that the host will not be assigned to a data space group. This is the default.

A host with a data instance must belong to a data space group.

Also see -dataspacegroup and Notes below.

-physicalgroup group1 [group2 [ group3 [...]]] Specifies the set of physical groups that this host will be associated with.

It is advisable to spread data instances between different physical groups so that there is redundancy in case of failure. See "Assigning hosts to data space groups" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Also see -nophysicalgroup.

Note: Physical group assignments are considered by the dataSpaceGroupSuggest command. See Notes below.

-nophysicalgroup Specifies that the host will be associated with no physical groups. This is the default.

Also see -physicalgroup.

-like name Specifies that this new host should be created with the same attributes as the named existing host, except where other options that you specify override settings from the existing host.

Also see -cascade.

-cascade Use this option with the -like option to specify that installations and instances associated with the -like host also be defined for the host being created. (These objects will be defined for the new host, but not actually created until you run modelApply.)
-comment comment Associates a comment with the host object. Put the comment in quotes if there are any spaces. The comment is stored and included in output of the hostList command.

Examples

Create a second management instance by adding a new host to the model with a set of installations and instances identical to those on the existing host (specified in the -like option). This command is run from the first management instance, which is on the first host, mysys1host (defined earlier, in the example for "Create a grid (gridCreate)"):

% ttGridAdmin hostCreate mysys2host -internalAddress intmysys2.example.com 
-externalAddress extmysys2.example.com -like mysys1host -cascade 
Host mysys2host created in Model
Installation installation1 created in Model
Instance gridmgmt1 created in Model

This defines gridmgmt1 on mysys2host, duplicating gridmgmt1 on mysys1host.

Create a host for a data instance, specifying the data space group:

% ttGridAdmin hostCreate mysyshost3 -internalAddress intmysys3.example.com 
-externalAddress extmysys3.example.com -dataSpaceGroup 1
Host mysyshost3 created in Model

Notes

  • In specifying host addresses, for each host use the same format—fully qualified domain name, simple host name, or IP address—as was used in the gridSshConfig command for that host. For example, do not specify mysys1 for hostCreate if mysys1.example.com was specified for gridSshConfig.

  • You can use hostModify to change some settings later.

  • If you do not assign the host to a data space group during host creation, you can later use the dataSpaceGroupSuggest command to determine optimal assignments based on which physical groups are associated with each host, or you can use the hostModify command to choose a data space group manually.

  • Hosts on the grid may be configured with either one or two network addresses, depending on system topology. If configured with two addresses, one is used for communications with systems inside the grid (internal) and one is used for client/server access to databases inside the grid from systems outside the grid (external). If configured with one address, which is not recommended for production environments, it is used for both internal and external communications. You must either set -address or set -internalAddress and -externalAddress.

Delete a host (hostDelete)

The hostDelete command removes a host from the model.

ttGridAdmin hostDelete name 
                       [-cascade]

Options

The hostDelete command has the options:

Option Description
name Name of the host object to remove from the model.
-cascade Specifies that installation and instance objects associated with the host should also be removed from the model.

Examples

This deletes a host that was created in an example in "Create a host (hostCreate)".

% ttGridAdmin hostDelete mysys2host -cascade
Instance gridmgmt1 on Host mysys2host deleted from Model
Installation installation1 on Host mysys2host deleted from Model
Host mysys2host deleted from Model

Notes

  • If the host has any installations or instances, you must either use -cascade or use installationDelete and instanceDelete.

  • Deleting instances and installations removes the objects from the model but does not remove the physical instances and installations.

Execute a command or script on grid hosts (hostExec)

The hostExec command executes a command (such as a system command or TimesTen command) or a script on hosts in the grid, as specified.

ttGridAdmin hostExec [-only hostname]
                     [-exclude hostname]
                     [-parallel n]
                      command | -script filepath

Options

The hostExec command has the options:

Option Description
-only hostname The command or script is executed only on the specified hosts. Specify just one host with -only, but you can use -only multiple times on the command line.

Use host names as defined in the model.

Without -only or -exclude, the command or script is executed on all hosts in the model.

-exclude hostname The command or script is executed on all hosts in the grid except for the specified hosts. Specify just one host with -exclude, but you can use -exclude multiple times on the command line.

Use host names as defined in the model.

Without -only or -exclude, the command or script is executed on all hosts in the model.

-parallel n Specifies that the command or script executes on no more than n hosts simultaneously. The default is 10. A value of 1 results in serial execution.
command | -script filepath command specifies a command to run.

Or:

-script filepath specifies the path and name of a shell script to run. The script must be on the local system, then is copied to each host.


Examples

This example first shows the existing hosts in the grid, then uses hostExec to run the df / command (to show disk space) on each host, excluding mysys3host and mysys4host. So the command is executed on mysys1host and mysys2host.

% ttGridAdmin hostList
Name        IntAddress             ExtAddress             DSG Comment
----------- ---------------------- ---------------------- --- -------
mysys1host  intmysys1.example.com  extmysys1.example.com    1
mysys2host  intmysys2.example.com  extmysys2.example.com    2
mysys3host  intmysys3.example.com  extmysys3.example.com    1
mysys4host  intmysys4.example.com  extmysys4.example.com    2

% ttGridAdmin hostExec -exclude mysys3host -exclude mysys4host df /
Commands executed on:
  mysys1host rc 0
  mysys2host rc 0
Return code from mysys1host: 0
Output from mysys1host:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda2           173483816  28416336 136254988  18% /
Return code from mysys2host: 0
Output from mysys2host:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda2           117144964  35319512  75874836  32% /

Notes

  • The command or script is executed on each host as the instance administrator, through passwordless SSH.

  • No environment variables are set on the hosts, other than those set by SSH by default.

  • The command returns 2000 if execution did not complete prior to the timeout.

  • During execution, stdout and stderr output is displayed as part of the stdout and stderr output from the hostExec command. Because output is buffered, the output from different commands is not intermingled.

List all hosts in the model (hostList)

The hostList command lists information about hosts in the specified version of the model.

ttGridAdmin hostList [-latest|-current|-version n]

Options

The hostList command has the options:

Option Description
-latest Lists hosts in the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Lists hosts in the current model—the model most recently applied to the grid.
-version n Lists hosts in the specified version number of the model.

Examples

The following two examples, relating to examples shown in "Modify a host (hostModify)" and "List model versions (modelList)", show identical output, indicating that version 4 is the latest version (the version not yet applied to the model).

For each host, the host name, internal address, external address, and associated data space group are listed (optionally with a comment).

% ttGridAdmin hostlist
Name        IntAddress             ExtAddress             DSG Comment
----------- ---------------------- ------------------     --- --------------------
mysys1host  intmysys1.example.com  extmysys1.example.com    1
mysys2host  intmysys2.example.com  extmysys2.example.com    1
mysys3host  intmysys3.example.com  extmysys3.example.com    1 Move from location1.
mysys4host  intmysys4.example.com  extmysys4.example.com    2

% ttGridAdmin hostlist -version 4
Name        IntAddress             ExtAddress             DSG Comment
----------- ---------------------- ------------------     --- --------------------
mysys1host  intmysys1.example.com  extmysys1.example.com    1
mysys2host  intmysys2.example.com  extmysys2.example.com    1
mysys3host  intmysys3.example.com  extmysys3.example.com    1 Move from location1.
mysys4host  intmysys4.example.com  extmysys4.example.com    2

Modify a host (hostModify)

The ttGridAdmin hostModify command modifies a host object in the model.

ttGridAdmin hostModify name
                       [-physicalgroup group1 [group2 [group3 [...]]]]
                       [-addphysicalgroup group1 [group2 [group3 [...]]]]
                       [-removephysicalgroup group1 [group2 [group3 [...]]]]
                       [-nophysicalgroup]
                       [-dataspacegroup n]
                       [-nodataspacegroup] 
                       [-comment comment]

Options

The hostModify command has the options:

Option Description
name Name of the existing host object to modify.
-physicalgroup group1 [group2 [group3 [...]]] Specifies a new set of physical groups that this host will be associated with. All physical groups previously associated with the host will be replaced with the specified groups.

Also see -addphysicalgroup, -removephysicalgroup, and -nophysicalgroup.

-addphysicalgroup group1 [group2 [group3 [...]]] Adds the specified physical groups to the groups the host is associated with.

Also see -physicalgroup, -removephysicalgroup, and -nophysicalgroup.

-removephysicalgroup group1 [group2 [group3 [...]]] Removes the specified physical groups from the groups the host is associated with.

Also see -physicalgroup, -addphysicalgroup, and -nophysicalgroup.

-nophysicalgroup Specifies that the host will not be associated with any physical groups, removing any prior associations.

Also see -physicalgroup, -addphysicalgroup, and -removephysicalgroup.

-dataspacegroup n Specifies the number of the data space group that this host will belong to. The number of data space groups a grid will have is determined by the k value set for the grid.

A host with a data instance should always belong to a data space group.

-nodataspacegroup Specifies that this host will not be part of any data space group (the default)
-comment comment Associates a comment with the host object or modifies an existing comment. Put the comment in quotes if there are any spaces. The comment is stored and included in output of the hostList command.

Examples

% ttGridAdmin hostModify mysyshost2 -physicalGroup location3 
-comment "Move from location1."
Host mysyshost2 modified in Model

Notes

  • The host system must be accessible through passwordless SSH at the time hostModify is executed.

  • If modelApply has already been executed for a model including this host, you cannot change the data space group assignment.

Import and export operations

Use ttGridAdmin commands in this section to import and export databases, display the status of those operations, or delete an export.

Also see "Migrating, Backing Up and Restoring Data" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Export a database (dbExport)

The dbExport command exports data from the specified database into a specified repository. The dbExport and dbImport commands are used, for example, to migrate a database between two grids or between versions of TimesTen that are not patch-compatible. See "Migrating, Backing Up and Restoring Data" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.

ttGridAdmin dbExport dbname 
                     -repository reponame 
                     [-name exportname]

An export is stored as a collection under a repository. You first must create the repository. See "Repository operations".

Options

The dbExport command has the options:

Option Description
dbname Name of the database to export.
-repository reponame Name of the repository where the export will be stored.
-name exportname Specifies a name for the export. The default is the letter "M" followed by the date and time of the backup, in the format:
Myyyymmddhhmmss

Examples

% ttGridAdmin dbExport database1 -repository repo1 -name exp_db1
...
dbExport exp_db1 started

You can then use dbExportStatus to check progress, as shown in the example in "Display the status of a database export (dbExportStatus)". The export is finished when each element and the database as a whole are indicated as complete.

Notes

  • The export is performed asynchronously. Use the dbExportStatus command to check progress.

  • Each replica set of the database is stored as a sub-collection.

  • The database must be in a closed state with all connections closed when you run dbExport.

  • Only one dbExport command can be run for a database at any given time, and dbExport cannot run concurrently with dbImport.

  • For disk space requirements, see "Exporting and importing a TimesTen Scaleout database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Delete a database export (dbExportDelete)

The dbExportDelete command deletes the specified database export.

ttGridAdmin dbExportDelete -repository reponame
                           -name exportname

Options

The dbExportDelete command has the options:

Option Description
-repository reponame Name of the repository where the export is stored.
-name exportname Name of the export to delete.

Examples

This example deletes the export created in "Export a database (dbExport)".

% ttGridAdmin dbExportDelete -repository repo1 -name exp_db1
Export exp_db1 deleted

Notes

This command is typically used to delete old or failed exports.

Display the status of a database export (dbExportStatus)

The dbExportStatus command shows the status of a database export or exports previously started.

ttGridAdmin dbExportStatus dbname 
                           [-name exportname]

Options

The dbExportStatus command has the options:

Option Description
dbname Name of the database being exported.
-name exportname Name of the export to check. The default is all exports of the specified database.

Examples

This example shows status upon completion of the export from the example in "Export a database (dbExport)". (That is the only export for database1 in the repository.)

% ttGridAdmin dbExportStatus database1
Database  Export  Repository Host  Instance  Elem State     Started
--------- ------- ---------- ----- --------- ---- --------- ------------------------
database1 exp_db1 repo1                           Completed 2017-03-02T14:42:24.000Z
                             host3 instance1    1 Complete
                             host4 instance1    2 Complete
                             host5 instance1    3 Complete

Notes

When you believe the export is complete, confirm that dbExportStatus shows Complete for the export as a whole and for every instance. If there were any failures, see "Check the status of a database export" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Import a database (dbImport)

The dbImport command imports data from a specified previous export into the specified database. The dbExport and dbImport commands are used, for example, to migrate a database between two grids or between versions of TimesTen that are not patch-compatible.

ttGridAdmin dbImport dbname 
                     -repository reponame 
                     -name exportname 
                     [-ckptFreq mb]
                     [-updateStats]
                     [-estimateStats pct]

Options

The dbImport command has the options:

Option Description
dbname Name of the database where the data is to be imported.
-repository reponame Name of the repository where the export is located.
-name exportname Name of the export to use for the import.
-ckptFreq mb Checkpoint frequency, in terms of how many megabytes have been imported. A checkpoint is written each time that many megabytes have been imported. The default is to write no checkpoints during the import.
-updateStats Update statistics on each table as it is imported.

Also see Notes below.

-estimateStats pct Estimate statistics on each table as it is imported, by reading the specified percentage of rows of each table.

Also see Notes below.


Examples

This example imports the export created in the example in "Export a database (dbExport)", into a database imp_db1.

% ttGridAdmin dbImport imp_db1 -repository repo1 -name exp_db1
dbImport exp_db1 started

You can then use dbImportStatus to check progress, as shown in the example in "Display the status of a database import (dbImportStatus)". The import is finished when each element and the database as a whole are indicated as complete.

Notes

  • The database must already be created and loaded and must have a distribution map, but must be closed, with all connections closed, when you run dbImport.

  • If you specify both -estimateStats and -updateStats, statistics on imported tables are updated, not estimated.

  • The import is performed asynchronously. Use the dbImportStatus command to check progress.

  • Only one dbImport command can run for a database at any given time, and dbImport cannot run concurrently with dbExport.

  • Functionality of the -ckptFreq, -updateStats, and -estimateStats options is the same as for equivalent options of the ttMigrate utility. See "ttMigrate".

  • For disk space requirements, see "Exporting and importing a TimesTen Scaleout database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Display the status of a database import (dbImportStatus)

The dbImportStatus command shows the status of a database import previously started.

ttGridAdmin dbImportStatus dbname
                           [-name exportname]

Options

The dbImportStatus command has the options:

Option Description
dbname Name of the database where the import is being checked.
-name exportname Name of the export from which the data is being imported. You can use this option in the atypical scenario where there are multiple imports into the same database (otherwise, the status of all the imports would be shown).

Examples

This example shows status upon completion of the import from the example in "Import a database (dbImport)".

% ttGridAdmin dbImportStatus imp_db1 -name exp_db1
Database Import  Repository Host  Instance  Elem State                  Started
-------- ------- ---------- ----- --------- ---- ---------------------- ------------------------
imp_db1  exp_db1 repo1                           Import_Finale_Complete 2016-07-25T17:53:27.000Z
                            host1 instance1    1 Import_Rows_Complete
                            host3 instance1    3 Import_Rows_Complete

Notes

When you believe the import is complete, confirm that dbImportStatus shows Complete for the import as a whole and for every instance. If there were any failures, see "Check the status of a database import" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Installation operations

Use ttGridAdmin commands in this section to define a TimesTen installation in the model, list all installations in the grid, show status of all installations, delete an installation, or execute a command on all installations.

Create an installation (installationCreate)

The installationCreate command defines a TimesTen installation in the model.

ttGridAdmin installationCreate hostname[.installname]
                               -location path
                               [-source where]
                               [-comment comment]

Options

The installationCreate command has the options:

Option Description
hostname[.installname] The hostname is the name of the host where the installation is to be created, optionally with a specified installname for the name of the installation in the model. The default is installation1.
-location path Path, on the specified host, to the directory where the installation is to be created. The specified directory does not have to exist, but if it exists it must be empty.
-source where Location that the installation will be copied from. The location does not have to be on a system that is part of the grid. You can specify it in any of the following formats, as applicable:
/path
address:/path
address!/path
[address]:/path

If path is a directory, it must be the top-level tt18.1.3.1.0 directory of an existing TimesTen installation. If it is a file, it must be a .zip file that expands into a TimesTen installation. The address is a DNS name or IP address.

If address is specified, passwordless SSH is used to fetch the installation source from the system with that address. You must use the fourth format if there is a colon in the address itself, such as for IPv6 addresses.

The default is the location of the installation associated with the active management instance, from which ttGridAdmin is executed.

Also see "Address formats".

-comment comment Associates a comment with the installation object. Put the comment in quotes if there are any spaces. The comment is stored and included in output of the installationList command.

Examples

Create an installation for host mysys4host, using the default source location. (This example was run from mysys1.)

% ttGridAdmin installationCreate mysys4host.installcreate 
-location /sw/tten/grid/ttinstls/installcreate
Installation installcreate on Host mysys4host created in Model

This time, specify a source location:

% ttGridAdmin installationCreate mysys4host.installcreate2
-location /sw/tten/grid/ttinstls/installcreate2 -source 
mysys1:/sw/tten/grid/ttinstls/myinstl/tt18.1.3.1.0
Installation installcreate2 on Host mysys4host created in Model

Notes

  • This command does not create a physical installation. It defines an installation object in the model. (The modelApply command creates the installation.)

  • Multiple installation objects for the same TimesTen release can point to the same physical installation; however, you cannot specify the same location on the same host for installations from different releases.

Delete an installation (installationDelete)

The installationDelete command deletes an installation from the model. It deletes the specified installation (or the only installation, as applicable) on the specified host.

ttGridAdmin installationDelete hostname[.installname]

Options

The installationDelete command has the option:

Option Description
hostname[.installname] The hostname is the name of the host where the installation is to be deleted. The installname is the name of the installation to be deleted and is required only if there is more than one installation on the host.

Examples

In this example, installcreate2 is the only installation on the host.

% ttGridAdmin installationDelete mysys4host
Installation installcreate2 on Host mysys4host deleted from Model

Notes

  • You cannot remove an installation that is still used by instances on the specified host.

  • This command removes the installation object from the model but does not remove the physical installation. Remove the files manually when you are certain they are no longer used.

Execute a command or script on grid installations (installationExec)

The installationExec command executes a command (such as a system command or TimesTen command) or a script on installations in the grid, as specified.

ttGridAdmin installationExec [-only hostname[.installname]]
                             [-exclude hostname[.installname]]
                             [-parallel n]
                             command | -script filepath

As the command or script executes, the TIMESTEN_INSTALL environment variable is set to contain the fully qualified path name of the installation as defined in the model.

Options

The installationExec command has the options:

Option Description
-only hostname[.installname] The command or script is executed only on the specified installations. Specify just one installation with -only, but you can use -only multiple times on the command line.

Use host names and installation names as defined in the model. You do not have to include the installation name if it is the only installation on the host.

-exclude hostname[.installname] The command or script is executed on all installations in the grid except for those specified. Specify just one installation with -exclude, but you can use -exclude multiple times on the command line.

Use host names and installation names as defined in the model. You do not have to include the installation name if it is the only installation on the host.

-parallel n Specifies that the command or script executes on no more than n installations simultaneously. The default is 10. A value of 1 results in serial execution.
command | -script filepath command specifies a command to run.

Or:

-script filepath specifies the path and name of a shell script to run. The script must be on the local system, then is copied to each installation.


Examples

This example checks the disk space usage on the file system of each installation.

% ttGridAdmin installationExec df '$TIMESTEN_INSTALL'
Commands executed on:
  mysys2host.installation1 rc 0
  mysys4host.installadc rc 0
  mysys1host.installation1 rc 0
  mysys3host.installslc rc 0
Return code from mysys2host.installation1: 0
Output from mysys2host.installation1:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda2           117144964  42660228  68534120  39% /
Return code from mysys4host.installadc: 0
Output from mysys4host.installadc:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda2           117144964  42660228  68534120  39% /
Return code from mysys1host1.installation1: 0
Output from mysys1host.installation1:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda2           173483816  57971304 106700020  36% /
Return code from mysys3host.installslc: 0
Output from mysys3host.installslc:
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda2           173483816  57971312 106700012  36% /

Notes

  • The command or script is executed as the instance administrator on each installation, through passwordless SSH.

  • The command returns 2000 if execution did not complete prior to the timeout.

  • During execution, stdout and stderr output is displayed as part of the stdout and stderr output from the installationExec command. Because output is buffered, the output from different commands is not intermingled.

List installations (installationList)

The installationList command lists all TimesTen installations in the model.

ttGridAdmin installationList [-latest|-current|-version n]
                             [-instance]

Options

The installationList command has the options:

Option Description
-latest List the installations in the latest (in progress) model, which has not yet been applied to the grid. This is the default.
-current List the installations in the current model—the model currently applied to the grid.
-version n List the installations in the specified version number of the model.
-instance Show the instances that are using each installation. Installations not yet associated with an instance are not displayed.

Examples

This example lists the installations in the latest (in progress) model.

% ttGridAdmin installationList
Host        Install        Location                                      Comment
----------- -------------  -------------------------------------------   -------
mysys1host  installation1  /sw/tten/grid/ttinstls/myinstl/tt18.1.3.1.0/
mysys2host  installation1  /sw/tten/grid/ttinstls/myinstl/tt18.1.3.1.0/
mysys3host  installcreate1 /sw/tten/grid/ttinstls/installcreate1/
mysys4host  installcreate1 /sw/tten/grid/ttinstls/installcreate1/

This example lists installations in the latest model that are associated with an instance.

% ttGridAdmin installationList -instance
Host        Install       Instance  Location                                     Comment
----------- ------------- --------  -------------------------------------------- -------
mysys1host  installation1 gridmgmt1 /sw/tten/grid/ttinstls/myinstl/tt18.1.3.1.0/
mysys2host  installation1 gridmgmt1 /sw/tten/grid/ttinstls/myinstl/tt18.1.3.1.0/

Display status of installations (installationStatus)

The installationStatus command shows the status of all installations that are associated with the grid. This is status of the physical installations, not status of installations in the model.

ttGridAdmin installationStatus

Examples

% ttGridAdmin installationStatus
Host        Install           Usable DelPend Message When
----------- ----------------- ----   ------- ------- -------------------
mysys1host  installation1     Yes    N               2016-11-01 14:49:31
mysys2host  installation1     Yes    N               2016-11-01 14:49:31
mysys3host  installcreate2slc Yes    N               2016-11-01 14:49:31
mysys4host  installcreate2adc Yes    N               2016-11-01 14:49:31

The DelPend entry indicates whether a deletion is pending, where installationDelete was executed but the updated model has not yet been applied to remove the physical installation.

Instance operations

Use ttGridAdmin commands in this section to define a TimesTen Scaleout instance in the model, modify an instance, delete an instance, list instances in the grid, display status of instances in the grid, import or export an instance configuration file, or execute a command on instances in the grid.

Export instance configuration attributes (instanceConfigExport)

The instanceConfigExport command exports configuration attribute settings, previously imported using instanceConfigImport, from the specified version of the model.

ttGridAdmin instanceConfigExport [-latest|-current|-version n]
                                 [filepath]

Options

The instanceConfigExport command has the options:

Option Description
-latest Export configuration attribute settings that were imported into the latest model, which has not yet been applied to the grid. This is the default.
-current Export configuration attribute settings that were imported into the current model—the model currently applied to the grid.
-version n Export configuration attribute settings that were imported into the specified version of the model.
filepath The path and name of the file to export configuration attribute settings into. If no file is specified, the information is written to stdout.

Examples

This example exports a configuration attribute setting from the current version of the model and from the latest (default) version of the model after the imports shown in the next section, "Import instance configuration attributes (instanceConfigImport)". Contents of the export files are also shown.

% ttGridAdmin instanceConfigExport -current /tmp/instanceconfigexp1
% more /tmp/instanceconfigexp1
max_conns_per_server=500
% ttGridAdmin instanceConfigExport /tmp/instanceconfigexp2
% more /tmp/instanceconfigexp2
max_conns_per_server=1000

Notes

This command exports only settings that were previously imported, not any other settings from the timesten.conf files.

Import instance configuration attributes (instanceConfigImport)

The instanceConfigImport command imports configuration attribute settings into the latest version of the model, to be used by every instance in the grid.

ttGridAdmin instanceConfigImport [filepath]

After you execute modelApply, the configuration file for each instance is updated to include the imported attributes. You must restart the TimesTen daemon on each instance for the changes to take effect.

See Notes below for a list of attributes you cannot import.

Options

The instanceConfigImport command has the option:

Option Description
filepath The path and name of the file to import configuration attribute settings from. If no file is specified, the information is read from stdin.

Examples

Import from this file.

% more /tmp/instanceconfigimp1
# Set maximum number of connections.
max_conns_per_server=500
% ttGridAdmin instanceConfigImport /tmp/instanceconfigimp1
Instance configuration file /tmp/instanceconfigimp1 imported

Apply the model (output is not shown):

% ttGridAdmin modelApply
...
ttGridAdmin modelApply complete

Now import from this file:

% more /tmp/instanceconfigimp2
# Set maximum number of connections.
max_conns_per_server=1000
% ttGridAdmin instanceConfigImport /tmp/instanceconfigimp2
Instance configuration file /tmp/instanceconfigimp2 imported

After these steps, the latest version of the model will have a maximum connections setting of 500 and the current version of the model will have a setting of 1000. This is shown in the examples in the previous section, "Export instance configuration attributes (instanceConfigExport)".

Notes

  • As shown in the example, each entry that is imported is of the form name=value. You can also include comments, indicated by #.

  • The timesten.conf files are updated when you execute modelApply.

  • The following attributes are set automatically when the modelApply command creates or configures instances and cannot be imported:

    admin_uid
    admin_user
    client_only
    daemon_port
    grid_external_addr
    grid_guid
    grid_host
    grid_instance
    grid_internal_addr
    grid_name
    guid
    hostname
    instance_guid
    instance_name
    listen_addr
    server_port
    timesten_release
    tns_admin
    
  • Refer to Chapter 1, "TimesTen Instance Configuration File" for information about TimesTen configuration attributes.

Create an instance (instanceCreate)

The instanceCreate command defines an instance in the model.

ttGridAdmin instanceCreate  hostname[.instancename]
                            -location path
                            [-type management|data]
                            [-installation name]
                            [-daemonport n]
                            [-csport n]  
                            [-mgmtport n] 
                            [-comment comment]
                            [-walletDir path]

Options

The instanceCreate command has the options:

Option Description
hostname[.instancename] The hostname is the name of the host where the instance is to be created, optionally with a specified instancename for the name of the instance in the model. The default is instance1.
-location path Path, on the specified host, to the directory where the instance is to be created. The specified directory does not have to exist.
-type management|data Specifies which type of instance is defined. The default is a data instance.
-installation name Name of the installation that the instance will use. This option is not necessary if there is only one installation on the host.
-daemonport n Port number where the TimesTen main daemon for the instance will listen. The default is 6624.

Important: If you create more than one instance on a system (such as a management instance and a data instance), you must specify unique port numbers.

-csport n Port number where the server for TimesTen client/server will listen. The default is 6625.

Important: If you create more than one instance on a system (such as a management instance and a data instance), you must specify unique port numbers.

-mgmtport n For management instances, the port number that will be used by replication when management data on the active management instance is replicated. The default is 3754.
-comment comment Associates a comment with the instance object. Put the comment in quotes if there are any spaces. The comment is stored and included in output of the instanceList command.
-walletDir path Path to the directory where the Oracle Wallet with cryptographic information for this instance will be stored. The default is timesten_home/info.

Wallets for multiple instances can be stored in the same directory, which can be shared between the instances, such as through NFS.


Examples

% ttGridAdmin instanceCreate mysys3host.griddata1
-location /sw/tten/grid/ttinstances -daemonPort 20000 -csPort 21000
Instance griddata1 on Host mysys3host created in Model

Notes

  • This command does not create a physical instance. It defines an instance object in the model. The modelApply command creates the physical instance.

  • Be aware of these prerequisites:

    • The host must have an associated installation object. Use the installationCreate command.

    • For a data instance, the host must be in a data space group. If that is not the case, the physical instance cannot be created when you apply the model.

      You can use the hostList command to confirm whether a host is in a data space group, and the hostModify command to assign a data space group if needed.

  • The timesten_home directory will be location/name. In the example, where the location is /sw/tten/ttinstances and the instance name is griddata1, timesten_home will be /sw/tten/ttinstances/griddata1.

  • Some instance settings can be changed later through the instanceModify command, as desired.

Delete an instance (instanceDelete)

The instanceDelete command deletes an instance from the model.

ttGridAdmin instanceDelete hostname[.instancename]

Options

The instanceDelete command has the option:

Option Description
hostname[.instancename] The hostname is the name of the host where the instance is to be deleted. The instancename is the name of the instance to be deleted and is required only if there is more than one instance on the host.

Examples

In this example, griddata1 is the only instance on the host.

% ttGridAdmin instanceDelete mysys3host
Instance griddata1 on Host mysys3host deleted from Model

Notes

  • This command first stops the instance if it has not already been stopped.

  • The command removes the instance object from the model. It does not remove the physical instance. (The modelApply command removes the instance.)

  • You cannot remove an instance that is still used by other objects in the model.

  • You cannot remove an instance that contains a database element.

Execute a command or script on grid instances (instanceExec)

The instanceExec command executes a command (such as a system command or TimesTen command) or a script on instances in the grid, as specified.

ttGridAdmin instanceExec [-only hostname[.instancename]]
                         [-exclude hostname[.instancename]]
                         [-parallel n]
                         [-type all|management|data]
                         [-up]
                          command | -script filepath

Options

The instanceExec command has the options:

Option Description
-only hostname[.instancename] The command or script is executed only on the specified instances. Specify just one instance with -only, but you can use -only multiple times on the command line.

Use host names and instance names as defined in the model. You do not have to include the instance name if it is the only instance on the host.

-exclude hostname[.instancename] The command or script is executed on all instances in the grid except for those specified. Specify just one instance with -exclude, but you can use -exclude multiple times on the command line.

Use host names and instance names as defined in the model. You do not have to include the instance name if it is the only instance on the host.

-parallel n Specifies that the command or script executes on no more than n instances simultaneously. The default is 10. A value of 1 results in serial execution.
-type all|management|data Specifies whether the command or script is executed on all instances (the default), only management instances, or only data instances.

This can be used in combination with -only or -exclude.

-up Specifies that the command or script is executed only on instances that are part of the current membership. The default is to execute commands on all instances (whether they are running or not).
command | -script filepath command specifies a command to run.

Or:

-script filepath specifies the path and name of a shell script to run. The script must be on the local system, then is copied to each instance.


Examples

On each data instance, this example creates directories databases and logs under /data (with no error if the directories already exist).

% ttGridAdmin instanceExec -type data mkdir -p /data/{databases,logs}
Overall return code: 0
Commands executed on:
  mysys6host.griddata4 rc 0
  mysys5host.griddata3 rc 0
  mysys3host.griddata1 rc 0
  mysys4host.griddata2 rc 0
Return code from mysys6host.griddata4: 0
Output from mysys6host.griddata4:
Return code from mysys5host.griddata3: 0
Output from mysys5host.griddata3:
Return code from mysys3host.griddata1: 0
Output from mysys3host.griddata1:
Return code from mysys4host.griddata2: 0
Output from mysys4host.griddata2:

This example starts the TimesTen daemon on mysys5host.griddata3 (useful, for example, if the element on that instance went down).

% ttGridAdmin instanceExec -only mysys5host.griddata3 ttDaemonAdmin -start
Overall return code: 0
Commands executed on:
  mysys5host.griddata3 rc 0
Return code from mysys5host.griddata3: 0
Output from mysys5host.griddata3:
TimesTen Daemon (PID: 7586, port: 6624) startup OK.

For each data instance, this example runs the ttIsql monitor command then exits ttIsql. (Only selected portions of the ttIsql connection output and monitoring output are shown.)

% ttGridAdmin instanceExec -type data 'ttIsql -e "monitor;quit" -dsn database1'
Overall return code: 0
Commands executed on:
  mysys4host.griddata2 rc 0
  mysys5host.griddata3 rc 0
  mysys6host.griddata4 rc 0
  mysys3host.griddata1 rc 0
Return code from mysys4host.griddata2: 0
Output from mysys4host.griddata2:
 
Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=database1";
Connection successful: DSN=database1;...
 
monitor;
 
  TIME_OF_1ST_CONNECT:         Fri Aug  3 13:47:42 2018
  ...
  PERM_ALLOCATED_SIZE:         262144
  PERM_IN_USE_SIZE:            29997
  PERM_IN_USE_HIGH_WATER:      29997
  TEMP_ALLOCATED_SIZE:         131072
  TEMP_IN_USE_SIZE:            19146
  TEMP_IN_USE_HIGH_WATER:      22352
  ...
 
quit;
Disconnecting...
Done.
Return code from mysys5host.griddata3: 0
Output from mysys5host.griddata3:
 
Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=database1";
Connection successful: DSN=database1;...
 
monitor;
 
  TIME_OF_1ST_CONNECT:         Fri Aug  3 13:47:41 2018
  ...
  PERM_ALLOCATED_SIZE:         262144
  PERM_IN_USE_SIZE:            29916
  PERM_IN_USE_HIGH_WATER:      29932
  TEMP_ALLOCATED_SIZE:         131072
  TEMP_IN_USE_SIZE:            19613
  TEMP_IN_USE_HIGH_WATER:      22819
  ...
 
quit;
Disconnecting...
Done.
Return code from mysys6host.griddata4: 0
Output from mysys6host.griddata4:
 
Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=database1";
Connection successful: DSN=database1;...
 
monitor;
 
  TIME_OF_1ST_CONNECT:         Fri Aug  3 13:47:41 2018
  ...
  PERM_ALLOCATED_SIZE:         262144
  PERM_IN_USE_SIZE:            29981
  PERM_IN_USE_HIGH_WATER:      29981
  TEMP_ALLOCATED_SIZE:         131072
  TEMP_IN_USE_SIZE:            19344
  TEMP_IN_USE_HIGH_WATER:      22550
  ...
 
quit;
Disconnecting...
Done.
Return code from mysys3host.griddata1: 0
Output from mysys3host.griddata1:
 
Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
connect "DSN=database1";
Connection successful: DSN=database1;...
 
monitor;
 
  TIME_OF_1ST_CONNECT:         Fri Aug  3 13:47:40 2018
  ...
  PERM_ALLOCATED_SIZE:         262144
  PERM_IN_USE_SIZE:            29965
  PERM_IN_USE_HIGH_WATER:      29965
  TEMP_ALLOCATED_SIZE:         131072
  TEMP_IN_USE_SIZE:            19281
  TEMP_IN_USE_HIGH_WATER:      22486
  ...
 
quit;
Disconnecting...
Done.

Notes

  • The command or script is executed as the instance administrator on each instance, through passwordless SSH.

  • Environment variables (such as TIMESTEN_HOME, CLASSPATH, PATH, and LD_LIBRARY_PATH) are set appropriately for each instance.

  • The command returns 2000 if execution did not complete prior to the timeout.

  • During execution, stdout and stderr output is displayed as part of the stdout and stderr output from the instanceExec command. Because output is buffered, the output from different commands is not intermingled.

List instances (instanceList)

The instanceList command lists information about instances in the specified version of the model.

ttGridAdmin instanceList [-latest|-current|-version n]
                         [-type all|management|data]
                         [-install]

Options

The instanceList command has the options:

Option Description
-latest Lists instances in the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Lists instances in the current model—the model most recently applied to the grid.
-version n Lists instances in the specified version number of the model.
-type all|management|data Specifies whether all instances (the default), only management instances, or only data instances are listed.
-install Shows the installation object associated with each instance.

Examples

This example is for a grid with two hosts on each of two systems. On each system, one host has a management instance and one has a data instance. By default, data instances as well as management instances are listed in the latest model (in the process of being modified and not yet applied).

% ttGridAdmin instanceList
Host        Instance  Type Instance Home                        Port  CSPort MgmtPort Comment
----------- --------- ---- -----------------------------------  ----- ------ -------- -------
mysys1host  gridmgmt1 Mgmt /sw/tten/grid/ttinstances/gridmgmt1/ 10000  11000    3754
mysys2host  gridmgmt1 Mgmt /sw/tten/grid/ttinstances/gridmgmt1/ 10000  11000    3754
mysys3host  griddata1 Data /sw/tten/grid/ttinstances/griddata1/ 20000  21000
mysys4host  griddata2 Data /sw/tten/grid/ttinstances/griddata2/ 20000  21000

This example also shows the associated installation objects (the Comment column is omitted):

% ttGridAdmin -instanceList -install
Host        Instance  Installation  Type  Instance Home                       Port  CSPort MgmtPort
----------- --------- ------------- ----  ----------------------------------- ----- ------ -------- 
mysys1host  gridmgmt1 installation1 Mgmt /sw/tten/grid/ttinstances/gridmgmt1/ 10000  11000    3754
mysys2host  gridmgmt1 installation1 Mgmt /sw/tten/grid/ttinstances/gridmgmt1/ 10000  11000    3754
mysys3host  griddata1 installation1 Data /sw/tten/grid/ttinstances/griddata1/ 20000  21000
mysys4host  griddata2 installation1 Data /sw/tten/grid/ttinstances/griddata2/ 20000  21000

Modify an instance (instanceModify)

The instanceModify command modifies an existing instance object in the model.

ttGridAdmin instanceModify hostname[.instancename]
                           [-installation name]
                           [-mgmtPort n]
                           [-comment comment]

Options

The instanceModify command has the options:

Option Description
hostname[.instancename.] The hostname is the name of the host where the instance is to be modified. The instancename is the name of the instance to be modified and is required only if there is more than one instance on the host.
-installation name Associates the instance with a different installation on the host, specified by the name of the installation in the model.
-mgmtPort n For management instances, a new port number that will be used for replication when management data on the active management instance is replicated. Changing this is allowed only if there ie exactly one management instance at the time the command is issued, but is relevant only if you plan to have two management instances.
-comment comment Associates a comment with the instance object or modifies an existing comment. Put the comment in quotes if there are any spaces. The comment is stored and included in output of the instanceList command.

Examples

In this example, griddata1 is the only instance on the host.

% ttGridAdmin instanceModify mysys3host -installation altinstall -comment 
Change_from_installcreate1
Instance griddata1 on Host mysys3host modified in Model

(Note that if you have a multi-word comment, you can use underscores instead of spaces to avoid having to put the comment in quotes.)

Notes

  • This command is most typically used to patch or upgrade your version of TimesTen by pointing to an installation of the desired release.

  • When instanceModify updates are applied by a subsequent modelApply command, the instance is not stopped and reconfigured at that time. Instead, the next time the instance is started, TimesTen Scaleout will detect that the instance configuration does not match the model, and will reconfigure it appropriately.

Display status of instances (instanceStatus)

The instanceStatus command displays information about the status of instances in the grid, in JSON format.

ttGridAdmin instanceStatus [-type all|management|data]

Options

The instanceStatus command has the option:

Option Description
-type all|management|data Specifies whether all instances (the default), only management instances, or only data instances are displayed.

Management instance operations

Use ttGridAdmin commands in this section to start, stop, switch, examine, or check status of the management instance or instances. Execute the commands from the appropriate management instance.

Note:

Typically, there are two management instances, the active and standby. Before you can perform any grid management functions, a management instance must be started as the active instance, from which you can run ttGridAdmin. (Initially, the instance from which you create the grid becomes the active management instance.)

See "Configure your grid" in Oracle TimesTen In-Memory Database Scaleout User's Guide for details.

See "Managing failover for the management instances" in Oracle TimesTen In-Memory Database Scaleout User's Guide for related information.

Start the active management instance (mgmtActiveStart)

The mgmtActiveStart command starts the current management instance (from which the command is run) as the active management instance.

ttGridAdmin mgmtActiveStart

Examples

% ttGridAdmin mgmtActiveStart
This management instance is now the active

Notes

  • The current management instance must previously be stopped.

  • There cannot be another management instance that has been started as the active instance.

Stop the active management instance (mgmtActiveStop)

The mgmtActiveStop command stops the active management instance.

ttGridAdmin mgmtActiveStop

This command is typically used as the last step in shutting down a grid. Otherwise, if there are two management instances, it is recommended to instead use mgmtActiveSwitch.

Examples

% ttGridAdmin mgmtActiveStop
Active management instance stopped 

Notes

  • If this command is used in a grid with two management instances (not recommended unless you are shutting down the grid), it can be run from either the active or the standby management instance. Nothing is done automatically to then promote the standby management instance to active. (See mgmtActiveSwitch.)

  • If data instances are running, then the database elements currently loaded in them will continue to operate.

  • You cannot perform any management operations until you restart the active management instance.

  • If data instances have stopped or failed, they cannot be restarted until you restart the active management instance.

Switch the active management instance (mgmtActiveSwitch)

The mgmtActiveSwitch command, executed from the current standby management instance, results in that instance becoming the active management instance. The original active management instance is stopped if it can be reached.

ttGridAdmin mgmtActiveSwitch [-force]

Options

The mgmtActiveSwitch command has the option:

Option Description
-force Specifies that the command will take effect even if the management instance from which it is run cannot be clearly identified as the standby management instance or is not ideally eligible to become the active management instance.

Important: Using -force will likely result in substantial data loss. Use only as a last resort.


Examples

% ttGridAdmin mgmtActiveSwitch
This is now the active management instance

Notes

  • This command is typically used if the active management instance has failed.

  • If or when the original active management instance is back up, you can use mgmtStandbyStart to restart it as the standby.

  • All data instances in the grid will automatically failover from the previous active management instance to the new active management instance.

Examine management instances (mgmtExamine)

The mgmtExamine command examines the management instances and recommends any necessary corrective action. Run the suggested commands.

ttGridAdmin mgmtExamine

Examples

This example shows output when both management instances are up. Aside from the opening note that they are both up, the output is the same as for the mgmtStatus command. See "Display status of management instances (mgmtStatus)" for descriptions of the columns. (For brevity, the Message column, which had no entries, is not shown in this example.)

% ttGridAdmin mgmtExamine
Both active and standby management instances are up. No action required.
 
Host        Instance  Reachable RepRole(Self) Role(Self) Seq RepAgent RepActive
----------- --------- --------- ------------- ---------- --- -------- ---------
mysys1host  gridmgmt1 Yes       Active        Active     554 Up       Yes
mysys2host  gridmgmt1 Yes       Standby       Standby    554 Up       No

This example shows output when the active management instance is down, including recommended actions and commands to run:

% ttGridAdmin mgmtExamine
Standby management instance is up, but active is down
Promote the standby to active

Host        Instance  Reachable RepRole(Self) Role(Self) Seq RepAgent RepActive Message
----------- --------- --------- ------------- ---------- --- -------- --------- -------------------
----------------
mysys1host  gridmgmt1 No        Unknown       Unknown        Down     No        Management database 
is not available
mysys2host  gridmgmt1 Yes       Standby       Standby    557 Up       No            
Recommended commands:
ssh -o StrictHostKeyChecking=yes -o PasswordAuthentication=no -x host1.example.com 
/sw/tten/gridsetup/ttinstances/gridmgmt1/bin/ttenv ttGridAdmin mgmtActiveSwitch

Notes

One use case is if both management instances fail, and you are not certain which one was the active. Run this command to examine them both and determine which one is "current" or "most recent", then start that one as the active management instance.

Start the standby management instance (mgmtStandbyStart)

The mgmtStandbyStart command starts the current management instance (from which the command is run) as the standby management instance.

ttGridAdmin mgmtStandbyStart

A typical scenario is when the active management instance fails, you promote the standby to active, then run this command to make the original active management instance become the new standby management instance.

Examples

% ttGridAdmin mgmtStandbyStart
Standby management instance started

Notes

  • The instance must previously be stopped.

  • There must be another management instance previously started as the active management instance.

  • This command initiates replication between the active and standby management instances, synchronizing management data between them.

Stop the standby management instance (mgmtStandbyStop)

The mgmtStandbyStop command stops the standby management instance.

ttGridAdmin mgmtStandbyStop

Examples

% ttGridAdmin mgmtStandbyStop
Standby management instance stopped

Notes

  • This command can be run from either the active or the standby management instance if they are both operational.

  • Usage scenarios include:

    • If the standby has failed

    • If you want to stop the standby for any reason, such as to reboot it or perform maintenance

  • The command will fail with an error if there is not an operational standby instance at the time the command is run.

Display status of management instances (mgmtStatus)

The mgmtStatus command displays status information for the management instances.

ttGridAdmin mgmtStatus

(Also see "Examine management instances (mgmtExamine)". The mgmtExamine command recommends actions to repair any reported problems with the management instances.)

Examples

% ttGridAdmin mgmtStatus
Host        Instance  Reachable RepRole(Self) Role(Self) Seq RepAgent RepActive
----------- --------- --------- ------------- ---------- --- -------- ---------
mysys1host  gridmgmt1 Yes       Active        Active     554 Up       Yes
mysys2host  gridmgmt1 Yes       Standby       Standby    554 Up       No

For each instance displayed:

  • Host and Instance show the name of the instance and the name of the host where it is located.

  • Reachable indicates whether the command was successful in reaching the instance to determine its state.

  • RepRole(Self) indicates the recorded role, if any, for the instance in replicating data between management instances.

  • Role(Self) indicates the recorded role, if any, for the instance.

  • Seq is the sequence number of the most recent change on the instance. If the Seq values are the same, then the two management instances are synchronized; otherwise, the one with the larger Seq value has the more recent data.

  • RepAgent indicates whether the replication agent is running on the instance.

  • RepActive indicates whether changes by the mgmtStatus command to management data on the instance were successful. The mgmtStatus command attempts to modify management data on each management instance, but this will not work on the standby management instance, which is read-only.

  • Message has any further information about the instance. (For brevity, this column is not shown in the example.)

Membership operations

Use ttGridAdmin commands in this section to export or import the membership client configuration file. A typical scenario is if you want to make changes to the file.

Note:

The membership configuration file is first specified when you create the grid, according to the gridCreate -membershipConfig option. See "Create a grid (gridCreate)".

Export the membership configuration file (membershipConfigExport)

The membershipConfigExport command exports the contents of the membership client configuration file from the specified version of the grid model into a specified file.

ttGridAdmin membershipConfigExport [-latest|-current|-version n] 
                                   [filepath] 

Options

The membershipConfigExport command has the options:

Option Description
-latest Export the configuration file from the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Export the configuration file from the current model—the model most recently applied to the grid.
-version n Export the configuration file from the specified version number of the model.
filepath The path and name of the file to write the contents of the membership client configuration file to. If no file is specified, the configuration is written to stdout.

Examples

% ttGridAdmin membershipConfigExport -latest /sw/tten/grid/zkcfg/membership2.conf

% cd /sw/tten/grid/zkcfg
% more membership2.conf
Servers zk1.example.com!2181,zk2.example.com!2181,zk3.example.com!2181

The example in the next section will import this file.

Import the membership configuration file (membershipConfigImport)

The membershipConfigImport command replaces the membership client configuration file in the latest model of the grid with the specified file.

ttGridAdmin membershipConfigImport filepath

Also see information for the gridCreate -membershipConfig option in "Create a grid (gridCreate)".

Options

The membershipConfigImport command has the option:

Option Description
filepath The path and name of the file that contains the new membership configuration.

Examples

This example imports the file created in the example from the preceding section, shown again here:

% cd /sw/tten/grid/zkcfg
% more membership2.conf
Servers zk1.example.com!2181,zk2.example.com!2181,zk3.example.com!2181

Run the command:

% ttGridAdmin membershipConfigImport /sw/tten/grid/zkcfg/membership2.conf
Membership configuration file /sw/tten/grid/zkcfg/membership2.conf imported

Notes

  • Any membership client configuration changes according to the new file are not applied until you execute the modelApply command.

  • Once you execute modelApply, the specified file is copied to each instance of the grid and its settings will take effect on each instance the next time the instance is restarted.

Model operations

Use ttGridAdmin commands in this section to apply the latest version of the model to the grid, delete a version of the model, export a version of the model to a JSON file, import a version of the model from a JSON file (to become the latest version), compare two versions of the model, or list information about all versions of the model.

Note:

The latest version of the model is the version that is pending for edits and updates. It has not yet been applied to the model. The current version of the model is the version most recently applied to the model. Only the latest version of the model is editable. All other versions are read-only. When the latest version is applied, it becomes the current version and a copy is made to serve as the initial latest version.

Apply the latest version of the model (modelApply)

The modelApply command applies the latest version of the model to the grid, implementing previous operations. This includes actions such as creating physical installations and instances according to installation and instance objects that have been defined in the model.

ttGridAdmin modelApply [-nostart]
                       [-details]

Options

The modelApply command has the options:

Option Description
-nostart By default, the modelApply command automatically starts new TimesTen Scaleout instances when they are created for the grid. If you specify -nostart, the instances are created but not started.
-details Displays additional information about the operations being performed by the command.

Examples

This example shows typical output.

% ttGridAdmin modelApply
Creating new model version............................................OK
Exporting current model (version 1)...................................OK
Identifying any deleted objects.......................................OK
Verifying installations...............................................OK
Creating new installations............................................OK
Verifying instances...................................................OK
Creating new instances................................................OK
Updating grid state...................................................OK
Configuring instance authentication...................................OK
Pushing new configuration files to each instance......................OK
Making model version 1 current, version 2 writable....................OK
Checking ssh connectivity of new instances............................OK
Starting new management instance......................................OK
Configuring standby management instance...............................OK
ttGridAdmin modelApply complete

(Output will vary depending on your situation, such as whether installations or instances in the model already existed, either from being created manually or from any previous modelApply commands that were only partially successful.)

Notes

  • When a grid is created, version 1 of the model is created automatically. When modelApply is executed on the grid for the first time, version 1 of the model is made read-only and version 2 is created. Version 2 is an exact copy of version 1 and is read-write. Version 1 is then applied to the grid. Subsequent changes made to the model are made to version 2, until modelApply is executed again, at which time version 3 is created, and so on. There is always a writable version of the model available.

  • At any given point, the writable version of the model, which has not yet been applied to the grid, is referred to as the latest version. The version that has been applied and is operational in the grid is referred to as the current version. (The current version and all previous versions are read-only.)

  • The modelApply command communicates with each instance in the grid and creates or updates configuration files on each instance, including timesten.conf, as needed. The command executes these operations in parallel as much as possible, but still may take a significant amount of time to complete. Complete all the steps in getting from one desired configuration to another desired configuration before applying the model.

  • It may not always be possible for modelApply to complete all of its operations, such as if a host is down. If there are problems, modelApply creates error logs in the diag directory of the management instance and indicates the names of those logs. The next time you execute modelApply, it will try again to complete any operations that failed previously, in addition to completing any new operations.

  • See "Applying the changes made to the model" in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information.

Compare models (modelCompare)

The modelCompare command compares two versions of the model and displays a summary of changes between them.

ttGridAdmin modelCompare -latest|-current|-version n
                         [-latest|-current|-version m]

Options

The modelCompare command has the options:

Option Description
-latest Specifies that the latest version of the model—the model being modified and not yet applied to the grid—is one of the versions to compare.

If the command line specifies only one version, that version is compared against the latest version by default.

-current Specifies that the current version of the model—the model most recently applied to the grid—is one of the versions to compare.
-version n Specifies that model version n is one of the versions to compare.
-version m Specifies that model version m is one of the versions to compare.

Examples

This example shows that the physical group location4 was added between the current model and the latest model. (Other differences shown are for meta data.)

% ttGridAdmin modelCompare -current -latest
6,9c6,8
<   "version"     : 8,
<   "whenCreated" : "2016-12-02T13:13:05.000Z",
<   "applied" : true,
<   "whenApplied" : "2016-12-13T14:57:41.000Z",
---
>   "version"     : 9,
>   "whenCreated" : "2016-12-13T14:57:19.000Z",
>   "applied" : false,
11c10
<   "current" : true,
---
>   "current" : false,
31a31,33
>     },
>     {"type" : "physicalGroup" ,
>      "name" : "location4"

Notes

The summary of changes is displayed in UNIX diff format.

Export a version of a model (modelExport)

The modelExport command exports information about the grid for the specified version of the model in JSON format, typically to a specified file.

ttGridAdmin modelExport [-latest|-current|-version n] 
                        [filepath]

Within the grid, the hierarchy of the output includes the following:

SQLNet
TNSNames
DataSpaceGroups
Hosts
   PhysicalGroups
   Installations
      Instances
Databases
   Connectables

Options

The modelExport command has the options:

Option Description
-latest Export the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Export the current model—the model most recently applied to the grid.
-version n Lists database definition objects in the specified version number of the model.
filepath Path and name of the file where the JSON representation of the model is written. If no file is specified, the export goes to stdout.

Examples

Export the current version (version 4) of the model. This is executed from a management instance:

% pwd
/sw/tten/grid/ttinstances/gridmgmt1/bin
% ttGridAdmin modelExport -current /sw/tten/grid/models/model4export.json
Model version 4 exported to /sw/tten/grid/models/model4export.json

Export the latest version (version 5) of the model, which is the default version to export. This is executed from a data instance:

% pwd
/sw/tten/grid/ttinstances/instance1/bin
% ttGridAdmin modelExport /sw/tten/grid/models/model5export.json
Model version 5 exported to /sw/tten/grid/models/model5export.json

Output files:

% pwd
/sw/tten/grid/models
% ls
model4export.json  model5export.json

Notes

  • Metrics and logs are not exported. They exist on the active management instance but are not part of the model.

  • You can execute this command from a management instance or a data instance.

  • You can use modelExport to create a backup of the model.

Import a version of the model (modelImport)

The modelImport command imports a model from a JSON file (perhaps exported earlier using the modelExport command) to update the latest version of the model, or creates a script that you can use to update the model later.

ttGridAdmin modelImport [-script scriptpath] 
                        [filepath]

Options

The modelImport command has the options:

Option Description
-script scriptpath Creates a script with the specified name and path. The model is not updated when you execute modelImport. Instead, you can execute the resulting script later to modify the latest version of the model to conform to the imported version. This allows you to review the changes beforehand.

Without -script, the latest model is updated immediately.

filepath Path and name of the JSON file from which the representation of the model is read.

If filepath is not specified, input is read from stdin.


Examples

Consider a scenario where you exported the latest version (Version 5) of the model, subsequently made changes to the latest version of the model without applying them, then decided you do not want those changes after all. To undo the changes, import the file you previously exported:

% ttGridAdmin modelImport /sw/tten/grid/models/model5export.json
Model imported

Without the -script option, the model is imported immediately.

With the script option, a script is created that you can run later:

% ttGridAdmin modelImport /sw/tten/grid/models/model5export.json -script 
/sw/tten/grid/models/modelmodscript
Script /sw/tten/grid/models/modelmodscript created.

Here is an example of a resulting script:

% pwd
/sw/tten/grid/models
% more modelmodscript
#!/bin/sh
# Created by ttGridAdmin -modelImport
TIMESTEN_HOME=/sw/tten/grid/ttinstances/gridmgmt
if [ -e $TIMESTEN_HOME/bin/ttenv.sh ]; then
 . $TIMESTEN_HOME/bin/ttenv.sh >/dev/null 2>&1
fi
# TNSNames unchanged
#Host mysys5host...
ttGridAdmin -hostCreate  mysys5host -internalAddress mysys5.example.com -externalAddress mysys5.example.com -physicalGroup location2
ttGridAdmin installationCreate mysys5host.installslc -location 
/sw/tten/grid/ttinstallations/installadc/
ttGridAdmin instanceCreate mysys5host.instance1 -installation installslc 
-location /sw/tten/grid/ttinstances/ -daemonPort 20000 -csPort 21000
#Host mysys3host...
#Host mysys1host...
#Host mysys2host...
#Host mysys4host...
#Dbdef database1
#Connectable unchanged!
#Connectable unchanged!
#DbDef unchanged!
#Dbdef TTGRIDADMIN
#Connectable unchanged!
#Connectable unchanged!
#DbDef unchanged!

Notes

  • The modelImport command compares the latest version of the model with the model being imported.

  • The changes to the latest version of the model are not done in an atomic transaction. Each change is done in a separate transaction, so any failure will result in complications.

List model versions (modelList)

The modelList command lists the versions of the model, indicating when each was defined, applied, and deleted, as applicable.

ttGridAdmin modelList

Examples

% ttGridAdmin modelList
Version Created             Applied             Deleted
------- ------------------- ------------------- -------------------
      1 2016-10-06 12:59:26 2016-10-14 13:45:24 N/A
      2 2016-10-14 13:44:45 2016-10-14 14:33:47 N/A
      3 2016-10-14 14:33:05 2016-10-14 14:46:33 N/A
      4 2016-10-14 14:46:20 N/A                 N/A

Oracle Database operations

Use ttGridAdmin commands in this section to import or export sqlnet.ora configuration or TNS names entries for connecting to an Oracle database.

These are Oracle Database features that allow an application in TimesTen Scaleout to interact with an Oracle database using the ttLoadFromOracle utility, OCI, or Pro*C/C++.

Notes:

  • Do not use these commands for OCI or Pro*C/C++ connections to a TimesTen Scaleout database. Entries for tnsnames and sqlnet are made automatically by TimesTen Scaleout.

  • The ttLoadFromOracle built-in procedure is for loading data from an Oracle database into TimesTen Classic or TimesTen Scaleout.

  • For a summary of TNS names and sqlnet.ora, see "Connecting to a TimesTen database from OCI" in Oracle TimesTen In-Memory Database C Developer's Guide.

Export a sqlnet file (SQLNetExport)

That SQLNetExport command exports sqlnet.ora configuration (that had previously been imported) from the specified version of the model, typically to a specified file.

ttGridAdmin SQLNetExport [-latest|-current|-version n] [filepath]

Options

The SQLNetExport command has the options:

Option Description
-latest Export sqlnet.ora configuration from the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Export sqlnet.ora configuration from the current model—the model most recently applied to the grid.
-version n Export sqlnet.ora configuration from the specified version number of the model.
filepath Path and name of the file that will contain the exported sqlnet.ora configuration. If no file is specified, the export goes to stdout.

Examples

This example exports sqlnet.ora from the latest version of the model (by default) then shows the contents of the file.

% ttGridAdmin SQLNetExport /sw/tten/grid/misc/sqlnet.ora
% cd /sw/tten/grid/misc
% more sqlnet.ora
# To use ezconnect syntax or tnsnames, the following entries must be
# included in the sqlnet.ora configuration.
#
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

Import a sqlnet file (SQLNetImport)

The SQLNetImport command imports sqlnet.ora configuration (used in communicating with an Oracle database through ttLoadFromOracle, OCI, Pro*C/C++, or ODP.NET) from the specified file into the sqlnet.ora file for the latest version of the model. This will be in place of any previously existing sqlnet.ora configuration.

ttGridAdmin SQLNetImport filepath

Note:

Any previous import is overwritten.

Option

The SQLNetImport command has the option:

Option Description
filepath Path and name of the file containing sqlnet.ora configuration to import.

Examples

% ttGridAdmin SQLNetImport /tmp/sqlnet.ora
SQLNet configuration file /tmp/sqlnet.ora imported

Notes

  • This is the only way to bring sqlnet.ora configuration into the grid. Do not manually add or manipulate configuration files.

  • The resulting sqlnet.ora file will be made available across all instances of the grid when you execute modelApply.

Export TNS names (TNSNamesExport)

The TNSNamesExport command exports TNS names entries (that had previously been imported) from the specified version of the model, typically to a specified file.

ttGridAdmin TNSNamesExport [-latest|-current|-version n] [filepath]

Options

The TNSNamesExport command has the options:

Option Description
-latest Export TNS names entries from the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Export TNS names entries from the current model—the model most recently applied to the grid.
-version n Export TNS names entries from the specified version number of the model.
filepath Path and name of the file that will contain the exported TNS names entries. If no file is specified, the export goes to stdout.

Examples

This example exports tnsnames.ora from the latest version of the model (by default), then shows the contents of the file.

% ttGridAdmin TNSNamesExport /sw/tten/grid/misc/tnsnames.ora
% cd /sw/tten/grid/misc
% more tnsnames.ora
...
  ORCL =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = www.example.com)(PORT=1630))
      (CONNECT_DATA =
        (SERVICE_NAME = orcl)
      )
    )
...

Import TNS names (TNSNamesImport)

The TNSNamesImport command imports TNS names entries (used in communicating with an Oracle database through ttLoadFromOracle, OCI, Pro*C/C++, or ODP.NET) from the specified file into the tnsnames.ora file for the latest version of the model. This will replace any previously imported TNS names entries.

ttGridAdmin TNSNamesImport filepath

Options

The TNSNamesImport command has the option:

Option Description
filepath Path and name of the file containing TNS entries to import.

Examples

% ttGridAdmin TNSNamesImport /tmp/tnsnames.ora
TNSNames configuration file /tmp/tnsnames.ora imported

Notes

  • This is the only way to bring TNS names configuration into the grid. Do not manually add or manipulate configuration files.

  • The resulting tnsnames.ora file will be made available across all instances of the grid when you execute modelApply.

  • The tnsnames.ora file in the grid always contains entries for all connectables. You can add to that through TNSNamesImport, but you cannot remove entries other than any you have previously imported.

Physical group operations

Use the ttGridAdmin commands in this section to define or delete a physical group or to list physical groups in the model.

Create a physical group (physicalCreate)

The physicalCreate command defines a physical group in the model.

ttGridAdmin physicalCreate name
                           [-comment comment]

Options

The physicalCreate command has the options:

Option Description
name Specifies the name for the physical group in the model.
-comment comment Associates a comment with the physical group object. Put the comment in quotes if there are any spaces. The comment is stored and included in output of the physicalList command.

Examples

% ttGridAdmin physicalCreate location1
PhysicalGroup location1 created.
% ttGridAdmin physicalCreate location2
PhysicalGroup location2 created.

Also see "Assigning hosts to physical groups" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Delete a physical group (physicalDelete)

The physicalDelete command removes a physical group from the model.

ttGridAdmin physicalDelete name

Options

The physicalDelete command has the option:

Option Description
name The name of the physical group to delete.

Examples

% ttGridAdmin physicalDelete location1
PhysicalGroup location1 deleted.
% ttGridAdmin physicalDelete location2
PhysicalGroup location2 deleted.

Notes

You cannot delete a physical group that is associated with any hosts.

List physical groups (physicalList)

The physicalList command lists all physical groups that are defined in the specified version of the model.

ttGridAdmin physicalList [-latest|-current|-version n]

Options

The physicalList command has the options:

Option Description
-latest Lists physical groups in the latest model—the model being modified and not yet applied to the grid. This is the default.
-current Lists physical groups in the current model—the model most recently applied to the grid.
-version n Lists physical groups in the specified version number of the model.

Examples

This example lists physical groups in the current version of the model, then adds another physical group and lists physical groups in the latest version (the default).

% ttGridAdmin physicalList -current
PhysicalGroup Comment
------------- -------
location1
location2
location3
% ttGridAdmin physicalCreate location4
PhysicalGroup location4 created.
% ttGridAdmin physicalList
PhysicalGroup Comment
------------- -------
location1
location2
location3
location4

Repository operations

Use ttGridAdmin commands in this section to create, attach, detach, or list repositories.

In TimesTen Scaleout, a repository is a file system directory tree used for database backups or exports or for collections of daemon logs. You specify the top-level directory when you create the repository. The contents of the directory and subdirectories of a repository, whether consisting of a backup, an export, or daemon logs, comprise a collection.

A repository is either mounted on each host of the grid (using NFS or equivalent), or mounted on a single host (optionally in the grid) and accessed by other hosts using scp (SSH copy).

For additional information, refer to "Migrating, Backing Up and Restoring Data" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

Attach a repository (repositoryAttach)

The repositoryAttach command attaches an existing repository to the grid, making it available for use.

ttGridAdmin repositoryAttach name
                             -path path
                             -method mount|scp
                             [-address internalAddress]

Options

The repositoryAttach command has the options:

Option Description
name Name of the repository to attach.
-path path Fully qualified path to the parent directory where the repository is located.

For -method mount, this is the full NFS path, such as /net/mysys2/repositories.

For -method scp, this is the full path, such as /repositories, on the system indicated by -address.

-method mount|scp Indicates how grid instances access the repository. Supported options are mount or scp.
  • mount: The repository is accessed through an NFS mount on each grid host.

  • scp: The repository is accessed by each grid host using scp through passwordless SSH.

Note: The -method setting for repositoryAttach must match the setting that was used for repositoryCreate when the repository was created.

-address internalAddress For repositories accessed through scp, this option is required and indicates the DNS name or IP address of the system where the repository is located.

Also see "Address formats".


Examples

This example attaches a repository /repositories/repo1 that is located on the system mysys2, using -method scp.

% ttGridAdmin repositoryAttach repo1 -path /repositories -method scp 
-address mysys2.example.com
Repository repo1 attached

Notes

This command is typically used to attach a repository that was created from another grid, so that you can restore a backup of a database from one grid into another grid. It can also be used to reattach a repository to the grid where it was created, if it was detached.

Create a repository (repositoryCreate)

The repositoryCreate command creates a new repository that will be available for the grid.

ttGridAdmin repositoryCreate name 
                             -path path 
                             -method mount|scp
                             [-address internalAddress]

Options

The repositoryCreate command has the options:

Option Description
name Specifies the name for the repository. This is the name of the directory that will be created under the parent directory specified by -path.
-path path Fully qualified path to the parent directory where the repository is to be created. This directory must already exist on the system(s) where the repository will be located and be readable and writable by the instance administrator.

For -method mount, this is the full NFS path, such as /net/mysys2/repositories.

For -method scp, this is the full path, such as /repositories, on the system indicated by -address.

-method mount|scp Indicates how grid instances access the repository. Supported options are mount or scp.
  • mount: The repository is accessed through an NFS mount on each grid host.

  • scp: The repository is accessed by each grid host using scp through passwordless SSH.

Note: If you will later use repositoryAttach for the repository being created, the -method setting for repositoryAttach must match the setting you are using for repositoryCreate.

-address internalAddress For repositories accessed through scp, this option is required and indicates the DNS name or IP address of the system where the repository is created.

Also see "Address formats".


Examples

This example creates a repository /repositories/repo1 on the system mysys2, using scp. The instance administrator must have write permission for /repositories.

% ttGridAdmin repositoryCreate repo1 -path /repositories -method scp 
-address mysys2.example.com
Repository repo1 created

This example creates the repository using mount.

% ttGridAdmin repositoryCreate repo1 -path /repositories -method mount
Repository repo1 created

The repository.json file has information about the repository.

Notes

  • The repository directory is created synchronously and has permissions of 700. For repositories accessed through NFS mount, the repository directory is path/name. For repositories access through scp, the repository directory is @address:path/name.

  • The repository is available for use as soon as it is created.

  • Once a repository is created with repositoryCreate, you can use repositoryAttach to access it from other grids.

Detach a repository (repositoryDetach)

The repositoryDetach command detaches (disassociates) a repository from the grid, so that it will no longer be usable from the grid.

ttGridAdmin repositoryDetach name

Options

The repositoryDetach command has the option:

Option Description
name Name of the repository to detach (as established when it was attached or created).

Examples

% ttGridAdmin repositoryDetach repo1
Repository repo1 detached

Notes

You can detach a repository that was created in the grid or, more typically, attached in the grid.

List repositories (repositoryList)

The repositoryList command lists repositories that are accessible (created or attached) in the grid, optionally including information about contents of the repositories—database backups, database exports, or collections of daemon logs and other information.

ttGridAdmin repositoryList [name]
                           [-contents [-details]]

Options

The repositoryList command has the options:

Option Description
name Name of the repository to list. If no name is specified, all repositories accessible to the grid are listed.
-contents Show the contents of each repository listed.
-details Show details about the contents of each repository listed (use with -contents).

Examples

This examples lists all repositories accessible to the grid (there is only one), but no contents.

% ttGridAdmin repositoryList
Repository Method Location            Address
---------- ------ ------------------- ------------------
repo1      scp    /repositories/repo1 mysys2.example.com

This example shows contents:

% ttGridAdmin repositoryList -contents
Repository Collection      Type   Date                     Details  
---------- --------------- ------ ------------------------ ------------------
repo1      B20170222145544 Backup 2017-02-22T14:55:48.000Z Database database1

ttGridRollout

Description

The ttGridRollout utility, run from the installation_dir/tt18.1.3.1.0/bin directory of your TimesTen installation, creates a new grid with one database definition. The database is created and loaded, its distribution is configured, then it is opened.

The utility reads a configuration file that contains user-defined parameters and attributes for the grid you want to create. TimesTen provides a configuration template that you can copy and modify.

You can specify the shape of the grid, the hosts to use, the number of management instances (one or two), and the number of data instances, among other settings. By default, if you do not specify hosts, management instances, and data instances, then a single management instance and a number of data instances suitable for the specified shape are created on your local host.

The installation from which you run ttGridRollout is copied to the other hosts you specify so that additional data instances and a standby management instance can be created as desired. If you specify two management instances, the first must be on your local host.

The ttGridRollout utility is a wrapper for the ttGridAdmin utility (also using ttInstanceCreate for the first management instance), and actions performed by ttGridRollout can optionally be performed directly using ttGridAdmin. Once you have created a grid with ttGridRollout, use ttGridAdmin to maintain it and to make any changes.

The ttGridRollout utility is typically used for creating sample grids or grids that will be used during product design and evaluation.

Important:

  • Execute this utility exactly as "ttGridRollout" (for example, not as "ttgridrollout").

  • The ttGridRollout utility does not support physical groups.

Required privilege

The user who runs this utility becomes the instance administrator of all instances created, and the user's primary user group becomes the TimesTen user group.

File system write permission is required wherever installations and instances will be created.

Usage with TimesTen Scaleout

This utility is specifically for use with TimesTen Scaleout.

Syntax

ttGridRollout [-h | -help | -?]
ttGridRollout [-n | -dry-run] [-wait n] [-timeout n] conf_file

Options

ttGridRollout has the options:

Option Description
-h

-help

-?

Displays help information.
conf_file Specifies the configuration file that contains the parameters for creating the grid and database.

A read-only template, ttgrid.conf.example, is located in the installation_dir/tt18.1.3.1.0/grid/conf directory. You can copy and modify this file to set up your configuration.

-n | -dry-run Displays the commands to be executed but does not execute them. Other options you specify will be reflected in the display of commands to be executed.

Note: It is advisable to do this before executing the command.

-wait n Specifies how long ttGridRollout will wait for database state changes to complete before returning. By default, there is no limit to the wait.

(Database operations in TimesTen Scaleout, such as creating, loading, and opening, initiate a state change that is recorded in the active management instance of the grid. The state change is complete once the database operation has completed on each instance of the grid.)

-timeout n Maximum number of seconds to wait for a long-running operation to complete. The default is 600.

Note:

the -wait option applies only to database operations. The -timeout option applies to any operation. These options are passed to ttGridAdmin.

Also see "Command timeouts and waits".

Configuration file parameters

The table that follows describes configuration parameters supported by the ttGridRollout configuration file (named ttgrid.conf by convention).

Important:

These parameters are required in your configuration file:
  • grid_name

  • dbdef_file

  • shape (optionally with data_hosts) or data_instances

  • instance_location

  • zoo_conf, unless all TimesTen instances and the membership server are on the local host

Parameter Description
cs_connect_files Connectable files (.connect) for client/server connectables, as desired. You can specify multiple, comma-separated .connect files. For example:
cs_connect_files = client1.connect, client2.connect

For information about connectable files, see "Create a connectable (connectableCreate)".

data_hosts List of entries for hosts to be used for data instances, in JSON format.

Optionally use this with shape (and it cannot be used without shape).

Do not use both data_hosts and data_instances.

If you do not specify enough hosts for an NxK grid (see the description for shape), ttGridRollout loops back to the start of the specified host list and will place additional instances on as many hosts as necessary. If you specify too many hosts, only the first NxK hosts are used.

This parameter supports the attributes address, externalAddress, internalAddress, installation_location, and instance_location. See "Configuration file parameter attributes", including information about default values.

Specifying address(es) is required—either address OR externalAddress and internalAddress.

Example:

data_hosts = [
{ "internalAddress":"tthost1-priv", 
"externalAddress":"tthost1.example.com", 
"installation_location":"/u01/tthost1/TimesTen" }, 
{ "internalAddress":"tthost2-priv", 
"externalAddress":"tthost2.example.com", 
"installation_location":"/u01/tthost2/TimesTen" }, 
{ "internalAddress":"tthost3-priv", 
"externalAddress":"tthost3.example.com", 
"installation_location":"/u01/tthost3/TimesTen" }, 
{ "internalAddress":"tthost4-priv", 
"externalAddress":"tthost4.example.com", 
"installation_location":"/u01/tthost4/TimesTen" } 
]

Notes: See notes for shape.

data_instances List of entries for data instances, in JSON format. This parameter allows you to specify data space groups, host and instance names, and daemon and client/server port numbers.

You cannot use data_instances together with shape or data_hosts. (Specify shape, with or without data_hosts, or specify data_instances.)

This parameter supports the attributes address, externalAddress, internalAddress, host, instance, dataSpaceGroup, daemonport, csport, installation_location, and instance_location. See "Configuration file parameter attributes", including information about default values.

The shape of the grid is determined by your dataSpaceGroup settings. If you do not specify data space groups, the grid will be Nx1, with one data space group.

Specifying address(es) is required—either address OR externalAddress and internalAddress.

Example:

data_instances = [
{ "internalAddress":"tthost1-priv", 
"externalAddress":"tthost1.example.com", 
"dataspacegroup":1, "daemonport":50001, "csport":50002 }, 
{ "internalAddress":"tthost2-priv", 
"externalAddress":"tthost2.example.com", 
"dataspacegroup":1, "daemonport":50001, "csport":50002 }, 
{ "internalAddress":"tthost3-priv", 
"externalAddress":"tthost3.example.com", 
"dataspacegroup":2, "daemonport":50001, "csport":50002 }, 
{ "internalAddress":"tthost4-priv", 
"externalAddress":"tthost4.example.com", 
"dataspacegroup":2, "daemonport":50001, "csport":50002 } 
]

Notes:

  • A host object is created for each instance, except where two data instances are specified to be on the same system and in the same dataspace group, in which case they will share the same host object.

  • An installation object is created for each host object. Multiple installation objects can point to the same physical installation.

dbdef_file Database definition file (.dbdef). This is required.

Directories are created on each host as necessary for the DataStore and LogDir locations.

For information about database definition files, see "Create a database definition (dbdefCreate)".

direct_connect_files Connectable files (.connect) for additional direct connectables, as desired, beyond the connectable that is automatically created when the database is created. You can specify multiple, comma-separated .connect files. For example:
direct_connect_files = mydbcfg1.connect, mydbcfg2.connect

For information about connectable files, see "Create a connectable (connectableCreate)".

grid_name The desired name of the grid. This is required.
init_script A SQL script (ttIsql script) for ttGridRollout to execute on the database after rolling out the grid (using the first data instance that was created). For example, the script may include SQL statements to create database users and schemas.
installation_location Path to the parent directory where you want to put the TimesTen installation on systems where the standby management instance (if applicable) and data instances are located. The tt18.1.3.1.0 directory is directly under this location. The directory is created on each host as necessary. If you specify an existing location, the directory must be empty.

The default is to use the same location as for the installation on the local host, from which ttGridRollout is run.

This location is used throughout the grid, except where you override it for a particular host or instance by setting the installation_location attribute of the data_hosts, data_instances, or mgmt_instances parameter.

instance_config A file for custom configuration of data instances, consisting of name=value pairs for any settings you want to add to the instance configurations.

This is accomplished using the ttGridAdmin instanceConfigImport command. Also see "Import instance configuration attributes (instanceConfigImport)".

instance_location Path to the parent directory for TimesTen instances (data and management). This is required. For each instance, the timesten_home directory will be named instancename under this location. The directory is created on each host as necessary.

This location is used throughout the grid, except where you override it for a particular host or instance by setting the instance_location attribute of the data_hosts, data_instances, or mgmt_instances parameter.

mgmt_instances List of entries for management instances, in JSON format. The first entry must be on the local host and will be the active management instance. The second entry (if applicable) must be on a different system and will be the standby management instance.

If you do not set mgmt_instances, ttGridRollout creates one management instance on the local host.

This parameter supports the attributes address, externalAddress, internalAddress, host, instance, daemonport, csport, mgmtport, installation_location, and instance_location. See "Configuration file parameter attributes", including information about default values.

Specifying address(es) is required—either address OR externalAddress and internalAddress.

Example:

mgmt_instances = [
{ "internalAddress":"tthost1-priv", 
"externalAddress":"tthost1.example.com" }, 
{ "internalAddress":"tthost2-priv", 
"externalAddress":"tthost2.example.com" } 
]

Notes:

  • A host object and an installation object are created for each instance.

shape The desired shape of the grid, NxK, where:
  • N is the number of instances in each data space group.

  • K is the K-factor (replication factor) of the grid, which is by definition the number of data space groups (1 or 2).

Either specify shape, with or without data_hosts, or specify data_instances. If you use shape without data_hosts, all TimesTen instances are placed on the local host.

When you specify shape for an NxK grid, NxK instances will be created (such as eight instances for a 4x2 grid). The first N instances will be in data space group 1, and for k=2 the next N data instances will be in data space group 2.

Notes:

  • A host object is created for each instance, except where two data instances will be on the same system and in the same dataspace group, in which case they will share the same host object.

  • If you specify host addresses as DNS names, default host object names are according to the addresses (such as mysys1 for an address mysys1.example.com, with _2 appended if there is a second host object on the same system, or mysys1_mgmt for the host of a management instance). If you specify addresses as IP addresses, default host object names are host_n sequentially.

  • An installation object is created for each host object. Multiple installation objects can point to the same physical installation.

  • As ttGridRollout creates instances, it names them instance1, instance2, instance3, and so on.

sqlnet_config SQL*Net configuration file (used in communicating with an Oracle database through ttLoadFromOracle, OCI, Pro*C/C++, or ODP.NET).

Through the ttGridAdmin SQLNetImport command, ttGridRollout applies the specified SQL*Net configuration on all data instances. Also see "Export a sqlnet file (SQLNetExport)".

tnsnames_config TNS names configuration file (used in communicating with an Oracle database through ttLoadFromOracle, OCI, Pro*C/C++, or ODP.NET).

Through the ttGridAdmin TNSNamesImport command, ttGridRollout applies the specified TNS names configuration on all data instances. Also see "Import TNS names (TNSNamesImport)".

zoo_conf Apache ZooKeeper membership service client configuration file. This parameter is required unless all management instances, data instances, and the ZooKeeper membership server will be on your local host.

For examples of ZooKeeper client configuration files, see "Membership operations". For details on how to configure ZooKeeper as a membership service, see "Using Apache ZooKeeper as the membership service" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

If you do not specify this parameter, ttGridRollout assumes that a ZooKeeper server already runs on the local host using the default client port setting, 2181.


Configuration file parameter attributes

The ttGridRollout configuration parameters support these attributes. Refer to the preceding table of parameters to see which attributes are supported by each parameter.

Attribute Description
address DNS name or IP address of the system for both external and internal communications, if a single address is used. Either use address or use internalAddress and externalAddress. Setting -address xxx is exactly equivalent to setting -internalAddress xxx and -externalAddress xxx.

This option takes one name or address only, and a specified name must resolve to one IP address or to multiple IP addresses on the same network segment.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Note: Using a single address is not recommended for production environments.

Also see "Address formats".

csport Port for client/server connections.

If this is not specified for a data instance, ttGridRollout uses an available port between 46337 and 46997.

If this is not specified for a management instance, ttGridRollout attempts to use the TimesTen default client/server port, 6625.

daemonport Port for TimesTen daemon communications.

If this is not specified for a data instance, ttGridRollout uses an available port between 46337 and 46997.

If this is not specified for a management instance, ttGridRollout attempts to use the TimesTen default daemon port, 6624.

dataSpaceGroup Desired data space group (1 or 2). The default is data space group 1.

If you use the data_instances parameter, you can use this attribute to specify the data space group for the instance.

externalAddress DNS name or IP address of the system for external communications (outside the grid) for client/server connections. Either use address or use internalAddress and externalAddress. Setting -internalAddress xxx and -externalAddress xxx is exactly equivalent to setting -address xxx.

This option takes one name or address only, but a name may resolve to one or more IP addresses.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Also see "Address formats".

host Desired name of the host object in the grid model.

Note: If you specify host addresses as DNS names, default host object names are according to the addresses (such as mysys1 for an address mysys1.example.com, with _2 appended if there is a second host object on the same system, or mysys1_mgmt for the host of a management instance). If you specify addresses as IP addresses, default host object names are host_n sequentially.

installation_location Overrides the grid-wide installation_location setting for a host or instance. See installation_location under "Configuration file parameters" for additional information.
instance If you use the data_instances or mgmt_instances parameter (as appropriate), you can use this attribute to specify the instance name.

Alternatively, for data instances, ttGridRollout names the instances instance1, instance2, instance3, and so on.

Alternatively, for management instances, ttGridRollout names the instances gridname_mgmt and gridname_mgmt2 (if there is a second management instance).

instance_location Overrides the grid-wide instance_location setting for a host or instance. See instance_location under "Configuration file parameters" for additional information.
internalAddress DNS name or IP address for internal communications (within the grid). Either use address or use internalAddress and externalAddress. Setting -internalAddress xxx and -externalAddress xxx is exactly equivalent to setting -address xxx.

This option takes one name or address only, and a specified name must resolve to one IP address or to multiple IP addresses on the same network segment.

If host names from /etc/hosts are being used, the /etc/hosts files on all instances in the grid must contain identical entries for all hosts in the grid.

Also see "Address formats".

mgmtport Port for management instance communications.

If this is not specified, ttGridRollout attempts to use the TimesTen default management port, 3754.


Examples

This sections provides three ttGridRollout examples with various types of configuration:

  • shape parameter without data_hosts to configure a 2x2 grid with one management instance, all on the local host

  • shape parameter with data_hosts to configure a 2x2 grid with one management instance on four systems, with the management instance and a data instance on the local host

  • data_instances parameter to configure a 3x2 grid with two management instances on eight systems, with the first management instance on the local host

Each example includes the configuration, the dry run output showing the ttGridAdmin commands to be executed, and portions of the execution output. In each example, mysys1 is the local host. Dry run output is edited for readability. (The ttInstanceCreate utility, to create the first management instance, is executed through the full path to the installation bin directory; ttGridAdmin is executed through the full path to the TimesTen ttenv environment setup script in the first management instance bin directory.)

Additional examples are in "Deploy a grid and database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.

shape without data_hosts: This scenario is convenient for standalone development.

Configuration:

dbdef_file = /sw/tten/dbdef/database1.dbdef
shape = 2x2
zoo_conf = /sw/tten/zkconfig/membership.conf
grid_name = grid1
instance_location = /sw/tten/grid1/ttinstances

Dry run:

% ./ttGridRollout -dry-run /sw/tten/gridconfig/ttgrid1.conf
ttInstanceCreate -grid -location /sw/tten/grid1/ttinstances -name grid1_mgmt
ttGridAdmin gridCreate grid1 -k 2 -host mysys1_mgmt -address mysys1
 -membershipConfig /sw/tten/zkconfig/membership.conf
ttGridAdmin hostCreate mysys1 -address mysys1 -dataspacegroup 1
ttGridAdmin installationCreate mysys1 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys1_2 -address mysys1 -dataspacegroup 2
ttGridAdmin installationCreate mysys1_2 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin instanceCreate mysys1.instance1 -location /sw/tten/grid1/ttinstances
 -daemonport 46337 -csport 46338
ttGridAdmin instanceCreate mysys1.instance2 -location /sw/tten/grid1/ttinstances
 -daemonport 46339 -csport 46340
ttGridAdmin instanceCreate mysys1_2.instance3 -location /sw/tten/grid1/ttinstances
 -daemonport 46341 -csport 46342
ttGridAdmin instanceCreate mysys1_2.instance4 -location /sw/tten/grid1/ttinstances
 -daemonport 46343 -csport 46344
ttGridAdmin dbdefCreate /sw/tten/dbdef/database1.dbdef
ttGridAdmin modelApply
ttGridAdmin dbCreate -wait database1
ttGridAdmin dbDistribute database1 -add all -apply
ttGridAdmin dbOpen -wait database1

Execution:

% ./ttGridRollout /sw/tten/gridconfig/ttgrid1.conf
INFO: Generating data_instances for 2x2 Grid
data_instances = [
 { "address":"mysys1", "dataspacegroup":1 },
 { "address":"mysys1", "dataspacegroup":1 },
 { "address":"mysys1", "dataspacegroup":2 },
 { "address":"mysys1", "dataspacegroup":2 }
]
INFO: Checking Zookeeper on zk1!2181 -- OK
INFO: Checking Zookeeper on zk2!2181 -- OK
INFO: Checking Zookeeper on zk3!2181 -- OK
INFO: Checking the address for the management database -- OK
INFO: Checking connectivity to mysys1 -- OK
 
================================================================================
 
...
 
================================================================================
4-instance (2x2) grid successfully created.
 
Management Instance Location
----------------------------
- mysys1:/sw/tten/grid1/ttinstances/grid1_mgmt
 
...
 
Data Instance Locations
-----------------------
- mysys1.instance1 ==> mysys1:/sw/tten/grid1/ttinstances/instance1
- mysys1.instance2 ==> mysys1:/sw/tten/grid1/ttinstances/instance2
- mysys1_2.instance3 ==> mysys1:/sw/tten/grid1/ttinstances/instance3
- mysys1_2.instance4 ==> mysys1:/sw/tten/grid1/ttinstances/instance4
 
...

shape with data_hosts: This scenario is useful for initial testing on multiple systems.

Configuration:

dbdef_file = /sw/tten/dbdef/database1.dbdef
shape = 2x2
zoo_conf = /sw/tten/zkconfig/membership.conf
grid_name = grid1
instance_location = /sw/tten/grid1/ttinstances
data_hosts = [
  { "internalAddress":"mysys1-i", "externalAddress":"mysys1.example.com" },
  { "internalAddress":"mysys2-i", "externalAddress":"mysys2.example.com" },
  { "internalAddress":"mysys3-i", "externalAddress":"mysys3.example.com" },
  { "internalAddress":"mysys4-i", "externalAddress":"mysys4.example.com" }
]

Dry run:

% ./ttGridRollout -dry-run /sw/tten/gridconfig/ttgrid1.conf
ttInstanceCreate -grid -location /sw/tten/grid1/ttinstances -name grid1_mgmt
ttGridAdmin gridCreate grid1 -k 2 -host mysys1_mgmt -address mysys1
 -membershipConfig /sw/tten/zkconfig/membership.conf
ttGridAdmin hostCreate mysys1 -externaladdress mysys1.example.com
 -internaladdress mysys1-i -dataspacegroup 1
ttGridAdmin installationCreate mysys1 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys2 -externaladdress mysys2.example.com
 -internaladdress mysys2-i -dataspacegroup 1
ttGridAdmin installationCreate mysys2 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys3 -externaladdress mysys3.example.com
 -internaladdress mysys3-i -dataspacegroup 2
ttGridAdmin installationCreate mysys3 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys4 -externaladdress mysys4.example.com
 -internaladdress mysys4-i -dataspacegroup 2
ttGridAdmin installationCreate mysys4 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin instanceCreate mysys1.instance1 -location /sw/tten/grid1/ttinstances
 -daemonport 46337 -csport 46338
ttGridAdmin instanceCreate mysys2.instance2 -location /sw/tten/grid1/ttinstances
 -daemonport 46339 -csport 46340
ttGridAdmin instanceCreate mysys3.instance3 -location /sw/tten/grid1/ttinstances
 -daemonport 46341 -csport 46342
ttGridAdmin instanceCreate mysys4.instance4 -location /sw/tten/grid1/ttinstances
 -daemonport 46343 -csport 46344
ttGridAdmin dbdefCreate /sw/tten/dbdef/database1.dbdef
ttGridAdmin modelApply
ttGridAdmin dbCreate -wait database1
ttGridAdmin dbDistribute database1 -add all -apply
ttGridAdmin dbOpen -wait database1

Execution:

% ./ttGridRollout /sw/tten/gridconfig/ttgrid1.conf
INFO: Generating data_instances for 2x2 Grid
data_instances = [
 { "externaladdress":"mysys1.example.com", "internaladdress":"mysys1-i",
 "dataspacegroup":1 },
 { "externaladdress":"mysys2.example.com", "internaladdress":"mysys2-i",
 "dataspacegroup":1 },
 { "externaladdress":"mysys3.example.com", "internaladdress":"mysys3-i",
 "dataspacegroup":2 },
 { "externaladdress":"mysys4.example.com", "internaladdress":"mysys4-i",
 "dataspacegroup":2 }

]
INFO: Checking Zookeeper on zk1!2181 -- OK
INFO: Checking Zookeeper on zk2!2181 -- OK
INFO: Checking Zookeeper on zk3!2181 -- OK
INFO: Checking the address for the management database -- OK
INFO: Checking connectivity to mysys1 -- OK
INFO: Checking connectivity to mysys1-i -- OK
INFO: Checking connectivity to mysys2-i -- OK
INFO: Checking connectivity to mysys3-i -- OK
INFO: Checking connectivity to mysys4-i -- OK
 
================================================================================
 
...
 
================================================================================
4-instance (2x2) grid successfully created.
 
Management Instance Location
----------------------------
- mysys1:/sw/tten/grid1/ttinstances/grid1_mgmt
 
...
 
Data Instance Locations
-----------------------
- mysys1.instance1 ==> mysys1-i:/sw/tten/grid1/ttinstances/instance1
- mysys2.instance2 ==> mysys2-i:/sw/tten/grid1/ttinstances/instance2
- mysys3.instance3 ==> mysys3-i:/sw/tten/grid1/ttinstances/instance3
- mysys4.instance4 ==> mysys4-i:/sw/tten/grid1/ttinstances/instance4
 
...

data_instances: This scenario is useful for more realistic proof-of-concept testing.

Configuration:

dbdef_file = /sw/tten/dbdef/database1.dbdef
zoo_conf = /sw/tten/zkconfig/membership.conf
grid_name = grid1
instance_location = /sw/tten/grid1/ttinstances
data_instances = [
  { "internalAddress":"mysys3-i", "externalAddress":"mysys3.example.com",
 "dataspacegroup":1, "daemonport":50001, "csport":50002 },
  { "internalAddress":"mysys4-i", "externalAddress":"mysys4.example.com",
 "dataspacegroup":1, "daemonport":50001, "csport":50002 },
  { "internalAddress":"mysys5-i", "externalAddress":"mysys5.example.com",
 "dataspacegroup":1, "daemonport":50001, "csport":50002 },
  { "internalAddress":"mysys6-i", "externalAddress":"mysys6.example.com",
 "dataspacegroup":2, "daemonport":50001, "csport":50002 },
  { "internalAddress":"mysys7-i", "externalAddress":"mysys7.example.com",
 "dataspacegroup":2, "daemonport":50001, "csport":50002 },
  { "internalAddress":"mysys8-i", "externalAddress":"mysys8.example.com",
 "dataspacegroup":2, "daemonport":50001, "csport":50002 }
]
mgmt_instances = [
  { "internalAddress":"mysys1-i", "externalAddress":"mysys1.example.com" },
  { "internalAddress":"mysys2-i", "externalAddress":"mysys2.example.com" }
]

Dry run:

% ./ttGridRollout -dry-run /sw/tten/gridconfig/ttgrid1.conf
ttInstanceCreate -grid -location /sw/tten/grid1/ttinstances -name grid1_mgmt
ttGridAdmin gridCreate grid1 -k 2 -host mysys1-i_mgmt -internalAddress mysys1-i
 -externalAddress mysys1.example.com -membershipConfig
 /sw/tten/zkconfig/membership.conf
ttGridAdmin hostCreate mysys2-i_mgmt -internalAddress mysys2-i -externalAddress
 mysys2.example.com
ttGridAdmin installationCreate mysys2-i_mgmt -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin instanceCreate mysys2-i_mgmt.grid1_mgmt2 -location
 /sw/tten/grid1/ttinstances -type management
ttGridAdmin hostCreate mysys3 -externaladdress mysys3.example.com
 -internaladdress mysys3-i -dataspacegroup 1
ttGridAdmin installationCreate mysys3 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys4 -externaladdress mysys4.example.com
 -internaladdress mysys4-i -dataspacegroup 1
ttGridAdmin installationCreate mysys4 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys5 -externaladdress mysys5.example.com
 -internaladdress mysys5-i -dataspacegroup 1
ttGridAdmin installationCreate mysys5 -location /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys6 -externaladdress mysys6.example.com -internaladdress
 mysys6-i -dataspacegroup 2
ttGridAdmin installationCreate mysys6 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys7 -externaladdress mysys7.example.com
 -internaladdress mysys7-i -dataspacegroup 2
ttGridAdmin installationCreate mysys7 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin hostCreate mysys8 -externaladdress mysys8.example.com
 -internaladdress mysys8-i -dataspacegroup 2
ttGridAdmin installationCreate mysys8 -location
 /sw/tten/grid1/ttinstall/installation1
ttGridAdmin instanceCreate mysys3.instance1 -location /sw/tten/grid1/ttinstances
 -daemonport 50001 -csport 50002
ttGridAdmin instanceCreate mysys4.instance2 -location /sw/tten/grid1/ttinstances
 -daemonport 50001 -csport 50002
ttGridAdmin instanceCreate mysys5.instance3 -location /sw/tten/grid1/ttinstances
 -daemonport 50001 -csport 50002
ttGridAdmin instanceCreate mysys6.instance4 -location /sw/tten/grid1/ttinstances
 -daemonport 50001 -csport 50002
ttGridAdmin instanceCreate mysys7.instance5 -location /sw/tten/grid1/ttinstances
 -daemonport 50001 -csport 50002
ttGridAdmin instanceCreate mysys8.instance6 -location /sw/tten/grid1/ttinstances
 -daemonport 50001 -csport 50002
ttGridAdmin dbdefCreate /sw/tten/dbdef/database1.dbdef
ttGridAdmin modelApply
ttGridAdmin dbCreate -wait database1
ttGridAdmin dbDistribute database1 -add all -apply
ttGridAdmin dbOpen -wait database1

Execution:

% ./ttGridRollout /sw/tten/gridconfig/ttgrid1.conf
INFO: Checking Zookeeper on zk1!2181 -- OK
INFO: Checking Zookeeper on zk2!2181 -- OK
INFO: Checking Zookeeper on zk3!2181 -- OK
INFO: Checking the address for the management database -- OK
INFO: Checking connectivity to mysys1-i -- OK
INFO: Checking connectivity to mysys2-i -- OK
INFO: Checking connectivity to mysys3-i -- OK
INFO: Checking connectivity to mysys4-i -- OK
INFO: Checking connectivity to mysys5-i -- OK
INFO: Checking connectivity to mysys6-i -- OK
INFO: Checking connectivity to mysys7-i -- OK
INFO: Checking connectivity to mysys8-i -- OK
 
================================================================================
 
...
 
================================================================================
6-instance (3x2) grid successfully created.
 
Management Instance Locations
-----------------------------
- mysys1-i:/sw/tten/grid1/ttinstances/grid1_mgmt
- mysys2-i:/sw/tten/grid1/ttinstances/grid1_mgmt2
 
...
 
Data Instance Locations
-----------------------
- mysys3.instance1 ==> mysys3-i:/sw/tten/grid1/ttinstances/instance1
- mysys4.instance2 ==> mysys4-i:/sw/tten/grid1/ttinstances/instance2
- mysys5.instance3 ==> mysys5-i:/sw/tten/grid1/ttinstances/instance3
- mysys6.instance4 ==> mysys6-i:/sw/tten/grid1/ttinstances/instance4
- mysys7.instance5 ==> mysys7-i:/sw/tten/grid1/ttinstances/instance5
- mysys8.instance6 ==> mysys8-i:/sw/tten/grid1/ttinstances/instance6
 
...