Skip Headers
Oracle® TimesTen In-Memory Database Installation Guide
Release 11.2.1

Part Number E13063-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

2 Data Store Upgrades

This chapter includes the following topics:

Introduction

When a TimesTen data store is loaded into shared memory, many of its attributes are fixed, including size, logging options, TimesTen software release number, and the location of its checkpoint and transaction log files on disk. This chapter describes the steps required to change these attributes and to upgrade TimesTen data stores when you install a new release of TimesTen.

The following sections describe the compatibility and character set of the installed TimesTen release:

Data store compatibility

Prior releases of TimesTen used either five numbers (7.0.0.0.0 and later), or three numbers (releases previous to 7.0.0.0.0, such as 6.0.17) to represent the release. Starting with TimesTen release 11.2.1.1.0, TimesTen release numbers consist of three components. The first three numbers in the release are used to indicate a major release of TimesTen, such as 11.2.1. The fourth number indicated the patch release of a major release of TimesTen, and the fifth number indicates the port patch. For example, TimesTen release number 11.2.1.5.1 indicates the first port patch of the fifth patch release of TimesTen release 11.2.1.

TimesTen data stores are not compatible between major releases, but they are always compatible between patch releases. For example, a data store created with TimesTen release 7.0.5.1.0 is not compatible with a TimesTen release 11.2.1.1.0 application, but a data store created with TimesTen 11.2.1.1.0 is compatible with a TimesTen release 11.2.1.5.0 application.

When referring to a TimesTen release, the release number is often abbreviated to the major release number. For example, release 11.2.1.1.0 may be abbreviated to 11.2.1.

Data type compatibility

TimesTen supports a selection of Oracle data types in addition to the original TimesTen data types that are maintained for backward compatibility. For details on all data types, see "Type specifications" in the Oracle TimesTen In-Memory Database SQL Reference. Because some Oracle data types have the same names as the backward-compatible TimesTen data types, a set of aliases exists for addressing the data types. Which data types the aliases refer to depends on the TypeMode that is set for the data store. See "TypeMode" in the Oracle TimesTen In-Memory Database Reference for more information.

TimesTen backward-compatible data types are replication-compatible with the data types in releases of TimesTen prior to 7.0. However, TimesTen backward-compatible data types are not compatible with TimesTen IMDB Cache to Oracle—only Oracle data types can be used with IMDB Cache to Oracle. If you want to use IMDB Cache to Oracle, you must convert any original TimesTen data types to the new Oracle data types when performing a data store upgrade with ttMigrate. See "Converting data types to Oracle data types" for details.

Oracle data types are not replication-compatible with releases of TimesTen prior to 7.0. If you want to perform an upgrade that requires replication with a release of TimesTen from before 7.0, you must upgrade the original data types as TimesTen data types. See "Upgrading data types as TimesTen data types" for more information.

Data store character set

TimesTen requires a data store to be configured to support a specific character set when it is created. The character set for the data store is specified using the data store attribute DatabaseCharacterSet. The value of this attribute is used to determine which characters may be input to and output from character fields, and how character data is stored and sorted. See "Choosing a database character set" in the Oracle TimesTen In-Memory Database Operations Guide for more information.

Before upgrading your data store from a release prior to TimesTen 7.0, you must specify a data store character set by adding the DatabaseCharacterSet attribute to your data store's DSN. This attribute is ignored by releases of TimesTen prior to 7.0. In most cases, you want to choose a data store character set that makes sense for your region and that matches the character data that is present in your data store. However, there are three important restrictions you must consider:

  • If you plan to use the data store with TimesTen IMDB Cache to Oracle, you must specify a value for DatabaseCharacterSet that is the same as the character set specified for the Oracle database that the TimesTen data store connects to.

  • Replication is not possible between data stores with different character sets. Because data stores created with releases of TimesTen prior to 7.0 do not have a data store character set specified, a special data store character set, TIMESTEN8, has been created, which allows replication compatibility between data stores created by the current release of TimesTen and those created by earlier releases. If you plan to perform the data store upgrade as an online upgrade with replication (see "Performing an online upgrade with replication"), then you must specify a DatabaseCharacterSet of TIMESTEN8 in your DSN.

  • If you use TimesTen Client/Server and intend to connect to the upgraded data store with an application linked to a Client ODBC library from a release prior to TimesTen 7.0, you must specify a DatabaseCharacterSet of TIMESTEN8 in your DSN to ensure compatibility. See "Performing a Client/Server online upgrade from TimesTen release 6.0 and above".

Note:

The TIMESTEN8 data store character set is intended for use only when transitioning from a release of TimesTen prior to 7.0. When you no longer need your data store to replicate to a pre-7.0 release of TimesTen, or to connect to a pre-7.0 client application, you should use ttMigrate to convert your data store to a data store character set other than TIMESTEN8. See "Data store character set conversion" for details.

Utilities used when upgrading TimesTen data stores

TimesTen includes three utilities that may be used when upgrading data stores.

The ttBackup and ttRestore utilities can export and import, respectively, an image copy of the TimesTen data store. This data store image is only compatible between patch releases of TimesTen, and it must be backed up and restored using the same bit-level of TimesTen (32-bit or 64-bit). You may use the ttBackup and ttRestore utilities to:

The ttMigrate utility, on the other hand, exports the TimesTen data store to a release-neutral format that can be used to migrate the data store across major releases and between 32- and 64-bit versions of TimesTen. You must use the ttMigrate utility to:

Note:

The ttMigrate utility cannot migrate data stores across different hardware platforms. For example, you cannot migrate a Windows data store to a Solaris data store. The release of ttMigrate must also match the release of the data store you are copying from or to. In the procedures detailed in the following sections, use the ttMigrate utility in the older version to save the tables of the original data store a disk file and use the ttMigrate utility in the new version to restore the file into the new data store.

On Windows, these utilities use the ODBC driver manager.

On UNIX platforms, the utilities are directly linked with the TimesTen Data Manager ODBC driver.

For a full description of the syntax and usage of these and other utilities, see "Utilities" in the Oracle TimesTen In-Memory Database Reference.

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 data store 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.

Note:

This is never recommended as a long-term approach, as it results in an inherently insecure system.

Data type conversion

When performing an upgrade from a release prior to TimesTen 7.0, you must choose whether to preserve the data types in your data store as TimesTen data types, or whether to convert them to Oracle data types. Your planned use for the data store and your preferred upgrade method have an impact on this decision.

Converting data types to Oracle data types

Note:

If you intend to use your data store with TimesTen IMDB Cache, you must convert your data types to Oracle data types. However, you cannot perform an online upgrade using replication in this case, as data types may only replicate to like data types.

This is not an issue if you are upgrading from TimesTen 7.0 or later and your data types have been converted to Oracle data types.

To convert the data types from a release prior to TimesTen 7.0 to Oracle data types, you must use the -convertTypesToOra option for ttMigrate when you restore your data store as part of your upgrade procedure. For example, if you restore the data store salesdata as part of an upgrade procedure, you may use the following to upgrade the data types to Oracle data types:

ttMigrate -r -convertTypesToOra salesdata salesdata.mig

See "TimesTen to Oracle data type conversions" in the Oracle TimesTen In-Memory Database Reference for more information.

Note:

Because the Oracle and TimesTen versions of some data types behave slightly differently, you should thoroughly test any applications written for releases of TimesTen prior to 7.0 with the Oracle data types before deploying them with the new release of TimesTen.

Upgrading data types as TimesTen data types

Note:

If you intend to perform an online upgrade using replication, you must upgrade your data types as TimesTen data types. See "Online upgrades with replication" for more information.

If you choose to upgrade the data types in a data store from a release prior to TimesTen 7.0 as TimesTen data types, you do not need to use any special options when restoring the data store with ttMigrate. The data types from a release prior to TimesTen 7.0 are automatically restored as TimesTen data types.

Note:

The default TypeMode attribute for data stores is 0, which indicates Oracle type mode. In Oracle type mode, a data type such as CHAR has the semantics of the Oracle CHAR data type rather than the TimesTen CHAR data type. To guarantee compatibility with applications written for TimesTen releases before 7.0, you should configure the DSN for your data store with a TypeMode of 1 before restoring the data store with ttMigrate as part of the upgrade procedure.

Data store character set conversion

A character set must be specified for each TimesTen data store using the DSN attribute DatabaseCharacterSet. In some cases, you may need to change the configured data store character set as part of the upgrade process. There are two different cases in which a data store character set conversion are required:

Converting from the TIMESTEN8 character set

You may use ttMigrate to convert a data store from TIMESTEN8 to any other character set by completing the following steps:

  1. Save the data store to a file using ttMigrate. For example, to save the data store salesdata to the file salesdata.mig, use the command:

    ttMigrate -c DSN=salesdata salesdata.mig
    
  2. Destroy the data store:

    ttDestroy salesdata
    
  3. Change the value of the DSN attribute DatabaseCharacterSet for your data store to the value specifying the new character set. For example, if you want your data store to use the WE8ISO8859P1 character set instead of TIMESTEN8, use the following line in your ODBCINI file:

    DatabaseCharacterSet=WE8ISO8859P1
    
  4. Load the data store from the file using ttMigrate with the -noCharsetConversion command-line option. This option ensures that no character values are changed when the data is loaded into the DSN using the new character set. For example:

    ttMigrate -r -noCharsetConversion
    DSN=salesdata salesdata.mig
    

    Note:

    If you find that you have accidentally converted your data store from TIMESTEN8 to the wrong character set, you can use the same procedure to convert your data store to the correct character set without any accidental modification of the character data.

Converting from a character set other than TIMESTEN8

You may use ttMigrate to convert a data store from any character set to any other character set by completing the following steps:

  1. Save the data store to a file using ttMigrate. For example, to save the data store salesdata to the file salesdata.mig, use the command:

    ttMigrate -c DSN=salesdata salesdata.mig
    
  2. Destroy the data store:

    ttDestroy salesdata
    
  3. Change the value of the DSN attribute DatabaseCharacterSet for your data store to the value specifying the new character set. For example, if you want your data store to use the WE8ISO8859P1 character set, use the following line in your ODBCINI file:

    DatabaseCharacterSet=WE8ISO8859P1
    
  4. Load the data store from the file using ttMigrate. TimesTen automatically converts the character data from the character set the file was saved with to the character set used by the DSN. For example:

    ttMigrate -r DSN=salesdata salesdata.mig
    

    Note:

    It is possible that character data is lost in the conversion process if no mapping exists from one character set to the other for a given character.

Upgrade modes

TimesTen allows you to perform these kinds of upgrades:

In-place upgrades

In-place upgrades are available for moving to a new patch release of TimesTen, such as moving from the first patch release of 11.2.1, release 11.2.1.1.0, to the second patch release of 11.2.1, release 11.2.1.2.0. As long as your TimesTen data stores do not reside in the TimesTen installation directory, you can uninstall an old release of TimesTen, install a new patch release of TimesTen and connect to existing data stores with the new release. No separate action is required for existing stores.

In-place upgrades require all applications to disconnect from the data store during the upgrade procedure. This kind of upgrade allows you to preserve the existing data store without using TimesTen's backup and migration utilities.

Offline upgrades

During the time required to perform an offline upgrade, the data store is not available to applications. Offline upgrades usually require enough disk space for an extra copy of the upgraded data store.

Offline upgrades are used to:

  • move to a new major or patch release of TimesTen.

  • move to a different directory or computer.

  • reduce data store size.

  • move between 32-bit and 64-bit data stores.

You should perform offline upgrades during a time when applications do not need continuous access to the data store. For example, if there is a maintenance window during weekends, schedule the upgrade during that time.

Offline upgrades require all applications to disconnect from the data store during the upgrade procedure. The data store 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.)

Online upgrades with replication

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

The online upgrade process only supports 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 data store to be upgraded are required, you must have available twice the memory and disk space that the data store usually requires, if performing the upgrade on a single system.

Note:

Replication is not supported between 32-bit and 64-bit data stores. Also, tables migrated using the ttMigrate -inline command should not be replicated with tables where the option is not supported, as inline columns cannot be replicated with not inline columns.

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 data store that has been upgraded to the new release. See "Performing a Client/Server online upgrade from TimesTen release 6.0 and above".

The Client/Server online upgrade process minimizes, but does not eliminate, the interruption of client application access to the data store being upgraded. To maintain nearly continuous availability of a data store to all clients, you may use the approach outlined in "Online upgrades with replication". This procedure keeps an identical copy of the data store available to the old release of TimesTen Server, while you upgrade the original to the new release. Once the upgraded original data store 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.

On Windows, more than one release of TimesTen cannot be installed at the same time. Therefore, it is not possible to perform online upgrades with Client/Server on Windows if you are upgrading from a release of TimesTen prior to 6.0. It is also not possible to combine the Client/Server online upgrade procedure with that for performing an online upgrade with replication unless you use two different computers, one for each release of the data store that you are upgrading.

Performing an in-place data store upgrade

To upgrade an existing data store without exporting the data store to an external format, you can perform an in-place upgrade. This requires that all applications disconnect from the data store and that the data store be unloaded from shared memory. The following sections describe how to perform the in-place data store upgrade:

Unloading a data store

TimesTen data stores remain loaded in shared memory as long as any applications or TimesTen agents (such as the cache or replication agents) are connected to them. Data stores may also be kept in shared memory, even when no applications or agents are connected, if the RAM policy of the data store has been modified using the ttAdmin utility. (See "ttAdmin" in Oracle TimesTen In-Memory Database Reference.) Perform the following to unload a data store:

  1. Disconnect all applications from the data store.

  2. In this example, the data store original is from the older release. The data store upgrade is in the new release. If replication has been started, pause replication on the data stores, and then stop replication on the data store that you are unloading from memory, using the commands:

    ttRepAdmin -receiver -name upgrade -state pause original
    ttRepAdmin -receiver -name original -state pause upgrade
    ttAdmin -repStop upgrade
    
  3. If the cache agent has been started for the data store, stop the cache agent with the command:

    ttAdmin -cacheStop upgrade
    
  4. Verify that the RAM policy allows the data store to be unloaded. If the RAM policy is set to manual, unload the data store using the command:

    ttAdmin -ramUnload upgrade
    

    If the RAM policy is set to always or inUse, change it to manual. 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.

  5. Use the ttStatus utility to verify that the data store has been unloaded from memory. (See "ttStatus" in Oracle TimesTen In-Memory Database Reference.)

Moving to a new patch release of TimesTen

All applications concurrently connected to a data store must be directly linked to a TimesTen ODBC driver of the same major release. TimesTen data stores from different patch releases are structurally equivalent or identical. For example, when upgrading from release 11.2.1.1.0 to 11.2.1.3.0, you do not need to migrate your existing data stores using the ttMigrate utility. However, during the installation of a new major or patch release, you should disconnect your application and stop the TimesTen daemon. If you have not explicitly performed these steps, the prior release's TimesTen daemon process is stopped, effectively disconnecting all applications from the data store. While preparing for the upgrade, make sure that all data stores are unloaded from memory before upgrading TimesTen.

For a description of the procedures for unloading a data store from memory, see "Unloading a data store".

Performing an offline upgrade

You can do an offline upgrade by exporting the data store into an external file and then importing the data store with the desired changes. These update procedures require that all applications be disconnected from the data store and that the data store be unloaded from shared memory. For applications that require continuous availability, see "Performing an online upgrade with replication".

Note:

If the data store to be upgraded is replicated, you must use ttMigrate to move the data store between releases. In addition if you rename table owners using the ttMigrate -r -rename option, you need to also rename the table owners in every other data store involved in the replication scheme.

For simple upgrades that do not require any changes to the size or structure of the data store, such as moving between patch releases, you can use the ttBackup and ttRestore utilities. For upgrades that require structural changes to the data store, such as major release upgrades, you must use the ttMigrate utility. The ttMigrate utility exports the data store in a release-neutral format that is more flexible, while the ttBackup utility exports an image copy of the data store that is only compatible across patch releases. The ttBackup utility may be used if you want to move the data store to a different computer or directory. The ttMigrate utility must be used if you want to:

The general steps in an offline upgrade include:

  1. Disconnect all applications from the data store and unload the data store from memory. For more information, see "Unloading a data store".

  2. Use either ttMigrate with the -c and -noRepUpgrade options or ttBackup to back up the data store.

  3. Install the new release of TimesTen. For more information, see "TimesTen Installation" on page 17.

  4. Use either ttMigrate with the -r and -noRepUpgrade options or ttRestore to restore the backed up data store to the new TimesTen release.

  5. Reconnect applications to the upgraded data store.

Note:

After ttMigrate has been used, all autorefresh cache groups in a destination data store that is not part of an active standby pair have AUTOREFRESH STATE set to OFF, no matter how it was set on the source data store. Reset AUTOREFRESH STATE to ON by using the ALTER CACHE GROUP statement.

Moving to a different directory

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

For example, to move a data store from /old/SalesData/sales with a data store name SalesData ("DSN=SalesData") to /new/SalesData/sales with data store name NewSalesData ("DSN=NewSalesData"), using the /tmp/dump directory for temporary storage, use the following commands:

  1. mkdir /tmp/dump

  2. ttBackup -dir /tmp/dump -fname salesdata "DSN=SalesData"

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

  4. ttRestore -dir /tmp/dump -fname salesdata "DSN=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 data store.

Note:

You must reconfigure replication if the moved data store has been configured to replicate.

Moving to a different computer

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

Note:

Before moving a replicated data store to another computer, you should be experienced with TimesTen replication. We highly advise calling TimesTen customer support for help with this procedure.

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

  1. Back up the data store on the original system using ttBackup.

  2. Move the backup to the new system.

  3. Reconfigure the replication scheme on any data stores the replicate to the moved store to specify the new host computer. (See Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide for details on how to specify a host in a replication scheme.)

  4. Restore the backup using ttRestore.

The following 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 data store to the other system, you need to create a data source name for access to the new data store copy.

To move a data store from /ds/Sales/Data with data store name salesdata on the source system to /data/Sales/View with data store name salesview on the destination system, use the following commands.

Step On the source system On the destination system
1. ttBackup -o "DSN=SalesData" >/tmp/salesbackup  
2. ftp /tmp/salesbackup to the destination system as /tmp/salesbackup

Note: Use the ftp command in binary mode.

 
3.   ttRestore -i"DSN=SalesView" </tmp/salesbackup
4.   rm /tmp/salesbackup
5. rm /tmp/salesbackup  

Reducing data store size

Once a data store 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 data store made with ttBackup also has the data store's permanent partition size embedded in it.

To reduce the allocated size of the permanent partition of a data store, save a copy using the ttMigrate utility with the -noRepUpgrade option. Then recreate the data store with a smaller permanent partition size and restore the data.

Note:

The permanent partition size of a data store cannot be reduced below the size that is actually required by the data currently stored in the data store. This value can be determined by querying the perm_in_use_size column of the table sys.monitor.

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

  1. Back up the old data store with ttMigrate -c -noRepUpgrade.

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

  3. Restore the backup with ttMigrate -r -noRepUpgrade.

Note:

If you want to modify the original DSN rather than create a new one in Step 2, then you must destroy the original data store files using the ttDestroy utility before restoring from the backup.

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

  1. ttMigrate -c -noRepUpgrade DSN=salesdata /tmp/salesbackup

  2. ttDestroy salesdata

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

  4. ttMigrate -r -noRepUpgrade "DSN=salesdata;AutoCreate\=1" /tmp/salesbackup

Note:

The temporary partition size of a data store may be changed by simply modifying the TempSize attribute of the DSN, unloading the data store from memory, and then reconnecting to it. See "Unloading a data store" for the steps to unload a data store from memory.

Moving between 32-bit and 64-bit data stores

The internal format of a 32-bit TimesTen data store differs from that of a 64-bit data store. To convert a 32-bit data store to a 64-bit data store:

  1. Export the 32-bit data store using the TimesTen 32-bit ttMigrate utility with the -noRepUpgrade option.

  2. Create a Data Source Name (DSN) for the 64-bit data store. See "Creating a DSN on UNIX" or "Creating a DSN on Windows" in Oracle TimesTen In-Memory Database Operations Guide.

  3. Import the file created in Step 1 into the 64-bit data store DSN using the 64-bit ttMigrate utility with the -noRepUpgrade option.

For example, suppose that the 32-bit data store DSN is salesdata32 while the 64-bit data store DSN is salesdata64. If a 32-bit instance of TimesTen is installed in /opt/TimesTen/giraffe32 and a 64-bit instance is installed in /opt/TimesTen/giraffe64, the required steps are:

  1. /opt/TimesTen/giraffe32/bin/ttMigrate -c -noRepUpgrade DSN=salesdata32/tmp/salesbackup

  2. /opt/TimesTen/giraffe64/bin/ttMigrate -r -noRepUpgrade "DSN=salesdata64;AutoCreate=1"/tmp/salesbackup

Note:

TimesTen does not support replication between 32-bit and 64-bit data stores.

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 data stores 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 6.0 to 11.2.1, you need to 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 data stores".

If you need to upgrade two or more data stores that are replicating to each other, you must perform a few extra steps to ensure that replication continues to operate during and after the upgrade. For example, to migrate two replicating data stores, master1 on host computer masterhost and subscriber1 on host computer subscriberhost, from TimesTen release 6.0 to TimesTen release 11.2.1, perform the following steps:

Note:

TimesTen 11.2.1 introduces a new feature called Cache Grid. By default, this feature is enabled, and requires additional configuration before cache groups can be created on a data store. If you are upgrading a data store containing cache groups from a release previous to 11.2.1, you should set the attribute CacheGridEnable to 0 in each DSN definition before beginning. For more information, see the Oracle In-Memory Database Cache User's Guide.
  1. Configure the replication scheme on both data stores 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 TimesTen to TimesTen Replication Guide for more information.

  2. On the computer masterhost, use the 6.0 release's ttAdmin utility to stop the replication daemon on the data store:

    ttAdmin -repStop master1
    
  3. Next, use the 6.0 release's ttMigrate utility with the -c option to back up data store master1 to a binary file:

    ttMigrate -c DSN=master1 master1.bak
    
  4. Use the 6.0 release's ttDestroy utility to destroy data store master1, where the data store's files are located in the directory data_store_path:

    ttDestroy /data_store_path/master1
    
  5. Use the 11.2.1 release's ttMigrate utility with the -r option to restore data store master1 from the binary file. Restoring the data store automatically upgrades it from release 6.0 to release 11.2.1. If you are restoring a very large data store, you should use the -C option to tell ttMigrate to perform a checkpoint operation on the data store periodically. This saves time if the restore fails at some point before the operation has been completed. For more information, see "Checkpoints" in the Oracle TimesTen In-Memory Database Operations Guide.

    ttMigrate -r -C 20 DSN=master1 master1.bak
    
  6. Use the 11.2.1 release's ttAdmin utility to start the replication daemon:

    ttAdmin -repStart master1
    

    Replication is now occurring between the data store master1 on release 11.2.1 and the data store subscriber1 on release 6.0.

    Now upgrade data store subscriber1 from release 6.0 to release 11.2.1. Perform the following steps:

  7. On the computer subscriberhost, use the 6.0 release's ttAdmin utility to stop the replication daemon:

    ttAdmin -repStop subscriber1
    
  8. Use the 6.0 release's ttDestroy utility to destroy data store subscriber1, where the data store's files are located in the directory data_store_path:

    ttDestroy data_store_path/subscriber1
    
  9. If you are upgrading from a release previous to 11.2.1, you must create a user with ADMIN privileges to duplicate a data store using replication. For example, to create the user pat with the password patpwd on the standby master data store, use:

    CREATE USER pat IDENTIFIED BY patpwd;
    GRANT ADMIN TO pat;
    
  10. Use the 11.2.1 release's ttRepAdmin utility with the -duplicate option to duplicate data store subscriber1 from data store master1 using replication.

    ttRepAdmin -duplicate -from master1 -host masterhost -uid pat -pwd patpwd
     -setMasterRepStart subscriber1
    
  11. Use the 11.2.1 release's ttAdmin utility to start the replication daemon:

    ttAdmin -repStart subscriber1
    

The data stores are now upgraded and replicating to each other.

Performing an online upgrade with replication

In "Performing an offline upgrade" we showed how to perform various maintenance operations on TimesTen data stores that require that all applications be stopped. This section describes how to use the TimesTen replication feature to perform online upgrades for applications that require continuous data availability. You can do an online upgrade when moving between major TimesTen releases. If moving to a patch release, you may instead perform an in-place or offline upgrade.

Normally, applications that require high availability of their data use TimesTen replication to keep at least one extra copy of their data stores up to date. An online upgrade works by keeping one 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 data stores, as described in the Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

Note:

Replication functions across releases only if the data store of the more recent release of TimesTen was upgraded from a data store of the older release of TimesTen. A data store created in the more recent release of TimesTen is not guaranteed to replicate correctly with the older release. For example, replication between a data store created in the 5.1 release of TimesTen and a data store created in the 7.0 release of TimesTen is not supported. However, if one data store was created in the 5.1 release, and the peer data store was created in the 5.1 release and then upgraded to the 7.0 release, replication between them is supported.

Note:

For security reasons, replication is not normally allowed between data store in TimesTen 7.0 and data stores in releases previous to TimesTen 7.0. To perform an online upgrade with replication, you must start the main TimesTen 7.0 or later daemon with the -insecure-backwards-compat option. See "Communicating with older releases of TimesTen" of the Oracle TimesTen In-Memory Database Operations Guide for more information.

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

Overview

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

Note:

The ttMigrate -r -rename option, used to rename the owner of data store objects, cannot be used with online upgrades.

The general steps in an online upgrade include:

  1. Disconnect all applications from the data store being upgraded.

  2. Shut down replication on the system being upgraded.

  3. Back up the data store residing on the system 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 data store on the system being upgraded using the newer release's ttMigrate with the -r option.

  6. Reconnect all applications to the upgraded data store.

  7. Restart replication on the upgraded system.

Note:

After ttMigrate has been used, all autorefresh cache groups in an upgraded data store that is not part of an active standby pair have AUTOREFRESH STATE set to OFF, no matter how it was set on the data store prior to the upgrade. Reset AUTOREFRESH STATE to ON by using the ALTER CACHE GROUP statement.

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

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

Step Upgrade system Active system
1. Configure replication to replicate to the active system using static ports. Configure replication to replicate to the upgrade system using static ports.
2.   Connect all applications to the active data store, if they are not connected.
3. Disconnect all applications from the upgrade data store.  
4.   Set replication to the upgrade system to the pause state.
5. Wait for updates to propagate to the active system.  
6. Stop replication.  
7. Back up the data store with ttMigrate -c.  
8. Stop the TimesTen daemon for the old release of TimesTen.  
9. Install the new release of TimesTen.  
10. Create a Data Source Name for the upgraded data store for the new TimesTen release, using the ODBC Data Source Administrator on Windows or the .odbc.ini file on UNIX.  
11. Restore the data store from the backup with ttMigrate -r.  
12. Clear the replication bookmark and logs using ttRepAdmin -receiver -reset and by setting replication to the active system to the stop and then the start state.  
13. Start replication.  
14.   Set replication to the upgrade system to the start state, ensuring that the accumulated updates propagate once replication is restarted.
15.   Start replication.
16.   Wait for all of the updates to propagate to the upgrade system.
17. Reconnect all applications to the upgrade data store.  

After the above procedures are carried out on the upgrade system, the active system can be upgraded using the same steps.

Limitations

Online upgrades can be performed only on data stores 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 the Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

If you are performing an online upgrade on a single system where a bidirectional replication configuration does not exist, you must make sure that enough memory and disk space are available to support two copies of the data store being upgraded. Both the original data store 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 data store on a second system.

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

Command> SELECT perm_in_use_size FROM sys.monitor;

Online upgrade example

This section describes how to perform an online upgrade of two bidirectionally replicated TimesTen data stores, using a concrete example.

Note:

TimesTen 11.2.1 introduces a new feature called Cache Grid. By default, this feature is enabled, and requires additional configuration before cache groups may be created on a data store. If you are upgrading a data store containing cache groups from a release previous to 11.2.1, you should set the attribute CacheGridEnable to 0 in each DSN definition before beginning. For more information, see the Oracle In-Memory Database Cache User's Guide.

We'll refer to the two TimesTen systems being upgraded as the upgrade system, on which the TimesTen instance and the data store are 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 data store upgrade on the server upgradehost. The active system consists of the data store active on the server activehost.

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

Step Upgrade system Active system
1. Use ttIsql to alter the replication scheme repscheme, setting static replication port numbers so that the data stores can communicate across releases:

Command> call ttRepStop;

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

Command> call ttRepStart;

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

Command> call ttRepStop;

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

Command> call ttRepStart;

2. Disconnect all production applications connected to the data store. Any workload being run on the upgrade system must start running on the active system instead. Use the ttRepAdmin utility to pause replication from the data store active to the data store upgrade:
ttRepAdmin -connStr DSN=active
 -receiver -name upgrade
 -state pause

This command temporarily stops the replication of updates from the data store active to the data store upgrade, but it retains any updates made to active in the data store transaction log files. The updates made to active during the upgrade procedure are applied later, when upgrade is brought back up. For details on setting the replication state, see "Setting the replication state of subscribers" in Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

3. Wait for all replication updates to be sent to the data store active. You can verify that all updates have been sent by applying a recognizable update to a table reserved for that purpose on the data store upgrade. When the update appears in the data store active, you know that all previous updates have been sent.  
4. Stop the replication agent with ttAdmin:
ttAdmin -repStop upgrade

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

Stop the replication agent with ttAdmin:
ttAdmin -repStop active

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

For details on starting and stopping replication agents, see "Starting and stopping the replication agents" in the Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

5. Use ttRepAdmin to stop replication from the data store upgrade to the data store active:
ttRepAdmin -connStr DSN=upgrade
  -receiver -name active
  -state stop

This step prevents active from accumulating updates to send to upgrade and resets some of the replication bookmarks.

 
6. Use ttMigrate to back up the data store upgrade. If the data store is very large, this step could take a significant amount of time. If sufficient disk space is free on the /backup file system, the following ttMigrate command can be used:
ttMigrate -c DSN=upgrade /backup/upgrade.dat
 
7. If the ttMigrate command is successful, destroy the data store upgrade.

To destroy a permanent data store (Temporary=0), use ttDestroy:

ttDestroy upgrade

To destroy a temporary data store (Temporary=1), use ttAdmin:

ttAdmin -ramUnload upgrade
Restart the replication agent on the data store active:
ttAdmin -repStart active
8. Install the new release of TimesTen. Resume replication from active to upgrade by setting the replication state to start:
ttRepAdmin -connStr DSN=active
 -receiver -name upgrade
 -start start
9. Use ttMigrate to load the backup created in Step 6. into the data store upgrade for the new release of TimesTen:
ttMigrate -r
 "DSN=upgrade;AutoCreate=0"
 /backup/upgrade.dat

If the data store is temporary (Temporary=1), first use ttAdmin -ramLoad:

ttAdmin -ramLoad upgrade

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

 
10. Use ttRepAdmin to clear the replication bookmark and logs by resetting the receiver state for the data store active and then setting replication to the stop state and then the start state:
ttRepAdmin -connStr DSN=upgrade
   -receiver -name active -reset
ttRepAdmin -connStr DSN=upgrade
   -receiver -name active
   -state stop
sleep 10
ttRepAdmin -connStr DSN=upgrade
   -receiver -name active
   -state start
sleep 10

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

 
11. Use ttAdmin to start the replication agent on the new data store upgrade and to begin sending updates to the data store active:
ttAdmin -repStart upgrade
 
12. Verify that the data store upgrade is receiving updates from active. You can verify that updates are sent by applying a recognizable update to a table reserved for that purpose in the data store active. When the update appears in upgrade, you know that replication is operational. If the applications are still running on the data store active, let them continue until the data store upgrade has been successfully migrated and you have verified that the updates are being replicated correctly from the active to upgrade.
13.   Once you are sure that updates are replicated correctly, you can disconnect all of the applications from the data store active and reconnect them to the data store upgrade. After verifying that the last of the updates from active are replicated to upgrade, the data store active is ready to be upgraded.

Note: You may choose to delay upgrading active to the new TimesTen release until sufficient testing has been performed with the data store upgrade in the new TimesTen release.


Performing an online upgrade with active standby pair replication

You generally use active standby pair replication to provide high availability of your data to your applications. It is possible to maintain continuous availability of your data, even during a upgrade of TimesTen, your operating system, or your system hardware, by performing an online upgrade with active standby pair replication. This section describes the following procedures:

Upgrading the data stores in an active standby pair with no cache groups

This section includes the following topics:

Upgrades for TimesTen patch releases on the standby master data store and subscriber stores

To upgrade to a TimesTen patch release on the standby master data store and subscriber stores, complete the following tasks on each store:

  1. Stop the replication agent on the store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for standby data store master2, you may use:

    ttAdmin -repStop master2
    
  2. Install the TimesTen patch. See "Performing an in-place data store upgrade".

  3. Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master2
    

Upgrades for TimesTen patch releases on the active master data store

To upgrade the active master data store, you must first reverse the roles of the active and standby master data stores, and then perform an in-place upgrade:

  1. Pause any applications that are generating updates on the active master data store.

  2. Execute the ttRepSubscriberWait built-in procedure on the active master data store, using the DSN and host of the standby master data store. For example, to ensure that all transactions are replicated to the standby master master2 on the host master2host, use:

    call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
    
  3. Stop the replication agent on the current active master data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master data store master1, use:

    ttAdmin -repStop master1
    
  4. Execute the ttRepDeactivate build-in procedure on the current active master data store. This puts the store in the IDLE state:

    call ttRepDeactivate;
    
  5. On the standby master data store, set the data store to the ACTIVE state using the ttRepStateSet built-in procedure. This store becomes the active master in the active standby pair:

    call ttRepStateSet( 'ACTIVE' );
    
  6. Resume any applications that were paused in Step 1, connecting them to the data store that is now acting as the active master (in this example, data store master2).

  7. Upgrade the former active master data store, which is now the standby master data store. See "Performing an in-place data store upgrade".

  8. Restart replication on the upgraded data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master2
    
  9. If you want to make the newly upgraded data store the active master data store again, see "Reversing the roles of the active and standby master data stores" in Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

Upgrades for major TimesTen releases, application software and hardware

When you upgrade an active standby pair across major releases of TimesTen, you must explicitly specify the TCP/IP port for each data store. If your active standby pair replication scheme is not configured with a PORT attribute for each data store, you must prepare for the upgrade by following these steps:

  1. Stop the replication agent on every data store using the call ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent on the data store master1, use:

    ttAdmin -repStop master1
    
  2. On the active master data store, use the ALTER ACTIVE STANDBY PAIR statement to specify a PORT attribute for every data store in the active standby pair. For example, to set a PORT attribute for the data stores master1 on the host master1host, master2 on the host master2host, and subscriber1 on the host subscriber1host, use:

    ALTER ACTIVE STANDBY PAIR
     ALTER STORE master1 ON "master1host" SET PORT 30000
     ALTER STORE master2 ON "master2host" SET PORT 30001
     ALTER STORE subscriber1 ON "subscriber1host" SET PORT 30002;
    
  3. Destroy the standby master data store and all of the subscribers using the ttDestroy utility. For example, to destroy the data store subscriber1, use:

    ttDestroy subscriber1
    
  4. Follow the normal procedure to start an active standby pair and duplicate the standby and subscriber data stores from the active master. See "Setting up an active standby pair" in Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

When you are ready to upgrade the active standby pair, the first data store that you must upgrade is the standby master. While this node is being upgraded, there is no standby master data store, and updates on the active master data store are propagated directly to the subscriber stores.

  1. Tell the active master data store to stop replicating updates to the standby master by executing the ttRepStateSave built-in procedure on the active master data store. For example, to stop replication to the standby master data store master2 on host master2host, use:

    call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
    
  2. Stop the replication agent on the standby master data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the standby master data store master2, use:

    ttAdmin -repStop master2
    
  3. Upgrade the node where the standby master data store resides. See "Performing an offline upgrade".

  4. Start the replication agent on the standby master store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master2
    

    When the upgraded standby master data store has become synchronized with the active master data store, the upgraded standby master data store moves from the RECOVERING state to the STANDBY state. The upgraded standby master data store also starts sending updates to the subscribers. You can determine when the standby master data store is in the STANDBY state by calling the ttRepStateGet built-in procedure on the standby master data store:

    call ttRepStateGet;
    
  5. Pause any applications that are generating updates on the active master data store.

  6. Execute the ttRepSubscriberWait built-in procedure on the active master data store, using the DSN and host of the standby master data store. For example, to ensure that all transactions are replicated to the standby master master2 on the host master2host, use:

    call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
    
  7. Stop the replication agent on the active master data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master data store master1, use:

    ttAdmin -repStop master1
    
  8. On the standby master data store, set the data store to the ACTIVE state using the ttRepStateSet built-in procedure. This store becomes the active master in the active standby pair:

    call ttRepStateSet( 'ACTIVE' );
    
  9. Tell the new active master data store (master2, in our example) to stop replicating updates to what is now the standby master (master1) by executing the ttRepStateSave built-in procedure on the active master data store. For example, to stop replication to the standby master data store master1 on host master1host, use:

    call ttRepStateSave( 'FAILED', 'master1', 'master1host' );
    
  10. Destroy the former active master data store using the ttDestroy utility:

    ttDestroy master1
    
  11. Perform the upgrade on the node where the master data store was destroyed. You do not need to do anything to upgrade the data store itself, since it was destroyed.

  12. If you are upgrading from a release previous to 11.2.1, you must create a user with ADMIN privileges on the current active master data store to duplicate that store. For example, to create the user pat with the password patpwd on the standby master data store, use:

    CREATE USER pat IDENTIFIED BY patpwd;
    GRANT ADMIN TO pat;
    
  13. Duplicate the new standby master data store from the current active master data store using the ttRepAdmin utility. For example, to duplicate the data store master2 on the host master2host to the data store master1, use the following on the host containing the data store master1:

    ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd
     -setMasterRepStart master1
    
  14. Start the replication agent on the new standby master data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master1
    
  15. Stop the replication agent on the first subscriber data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the subscriber data store subscriber1, use:

    ttAdmin -repStop subscriber1
    
  16. Destroy the subscriber data store using the ttDestroy utility:

    ttDestroy subscriber1
    
  17. Perform the upgrade on the node where the subscriber data store was destroyed.

  18. Duplicate the subscriber data store from the standby master data store using the ttRepAdmin utility:

    ttRepAdmin -duplicate -from master1 -host master1host -uid pat -pwd patpwd
     -setMasterRepStart subscriber1
    
  19. Start the replication agent for the duplicated subscriber data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart subscriber1
    
  20. Repeat Step 15 through Step 19 for each other subscriber data store.

Upgrading the data stores in an active standby pair with cache groups

This section includes the following topics:

Upgrades for TimesTen patch releases on the standby master data store and subscriber stores

To upgrade to a TimesTen patch release on the standby master data store and subscriber stores, complete the following tasks on each store:

  1. Stop the replication agent on the data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for standby data store master2, you may use:

    ttAdmin -repStop master2
    
  2. Stop the cache agent on the data store using the ttCacheStop built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStop master2
    
  3. Install the TimesTen patch. See "Performing an in-place data store upgrade".

  4. Restart the cache agent using the ttCacheStart built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStop master2
    
  5. Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master2
    

Upgrades for TimesTen patch releases on the active master data store

To upgrade the active master data store, you must first reverse the roles of the active and standby master data stores, and then perform an in-place upgrade:

  1. Pause any applications that are generating updates on the active master data store.

  2. Execute the ttRepSubscriberWait built-in procedure on the active master data store, using the DSN and host of the standby master data store. For example, to ensure that all transactions are replicated to the standby master master2 on the host master2host, use:

    call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
    
  3. Stop the replication agent on the current active master data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master data store master1, use:

    ttAdmin -repStop master1
    
  4. Stop the cache agent on the current active master data store using the ttCacheStop built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStop master1
    
  5. Execute the ttRepDeactivate build-in procedure on the current active master data store. This puts the store in the IDLE state:

    call ttRepDeactivate;
    
  6. On the standby master data store, set the data store to the ACTIVE state using the ttRepStateSet built-in procedure. This store becomes the active master in the active standby pair:

    call ttRepStateSet( 'ACTIVE' );
    
  7. Resume any applications that were paused in Step 1, connecting them to the data store that is now acting as the active master (in this example, data store master2).

  8. Upgrade the former active master data store, which is now the standby master data store. See "Performing an in-place data store upgrade".

  9. Restart the cache agent on the upgraded data store using the ttCacheStart built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStart master1
    
  10. Restart replication on the upgraded data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master1
    
  11. If you want to make the newly upgraded data store the active master data store again, see "Reversing the roles of the active and standby master data stores" in Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

Upgrades for major TimesTen releases, application software and hardware

When you upgrade an active standby pair across major releases of TimesTen, you must explicitly specify the TCP/IP port for each data store. If your active standby pair replication scheme is not configured with a PORT attribute for each data store, you must prepare for the upgrade by following these steps:

  1. Tell the active master data store to stop replicating updates to the standby master by executing the ttRepStateSave built-in procedure on the active master data store. For example, to stop replication to the standby master data store master2 on host master2host, use:

    call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
    
  2. Stop the replication agent on every data store using the call ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent on the data store master1, use:

    ttAdmin -repStop master1
    
  3. On the active master data store, use the ALTER ACTIVE STANDBY PAIR statement to specify a PORT attribute for every data store in the active standby pair. For example, to set a PORT attribute for the data stores master1 on the host master1host, master2 on the host master2host, and subscriber1 on the host subscriber1host, use:

    ALTER ACTIVE STANDBY PAIR
     ALTER STORE master1 ON "master1host" SET PORT 30000
     ALTER STORE master2 ON "master2host" SET PORT 30001
     ALTER STORE subscriber1 ON "subscriber1host" SET PORT 30002;
    
  4. Destroy the standby master data store and all of the subscribers using the ttDestroy utility. For example, to destroy the data store subscriber1, use:

    ttDestroy subscriber1
    
  5. Follow the normal procedure to start an active standby pair and duplicate the standby and subscriber data stores from the active master. See "Setting up an active standby pair" in Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.

Begin major upgrades on the node with the standby master data store. While this node is being upgraded, there is no standby master data store, and updates on the active master data store are propagated directly to the subscriber stores.

Note:

TimesTen 11.2.1 introduces a new feature called Cache Grid. By default, this feature is enabled, and requires additional configuration before cache groups may be created on a data store. If you are upgrading from a release previous to 11.2.1, you should set the attribute CacheGridEnable to 0 in each DSN definition before beginning. For more information, see the Oracle In-Memory Database Cache User's Guide.
  1. Tell the active master data store to stop replicating updates to the standby master by executing the ttRepStateSave built-in procedure on the active master data store. For example, to stop replication to the standby master data store master2 on host master2host, use:

    call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
    
  2. Stop the replication agent on the standby master data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the standby master data store master2, use:

    ttAdmin -repStop master2
    
  3. Stop the cache agent on the standby master data store using the ttCacheStop built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStop master2
    
  4. Upgrade the node where the standby master data store resides. See "Performing an offline upgrade".

  5. Start the cache agent on the standby master data store using the ttCacheStart built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStart master2
    
  6. Start the replication agent on the standby master data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master2
    

    When the upgraded standby master data store has become synchronized with the active master data store, the upgraded standby master data store moves from the RECOVERING state to the STANDBY state. The upgraded standby master data store also starts sending updates to the subscribers. You can determine when the standby master data store is in the STANDBY state by calling the ttRepStateGet built-in procedure on the standby master data store:

    call ttRepStateGet;
    
  7. Pause any applications that are generating updates on the active master data store.

  8. Execute the ttRepSubscriberWait built-in procedure on the active master data store, using the DSN and host of the standby master data store. For example, to ensure that all transactions are replicated to the standby master master2 on the host master2host, use:

    call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
    
  9. Stop the replication agent on the active master data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master data store master1, use:

    ttAdmin -repStop master1
    
  10. Stop the cache agent on the active master data store using the ttCacheStop built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStop master1
    
  11. On the standby master data store, set the data store to the ACTIVE state using the ttRepStateSet built-in procedure. This store becomes the active master in the active standby pair:

    call ttRepStateSet( 'ACTIVE' );
    
  12. Tell the new active master data store (master2, in our example) to stop replicating updates to what is now the standby master (master1) by executing the ttRepStateSave built-in procedure on the active master data store. For example, to stop replication to the standby master data store master1 on host master1host, use:

    call ttRepStateSave( 'FAILED', 'master1', 'master1host' );
    
  13. Destroy the former active master data store using the ttDestroy utility:

    ttDestroy master1
    
  14. Perform the upgrade on the node where the master data store was destroyed. You do not need to do anything to upgrade the data store itself, since it was destroyed.

  15. If you are upgrading from a release previous to 11.2.1, you must create a user with ADMIN privileges on the current active master data store to duplicate that store. For example, to create the user pat with the password patpwd on the standby master data store, use:

    CREATE USER pat IDENTIFIED BY patpwd;
    GRANT ADMIN TO pat;
    
  16. Duplicate the new standby master data store from the current active master data store using the ttRepAdmin utility. For example, to duplicate the data store master2 on the host master2host to the data store master1, where the cache user ID is terry and the cache password is terrypwd, use the following on the host containing the data store master1:

    ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd
     -cacheuid terry -cachepwd terrypwd -keepCG -setMasterRepStart 
     "DSN=master1;UID=;PWD=;PWDCrypt="
    

    Note:

    Only the instance administrator can create a data store, but the DSN for a data store containing cache groups is often configured with UID, PWD and/or PWDCrypt attributes. To allow the ttRepAdmin utility to create the data store when duplicating, you may specify blank UID, PWD and/or PWDCrypt values in the connection string to connect as the instance administrator.
  17. Start the cache agent on the new standby master data store using the ttCacheStart built-in procedure or the ttAdmin utility:

    ttAdmin -cacheStart master1
    
  18. Start the replication agent on the new standby master data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master1
    
  19. Stop the replication agent on the first subscriber data store using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the subscriber data store subscriber1, use:

    ttAdmin -repStop subscriber1
    
  20. Destroy the subscriber data store using the ttDestroy utility:

    ttDestroy subscriber1
    
  21. Perform the upgrade on the node where the subscriber data store was destroyed.

  22. Duplicate the subscriber data store from the standby master data store using the ttRepAdmin utility:

    ttRepAdmin -duplicate -from master1 -host master1host -uid scott -pwd tiger
     -noKeepCG -setMasterRepStart subscriber1
    
  23. Start the replication agent for the duplicated subscriber data store using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart subscriber1
    
  24. Repeat Step 15 through Step 19 for each other subscriber data store.

Performing a Client/Server online upgrade from TimesTen release 6.0 and above

TimesTen Server is able to talk directly to all user applications linked with TimesTen Client ODBC driver release 6.0 or higher. There are at least two possible ways to upgrade a TimesTen Client/Server installation, depending on your requirements for client access to the data store:

Note:

For security reasons, client/server communication is not normally allowed between TimesTen 7.0 and previous releases. To perform an online upgrade with client/server, you must start the main TimesTen 7.0 daemon with the -insecure-backwards-compat option. See "Communicating with older releases of TimesTen" of the Oracle TimesTen In-Memory Database Operations Guide for more information.

Client/Server online upgrade

To perform an online upgrade of a TimesTen Client/Server system to a new major release 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 data store. Any attempted updates to the data store by the clients fail, and you should stop user applications if necessary.

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

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

  4. Start the new release of TimesTen Server. The client applications now have access to the upgraded data stores.

Note:

Since both releases of TimesTen Server have been configured to listen on the same port in this procedure, if you want to restart the the server for the old release you must first configure it to listen on a different port.

Client/Server online upgrade with continuous access to the data store

The migration of a data store using ttMigrate can be a long process if your data stores are very large. If it is critical that your client applications have nearly continuous access to the data store 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 one copy of the data store. The client applications remain connected to the other, non-upgraded copy of the data store.

  3. Disconnect all clients from the old release of the data store.

  4. Stop the old release of TimesTen Server.

  5. Wait for all updates to finish replicating from the old release of the data store 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 data store with no change to their configurations.

Record of upgrades

If replication is configured on a data store, a new set of tables with the prefix ttrep_schema_version- is created each time that the ttMigrate -r command is used. These tables provide a history of the data store's replication scheme from release to release.

These tables do not take up much space and are helpful when debugging upgrade problems. However, you can drop these tables if you do not experience problems with replication after running ttMigrate.

For example, after two migrations, the data store might contain tables which look like this:

TTREP_SCHEMA_VERSION_004.REPELEMENTS
TTREP_SCHEMA_VERSION_004.REPLICATIONS
TTREP_SCHEMA_VERSION_004.REPPEERS
TTREP_SCHEMA_VERSION_004.REPSTORES
TTREP_SCHEMA_VERSION_004.REPSUBSCRIPTIONS
TTREP_SCHEMA_VERSION_004.REPTABLES
TTREP_SCHEMA_VERSION_004.TTSTORES
TTREP_SCHEMA_VERSION_005.REPELEMENTS
TTREP_SCHEMA_VERSION_005.REPLICATIONS
TTREP_SCHEMA_VERSION_005.REPPEERS
TTREP_SCHEMA_VERSION_005.REPSTORES
TTREP_SCHEMA_VERSION_005.REPSUBSCRIPTIONS
TTREP_SCHEMA_VERSION_005.REPTABLES
TTREP_SCHEMA_VERSION_005.TTSTORES