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.