1. Installation, Migration, and Upgrade Guide
  2. Upgrades in TimesTen Classic
  3. Performing an Online Upgrade with Classic Replication

Performing an Online Upgrade with Classic Replication

This section describes how to use the TimesTen replication feature to perform online upgrades for applications that require continuous data availability.

This procedure is for classic replication in a unidirectional, bidirectional, or multidirectional scenario.

Typically, applications that require high availability of their data use TimesTen replication to keep at least one extra copy of their databases up to date. An online upgrade works by keeping one of these two copies available to the application while the other is being upgraded. The procedures described in this section assume that you have a bidirectional replication scheme configured and running for two databases, as described in Unidirectional or Bidirectional Replication in the Oracle TimesTen In-Memory Database Replication Guide.

Note the following:

The following sections describe how to perform an online upgrade with replication.

Requirements

To perform online upgrades with replication, replication must be configured to use static ports. See Port Assignments in Oracle TimesTen In-Memory Database Replication Guide for information.

Additional disk space must be allocated to hold a backup copy of the database made by the ttMigrate utility. The size of the backup copy is typically about the same as the in-use size of the database. This size may be determined by querying the v$monitor view, using ttIsql: 

Command> SELECT perm_in_use_size FROM v$monitor;

Upgrade Steps

The following steps illustrate how to perform an online upgrade while replication is running. The upgrade host is the host on which the database upgrade is being performed, and the active host is the host containing the database to which the application remains connected.

Step Upgrade host Active host

1.

Configure replication to replicate to the active host using static ports.

Configure replication to replicate to the upgrade host using static ports.

2.

n/a

Connect all applications to the active database, if they are not connected.

3.

Disconnect all applications from the database that will be upgraded.

n/a

4.

n/a

Set replication to the upgrade host to the PAUSE state.

5.

Wait for updates to propagate to the active host.

n/a

6.

Stop replication.

n/a

7.

Back up the database with ttMigrate -c and run ttDestroy to destroy the database.

n/a

8.

Stop the TimesTen daemon for the old release.

n/a

9.

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.

n/a

10.

Create a DSN for the post-upgrade database for the new release. Adjust parallelism options for the DSN.

n/a

11.

Restore the database from the backup with ttMigrate -r.

n/a

12.

Clear the replication bookmark and logs using ttRepAdmin -receiver -reset and by setting replication to the active host to the stop and then the start state.

n/a

13.

Start replication.

n/a

14.

n/a

Set replication to the upgrade host to the start state, ensuring that the accumulated updates propagate once replication is restarted.

15.

n/a

Start replication.

16.

n/a

Wait for all of the updates to propagate to the upgrade host.

17.

Reconnect all applications to the post-upgrade database.

n/a

After the above procedures are completed on the upgrade host, the active host can be upgraded using the same steps.

Online Upgrade Example

This section describes how to perform an online upgrade in a scenario with two bidirectionally replicated databases.

In the following discussion, the two hosts are referred to as the upgrade host, on which the instance (with its databases) is being upgraded, and the active host, which remains operational and connected to the application for the duration of the upgrade. After the procedure is completed, the same steps can be followed to upgrade the active host. However, you may prefer to delay conversion of the active host to first test the upgraded instance.

The upgrade host in this example consists of the database upgrade on the server upgradehost. The active host consists of the database active on the server activehost.

Follow these steps in the order they are presented:

Step Upgrade host Active host

1.

Use ttIsql to alter the replication scheme repscheme, setting static replication port numbers so that the databases can communicate across releases:

Command> call ttRepStop;

Command> ALTER REPLICATION repscheme ALTER STORE upgrade ON upgradehost SET PORT 40000 ALTER STORE active ON activehost SET PORT 40001;

Command> call ttRepStart;

Use ttIsql to alter the replication scheme repscheme, setting static replication port numbers so that the databases can communicate across releases:

Command> call ttRepStop;

Command> ALTER REPLICATION repscheme ALTER STORE upgrade ON upgradehost SET PORT 40000 ALTER STORE active ON activehost SET PORT 40001;

Command> call ttRepStart;

2.

Disconnect all production applications connected to the database. Any workload being run on the upgrade host must start running on the active host instead.

Use the ttRepAdmin utility to pause replication from the database active to the database upgrade: 

ttRepAdmin -receiver -name upgrade
 -state pause active

This command temporarily stops the replication of updates from the database active to the database upgrade, but it retains any updates made to active in the database transaction log files. The updates made to active during the upgrade procedure are applied later, when upgrade is brought back up.

See Set the Replication State of Subscribers in Oracle TimesTen In-Memory Database Replication Guide for details.

3.

Wait for all replication updates to be sent to the database active. You can verify that all updates have been sent by applying a recognizable update to a table reserved for that purpose on the database upgrade. When the update appears in the database active, you know that all previous updates have been sent.

For example, call the ttRepSubscriberWait built-in procedure. You should expect a value of <00> to be returned, indicating there was a clean response, not a time out. (If there is a time out, ttRepSubscriberWait returns a value of 01.) 

Command> call ttRepSubscriberWait (,,,,60);
< 00 >
1 row found.

See ttRepSubscriberWait in the Oracle TimesTen In-Memory Database Reference for information.

n/a

4.

Stop the replication agent with ttAdmin: 

ttAdmin -repStop upgrade

From this point on, no updates are sent to the database active.

Stop the replication agent with ttAdmin: 

ttAdmin -repStop active

From this point on, no updates are sent to the database upgrade.

See Starting and Stopping the Replication Agents in Oracle TimesTen In-Memory Database Replication Guide for details.

5.

Use ttMigrate to back up the database upgrade. If the database is very large, this step could take a significant amount of time. If sufficient disk space is free on the /backup file host, use the following ttMigrate command: 

ttMigrate -c upgrade /backup/upgrade.dat

n/a

6.

If the ttMigrate command is successful, destroy the database upgrade. 

ttDestroy upgrade

Restart the replication agent on the database active: 

ttAdmin -repStart active

7.

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.

Resume replication from active to upgrade by setting the replication state to start: 

ttRepAdmin -receiver -name upgrade
 -start start active

8.

Use ttMigrate to load the backup created in step 5. into the database upgrade for the new release: 

ttMigrate -r upgrade /backup/upgrade.dat
Change the ramPolicy to manual (The ramPolicy is set to inUse by default).
ttAdmin -ramPolicy manual upgrade
ttAdmin -ramLoad upgrade

Note: In this step, you must use the ttMigrate utility contained inthe new release of to which you are upgrading.

n/a

9.

Use ttRepAdmin to clear the replication bookmark and logs by resetting the receiver state for the database active and then setting replication to the stop state and then the start state: 

ttRepAdmin -receiver -name active
   -reset upgrade
ttRepAdmin -receiver -name active
   -state stop upgrade
sleep 10
ttRepAdmin -receiver -name active
   -state start upgrade
sleep 10

Note: The sleep command is to ensure that each state takes effect, as the state change can take up to 10 seconds depending on the resources and operating system.

n/a

10.

Use ttAdmin to start the replication agent on the new database upgrade and to begin sending updates to the database active: 

ttAdmin -repStart upgrade

n/a

11.

Verify that the database upgrade is receiving updates from the database active. You can verify that updates are sent by applying a recognizable update to a table reserved for that purpose in the database active. When the update appears in upgrade, you know that replication is operational.

If the applications are still running on the database active, let them continue until the database upgrade has been successfully migrated and you have verified that the updates are being replicated correctly from active to upgrade.

12.

n/a

Once you are sure that updates are replicated correctly, you can disconnect all of the applications from the database active and reconnect them to the database upgrade. After verifying that the last of the updates from active are replicated to upgrade, the instance with active is ready to be upgraded.

Note: You may choose to delay upgrading the instance with active to the new release until sufficient testing has been performed with the database upgrade in the new release. When you are ready to upgrade the instance with the active to the new release, follow the steps in Online Patch Upgrade for Active Master for details.