When you set up a replication scheme or administer a recovery, a common task is
to duplicate a database. Use the
-duplicate option of the
ttRepAdmin utility or the
C function to duplicate a database.
To duplicate a database, these conditions must be fulfilled:
The instance administrator performs the duplicate operation.
The instance administrator user name must be the same on both instances involved in the duplication.
You must provide the user name and password for a user with the
ADMINprivilege on the source database.
You must use the
-keepCGoption when duplicating an active master database that has cache groups and provide the cache administration username and password.
The target DSN cannot include client/server attributes.
Preallocate attribute to ensure that there is sufficient
space for the new database. If enabled, then TimesTen preallocates space on the file
system for the database checkpoint files for the new database during the duplicate.
See Preallocate in the Oracle TimesTen In-Memory Database
On the source database, create a user and grant the
ADMIN privilege to the user:
Command> CREATE USER ttuser IDENTIFIED BY ttuser; User created. Command> GRANT ADMIN TO ttuser;
Assume the user name of the instance administrator is
timesten. Logged in as
timesten on the target host, duplicate the
dsn1 database on
ttRepAdmin -duplicate -from dsn1 -host host1 dsn2 Enter internal UID at the remote datastore with ADMIN privileges: ttuser Enter password of the internal Uid at the remote datastore:
ttuser when prompted for the password of the internal user at the remote database.
The following sections describe options when duplicating:
Duplicating Over a Specific Network Interface
If you want to use a specific local or remote network interface over which the database duplication occurs, you can optionally specify either by providing an alias or the IP address of the network interface.
You can specify the local and remote network interfaces for the source and
target hosts by using the
ttRepAdmin -duplicate. If you do not specify one or both
network interfaces, TimesTen Classic chooses them.
Duplicating With Cache Groups
If you are duplicating an active database that has defined cache groups, use the
You must also specify the cache administration user name and password with the
-cachePwd options. If you do not provide the
cache administration user password,
ttRepAdmin prompts for a password. If the
cache administration user name is
orauser and the password is
orapwd, duplicate database
ttRepAdmin -duplicate -from dsn1 -host host1 -keepCG -connStr "DSN=dsn2;UID=;PWD=" Enter internal UID at the remote datastore with ADMIN privileges: ttuser Enter password of the internal Uid at the remote datastore:
ttuser when prompted for the password. The
ttRepAdmin utility then prompts for the cache administration user and password:
Enter cache administrator UID: orauser Enter cache administrator password:
orapwd when prompted for the cache administration password.
dsn2 are specified as null values in the connection string so that the connection is made as the current OS user, which is the instance administrator. Only the instance administrator can run
ttRepAdmin -duplicate. If
dsn2 is configured with
PWDCrypt instead of
PWD, then the connection string should be
When you duplicate a standby database with cache groups to a read-only subscriber, use the
-nokeepCG option. In this example,
dsn2 is the standby database and
sub1 is the read-only subscriber:
ttRepAdmin -duplicate -from dsn2 -host host2 -nokeepCG -connStr "DSN=sub1;UID=;PWD="
ttRepAdmin utility prompts for values for
If you cannot access the Oracle database (either the Oracle database is down or you cannot connect to it) while performing a duplicate for a replication scheme with AWT cache groups or cache groups with incremental autorefresh, then the
ttRepAdmin -duplicate command cannot update the metadata on the Oracle database (that cache uses to manage AWT cache groups and cache groups with autorefresh) after AWT cache groups or cache groups with incremental autorefresh are duplicated. In this case, use one of the following options to perform the duplicate:
If you are using
ttRepAdmin -duplicateto recover either a failed active or standby master where all AWT cache groups or cache groups with incremental autorefresh are included in the active standby pair replication scheme, then use the
-keepCG -recoveringNodeoptions. When this option is used, changes that occur during the duplicate operation are tracked and so may not need to initiate a full autorefresh.
Otherwise, use the
-keepCG -deferCacheUpdateoptions. This option may initiate a full autorefresh.
After completion of the duplicate operation with either
-keepCG -recoveringNode options or
-keepCG -deferCacheUpdate options, warning messages are posted informing you that while the duplicate operation was successful, updates to the Oracle database metadata are deferred until the cache and replication agents are started. Thus, once the duplicate operation is complete, start both the cache and replication agents on the new node. If there are cascading TimesTen node failures and intermittent connectivity problems with the Oracle database, then starting the cache and replication agents may initiate a full autorefresh.