Performing an Upgrade with Active Standby Pair Replication

Active standby pair replication provides high availability of your data to your applications. With active standby pairs, unless you want to perform an upgrade to a new major release in a configuration that also uses asynchronous writethrough cache groups, you can perform an online upgrade to maintain continuous availability of your data during an upgrade. This section describes the following procedures:

Note:

Only asynchronous writethrough or read-only cache groups are supported with active standby pairs.

Online Upgrades for an Active Standby Pair with No Cache Groups

This section includes the following topics for online upgrades in a scenario with active standby pairs and no cache groups:

Also see "Performing an Online Upgrade with Classic Replication" for an overview, limitations, and requirements.

Online Patch Upgrade for Standby Master and Subscriber

To perform an online upgrade to a new patch release for the standby master database and subscriber databases, complete the following tasks on each database. For this procedure, assume there are no cache groups.

Stop the replication agent on the database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the master2 standby database:
```
ttAdmin -repStop master2
```
Create a new installation and a new instance for the new release. See "Creating an Installation on Linux/UNIX" and "Creating an Instance on Linux/UNIX: Basics" for information.
Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:
```
ttAdmin -repStart master2
```

Online Patch Upgrade for Active Master

To perform an online upgrade to a new patch release for the active master database, you must first reverse the roles of the active and standby master databases, then perform the upgrade. For this procedure, assume there are no cache groups.

Pause any applications that are generating updates on the active master database.
Run the ttRepSubscriberWait built-in procedure on the active master database, using the DSN and host of the standby master database. (The result of the call should be 00. If the value is 01, you should call ttRepSubscriberWait again until the value 00 is returned.) For example, to ensure that all transactions are replicated to the master2 standby master on the master2host:
```
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
```
Stop the replication agent on the current active master database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the master1 active master database:
```
ttAdmin -repStop master1
```
Execute the ttRepDeactivate build-in procedure on the current active master database. This puts the database in the IDLE state:
```
call ttRepDeactivate;
```
On the standby master database, set the database to the ACTIVE state using the ttRepStateSet built-in procedure. This database becomes the active master in the active standby pair:
```
call ttRepStateSet( 'ACTIVE' );
```
Resume any applications that were paused in step 1, connecting them to the database that is now acting as the active master (for example, master2).

Note:

At this point, replication will not yet occur from the new active database to subscriber databases. Replication will resume after the host for the new standby database has been upgraded and the replication agent of the new standby database is running.
Upgrade the instance of the former active master database, which is now the standby master database. See About Performing a Basic Patch Upgrade for details.
Restart replication on the database in the upgraded instance, using the ttRepStart built-in procedure or the ttAdmin utility:
```
ttAdmin -repStart master2
```
To make the database in the newly upgraded instance the active master database again, see Reversing the Roles of the Active and Standby Databases in the Oracle TimesTen In-Memory Database Replication Guide.

Online Major Upgrade for Active Standby Pair

When you perform an online upgrade for an active standby pair to a new major release of TimesTen, you must explicitly specify the TCP/IP port for each database. If your active standby pair replication scheme is not configured with a PORT attribute for each database, you must use the following steps to prepare for the upgrade. For this procedure, assume there are no cache groups. (Online major upgrades for active standby pairs with cache groups are only supported for read-only cache groups.)

Stop the replication agent on every database using the call ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent on the master1 database:
```
ttAdmin -repStop master1
```
On the active master database, use the ALTER ACTIVE STANDBY PAIR statement to specify a PORT attribute for every database in the active standby pair. For example, to set a PORT attribute for the master1 database on the master1host host and the master2 database on the master2host host and the subscriber1 database on the subscriber1host host:
```
ALTER ACTIVE STANDBY PAIR
 ALTER STORE master1 ON "master1host" SET PORT 30000
 ALTER STORE master2 ON "master2host" SET PORT 30001
 ALTER STORE subscriber1 ON "subscriber1host" SET PORT 30002;
```
Destroy the standby master database and all of the subscribers using the ttDestroy utility. For example, to destroy the subscriber1 database:
```
ttDestroy subscriber1
```
Follow the normal procedure to start an active standby pair and duplicate the standby and subscriber databases from the active master. See Setting Up an Active Standby Pair with No Cache Groups in the Oracle TimesTen In-Memory Database Replication Guide for details.

To upgrade the instances of the active standby pair, first upgrade the instance of the standby master. While this node is being upgraded, there is no standby master database, so updates on the active master database are propagated directly to the subscriber databases. Following the upgrade of the standby node, the active and standby roles are switched and the new standby node is created from the new active node. Finally, the subscriber nodes are upgraded.

Instruct the active master database to stop replicating updates to the standby master by executing the ttRepStateSave built-in procedure on the active master database. For example, to stop replication to the master2 standby master database on the master2host host:
```
call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
```
Stop the replication agent on the standby master database using the ttRepStop built-in procedure or the ttAdmin utility. The following example stops the replication agent for the master2 standby master database.
```
ttAdmin -repStop master2
```
Use the ttMigrate utility to back up the standby master database to a binary file.
```
ttMigrate -c master2 master2.bak
```
See ttMigrate in the Oracle TimesTen In-Memory Database Reference for details.
Destroy the standby master database, using the ttDestroy utility.
```
ttDestroy master2
```
Create a new installation and a new instance on the master2host standby master host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
In the new instance on master2host, use ttMigrate to restore the standby master database from the binary file created earlier. (This example performs a checkpoint operation after every 20 megabytes of data has been restored.)
```
ttMigrate -r -C 20 master2 master2.bak
```
Start the replication agent on the standby master database using the ttRepStart built-in procedure or the ttAdmin utility.
```
ttAdmin -repStart master2
```
When the standby master database in the upgraded instance has become synchronized with the active master database, this standby master database moves from the RECOVERING state to the STANDBY state. The standby master database also starts sending updates to the subscribers. You can determine when the standby master database is in the STANDBY state by calling the ttRepStateGet built-in procedure.
```
call ttRepStateGet;
```
Pause any applications that are generating updates on the active master database.
Execute the ttRepSubscriberWait built-in procedure on the active master database, using the DSN and host of the standby master database. (The result of the call should be 00. If the value is 01, you should call ttRepSubscriberWait again until the value 00 is returned.) For example, to ensure that all transactions are replicated to the master2 standby master on the master2host host:
```
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
```
Stop the replication agent on the active master database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the master1 active master database:
```
ttAdmin -repStop master1
```
On the standby master database, set the database to the ACTIVE state using the ttRepStateSet built-in procedure. This database becomes the active master in the active standby pair.
```
call ttRepStateSet( 'ACTIVE' );
```
Instruct the new active master database (master2, in our example) to stop replicating updates to what is now the standby master (master1) by executing the ttRepStateSave built-in procedure on the active master database. For example, to stop replication to the master1 standby master database on master1host host:
```
call ttRepStateSave( 'FAILED', 'master1', 'master1host' );
```
Destroy the former active master database, using the ttDestroy utility.
```
ttDestroy master1
```
Create the new installation and the instance for the new release on master1host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
Create a new standby master database by duplicating the new active master database, using the ttRepAdmin utility. For example, to duplicate the master2 database master2 on the master2host host to the master1 database, use the following on the host containing the master1 database:
```
ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd
 -setMasterRepStart master1
```
Start the replication agent on the new standby master database using the ttRepStart built-in procedure or the ttAdmin utility.
```
ttAdmin -repStart master1
```
Stop the replication agent on the first subscriber database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the subscriber1 subscriber database:
```
ttAdmin -repStop subscriber1
```
Destroy the subscriber database using the ttDestroy utility.
```
ttDestroy subscriber1
```
Create a new installation and a new instance for the new release on the subscriber host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
Create the subscriber database by duplicating the new standby master database, using the ttRepAdmin utility, as follows.
```
ttRepAdmin -duplicate -from master1 -host master1host -uid pat -pwd patpwd
 -setMasterRepStart subscriber1
```
Start the replication agent for the duplicated subscriber database using the ttRepStart built-in procedure or the ttAdmin utility.
```
ttAdmin -repStart subscriber1
```
Repeat step 17 through step 21 for each other subscriber database.

Online Upgrades for an Active Standby Pair with Cache Groups

This section includes the following topics for online patch upgrades in a scenario with active standby pairs and cache groups:

Also see "Performing an Online Upgrade with Classic Replication" for an overview, limitations, and requirements.

Online Patch Upgrade for Standby Master and Subscriber (Cache Groups)

To perform an online upgrade to a new patch release for the standby master database and subscriber databases, in a configuration with cache groups, complete the following tasks on each database (with exceptions noted).

Stop the replication agent on the database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the master2 standby database:
```
ttAdmin -repStop master2
```
Stop the cache agent on the standby database using the ttCacheStop built-in procedure or the ttAdmin utility:
```
ttAdmin -cacheStop master2
```
Create a new installation and a new instance for the new release. See "Creating an Installation on Linux/UNIX" and "Creating an Instance on Linux/UNIX: Basics" for information.
Restart the cache agent on the standby database using the ttCacheStart built-in procedure or the ttAdmin utility:
```
ttAdmin -cacheStart master2
```
Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:
```
ttAdmin -repStart master2
```

Note:

Steps 2 and 4, stopping and restarting the cache agent, are not applicable for subscriber databases.

Online Patch Upgrade for Active Master (Cache Groups)

To perform an online upgrade to a new patch release for the active master database, in a configuration with cache groups, perform the following steps. You must first reverse the roles of the active and standby master databases, then perform an the upgrade.

Pause any applications that are generating updates on the active master database.
Stop the cache agent on the current active master database using the ttCacheStop built-in procedure or the ttAdmin utility:
```
ttAdmin -cacheStop master1
```
Execute the ttRepSubscriberWait built-in procedure on the active master database, using the DSN and host of the standby master database. For example, to ensure that all transactions are replicated to the master2 standby master on the master2host host:
```
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
```
Stop the replication agent on the current active master database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the master1 active master database:
```
ttAdmin -repStop master1
```
Execute the ttRepDeactivate build-in procedure on the current active master database. This puts the database in the IDLE state:
```
call ttRepDeactivate;
```
On the standby master database, set the database to the ACTIVE state using the ttRepStateSet built-in procedure. This database becomes the active master in the active standby pair:
```
call ttRepStateSet( 'ACTIVE' );
```
Resume any applications that were paused in step 1, connecting them to the database that is now acting as the active master (in this example, the master2 database).
Upgrade the instance for the former active master database, which is now the standby master database. See About Performing a Basic Patch Upgrade for details.
Restart the cache agent on the post-upgrade database using the ttCacheStart built-in procedure or the ttAdmin utility:
```
ttAdmin -cacheStart master1
```
Restart replication on the post-upgrade database using the ttRepStart built-in procedure or the ttAdmin utility:
```
ttAdmin -repStart master1
```
To make the post-upgrade database the active master database again, see Reversing the Roles of the Active and Standby Databases in the Oracle TimesTen In-Memory Database Replication Guide.

Online Major Upgrade for Active Standby Pair (Read Only Cache Groups)

Complete the following steps to perform a major upgrade in a scenario with an active standby pair with read-only cache groups. This example upgrades from the 18.1 release to the 22.1

These steps assume that master1 is the active master database on the master1host host and master2 is the standby master database on the master2host host.

Note:

For more information on the built-in procedures and utilities discussed here, see Built-In Procedures and Utilities in the Oracle TimesTen In-Memory Database Reference.

On the active master host, run the ttAdmin utility to stop the replication agent for the active master database.
```
ttAdmin -repStop master1
```
On the active master database, use the DROP ACTIVE STANDBY PAIR statement to drop the active standby pair. For example, from the ttIsql utility:
```
Command> DROP ACTIVE STANDBY PAIR;
```
On the active master database, use the CREATE ACTIVE STANDBY PAIR statement to create a new active standby pair with the cache groups excluded. Ensure that you explicitly specify the TCP/IP port for each database.
```
Command> CREATE ACTIVE STANDBY PAIR master1 ON "master1host",
           master2 ON "master2host"
         STORE master1 ON "master1host" PORT 20000
         STORE master2 ON "master2host" PORT 20010
         EXCLUDE CACHE GROUP cacheuser.readcache;
```
Note:

You can use the cachegroups command within the ttIsql utility to identify all the cache groups defined in the database. In this example, readcache is a read-only cache group owned by the cacheuser user.
On the active master database, call the ttRepStateSet built-in procedure to set the replication state for the active master database to ACTIVE.
```
Command> call ttRepStateSet('ACTIVE');
```
To verify that the replication state for the active master database is set to ACTIVE, call the ttRepStateGet built-in procedure.
```
Command> call ttRepStateGet();
< ACTIVE >
1 row found.
```
On the active master database, call the ttRepStart built-in procedure to start the replication agent.
```
Command> call ttRepStart();
```
On the standby master host, run the ttAdmin utility to stop the replication agent for the standby master database.
```
ttAdmin -repStop master2
```
On the standby master host, run the ttAdmin utility to stop the cache agent for the standby master database.
```
ttAdmin -cacheStop master2
```
On the standby master host, run the ttDestroy utility to destroy the standby master database. You must either add the -force option or first drop all cache groups. After you run the ttDestroy utility, run the cacheCleanUp.sql script as described below.
```
ttDestroy -force master2
```
Run the timesten_home/install/oraclescripts/cacheCleanUp.sql SQL*Plus script as the cache administration user to drop the Oracle Database objects. This script takes the host name and the database name (with full path) as parameters. See Dropping Oracle Database Objects Used by Cache Groups with Autorefresh in the Oracle TimesTen In-Memory Database Cache Guide for details.
Create a new standby master database by duplicating the active master database with the ttRepAdmin utility. For example, to duplicate the master1 database on the master1host host of the master2 database, run the following on the host containing the master2 database:
```
ttRepAdmin -duplicate -from master1 -host master1host -UID pat -PWD patpwd 
  -keepCG -cacheUid cacheuser -cachePwd cachepwd master2
```
Note:

You need a user with ADMIN privileges defined in the active master database for it to be duplicated. In this example, the pat user identified by the patpwd password has ADMIN privileges.

To keep the cache group tables, you need a cache administration user while adding the -keepCG option. In this example, the cacheuser user identified by the cachepwd password is a cache administration user.
On the new standby master database, use the DROP CACHE GROUP statement to drop all the cache groups.
```
Command> DROP CACHE GROUP cacheuser.readcache;
```
On the standby master host, run the ttMigrate utility to back up the standby master database to a binary file.
```
ttMigrate -c master2 master2.bak
```
On the standby master host, run the ttDestroy utility to destroy the standby master database. After you run the ttDestroy utility, run the cacheCleanUp.sql script as described below.
```
ttDestroy master2
```
Run the timesten_home/install/oraclescripts/cacheCleanUp.sql SQL*Plus script as the cache administration user to drop the Oracle Database objects. This script takes the host name and the database name (with full path) as parameters. See Dropping Oracle Database Objects Used by Cache Groups with Autorefresh in the Oracle TimesTen In-Memory Database Cache Guide for details.
Create a new installation and a new instance for the new release on the standby master host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
In the new instance on the standby master host, run the ttMigrate utility to restore the standby master database from the binary file created earlier.
```
ttMigrate -r -C 20 master2 master2.bak
```
Note:

This example performs a checkpoint operation after every 20 MB of data has been restored.
On the standby master database, use the CREATE USER statement to create a new cache administration user.
```
Command> CREATE USER cacheuser2 IDENTIFIED BY cachepwd;
Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE,
         DROP ANY TABLE TO cacheuser2;
```
Note:

You must create the new cache administration user in the Oracle database and grant the user the minimum set of privileges required to perform cache group operations.
Connect to the standby master database as the cache administration user, and call the ttCacheUidPwdSet built-in procedure to set the new cache administration user name and password. Ensure you specify the cache administration user password for the Oracle database in the OraclePWD connection attribute within the connection string.
```
ttIsql "DSN=master2;UID=cacheuser2;PWD=cachepwd;OraclePWD=oracle"
Command> call ttCacheUidPwdSet('cacheuser2','oracle');
```
On the standby master database, call the ttCacheStart built-in procedure to start the cache agent.
```
Command> call ttCacheStart();
```
On the standby master database, call the ttRepStart built-in procedure to start the replication agent.
```
Command> call ttRepStart();
```
The replication state will automatically be set to STANDBY. You can call the ttRepStateGet built-in procedure to confirm this. (This occurs asynchronously and may take a little time.)
```
Command> call ttRepStateGet();
< STANDBY >
1 row found.
```
On the standby master database, use the CREATE READONLY CACHE GROUP statement to create all the read-only cache groups.
```
Command> CREATE READONLY CACHE GROUP cacheuser2.readcache
         AUTOREFRESH INTERVAL 10 SECONDS
         FROM oratt.readtbl
           (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR(32));
```
Note:

Ensure that the cache administration user has SELECT privileges on the cache group tables in the Oracle database. In this example, the cacheuser2 user has SELECT privileges on the readtbl table owned by the oratt user in the Oracle database.
On the standby master database, use the LOAD CACHE GROUP statement to load the data from the Oracle database tables into the TimesTen cache groups.
```
Command> LOAD CACHE GROUP cacheuser2.readcache
         COMMIT EVERY 200 ROWS;
```
Pause any applications that are generating updates on the active master database.
On the active master database, call the ttRepSubscriberWait built-in procedure using the DSN and host of the standby master database. For example, to ensure that all transactions are replicated to the master2 database on the master2host host:
```
Command> call ttRepSubscriberWait(NULL,NULL,'master2','master2host',120);
```
On the active master database, call the ttRepStop built-in procedure to stop the replication agent.
```
Command> call ttRepStop();
```
On the active master database, call the ttRepDeactivate built-in procedure to set the replication state for the active master database to IDLE.
```
Command> call ttRepDeactivate();
```
On the standby master database, call the ttRepStateSet built-in procedure to set the replication state for the standby master database to ACTIVE. This database and its host become the active master in the active standby pair replication scheme.
```
Command> call ttRepStateSet('ACTIVE');
```
Note:

In this example, the master2 database on the master2host host just became the active master in the active standby pair replication scheme. Likewise, the master1 database on the master1host host is henceforth considered the standby master in the active standby pair replication scheme.
On the new active master database, call the ttRepStop built-in procedure to stop the replication agent.
```
Command> call ttRepStop();
```
On the active master database, use the ALTER CACHE GROUP statement to set the AUTOREFRESH mode of all cache groups to PAUSED.
```
Command> ALTER CACHE GROUP cacheuser2.readcache
         SET AUTOREFRESH STATE PAUSED;
```
On the active master database, use the DROP ACTIVE STANDBY PAIR statement to drop the active standby pair.
```
Command> DROP ACTIVE STANDBY PAIR;
```
On the active master database, use the CREATE ACTIVE STANDBY PAIR statement to create a new active standby pair with the cache groups included. Ensure you explicitly specify the TCP/IP port for each database.
```
Command> CREATE ACTIVE STANDBY PAIR master1 ON "master1host",
           master2 ON "master2host"
         STORE master1 ON "master1host" PORT 20000
         STORE master2 ON "master2host" PORT 20010;
```
On the active master database, call the ttRepStateSet built-in procedure to set the replication state for the active master database to ACTIVE.
```
Command> call ttRepStateSet('ACTIVE');
```
On the active master database, call the ttRepStart built-in procedure to start the replication agent.
```
Command> call ttRepStart();
```
Resume any applications that were paused in step 21, connecting them to the new active master database.
On the new standby master host, run the ttDestroy utility to destroy the new standby master database. After you run the ttDestroy utility, run the cacheCleanUp.sql script as described below.
```
ttDestroy master1
```
Run the timesten_home/install/oraclescripts/cacheCleanUp.sql SQL*Plus script as the cache administration user to drop the Oracle Database objects. This script takes the host name and the database name (with full path) as parameters. See Dropping Oracle Database Objects Used by Cache Groups with Autorefresh in the Oracle TimesTen In-Memory Database Cache Guide for details.
Create a new installation and a new instance for the new release on the standby master host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
Create a new standby master database by duplicating the active master database with the ttRepAdmin utility. For example, to duplicate the master2 database on the master2host host to the master1 database, run the following on the host containing the master1 database:
```
ttRepAdmin -duplicate -from master2 -host master2host -UID pat -PWD patpwd 
  -keepCG -cacheUid cacheuser2 -cachePwd cachepwd master1
```
On the standby master host, run the ttAdmin utility to start the cache agent for the standby master database.
```
ttAdmin -cacheStart master1
```
On the standby master host, run the ttAdmin utility to start the cache agent for the standby master database.
```
ttAdmin -repStart master1
```

Offline Upgrades for an Active Standby Pair with Cache Groups

Performing a major upgrade in a scenario with an active standby pair with asynchronous writethrough cache groups requires an offline upgrade. This is discussed in the subsection that follows.

Offline Major Upgrade for Active Standby Pair (Cache Groups)

Complete the following steps to perform a major upgrade in a scenario with an active standby pair with cache groups. You must perform this upgrade offline. (This example assumes you want to upgrade from release 18.1 to release 22.1

These steps assume master1 is an active master database on the master1host host and master2 is a standby master database on the master2host host. (For information about the built-in procedures and utilities discussed, refer to Built-In Procedures and Utilities in Oracle TimesTen In-Memory Database Reference.)

Stop any updates to the active database before you upgrade.
From master1, call the ttRepSubscriberWait built-in procedure to ensure that all data updates have been applied to the standby database, where numsec is the desired wait time.
```
call ttRepSubscriberWait(null, null, 'master2', 'master2host', numsec);
```
From master2, call ttRepSubscriberWait to ensure that all data updates have been applied to the Oracle database.
```
call ttRepSubscriberWait(null, null, '_ORACLE', null, numsec);
```
On master1host, use the ttAdmin utility to stop the replication agent for the active database.
```
ttAdmin -repStop master1
```
On master2host, use ttAdmin to stop the replication agent for the standby database.
```
ttAdmin -repStop master2
```
On master1host, call the ttCacheStop built-in procedure or use ttAdmin to stop the cache agent for the active database.
```
ttAdmin -cacheStop master1
```
On master2host, call ttCacheStop or use ttAdmin to stop the cache agent for the standby database.
```
ttAdmin -cacheStop master2
```
On master1host, use the ttMigrate utility to back up the active database to a binary file.
```
ttMigrate -c master1 master1.bak
```
On master1host, use the ttDestroy utility to destroy the active database. You must either use the -force option or first drop all cache groups. If you use -force, run the script cacheCleanup.sql afterward.
```
ttDestroy -force /data_store_path/master1
```
The cacheCleanup.sql script is a SQL*Plus script, located in the installation_dir/oraclescripts directory (and accessible through timesten_home/install/oraclescripts), that you run after connecting to the Oracle database as the cache user. It takes as parameters the host name and the database name (with full path). For information, refer to Dropping Oracle Database Objects Used by Cache Groups with Autorefresh in the Oracle TimesTen In-Memory Database Cache Guide.
Create a new installation and a new instance for the new major release on master1host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
Create a new database in 22.1.w.x using ttIsql with DSN connection attribute setting AutoCreate=1. In this new database, create a cache user. The following example is a sequence of commands to execute in ttIsql to create this cache user and give it appropriate access privileges.
The cache user requires ADMIN privilege to execute the next step, ttMigrate –r. Once migration is complete, you can revoke the ADMIN privilege from this user if desired.
```
Command> CREATE USER cacheuser IDENTIFIED BY cachepassword;
Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, 
         DROP ANY TABLE TO cacheuser;
Command> GRANT ADMIN TO cacheuser;
```
In the new instance on master1host, use the ttMigrate utility as the cache user to restore master1 from the binary file created earlier. (This example performs a checkpoint operation after every 20 megabytes of data has been restored, and assumes the password is the same in the Oracle database as in TimesTen.)
```
ttMigrate -r -cacheuid cacheuser -cachepwd cachepassword -C 20 -connstr
 "DSN=master1;uid=cacheuser;pwd=cachepassword;oraclepwd=cachepassword"
 master1.bak
```
On master1host, use ttAdmin to start the replication agent.
```
ttAdmin -repStart master1
```
Note:

This step also sets the database to the active state. You can then call the ttRepStateGet built-in procedure (which takes no parameters) to confirm the state.
On master1host, call the ttCacheStart built-in procedure or use ttAdmin to start the cache agent.
```
ttAdmin -cacheStart master1
```
Then you can use the ttStatus utility to confirm the replication and cache agents have started.
Put each automatic refresh cache group into the AUTOREFRESH PAUSED state. This example uses ttIsql:
```
Command> ALTER CACHE GROUP mycachegroup SET AUTOREFRESH STATE paused;
```
From master1, reload each cache group, specifying the name of the cache group and how often to commit during the operation. This example uses ttIsql:
```
Command> LOAD CACHE GROUP cachegroupname COMMIT EVERY n ROWS;
```
You can optionally specify parallel loading as well. See the LOAD CACHE GROUP SQL statement in the Oracle TimesTen In-Memory Database SQL Reference for details.
On master2host, use ttDestroy to destroy the standby database. You must either use the -force option or first drop all cache groups. If you use -force, run the script cacheCleanup.sql afterward (as discussed earlier).
```
ttDestroy -force /data_store_path/master2
```
Create the new installation and the new instance for the new major release on master2host. See Creating an Installation on Linux/UNIX and Creating an Instance on Linux/UNIX: Basics for information.
In the new instance on master2host, use the ttRepAdmin utility with the -duplicate option to create a duplicate of active database master1 to use as standby database master2. Specify the appropriate administrative user on master1, the cache manager user and password, and to keep cache groups.
```
ttRepAdmin -duplicate -from master1 -host master1host -uid pat -pwd patpwd 
-cacheUid orcluser -cachePwd orclpwd -keepCG master2
```
On master2host, use ttAdmin to start the replication agent. (You could optionally have used the ttRepAdmin option -setMasterRepStart in the previous step instead.)
```
ttAdmin -repStart master2
```
On master2, the replication state will automatically be set to STANDBY. You can call the ttRepStateGet built-in procedure to confirm this. (This occurs asynchronously and may take a little time.)
```
call ttRepStateGet();
```
On master2host, call the ttCacheStart built-in procedure or use ttAdmin to start the cache agent.
```
ttAdmin -cacheStart master2
```
After this, you can use the ttStatus utility to confirm the replication and cache agents have started.

If you want to create read-only subscriber databases, on each subscriber host you can create the subscriber by using the ttRepAdmin utility -duplicate option to duplicate the standby database. The following example creates subscriber1, using the same ADMIN user as above and the -nokeepCG option to convert the cache tables to normal TimesTen tables, as appropriate for a read-only subscriber.

ttRepAdmin -duplicate -from master2 -host master2host -nokeepCG 
-uid pat -pwd patpwd subscriber1

For related information, refer to Rolling Out a Disaster Recovery Subscriber in the Oracle TimesTen In-Memory Database Replication Guide.