Duplicating a Database
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 ttRepDuplicateEx
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
ADMIN
privilege on the source database. -
You must use the
-keepCG
option 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.
Note:
Enable the 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
Reference.
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 host1
to dsn2
:
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:
Enter ttuser
when prompted for the password of the internal user at the remote database.
See ttRepAdmin in Oracle TimesTen In-Memory Database Referenceand ttRepDuplicateEx in Oracle TimesTen In-Memory Database C Developer's Guide.
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 -localIP
and -remoteIP
options of 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
-keepCG
option.
You must also specify the cache administration user name and password with the
-cacheUid
and -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 dsn1
on host1
:
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:
Enter 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:
Enter orapwd
when prompted for the cache administration password.
The UID
and PWD
for 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 "DSN=dsn2;UID=;PWDCrypt="
.
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="
The ttRepAdmin
utility prompts for values for -uid
and -pwd
.
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 -duplicate
to 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 -recoveringNode
options. 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 -deferCacheUpdate
options. 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.