3 TimesTen Upgrades

Data type compatibility

TimesTen supports a selection of Oracle Database 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 Oracle TimesTen In-Memory Database SQL Reference. Because some Oracle Database 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 setting for the database. See "TypeMode" in 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 before 7.0. However, TimesTen backward-compatible data types are not compatible with TimesTen Cache. Use only Oracle Database data types with TimesTen Cache. To use TimesTen Cache, you must convert any original TimesTen data types to the Oracle Database data types when performing a database migration with ttMigrate, described in Oracle TimesTen In-Memory Database Reference. See "Converting TimesTen data types to Oracle Database data types", following shortly, for details.

Oracle Database data types are not replication-compatible with releases of TimesTen before 7.0. 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 "Preserving TimesTen data types" for more information.

Data type considerations when upgrading from a TimesTen release before 7.0

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

The following subsections cover each approach:

• Converting TimesTen data types to Oracle Database data types

• Preserving TimesTen data types

ttMigrate -r -convertTypesToOra salesdata salesdata.mig

Database character set specification

TimesTen requires a database to be configured to support a specific character set when it is created. The character set for the database is specified using the database attribute DatabaseCharacterSet, described in Oracle TimesTen In-Memory Database Reference. The value of this attribute determines 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 Oracle TimesTen In-Memory Database Operations Guide and "Supported character sets" in Oracle TimesTen In-Memory Database Reference for more information.

Be aware of the following points.

• If you plan to use the database with TimesTen Cache, or you plan to use the ttLoadFromOracle built-in procedure to populate TimesTen tables from an Oracle database, you must specify a value for DatabaseCharacterSet that is the same as the character set specified for the Oracle database to which the TimesTen database connects.

• Replication is not possible between databases with different character sets.

Character set restrictions when upgrading from a TimesTen release before 7.0

If you perform an upgrade from a release before TimesTen 7.0, consider the following important restrictions.

• Because databases created with releases of TimesTen before 7.0 do not have a database character set specified, a special database character set, TIMESTEN8, was created, which allows replication compatibility between databases created by the current release of TimesTen and those created by earlier releases. If you plan to perform the TimesTen 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 a database in an upgraded TimesTen instance with an application linked to a Client ODBC library from a release before TimesTen 7.0, you must specify a DatabaseCharacterSet of TIMESTEN8 in your DSN to ensure compatibility. See "Performing a Client/Server online upgrade".

Database character set conversion

In some cases, you may need to change the configured database character set as part of the upgrade process. There are two particular cases in which a database character set change is required:

• You must change your database character set from the one that you originally specified to a new one that fits your requirements more closely.

• You have specified the database character set as TIMESTEN8 to upgrade from a release of TimesTen before 7.0 using online upgrade with replication or Client/Server. After the upgrade is complete for all databases and client applications, you should convert each database from this special transitional character set to the national character set you prefer to use for your region.

You can use ttMigrate to convert a database from any character set to any other character set by completing the following steps.

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

   ttMigrate -c salesdata salesdata.mig
   

2. Destroy the database, using ttDestroy.

   ttDestroy salesdata
   

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

   DatabaseCharacterSet=WE8ISO8859P1
   

4. Load the database from the file using ttMigrate. TimesTen automatically converts the character data from the character set the file was saved with to the character set specified in the DSN.

   ttMigrate -r salesdata salesdata.mig
   

Online minor upgrade for standby master and subscriber

To perform an online minor upgrade to a new TimesTen patch release for the standby master database and subscriber databases, complete the following tasks on each database. For this procedure, assume there are no cache groups.

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

   ttAdmin -repStop master2
   

2. Install the new TimesTen patch release. See "Performing an in-place upgrade".

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

   ttAdmin -repStart master2
   

Online minor upgrade for active master

To perform an online minor upgrade to a new TimesTen patch release for the active master database, you must first reverse the roles of the active and standby master databases, then perform an in-place upgrade. For this procedure, assume there are no cache groups.

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

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

   call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
   

3. Stop the replication agent on the current active master database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master database master1:

   ttAdmin -repStop master1
   

4. Execute the ttRepDeactivate build-in procedure on the current active master database. This puts the database in the IDLE state:

   call ttRepDeactivate;
   

5. On the standby master database, set the database to the ACTIVE state using the ttRepStateSet built-in procedure. This database 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 database that is now acting as the active master (in this example, database master2).

   Note:

   At this point, replication will not yet occur from the new active database to subscriber databases. Replication will resume after the host for the new standby database has been upgraded and the replication agent of the new standby database is running.

7. Upgrade the TimesTen instance of the former active master database, which is now the standby master database. See "Performing an in-place upgrade".

8. Restart replication on the database in the upgraded TimesTen instance, using the ttRepStart built-in procedure or the ttAdmin utility:

   ttAdmin -repStart master2
   

9. To make the database in the newly upgraded TimesTen instance the active master database again, see "Reversing the roles of the active and standby databases" in Oracle TimesTen In-Memory Database Replication Guide.

Online major upgrade for active standby pair

When you perform an online upgrade for an active standby pair to a new major release of TimesTen, you must explicitly specify the TCP/IP port for each database. If your active standby pair replication scheme is not configured with a PORT attribute for each database, you must use the following steps to prepare for the upgrade. For this procedure, assume there are no cache groups. (Online major upgrades for active standby pairs with cache groups are only supported for read-only cache groups.)

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

   ttAdmin -repStop master1
   

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

   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 database and all of the subscribers using the ttDestroy utility. For example, to destroy the database subscriber1:

   ttDestroy subscriber1
   

4. Follow the normal procedure to start an active standby pair and duplicate the standby and subscriber databases from the active master. See "Setting up an active standby pair with no cache groups" in Oracle TimesTen In-Memory Database Replication Guide.

To upgrade the TimesTen instances of the active standby pair, first upgrade the instance of the standby master. While this node is being upgraded, there is no standby master database, so updates on the active master database are propagated directly to the subscriber databases. Following the upgrade of the standby node, the active and standby roles are switched and the new standby node is created from the new active node. Finally, the subscriber nodes are upgraded.

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

   call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
   

2. Stop the replication agent on the standby master database using the ttRepStop built-in procedure or the ttAdmin utility. The following example stops the replication agent for the standby master database master2.

   ttAdmin -repStop master2
   

3. Use the ttMigrate utility to back up the standby master database to a binary file.

   ttMigrate -c master2 master2.bak
   

   For information about ttMigrate, refer to Oracle TimesTen In-Memory Database Reference

4. Destroy the standby master database, using the ttDestroy utility.

   ttDestroy master2
   

5. Uninstall the old release and install the new release of TimesTen on the standby master host, master2host. See "Installing TimesTen on UNIX systems" or "Installing TimesTen on Windows systems".

6. In the new TimesTen instance on master2host, use ttMigrate to restore the standby master database from the binary file created earlier. (This example performs a checkpoint operation after every 20 megabytes of data has been restored.)

   ttMigrate -r -C 20 master2 master2.bak
   

7. Start the replication agent on the standby master database using the ttRepStart built-in procedure or the ttAdmin utility.

   ttAdmin -repStart master2
   

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

   call ttRepStateGet;
   

8. Pause any applications that are generating updates on the active master database.

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

   call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
   

10. Stop the replication agent on the active master database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master database master1:

    ttAdmin -repStop master1
    

11. On the standby master database, set the database to the ACTIVE state using the ttRepStateSet built-in procedure. This database becomes the active master in the active standby pair.

    call ttRepStateSet( 'ACTIVE' );
    

12. Instruct the new active master database (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 database. For example, to stop replication to the standby master database master1 on host master1host:

    call ttRepStateSave( 'FAILED', 'master1', 'master1host' );
    

13. Destroy the former active master database, using the ttDestroy utility.

    ttDestroy master1
    

14. Uninstall the old release and install the new release of TimesTen on master1host.

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

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

16. Create a new standby master database by duplicating the new active master database, using the ttRepAdmin utility. For example, to duplicate the database master2 on the host master2host to the database master1, use the following on the host containing the database master1:

    ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd
     -setMasterRepStart master1
    

17. Start the replication agent on the new standby master database using the ttRepStart built-in procedure or the ttAdmin utility.

    ttAdmin -repStart master1
    

18. Stop the replication agent on the first subscriber database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the subscriber database subscriber1:

    ttAdmin -repStop subscriber1
    

19. Destroy the subscriber database using the ttDestroy utility.

    ttDestroy subscriber1
    

20. Uninstall the old release and install the new release of TimesTen on the subscriber host.

21. Create the subscriber database by duplicating the new standby master database, using the ttRepAdmin utility, as follows.

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

22. Start the replication agent for the duplicated subscriber database using the ttRepStart built-in procedure or the ttAdmin utility.

    ttAdmin -repStart subscriber1
    

23. Repeat step 18 through step 22 for each other subscriber database.

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

To perform an online minor upgrade to a new TimesTen patch release for the standby master database and subscriber databases, in a configuration with cache groups, complete the following tasks on each database (with exceptions noted).

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

   ttAdmin -repStop master2
   

2. Stop the cache agent on the standby database using the ttCacheStop built-in procedure or the ttAdmin utility:

   ttAdmin -cacheStop master2
   

3. Install the TimesTen patch. See "Performing an in-place upgrade".

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

   ttAdmin -cacheStart master2
   

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

   ttAdmin -repStart master2
   

Online minor upgrade for active master (cache groups)

To perform an online minor upgrade to a new TimesTen patch release for the active master database, in a configuration with cache groups, perform the following steps. You must first reverse the roles of the active and standby master databases, then perform an in-place upgrade.

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

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

   call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
   

3. Stop the replication agent on the current active master database using the ttRepStop built-in procedure or the ttAdmin utility. For example, to stop the replication agent for the active master database master1:

   ttAdmin -repStop master1
   

4. Stop the cache agent on the current active master database 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 database. This puts the database in the IDLE state:

   call ttRepDeactivate;
   

6. On the standby master database, set the database to the ACTIVE state using the ttRepStateSet built-in procedure. This database 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 database that is now acting as the active master (in this example, database master2).

8. Upgrade the TimesTen instance for the former active master database, which is now the standby master database. See "Performing an in-place upgrade".

9. Restart the cache agent on the post-upgrade database using the ttCacheStart built-in procedure or the ttAdmin utility:

   ttAdmin -cacheStart master1
   

10. Restart replication on the post-upgrade database using the ttRepStart built-in procedure or the ttAdmin utility:

    ttAdmin -repStart master1
    

11. To make the post-upgrade database the active master database again, see "Reversing the roles of the active and standby databases" in Oracle TimesTen In-Memory Database Replication Guide.

Online major upgrade for active standby pair (read-only cache groups)

Complete the following steps to perform a TimesTen major upgrade from an 11.2.1.x.x release to an 11.2.2.x.x release in a scenario with an active standby pair with read-only cache groups.

These steps assume an active master database master1 on host master1host and a standby master database master2 on host master2host.

1. On the active master host, run the ttAdmin utility to stop the replication agent for the active master database.

   ttAdmin -repStop master1
   

2. On the active master database, use the DROP ACTIVE STANDBY PAIR statement to drop the active standby pair. For example, from the ttIsql utility:

   Command> DROP ACTIVE STANDBY PAIR;
   

3. On the active master database, use the CREATE ACTIVE STANDBY PAIR statement to create a new active standby pair with the cache groups excluded. Ensure that you explicitly specify the TCP/IP port for each database.

   Command> CREATE ACTIVE STANDBY PAIR master1 ON "master1host",
              master2 ON "master2host"
            STORE master1 ON "master1host" PORT 20000
            STORE master2 ON "master2host" PORT 20010
            EXCLUDE CACHE GROUP cacheuser.readcache;
   

   Note:

   You can use the cachegroups command within the ttIsql utility to identify all the cache groups defined in the database. In this example, readcache is a read-only cache group owned by the cacheuser user.

4. On the active master database, call the ttRepStateSet built-in procedure to set the replication state for the active master database to ACTIVE.

   Command> call ttRepStateSet('ACTIVE');
   

   To verify that the replication state for the active master database is set to ACTIVE, call the ttRepStateGet built-in procedure.

   Command> call ttRepStateGet();
   < ACTIVE, NO GRID >
   1 row found.
   

5. On the active master database, call the ttRepStart built-in procedure to start the replication agent.

   Command> call ttRepStart();
   

6. On the standby master host, run the ttAdmin utility to stop the replication agent for the standby master database.

   ttAdmin -repStop master2
   

7. On the standby master host, run the ttAdmin utility to stop the cache agent for the standby master database.

   ttAdmin -cacheStop master2
   

8. On the standby master host, run the ttDestroy utility to destroy the standby master database. You must either add the -force option or first drop all cache groups.

   ttDestroy -force master2
   

9. Create a new standby master database by duplicating the active master database with the ttRepAdmin utility. For example, to duplicate the master1 database on the master1host host of the master2 database, run the following on the host containing the master2 database.

   ttRepAdmin -duplicate -from master1 -host master1host -UID pat -PWD patpwd 
     -keepCG -cacheUid cacheuser -cachePwd cachepwd master2
   

   Note:

   You need a user with ADMIN privileges defined in the active master database for it to be duplicated. In this example, the pat user identified by the patpwd password has ADMIN privileges.

   To keep the cache group tables, you need a cache administration user while adding the -keepCG option. In this example, the cacheuser user identified by the cachepwd password is a cache administration user.

10. On the new standby master database, use the DROP CACHE GROUP statement to drop all the cache groups.

    Command> DROP CACHE GROUP cacheuser.readcache;
    

11. On the standby master host, run the ttMigrate utility to back up the standby master database to a binary file.

    ttMigrate -c master2 master2.bak
    

12. On the standby master host, run the ttDestroy utility to destroy the standby master database.

    ttDestroy master2
    

13. Uninstall the old release and install the new release of TimesTen on the standby master host. See "Installing TimesTen on UNIX systems" or "Installing TimesTen on Windows systems".

14. In the new TimesTen instance on the standby master host, run the ttMigrate utility to restore the standby master database from the binary file created earlier.

    ttMigrate -r -C 20 master2 master2.bak
    

    Note:

    This example performs a checkpoint operation after every 20 MB of data has been restored.

15. On the standby master database, use the CREATE USER statement to create a new cache administration user.

    Command> CREATE USER cacheuser2 IDENTIFIED BY cachepwd;
    Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE 
               TO cacheuser2;
    

    Note:

    You must create the new cache administration user in the Oracle database and grant the user the minimum set of privileges required to perform cache grid and cache group operations. See "Create users in the Oracle database" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

16. Connect to the standby master database as the cache administration user, and call the ttCacheUidPwdSet built-in procedure to set the new cache administration user name and password. Ensure you specify the cache administration user password for the Oracle database in the OraclePWD connection attribute within the connection string.

    ttIsql "DSN=master2;UID=cacheuser2;PWD=cachepwd;OraclePWD=oracle"
    Command> call ttCacheUidPwdSet('cacheuser2','oracle');
    

17. On the standby master database, call the ttCacheStart built-in procedure to start the cache agent.

    Command> call ttCacheStart();
    

18. On the standby master database, call the ttRepStart built-in procedure to start the replication agent.

    Command> call ttRepStart();
    

    The replication state will automatically be set to STANDBY. You can call the ttRepStateGet built-in procedure to confirm this. (This occurs asynchronously and may take a little time.)

    Command> call ttRepStateGet();
    < STANDBY, NO GRID >
    1 row found.
    

19. On the standby master database, use the CREATE READONLY CACHE GROUP statement to create all the read-only cache groups.

    Command> CREATE READONLY CACHE GROUP cacheuser2.readcache
             AUTOREFRESH INTERVAL 10 SECONDS
             FROM oratt.readtbl
               (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR(32));
    

    Note:

    Ensure that the cache administration user has SELECT privileges on the cache group tables in the Oracle database. In this example, the cacheuser2 user has SELECT privileges on the readtbl table owned by the oratt user in the Oracle database. For more information, see "Create the Oracle Database tables to be cached" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

20. On the standby master database, use the LOAD CACHE GROUP statement to load the data from the Oracle database tables into the TimesTen cache groups.

    Command> LOAD CACHE GROUP cacheuser2.readcache
             COMMIT EVERY 200 ROWS;
    

21. Pause any applications that are generating updates on the active master database.

22. On the active master database, call the ttRepSubscriberWait built-in procedure using the DSN and host of the standby master database. For example, to ensure that all transactions are replicated to the master2 database on the master2host host:

    Command> call ttRepSubscriberWait(NULL,NULL,'master2','master2host',120);
    

23. On the active master database, call the ttRepStop built-in procedure to stop the replication agent.

    Command> call ttRepStop();
    

24. On the active master database, call the ttRepDeactivate built-in procedure to set the replication state for the active master database to IDLE.

    Command> call ttRepDeactivate();
    

25. On the standby master database, call the ttRepStateSet built-in procedure to set the replication state for the standby master database to ACTIVE. This database and its host become the active master in the active standby pair replication scheme.

    Command> call ttRepStateSet('ACTIVE');
    

    Note:

    In this example, the master2 database on the master2host host just became the active master in the active standby pair replication scheme. Likewise, the master1 database on the master1host host is henceforth considered the standby master in the active standby pair replication scheme.

26. On the new active master database, call the ttRepStop built-in procedure to stop the replication agent.

    Command> call ttRepStop();
    

27. On the active master database, use the ALTER CACHE GROUP statement to set the AUTOREFRESH mode of all cache groups to PAUSED.

    Command> ALTER CACHE GROUP cacheuser2.readcache
             SET AUTOREFRESH STATE PAUSED;
    

28. On the active master database, use the DROP ACTIVE STANDBY PAIR statement to drop the active standby pair.

    Command> DROP ACTIVE STANDBY PAIR;
    

29. On the active master database, use the CREATE ACTIVE STANDBY PAIR statement to create a new active standby pair with the cache groups included. Ensure you explicitly specify the TCP/IP port for each database.

    Command> CREATE ACTIVE STANDBY PAIR master1 ON "master1host",
               master2 ON "master2host"
             STORE master1 ON "master1host" PORT 20000
             STORE master2 ON "master2host" PORT 20010;
    

30. On the active master database, call the ttRepStateSet built-in procedure to set the replication state for the active master database to ACTIVE.

    Command> call ttRepStateSet('ACTIVE');
    

31. On the active master database, call the ttRepStart built-in procedure to start the replication agent.

    Command> call ttRepStart();
    

32. Resume any applications that were paused in step 21, connecting them to the new active master database.

33. On the new standby master host, run the ttDestroy utility to destroy the new standby master database.

    ttDestroy master1
    

34. Uninstall the old release and install the new release of TimesTen on the standby master host.

35. Create a new standby master database by duplicating the active master database with the ttRepAdmin utility. For example, to duplicate the master2 database on the master2host host to the master1 database, run the following on the host containing the master1 database:

    ttRepAdmin -duplicate -from master2 -host master2host -UID pat -PWD patpwd 
      -keepCG -cacheUid cacheuser2 -cachePwd cachepwd master1
    

36. On the standby master host, run the ttAdmin utility to start the cache agent for the standby master database.

    ttAdmin -cacheStart master1
    

37. On the standby master host, run the ttAdmin utility to start the cache agent for the standby master database.

    ttAdmin -repStart master1
    

Offline major upgrade for active standby pair (cache groups)

Complete the following steps to perform a TimesTen major upgrade from an 11.2.1.x.x release to an 11.2.2.x.x release in a scenario with an active standby pair with cache groups. You must perform this upgrade offline.

These steps assume an active master database master1 on host master1host and a standby master database master2 on host master2host. (For information about the built-in procedures and utilities discussed here, refer to "Built-In Procedures" and "Utilities" in Oracle TimesTen In-Memory Database Reference.)

1. Stop any updates to the active database before you upgrade.

2. From master1, call the ttRepSubscriberWait built-in procedure to ensure that all data updates have been applied to the standby database, where numsec is the desired wait time.

   call ttRepSubscriberWait(null, null, 'master2', 'master2host', numsec);
   

3. From master2, call ttRepSubscriberWait to ensure that all data updates have been applied to the Oracle database.

   call ttRepSubscriberWait(null, null, '_ORACLE', null, numsec);
   

4. On master1host, use the ttAdmin utility to stop the replication agent for the active database.

   ttAdmin -repStop master1
   

5. On master2host, use ttAdmin to stop the replication agent for the standby database.

   ttAdmin -repStop master2
   

6. On master1host, call the ttCacheStop built-in procedure or use ttAdmin to stop the cache agent for the active database.

   ttAdmin -cacheStop master1
   

7. On master2host, call ttCacheStop or use ttAdmin to stop the cache agent for the standby database.

   ttAdmin -cacheStop master2
   

8. On master1host, use the ttMigrate utility to back up the active database to a binary file.

   ttMigrate -c master1 master1.bak
   

9. On master1host, use the ttDestroy utility to destroy the active database. You must either use the -force option or first drop all cache groups. If you use -force, run the script cacheCleanup.sql afterward.

   ttDestroy -force /data_store_path/master1
   

   The cacheCleanup.sql script is a SQL*Plus script, located in the TimesTen_install_dir/oraclescripts directory, that you run after connecting to the Oracle database as the cache user. It takes as parameters the TimesTen host name and the TimesTen database name (with full path). For information, refer to "Dropping Oracle Database objects used by autorefresh cache groups" in Oracle TimesTen Application-Tier Database Cache User's Guide.

10. Uninstall the old and install the new TimesTen major release on master1host. For details, see "Installing TimesTen on UNIX systems" or "Installing TimesTen on Windows systems".

11. Create a new database in 11.2.2.x.x using ttIsql with DSN connection attribute setting AutoCreate=1. In this new database, create a cache user. The following example is a sequence of commands to execute in ttIsql to create this cache user and give it appropriate access privileges.

    The cache user requires ADMIN privilege to execute the next step, ttMigrate –r. Once migration is complete, you can revoke the ADMIN privilege from this user.

    Command> CREATE USER cacheuser IDENTIFIED BY cachepassword;
    Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE
     TO cacheuser;
    Command> GRANT ADMIN TO cacheuser;
    

12. In the new TimesTen instance on master1host, use the ttMigrate utility as the cache user to restore master1 from the binary file created earlier. (This example performs a checkpoint operation after every 20 MB of data has been restored, and assumes the password is the same in the Oracle database as in TimesTen.)

    ttMigrate -r -cacheuid cacheuser -cachepwd cachepassword -C 20 -connstr
     "DSN=master1;uid=cacheuser;pwd=cachepassword;oraclepwd=cachepassword"
     master1.bak
    

13. On master1host, use ttAdmin to start the replication agent.

    ttAdmin -repStart master1
    

    Note:

    This step also sets the database to the active state. You can then call the ttRepStateGet built-in procedure (which takes no parameters) to confirm the state.

14. On master1host, call the ttCacheStart built-in procedure or use ttAdmin to start the cache agent.

    ttAdmin -cacheStart master1
    

    Then you can use the ttStatus utility to confirm the replication and cache agents have started.

15. Put each automatic refresh cache group into the AUTOREFRESH PAUSED state. This example uses ttIsql:

    Command> ALTER CACHE GROUP mycachegroup SET AUTOREFRESH STATE paused;
    

16. From master1, reload each cache group, specifying the name of the cache group and how often to commit during the operation. This example uses ttIsql:

    Command> LOAD CACHE GROUP cachegroupname COMMIT EVERY n ROWS;
    

    You can optionally specify parallel loading as well. For information about the LOAD CACHE GROUP SQL statement, refer to Oracle TimesTen In-Memory Database SQL Reference.

17. On master2host, use ttDestroy to destroy the standby database. You must either use the -force option or first drop all cache groups. If you use -force, run the script cacheCleanup.sql afterward (as discussed earlier).

    ttDestroy -force /data_store_path/master2
    

18. Uninstall the old and install the new TimesTen major release on master2host.

19. In the new TimesTen instance on master2host, use the ttRepAdmin utility with the -duplicate option to create a duplicate of active database master1 to use as standby database master2. Specify the appropriate administrative user on master1, the cache manager user and password, and to keep cache groups.

    ttRepAdmin -duplicate -from master1 -host master1host -uid pat -pwd patpwd 
    -cacheUid orcluser -cachePwd orclpwd -keepCG master2
    

20. On master2host, use ttAdmin to start the replication agent. (You could optionally have used the ttRepAdmin option -setMasterRepStart in the previous step instead.)

    ttAdmin -repStart master2
    

21. On master2, the replication state will automatically be set to STANDBY. You can call the ttRepStateGet built-in procedure to confirm this. (This occurs asynchronously and may take a little time.)

    call ttRepStateGet();
    

22. On master2host, call the ttCacheStart built-in procedure or use ttAdmin to start the cache agent.

    ttAdmin -cacheStart master2
    

    After this, you can use the ttStatus utility to confirm the replication and cache agents have started.

If you want to create read-only subscriber databases, on each subscriber host you can create the subscriber by using the ttRepAdmin utility -duplicate option to duplicate the standby database. The following example creates subscriber1, using the same ADMIN user as above and the -nokeepCG option to convert the cache tables to normal TimesTen tables, as appropriate for a read-only subscriber.

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

For related information, refer to "Rolling out a disaster recovery subscriber" in Oracle TimesTen In-Memory Database Replication Guide.

Verify that the active standby pair is operating properly

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

1. Verify the following.

   • The active and the standby databases run a TimesTen 11.2.2.x.x release.

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

   • Replication is working.

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

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

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

2. Enter the ttCWAdmin -status -dsn yourDSN command to verify the following.

   • The active database is on a different host than the standby database.

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

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

3. Enter the ttStatus command on the active database to verify the following.

   • The ttCRSactiveservice and ttCRSmaster processes are running.

   • The subdaemon and the replication agents are running.

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

4. Enter the ttStatus command on the standby database to verify the following.

   • The ttCRSsubservice and ttCRSmaster processes are running.

   • The subdaemon and the replication agents are running.

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

Shut down the standby database

Complete these steps to shut down the standby database.

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

   crsctl status resource -n standbyHostName | grep TT
   

2. Use Oracle Clusterware commands to shut down the standby database. The Oracle Clusterware commands stop the Master processes for the standby database, the Daemon process for the TimesTen installation, and the Agent process for the TimesTen installation.

   crsctl stop resource TT_Master_upgrade2_terry_myDSN_1
   crsctl stop resource TT_Daemon_upgrade2_terry_host2
   crsctl stop resource TT_Agent_upgrade2_terry_host2
   

3. Stop the TimesTen main daemon.

   ttDaemonAdmin -stop
   

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

Perform an in-place upgrade for the standby database

Complete these steps for an in-place upgrade of the TimesTen instance for the standby database.

1. Use the setup.sh script from the installation media of your current TimesTen release to do the in-place upgrade. The in-place upgrade uninstalls the previous 11.2.2.x.x installation for the standby database. The new installation for the current release must be installed into the same directory structure.

   The in-place upgrade must keep the following files on the standby database:

   • Standby database files (such as checkpoint files, transaction log files, and so on)

   • sys.odbc.ini

   • ttendaemon.options

   • cluster.oracle.ini

     See "Configuring Oracle Clusterware management with the cluster.oracle.ini file" in Oracle TimesTen In-Memory Database Replication Guide for information about this file.

   • ttcrsagent.options

     See "Install TimesTen on each host" and "Start the TimesTen cluster agent" in Oracle TimesTen In-Memory Database Replication Guide for information related to this file.

   • tnsnames.ora

   See "Sample in-place upgrade".

2. Configure the new installation for Oracle Clusterware.

Start the standby database

Complete these steps to start the standby database.

1. Enter the following ttCWAdmin command to start the TimesTen main daemon, the TimesTen Oracle Clusterware agent process and the TimesTen Oracle Clusterware Daemon process:

   ttCWAdmin -init -hosts localhost
   

2. Start the Oracle Clusterware Master process for the standby database.

   crsctl start resource TT_Master_upgrade2_terry_MYDSN_1
   

Switch the roles of the active and standby databases

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

ttCWAdmin -switch -dsn myDSN

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

Shut down the new standby database

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

crsctl status resource -n host1 | grep TT

Enter commands such as those in "Shut down the standby database". Use the appropriate instance name, instance administrator, DSN, and host name. For example:

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

Perform an in-place upgrade of the new standby database

Enter commands such as those in "Perform an in-place upgrade for the standby database".

Start the new standby database

See "Start the standby database", but use the Master process name obtained by the crsctl status resource command from "Shut down the new standby database", above.

ttCWAdmin -init -hosts localhost
crsctl start resource TT_Master_upgrade2_terry_MYDSN_0

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

The following are sample sys.odbc.ini entries:

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

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

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

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

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

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

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

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

crsctl status resource -n standbyHostName | grep TT

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

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

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

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