3 TimesTen Upgrades

Data type considerations

This section covers data type considerations, particularly those that are relevant if you are upgrading from a version of TimesTen prior to 7.0. It discusses the following topics:

• Data type compatibility

• Data type considerations when upgrading from a TimesTen version before 7.0

ttMigrate -r -convertTypesToOra salesdata salesdata.mig

Database character set considerations

This section covers database character set considerations, including those that are relevant if you are upgrading from a version of TimesTen prior to 7.0. It discusses the following topics:

• Database character set specification

• Character set restrictions when upgrading from a TimesTen version before 7.0

• Database character set conversion

Location of existing database files

As noted in "Considerations for locations of database files and other user files", it is strongly recommended that you not store any database files or user files under the TimesTen installation path, where they may be removed during upgrade or uninstallation operations.

If, however, you do have databases under the installation directory, you can use the following general steps to move each database elsewhere:

1. Use the ttBackup utility to back up the database.

2. Use the ttDestroy utility to destroy the database.

3. Update the DSN definition for the database so that the DataStore and LogDir attributes reference a location outside of the installation path.

4. Use the ttRestore utility to restore the database to the new location.

In Oracle TimesTen In-Memory Database Reference, see "Utilities" for information about these utilities and "Connection Attributes" for information about these attributes.

Also see "Moving to a different directory".

Access control

Access control is mandatory in TimesTen beginning with release 11.2.1. If you have been using previous versions of TimesTen without access control and you do not want to initially secure your database objects after upgrading to the current release, you can grant the ADMIN system privilege to PUBLIC using the following SQL command:

GRANT ADMIN TO PUBLIC;

If you grant the ADMIN privilege to PUBLIC, all users have unrestricted access to all database objects and are able to perform all administrative tasks, except for those tasks that must be performed as the instance administrator. Granting the ADMIN privilege to PUBLIC should be viewed as a temporary workaround, for upgrade purposes only.

In-place upgrades

In-place upgrades are available on UNIX systems for moving to a new patch release of TimesTen, such as from release 11.2.2.4.0 to release 11.2.2.5.0. There are also equivalent uninstallation and installation steps you can perform on Windows systems.

To perform an in-place upgrade, use the UNIX installer option to upgrade an existing instance. The uninstallation of the old version and installation of the new version take place in a single operation. New software libraries and binaries are installed in the same location as before. If you choose default responses, existing databases will be preserved (assuming they were not located under the install_dir directory) without the necessity of using the TimesTen backup and migration utilities.

During the in-place upgrade, all applications must disconnect from databases in the TimesTen instance being upgraded.

On Windows systems, you can perform equivalent steps to move between patch releases by first uninstalling TimesTen, keeping your DSNs when prompted, then installing the new version. As with an in-place upgrade on UNIX, this does not require use of the backup and migration utilities.

See "Performing an in-place upgrade".

Offline upgrades

While an offline upgrade is in progress, databases are not available to applications. Offline upgrades usually require enough disk space for two copies of each database in the TimesTen instance being upgraded.

Offline upgrades are used to do the following:

• Move to a new major release of TimesTen.

  Most major TimesTen upgrades do not require an offline upgrade, but some situations do (such as for active standby pairs with cache groups or managed by Oracle Clusterware, as discussed later in this chapter).

• Move to a different directory or computer.

• Reduce database size.

• Move between 32-bit and 64-bit databases.

Offline upgrades require all applications to disconnect from TimesTen during the upgrade procedure. Databases must also be unloaded from shared memory. Offline upgrades require you to use TimesTen's ttMigrate or ttBackup utilities. (See "ttMigrate" and "ttBackup" in Oracle TimesTen In-Memory Database Reference.)

See "Performing an offline upgrade".

Online upgrades with replication

When upgrading to a new major release of TimesTen, you may have a mission-critical database that must remain continuously available to your applications. You can use TimesTen replication to keep two copies of a database synchronized, even when the databases are from different releases of TimesTen, allowing your applications to stay connected to one copy of the database while the TimesTen instance for the other database is being upgraded. When the upgrade is finished, any updates that have been made on the active database are transmitted immediately to the database in the upgraded TimesTen instance, and your applications can then be switched with no data loss and no downtime. For more information, see "Performing an online upgrade with replication".

The online upgrade process supports only updates to user tables during the upgrade. Data definition changes such as CREATE TABLE or CREATE INDEX are not replicated. In addition, all tables to be replicated must have a PRIMARY KEY or a unique index on non-nullable columns.

Because two copies of the database (or two copies of each database, if there are more than one) are required during the upgrade, you must have available twice the memory and disk space normally required, if performing the upgrade on a single system.

Online upgrades with Client/Server

If you are upgrading a TimesTen Client/Server installation to a new major release, you can minimize downtime by performing a Client/Server online upgrade. During this process, TimesTen clients from the previous release are able to continue to communicate with a database in a TimesTen instance that has been upgraded to the new release. See "Performing a Client/Server online upgrade".

The Client/Server online upgrade process minimizes, but does not eliminate, the interruption of client application access to the database in the TimesTen instance being upgraded. To maintain nearly continuous availability of a database to all clients, you may use the approach discussed in the preceding section, "Online upgrades with replication". This procedure keeps an identical copy of the database available to the old release of TimesTen Server, while you perform the upgrade. Once the original database is available to the new release of TimesTen Server, you may stop the old release and start the new release, listening on the same port. The only interruption in availability using this method is the very brief period after the old server is stopped and before the new server is started.

Unloading a database from memory

A TimesTen database remains loaded in shared memory as long as any applications or TimesTen agents, such as the cache agent or replication agent, are connected to it. A database may also be kept in shared memory if the RAM policy of the database has been modified using the ttAdmin utility, even when no applications or agents are connected. (See "ttAdmin" in Oracle TimesTen In-Memory Database Reference.)

Use the following steps to unload a database from memory in a TimesTen instance being upgraded. All steps must be completed for each database in the TimesTen instance.

1. Disconnect all applications from the database.

2. If the replication agent is running on the database, set the replication state to pause and stop the replication agent. This example references an active standby pair, activedb and standbydb, where activedb belongs to the TimesTen instance being upgraded. The example sets the replication state from activedb to standbydb to pause, then stops the replication agent on activedb. Assume standbydb does not belong to the TimesTen instance being upgraded.

   ttRepAdmin -receiver -name activedb -state pause standbydb
   ttAdmin -repStop activedb
   

3. If the cache agent is running on the database, stop the cache agent. This example references a database cachedb that uses IMDB Cache and belongs to the TimesTen instance being upgraded. (The example does not consider replication.)

   ttAdmin -cacheStop cachedb
   

4. If the RAM policy is set to manual, unload the database from memory using ttAdmin. This example references a database upgradedb that belongs to the TimesTen instance being upgraded (and does not consider replication or cache):

   ttAdmin -ramUnload upgradedb
   

   If the RAM policy is set to always, change it to manual, then unload the database from memory. For example:

   ttAdmin -ramPolicy manual -ramUnload upgradedb
   

   If the RAM policy is inUse and a grace period is set, set the grace period to 0 or wait for the grace period to elapse. For example:

   ttAdmin -ramGrace 0 upgradedb
   

5. Use the ttStatus utility to verify that the databases belonging to the TimesTen instance being upgraded have been unloaded from memory. (See "ttStatus" in Oracle TimesTen In-Memory Database Reference.)

Also see "Reloading a database into memory", following shortly.

Performing the upgrade

To perform an in-place upgrade on a UNIX system, use the TimesTen installer option to upgrade an existing instance (not install a new instance). UNIX installer options are covered in "Installing TimesTen".

The uninstallation of the old version and installation of the new version take place in a single process. New software libraries and binaries are installed in the same location as before. You are prompted whether to remove files in install_dir/info and install_dir/network/admin/samples. Presuming you choose the default "no" responses, existing databases will be preserved (assuming they were not located under the install_dir directory) without the necessity of using the TimesTen backup and migration utilities.

On Windows systems, there is no installer option for such an upgrade. Instead, when moving between patch releases, you must perform an uninstallation of TimesTen followed by an installation of the new version. Uninstallation on Windows is covered in "Uninstalling TimesTen on Windows systems". Presuming you choose to save your DSNs while uninstalling, existing databases will be preserved (assuming they were not located under the install_dir directory) without the necessity of using the TimesTen backup and migration utilities. Installation on Windows is covered in "Installing TimesTen".

Reloading a database into memory

After unloading the databases from memory (as shown in "Unloading a database from memory") and upgrading the TimesTen instance, use commands such as the following to reload a database into memory. (These examples are independent of each other.) Such steps must be performed, as applicable, for each database in the instance that was upgraded.

To restart replication (assuming activedb of an active standby pair was in the TimesTen instance being upgraded):

ttRepAdmin -receiver -name activedb -state start standbydb
ttAdmin -repStart activedb

To restart IMDB Cache (assuming cachedb uses cache and was in the TimesTen instance being upgraded):

ttAdmin -cacheStart cachedb

To reload the database into memory (assuming RAM policy was set to manual for the database upgradedb, which was in the TimesTen instance being upgraded):

ttAdmin -ramLoad upgradedb

If you changed the RAM policy from always to manual when you unloaded the database from memory, change it back to always. For example:

ttAdmin -ramPolicy always upgradedb

If the RAM policy was inUse before you unloaded the database from memory and you changed the grace period to 0, change it back to its original setting. For example:

ttAdmin -ramPolicy inUse -ramGrace 300 upgradedb

Moving to a different directory

The TimesTen daemon identifies a database by the full path name of the database checkpoint files. To move a TimesTen database to a different directory, back up the database using the ttBackup utility, create a new DSN definition that specifies the new database path name, then restore the database into its new location using the ttRestore utility. When you have verified that the database functions properly in the new location, free up the disk space by using ttDestroy to remove the old database.

For example, to move a database from /old/SalesData/sales with a database name SalesData to /new/SalesData/sales with database name NewSalesData, using the /tmp/dump directory for temporary storage, use the following commands:

1. mkdir /tmp/dump

2. ttBackup -dir /tmp/dump -fname salesdata SalesData

3. Create a DSN definition for the NewSalesData database and specify the new database path: /new/SalesData/sales/NewSalesData.

4. ttRestore -dir /tmp/dump -fname salesdata NewSalesData

   (Verify that NewSalesData is operational.)

5. rm -r /tmp/dump

6. ttDestroy /old/SalesData/sales/SalesData

7. Remove the DSN definition for the SalesData database.

This example is for UNIX systems. Do the equivalent on a Windows system.

Moving to a different computer

You can also use the ttBackup and ttRestore utilities to move a database between two computers that have the same CPU architecture and are running the same operating system.

To copy a database from one system to another with the same CPU architecture and operating system:

1. Back up the database on the original system using ttBackup.

2. Move the backup to the new system.

3. Reconfigure the replication scheme on any databases that replicate to the moved database to specify the new host computer. (See "Reversing the roles of the master databases" in Oracle TimesTen In-Memory Database Replication Guide for information relevant in specifying a host in a replication scheme.)

4. Restore the backup using ttRestore.

Following is an example to move a database /ds/Sales/Data/salesdata on the source system to a database /data/Sales/View/salesview on the destination system. The example uses the -o flag of ttBackup to use standard output for the backup. Using the -o flag, the backup is stored in a single file, which is easily copied over the network to the other system. Once you have copied the database to the other system, you must create a DSN for access to the new database copy.

This example is for UNIX systems. Do the equivalent on a Windows system.

Reducing database size

Once a database has been defined with a particular size for the permanent partition (indicated by the PermSize DSN attribute), it cannot be loaded at a smaller size, even if tables or rows are deleted. A copy of the database made with ttBackup also has the permanent partition size of the database embedded in it.

To reduce the allocated size of the permanent partition of a database, save a copy using the ttMigrate utility with the -relaxedUpgrade option. Then re-create the database with a smaller permanent partition size and restore the data.

Perform these steps to reduce the permanent partition size of a database:

1. Back up the old database, using the ttMigrate -c and -relaxedUpgrade options.

2. Create a new DSN definition for the new copy of the database with a smaller PermSize value.

3. Restore the backup, using the ttMigrate -r and -relaxedUpgrade options.

Here are steps to reduce the allocated size of a database from 400 MB to 100 MB. The database is in /ds/Sales/Data and has the DSN salesdata.

1. ttMigrate -c -relaxedUpgrade salesdata /tmp/salesbackup

2. ttDestroy salesdata

3. Modify the DSN salesdata to have a size of 100 MB.

4. ttMigrate -r -relaxedUpgrade salesdata /tmp/salesbackup

Moving between 32-bit and 64-bit databases

The internal format of a 32-bit TimesTen database differs from that of a 64-bit database. On UNIX systems, you can use the following procedure to convert a 32-bit database to a 64-bit database:

1. From the 64-bit system, use ttMigrateCS to connect in client/server mode to the 32-bit database and create a data file for the 32-bit database on the 64-bit system. Use the -relaxedUpgrade option. (The ttMigrateCS utility is the client/server version of ttMigrate.)

2. On the 64-bit system, create a DSN for the 64-bit database. See "Creating a Data Manager DSN on UNIX" or "Creating a Data Manager DSN on Windows" in Oracle TimesTen In-Memory Database Operations Guide.

3. On the 64-bit system, import the file created in step 1 into the 64-bit database using the ttMigrate utility, again with the -relaxedUpgrade option.

For example, if the 32-bit database is salesdata1 and the 64-bit database is salesdata2 (with all steps performed on the 64-bit system):

1. ttMigrateCS -c -relaxedUpgrade salesdata1 salesdata.dat

2. Create a DSN for salesdata2.

3. ttMigrate -r -relaxedUpgrade salesdata2 salesdata.dat

The ttMigrateCS version of ttMigrate is UNIX-only. On Windows systems, you can do the equivalent by using ttMigrate to connect to the 32-bit database from the 64-bit system through a defined TimesTen client DSN.

Moving to a different major release of TimesTen

You can have multiple TimesTen major releases installed on a system at the same time. However, TimesTen databases created by one major release cannot be accessed directly by applications of a different major release. To migrate data between TimesTen major releases, for example from TimesTen 7.0 to 11.2.2, you must export the data using the ttMigrate utility from the old release and import it using the ttMigrate utility from the new release. The procedure for this upgrade is similar to the steps outlined in "Moving between 32-bit and 64-bit databases".

If you are upgrading TimesTen instances that have two or more databases that are replicating to each other, you must perform a few extra steps to ensure that replication continues to operate during and after the upgrades. For example, to migrate two replicating databases, master1 on host computer masterhost and subscriber1 on host computer subscriberhost, from TimesTen release 7.0 to TimesTen release 11.2.2, perform the steps that follow.

1. Configure the replication scheme on both databases to use static TCP/IP ports for replication. This is necessary because the intermediate result of this procedure is that replication occurs between two different releases of TimesTen. Each release does not necessarily know how to find the main daemon of the other to have the replication ports assigned dynamically. See "Port assignments" in the Oracle TimesTen In-Memory Database Replication Guide for more information.

2. On the computer masterhost, use the ttAdmin utility of the 7.0 release to stop the replication daemon on the database:

   ttAdmin -repStop master1
   

3. Next, use the ttMigrate utility of the 7.0 release with the -c option to back up database master1 to a binary file:

   ttMigrate -c master1 master1.bak
   

4. Use the ttDestroy utility of the 7.0 release to destroy database master1, where the database files are located in the directory data_store_path:

   ttDestroy /data_store_path/master1
   

5. Use the ttMigrate utility of the 11.2.2 release with the -r option to restore database master1 from the binary file. Restoring the database automatically upgrades it from release 7.0 to release 11.2.2. If you are restoring a very large database, you should use the -C (capital "C") option to tell ttMigrate to perform a checkpoint operation on the database periodically. This saves time if the restore fails at some point before the operation has been completed. For more information, see "Checkpoint operations" in the Oracle TimesTen In-Memory Database Operations Guide.

   ttMigrate -r -C 20 master1 master1.bak
   

6. Use the ttAdmin utility of the 11.2.2 release to start the replication daemon:

   ttAdmin -repStart master1
   

   Replication is now occurring between the database master1 on release 11.2.2 and the database subscriber1 on release 7.0.

   Now upgrade the TimesTen instance for database subscriber1 from release 7.0 to release 11.2.2. Perform the steps that follow.

7. On the computer subscriberhost, use the ttAdmin utility of the 7.0 release to stop the replication daemon:

   ttAdmin -repStop subscriber1
   

8. Use the ttDestroy utility of the 7.0 release to destroy database subscriber1, where the database files are located in the directory data_store_path:

   ttDestroy data_store_path/subscriber1
   

9. If you are upgrading from a TimesTen version prior to 11.2.1, when access control was introduced, you must create a user with ADMIN privileges to duplicate a database using replication. (If you are upgrading from 11.2.1 or higher, you can presumably use an ADMIN user that was migrated over by ttMigrate.) For example, to create the user pat with the password patpwd on the standby master database:

   CREATE USER pat IDENTIFIED BY patpwd;
   GRANT ADMIN TO pat;
   

10. Use the ttRepAdmin utility of the 11.2.2 release with the -duplicate option to duplicate database subscriber1 from database master1 using replication.

    ttRepAdmin -duplicate -from master1 -host masterhost -uid pat -pwd patpwd
     -setMasterRepStart subscriber1
    

11. Use the ttAdmin utility of the 11.2.2 release to start the replication daemon:

    ttAdmin -repStart subscriber1
    

The upgrade is now complete and the databases are replicating to each other.

For additional information about particular scenarios where an offline upgrade is required for a major TimesTen upgrade, see "Offline major upgrades for an active standby pair with cache groups" and "Performing an offline TimesTen upgrade when using Oracle Clusterware".

Procedural overview

Upgrading a database from an older TimesTen release to a newer release is performed by disconnecting all applications from one of two replicated copies of a database, making a backup of the database with the ttMigrate utility from the older release, loading the backup into a newer release database using the ttMigrate utility from the newer release, and then reconnecting all applications to the database in the upgraded TimesTen instance.

The general steps in an online upgrade include:

1. Disconnect all applications from the database in the TimesTen instance being upgraded.

2. Shut down replication in the TimesTen instance being upgraded.

3. Back up the database residing in the TimesTen instance being upgraded using the older release's ttMigrate with the -c option.

4. Install the newer release of TimesTen on the system being upgraded.

5. Restore the replicated database in the upgraded TimesTen instance using the newer release's ttMigrate with the -r option.

6. Restart replication on the upgraded TimesTen instance.

7. Reconnect all applications to the database in the upgraded TimesTen instance.

To maintain continuous availability, applications continue to run on one copy of the database while the upgrade is performed on the TimesTen instance of the disconnected copy of the database. TimesTen replication retains updates made to the active copy of the database during the upgrade period, and then transfers and applies the updates to the post-upgrade database when replication is restarted. When the replicated updates have been completely applied, the applications may be reconnected to the post-upgrade database.

Limitations

Online upgrades can be performed only with databases for which all the user tables meet the replication requirements. All the user tables must contain either a PRIMARY KEY declaration or have a unique index declared over non-nullable columns.

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.

If you are performing an online upgrade on a single system where a bidirectional replication configuration does not exist, you must ensure that enough memory and disk space are available to support two copies of the database where the upgrade is being performed. Both the original database and its copy remain active for the duration of the upgrade. To maintain the performance of your production applications, you may want to create the copy of the database on a second system.

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 sys.monitor table, using ttIsql:

Command> SELECT perm_in_use_size FROM sys.monitor;

Upgrade steps

The following timeline illustrates the steps for performing an online upgrade while replication is running. The upgrade system is the system on which the database upgrade is being performed, and the active system is the system containing the database to which the application remains connected.

After the above procedures are carried out on the upgrade system, the active system 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 TimesTen databases, using a specific example.

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

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

Follow the steps listed here in the order they are presented. The online upgrade procedures are as follows.

ttRepAdmin -receiver -name upgrade
 -state pause active

ttAdmin -repStop upgrade

ttAdmin -repStop active

ttRepAdmin -receiver -name active
  -state stop upgrade

ttMigrate -c upgrade /backup/upgrade.dat

ttDestroy upgrade

ttAdmin -ramUnload upgrade

ttAdmin -repStart active

ttRepAdmin -receiver -name upgrade
 -start start active

ttMigrate -r upgrade /backup/upgrade.dat

ttAdmin -ramLoad upgrade

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

ttAdmin -repStart upgrade

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:

• Online minor upgrade for standby master and subscriber

• Online minor upgrade for active master

• Online major upgrade for active standby pair

Also see "Performing an online upgrade with replication" for an overview, limitations, and requirements.

Online minor upgrades for an active standby pair with cache groups

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

• Online minor upgrade for standby master and subscriber (cache groups)

• Online minor upgrade for active master (cache groups)

Also see "Performing an online upgrade with replication" for an overview, limitations, and requirements.

Offline major upgrades for an active standby pair with cache groups

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

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

Supported configurations

The following basic configurations are supported for online rolling in-place upgrades for TimesTen. In all cases, the hosts are managed by Oracle Clusterware.

• One active standby pair on two hosts.

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

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

(Other scenarios, such as with additional spare systems, 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 in-place upgrade does not change the TimesTen environment for the active and standby databases.

• The in-place upgrade is from a TimesTen 11.2.2.x.x release to a later TimesTen 11.2.2.x.x release. These instructions are for TimesTen minor version upgrades only. Online major version upgrades in configurations where active standby pairs are managed by Clusterware are not currently supported.

• Oracle Clusterware is release 11.2.0.2 or 11.2.0.3.

• The in-place upgrade applies to one TimesTen installation on each host.

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

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

Upgrade tasks for one active standby pair

This section describes the following tasks:

• Verify that the active standby pair is operating properly

• Shut down the standby database

• Perform an in-place upgrade for the standby database

• Start the standby database

• Switch the roles of the active and standby databases

• Shut down the new standby database

• Perform an in-place upgrade of the new standby database

• Start the new standby database

ttCWAdmin -switch -dsn myDSN

crsctl status resource -n host1 | grep TT

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

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 TimesTen 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, discussed in the preceding section, "Upgrade tasks for one active standby pair". 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, as discussed in the preceding section, "Upgrades for multiple active standby pairs on many pairs of hosts". Alternatively, multiple active standby pairs can be configured 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 3-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 3-1 Multiple active standby pairs on two hosts

Description of "Figure 3-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 "The cluster.oracle.ini file" in Oracle TimesTen In-Memory Database Replication Guide for information about that file.)

The in-place 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, discussed in "Upgrades for multiple active standby pairs on many pairs of hosts".

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 in order to perform the upgrade for the entire "standby" host.

Be aware that in-place upgrades affect the entire TimesTen installation and associated databases on one host.

1. Verify that the standby databases are running 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.

The following subsections contain related samples.

• Sample configuration files: multiple active standby pairs on one pair of hosts

• Sample scripts: stopping and starting multiple standby processes on one host

[databasea]
Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so
DataStore=/scratch/terry/ds/databasea
PermSize=40
TempSize=32
PLSQL=1
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL
 
[databaseb]
Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so
DataStore=/scratch/terry/ds/databaseb
PermSize=40
TempSize=32
PLSQL=1
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL

[databasec]
Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so
DataStore=/scratch/terry/ds/databasec
PermSize=40
TempSize=32
PLSQL=1
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL

[databased]
Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so
DataStore=/scratch/terry/ds/databased
PermSize=40
TempSize=32
PLSQL=1
DatabaseCharacterSet=WE8MSWIN1252
OracleNetServiceName=ORCL

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

crsctl status resource -n standbyHostName | grep TT

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

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

Sample in-place upgrade

This section provides a sample in-place upgrade.

$ ./setup.sh
 
There is 1 TimesTen instance installed locally :
 
1) sb1122 (TimesTen11.2.2.4)
 
Of the following options :
 
  [1] Install a new instance
  [2] Upgrade an existing instance
  [3] Display information about an existing instance
  [q] Quit the installation
 
Which would you like to perform? [ 1 ] 2
 
NOTE: There is only one instance which can be upgraded.
 
Instance Name          : sb1122
Product Installed      : TimesTen11.2.2.4
Installation Directory : /scratch/sboand/TimesTen/sb1122
BitLevel               : 64
Component Installed    : Client/Server and DataManager
Daemon Port            : 33333
 
NOTE: Upgrading will remove the selected instance (and any directories or files
      under its path) and then re-install into the same directory. You will
      have the option to retain configuration files in :
      /scratch/sboand/TimesTen/sb1122/info 
 
Would you like to upgrade this instance? [ yes ]
 
NOTE: <install_dir>/info contains information related to the data
   stores that have been created with this release. If you remove
   /scratch/sboand/TimesTen/sb1122/info
   you will no longer be able to access your data stores,
   nor would you be able to restore nor migrate your data. 
 
   Would you also like to remove all files in <install_dir>/info? [ no ]
   Would you like to remove the DemoDataStore directory in    
/scratch/sboand/TimesTen/sb1122/info/DemoDataStore? [ yes ] no
   Would you also like to remove all files in <install_dir>/network/admin/samples? [ no ]
   /scratch/sboand/TimesTen/sb1122 Removed (retained <install_dir>/info)
TimesTen uninstall completed.
 
Of the three components:
  [1] Client/Server and Data Manager
  [2] Data Manager Only
  [3] Client Only
 
Which would you like to install? [ 1 ]
Upgrading installation in /scratch/sboand/TimesTen/sb1122
Where would you like to create the daemon home directory? 
[ /scratch/sboand/TimesTen/sb1122/info ]
 
The daemon logs will be located in /scratch/sboand/TimesTen/sb1122/info
Would you like to specify a different location for the daemon logs? [ no ]
Installing into /scratch/sboand/TimesTen/sb1122 ...
Uncompressing ...
 
NOTE: For security, we recommend that you restrict access to the
      TimesTen installation to members of a single OS group. Only members of
      that OS group will be allowed to perform direct mode connections to
      TimesTen, and only members of that OS group will be allowed to perform
      operations that access TimesTen data stores, TimesTen files and shared
      memory. The OS group defaults to the primary group of the instance
      administrator. You can default to this group, choose another OS group
      or you can make this instance world-accessible. If you choose to make
      this instance world-accessible, all database files and shared memory
      are readable and writable by all users.
 
Restrict access to the the TimesTen installation to the group 'g900'? [ yes ]
 
NOTE: Enabling PL/SQL will increase the size of some TimesTen libraries.
 
Would you like to enable PL/SQL for this instance? [ yes ]
 
Do you want to replace the ttendaemon.options file in
/scratch/sboand/TimesTen/sb1122/info? [ yes ] no
 
NOTE: The existing daemon options file has been retained. The default options
      file was written as
      /scratch/sboand/TimesTen/sb1122/info/ttendaemon.options.sb1122. 
 
In order to use the 'In-Memory Database Cache' feature in any databases
created within this installation, you must set a value for the TNS_ADMIN
environment variable. It can be left blank, and a value can be supplied later
using <install_dir>/bin/ttModInstall.
 
A value for TNS_ADMIN (/scratch/sboand/TimesTen/sb1122/network/admin/samples) was
found in the previous daemon options file.
 
Please enter a value for TNS_ADMIN (s=skip)? 
[ /scratch/sboand/TimesTen/sb1122/network/admin/samples ] s
 
Installing server components ...
What is the TCP/IP port number that you want the TimesTen Server to listen on? 
[ 33334 ]
Do you want to install QuickStart and the TimesTen Documentation? [ no ]
Would you like to install the documentation (without QuickStart)? [ yes ] no
 
An existing cluster.oracle.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
 
Would you like to replace the existing cluster.oracle.ini file? [ no ]
 
The existing cluster.oracle.ini file will be used.
The sample cluster.oracle.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/cluster.oracle.ini.tt1122'.
 
An existing sys.odbc.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
 
NOTE: You may not be able to successfully run the demos if you keep your
      existing sys.odbc.ini file. If you choose to replace the existing
      file, a backup will be made automatically.
 
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/info/sys.odbc.ini file ? [ no ]
 
The existing sys.odbc.ini file will be used.
The sample sys.odbc.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/sys.odbc.ini.sb1122'.
 
An existing tnsnames.ora file has been detected in
/scratch/sboand/TimesTen/sb1122/network/admin/samples.
 
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/network/admin/samples/tnsnames.ora file ? [ no ]
 
The existing tnsnames.ora file will be used.
The sample tnsnames.ora file will be saved as
'/scratch/sboand/TimesTen/sb1122/network/admin/samples/tnsnames.ora.tt1122'.
 
Installing client components ...
 
An existing sys.ttconnect.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
 
NOTE: You may not be able to successfully run the Client/Server demos if you keep
      your existing sys.ttconnect.ini file. If you choose to replace the existing
      file, a backup will be made automatically.
 
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/info/sys.ttconnect.ini file ? [ no ]
 
The existing sys.ttconnect.ini file will be used.
The sample sys.ttconnect.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/sys.ttconnect.ini.sb1122'.
 
Would you like to use TimesTen Replication with Oracle Clusterware? [ no ] yes
 
A Clusterware installation was detected in /scratch/oracle/crs/app/11.2.0/grid
 
Please provide the path to the Oracle Clusterware installation on this machine
(s=skip)? [ /scratch/oracle/crs/app/11.2.0/grid ]
 
NOTE: The TimesTen Clusterware agent port must be the same on all nodes
      of the cluster. Please refer to the TimesTen documentation for
      additional information.
 
Please enter a port number for the TimesTen Clusterware agent? [ 33339 ]
 
Executing '/scratch/oracle/crs/app/11.2.0/grid/bin/olsnodes' ...
Oracle Clusterware is currently configured on the following nodes :
 
1. host1
2. host2
3. host3
4. host4
5. host5
 
NOTE: By default, all of the nodes listed above will be added to the TimesTen
      Replication with Oracle Clusterware configuration. You can also
      specify your own list of nodes based on the list above.
 
Would you like to specify a node list for TimesTen Replication with Oracle
Clusterware? [ no ] yes
From the nodes above, please provide a list of nodes that you would like to add
(ex: 1,2 or skip)? [  ] 4,5
 
TimesTen Replication with Oracle Clusterware will be configured for the following nodes :
 
host4
host5
 
Are you sure? [ yes ]
Overwrite the existing TimesTen Clusterware options file? [ no ]
The new TimesTen Clusterware options file will be located here :
        /scratch/sboand/TimesTen/sb1122/info/ttcrsagent.options.tt1122.
 
NOTE: The TimesTen daemon startup/shutdown scripts have not been installed.
 
Run the 'setuproot' script :
        cd /scratch/sboand/TimesTen/sb1122/bin
        ./setuproot -install
This will move the TimesTen startup script into its appropriate location.
 
The startup script is currently located here :
  '/scratch/sboand/TimesTen/sb1122/startup/tt_sb1122'.
 
The documentation was not installed.
To manually install the documentation, run the command 'setup.sh -installDoc'
 
The 11.2.2.6 Release Notes are located here :
  '/scratch/sboand/TimesTen/sb1122/README.html'
 
Starting the daemon ...
TimesTen Daemon startup OK.
End of TimesTen installation.

Considerations regarding parallel replication

Be aware of the following considerations when upgrading systems that use parallel replication:

• Consider an active standby pair without parallel replication enabled. To upgrade the TimesTen instances to release 11.2.2.3.0 or higher and use automatic parallel replication (default value of 0 for the ReplicationApplyOrdering attribute), simply use the appropriate procedure for an active standby pair upgrade. See "Performing an upgrade with active standby pair replication".

• You cannot replicate between databases that have the ReplicationParallelism attribute set to greater than 1 but have different values for the ReplicationApplyOrdering attribute.

Scenarios that require an offline upgrade

You must use an offline upgrade for these scenarios:

• Moving from user-specified parallel replication to automatic parallel replication. For example, from a release preceding 11.2.2.3.0 to release 11.2.2.3.0 or higher with the ReplicationApplyOrdering attribute set to the default value (0).

• Moving from an automatic parallel replication environment to another automatic parallel replication environment with a different number of tracks, as indicated by the value of the ReplicationParallelism attribute.

• Moving between major releases (such as from 11.2.1.x.x to 11.2.2.x.x) and using asynchronous writethrough cache groups.

• Moving from regular replication with asynchronous writethrough in 11.2.1.x.x to automatic parallel replication with asynchronous writethrough in 11.2.2.x.x.

For offline upgrades, you can use the procedure described in "Performing an offline upgrade". Alternatively, you can upgrade one side and use the ttRepAdmin -duplicate -recreate command to create the new database.

Client/Server online upgrade

To perform an online upgrade of a TimesTen Client/Server system to a new major release (such as from 11.2.1.x.x to 11.2.2.x.x) with minimal reconfiguration, perform the following steps:

1. Stop the TimesTen Server on the old release of TimesTen. From this point until the TimesTen Server for the new release is started, your client applications do not have access to the database. Any attempted updates to the database by the clients fail, and you should stop user applications if necessary.

2. Install the new release of TimesTen. At installation time, configure the server to listen on the same port as the old release of TimesTen.

3. Use ttMigrate to migrate the database from the old release to the new release. See "Moving between 32-bit and 64-bit databases" for an example of this procedure.

4. Start the new release of TimesTen Server. The client applications now have access to the post-upgrade databases.

Client/Server online upgrade with continuous access to the database

The migration of a database using ttMigrate can be a long process if your databases are very large. If it is critical that your client applications have nearly continuous access to the database during the Client/Server online upgrade procedure, you may incorporate the procedure for performing an online upgrade with replication by following these steps:

1. Install the new release of TimesTen, making sure to configure TimesTen Server to listen on the same port as the old release. The installation script asks whether you would like to start the new server. You must answer "no."

2. Follow the steps in "Performing an online upgrade with replication" to upgrade the TimesTen instance for one copy of the database. The client applications remain connected to the other, non-upgraded copy of the database.

3. Disconnect all clients from the old release of the database.

4. Stop the old release of TimesTen Server.

5. Wait for all updates to finish replicating from the old release of the database to the new release.

6. Start the new release of TimesTen Server. It begins listening on the same port as the old release, and client applications may now connect to the new release of the database with no change to their configurations.