7 Upgrades in TimesTen Classic
Ensure you review the installation process in the preceding chapters before completing the upgrade procedures described in this chapter.
Topics include:
Overview of Release Numbers
There is a release numbering scheme for TimesTen releases. This scheme is relevant when discussing upgrades. For example, for a given release, a.b.c.d.e:
-
aindicates the first part of the major release. -
bindicates the second part of the major release. -
cindicates the patch set. -
dindicates the patch level within the patch set. -
eis reserved.
Important considerations:
-
Releases within the same major release (
a.b) are binary compatible. If a release is binary compatible, you do not have to recreate the database for the upgrade (or downgrade). -
Releases with a different major release are not binary compatible. In this case, you must recreate the database. See "Migrating a Database" for details.
As an example, for the 26.1.1.1.0 release:
-
The first two numbers of the five-place release number (
26.1) indicate the major release. -
The third number of the five-place release number (
1) indicates the patch set. For example,26.1.1.1.0is binary compatible with26.1.1.2.0because the first two digits in the five-place release number (26and1) are the same. -
The fourth number of the five-place release number (
1) indicates the patch level within the patch set.26.1.1.2.0is the first patch level within patch set two. -
The fifth number of the five-place release number (
0) is reserved.
Types of Upgrades
TimesTen Classic supports two types of upgrades:
-
An offline upgrade requires that you close all TimesTen databases to prevent future connections to these databases, you disconnect all applications from TimesTen, and you stop all TimesTen databases. This type of upgrade is useful when some amount of downtime is acceptable. During this downtime, the TimesTen databases are unavailable.
An offline upgrade enables you to upgrade (or downgrade) to a new patch release or to upgrade to a major release:
-
Upgrade to a new patch release:
-
Run the
ttInstanceModifyutility with the-installoption to upgrade the instance. See "About Moving to a Different Patch Release by Modifying the Instance" for details. -
Run the
ttBackupand thettRestoreutilities to upgrade patches and patch sets, although this is not the preferred method. See "Moving to a Different Patch Release Using ttBackup and ttRestore" for information.
-
-
Upgrade to a new major release: Run the
ttMigrateutility to export a database to a flat file and then usettMigrateagain to import the data into the new database. This is the only method to perform an offline upgrade that involves moving between major releases. See "Moving to a Different Major Release Using ttMigrate" for details.
-
-
An online upgrade involves using a pair of databases that are replicated and then performing an offline upgrade of each database in turn. This type of upgrade is useful when it is critically important that downtime be at a minimum. See "Online Upgrade: Using TimesTen Replication" for details.
About Moving to a Different Patch Release by Modifying the Instance
This section contains information about moving to a different patch release of TimesTen by modifying the TimesTen instance. Moving to a different patch release includes upgrades and downgrades. See "Moving to a Different Patch Release Using ttBackup and ttRestore" for information on moving to a different patch release using backup and restore operations.
-
Start a database: The subdaemon either creates a new shared memory segment or re-attaches to an existing one. These operations are used to start a database:
-
Load: The subdaemon creates a new shared memory segment, and loads the contents of the most recent checkpoint file into this new shared memory segment.
-
Remap: The subdaemon re-attaches to an existing shared memory segment.
-
-
Stop a database: The subdaemon disconnects from the shared memory segment and either destroys the shared memory segment or preserves it. These operations are used to stop a database:
-
Unload (clean): The shared memory segment is written to the checkpoint file on disk (by performing a static checkpoint operation). The subdaemon disconnects from and destroys the shared memory segment. The load operation starts the database.
-
Detach (clean): The shared memory segment is optionally written to the checkpoint file on disk (by performing a static checkpoint operation). The subdaemon disconnects from the shared memory segment, but does not destroy it. The shared memory segment remains in memory. The remap operation starts the database.
-
Note:
For a complete list of the operations you use to start and stop a database, see "Managing TimesTen Databases" in the Oracle TimesTen In-Memory Database Operations Guide.-
Basic patch upgrade: A type of upgrade where the shared memory segment is destroyed when the database is stopped. A new shared memory segment is created when the database is started. This is the preferred method for performing a patch upgrade. See "About Performing a Basic Patch Upgrade" for details.
-
Fast patch upgrade: A type of upgrade where the shared memory segment is preserved in memory when the database is stopped. The same memory segment is used when the database is started. This is the preferred method if your databases are large and you have both critical uptime requirements and short maintenance windows. See "About Performing a Fast Patch Upgrade" for details.
About Performing a Basic Patch Upgrade
A basic patch upgrade is used when you do not have critical uptime requirements and short maintenance windows. When you stop the database, the contents of the shared memory segment is written to the checkpoint file on disk. The shared memory segment is then destroyed. When you start the database after an upgrade, a new shared memory segment is created and the contents of the checkpoint file are read into this newly created shared memory segment. Depending on the size of your database, the checkpoint operation performed when the database stops and the subsequent ramLoad operation performed when the database starts could be time consuming.
The process involves downloading the TimesTen full distribution (the upgrade release) and creating a new installation. The instance that requires upgrading is then modified to point to the new installation. The ttInstanceModify utility is used to perform this instance modification. As previously noted, you must close all TimesTen databases and disconnect all applications from TimesTen.
Download and Create the New Installation
To upgrade to a new patch release of TimesTen, you must first create the new installation.
About Performing a Fast Patch Upgrade
Consider performing a fast patch upgrade when you have large databases and you have both critical uptime requirements and short maintenance windows. During the fast patch upgrade, the static checkpoint operation performed at database stop is optional, and the shared memory segment is preserved after the subdaemon disconnects. When the database is started, the checkpoint operation is not performed and a new subdaemon connects to this preserved shared memory segment. This reduces the time it takes to upgrade an instance, especially if your databases are large, by skipping both the load of the database into memory operation and the checkpoint operation.
To use a fast patch upgrade, the ramPolicy for the database must be set to enduring. This keeps the database image in memory after the subdaemon disconnects. See Specifying a RAM Policy in the Oracle TimesTen In-Memory Database Operations
Guide for information on setting a RAM policy.
The size of the TimesTen shared memory segment must remain the same before and after the fast patch upgrade. The TimesTen ttShmSize utility is provided to calculate the size of the shared memory segment. Run this utility before you upgrade the instance and then run it again after you upgrade the instance to ensure the size of the shared memory segment has not changed after the upgrade. In addition, ensure you do not modify the PermSize, the TempSize, the LogBufMB, and the Connections connection attributes after the upgrade. These attributes affect the size of the shared memory segment.
See ttShmSize and Connection Attributes in the Oracle TimesTen In-Memory Database
Reference for information on the ttShmSize utility and the TimesTen connection attributes.
Download and Create the New Installation
To upgrade to a new patch release of TimesTen, you must first create the new installation.
Prepare to Detach the Subdaemon from the Shared Memory Segment
Perform these operations on the instance created with the current release of TimesTen (26.1.1.1.0, in this example).
Detach the Subdaemon from the Shared Memory Segment
Perform these steps to disconnect the subdaemon from the shared memory segment.
Moving to a Different Patch Release Using ttBackup and ttRestore
You can run the ttBackup and ttRestore utilities to move to a new patch release, although this is not the preferred method. For the preferred method, see About Moving to a Different Patch Release by Modifying the Instance.
Note:
TimesTen replication with Oracle Clusterware is not supported on Oracle Linux for Arm systems. If you are using Oracle Linux for Arm, Oracle Clusterware messages do not appear in any output in this example.Perform these steps for each database.
On the old release:
- Use the
ttAdminutility to close thedatabase1database. This prevents further user connections.% ttAdmin -close database1 RAM Residence Policy : manual Manually Loaded In RAM : True Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database State : Closed - Disconnect all applications from the database. Run the
ttStatusutility to verify there are no connections to the database (database1, in this example).% ttStatus TimesTen status report as of Tues Aug 26 04:37:10 2025 Daemon pid 4649 port 6624 instance myinstance TimesTen server pid 4656 started on port 6625 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Data store /scratch/ttuser/database1 Daemon pid 4649 port 6624 instance myinstance TimesTen server pid 4656 started on port 6625 There are no connections to the data store Closed to user connections RAM residence policy: manual Data store is manually loaded into RAM Replication policy : Manual Cache Agent policy : Manual PL/SQL enabled. ------------------------------------------------------------------------ Accessible by group g900 End of report -
Run the
ttVersionutility to verify the current release (26.1.1.1.0, in this example).% ttVersion TimesTen Release 26.1.1.1.0 (64 bit Linux/x86_64) (myinstance:6624) 2025-08-25T07:41:05Z Instance admin: instanceadmin Instance home directory: /scratch/ttuser/myinstance20/myinstance Group owner: g900 Daemon home directory: /scratch/ttuser/myinstance/myinstance/info PL/SQL enabled. -
Backup the database. In this example, backup the
database1database for release26.1.1.1.0.% ttBackup -dir /tmp/dump/backup -fname database1_2611 database1 Backup started ... Backup complete -
Unload the database from memory. This example assumes a RAM policy of manual. See Specifying a RAM Policy in the Oracle TimesTen In-Memory Database Operations Guide for information on the RAM policy.
% ttAdmin -ramUnload database1 RAM Residence Policy : manual Manually Loaded In RAM : False Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database State : Closed -
Stop the TimesTen main daemon.
% ttDaemonAdmin -stop TimesTen Daemon (PID: 4649, port: 6624) stopped.
For the new release:
Once your databases are correctly configured and fully operational, you can optionally remove the backup file (in this example, /tmp/dump/backup/database1_2611).
Moving to a Different Major Release Using ttMigrate
Moving to a different major release is done through migration. Migration includes upgrading from one major TimesTen release to a new major TimesTen release, or changing the operating system platform that TimesTen runs on.
Migration involves copying out the schema and data from one database, creating
a new database with the new release, and then creating the schema and inserting the data
into the new database. The ttMigrate utility is used to automate the
migration of databases. See ttMigrate in the Oracle TimesTen In-Memory Database
Reference for information on the
ttMigrate utility.
Release Compatibility
Starting with Release 26.1, on Linux and UNIX, TimesTen has strengthened password security that adopts a stronger hashing algorithm. The Times databases must be one of the following releases to support the stronger algorithm and avoid authentication issues when performing a major upgrade:
- Release 26.1.1.1.0 or later for TimesTen 26.1
- Release 22.1.1.36.0 or later for TimesTen 22.1
- Release 18.1.4.54.0 and later for TimesTen 18.1
Prerequisites
Before migrating a database from one major release to another, ensure you back up the database in the old release. See ttBackup and ttRestore in Oracle TimesTen In-Memory Database Reference and Backing Up and Restoring a Database in this book for details.
Old Release
Follow these steps for the old release:
-
Use the
ttAdminutility to close thedatabase1database. This prevents further user connections.% ttAdmin -close database1 RAM Residence Policy : manual Manually Loaded In RAM : True Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database State : Closed -
Disconnect all applications from the database. Run the
ttStatusutility to verify there are no connections to the database (database1, in this example).% ttStatus TimesTen status report as of Sat Oct 2 18:31:59 2021 Daemon pid 28436 port 6624 instance myinstance TimesTen server pid 28443 started on port 6625 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Data store /scratch/ttuser/database1 Daemon pid 28436 port 6624 instance myinstance TimesTen server pid 28443 started on port 6625 There are 13 connections to the data store Shared Memory KEY 0x061014ae ID 491521 PL/SQL Memory Key 0x071014ae ID 524290 Address 0x5000000000 Type PID Context Connection Name ConnID Subdaemon 28440 0x0000000001893250 Manager 2047 Subdaemon 28440 0x0000000001914210 Rollback 2046 Subdaemon 28440 0x00007f55d80008c0 Deadlock Detector 2043 Subdaemon 28440 0x00007f55d807f330 Log Marker 2040 Subdaemon 28440 0x00007f55dc0008c0 Monitor 2044 Subdaemon 28440 0x00007f55dc07f330 AsyncMV 2039 Subdaemon 28440 0x00007f55e00008c0 Checkpoint 2042 Subdaemon 28440 0x00007f55e007f330 Aging 2041 Subdaemon 28440 0x00007f55e40008c0 Flusher 2045 Subdaemon 28440 0x00007f55e40a6970 HistGC 2038 Subdaemon 28440 0x00007f56600008c0 XactId Rollback 2036 Subdaemon 28440 0x00007f56641b9cb0 IndexGC 2037 Subdaemon 28440 0x00007f5668048360 Garbage Collector 2035 Closed to user connections RAM residence policy: Manual Data store is manually loaded into RAM Replication policy : Manual Cache Agent policy : Manual PL/SQL enabled. ------------------------------------------------------------------------ Accessible by group g900 End of report -
Run the
ttVersionutility to verify the current release.% ttVersion TimesTen Release tt26.1.1.1.0 (64 bit Linux/x86_64) (myinstance:6624) 2021-09-12T07:34:06Z Instance admin: instanceadmin Instance home directory: /scratch/ttuser/myinstance Group owner: g900 Daemon home directory: /scratch/ttuser/myinstance/info PL/SQL enabled. -
Use the
ttMigrateutility to copy out the schema and data from the database (database1, in this example).% ttMigrate -c database1 /tmp/database1.data Saving profile DEFAULT Profile successfully saved. Saving profile SYSTEM Profile successfully saved. Saving user PUBLIC User successfully saved. Saving table TTUSER.COUNTRIES Saving foreign key constraint COUNTR_REG_FK Saving rows... 25/25 rows saved. Table successfully saved. Saving table TTUSER.DEPARTMENTS Saving foreign key constraint DEPT_LOC_FK Saving rows... 27/27 rows saved. Table successfully saved. Saving table TTUSER.EMPLOYEES Saving index TTUSER.TTUNIQUE_0 Saving foreign key constraint EMP_DEPT_FK Saving foreign key constraint EMP_JOB_FK Saving rows... 107/107 rows saved. Table successfully saved. Saving table TTUSER.JOBS Saving rows... 19/19 rows saved. Table successfully saved. Saving table TTUSER.JOB_HISTORY Saving foreign key constraint JHIST_DEPT_FK Saving foreign key constraint JHIST_EMP_FK Saving foreign key constraint JHIST_JOB_FK Saving rows... 10/10 rows saved. Table successfully saved. Saving table TTUSER.LOCATIONS Saving foreign key constraint LOC_C_ID_FK Saving rows... 23/23 rows saved. Table successfully saved. Saving table TTUSER.REGIONS Saving rows... 4/4 rows saved. Table successfully saved. Saving view TTUSER.EMP_DETAILS_VIEW View successfully saved. Saving sequence TTUSER.DEPARTMENTS_SEQ Sequence successfully saved. Saving sequence TTUSER.EMPLOYEES_SEQ Sequence successfully saved. Saving sequence TTUSER.LOCATIONS_SEQ Sequence successfully saved. -
Unload the database from memory. This example assumes a RAM policy of manual. See Specifying a RAM Policy in the Oracle TimesTen In-Memory Database Operations Guide for information on the RAM policy.
% ttAdmin -ramUnload database1 RAM Residence Policy : manual Manually Loaded In RAM : False Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database State : Closed -
Stop the TimesTen main daemon.
% ttDaemonAdmin -stop TimesTen Daemon (PID: 28436, port: 6624) stopped. -
Copy the migrated object files (
/tmp/database1.data, in this example) to a file system that is accessible by the instance in the new release.
New Release
Follow these steps for the new release:
Once the database is operational in the new release, create a backup of this
database to have a valid restoration point for your database. Once you have created a backup
of your database, you may delete the ttMigrate copy of your database (in
this example, /tmp/database1.data). Optionally, for the old release, you
can remove the instance and delete the installation.
Ensure you recompile and relink existing ODBC and OCI applications after you perform the upgrade and before you use the new release of TimesTen. See Overview of ODBC API Incompatibilities in the Oracle TimesTen In-Memory Database C Developer's Guide for more information.
Online Upgrade: Using TimesTen Replication
When upgrading to a new release of TimesTen Classic, 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 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 instance, and your applications can then be switched with no data loss and no downtime. See "Performing an Online Upgrade with Classic Replication" for information.
The online upgrade process supports only updates to user tables during the upgrade. The tables to be replicated must have a PRIMARY KEY or a unique index on non-nullable columns. Data definition changes such as CREATE TABLE or CREATE INDEX are not replicated except in the case for an active standby pair with DDLReplicationLevel set to 2. In the latter case, CREATE TABLE and CREATE INDEX are replicated.
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 host.
Note:
-
Online major upgrades for active standby pairs with cache groups are only supported for read-only cache groups.
-
Online major upgrades for active standby pairs that are managed by Oracle Clusterware are not supported.
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:
-
For active standby pairs, see Online Upgrades for an Active Standby Pair with No Cache Groups and Online Upgrades for an Active Standby Pair with Cache Groups for details. Online major upgrades for active standby pairs with cache groups are only supported for read-only cache groups. Instead see Offline Upgrades for an Active Standby Pair with Cache Groups for this information.
-
For the use of Oracle Clusterware, see Performing an Online TimesTen Upgrade When Using Oracle Clusterware for information. Online major upgrades are not supported for active standby pairs managed by Oracle Clusterware.
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 |
|
5. |
Wait for updates to propagate to the active host. |
n/a |
|
6. |
Stop replication. |
n/a |
|
7. |
Back up the database with |
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 |
n/a |
|
12. |
Clear the replication bookmark and logs using |
n/a |
|
13. |
Start replication. |
n/a |
|
14. |
n/a |
Set replication to the upgrade host to the |
|
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
|
Use
|
|
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 -receiver -name upgrade -state pause active This command temporarily stops the replication of updates from the database 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 For example, call the 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 -repStop upgrade From this point on, no updates are sent to the database |
Stop the replication agent with ttAdmin -repStop active From this point on, no updates are sent to the database See Starting and Stopping the Replication Agents in Oracle TimesTen In-Memory Database Replication Guide for details. |
|
5. |
Use ttMigrate -c upgrade /backup/upgrade.dat |
n/a |
|
6. |
If the ttDestroy upgrade |
Restart the replication agent on the database 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 ttRepAdmin -receiver -name upgrade -state start active |
|
8. |
Use ttMigrate -r upgrade /backup/upgrade.dat Change the ramPolicy to manual (The ramPolicy is set to inUse by default).ttAdmin -ramLoad upgrade Note: In this step, you must use the |
n/a |
|
9. |
Use 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 |
n/a |
|
10. |
Use ttAdmin -repStart upgrade |
n/a |
|
11. |
Verify that the database |
If the applications are still running on the database |
|
12. |
n/a |
Once you are sure that updates are replicated correctly, you can disconnect all of the applications from the database Note: You may choose to delay upgrading the instance with |
Upgrades When Using Parallel Replication
You can perform an online or offline upgrade from a database that has not enabled parallel replication to a database that has enabled automatic parallel replication (with or without disabled commit dependencies). See ReplicationApplyOrdering attribute, in the Oracle TimesTen In-Memory Database Reference for information on setting automatic parallel replication values.
The remainder of this section discusses additional considerations along with scenarios where an offline upgrade is required.
Considerations Regarding Parallel Replication
Be aware of the following considerations when upgrading hosts that use parallel replication:
-
Consider an active standby pair without parallel replication enabled. To upgrade the instances to a
26.1release and use automatic parallel replication (default value of0for theReplicationApplyOrderingattribute), use the appropriate procedure for an active standby pair upgrade. See Performing an Upgrade with Active Standby Pair Replication for details. -
Consider an active standby pair with no cache groups and automatic parallel replication enabled (value of
0for theReplicationApplyOrderingattribute). To upgrade the instances to a26.1release to use automatic parallel replication with disabled commit dependencies (value of2for theReplicationApplyOrderingattribute), use the procedure for an active standby pair online major upgrade. See Online Major Upgrade for Active Standby Pair for details. The value for theReplicationApplyOrderingattribute must be changed from0to2before restoring any of the databases. For example:ttMigrate -r "DSN=master2;ReplicationApplyOrdering=2;ReplicationParallelism=2; LogBufParallelism=4" master2.bak
Note:
You may upgrade a database with a replication scheme with
ReplicationApplyOrdering=2to a database withReplicationApplyOrdering=0by using the same active standby pair online major upgrade procedure.Automatic parallel replication with disabled commit dependencies supports only asynchronous active standby pairs with no cache groups. For more information, see Configuring Parallel Replication in the Oracle TimesTen In-Memory Database Replication Guide.
-
You cannot replicate between databases that have the
ReplicationParallelismattribute set to greater than1but have different values for theReplicationApplyOrderingattribute.
Scenarios That Require an Offline Upgrade
You must use an offline upgrade for these scenarios:
-
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
ReplicationParallelismattribute. -
Moving between major releases and using asynchronous writethrough cache groups.
-
Moving from regular replication with asynchronous writethrough to automatic parallel replication with asynchronous writethrough.
Use the procedure described in Moving to a Different Major Release Using ttMigrate for offline upgrades. Alternatively, you can upgrade one side and use the ttRepAdmin -duplicate -recreate command to create the new database.
Performing an Upgrade of Your Client Instance
You can upgrade your client instance which is being used to access a database in a full instance. For information on instances, see Overview of Installations and Instances and TimesTen Instances for details. For information on Client/Server, see Overview of the TimesTen Client/Server in the Oracle TimesTen In-Memory Database Operations Guide.
To perform the upgrade, follow these steps: