Performing an Online TimesTen Upgrade When Using Oracle Clusterware

This section discusses the steps for an online upgrade of TimesTen when using TimesTen with Oracle Clusterware. Since TimesTen replication with Oracle Clusterware is not supported on Oracle Linux for Arm systems, the information in this section is not applicable if you are using Oracle Linux for Arm.

The section discusses how to perform an online rolling upgrade (patch) for TimesTen, from TimesTen 22.1.w.x to 22.1.y.z, in a configuration where Oracle Clusterware manages active standby pairs. (See Performing an Offline TimesTen Upgrade when Using Oracle Clusterware for an offline upgrade.)

The following topics are covered:

Refer to Oracle TimesTen In-Memory Database Release Notes for supported versions of Oracle Clusterware.

Supported Configurations

The following basic configurations are supported for online rolling upgrades for TimesTen. In all cases, Oracle Clusterware manages the hosts.

  • One active standby pair on two hosts.

  • Multiple active standby pairs with one database on each host.

  • Multiple active standby pairs with one or more database on each host.

(Other scenarios, such as with additional spare hosts, are effectively equivalent to one of these scenarios.)

Restrictions and Assumptions

Note the following assumptions for upgrading TimesTen when using Oracle Clusterware:

  • The existing active standby pairs are configured and operating properly.

  • Oracle Clusterware commands are used correctly to stop and start the standby database.

  • The upgrade does not change the TimesTen environment for the active and standby databases.

  • These instructions are for TimesTen patch upgrades only. Online major upgrades are not supported in configurations where Oracle Clusterware manages active standby pairs.

  • There are at least two hosts managed by Oracle Clusterware.

    Multiple active or standby databases managed by Oracle Clusterware can exist on a host only if there are at least two hosts in the cluster.

Note:

Upgrade Oracle Clusterware if desired, but not concurrently with an online TimesTen upgrade. When performing an online TimesTen patch upgrade in configurations where Oracle Clusterware manages active standby pairs, you must perform the Clusterware upgrade independently and separately, either before or after the TimesTen upgrade.

Upgrade Tasks for One Active Standby Pair

This section describes the following tasks:

Note:

In examples in the following subsections, the host name is host2, the DSN is myDSN, the instance name is upgrade2, and the instance administrator is terry.

Verify an Active Standby Pair Is Operating Properly

Complete these steps to confirm that the active standby pair is operating properly.

  1. Verify the following.
    • The active and the standby databases run a TimesTen 22.1.w.x release.

    • The active and standby databases are on separate hosts managed by Oracle Clusterware.

    • Replication is working.

    • If the active standby pair replication scheme includes cache groups, the following are true:

      • AWT and SWT writes are working from the standby database in TimesTen to the Oracle database.

      • Refreshes are working from the Oracle database to the active database in TimesTen.

  2. Run the ttCWAdmin -status -dsn yourDSN command to verify the following.
    • The active database is on a different host than the standby database.

    • The state of the active database is 'ACTIVE' and the status is 'AVAILABLE'.

    • The state of the standby database is 'STANDBY' and the status is 'AVAILABLE'.

  3. Run the ttStatus command on the active database to verify the following.
    • The ttCRSactiveservice and ttCRSmaster processes are running.

    • The subdaemon and the replication agents are running.

    • If the active standby pair replication scheme includes cache groups, the cache agent is running.

  4. Run the ttStatus command on the standby database to verify the following.
    • The ttCRSsubservice and ttCRSmaster processes are running.

    • The subdaemon and the replication agents are running.

    • If the active standby pair replication scheme includes cache groups, the cache agent is running.

Shut Down the Standby Database

Complete these steps to shut down the standby database.

  1. Run an Oracle Clusterware command similar to the following to obtain the names of the Oracle Clusterware Master, Daemon, and Agent processes on the host of the standby database. It is suggested to filter the output by using the grep TT command:
    crsctl status resource -n standbyHostName | grep TT
    
  2. Run Oracle Clusterware commands to shut down the standby database. The Oracle Clusterware commands stop the Master processes for the standby database, the Daemon process for the instance, and the Agent process for the instance.
    crsctl stop resource TT_Master_upgrade2_terry_myDSN_1
    crsctl stop resource TT_Daemon_upgrade2_terry_host2
    crsctl stop resource TT_Agent_upgrade2_terry_host2
    
  3. Stop the TimesTen main daemon.
    ttDaemonAdmin -stop
    

    If the ttDaemonAdmin -stop command gives error 10028, retry the command.

Perform an Upgrade for the Standby Database

Complete these steps for an offline upgrade of the instance for the standby database.

  1. Create a new installation. See "Creating an Installation on Linux/UNIX" for information.
  2. Point the instance to the new installation. See "Associate an Instance with a Different Installation (Upgrade or Downgrade)" for details.
  3. Configure the new installation for Oracle Clusterware.

Start the Standby Database

Complete these steps to start the standby database.

  1. Run the following ttCWAdmin command to start the TimesTen main daemon, the TimesTen Oracle Clusterware agent process and the TimesTen Oracle Clusterware Daemon process:
    ttCWAdmin -init -hosts localhost
    
  2. Start the Oracle Clusterware Master process for the standby database.
    crsctl start resource TT_Master_upgrade2_terry_MYDSN_1

Switch the Roles of the Active and Standby Databases

Use the ttCWAdmin -switch command to switch the roles of the active and standby databases to enable the offline upgrade on the other master database.

ttCWAdmin -switch -dsn myDSN

Use the ttCWAdmin -status command to verify that the switch operation has completed before starting the next task.

Shut Down the New Standby Database

Use the Oracle Clusterware crsctl status resource command to obtain the names of the Master, Daemon, and Agent processes on the host of the new standby database. This example assumes the host host1 and filters the output through grep TT:

crsctl status resource -n host1 | grep TT

Run commands such as those in "Shut Down the Standby Database" and use the appropriate instance name, instance administrator, DSN, and host name. For example:

crsctl stop resource TT_Master_upgrade2_terry_MYDSN_0
crsctl stop resource TT_Daemon_upgrade2_terry_host1
crsctl stop resource TT_Agent_upgrade2_terry_host1
ttDaemonAdmin -stop

Perform an Upgrade of the New Standby Database

Start the New Standby Database

See "Start the Standby Database" and use the Master process name obtained by the crsctl status resource command from "Shut Down the New Standby Database" as outlined above.

ttCWAdmin -init -hosts localhost
crsctl start resource TT_Master_upgrade2_terry_MYDSN_0

Upgrades for Multiple Active Standby Pairs on Many Pairs of Hosts

The process to upgrade the instances for multiple active standby pairs on multiple pairs of hosts is essentially the same as the process to upgrade the instances for a single active standby pair on two hosts. See "Upgrade Tasks for One Active Standby Pair" for details. The best practice is to perform the upgrades for the active standby pairs one at a time.

Use the ttCWAdmin -status command to determine the state of the databases managed by Oracle Clusterware.

Upgrades for Multiple Active Standby Pairs on a Pair of Hosts

Multiple active standby pairs can be on multiple pairs of hosts. See Upgrades for Multiple Active Standby Pairs on Many Pairs of Hosts for details. Alternatively, multiple active standby pairs can be on a single pair of hosts. One scenario is for all the active databases to be on one host and all the standby databases to be on the other. A more typical scenario, to better balance the workload, is for each host to have some active databases and some standby databases.

Figure 7-1 shows two active standby pairs on two hosts managed by Oracle Clusterware. The active database called active1 on host1 replicates to standby1 on host2. The active database called active2 on host2 replicates to standby2 on host1. AWT updates from both standby databases are propagated to the Oracle database. Read-only updates from the Oracle database are propagated to the active databases.

Figure 7-1 Multiple Active Standby Pairs on Two Hosts

Description of Figure 7-1 follows
Description of "Figure 7-1 Multiple Active Standby Pairs on Two Hosts"

This configuration can result in greater write throughput for cache groups and more balanced resource usage. See the next section, Sample Configuration Files: Multiple Active Standby Pairs on One Pair of Hosts, for sample sys.odbc.ini entries and a sample cluster.oracle.ini file for this kind of configuration. (See Configuring Oracle Clusterware Management with the cluster.oracle.ini File in the Oracle TimesTen In-Memory Database Replication Guide for information about that file.)

The rolling upgrade process for multiple active standby pairs on a single pair of hosts is similar in nature to the process of upgrading multiple active standby pairs on multiple pairs of hosts. See Upgrades for Multiple Active Standby Pairs on Many Pairs of Hosts for details.

First, however, if the active and standby databases are mixed between the two hosts, switch all standby databases to one host and all active databases to the other host. Use the ttCWAdmin -switch -dsn DSN command to switch active and standby databases between hosts. Once all the active databases are on one host and all the standby databases are on the other host, follow the steps below to perform the upgrade for the entire "standby" host.

Be aware that upgrades affect the entire instance and associated databases on one host.

  1. Verify that the standby databases run on the desired host. Use the ttCWAdmin -status -dsn DSN command and the ttCWAdmin -status command.
  2. Modify the Oracle Clusterware stop commands to stop all Master processes on the host where all the standby databases reside.
  3. Modify the Oracle Clusterware start commands to start all Master processes on the host where all the standby databases reside.

Sample Configuration Files: Multiple Active Standby Pairs on One Pair of Hosts

The following are sample sys.odbc.ini entries:

[databasea]
Driver=timesten_home/install/lib/libtten.so
DataStore=/scratch/terry/ds/databasea
PermSize=400
TempSize=320
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL
 
[databaseb]
Driver=timesten_home/install/lib/libtten.so
DataStore=/scratch/terry/ds/databaseb
PermSize=400
TempSize=320
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL

[databasec]
Driver=timesten_home/install/lib/libtten.so
DataStore=/scratch/terry/ds/databasec
PermSize=400
TempSize=320
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL

[databased]
Driver=timesten_home/install/lib/libtten.so
DataStore=/scratch/terry/ds/databased
PermSize=400
TempSize=320
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL

The following is a sample cluster.oracle.ini file:

[databasea]
MasterHosts=host1,host2
CacheConnect=Y
 
[databaseb]
MasterHosts=host2,host1
CacheConnect=Y
 
[databasec]
MasterHosts=host2,host1
CacheConnect=Y
 
[databased]
MasterHosts=host1,host2
CacheConnect=Y

The cluster.oracle.ini file places one active database and one standby database on each host. This is accomplished by reversing the order of the host names specified for the MasterHost attribute.

Sample Scripts: Stopping and Starting Multiple Standby Processes on One Host

Run an Oracle Clusterware command similar to the following to obtain the names of the Oracle Clusterware Master, Daemon and Agent processes on the host of the standby database. It is suggested to filter the output by using the grep TT:

crsctl status resource -n standbyHostName | grep TT

The following script is an example of a "stop standby" script for multiple databases on the same host that Oracle Clusterware manages. The instance name is upgrade2. The instance administrator is terry. The host is host2. There are two standby databases: databasea and databaseb.

crsctl stop resource TT_Master_upgrade2_terry_DATABASEA_0
crsctl stop resource TT_Master_upgrade2_terry_DATABASEB_1
crsctl stop resource TT_Daemon_upgrade2_terry_HOST2
crsctl stop resource TT_Agent_upgrade2_terry_HOST2
ttDaemonAdmin -stop

The following script is an example of a "start standby" script for the same configuration.

ttCWAdmin -init -hosts localhost
crs start resource TT_Master_upgrade2_terry_DATABASEA_0
crs start resource TT_Master_upgrade2_terry_DATABASEB_1