| Oracle® TimesTen In-Memory Database Installation Guide 11g Release 2 (11.2.2) E21632-16 |
|
|
View PDF |
| Oracle® TimesTen In-Memory Database Installation Guide 11g Release 2 (11.2.2) E21632-16 |
|
|
View PDF |
This chapter describes the process of upgrading from one release of TimesTen to a newer release of TimesTen. It includes the following topics:
Performing an offline TimesTen upgrade when using Oracle Clusterware
Performing an online TimesTen upgrade when using Oracle Clusterware
Note:
For general information about TimesTen utilities to use during upgrades, refer to "Overview: copying, migrating, and restoring a database".This section covers some areas to consider before upgrading TimesTen:
This section covers data type considerations, particularly those that are relevant if you are upgrading from a release of TimesTen earlier than 7.0. It discusses the following topics.
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.
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:
If you intend to use your database with TimesTen Cache, you must convert your TimesTen data types to Oracle Database data types.
To convert the data types from a release before TimesTen 7.0 to Oracle Database data types, you must use the -convertTypesToOra option for ttMigrate (described in Oracle TimesTen In-Memory Database Reference) when you restore your database as part of your upgrade procedure. For example, if you restore the database salesdata as part of an upgrade procedure, you may use the following to upgrade the data types to Oracle Database data types:
ttMigrate -r -convertTypesToOra salesdata salesdata.mig
See "TimesTen to Oracle Database data type conversions" in Oracle TimesTen In-Memory Database Reference for more information.
Notes:
You cannot perform an online upgrade using replication if you are converting from TimesTen to Oracle Database data types, as data types may only replicate to like data types. (This replication restriction is not an issue when upgrading from TimesTen 7.0 or later and data types have been converted to Oracle Database data types.)
Because the Oracle Database and TimesTen versions of some data types behave slightly differently, you should thoroughly test any applications written for releases of TimesTen before 7.0 with the Oracle Database data types before deploying them with the new release of TimesTen.
If you intend to perform an online upgrade using replication, you must preserve your data types as TimesTen data types. See "Online upgrades with replication" for more information.
If you choose to preserve the data types in a database from a release before TimesTen 7.0 as TimesTen data types, you are not required to use any special options when restoring the database with ttMigrate. The data types from a release before TimesTen 7.0 are automatically restored as TimesTen data types.
Note:
The default
TypeMode setting is 0, for Oracle type mode. In this mode, a data type such as CHAR has the semantics of the Oracle Database 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 database with a TypeMode setting of 1 before restoring the database with ttMigrate (described in Oracle TimesTen In-Memory Database Reference) as part of the upgrade procedure.
See "TypeMode" in Oracle TimesTen In-Memory Database Reference for additional information.
This section covers database character set considerations, including those that are relevant if you are upgrading from a release of TimesTen earlier than 7.0. It discusses the following topics:
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.
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".
Note:
TheTIMESTEN8 database character set is intended for use only when transitioning from a release of TimesTen before 7.0. When you no longer need your database to replicate to a pre-7.0 release of TimesTen, or to connect to a pre-7.0 client application, you should use ttMigrate, described in Oracle TimesTen In-Memory Database Reference, to convert your database to a database character set other than TIMESTEN8. See the next section, "Database character set conversion", for details.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.
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
Destroy the database, using ttDestroy.
ttDestroy salesdata
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
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
Notes:
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.
If you are upgrading from a release earlier than TimesTen 7.0 and converting from the TIMESTEN8 character set, use the ttMigrate -noCharsetConversion option. This 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 salesdata salesdata.mig
As noted in "Considerations for locations of database files and other user files", it is strongly recommended that you not store any database files or user files under the TimesTen installation path, where they may be removed during upgrade or uninstallation operations.
If, however, you do have databases under the installation directory, you can use the following general steps to move each database elsewhere:
Use the ttBackup utility to back up the database.
Use the ttDestroy utility to destroy the database.
Update the DSN definition for the database so that the DataStore and LogDir connection attributes reference a location outside of the installation path.
Use the ttRestore utility to restore the database to the new location.
For more information about these utilities and attributes, see "Utilities" and "Connection Attributes" in Oracle TimesTen In-Memory Database Reference.
Access control is mandatory in TimesTen beginning with release 11.2.1. If you have been using earlier releases of TimesTen without access control and you do not want to initially secure your database objects after upgrading to the current release, you can grant the ADMIN system privilege to PUBLIC using the following SQL command:
GRANT ADMIN TO PUBLIC;
If you grant the ADMIN privilege to PUBLIC, all users have unrestricted access to all database objects and are able to perform all administrative tasks, except for those tasks that must be performed as the instance administrator. Granting the ADMIN privilege to PUBLIC should be viewed as a temporary workaround, for upgrade purposes only.
Note:
This is never recommended as a long-term approach, as it results in an inherently insecure system.When using the ttMigrate utility to upgrade a database that is part of a replication scheme, you must restore the replication scheme (using ttMigrate -r) to the same database from which it was originally created (using ttMigrate -c). Attempting to restore the migration file to a different database results in an error, and the replication scheme will not be restored.
The type of upgrade you can perform—in-place, online, or offline—depends on the level of upgrade—major or minor—among other factors. A major upgrade is one between different major releases of TimesTen, such as from 11.2.1.x.x to 11.2.2.x.x. By contrast, TimesTen databases from different patch releases of the same major release are structurally equivalent or identical, so upgrading to a new patch release, such as from 11.2.2.6.0 to 11.2.2.7.0, is considered a minor upgrade.
The following subsections describe the types of upgrades:
For a minor upgrade, you are generally not required to migrate your existing databases and can perform an in-place upgrade (on UNIX systems only).
For a major upgrade, you can usually perform an online upgrade, depending on your situation.
Situations that require offline upgrades are noted in that section.
Important:
There are steps you should take before performing any upgrade:While preparing for the upgrade, ensure that all databases are unloaded from memory before upgrading TimesTen. For a description of the procedures for unloading a database from memory, see "Unloading a database from memory".
During the installation of any new release, you should disconnect your application. The TimesTen daemon process from the prior release is stopped during uninstallation, effectively disconnecting all applications that were still connected to any databases in the instance.
In-place upgrades are available on UNIX systems for moving to a new patch release of TimesTen, such as from release 11.2.2.6.0 to release 11.2.2.7.0. There are also equivalent uninstallation and installation steps you can perform on Windows systems.
To perform an in-place upgrade, use the UNIX installer option to upgrade an existing instance. The uninstallation of the old release and installation of the new release take place in a single operation. New software libraries and binaries are installed in the same location as before. If you choose default responses, existing databases will be preserved (assuming they were not located under the install_dir directory) without the necessity of using the TimesTen backup and migration utilities.
During the in-place upgrade, all applications must disconnect from databases in the TimesTen instance being upgraded.
On Windows systems, you can perform equivalent steps to move between patch releases by first uninstalling TimesTen, keeping your DSNs when prompted, then installing the new release. As with an in-place upgrade on UNIX, this does not require use of the backup and migration utilities.
See "Performing an in-place upgrade".
Important:
Before upgrading, ensure that you do not have any databases or important files under the TimesTen installation directory. See "Considerations for locations of database files and other user files" and "Location of existing database files" for related information.While an offline upgrade is in progress, databases are not available to applications. Offline upgrades usually require enough disk space for two copies of each database in the TimesTen instance being upgraded.
You can use offline upgrades to do the following:
Move to a new major release of TimesTen, using ttMigrate.
Move to a new minor or patch release of TimesTen, using ttBackup and ttRestore.
Note:
For a minor or patch upgrade, it is more typical to use an in-place upgrade or Windows equivalent, as discussed in the preceding section, "In-place upgrades".Offline upgrades require all applications to disconnect from TimesTen during the upgrade procedure. Databases must also be unloaded from shared memory. Offline upgrades require you to use the TimesTen ttMigrate utility (for a major upgrade) or ttBackup utility. (See "ttMigrate" and "ttBackup" in Oracle TimesTen In-Memory Database Reference.)
When upgrading to a new major release of TimesTen, you may have a mission-critical database that must remain continuously available to your applications. You can use TimesTen replication to keep two copies of a database synchronized, even when the databases are from different releases of TimesTen, allowing your applications to stay connected to one copy of the database while the TimesTen instance for the other database is being upgraded. When the upgrade is finished, any updates that have been made on the active database are transmitted immediately to the database in the upgraded TimesTen instance, and your applications can then be switched with no data loss and no downtime. For more information, see "Performing an online upgrade with replication".
The online upgrade process supports only updates to user tables during the upgrade. Data definition changes such as CREATE TABLE or CREATE INDEX are not replicated. In addition, all tables to be replicated must have a PRIMARY KEY or a unique index on non-nullable columns.
Because two copies of the database (or two copies of each database, if there are more than one) are required during the upgrade, you must have available twice the memory and disk space normally required, if performing the upgrade on a single system.
Notes:
Online major upgrades for active standby pairs with cache groups are only supported for read-only cache groups.
Online major upgrades for active standby pairs that are managed by Oracle Clusterware are not supported.
Replication is not supported between 32-bit and 64-bit databases. Tables migrated using the ttMigrate -inline command should not be replicated with tables that do not have inline columns, as inline columns cannot be replicated with not inline columns.
If you are upgrading a TimesTen Client/Server installation to a new major release, you can minimize downtime by performing a Client/Server online upgrade. During this process, TimesTen clients from the previous release are able to continue to communicate with a database in a TimesTen instance that has been upgraded to the new release. See "Performing a Client/Server online upgrade".
The Client/Server online upgrade process minimizes, but does not eliminate, the interruption of client application access to the database in the TimesTen instance being upgraded. To maintain nearly continuous availability of a database to all clients, you may use the approach discussed in the preceding section, "Online upgrades with replication". This procedure keeps an identical copy of the database available to the old release of TimesTen Server, while you perform the upgrade. Once the original database is available to the new release of TimesTen Server, you may stop the old release and start the new release, listening on the same port. The only interruption in availability using this method is the very brief period after the old server is stopped and before the new server is started.
You can perform an in-place upgrade of a TimesTen instance on a UNIX system if you are moving between patch releases (staying within the same major TimesTen release), such as upgrading from one 11.2.2.x.x release to a higher 11.2.2.x.x release. This does not require migrating the databases.
On Windows systems, there is no installer option for such an upgrade. Instead, even when just moving between patch releases, you must perform a separate uninstallation and installation of TimesTen. As with an in-place upgrade on UNIX, migrating the databases is not required.
Before the upgrade, for each database in the instance, all applications must disconnect from the database and the database must be unloaded from shared memory.
The following subsections discuss the process for performing an in-place upgrade or Windows equivalent:
A TimesTen database remains loaded in shared memory if any applications or TimesTen agents, such as the cache agent or replication agent, are connected to it. A database may also be kept in shared memory for particular RAM policy configurations set using the ttAdmin utility, even when no applications or agents are connected. (See "ttAdmin" in Oracle TimesTen In-Memory Database Reference.)
Use the following steps to unload a database from memory in a TimesTen instance being upgraded. All steps must be completed for each database in the TimesTen instance.
Disconnect all applications from the database.
If the replication agent is running on the database, set the replication state to pause and stop the replication agent. This example references an active standby pair, activedb and standbydb, where activedb belongs to the TimesTen instance being upgraded. The example sets the replication state from activedb to standbydb to pause, then stops the replication agent on activedb. Assume standbydb does not belong to the TimesTen instance being upgraded.
ttRepAdmin -receiver -name activedb -state pause standbydb ttAdmin -repStop activedb
If the cache agent is running on the database, stop the cache agent. This example references a database cachedb that uses TimesTen Cache and belongs to the TimesTen instance being upgraded. (The example does not consider replication. If the cache agent is running, this step must be performed regardless of whether the database is configured for replication.)
ttAdmin -cacheStop cachedb
Unload the database from memory using ttAdmin. The first example assumes RAM policy is set to manual and references a database upgradedb that belongs to the TimesTen instance being upgraded. (The example does not consider replication or cache. This step must be performed regardless of whether the database is configured for replication or cache.)
ttAdmin -ramUnload upgradedb
Or, if the RAM policy is set to always, change it to manual, then unload the database from memory. For example:
ttAdmin -ramPolicy manual -ramUnload upgradedb
Or, 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. This results in the database being unloaded. For example:
ttAdmin -ramGrace 0 upgradedb
Use the ttStatus utility to verify that the database has been unloaded from memory. The utility will indicate "There are no connections to the data store." (When a database is loaded into memory, there are automatic subdaemon connections.)
See "ttStatus" in Oracle TimesTen In-Memory Database Reference.
Optionally stop the TimesTen daemon. (During an in-place upgrade, the daemon is automatically stopped.)
ttDaemonAdmin -stop
Also see "Reloading a database into memory", following shortly.
Note:
Theactivedb, cachedb and upgradedb databases, for example, can be the same database. A TimesTen database can have both replication and cache configured, and a RAM policy other than manual.To perform an in-place upgrade on a UNIX system, use the TimesTen installer option to upgrade an existing instance (not install a new instance). UNIX installer options are covered in "Installing TimesTen".
The uninstallation of the old release and installation of the new release take place in a single process. New software libraries and binaries are installed in the same location as before. You are prompted whether to remove files in install_dir/info and install_dir/network/admin/samples. Presuming you choose the default "no" responses, existing databases will be preserved (assuming they were not located under the install_dir directory) and their configurations will be preserved (in the info directory) without the databases having to be migrated.
On Windows systems, there is no installer option for such an upgrade. Instead, when moving between patch releases (staying within the same major TimesTen release), you must perform an uninstallation of TimesTen followed by an installation of the new release. Uninstallation on Windows is covered in "Uninstalling TimesTen on Windows systems". Presuming you choose to save your DSNs while uninstalling, existing databases will be preserved (assuming they were not located under the install_dir directory) and their configurations will be preserved without the databases having to be migrated. Installation on Windows is covered in "Installing TimesTen".
Important:
Before upgrading, ensure that you do not have any databases or important files under the TimesTen installation directory. See "Considerations for locations of database files and other user files" and "Location of existing database files" for related information.After unloading the databases from memory (as shown in "Unloading a database from memory") and upgrading the TimesTen instance, use commands such as the following to reload a database into memory. (These examples are independent of each other.) Such steps must be performed, as applicable, for each database in the instance that was upgraded.
Confirm the TimesTen daemon has started. (During an in-place upgrade, the daemon should start automatically.) If necessary:
ttDaemonAdmin -start
Use ttAdmin to reload the database into memory. If the RAM policy was manual for the database upgradedb before the upgrade:
ttAdmin -ramLoad upgradedb
Or, if the RAM policy was always before the upgrade, change it back to always. This results in the database being reloaded. For example:
ttAdmin -ramPolicy always upgradedb
Or, if the RAM policy is inUse and you changed the grace period to 0, change it back to its original setting. For example:
ttAdmin -ramPolicy inUse -ramGrace 300 upgradedb
To restart replication (assuming activedb of an active standby pair was in the TimesTen instance being upgraded):
ttRepAdmin -receiver -name activedb -state start standbydb ttAdmin -repStart activedb
To restart TimesTen Cache (assuming cachedb uses cache and was in the TimesTen instance being upgraded):
ttAdmin -cacheStart cachedb
You can do an offline upgrade by exporting any database into an external file and then importing the database with the desired changes. These upgrade procedures require that all applications be disconnected from the database and that the database be unloaded from shared memory. For applications that require continuous availability, see "Performing an online upgrade with replication".
This section covers the following topics:
These procedures are for standalone TimesTen databases. Replication and TimesTen Cache scenarios are not considered here.
You can have multiple TimesTen major releases installed on a system at the same time. However, TimesTen databases created by one major release cannot be accessed directly by applications of a different major release. To migrate data between TimesTen major releases, for example from TimesTen 11.2.1 to 11.2.2, you must export the data using the ttMigrate utility from the old release and import it using the ttMigrate utility from the new release.
Note:
For additional information about particular scenarios where an offline upgrade is required for a major TimesTen upgrade, see "Offline upgrades for an active standby pair with cache groups" and "Performing an offline TimesTen upgrade when using Oracle Clusterware".The general steps in an offline upgrade include the following. This procedure assumes you will install the new release while the old release is still installed, which is generally advisable until you are sure databases are correctly configured and fully operational on the new release.
On the old release, for each database:
Disconnect all applications from the database.
Use ttMigrate with the -c option to save a copy of the database contents. For example:
ttMigrateCS -c salesdata salesdata.dat
Unload the database from memory. For more information, see "Unloading a database from memory". For an offline upgrade, stop the TimesTen daemon (ttDaemonAdmin -stop) after unloading the database from memory.
As necessary, use the ttDestroy utility to destroy the old database. This step is required if the new database will be in the same location as the old database.
Important: It is advisable to first use ttBackup to back up the database, as a precaution. The backup can be deleted once the database is fully operational on the new release.
Once the preceding steps have been completed for each database, install the new release of TimesTen. For more information, see Chapter 1, "TimesTen Installation".
Then confirm that the PATH and LD_LIBRARY_PATH environment variables on your system are set appropriately to point to the new TimesTen release.
On the new release, for each database:
Confirm the DataStore connection attribute is set correctly after the upgrade.
Recreate the database using AutoCreate=1, such as in the following example:
ttIsql -connstr "dsn=salesdata;AutoCreate=1" -e "quit"
The database will be empty at this point.
Use ttMigrate with the -r and (typically) -relaxedUpgrade options to restore the backed up database to the new TimesTen release. For example:
ttMigrate -r -relaxedUpgrade salesdata salesdata.dat
Once databases are correctly configured and fully operational on the new release, optionally uninstall the old release. Uninstallation is also covered in Chapter 1, "TimesTen Installation".
You can use the ttBackup and ttRestore utilities to move to a new minor or patch release within the same major release line.
Notes:
For a minor or patch upgrade, it is more typical to use an in-place upgrade or Windows equivalent, as discussed in "Performing an in-place upgrade".
On Windows, you cannot have two different releases from the same major release (such as 11.2.2.6.0 and 11.2.2.7.0) installed simultaneously on the same system.
The general steps in an offline upgrade to a new minor or patch release include the following.
On the old release, for each database:
Disconnect all applications from the database.
Back up the database on the original system using ttBackup. For example:
ttBackup -dir /tmp/dump -fname salesdata SalesData
Unload the database from memory. For more information, see "Unloading a database from memory". For an offline upgrade, stop the TimesTen daemon (ttDaemonAdmin -stop) after unloading the database from memory.
As necessary, use the ttDestroy utility to destroy the old database. This step is required if the new database will be in the same location as the old database.
Once the preceding steps have been completed for each database, uninstall the old release and install the new release of TimesTen. For more information, see Chapter 1, "TimesTen Installation".
Then confirm that the PATH and LD_LIBRARY_PATH environment variables on your system are set appropriately to point to the new TimesTen release.
On the new release, for each database:
Confirm the DataStore connection attribute is set correctly after the upgrade.
Restore the backup on the new system using ttRestore. For example:
ttRestore -dir /tmp/dump -fname salesdata SalesData
"Performing an offline upgrade" discussed how to perform various maintenance operations on TimesTen databases 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.
Typically, applications that require high availability of their data use TimesTen replication to keep at least one extra copy of their databases up to date. An online upgrade works by keeping one of these two copies available to the application while the other is being upgraded. The procedures described in this section assume that you have a bidirectional replication scheme configured and running for two databases, as described in "Unidirectional or bidirectional replication" in Oracle TimesTen In-Memory Database Replication Guide.
Be aware of the following:
Replication functions across releases only if the database of the more recent release of TimesTen was upgraded from a database of the older release of TimesTen. A database created in the more recent release of TimesTen is not guaranteed to replicate correctly with the older release. For example, replication between a database created in a 7.0.6.x.x release of TimesTen and a database created in an 11.2.2.x.x release of TimesTen is not supported. However, if one database was created in the 7.0.6.x.x release, and the peer database was also created in the 7.0.6.x.x release and then migrated to a TimesTen 11.2.2.x.x release, replication between them is supported.
For active standby pairs, as applicable, see "Online upgrades for an active standby pair with no cache groups" and "Online upgrades for an active standby pair with cache groups". Online major upgrades for active standby pairs with cache groups are only supported for read-only cache groups. Instead see "Offline upgrades for an active standby pair with cache groups".
For use of Oracle Clusterware, as applicable, see "Performing an online TimesTen upgrade when using Oracle Clusterware". Online major upgrades are not supported for active standby pairs managed by Oracle Clusterware. Instead see "Performing an online TimesTen upgrade when using Oracle Clusterware".
The following sections describe how to perform an online upgrade with replication.
Upgrading a database from an older TimesTen release to a newer release is performed by disconnecting all applications from one of two replicated copies of a database, making a backup of the database with the ttMigrate utility from the older release, loading the backup into a newer release database using the ttMigrate utility from the newer release, and then reconnecting all applications to the database in the upgraded TimesTen instance.
The general steps in an online upgrade include the following.
Disconnect all applications from the database in the TimesTen instance being upgraded.
Shut down replication in the TimesTen instance being upgraded.
Back up the database residing in the TimesTen instance being upgraded using the older release's ttMigrate with the -c option.
Install the newer release of TimesTen on the system being upgraded.
Restore the replicated database in the upgraded TimesTen instance using the newer release's ttMigrate with the -r option.
Restart replication on the upgraded TimesTen instance.
Reconnect all applications to the database in the upgraded TimesTen instance.
Note:
AfterttMigrate has been used, all autorefresh cache groups in post-upgrade database that is not part of an active standby pair have AUTOREFRESH STATE set to OFF, no matter how it was set on the database before 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 database while the upgrade is performed on the TimesTen instance of the disconnected copy of the database. TimesTen replication retains updates made to the active copy of the database during the upgrade period, and then transfers and applies the updates to the post-upgrade database when replication is restarted. When the replicated updates have been completely applied, the applications may be reconnected to the post-upgrade database.
Online upgrades can be performed only with databases for which all the user tables meet the replication requirements. All the user tables must contain either a PRIMARY KEY declaration or have a unique index declared over non-nullable columns.
To perform online upgrades with replication, replication must be configured to use static ports. See "Port assignments" in Oracle TimesTen In-Memory Database Replication Guide.
If you are performing an online upgrade on a single system where a bidirectional replication configuration does not exist, you must ensure that enough memory and disk space are available to support two copies of the database where the upgrade is being performed. Both the original database and its copy remain active for the duration of the upgrade. To maintain the performance of your production applications, you may want to create the copy of the database on a second system.
Additional disk space must be allocated to hold a backup copy of the database made by the ttMigrate utility. The size of the backup copy is typically about the same as the in-use size of the database. This size may be determined by querying the sys.monitor table, using ttIsql:
Command> SELECT perm_in_use_size FROM sys.monitor;
The following timeline illustrates the steps for performing an online upgrade while replication is running. The upgrade system is the system on which the database upgrade is being performed, and the active system is the system containing the database to which the application remains connected.
Note:
The following steps are for a standard upgrade. Upgrading from a database in TimesTen 11.2.1 that has the connection attributeReplicationApplyOrdering set to 0, or from a database in TimesTen 11.2.1 or TimesTen 11.2.2 that has ReplicationParallelism set to <2, requires that you re-create the database, even if the releases are from the same major release line.After the above procedures are carried out on the upgrade system, the active system can be upgraded using the same steps.
This section describes how to perform an online upgrade in a scenario with two bidirectionally replicated TimesTen databases, using a specific example.
Note:
TimesTen 11.2.1 introduced the cache grid feature. By default, this feature is enabled, and requires additional configuration before cache groups may be created on a database. If you are upgrading an environment containing cache groups from a release preceding 11.2.1, you should set theCacheGridEnable attribute to 0 in each DSN definition before beginning. For more information, see "Create a cache grid" in Oracle TimesTen Application-Tier Database Cache User's Guide.In the following discussion, the two TimesTen systems are referred to as the upgrade system, on which the TimesTen instance (with its databases) is being upgraded, and the active system, which remains operational and connected to the application for the duration of the upgrade. After the procedure is completed, the same steps can be followed to upgrade the active system. However, you may prefer to delay conversion of the active system to first test the upgraded TimesTen instance.
The upgrade system in this example consists of the database upgrade on the server upgradehost. The active system consists of the database active on the server activehost.
Follow the steps listed here in the order they are presented. The online upgrade procedures are as follows.
| Step | Upgrade system | Active system |
|---|---|---|
| 1. | Use ttIsql to alter the replication scheme repscheme, setting static replication port numbers so that the databases can communicate across releases:
|
Use ttIsql to alter the replication scheme repscheme, setting static replication port numbers so that the databases can communicate across releases:
|
| 2. | Disconnect all production applications connected to the database. 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 database active to the database upgrade:
ttRepAdmin -receiver -name upgrade -state pause active This command temporarily stops the replication of updates from the database |
| 3. | Wait for all replication updates to be sent to the database active. You can verify that all updates have been sent by applying a recognizable update to a table reserved for that purpose on the database upgrade. When the update appears in the database 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 database |
Stop the replication agent with ttAdmin:
ttAdmin -repStop active From this point on, no updates are sent to the database For details on starting and stopping replication agents, see "Starting and stopping the replication agents" in Oracle TimesTen In-Memory Database Replication Guide. |
| 5. | Use ttRepAdmin to stop replication from the database upgrade to the database active:
ttRepAdmin -receiver -name active -state stop upgrade This step prevents |
|
| 6. | Use ttMigrate to back up the database upgrade. If the database is very large, this step could take a significant amount of time. If sufficient disk space is free on the /backup file system, use the following ttMigrate command:
ttMigrate -c upgrade /backup/upgrade.dat |
|
| 7. | If the ttMigrate command is successful, destroy the database upgrade.
To destroy a permanent database ( ttDestroy upgrade To destroy a temporary database ( ttAdmin -ramUnload upgrade |
Restart the replication agent on the database 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 -receiver -name upgrade -start start active |
| 9. | Use ttMigrate to load the backup created in step 6. into the database upgrade for the new release of TimesTen:
ttMigrate -r upgrade /backup/upgrade.dat If the database is temporary ( ttAdmin -ramLoad upgrade Note: In this step, you must use the |
|
| 10. | Use ttRepAdmin to clear the replication bookmark and logs by resetting the receiver state for the database active and then setting replication to the stop state and then the start state:
ttRepAdmin -receiver -name active -reset upgrade ttRepAdmin -receiver -name active -state stop upgrade sleep 10 ttRepAdmin -receiver -name active -state start upgrade sleep 10 Note: The |
|
| 11. | Use ttAdmin to start the replication agent on the new database upgrade and to begin sending updates to the database active:
ttAdmin -repStart upgrade |
|
| 12. | Verify that the database upgrade is receiving updates from the database active. You can verify that updates are sent by applying a recognizable update to a table reserved for that purpose in the database active. When the update appears in upgrade, you know that replication is operational. |
If the applications are still running on the database active, let them continue until the database upgrade has been successfully migrated and you have verified that the updates are being replicated correctly from active to upgrade. |
| 13. | Once you are sure that updates are replicated correctly, you can disconnect all of the applications from the database active and reconnect them to the database upgrade. After verifying that the last of the updates from active are replicated to upgrade, the TimesTen instance with active is ready to be upgraded.
Note: You may choose to delay upgrading the TimesTen instance with |
Active standby pair replication provides high availability of your data to your applications. With active standby pairs, unless you want to perform an upgrade to a new major release of TimesTen in a configuration that also uses asynchronous writethrough cache groups, you can perform an online upgrade to maintain continuous availability of your data during an upgrade of TimesTen. This section describes the following procedures:
Online upgrades for an active standby pair with no cache groups
Online upgrades for an active standby pair with cache groups
Offline upgrades for an active standby pair with cache groups
Note:
Only asynchronous writethrough or read-only cache groups are supported with active standby pairs.This section includes the following topics for online upgrades in a scenario with active standby pairs and no cache groups:
Also see "Performing an online upgrade with replication" for an overview, limitations, and requirements.
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.
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
Install the new TimesTen patch release. See "Performing an in-place upgrade".
Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
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.
Pause any applications that are generating updates on the active master database.
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 );
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
Execute the ttRepDeactivate build-in procedure on the current active master database. This puts the database in the IDLE state:
call ttRepDeactivate;
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' );
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.Upgrade the TimesTen instance of the former active master database, which is now the standby master database. See "Performing an in-place upgrade".
Restart replication on the database in the upgraded TimesTen instance, using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
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.
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.)
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
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;
Destroy the standby master database and all of the subscribers using the ttDestroy utility. For example, to destroy the database subscriber1:
ttDestroy subscriber1
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.
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' );
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
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
Destroy the standby master database, using the ttDestroy utility.
ttDestroy master2
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".
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
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;
Pause any applications that are generating updates on the active master database.
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 );
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
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' );
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' );
Destroy the former active master database, using the ttDestroy utility.
ttDestroy master1
Uninstall the old release and install the new release of TimesTen on master1host.
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;
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
Start the replication agent on the new standby master database using the ttRepStart built-in procedure or the ttAdmin utility.
ttAdmin -repStart master1
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
Destroy the subscriber database using the ttDestroy utility.
ttDestroy subscriber1
Uninstall the old release and install the new release of TimesTen on the subscriber host.
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
Start the replication agent for the duplicated subscriber database using the ttRepStart built-in procedure or the ttAdmin utility.
ttAdmin -repStart subscriber1
Repeat step 18 through step 22 for each other subscriber database.
This section includes the following topics for online minor upgrades in a scenario with active standby pairs and cache groups:
Online minor upgrade for standby master and subscriber (cache groups)
Online major upgrade for active standby pair (read-only cache groups)
Also see "Performing an online upgrade with replication" for an overview, limitations, and requirements.
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).
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
Stop the cache agent on the standby database using the ttCacheStop built-in procedure or the ttAdmin utility:
ttAdmin -cacheStop master2
Install the TimesTen patch. See "Performing an in-place upgrade".
Restart the cache agent on the standby database using the ttCacheStart built-in procedure or the ttAdmin utility:
ttAdmin -cacheStart master2
Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
Note:
Steps 2 and 4, stopping and restarting the cache agent, are not applicable for subscriber databases.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.
Pause any applications that are generating updates on the active master database.
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 );
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
Stop the cache agent on the current active master database using the ttCacheStop built-in procedure or the ttAdmin utility:
ttAdmin -cacheStop master1
Execute the ttRepDeactivate build-in procedure on the current active master database. This puts the database in the IDLE state:
call ttRepDeactivate;
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' );
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).
Upgrade the TimesTen instance for the former active master database, which is now the standby master database. See "Performing an in-place upgrade".
Restart the cache agent on the post-upgrade database using the ttCacheStart built-in procedure or the ttAdmin utility:
ttAdmin -cacheStart master1
Restart replication on the post-upgrade database using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master1
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.
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.
Note:
For more information on the built-in procedures and utilities discussed here, see "Built-in Procedures" and "Utilities" in the Oracle TimesTen In-Memory Database Reference.On the active master host, run the ttAdmin utility to stop the replication agent for the active master database.
ttAdmin -repStop master1
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;
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 thecachegroups 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.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.
On the active master database, call the ttRepStart built-in procedure to start the replication agent.
Command> call ttRepStart();
On the standby master host, run the ttAdmin utility to stop the replication agent for the standby master database.
ttAdmin -repStop master2
On the standby master host, run the ttAdmin utility to stop the cache agent for the standby master database.
ttAdmin -cacheStop master2
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
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 withADMIN 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.
On the new standby master database, use the DROP CACHE GROUP statement to drop all the cache groups.
Command> DROP CACHE GROUP cacheuser.readcache;
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
On the standby master host, run the ttDestroy utility to destroy the standby master database.
ttDestroy master2
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".
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.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.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');
On the standby master database, call the ttCacheStart built-in procedure to start the cache agent.
Command> call ttCacheStart();
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.
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 hasSELECT 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.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;
Pause any applications that are generating updates on the active master database.
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);
On the active master database, call the ttRepStop built-in procedure to stop the replication agent.
Command> call ttRepStop();
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();
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, themaster2 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.On the new active master database, call the ttRepStop built-in procedure to stop the replication agent.
Command> call ttRepStop();
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;
On the active master database, use the DROP ACTIVE STANDBY PAIR statement to drop the active standby pair.
Command> DROP ACTIVE STANDBY PAIR;
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;
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');
On the active master database, call the ttRepStart built-in procedure to start the replication agent.
Command> call ttRepStart();
Resume any applications that were paused in step 21, connecting them to the new active master database.
On the new standby master host, run the ttDestroy utility to destroy the new standby master database.
ttDestroy master1
Uninstall the old release and install the new release of TimesTen on the standby master host.
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
On the standby master host, run the ttAdmin utility to start the cache agent for the standby master database.
ttAdmin -cacheStart master1
On the standby master host, run the ttAdmin utility to start the cache agent for the standby master database.
ttAdmin -repStart master1
Performing a TimesTen major upgrade in a scenario with an active standby pair with asynchronous writethrough cache groups requires an offline upgrade. This is discussed in the subsection that follows.
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.
Note:
This procedure is not supported for upgrading from a 7.0.x or earlier release of TimesTen. For that case, an alternative is to exclude cache groups from your replication scheme before the upgrade, use the procedure for upgrading without cache groups, then include the previously excluded cache groups into the replication scheme after the upgrade. For an upgrade without cache groups, see "Online major upgrade for active standby pair".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.)
Stop any updates to the active database before you upgrade.
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);
From master2, call ttRepSubscriberWait to ensure that all data updates have been applied to the Oracle database.
call ttRepSubscriberWait(null, null, '_ORACLE', null, numsec);
On master1host, use the ttAdmin utility to stop the replication agent for the active database.
ttAdmin -repStop master1
On master2host, use ttAdmin to stop the replication agent for the standby database.
ttAdmin -repStop master2
On master1host, call the ttCacheStop built-in procedure or use ttAdmin to stop the cache agent for the active database.
ttAdmin -cacheStop master1
On master2host, call ttCacheStop or use ttAdmin to stop the cache agent for the standby database.
ttAdmin -cacheStop master2
On master1host, use the ttMigrate utility to back up the active database to a binary file.
ttMigrate -c master1 master1.bak
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.
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".
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 if desired.
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;
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 megabytes 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
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 thettRepStateGet built-in procedure (which takes no parameters) to confirm the state.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.
Put each automatic refresh cache group into the AUTOREFRESH PAUSED state. This example uses ttIsql:
Command> ALTER CACHE GROUP mycachegroup SET AUTOREFRESH STATE paused;
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.
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
Uninstall the old and install the new TimesTen major release on master2host.
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
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
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();
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.
This section discusses the steps for an offline upgrade of TimesTen when using TimesTen with Oracle Clusterware. You have the option of also upgrading Oracle Clusterware, independently, while upgrading TimesTen. (For an online upgrade, see "Performing an online TimesTen upgrade when using Oracle Clusterware".)
Notes:
These instructions apply for either a TimesTen minor upgrade (11.2.2.x.x to higher 11.2.2.x.x) or a TimesTen major upgrade (11.2.1.x.x to 11.2.2.x.x).
TimesTen 11.2.2 supports Clusterware releases 11.2.0.2 and 11.2.0.3 only. (TimesTen 11.2.1 supports Clusterware releases 11.1.0.7, 11.2.0.2, and 11.2.0.3.)
TimesTen does not support Clusterware on Windows platforms.
For this procedure, except where noted, you can execute the ttCWAdmin commands from any host in the cluster. Each command affects all hosts.
Stop the replication agents on the databases in the active standby pair:
ttCWAdmin -stop -dsn advancedDSN
Drop the active standby pair:
ttCWAdmin -drop -dsn advancedDSN
Stop the TimesTen cluster agent. This removes the hosts from the cluster and stops the TimesTen daemon:
ttCWAdmin -shutdown
Upgrade TimesTen on the desired hosts.
To perform a TimesTen minor upgrade, each node in the cluster must have TimesTen from the same major release line (such as all 11.2.2.x.x releases). You can do an in-place upgrade as discussed in "Performing an in-place upgrade".
To perform a TimesTen major upgrade, you must use ttMigrate as discussed in "Performing an offline upgrade".
Upgrade Oracle Clusterware if desired, according to instructions in Oracle Database documentation:
Select the "Installing and Upgrading" link.
Refer to the Grid Infrastructure Installation Guide for your platform.
Also see "Overview of Upgrading Oracle Clusterware" in Oracle Clusterware Administration and Deployment Guide.
For use with TimesTen, you can upgrade from Clusterware release 11.1.0.7 to 11.2.0.3 or from 11.2.0.2 to 11.2.0.3, but not from 11.1.0.7 to 11.2.0.2.
If you have upgraded Oracle Clusterware, use the ttmodinstall utility (documented in Oracle TimesTen In-Memory Database Reference) to configure TimesTen with Oracle Clusterware. On each host, enter:
ttmodinstall -crs
When ttmodinstall asks permission to overwrite the ttcrsagent.options file, choose yes (the default).
See "Install TimesTen on each host" and "Start the TimesTen cluster agent" in Oracle TimesTen In-Memory Database Replication Guide for information related to ttcrsagent.options.
Start the TimesTen cluster agent. This includes the hosts defined in the cluster as specified in ttcrsagent.options. This also starts the TimesTen daemon.
ttCWAdmin -init
Create the active standby pair replication scheme:
ttCWAdmin -create -dsn advancedDSN
Important: The host from which you run this command must have access to the cluster.oracle.ini file. (See "Configuring Oracle Clusterware management with the cluster.oracle.ini file" in Oracle TimesTen In-Memory Database Replication Guide for information about this file.)
Start the active standby pair replication scheme:
ttCWAdmin -start -dsn advancedDSN
This section discusses how to perform an online rolling in-place minor upgrade for TimesTen, from one TimesTen 11.2.2.x.x release to a higher 11.2.2.x.x release, in a configuration where Oracle Clusterware manages active standby pairs. (For an offline upgrade, see "Performing an offline TimesTen upgrade when using Oracle Clusterware".)
The following topics are covered:
Upgrades for multiple active standby pairs on many pairs of hosts
Upgrades for multiple active standby pairs on a pair of hosts
Notes:
TimesTen 11.2.2 supports Clusterware releases 11.2.0.2 and 11.2.0.3 only. (TimesTen 11.2.1 supports Clusterware releases 11.1.0.7, 11.2.0.2, and 11.2.0.3.)
TimesTen does not support Clusterware on Windows platforms.
The following basic configurations are supported for online rolling in-place upgrades for TimesTen. In all cases, Oracle Clusterware manages the hosts.
One active standby pair on two hosts.
Multiple active standby pairs with one TimesTen database on each host.
Multiple active standby pairs with one or more TimesTen database on each host.
(Other scenarios, such as with additional spare systems, are effectively equivalent to one of these scenarios.)
Note the following assumptions for upgrading TimesTen when using Oracle Clusterware:
The existing active standby pairs are configured and operating properly.
Oracle Clusterware commands are used correctly to stop and start the standby database.
The in-place upgrade does not change the TimesTen environment for the active and standby databases.
The in-place upgrade is from a TimesTen 11.2.2.x.x release to a later TimesTen 11.2.2.x.x release. These instructions are for TimesTen minor upgrades only. Online major upgrades are not currently supported in configurations where Oracle Clusterware manages active standby pairs.
Oracle Clusterware is release 11.2.0.2 or 11.2.0.3.
The in-place upgrade applies to one TimesTen installation on each host.
There are at least two hosts managed by Oracle Clusterware.
Multiple active or standby databases managed by Oracle Clusterware can exist on a host only if there are at least two hosts in the cluster.
Important:
Upgrade Oracle Clusterware if desired, but not concurrently with an online TimesTen upgrade. When performing an online TimesTen minor upgrade in configurations where Oracle Clusterware manages active standby pairs, you must perform the Clusterware upgrade independently and separately, either before or after the TimesTen upgrade.
Be aware that for use with TimesTen, you can upgrade from Clusterware release 11.1.0.7 to 11.2.0.3 or from 11.2.0.2 to 11.2.0.3, but not from 11.1.0.7 to 11.2.0.2.
For upgrading TimesTen when using Oracle Clusterware, online rolling in-place upgrades are not supported when global cache groups are replicated by the active standby pairs.
Note:
Refer to Oracle Database documentation for information about upgrading Oracle Clusterware:Select the "Installing and Upgrading" link.
Refer to the Grid Infrastructure Installation Guide for your platform.
Also see "Overview of Upgrading Oracle Clusterware" in Oracle Clusterware Administration and Deployment Guide.
This section describes the following tasks:
Note:
In examples in the following subsections, the host name ishost2, the DSN is myDSN, the TimesTen instance name is upgrade2, and the instance administrator is terry.Complete these steps to confirm that the active standby pair is operating properly.
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.
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'.
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.
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.
Complete these steps to shut down the standby database.
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
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
Stop the TimesTen main daemon.
ttDaemonAdmin -stop
If the ttDaemonAdmin -stop command gives error 10028, retry the command.
Complete these steps for an in-place upgrade of the TimesTen instance for the standby database.
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
Configure the new installation for Oracle Clusterware.
Complete these steps to start the standby database.
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
Start the Oracle Clusterware Master process for the standby database.
crsctl start resource TT_Master_upgrade2_terry_MYDSN_1
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.
Use the Oracle Clusterware crsctl status resource command to obtain the names of the Master, Daemon, and Agent processes on the host of the new standby database. This example assumes the host host1 and filters the output through grep TT:
crsctl status resource -n host1 | grep TT
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
Enter commands such as those in "Perform an in-place upgrade for the 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
The process to upgrade the TimesTen instances for multiple active standby pairs on multiple pairs of hosts is essentially the same as the process to upgrade the instances for a single active standby pair on two hosts, discussed in the preceding section, "Upgrade tasks for one active standby pair". The best practice is to perform the upgrades for the active standby pairs one at a time.
Use the ttCWAdmin -status command to determine the state of the databases managed by Oracle Clusterware.
Multiple active standby pairs can be on multiple pairs of hosts, as discussed in the preceding section, "Upgrades for multiple active standby pairs on many pairs of hosts". Alternatively, multiple active standby pairs can be on a single pair of hosts. One scenario is for all the active databases to be on one host and all the standby databases to be on the other. A more typical scenario, to better balance the workload, is for each host to have some active databases and some standby databases.
Figure 3-1 shows two active standby pairs on two hosts managed by Oracle Clusterware. The active database called active1 on host1 replicates to standby1 on host2. The active database called active2 on host2 replicates to standby2 on host1. AWT updates from both standby databases are propagated to the Oracle database. Read-only updates from the Oracle database are propagated to the active databases.
Figure 3-1 Multiple active standby pairs on two hosts
This configuration can result in greater write throughput for cache groups and more balanced resource usage. See the next section, "Sample configuration files: multiple active standby pairs on one pair of hosts", for sample sys.odbc.ini entries and a sample cluster.oracle.ini file for this kind of configuration. (See "Configuring Oracle Clusterware management with the cluster.oracle.ini file" in Oracle TimesTen In-Memory Database Replication Guide for information about that file.)
The in-place rolling upgrade process for multiple active standby pairs on a single pair of hosts is similar in nature to the process of upgrading multiple active standby pairs on multiple pairs of hosts, discussed in "Upgrades for multiple active standby pairs on many pairs of hosts".
First, however, if the active and standby databases are mixed between the two hosts, switch all standby databases to one host and all active databases to the other host. Use the ttCWAdmin -switch -dsn DSN command to switch active and standby databases between hosts. Once all the active databases are on one host and all the standby databases are on the other host, follow the steps below to perform the upgrade for the entire "standby" host.
Be aware that in-place upgrades affect the entire TimesTen installation and associated databases on one host.
Verify that the standby databases run on the desired host. Use the ttCWAdmin -status -dsn DSN command and the ttCWAdmin -status command.
Modify the Oracle Clusterware stop commands to stop all Master processes on the host where all the standby databases reside.
Modify the Oracle Clusterware start commands to start all Master processes on the host where all the standby databases reside.
The following subsections contain related samples.
Sample configuration files: multiple active standby pairs on one pair of hosts
Sample scripts: stopping and starting multiple standby processes on one host
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.
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
This section provides a sample in-place upgrade.
% ./setup.sh
There is 1 TimesTen instance installed locally :
1) sb1122 (TimesTen11.2.2.4)
Of the following options :
[1] Install a new instance
[2] Upgrade an existing instance
[3] Display information about an existing instance
[q] Quit the installation
Which would you like to perform? [ 1 ] 2
NOTE: There is only one instance which can be upgraded.
Instance Name : sb1122
Product Installed : TimesTen11.2.2.4
Installation Directory : /scratch/sboand/TimesTen/sb1122
BitLevel : 64
Component Installed : Client/Server and DataManager
Daemon Port : 33333
NOTE: Upgrading will remove the selected instance (and any directories or files
under its path) and then re-install into the same directory. You will
have the option to retain configuration files in :
/scratch/sboand/TimesTen/sb1122/info
Would you like to upgrade this instance? [ yes ]
NOTE: <install_dir>/info contains information related to the data
stores that have been created with this release. If you remove
/scratch/sboand/TimesTen/sb1122/info
you will no longer be able to access your data stores,
nor would you be able to restore nor migrate your data.
Would you also like to remove all files in <install_dir>/info? [ no ]
Would you like to remove the DemoDataStore directory in
/scratch/sboand/TimesTen/sb1122/info/DemoDataStore? [ yes ] no
Would you also like to remove all files in <install_dir>/network/admin/samples? [ no ]
/scratch/sboand/TimesTen/sb1122 Removed (retained <install_dir>/info)
TimesTen uninstall completed.
Of the three components:
[1] Client/Server and Data Manager
[2] Data Manager Only
[3] Client Only
Which would you like to install? [ 1 ]
Upgrading installation in /scratch/sboand/TimesTen/sb1122
Where would you like to create the daemon home directory?
[ /scratch/sboand/TimesTen/sb1122/info ]
The daemon logs will be located in /scratch/sboand/TimesTen/sb1122/info
Would you like to specify a different location for the daemon logs? [ no ]
Installing into /scratch/sboand/TimesTen/sb1122 ...
Uncompressing ...
NOTE: For security, we recommend that you restrict access to the
TimesTen installation to members of a single OS group. Only members of
that OS group will be allowed to perform direct mode connections to
TimesTen, and only members of that OS group will be allowed to perform
operations that access TimesTen data stores, TimesTen files and shared
memory. The OS group defaults to the primary group of the instance
administrator. You can default to this group, choose another OS group
or you can make this instance world-accessible. If you choose to make
this instance world-accessible, all database files and shared memory
are readable and writable by all users.
Restrict access to the TimesTen installation to the group 'g900'? [ yes ]
NOTE: Enabling PL/SQL will increase the size of some TimesTen libraries.
Would you like to enable PL/SQL for this instance? [ yes ]
Do you want to replace the ttendaemon.options file in
/scratch/sboand/TimesTen/sb1122/info? [ yes ] no
NOTE: The existing daemon options file has been retained. The default options
file was written as
/scratch/sboand/TimesTen/sb1122/info/ttendaemon.options.sb1122.
In order to use the 'TimesTen Cache' feature in any databases
created within this installation, you must set a value for the TNS_ADMIN
environment variable. It can be left blank, and a value can be supplied later
using <install_dir>/bin/ttModInstall.
A value for TNS_ADMIN (/scratch/sboand/TimesTen/sb1122/network/admin/samples) was
found in the previous daemon options file.
Please enter a value for TNS_ADMIN (s=skip)?
[ /scratch/sboand/TimesTen/sb1122/network/admin/samples ] s
Installing server components ...
What is the TCP/IP port number that you want the TimesTen Server to listen on?
[ 33334 ]
Do you want to install QuickStart and the TimesTen Documentation? [ no ]
Would you like to install the documentation (without QuickStart)? [ yes ] no
An existing cluster.oracle.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
Would you like to replace the existing cluster.oracle.ini file? [ no ]
The existing cluster.oracle.ini file will be used.
The sample cluster.oracle.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/cluster.oracle.ini.tt1122'.
An existing sys.odbc.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
NOTE: You may not be able to successfully run the demos if you keep your
existing sys.odbc.ini file. If you choose to replace the existing
file, a backup will be made automatically.
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/info/sys.odbc.ini file ? [ no ]
The existing sys.odbc.ini file will be used.
The sample sys.odbc.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/sys.odbc.ini.sb1122'.
An existing tnsnames.ora file has been detected in
/scratch/sboand/TimesTen/sb1122/network/admin/samples.
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/network/admin/samples/tnsnames.ora file ? [ no ]
The existing tnsnames.ora file will be used.
The sample tnsnames.ora file will be saved as
'/scratch/sboand/TimesTen/sb1122/network/admin/samples/tnsnames.ora.tt1122'.
Installing client components ...
An existing sys.ttconnect.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
NOTE: You may not be able to successfully run the Client/Server demos if you keep
your existing sys.ttconnect.ini file. If you choose to replace the existing
file, a backup will be made automatically.
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/info/sys.ttconnect.ini file ? [ no ]
The existing sys.ttconnect.ini file will be used.
The sample sys.ttconnect.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/sys.ttconnect.ini.sb1122'.
Would you like to use TimesTen Replication with Oracle Clusterware? [ no ] yes
A Clusterware installation was detected in /scratch/oracle/crs/app/11.2.0/grid
Please provide the path to the Oracle Clusterware installation on this machine
(s=skip)? [ /scratch/oracle/crs/app/11.2.0/grid ]
NOTE: The TimesTen Clusterware agent port must be the same on all nodes
of the cluster. Please refer to the TimesTen documentation for
additional information.
Please enter a port number for the TimesTen Clusterware agent? [ 33339 ]
Executing '/scratch/oracle/crs/app/11.2.0/grid/bin/olsnodes' ...
Oracle Clusterware is currently configured on the following nodes :
1. host1
2. host2
3. host3
4. host4
5. host5
NOTE: By default, all of the nodes listed above will be added to the TimesTen
Replication with Oracle Clusterware configuration. You can also
specify your own list of nodes based on the list above.
Would you like to specify a node list for TimesTen Replication with Oracle
Clusterware? [ no ] yes
From the nodes above, please provide a list of nodes that you would like to add
(ex: 1,2 or skip)? [ ] 4,5
TimesTen Replication with Oracle Clusterware will be configured for the following nodes :
host4
host5
Are you sure? [ yes ]
Overwrite the existing TimesTen Clusterware options file? [ no ]
The new TimesTen Clusterware options file will be located here :
/scratch/sboand/TimesTen/sb1122/info/ttcrsagent.options.tt1122.
NOTE: The TimesTen daemon startup/shutdown scripts have not been installed.
Run the 'setuproot' script :
cd /scratch/sboand/TimesTen/sb1122/bin
./setuproot -install
This will move the TimesTen startup script into its appropriate location.
The startup script is currently located here :
'/scratch/sboand/TimesTen/sb1122/startup/tt_sb1122'.
The documentation was not installed.
To manually install the documentation, run the command 'setup.sh -installDoc'
The 11.2.2.6 Release Notes are located here :
'/scratch/sboand/TimesTen/sb1122/README.html'
Starting the daemon ...
TimesTen Daemon startup OK.
End of TimesTen installation.
Automatic parallel replication is enabled by default beginning in TimesTen release 11.2.2.2.0. In previous releases of 11.2.2 and in releases of 11.2.1, user-specified replication was available, but automatic parallel replication was not available. Automatic parallel replication with disabled commit dependencies is available in TimesTen release 11.2.2.8.0.
Note:
The values for theReplicationApplyOrdering attribute, documented in Oracle TimesTen In-Memory Database Reference, have changed. Beginning in release 11.2.2.2.0, a value of 0 enables automatic parallel replication. Before release 11.2.2.2.0, a value of 0 disabled user-specified parallel replication. Beginning in release 11.2.2.8.0, a value of 2 enables automatic parallel replication with disabled commit dependencies.You can perform an online or offline upgrade from a database that has not enabled parallel replication to a database of this release that has enabled parallel replication (with or without disabled commit dependencies).
The rest of this section discusses additional considerations along with scenarios where an offline upgrade is required.
Be aware of the following considerations when upgrading systems that use parallel replication:
Consider an active standby pair without parallel replication enabled. To upgrade the TimesTen instances to release 11.2.2.3.0 or higher and use automatic parallel replication (default value of 0 for the ReplicationApplyOrdering attribute), simply use the appropriate procedure for an active standby pair upgrade. See "Performing an upgrade with active standby pair replication".
Consider an active standby pair with no cache groups and automatic parallel replication enabled (value of 0 for the ReplicationApplyOrdering attribute). To upgrade the TimesTen instances to release 11.2.2.8.0 or higher to use automatic parallel replication with disabled commit dependencies (value of 2 for the ReplicationApplyOrdering attribute), use the procedure for an active standby pair online major upgrade. See "Online major upgrade for active standby pair". The value for the ReplicationApplyOrdering attribute must be changed from 0 to 2 before restoring any of the databases. For example:
ttMigrate -r "DSN=master2;ReplicationApplyOrdering=2;ReplicationParallelism=2; LogBufParallelism=4" master2.bak
Note:
You may upgrade a TimesTen database with a replication scheme withReplicationApplyOrdering=2 to a database with ReplicationApplyOrdering=0 by using the same active standby pair online major upgrade procedure.
Automatic parallel replication with disabled commit dependencies supports only asynchronous active standby pairs with no cache groups. For more information, see "Configuring parallel replication" in the Oracle TimesTen In-Memory Database Replication Guide.
You cannot replicate between databases that have the ReplicationParallelism attribute set to greater than 1 but have different values for the ReplicationApplyOrdering attribute.
You must use an offline upgrade for these scenarios:
Moving from user-specified parallel replication to automatic parallel replication. For example, from a release preceding 11.2.2.3.0 to release 11.2.2.3.0 or higher with the ReplicationApplyOrdering attribute set to the default value (0).
Moving from an automatic parallel replication environment to another automatic parallel replication environment with a different number of tracks, as indicated by the value of the ReplicationParallelism attribute.
Moving between major releases (such as from 11.2.1.x.x to 11.2.2.x.x) and using asynchronous writethrough cache groups.
Moving from regular replication with asynchronous writethrough in 11.2.1.x.x to automatic parallel replication with asynchronous writethrough in 11.2.2.x.x.
For offline upgrades, you can use the procedure described in "Performing an offline upgrade". Alternatively, you can upgrade one side and use the ttRepAdmin -duplicate -recreate command to create the new database.
If replication is configured on a database, a new set of tables with the prefix ttrep_schema_version- is created each time the ttMigrate -r command is used. These tables provide a history of the 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 database might contain tables 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
TimesTen Server can 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 database:
If you do not need the database in the TimesTen instance being upgraded to be available continuously to your client applications, you may simply stop the old server, perform the migration of the database using ttMigrate, and then start the new release of the server, which should be configured to listen on the same server port.
If it is critical that the database be continuously available to the client applications, you may use the procedure outlined in "Performing an online upgrade with replication" to keep a second copy of the database available during the migration of the first copy.
To perform an online upgrade of a TimesTen Client/Server system to a new major release (such as from 11.2.1.x.x to 11.2.2.x.x) with minimal reconfiguration, perform the following steps:
Stop the TimesTen Server on the old release of TimesTen. From this point until the TimesTen Server for the new release is started, your client applications do not have access to the database. Any attempted updates to the database by the clients fail, and you should stop user applications if necessary.
Install the new release of TimesTen. At installation time, configure the server to listen on the same port as the old release of TimesTen.
Use ttMigrate to migrate the database from the old release to the new release. See "Moving to a different major release of TimesTen" for an example of this procedure.
Start the new release of TimesTen Server. The client applications now have access to the post-upgrade databases.
Note:
Since both releases of TimesTen Server have been configured to listen on the same port in this procedure, to restart the server for the old release you must first configure it to listen on a different port.The migration of a database using ttMigrate can be a long process if your databases are very large. If it is critical that your client applications have nearly continuous access to the database during the Client/Server online upgrade procedure, you may incorporate the procedure for performing an online upgrade with replication by following these steps:
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".
Follow the steps in "Performing an online upgrade with replication" to upgrade the TimesTen instance for one copy of the database. The client applications remain connected to the other, non-upgraded copy of the database.
Disconnect all clients from the old release of the database.
Stop the old release of TimesTen Server.
Wait for all updates to finish replicating from the old release of the database to the new release.
Start the new release of TimesTen Server. It begins listening on the same port as the old release, and client applications may now connect to the new release of the database with no change to their configurations.
|
 Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|