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:
-
Upgrades for Multiple Active Standby Pairs on Many Pairs of Hosts
-
Upgrades for Multiple Active Standby Pairs on a Pair of Hosts
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.
Perform an Upgrade for the Standby Database
Complete these steps for an offline upgrade of the instance for the standby database.
- Create a new installation. See "Creating an Installation on Linux/UNIX" for information.
- Point the instance to the new installation. See "Associate an Instance with a Different Installation (Upgrade or Downgrade)" for details.
- Configure the new installation for Oracle Clusterware.
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
See "Perform an Upgrade for the Standby Database" for the steps.
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 follows](img/upgrade.png)
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.
- Verify that the standby databases run on the desired host. Use the
ttCWAdmin -status -dsn
DSN
command and thettCWAdmin -status
command. - Modify the Oracle Clusterware
stop
commands to stop all Master processes on the host where all the standby databases reside. - Modify the Oracle Clusterware
start
commands to start all Master processes on the host where all the standby databases reside.
The following subsections contain related samples.
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