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".
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.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 |
|---|---|
|
Administers a TimesTen Scaleout grid. |
|
|
Creates a new grid and database. |
Table 4-2 Utilities supported in both TimesTen Scaleout and TimesTen Classic descriptions
| Name | Description |
|---|---|
|
Examines all files in an installation of TimesTen and generates a signature for the installation, |
|
|
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. |
|
|
Create a new TimesTen instance. |
|
|
Destroys an existing TimesTen instance. |
|
|
Modifies certain attributes of an instance. |
|
|
Executes SQL statements interactively. |
|
|
Saves and restores TimesTen objects. |
|
|
Prints out the schema, or selected objects, of a database. |
|
|
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. |
|
|
Monitors database metrics or takes and compares snapshots of metrics. |
|
|
lists the TimesTen release information. |
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 astimesten.conf, sys.odbc.ini, and tnsnames.ora).Instance administrator of the management instance from which ttGridAdmin is run. The user then becomes the instance administrator of all instances created with ttGridAdmin.
This utility is specifically for use with TimesTen Scaleout, with commands that perform any operations on a grid.
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".
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.
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.
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: 2001:b400:2000:834:26:3eff:fe07:5b83
IPv4 address: 192.0.2.1
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.
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.
The listed sections provide detailed information about ttGridAdmin commands and functionality in these areas:
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] ...
ttGridAdmin has the general options:
This section describes error or status values and JSON data elements returned by ttGridAdmin commands.
ttGridAdmin commands returns error codes to note success or failure, including these general codes:
| Code | Description |
|---|---|
| 0 | Success |
| 255 | Internal error |
| 254 | Syntax error |
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.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.
The dbBackup command initiates a backup of the specified database.
ttGridAdmin dbBackup dbname -repository reponame [-name backupname] [-backupType normal|staged] [-bwlimit limit] [-compress value]
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.
TimesTen Scaleout enables you to create staged backups for SCP repositories. This type of backup eliminates the overhead of creating local copies of the checkpoints and log files and reduces the WAN traffic of creating a remote copy in the repository. See "Back up a database into a remote repository (WAN-friendly)" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more information.
Important:
Be aware of the following if the specified repository was created with-method scp:
For normal backups, backup file for each element is stored on the local file system 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".
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
|
-backupType normal|staged |
For repositories using the SCP method, specifies the type of backup to create. Supported options are normal or staged.
By default, TimesTen creates normal backups. |
-bwlimit limit |
For staged backups, specifies the aggregated maximum bandwidth (in MB per second) used to copy and synchronize files between hosts and repository.
By default, staged backups use as much WAN bandwidth as possible. |
-compress value |
For staged backups, specifies the level of compression used to copy and synchronize files between hosts and repository. Supported values range from 0 to 9, where 0 represents no compression and 9 represents the maximum compression available.
By default, staged backups use no compression. |
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.
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 database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.
The dbBackupDelete command deletes the specified database backup.
ttGridAdmin dbBackupDelete -repository reponame -name backupname
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. |
This example deletes the backup created in the example in "Back up a database (dbBackup)".
% ttGridAdmin dbBackupDelete -repository repo1 -name B20170222145544 Backup B20170222145544 deleted
The dbBackupStatus command shows the status of a database backup or backups previously started.
ttGridAdmin dbBackupStatus dbname [-name backupname]
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. |
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
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.
The dbRestore command restores a database backup into a new database.
ttGridAdmin dbRestore dbname -repository reponame -backup backupname
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. |
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.
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 database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.
The dbRestoreStatus command shows the status of a database restore previously started.
ttGridAdmin dbRestoreStatus dbname
The dbRestoreStatus command has the option:
| Option | Description |
|---|---|
dbname |
Name of the database where the restore is being checked. |
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
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.
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 thedbdefCreate command.See "Connecting to a database" and its subsections in Oracle TimesTen In-Memory Database Scaleout User's Guide for additional information about connectables.
The connectableCreate command creates a connectable object in the model, defining connection attribute settings.
ttGridAdmin connectableCreate -dbdef name [-cs [-only hostname[.instancename]]] filepath
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 |
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. |
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.
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.
The connectableDelete command deletes an existing connectable object from the model.
ttGridAdmin connectableDelete name
The connectableDelete command has the option:
| Option | Description |
|---|---|
name |
The name of the connectable object to delete. |
% ttGridAdmin connectableDelete database1client Connectable database1client deleted from Model.
The connectableExport command exports a connectable object and its connection attribute settings, typically to a specified file.
ttGridAdmin connectableExport name [filepath]
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. |
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
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]
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. |
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.
The connectableModify command modifies a connectable object.
ttGridAdmin connectableModify [-only hostname[.instancename]] filepath
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 Note: Instances specified with |
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. |
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.
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.)
Use the ttGridAdmin command in this section to get recommendations for assignments of hosts to data space groups.
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]
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 |
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
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.
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.
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.
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 |
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.
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.)
The dbdefDelete command removes a database definition object from the model.
ttGridAdmin dbdefDelete name
[-cascade|-nocascade]
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. |
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
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.
The dbdefExport command exports an existing database definition object from the model, typically to a specified file.
ttGridAdmin dbdefExport name [filepath]
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. |
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
The dbdefList command lists the database definition objects that exist in the specified version of the model.
ttGridAdmin dbdefList [-latest|-current|-version n]
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. |
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
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
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 |
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.
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.
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.
The dbClose command closes the database so that applications can no longer connect to it.
ttGridAdmin dbClose name [-nowait | -wait [timeout]]
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 The In a large grid, it is not typical or generally advisable to use |
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)
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.
The dbCreate command creates a database in the grid according to the specified database definition.
ttGridAdmin dbCreate name [-instance hostname[.instancename]] [-nowait | -wait [timeout]]
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 The 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 The In a large grid, it is not typical or generally advisable to use |
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 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 -all 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) Database database1 element level status as of Sat Nov 11 14:23:05 PST 2017 Host Instance Elem Status Date/Time of Event Message ---------- --------- ---- ------ ------------------- ------- mysys3host griddata1 1 loaded 2017-11-11 14:22:52 mysys4host griddata2 2 loaded 2017-11-11 14:22:51 mysys5host griddata3 3 failed 2017-11-11 14:22:52 mysys6host griddata4 4 loaded 2017-11-11 14:22:53 Database database1 Replica Set status as of Sat Nov 11 14:23:05 PST 2017 RS DS Elem Host Instance Status Date/Time of Event Message -- -- ---- ---- -------- ------ ------------------ ------- Database database1 Data Space Group status as of Sat Nov 11 14:23:05 PST 2017 DS RS Elem Host Instance Status Date/Time of Event Message -- -- ---- ---- -------- ------ ------------------ -------
(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)
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.)
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]]
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 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 The In a large grid, it is not typical or generally advisable to use |
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 -all 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 2) Database database1 element level status as of Tue Jan 9 16:04:16 PST 2018 Host Instance Elem Status Date/Time of Event Message ---------- --------- ---- --------- ------------------- ------- mysys3host griddata1 1 destroyed 2018-01-09 16:04:02 mysys4host griddata2 2 destroyed 2018-01-09 16:04:01 mysys5host griddata3 3 unloaded 2018-01-09 16:01:25 mysys6host griddata4 4 unloaded 2018-01-09 16:01:01 Database database1 Replica Set status as of Tue Jan 9 16:04:16 PST 2018 RS DS Elem Host Instance Status Date/Time of Event Message -- -- ---- ---------- --------- -------- ------------------- ------- 1 1 3 mysys5host griddata3 unloaded 2018-01-09 16:01:25 1 2 4 mysys6host griddata4 unloaded 2018-01-09 16:01:01 Database database1 Data Space Group status as of Tue Jan 9 16:04:16 PST 2018 DS RS Elem Host Instance Status Date/Time of Event Message -- -- ---- ---------- --------- -------- ------------------- ------- 1 1 3 mysys5host griddata3 unloaded 2018-01-09 16:01:25 2 1 4 mysys6host griddata4 unloaded 2018-01-09 16:01:01
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.
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:
ThedbDisconnect command does not affect subdaemon connections.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):
A recommended best practice is to run 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 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 The If there is a large number of connections, it may not be advisable to use Note: Even when using |
This example:
Uses dbStatus to show existing connections.
Closes the database and confirms.
Disconnects in transactional mode (without wait).
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.)
Disconnects in immediate mode (without wait), to be sure connections are closed.
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
---- -------- ------ ---- --- ---- ----- ----- ----
%
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.
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.
The dbDisconnectStatus command has the option:
| Option | Description |
|---|---|
name |
Name of the database. |
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.
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 When the additions are applied, data will be distributed evenly across the grid. Notes:
Also see Notes below for this and other options taking |
-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 It is typical to use If you have a grid with Note: Until you issue 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 Specify one instance per usage, but you can use If you use You can use Notes:
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 |
-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 |
-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 See "Recovering from a data distribution error" in Oracle TimesTen In-Memory Database Scaleout User's Guide for related information. Note: The |
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
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.
The dbList command lists the databases that have been created in the grid and indicates whether they have been loaded or opened.
ttGridAdmin dbList
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]]
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 The In a large grid, it is not typical or generally advisable to use |
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)
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.
The dbOpen command opens the database so that applications can connect to it.
ttGridAdmin dbOpen name [-nowait | -wait [timeout]]
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 The In a large grid, it is not typical or generally advisable to use |
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)
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.
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.
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 |
-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 |
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.
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. |
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 |
Type |
The type of connection. One of the following:
|
CHost |
For client/server connections, the host name of the client where the application is running.
Note: This item is not shown when the |
CAddr |
For client server connections, the IP address of the client where the application is running.
Note: This item is not shown when the |
CPid |
For client/server connections, the operating system process ID of the application.
Note: This item is not shown when the |
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. |
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
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
The dbUnload command unloads the specified database from memory.
ttGridAdmin dbUnload name [-nowait | -wait [timeout]] [-force]
Important:
If adbUnload 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.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 The In a large grid, it is not typical or generally advisable to use |
-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 |
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)
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.
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.
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 |
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
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.
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 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 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 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 |
For the first management instance of the grid being created, path to the directory where the Oracle Wallet with cryptographic information 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. |
% 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
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.
Use the gridDisplay command to display information about the grid.
ttGridAdmin gridDisplay
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.4.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
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]
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 |
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]
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. |
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 |
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.)
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 files from the DataStore directory of each element, as specified in the database definition
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]
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. |
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 ...
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.
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 usinggridSshConfig.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. |
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
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).
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.
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]
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 |
-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 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 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 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 Note: Once a host is assigned to a data space group and |
-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 |
-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 Note: Physical group assignments are considered by the |
-nophysicalgroup |
Specifies that the host will be associated with no physical groups. This is the default.
Also see - |
-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 |
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. |
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
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.
The hostDelete command removes a host from the model.
ttGridAdmin hostDelete name
[-cascade]
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. |
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
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
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 |
-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 |
-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:
|
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% /
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.
The hostList command lists information about hosts in the specified version of the model.
ttGridAdmin hostList [-latest|-current|-version n]
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. |
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
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]
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 group1 [group2 [group3 [...]]] |
Adds the specified physical groups to the groups the host is associated with.
Also see |
-removephysicalgroup group1 [group2 [group3 [...]]] |
Removes the specified physical groups from the groups the host is associated with.
Also see |
-nophysicalgroup |
Specifies that the host will not be associated with any physical groups, removing any prior associations.
Also see |
-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. |
% ttGridAdmin hostModify mysyshost2 -physicalGroup location3 -comment "Move from location1." Host mysyshost2 modified in Model
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.
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".
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
|
% 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.
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 database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.
The dbExportDelete command deletes the specified database export.
ttGridAdmin dbExportDelete -repository reponame -name exportname
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. |
This example deletes the export created in "Export a database (dbExport)".
% ttGridAdmin dbExportDelete -repository repo1 -name exp_db1 Export exp_db1 deleted
The dbExportStatus command shows the status of a database export or exports previously started.
ttGridAdmin dbExportStatus dbname [-name exportname]
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. |
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
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.
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] [-numThreads num]
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. |
-numThreads num |
Restore database objects in parallel using the specified number of threads.
Valid values are 1 through 32. The default value is 4. |
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.
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 database" in Oracle TimesTen In-Memory Database Scaleout User's Guide.
The dbImportStatus command shows the status of a database import previously started.
ttGridAdmin dbImportStatus dbname [-name exportname]
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). |
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
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.
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.
The installationCreate command defines a TimesTen installation in the model.
ttGridAdmin installationCreate hostname[.installname] -location path [-source where] [-comment comment]
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 If The default is the location of the installation associated with the active management instance, from which 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. |
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.4.1.0 Installation installcreate2 on Host mysys4host created in Model
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.
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]
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. |
In this example, installcreate2 is the only installation on the host.
% ttGridAdmin installationDelete mysys4host Installation installcreate2 on Host mysys4host deleted from Model
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.
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:
|
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% /
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.
The installationList command lists all TimesTen installations in the model.
ttGridAdmin installationList [-latest|-current|-version n]
[-instance]
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. |
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.4.1.0/ mysys2host installation1 /sw/tten/grid/ttinstls/myinstl/tt18.1.4.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.4.1.0/ mysys2host installation1 gridmgmt1 /sw/tten/grid/ttinstls/myinstl/tt18.1.4.1.0/
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
% 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.
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.
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]
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. |
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
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.
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. |
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)".
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.
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]
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 |
For the instance being crated, 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. |
% ttGridAdmin instanceCreate mysys3host.griddata1 -location /sw/tten/grid/ttinstances -daemonPort 20000 -csPort 21000 Instance griddata1 on Host mysys3host created in Model
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.
The instanceDelete command deletes an instance from the model.
ttGridAdmin instanceDelete hostname[.instancename]
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. |
In this example, griddata1 is the only instance on the host.
% ttGridAdmin instanceDelete mysys3host Instance griddata1 on Host mysys3host deleted from Model
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.
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
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 |
-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:
|
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.
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.
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]
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. |
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
The instanceModify command modifies an existing instance object in the model.
ttGridAdmin instanceModify hostname[.instancename] [-installation name] [-mgmtPort n] [-comment comment]
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. |
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.)
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.
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 runttGridAdmin. (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.
The mgmtActiveStart command starts the current management instance (from which the command is run) as the active management instance.
ttGridAdmin mgmtActiveStart
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.
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.
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]
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 |
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.
The mgmtExamine command examines the management instances and recommends any necessary corrective action. Run the suggested commands.
ttGridAdmin mgmtExamine
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
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.
The mgmtStandbyStop command stops the standby management instance.
ttGridAdmin mgmtStandbyStop
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.
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.)
% 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.)
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 thegridCreate -membershipConfig option. See "Create a grid (gridCreate)".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]
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. |
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)".
The membershipConfigImport command has the option:
| Option | Description |
|---|---|
filepath |
The path and name of the file that contains the new membership configuration. |
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
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.
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.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]
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. |
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.)
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.
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]
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. |
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"
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
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. |
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
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]
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 |
filepath |
Path and name of the JSON file from which the representation of the model is read.
If |
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!
The modelList command lists the versions of the model, indicating when each was defined, applied, and deleted, as applicable.
ttGridAdmin modelList
% 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
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.
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]
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. |
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)
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.The SQLNetImport command has the option:
| Option | Description |
|---|---|
filepath |
Path and name of the file containing sqlnet.ora configuration to import. |
% ttGridAdmin SQLNetImport /tmp/sqlnet.ora SQLNet configuration file /tmp/sqlnet.ora imported
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]
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. |
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)
)
)
...
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
The TNSNamesImport command has the option:
| Option | Description |
|---|---|
filepath |
Path and name of the file containing TNS entries to import. |
% ttGridAdmin TNSNamesImport /tmp/tnsnames.ora TNSNames configuration file /tmp/tnsnames.ora imported
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.
Use the ttGridAdmin commands in this section to define or delete a physical group or to list physical groups in the model.
The physicalCreate command defines a physical group in the model.
ttGridAdmin physicalCreate name [-comment comment]
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. |
% 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.
The physicalDelete command removes a physical group from the model.
ttGridAdmin physicalDelete name
The physicalDelete command has the option:
| Option | Description |
|---|---|
name |
The name of the physical group to delete. |
% ttGridAdmin physicalDelete location1 PhysicalGroup location1 deleted. % ttGridAdmin physicalDelete location2 PhysicalGroup location2 deleted.
The physicalList command lists all physical groups that are defined in the specified version of the model.
ttGridAdmin physicalList [-latest|-current|-version n]
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. |
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
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.
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]
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 For |
-method mount|scp |
Indicates how grid instances access the repository. Supported options are mount or scp.
Note: The |
-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". |
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
The repositoryCreate command creates a new repository that will be available for the grid.
ttGridAdmin repositoryCreate name -path path -method mount|scp [-address internalAddress]
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 For |
-method mount|scp |
Indicates how grid instances access the repository. Supported options are mount or scp.
Note: If you will later use |
-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". |
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.
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.
The repositoryDetach command detaches (disassociates) a repository from the grid, so that it will no longer be usable from the grid.
ttGridAdmin repositoryDetach name
The repositoryDetach command has the option:
| Option | Description |
|---|---|
name |
Name of the repository to detach (as established when it was attached or created). |
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]]
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). |
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
The ttGridRollout utility, run from the installation_dir/tt18.1.4.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.
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.
ttGridRollout [-h | -help | -?] ttGridRollout [-n | -dry-run] [-wait n] [-timeout n] conf_file
ttGridRollout has the options:
| Option | Description |
|---|---|
-h
|
Displays help information. |
conf_file |
Specifies the configuration file that contains the parameters for creating the grid and database.
A read-only template, |
-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".
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 Do not use both If you do not specify enough hosts for an This parameter supports the attributes Specifying address(es) is required—either 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 |
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 This parameter supports the attributes The shape of the grid is determined by your Specifying address(es) is required—either 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:
|
dbdef_file |
Database definition file (.dbdef). This is required.
Directories are created on each host as necessary for the 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.4.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 This location is used throughout the grid, except where you override it for a particular host or instance by setting the |
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 |
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 |
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 This parameter supports the attributes Specifying address(es) is required—either Example:
mgmt_instances = [
{ "internalAddress":"tthost1-priv",
"externalAddress":"tthost1.example.com" },
{ "internalAddress":"tthost2-priv",
"externalAddress":"tthost2.example.com" }
]
Notes:
|
shape |
The desired shape of the grid, NxK, where:
Either specify When you specify Notes:
|
sqlnet_config |
SQL*Net configuration file (used in communicating with an Oracle database through ttLoadFromOracle, OCI, Pro*C/C++, or ODP.NET).
Through the |
tnsnames_config |
TNS names configuration file (used in communicating with an Oracle database through ttLoadFromOracle, OCI, Pro*C/C++, or ODP.NET).
Through the |
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, |
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 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, If this is not specified for a management instance, |
daemonport |
Port for TimesTen daemon communications.
If this is not specified for a data instance, If this is not specified for a management instance, |
dataSpaceGroup |
Desired data space group (1 or 2). The default is data space group 1.
If you use the |
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 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 |
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, Alternatively, for management instances, |
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 Also see "Address formats". |
mgmtport |
Port for management instance communications.
If this is not specified, |
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 ...