This chapter describes upgrading from one release of TimesTen to a newer release of TimesTen. It includes the following topics:
Performing an online upgrade with active standby pair replication
Performing an offline TimesTen upgrade when using Oracle Clusterware
Performing an online TimesTen upgrade when using Oracle Clusterware
Performing a Client/Server online upgrade from TimesTen release 6.0 and above
When a TimesTen database is loaded into shared memory, many of its attributes are fixed, including size, logging options, TimesTen software release number, and the location of its checkpoint and transaction log files on disk. This chapter describes the steps required to change these attributes and to upgrade TimesTen databases when you install a new release of TimesTen.
The following sections describe the compatibility and character set of the installed TimesTen release:
In prior releases of TimesTen, release numbers used either five parts (7.0.0.0.0 and later), or three parts (releases before 7.0.0.0.0, such as 6.0.17) to represent the release. Starting with TimesTen release 11.2.1.0.0, five parts are used, with the first three parts, such as 11.2.2, indicating a major release of TimesTen. The fourth part indicates the patch release of a major release, and the fifth part indicates a port patch. For example, TimesTen release number 11.2.2.2.1 indicates the first port patch of the second patch release of TimesTen 11g Release 2 (11.2.2).
TimesTen databases are not compatible between major releases, but they are always compatible between patch releases. For example, a database created with TimesTen release 7.0.5.1.0 is not compatible with a TimesTen release 11.2.1.1.0 application, but a database created with TimesTen 11.2.1.0.0 is compatible with a TimesTen release 11.2.1.1.0 application.
TimesTen supports a selection of Oracle data types in addition to the original TimesTen data types that are maintained for backward compatibility. For details on all data types, see "Type specifications" in the Oracle TimesTen In-Memory Database SQL Reference. Because some Oracle data types have the same names as the backward-compatible TimesTen data types, a set of aliases exists for addressing the data types. Which data types the aliases refer to depends on the TypeMode that is set for the database. See "TypeMode" in the Oracle TimesTen In-Memory Database Reference for more information.
TimesTen backward-compatible data types are replication-compatible with the data types in releases of TimesTen before 7.0. However, TimesTen backward-compatible data types are not compatible with TimesTen IMDB Cache to Oracle— use only Oracle data types with IMDB Cache to Oracle. If you want to use IMDB Cache to Oracle, you must convert any original TimesTen data types to the new Oracle data types when performing a database upgrade with ttMigrate. See "Converting data types to Oracle data types" for details.
Oracle 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 "Upgrading data types as TimesTen data types" for more information.
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. The value of this attribute is used to determine which characters may be input to and output from character fields, and how character data is stored and sorted. See "Choosing a database character set" in the Oracle TimesTen In-Memory Database Operations Guide for more information.
Before upgrading your database from a release before TimesTen 7.0, you must specify a database character set by adding the DatabaseCharacterSet attribute to your database's DSN. This attribute is ignored by releases of TimesTen before 7.0. In most cases, you want to choose a database character set that makes sense for your region and that matches the character data that is present in your database. Consider the following important restrictions, however.
If you plan to use the database with TimesTen IMDB Cache to Oracle, you must specify a value for DatabaseCharacterSet that is the same as the character set specified for the Oracle database that the TimesTen database connects to.
Replication is not possible between databases with different character sets. Because databases created with releases of TimesTen before 7.0 do not have a database character set specified, a special database character set, TIMESTEN8, has been 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 database upgrade as an online upgrade with replication (see "Performing an online upgrade with replication"), then you must specify a DatabaseCharacterSet of TIMESTEN8 in your DSN.
If you use TimesTen Client/Server and intend to connect to the upgraded database 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 from TimesTen release 6.0 and above".
|
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 to convert your database to a database character set other than TIMESTEN8. See "Database character set conversion" for details. |
TimesTen includes three utilities that may be used when upgrading databases.
The ttBackup and ttRestore utilities can export and import, respectively, an image copy of the TimesTen database. This database image is only compatible between patch releases of TimesTen, and it must be backed up and restored using the same bit-level of TimesTen (32-bit or 64-bit). You may use the ttBackup and ttRestore utilities to:
Move a database from one TimesTen instance to another TimesTen instance running the same major release version of TimesTen.
Move a database from one computer to another computer running the same major release version of TimesTen.
Move a database from one patch release of TimesTen (such as 11.2.2.1.0) to a different patch release of TimesTen (such as 11.2.2.2.0).
The ttMigrate utility, however, exports the TimesTen database to a release-neutral format that can be used to migrate the database across major releases and between 32-bit and 64-bit versions of TimesTen. You must use the ttMigrate utility to:
Move a database from one major release of TimesTen (such as 7.0) to a different major release (such as 11.2.2).
Move a database from a 32-bit version of TimesTen to a 64-bit version (or vice versa).
Reduce the size of a TimesTen database.
|
Note: ThettMigrate utility cannot migrate databases across different hardware platforms. For example, you cannot migrate a Windows database to a Solaris database. The release of ttMigrate must also match the release of the database you are copying from or to. In the procedures detailed in the following sections, use the ttMigrate utility in the older version to save the tables of the original database a disk file and use the ttMigrate utility in the new version to restore the file into the new database. |
On Windows, these utilities use the ODBC driver manager.
On UNIX platforms, the utilities are directly linked with the TimesTen Data Manager ODBC driver.
For a full description of the syntax and usage of these and other utilities, see "Utilities" in the Oracle TimesTen In-Memory Database Reference.
Access control is mandatory in TimesTen beginning with release 11.2.1. If you have been using previous versions of TimesTen without access control and you do not want to initially secure your database objects after upgrading to the current release, you can grant the ADMIN system privilege to PUBLIC using the following SQL command:
GRANT ADMIN TO PUBLIC;
If you grant the ADMIN privilege to PUBLIC, all users have unrestricted access to all database objects and are able to perform all administrative tasks, except for those tasks that must be performed as the instance administrator. Granting the ADMIN privilege to PUBLIC should be viewed as a temporary workaround, for upgrade purposes only.
|
Note: This is never recommended as a long-term approach, as it results in an inherently insecure system. |
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 whether to convert them to Oracle data types. Your planned use for the database and your preferred upgrade method have an impact on this decision.
|
Note: If you intend to use your database with TimesTen IMDB Cache, you must convert your data types to Oracle data types. However, you cannot perform an online upgrade using replication in this case, as data types may only replicate to like data types.This is not an issue if you are upgrading from TimesTen 7.0 or later and your data types have been converted to Oracle data types. |
To convert the data types from a release before TimesTen 7.0 to Oracle data types, you must use the -convertTypesToOra option for ttMigrate 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 data types:
ttMigrate -r -convertTypesToOra salesdata salesdata.mig
See "TimesTen to Oracle data type conversions" in the Oracle TimesTen In-Memory Database Reference for more information.
|
Note: Because the Oracle and TimesTen versions of some data types behave slightly differently, you should thoroughly test any applications written for releases of TimesTen before 7.0 with the Oracle data types before deploying them with the new release of TimesTen. |
|
Note: If you intend to perform an online upgrade using replication, you must upgrade your data types as TimesTen data types. See "Online upgrades with replication" for more information. |
If you choose to upgrade the data types in a 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 defaultTypeMode attribute for databases is 0, which indicates Oracle type mode. In Oracle type mode, a data type such as CHAR has the semantics of the Oracle CHAR data type rather than the TimesTen CHAR data type. To guarantee compatibility with applications written for TimesTen releases before 7.0, you should configure the DSN for your database with a TypeMode of 1 before restoring the database with ttMigrate as part of the upgrade procedure. |
A character set must be specified for each TimesTen database using the DSN attribute DatabaseCharacterSet. In some cases, you may need to change the configured database character set as part of the upgrade process. There are two different cases in which a database character set conversion are required:
You have specified the database character set as TIMESTEN8 to upgrade your database 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. See "Converting from the TIMESTEN8 character set".
You must change your database's character set from the one that you originally specified to a new one that fits your requirements more closely. See "Converting from a character set other than TIMESTEN8", following shortly.
You may use ttMigrate to convert a database from TIMESTEN8 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 DSN=salesdata salesdata.mig
Destroy the database:
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 instead of TIMESTEN8, use the following line in your ODBCINI file:
DatabaseCharacterSet=WE8ISO8859P1
Load the database from the file using ttMigrate with the -noCharsetConversion command-line option. This option ensures that no character values are changed when the data is loaded into the DSN using the new character set. For example:
ttMigrate -r -noCharsetConversion DSN=salesdata salesdata.mig
|
Note: If you find that you have accidentally converted your database fromTIMESTEN8 to the wrong character set, you can use the same procedure to convert your database to the correct character set without any accidental modification of the character data. |
You may 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 DSN=salesdata salesdata.mig
Destroy the database:
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 used by the DSN. For example:
ttMigrate -r DSN=salesdata salesdata.mig
|
Note: It is possible that character data is lost in the conversion process if no mapping exists from one character set to the other for a given character. |
TimesTen enables you to perform the following types of upgrades:
TimesTen databases from different patch releases of the same major release are structurally equivalent or identical. For example, when upgrading from release 11.2.2.0.0 to 11.2.2.1.0, you are not required to migrate your existing databases using the ttMigrate utility, unless you change the instance name and or daemon home directory. If you are changing the instance name or the daemon home directory, keep the old installation installed. Install the new installation. Then use the ttAdoptStores utility to move your data stores to the new installation. Review your data stores, then remove the old instance of TimesTen.
However, during the installation of any new release, you should disconnect your application and stop the TimesTen daemon. If you have not explicitly performed these steps, the TimesTen daemon process from the prior release is stopped, effectively disconnecting all applications from the database. 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".
In-place upgrades are available (on UNIX systems only) for moving to a new patch release of TimesTen, such as moving from the first patch release of 11.2.2, release 11.2.2.1.0, to the second patch release of 11.2.2, release 11.2.2.2.0.
In a TimesTen in-place upgrade, software libraries and binaries are updated in place while the TimesTen directory structure and database files remain unchanged.
During the in-place upgrade process, all applications must disconnect from databases in the TimesTen instance being upgraded. This type of upgrade enables you to preserve the existing databases in the TimesTen instance without using the TimesTen backup and migration utilities.
During the time required to perform an offline upgrade, the database is not available to applications. Offline upgrades usually require enough disk space for an extra copy of the upgraded database.
Offline upgrades are used to do the following:
Move to a new major or patch release of TimesTen.
Move to a different directory or computer.
Reduce database size.
Move between 32-bit and 64-bit databases.
Offline upgrades require all applications to disconnect from the database during the upgrade procedure. The database must also be unloaded from shared memory. Offline upgrades require you to use TimesTen's ttMigrate or ttBackup utilities. (See "ttMigrate" and "ttBackup" in Oracle TimesTen In-Memory Database Reference.)
See "Performing an offline upgrade" and "Performing an offline TimesTen upgrade when using Oracle Clusterware".
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 other one is being upgraded. When the upgrade is finished, any updates that have been made on the active database are transmitted immediately to the upgraded database, and your applications can then be switched to the upgraded database with no data loss and no down time. 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 to be upgraded are required, you must have available twice the memory and disk space that the database usually requires, if performing the upgrade on a single system.
In addition to the reference above, also refer to the following topics related to replication:
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 communi cate with a database that has been upgraded to the new release. See "Performing a Client/Server online upgrade from TimesTen release 6.0 and above".
The Client/Server online upgrade process minimizes, but does not eliminate, the interruption of client application access to the database being upgraded. To maintain nearly continuous availability of a database to all clients, you may use the approach outlined in "Online upgrades with replication". This procedure keeps an identical copy of the database available to the old release of TimesTen Server, while you upgrade the original to the new release. Once the upgraded 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 UNIX systems only), which does not require exporting its databases to an external format. Prior to 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:
All steps must be completed for each database in the TimesTen instance.
A TimesTen database remains loaded in shared memory as long as any applications or TimesTen agents, such as the cache agent or replication agent, is connected to it. A database may also be kept in shared memory if the RAM policy of the database has been modified using the ttAdmin utility, even when no applications or agents are connected. (See "ttAdmin" in Oracle TimesTen In-Memory Database Reference.)
Use the following steps to unload a database from memory in a TimesTen instance being upgraded.
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 IMDB cache and belongs to the TimesTen instance being upgraded. (The example does not consider replication.)
ttAdmin -cacheStop cachedb
If the RAM policy is set to manual, unload the database from memory using ttAdmin. This example references a database upgradedb that belongs to the TimesTen instance being upgraded (and does not consider replication or cache):
ttAdmin -ramUnload upgradedb
If the RAM policy is set to always, change it to manual, then unload the database from memory. For example:
ttAdmin -ramPolicy manual -ramUnload upgradedb
If the RAM policy is inUse and a grace period is set, set the grace period to 0 or wait for the grace period to elapse. For example:
ttAdmin -ramGrace 0 upgradedb
Use the ttStatus utility to verify that the databases belonging to the TimesTen instance being upgraded have been unloaded from memory. (See "ttStatus" in Oracle TimesTen In-Memory Database Reference.)
Also see the next section, "Reloading a database into memory".
|
Note: Theactivedb, cachedb and upgradedb databases, for example, can be the same database. A TimesTen database can have both replication and cache configured, as well as a RAM policy other than manual. |
When doing an in-place upgrade (applicable on UNIX systems only), you must use the TimesTen installer option to upgrade an existing instance (not install a new instance). UNIX installer options are covered in "Installing TimesTen".
After unloading the databases from memory (as shown in the preceding section, "Unloading a database from memory") and upgrading the TimesTen instance, use commands such as the following to reload a database into memory. (These examples are independent of each other.) Such steps must be performed, as applicable, for each database in the instance that was upgraded.
To restart replication (assuming activedb of an active standby pair was in the TimesTen instance being upgraded):
ttRepAdmin -receiver -name activedb -state start standbydb ttAdmin -repStart activedb
To restart IMDB cache (assuming cachedb uses cache and was in the TimesTen instance being upgraded):
ttAdmin -cacheStart cachedb
To reload the database into memory (assuming RAM policy was set to manual for the database upgradedb, which was in the TimesTen instance being upgraded):
ttAdmin -ramLoad upgradedb
If you changed the RAM policy from always to manual when you unloaded the database from memory, change it back to always. For example:
ttAdmin -ramPolicy always upgradedb
If the RAM policy was inUse before you unloaded the database from memory and you changed the grace period to 0, change it back to its original setting. For example:
ttAdmin -ramGrace 300 upgradedb
You can do an offline upgrade by exporting the database into an external file and then importing the database with the desired changes. These update 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".
|
Note: If the database to be upgraded is replicated, you must usettMigrate to move the database between releases. |
For simple upgrades that do not require any changes to the size or structure of the database, such as moving between patch releases, you can use the ttBackup and ttRestore utilities. For upgrades that require structural changes to the database, such as major release upgrades, you must use the ttMigrate utility. The ttMigrate utility exports the database in a release-neutral format that is more flexible, while the ttBackup utility exports an image copy of the database that is only compatible across patch releases. The ttBackup utility may be used to move the database to a different computer or directory. The ttMigrate utility must be used if you want to do the following:
Move to a new major or patch release of TimesTen.
Reduce database size.
Move between 32-bit and 64-bit databases.
The general steps in an offline upgrade include:
Disconnect all applications from the database and unload the database from memory. For more information, see "Unloading a database from memory".
Use either ttMigrate with the -c and -relaxedUpgrade options or ttBackup to back up the database.
Install the new release of TimesTen. For more information, see Chapter 1, "TimesTen Installation".
Use either ttMigrate with the -r and -relaxedUpgrade options or ttRestore to restore the backed up database to the new TimesTen release.
Reconnect applications to the upgraded database.
|
Note: AfterttMigrate has been used, all autorefresh cache groups in a destination database that is not part of an active standby pair have AUTOREFRESH STATE set to OFF, no matter how it was set on the source database. Reset AUTOREFRESH STATE to ON by using the ALTER CACHE GROUP statement. |
The TimesTen daemon identifies a database by the full path name of the database's checkpoint files. To move a TimesTen database to a different directory, back up the database using the ttBackup utility, create a new DSN definition that specifies the new database path name, then restore the database into its new location using the ttRestore utility. When you have verified that the database functions properly in the new location, free up the disk space by using ttDestroy to remove the old database.
For example, to move a database from /old/SalesData/sales with a database name SalesData ("DSN=SalesData") to /new/SalesData/sales with database name NewSalesData ("DSN=NewSalesData"), using the /tmp/dump directory for temporary storage, use the following commands:
mkdir /tmp/dump
ttBackup -dir /tmp/dump -fname salesdata "DSN=SalesData"
Create a DSN definition for the NewSalesData database and specify the new database path: /new/SalesData/sales/NewSalesData.
ttRestore -dir /tmp/dump -fname salesdata "DSN=NewSalesData"
(Verify that NewSalesData is operational.)
rm -r /tmp/dump
ttDestroy /old/SalesData/sales/SalesData
Remove the DSN definition for the SalesData database.
|
Note: You must reconfigure replication if the moved database has been configured to replicate. |
You can also use the ttBackup and ttRestore utilities to move a database between two computers that have the same CPU architecture and are running the same operating system.
|
Note: Before moving a replicated database to another computer, you should be experienced with TimesTen replication. We highly advise calling TimesTen customer support for help with this procedure. |
To copy a database from one system to another with the same CPU architecture and operating system:
Back up the database on the original system using ttBackup.
Move the backup to the new system.
Reconfigure the replication scheme on any databases the replicate to the moved database to specify the new host computer. (See "Reversing the roles of the master databases" in Oracle TimesTen In-Memory Database Replication Guide for information relevant in specifying a host in a replication scheme.)
Restore the backup using ttRestore.
The following example uses the -o flag of ttBackup to use standard output for the backup. Using the -o flag, the backup is stored in a single file, which is easily copied over the network to the other system. Once you have copied the database to the other system, you must create a data source name for access to the new database copy.
To move a database from /ds/Sales/Data with database name salesdata on the source system to /data/Sales/View with database name salesview on the destination system, use the following commands.
| Step | On the source system | On the destination system |
|---|---|---|
| 1. | ttBackup -o "DSN=SalesData" >/tmp/salesbackup | |
| 2. | ftp /tmp/salesbackup to the destination system as /tmp/salesbackup
Note: Use the | |
| 3. | ttRestore -i"DSN=SalesView" </tmp/salesbackup | |
| 4. | rm /tmp/salesbackup | |
| 5. | rm /tmp/salesbackup |
Once a database has been defined with a particular size for the permanent partition (indicated by the PermSize DSN attribute), it cannot be loaded at a smaller size, even if tables or rows are deleted. A copy of the database made with ttBackup also has the database's permanent partition size embedded in it.
To reduce the allocated size of the permanent partition of a database, save a copy using the ttMigrate utility with the -relaxedUpgrade option. Then re-create the database with a smaller permanent partition size and restore the data.
|
Note: The permanent partition size of a database cannot be reduced below the size that is actually required by the data currently stored in the database. This value can be determined by querying theperm_in_use_size column of the table sys.monitor. |
Perform these steps to reduce the permanent partition size of a database:
Back up the old database, as follows.
ttMigrate -c -relaxedUpgrade
Create a new DSN definition for the new copy of the database with a smaller PermSize value.
Restore the backup, as follows.
ttMigrate -r -relaxedUpgrade
|
Note: To modify the original DSN rather than create a new one in Step 2, then you must destroy the original database files using thettDestroy utility before restoring from the backup. |
Here are the steps to reduce a database's allocated size from 400 MB to 100 MB. The database is in /ds/Sales/Data and has the DSN salesdata.
ttMigrate -c -relaxedUpgrade DSN=salesdata /tmp/salesbackup
ttDestroy salesdata
Update the DSN salesdata to have a size of 100 MB.
ttMigrate -r -relaxedUpgrade "DSN=salesdata;AutoCreate\=1" /tmp/salesbackup
|
Note: The temporary partition size of a database may be changed by simply modifying theTempSize attribute of the DSN, unloading the database from memory, and then reconnecting to it. See "Unloading a database from memory" for the steps to unload a database from memory. |
The internal format of a 32-bit TimesTen database differs from that of a 64-bit database. To convert a 32-bit database to a 64-bit database:
Export the 32-bit database using the TimesTen 32-bit ttMigrate utility with the -relaxedUpgrade option.
Create a Data Source Name (DSN) for the 64-bit database. See "Creating a Data Manager DSN on UNIX" or "Creating a Data Manager DSN on Windows" in Oracle TimesTen In-Memory Database Operations Guide.
Import the file created in Step 1 into the 64-bit database DSN using the 64-bit ttMigrate utility with the -relaxedUpgrade option.
For example, suppose that the 32-bit database DSN is salesdata32 while the 64-bit database DSN is salesdata64. If a 32-bit instance of TimesTen is installed in /opt/TimesTen/giraffe32 and a 64-bit instance is installed in /opt/TimesTen/giraffe64, the required steps are:
/opt/TimesTen/giraffe32/bin/ttMigrate -c -relaxedUpgrade DSN=salesdata32/tmp/salesbackup
/opt/TimesTen/giraffe64/bin/ttMigrate -r -relaxedUpgrade "DSN=salesdata64;AutoCreate=1"/tmp/salesbackup
|
Note: TimesTen does not support replication between 32-bit and 64-bit databases. |
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 6.0 to 11.2.2, you must export the data using the ttMigrate utility from the old release and import it using the ttMigrate utility from the new release. The procedure for this upgrade is similar to the steps outlined in "Moving between 32-bit and 64-bit databases".
If you must upgrade two or more databases that are replicating to each other, you must perform a few extra steps to ensure that replication continues to operate during and after the upgrade. For example, to migrate two replicating databases, master1 on host computer masterhost and subscriber1 on host computer subscriberhost, from TimesTen release 6.0 to TimesTen release 11.2.2, perform the steps that follow.
|
Note: TimesTen 11.2.1 introduced the cache grid feature. By default, this feature is enabled and requires additional configuration before cache groups can be created on a database. If you are upgrading a database 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 the Oracle In-Memory Database Cache User's Guide. |
Configure the replication scheme on both databases to use static TCP/IP ports for replication. This is necessary because the intermediate result of this procedure is that replication occurs between two different releases of TimesTen. Each release does not necessarily know how to find the main daemon of the other to have the replication ports assigned dynamically. See "Port assignments" in the Oracle TimesTen In-Memory Database Replication Guide for more information.
On the computer masterhost, use the ttAdmin utility of the 6.0 release to stop the replication daemon on the database:
ttAdmin -repStop master1
Next, use the ttMigrate utility of the 6.0 release with the -c option to back up database master1 to a binary file:
ttMigrate -c DSN=master1 master1.bak
Use the ttDestroy utility of the 6.0 release to destroy database master1, where the database's files are located in the directory data_store_path:
ttDestroy /data_store_path/master1
Use the ttMigrate utility of the 11.2.2 release with the -r option to restore database master1 from the binary file. Restoring the database automatically upgrades it from release 6.0 to release 11.2.2. If you are restoring a very large database, you should use the -C option to tell ttMigrate to perform a checkpoint operation on the database periodically. This saves time if the restore fails at some point before the operation has been completed. For more information, see "Checkpoint operations" in the Oracle TimesTen In-Memory Database Operations Guide.
ttMigrate -r -C 20 DSN=master1 master1.bak
Use the ttAdmin utility of the 11.2.2 release to start the replication daemon:
ttAdmin -repStart master1
Replication is now occurring between the database master1 on release 11.2.2 and the database subscriber1 on release 6.0.
Now upgrade database subscriber1 from release 6.0 to release 11.2.2. Perform the steps that follow.
On the computer subscriberhost, use the ttAdmin utility of the 6.0 release to stop the replication daemon:
ttAdmin -repStop subscriber1
Use the ttDestroy utility of the 6.0 release to destroy database subscriber1, where the database files are located in the directory data_store_path:
ttDestroy data_store_path/subscriber1
If you are upgrading from a release preceding 11.2.2, you must create a user with ADMIN privileges to duplicate a database using replication. 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;
Use the ttRepAdmin utility of the 11.2.2 release with the -duplicate option to duplicate database subscriber1 from database master1 using replication.
ttRepAdmin -duplicate -from master1 -host masterhost -uid pat -pwd patpwd -setMasterRepStart subscriber1
Use the ttAdmin utility of the 11.2.2 release to start the replication daemon:
ttAdmin -repStart subscriber1
The databases are now upgraded and replicating to each other.
In "Performing an offline upgrade" we showed 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. You can do an online upgrade when moving between major TimesTen releases. If moving to a patch release, you may instead perform an in-place or offline upgrade.
Normally, applications that require high availability of their data use TimesTen replication to keep at least one extra copy of their 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" Oracle TimesTen In-Memory Database Replication Guide.
|
Note: 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 the 5.1 release of TimesTen and a database created in the 7.0 release of TimesTen is not supported. However, if one database was created in the 5.1 release, and the peer database was created in the 5.1 release and then upgraded to the 7.0 release, replication between them is supported. |
|
Note: For security reasons, replication is not normally allowed between databases in TimesTen 7.0 and databases in releases preceding TimesTen 7.0. To perform an online upgrade with replication, you must start the main TimesTen 7.0 or later daemon with the-insecure-backwards-compat option. |
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 upgraded database.
The general steps in an online upgrade include:
Disconnect all applications from the database being upgraded.
Shut down replication on the system being upgraded.
Back up the database residing on the system 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 on the system being upgraded using the newer release's ttMigrate with the -r option.
Reconnect all applications to the upgraded database.
Restart replication on the upgraded system.
|
Note: AfterttMigrate has been used, all autorefresh cache groups in an upgraded 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 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 upgraded database when replication is restarted. When the replicated updates have been completely applied, the applications may be reconnected to the upgraded database.
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 an 11.2.1 database that has the connection attributeReplicationApplyOrdering set to 0, or from an 11.2.1 or 11.2.2 database that has ReplicationParallelism set to <2, requires that you re-create the database, even if the version is the same or only the minor version has changed. |
After the above procedures are carried out on the upgrade system, the active system can be upgraded using the same steps.
Online upgrades can be performed only on 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 being upgraded. 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;
This section describes how to perform an online upgrade of 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 a database 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 the Oracle In-Memory Database Cache User's Guide. |
We'll refer to the two TimesTen systems being upgraded as the upgrade system, on which the TimesTen instance and the database are upgraded, and the active system, which remains operational and connected to the application for the duration of the upgrade. After this procedure is completed, the same steps can be followed to upgrade the active system. However, you may prefer to delay conversion of the active system to first test the upgraded TimesTen instance.
The upgrade system in this example consists of the 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 -connStr DSN=active -receiver -name upgrade -state pause 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 -connStr DSN=upgrade -receiver -name active -state stop 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 DSN=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 -connStr DSN=active -receiver -name upgrade -start start |
| 9. | Use ttMigrate to load the backup created in Step 6. into the database upgrade for the new release of TimesTen:
ttMigrate -r "DSN=upgrade;AutoCreate=0" /backup/upgrade.dat If the database is temporary (Temporary=1), first use 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 -connStr DSN=upgrade -receiver -name active -reset ttRepAdmin -connStr DSN=upgrade -receiver -name active -state stop sleep 10 ttRepAdmin -connStr DSN=upgrade -receiver -name active -state start sleep 10 Note: The | |
| 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 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 the 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 database active is ready to be upgraded.
Note: You may choose to delay upgrading |
You generally use active standby pair replication to provide high availability of your data to your applications. It is possible to maintain continuous availability of your data, even during a upgrade of TimesTen, your operating system, or your system hardware, by performing an online upgrade with active standby pair replication. This section describes the following procedures:
Upgrading the databases in an active standby pair with no cache groups
Upgrading the databases in an active standby pair with cache groups
This section includes the following topics:
Upgrades for TimesTen patch releases on the standby master database and subscriber databases
Upgrades for TimesTen patch releases on the active master database
Upgrades for major TimesTen releases, application software and hardware
To upgrade to a TimesTen patch release on the standby master database and subscriber databases, complete the following tasks on each database:
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 TimesTen patch. See "Performing an in-place upgrade".
Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
To upgrade the active master database, you must first reverse the roles of the active and standby master databases, and 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
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 former active master database, which is now the standby master database. See "Performing an in-place upgrade".
Restart replication on the upgraded database using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
To make the newly upgraded database the active master database again, see "Reversing the roles of the active and standby master databases" in Oracle TimesTen In-Memory Database Replication Guide.
When you upgrade an active standby pair across major releases 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 prepare for the upgrade by following these steps:
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.
When you are ready to upgrade the active standby pair, the first database that you must upgrade is the standby master. While this node is being upgraded, there is no standby master database, and updates on the active master database are propagated directly to the subscriber databases.
Tell 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. For example, to stop the replication agent for the standby master database master2:
ttAdmin -repStop master2
Upgrade the node where the standby master database resides. See "Performing an offline upgrade".
Start the replication agent on the standby master database using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
When the upgraded standby master database has become synchronized with the active master database, the upgraded standby master database moves from the RECOVERING state to the STANDBY state. The upgraded 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 on the standby master database:
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' );
Tell 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
Perform the upgrade on the node where the master database was destroyed. There is no need to do anything to upgrade the database itself, since it was destroyed.
If you are upgrading from a release preceding 11.2.1, you must create a user with ADMIN privileges on the current active master database to duplicate that database. 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;
Duplicate the new standby master database from the current 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
Perform the upgrade on the node where the subscriber database was destroyed.
Duplicate the subscriber database from the 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 15 through Step 19 for each other subscriber database.
This section includes the following topics:
Upgrades for TimesTen patch releases on the standby master database and subscriber databases
Upgrades for TimesTen patch releases on the active master database
Upgrades for major TimesTen releases, application software and hardware
To upgrade to a TimesTen patch release on the standby master database and subscriber databases, complete the following tasks on each database.
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 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 using the ttCacheStart built-in procedure or the ttAdmin utility:
ttAdmin -cacheStop master2
Restart the replication agent using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
To upgrade the active master database, you must first reverse the roles of the active and standby master databases, and 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 former active master database, which is now the standby master database. See "Performing an in-place upgrade".
Restart the cache agent on the upgraded database using the ttCacheStart built-in procedure or the ttAdmin utility:
ttAdmin -cacheStart master1
Restart replication on the upgraded database using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master1
To make the newly upgraded database the active master database again, see "Reversing the roles of the active and standby master databases" in Oracle TimesTen In-Memory Database Replication Guide.
When you upgrade an active standby pair across major releases 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 prepare for the upgrade by following these steps:
Tell 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 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.
Begin major upgrades on the node with the standby master database. While this node is being upgraded, there is no standby master database, and updates on the active master database are propagated directly to the subscriber databases.
|
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 a database containing cache groups from a release preceding 11.2.1, you should set theCacheGridEnable attribute to 0 in each DSN definition before beginning, as discussed in Oracle In-Memory Database Cache User's Guide. |
Tell 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. For example, to stop the replication agent for the standby master database master2:
ttAdmin -repStop master2
Stop the cache agent on the standby master database using the ttCacheStop built-in procedure or the ttAdmin utility:
ttAdmin -cacheStop master2
Upgrade the node where the standby master database resides. See "Performing an offline upgrade".
Start the cache agent on the standby master database using the ttCacheStart built-in procedure or the ttAdmin utility:
ttAdmin -cacheStart master2
Start the replication agent on the standby master database using the ttRepStart built-in procedure or the ttAdmin utility:
ttAdmin -repStart master2
When the upgraded standby master database has become synchronized with the active master database, the upgraded standby master database moves from the RECOVERING state to the STANDBY state. The upgraded 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 on the standby master database:
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, use the following command.
ttAdmin -repStop master1
Stop the cache agent on the active master database using the ttCacheStop built-in procedure or the ttAdmin utility:
ttAdmin -cacheStop 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' );
Tell 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
Perform the upgrade on the node where the master database was destroyed. There is no need to do anything to upgrade the database itself, since it was destroyed.
If you are upgrading from a release preceding 11.2.1, you must create a user with ADMIN privileges on the current active master database to duplicate that database. 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;
Duplicate the new standby master database from the current active master database using the ttRepAdmin utility. For example, to duplicate the database master2 on the host master2host to the database master1, where the cache user ID is terry and the cache password is terrypwd, use the following on the host containing the database master1:
ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd -cacheuid terry -cachepwd terrypwd -keepCG -setMasterRepStart "DSN=master1;UID=;PWD=;PWDCrypt="
|
Note: Only the instance administrator can create a database, but the DSN for a database containing cache groups is often configured with any of theUID, PWD, and PWDCrypt attributes. To allow the ttRepAdmin utility to create the database when duplicating, you may specify blank values for any of UID, PWD, or PWDCrypt in the connection string to connect as the instance administrator. |
Start the cache agent on the new standby master database using the ttCacheStart built-in procedure or the ttAdmin utility:
ttAdmin -cacheStart 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
Perform the upgrade on the node where the subscriber database was destroyed.
Duplicate the subscriber database from the standby master database using the ttRepAdmin utility:
ttRepAdmin -duplicate -from master1 -host master1host -uid scott -pwd tiger -noKeepCG -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 15 through Step 19 for each other subscriber database.
When using TimesTen with Oracle Clusterware, perform these tasks for an offline upgrade of TimesTen. You can also upgrade Oracle Clusterware while upgrading TimesTen. (Also see the next section, "Performing an online TimesTen upgrade when using Oracle Clusterware".)
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 on the host. This removes the host from the cluster and stops the TimesTen daemon:
ttCWAdmin -shutdown -hosts localhost
Upgrade TimesTen on the desired hosts. Every node in the cluster must have TimesTen from the same major release. If you are upgrading between major releases, use the ttMigrate utility.
Upgrade Oracle Clusterware if desired. See Oracle Clusterware Administration and Deployment Guide.
If you have upgraded Oracle Clusterware, use the ttmodinstall utility 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).
Start the TimesTen cluster agent. This includes the host in the cluster and starts the TimesTen daemon:
ttCWAdmin -init
Create the active standby pair replication scheme:
ttCWAdmin -create -dsn advancedDSN
Start the active standby pair replication scheme:
ttCWAdmin -start -dsn advancedDSN
This section discusses how to perform a minor online rolling in-place upgrade for TimesTen in a configuration where active standby pairs are managed by Oracle Clusterware. (Also see the preceding section, "Performing an offline TimesTen upgrade when using Oracle Clusterware".)
The following topics are covered:
|
Note: These instructions are for minor upgrades only, from one TimesTen 11.2.2.x.x version to another 11.2.2.x.x version. |
The following basic configurations are supported for online rolling in-place upgrades for TimesTen. In all cases, the hosts are managed by Oracle Clusterware.
One active standby pair on two hosts.
Multiple active standby pairs with one TimesTen database on each host.
Multiple active standby pairs with one or more TimesTen database on each host.
(Other scenarios, such as with additional spare systems, are effectively equivalent to one of these scenarios.)
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 minor upgrades only.)
Oracle Clusterware is release 11.2.0.2 or 11.2.0.3.
The in-place upgrade applies to one TimesTen installation on each host.
There are at least two hosts managed by Oracle Clusterware.
Multiple active or standby databases managed by Oracle Clusterware can exist on a host as long as there are at least two hosts in the cluster.
Note the following restrictions 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.
Online rolling in-place grades are not supported on Windows in this TimesTen release.
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 are running a TimesTen 11.2.2.x.x release.
The active standby pair is on two 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 Oracle Database are working.
Refreshes from Oracle Database to the active TimesTen database are working.
Enter the ttCWAdmin -status -dsn yourDSN command to verify the following.
The active database i:{ńs 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:
crs_stat -c standbyHostName
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.
crs_stop TT_Master_upgrade2_terry_myDSN_1 crs_stop TT_Daemon_upgrade2_terry_host2 crs_stop TT_Agent_upgrade2_terry_host2
Set the TimesTen RAM policy to manual and stop the TimesTen main daemon.
ttAdmin -ramPolicy manual -dsn myDSN ttDaemonAdmin -stop
If the ttDaemonAdmin -stop command gives error 10028, retry the command.
Complete these steps for an in-place upgrade of 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
ttcrsagent.options
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
Set the RAM policy for the standby database to inUse.
ttAdmin -ramPolicy inUse -dsn myDSN
Start the Oracle Clusterware Master process for the standby database.
crs_start 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 crs_stat command to obtain the names of the Master, Daemon and Agent processes on the host of the new standby database (host1 in this example):
crs_stat -c host1
Enter commands such as those in "Shut down the standby database". Use the appropriate instance name, instance administrator, DSN, and host name. For example:
crs_stop TT_Master_upgrade2_terry_MYDSN_0 crs_stop TT_Daemon_upgrade2_terry_host1 crs_stop TT_Agent_upgrade2_terry_host1 ttAdmin -ramPolicy manual -dsn myDSN ttDaemonAdmin -stop
Enter commands such as those in "Perform an in-place upgrade of the standby database".
See "Start the standby database". Use the Master process name obtained by the crs_stat -c command.
ttCWAdmin -init -hosts localhost ttAdmin -ramPolicy inUse -dsn myDSN crs_start TT_Master_upgrade2_terry_MYDSN_0
The process to upgrade a single active standby pair on two hosts is the same as the process to upgrade multiple active standby pairs on multiple pairs of hosts. The best practice is to upgrade the active standby pairs one at a time.
Use the ttCWAdmin -status command to determine the state of the databases managed by Oracle Clusterware.
An active standby pair managed by Oracle Clusterware must use at least two hosts, one for the active database and one for the standby database, but more than one active standby pair can be configured on a pair of hosts. 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 "Sample configuration files: multiple active standby pairs on the same pair of hosts" for sample sys.odbc.ini entries and a sample cluster.oracle.ini file for this kind of configuration.
The in-place rolling upgrade process is similar, with these additional modifications:
Switch all standby databases to one host and do the upgrade for the entire "standby" host. In-place upgrades affect the entire TimesTen installation and associated databases on one host. Use the ttCWAdmin -switch -dsn DSN command to move the standby databases to one host.
Verify that the standby databases are running 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 the standby databases reside.
Modify the Oracle Clusterware start commands to start all Master processes on the host where the standby databases reside.
Modify the ttAdmin ramPolicy command to change the policy for all databases on the host where the standby databases reside.
The following subsections contain related samples.
Sample configuration files: multiple active standby pairs on the same pair of hosts
Sample scripts: stopping and starting multiple standby processes on one host
The following are sample sys.odbc.ini entries for databasea and databaseb:
[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
Note that 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 hosts names specified for the MasterHost attribute.
Use the crs_stat -c hostName command to obtain the names of the Master, Daemon and Agent processes for the standby host.
The following script is an example of a "stop standby" script for multiple databases on the same host that is managed by Oracle Clusterware. The TimesTen instance name is upgrade2. The instance administrator is terry. The host is host2. There are two standby databases: databasea and databaseb.
crs_stop TT_Master_upgrade2_terry_DATABASEA_0 crs_stop TT_Master_upgrade2_terry_DATABASEB_1 crs_stop TT_Daemon_upgrade2_terry_HOST2 crs_stop TT_Agent_upgrade2_terry_HOST2 ttAdmin -ramPolicy manual -dsn databasea ttAdmin -ramPolicy manual -dsn databaseb ttDaemonAdmin -stop
The following script is an example of a "start standby" script for the same configuration.
ttCWAdmin -init -hosts localhost ttAdmin -ramPolicy inUse -dsn databasea ttAdmin -ramPolicy inUse -dsn databaseb crs_start TT_Master_upgrade2_terry_DATABASEA_0 crs_start TT_Master_upgrade2_terry_DATABASEB_1
This section provides a sample in-place upgrade.
$ ./setup.sh
There are 1 TimesTen instances installed locally :
1) upgrade2 (TimesTen11.2.2.3.0)
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 : upgrade2
Product Installed : TimesTen11.2.2.3.0
Installation Directory : /scratch/terry/TimesTen/upgrade2
BitLevel : 64
Component Installed : Client/Server and DataManager
Daemon Port : 12345
NOTE: Upgrading will remove the selected instance and re-install into
the same directory. You will have the option to retain configuration
files in : /scratch/terry/TimesTen/upgrade2/info
Would you like to upgrade this instance? [ yes ]
** WARNING **
The uninstallation has been executed by a non-root user.
If the TimesTen daemon startup scripts were installed,
you must run <install_dir>/bin/setuproot -uninstall
to remove them. If you proceed with this uninstallation, you
will have to remove the startup scripts manually.
Would you like to proceed with the uninstallation? [ yes ]
The TimesTen daemon (timestend) is running
Terminating subprocesses.
NOTE: /scratch/terry/TimesTen/upgrade2/info contains information related to the data
stores that have been created with this release. If you remove
/scratch/terry/TimesTen/upgrade2/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
/scratch/terry/TimesTen/upgrade2/info? [ no ]
Would you also like to remove all files in
/scratch/terry/TimesTen/upgrade2/network/admin/samples? [ no ]
/scratch/terry/TimesTen/upgrade2 Removed
(retained /scratch/terry/TimesTen/upgrade2/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/terry/TimesTen/upgrade2
Where would you like to create the daemon home directory?
[ /scratch/terry/TimesTen/upgrade2/info ]
The daemon logs will be located in /scratch/terry/TimesTen/upgrade2/info
Would you like to specify a different location for the daemon logs? [ no ]
Installing into /scratch/terry/TimesTen/upgrade2 ...
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 's999'? [ 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/terry/TimesTen/upgrade2/info? [ yes ] no
NOTE: The existing daemon options file has been retained. The default options
file was written as /scratch/terry/TimesTen/upgrade2/info/ttendaemon.options.upgrade2.
TNS_ADMIN exists in your environment and is set to :
/scratch/terry/TimesTen/upgrade2/network/admin/samples
Would you like to use this TNS_ADMIN setting for the In-Memory Database Cache?
[ yes ]
TNS_ADMIN will be set to /scratch/terry/TimesTen/upgrade2/network/admin/samples
You can change TNS_ADMIN later by running <install_dir>/bin/ttmodinstall.
Installing server components ...
What is the TCP/IP port number that you want the TimesTen Server to listen on?
[ 12346 ]
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/terry/TimesTen/upgrade2/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/terry/TimesTen/upgrade2/info/cluster.oracle.ini.tt1122'.
An existing sys.odbc.ini file has been detected in /scratch/terry/TimesTen/upgrade2/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/terry/TimesTen/upgrade2/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/terry/TimesTen/upgrade2/info/sys.odbc.ini.upgrade2'.
Installing client components ...
Would you like to use TimesTen Replication with Oracle Clusterware? [ no ] yes
A Clusterware installation was detected in /opt/oracle/product/11.2.0/crs
Please provide the path to the Oracle Clusterware installation on this machine
(s=skip)? [ /opt/oracle/product/11.2.0/crs ]
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? [ 12351 ]
Executing '/opt/oracle/product/11.2.0/crs/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 ] y
From the nodes above, please provide a list of nodes
that you would like to add (ex: 1,2 or skip)? [ ] 1,2,3,4
TimesTen Replication with Oracle Clusterware will be configured
for the following nodes :
host1
host2
host3
host4
Are you sure? [ yes ] y
Overwrite the existing TimesTen Clusterware options file? [ no ]
The new TimesTen Clusterware options file will be located here :
/scratch/terry/TimesTen/upgrade2/info/ttcrsagent.options.tt1122.
NOTE: The TimesTen daemon startup/shutdown scripts have not been installed.
Run the 'setuproot' script :
cd /scratch/terry/TimesTen/upgrade2/bin
./setuproot -install
This will move the TimesTen startup script into its appropriate location.
The startup script is currently located here :
'/scratch/terry/TimesTen/upgrade2/startup/tt_upgrade2'.
The documentation was not installed.
To manually install the documentation, run the command 'setup.sh -installDoc'
The 11.2.2.4.0 Release Notes are located here :
'/scratch/terry/TimesTen/upgrade2/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.
|
Note: The values for theReplicationApplyOrdering attribute have changed. Beginning in release 11.2.2.2.0, a value of 0 enables automatic parallel replication. Prior to release 11.2.2.2.0, a value of 0 disabled user-specified parallel replication. |
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.
To upgrade an active standby pair without parallel replication enabled to release 11.2.2.3.0 or higher with the ReplicationApplyOrdering attribute set to the default value (0), you must use the steps for doing an active standby upgrade. See "Performing an online upgrade with active standby pair replication".
You must use an offline upgrade for these scenarios:
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).
From automatic parallel replication to another automatic parallel replication with different number of tracks as indicated by the value of the ReplicationParallelism attribute.
If you are moving between major and minor releases and are using asynchronous writethrough parallelism.
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 the section "Performing an offline upgrade". Alternatively, you can upgrade one side and use the ttRepAdmin -duplicate -recreate command to create the new database.
An upgrade from a database with parallel replication to a release with no parallel replication is possible only if the master has not been running with more than one track. Once multiple transmitters have been in operation for a specified source database, replication to a database without parallel replication enabled is not possible.
You cannot replicate between a database that has the ReplicationParallelism attribute set to greater than 1 and that has different values for the ReplicationApplyOrdering attribute.
If replication is configured on a database, a new set of tables with the prefix ttrep_schema_version- is created each time that the ttMigrate -r command is used. These tables provide a history of the database's replication scheme from release to release.
These tables do not take up much space and are helpful when debugging upgrade problems. However, you can drop these tables if you do not experience problems with replication after running ttMigrate.
For example, after two migrations, the 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 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.
|
Note: For security reasons, client/server communication is not normally allowed between TimesTen 7.0 and previous releases. To perform an online upgrade with Client/Server, you must start the main TimesTen 7.0 daemon with the-insecure-backwards-compat option. |
To perform an online upgrade of a TimesTen Client/Server system to a new major release 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 install 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 between 32-bit and 64-bit databases" for an example of this procedure.
Start the new release of TimesTen Server. The client applications now have access to the upgraded databases.
|
Note: Since both releases of TimesTen Server have been configured to listen on the same port in this procedure, if you want to restart the 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 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.
This section summarizes the new features of Oracle TimesTen In-Memory Database release 11.2.2 that are documented in this guide and provides links to more information.
Where features or procedures differ from other Windows platforms, this version of the document includes information for Windows 7 systems.
Beginning with this release, the Windows 64-bit installer includes an option for a 32-bit client as well as a 64-bit client. You can install both (default), either, or neither. See "Installing TimesTen".
TimesTen is supported on Oracle Exalogic Elastic Cloud (Exalogic). The Exalogic certification was performed using the TimesTen with a quarter-rack Exalogic version 1.0 server. For details on installing TimesTen on Exalogic, see "Installing TimesTen on Exalogic systems".
This guide includes a chapter on migrating TimesTen databases. In previous releases, this information was found in the Oracle TimesTen In-Memory Database Operations Guide. See Chapter 2, "Migration, Backup, and Restoration."
Installation Guide
11g Release 2 (11.2.2)
E21632-09
September 2012
Oracle TimesTen In-Memory Database Installation Guide, 11g Release 2 (11.2.2)
E21632-09
Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
The Oracle TimesTen In-Memory Database provides application-tier database and transaction management built on a memory-optimized architecture accessed through industry-standard interfaces. Optional data replication and Oracle caching extend the product to enable multi-node and multitier configurations that exploit the full performance potential of today's networked, memory-rich computing platforms.
The TimesTen CD contains a readme.html file that is the latest version of the release notes. These notes list product information and late changes to the printed documentation.
TimesTen documentation is available on the product distribution media and on the Oracle Technology Network:
http://www.oracle.com/technetwork/products/timesten/documentation/
TimesTen supports multiple platforms. Unless otherwise indicated, the information in this guide applies to all supported platforms. The term Windows applies to all supported Windows platforms. The term UNIX applies to all supported UNIX and Linux platforms. Refer to the "Platforms" section in Oracle TimesTen In-Memory Database Release Notes for specific platform versions supported by TimesTen.
|
Note: In TimesTen documentation, the terms "data store" and "database" are equivalent. Both terms refer to the TimesTen database unless otherwise noted. |
This document uses the following text conventions:
| Convention | Meaning |
|---|---|
| italic | Italic type indicates terms defined in text, book titles, or emphasis. |
monospace | Monospace type indicates code, commands, URLs, function names, attribute names, directory names, file names, text that appears on the screen, or text that you enter. |
italic monospace | Italic monospace type indicates a placeholder or a variable in a code example for which you specify or use a particular value. For example:
Replace |
| [ ] | Square brackets indicate that an item in a command line is optional. |
| { } | Curly braces indicated that you must choose one of the items separated by a vertical bar ( | ) in a command line. |
| | | A vertical bar (or pipe) separates alternative arguments. |
| . . . | An ellipsis (. . .) after an argument indicates that you may use multiple arguments on a single command line. An ellipsis in a code example indicates that what is shown is only a partial example. |
| % | The percent sign indicates the UNIX shell prompt. |
In addition, TimesTen documentation uses the following special conventions:
| Convention | Meaning |
|---|---|
install_dir | The path that represents the directory where TimesTen is installed. |
TTinstance | The instance name for your specific installation of TimesTen. Each installation of TimesTen must be identified at installation time with a unique instance name. This name appears in the installation path. |
bits or bb | Two digits, either 32 or 64, that represent either a 32-bit or 64-bit operating system. |
release or rr | The first three parts in a release number with or without dots. The first three parts of a release number represent a major TimesTen release. For example, 1122 or 11.2.2 represents TimesTen 11g Release 2 (11.2.2). |
DSN | TimesTen data source name (for the TimesTen database). |
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
