2 Migration, Backup, and Restoration

TimesTen backup features

Every database backup contains the information needed to restore the database as it existed at the backup point, which is the time the backup began. Restoration of a database from a given backup restores the modifications of all transactions that committed before the backup point.

A backup operation is atomic: If it completes successfully, it produces a backup you can use to restore a database to the state of its backup point. If it fails for any reason, it leaves the files of any existing backup intact and its backup point unchanged.

TimesTen writes a database backup to a location specified by a backup path, which consists of a directory name and an optional basename. You must specify the backup directory and basename when the backup is created. The basename defaults to the basename of the database itself if you do not specify a basename.

Types of backup provided

TimesTen supports both full and incremental backups. TimesTen also allows stream backups.

• Stream: A stream backup writes the database backup file to stdout.

• Full: A full backup saves the entire database. For full backups, you must have enough disk space available to hold both the existing backup and the new backup, until the new backup succeeds.

• Incremental: An incremental backup augments an existing incremental-enabled backup of the same database. An incremental backup moves the backup point of an existing backup forward in time by augmenting the backup with all of the transaction log records created since its last backup point.

  An incremental backup typically completes much faster than a full backup, as it has less data to copy. The performance gain of incremental backups over full backups comes at the cost of increased disk usage and longer restoration times. Use incremental backups in concert with full backups to achieve a balance between backup time, disk usage, and restoration time.

  Before you can perform an incremental backup, you must first enable your backup to allow for incremental backups by executing the ttBackup utility command with the -fileFullEnable or the -fileIncrOrFull options. In either case, if your backup was not previously enabled for incremental, a full file backup is performed before the backup is enabled for subsequent incremental backups. TimesTen supports the creation of up to eight incremental-enabled backup instances for each database. If you attempt to start a ninth incremental backup, TimesTen returns an error.

  If you restore a database from a backup, regardless of whether the backup was enabled or disabled for incremental, the restored database is disabled for incremental backups. Thus, if you want incremental backups, you must again execute the ttBackup utility command with the -fileFullEnable or the -fileIncrOrFull option to enable incremental backups.

A set of files containing backup information for a given database, residing at a given backup path, is known as a backup instance. A given backup instance must be explicitly enabled for incremental backups.

The files of the existing backup may be modified by a failed full or incremental backup, but not in a way that compromises the ability to restore from them.

The total list of backup types supported by TimesTen are as follows:

Moving a database to a different computer (same platform)

You can use the ttBackup and ttRestore utilities to move a database between two computers that have the same major release of TimesTen, the same CPU architecture, and the same operating system.

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

1. Disconnect applications from the database.

2. Back up the database on the original system using ttBackup. For example:

   ttBackup -dir /tmp/dump -fname salesdata SalesData
   

3. Move the backup to the new system.

4. Create a DSN for the database on the new system. See "Creating a Data Manager DSN on UNIX" or "Creating a Data Manager DSN on Windows" in Oracle TimesTen In-Memory Database Operations Guide.

5. Confirm the DataStore connection attribute is set correctly for the location on the new system.

6. Restore the backup on the new system using ttRestore. For example:

   ttRestore -dir /tmp/dump -fname salesdata NewSalesData
   

7. As desired, once the database is operational on the new system, use the ttDestroy utility to destroy the database on the old system, and delete the old DSN.

Moving a database to a different platform

The internal format of a TimesTen database differs between platforms. You can use this procedure to move a database from one platform to another, such as from Solaris to Linux or from a 32-bit platform to a 64-bit platform, and reformat it for the target platform.

1. Disconnect applications from the database.

2. From the target system, use ttMigrateCS (or Windows equivalent) to connect in client/server mode to the database on the originating system and use the -c option to create a data file for the database on the target system. For example:

   ttMigrateCS -c salesdata1 salesdata.dat
   

3. On the target system, create a DSN for the 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.

4. Recreate the database using AutoCreate=1, such as in the following example:

   ttIsql -connstr "dsn=salesdata2;AutoCreate=1" -e "quit"
   

   The database will be empty at this point.

5. Confirm the DataStore connection attribute is set correctly for the location on the new system.

6. On the target system, import the file created by ttMigrateCS into the new database using the ttMigrate utility with the -r option and the -relaxedUpgrade option. For example:

   ttMigrate -r -relaxedUpgrade salesdata2 salesdata.dat
   

7. As desired, once the database is operational on the new system, use the ttDestroy utility to destroy the database on the old system, and delete the old DSN.

Moving a database to a different directory

The TimesTen daemon identifies a database by the full path name of the database 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.

Examples in the following procedure move a database from /old/SalesData/sales with a database name SalesData to /new/SalesData/sales with database name NewSalesData, using the /tmp/dump directory for temporary storage. (The examples are for a UNIX system. Do the equivalent on a Windows system.)

1. Create a temporary directory. For example:

   mkdir /tmp/dump
   

2. Disconnect applications from the database.

3. Back up the database to the temporary directory using ttBackup. For example:

   ttBackup -dir /tmp/dump -fname salesdata SalesData
   

4. Unload the database from memory. For more information, see "Unloading a database from memory".

5. Create a DSN definition for the new location and specify the new database path. For example: /new/SalesData/sales/NewSalesData.

6. Confirm the DataStore connection attribute is set correctly for the new location.

7. Restore the backup in the new location. For example:

   ttRestore -dir /tmp/dump -fname salesdata NewSalesData
   

8. Remove the temporary directory. For example:

   rm -r /tmp/dump
   

9. After you confirm the database is operational in the new location, optionally use the ttDestroy utility to destroy it in the old location, and delete the old DSN.

Reducing database size

Once a database has been defined with a particular size for the permanent region (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 permanent region size of the database embedded in it.

To reduce the allocated size of the permanent region of a database, you must save a copy using the ttMigrate utility then re-create the database with a smaller permanent region size and restore the data.

Perform these steps to reduce the permanent region size of a database:

1. Disconnect applications from the database.

2. Use the ttMigrate -c option to create a data file for the database. For example:

   ttMigrate -c salesdata /tmp/salesbackup
   

3. Unload the database from memory. For more information, see "Unloading a database from memory".

4. To modify the original DSN rather than create a new one, you must destroy the original database files using the ttDestroy utility before restoring from the backup.

5. Create a new DSN definition for the new copy of the database with a smaller PermSize value.

6. Recreate the database using AutoCreate=1, such as in the following example:

   ttIsql -connstr "dsn=salesdata;AutoCreate=1" -e "quit"
   

   The database will be empty at this point.

7. Restore the backup, using the ttMigrate -r and -relaxedUpgrade options. For example:

   ttMigrate -r -relaxedUpgrade salesdata /tmp/salesbackup
   

Object migration and character sets

The ttMigrate utility tags each object it saves with the object's character set. By default, ttMigrate stores object data in the database character set; however, you can select a different character set by using the -saveAsCharset option. You can specify this option in create mode (-c) or append mode (-a).

When you use ttMigrate to restore an object, the data is implicitly converted to the database character set of the target database, if necessary. Character set conversion may result in data loss if the database character set of the target database cannot represent all of the data that it receives.

If you know that the data is encoded in the database character set of the target database, use the -noCharsetConversion option when restoring (-r). When using this option, ttMigrate assumes that the data uses the same database character set of the target database.

When you restore untagged character data from a database that was created before release 7.0 into a database from release 7.0 and later, ttMigrate treats the data as if it is in the database character set of the target database. All TimesTen databases from release 7.0 and earlier use the TIMESTEN8 character set.

If you are migrating from a TimesTen database that uses TIMESTEN8 to a TimesTen database that uses a different character set, the following may occur:

• The query result may differ in the new TimesTen database with the new character set. The user application may work on a multibyte character set and use the TIMESTEN8 character set to store the character string as it is. When querying the data using the LIKE predicate (or any scalar functions) to match a substring, the query engine may match a binary pattern that does not begin or end at a character boundary under TIMESTEN8 character set, since it is a single byte character set. Every byte is treated as a character even it is actually in the middle of a multibyte character.

  Another possible issue arises if the user partitions a long character string and stores it in separate rows. The string may be reconstructed later by concatenating the values from multiple rows. This may work with the TIMESTEN8 character set. However, when using a multibyte character set, if the partition is not on the character boundary, the string value can be changed. In this case, ensure that the string is partitioned on the character boundary.

• Performance may be slower with queries that use predicates or scalar functions on character strings in databases with a character set other than TIMESTEN8.

Migration and length semantics

The ttMigrate utility saves length semantic information about CHAR and VARCHAR2 columns. It restores the length semantic information when restoring objects into databases created in TimesTen release 7.0 or later.

When objects are migrated back into a TimesTen release before 7.0, columns with character semantics are converted to byte semantics and the column length is adjusted to match the byte length of the original columns.

When objects are migrated from a release before 7.0 to release 7.0 and later, byte semantics is used.

Migrating linguistic indexes

The ttMigrate utility supports migration of linguistic indexes into TimesTen releases that support them. When migrating back to a TimesTen release before 7.0, ttMigrate issues a warning indicating that the linguistic indexes cannot be restored. Migration of the table proceeds without the linguistic indexes.

Migrating cache group tables

You cannot restore cache group tables containing NCHAR/NVARCHAR2 columns to a release before 7.0. Releases before 7.0 do not allow these data types in cache group tables.