| Oracle® TimesTen In-Memory Database Installation Guide 11g Release 2 (11.2.2) Part Number E21632-09 |
|
|
PDF · Mobi · ePub |
| Oracle® TimesTen In-Memory Database Installation Guide 11g Release 2 (11.2.2) Part Number E21632-09 |
|
|
PDF · Mobi · ePub |
This chapter describes migration, backup and restoration for the TimesTen database in these topics:
The TimesTen utilities for copying, restoring and migrating a database enable you to perform the following:
Migrate a database between releases of TimesTen. Use the ttMigrate utility. This utility saves tables and indexes from a TimesTen database into a binary file. The tables and indexes can then be restored into another TimesTen database. This enables you to migrate data between TimesTen releases.
Migrate a database between different hardware platforms. Use the ttBulkCp utility to save and restore the data. The ttBulkCp utility copies data from TimesTen tables into ASCII files and back again, but only for those objects owned by the user executing the utility, and those objects for which the owner has SELECT privileges.
The ttBulkCp utility enables you to copy a single table between databases, including between databases from different releases of TimesTen or between databases on different hardware platforms.
The ttSchema utility saves the table definitions. Use ttIsql to re-create the tables from the saved table definitions.
Take a snapshot of a database and then restore the database in the exact same state. Use the ttBackup and ttRestore utilities or the ttBackup and ttRestore C functions.
The TimesTen backup and restore facility enables you to create a backup of any TimesTen database to restore it at a later time. The primary use for the backup and restore facility is to allow the restoration of a recent state of a database that has been lost. For details about using the TimesTen backup and restore facility, see "ttBackup" and "ttRestore" in Oracle TimesTen In-Memory Database Reference. These utilities are supported only where the TimesTen Data Manager is installed.
Every database backup contains the information needed to restore the database as it existed at a 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 will produce a backup that can be used 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.
Important:
Do not manually change the contents of the backup directory. The addition, removal, or modification of any file in the backup directory, except for modifications made by ttBackup and ttRestore themselves, may compromise the integrity of the backup and restoration of the database from the backup may not be possible.
Databases containing cache groups can be backed up with the ttBackup utility. However, when restoring such a backup, special consideration is required. The restored data within the cache groups may be out of date or out of sync with the data in the back-end Oracle database. To restore a database that contains cache groups, see "Backing up and restoring a database with cache groups" in Oracle In-Memory Database Cache User's Guide.
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 in order 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 referred to 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:
| Backup type | File or stream | Full or incremental | Incremental-enabled | Comment |
|---|---|---|---|---|
fileFull |
File | Full | No | This is the default. |
fileFullEnable |
File | Full | Yes | |
fileIncremental |
File | Incremental | Yes | Fails if incremental backup is not possible. |
fileIncrOrFull |
File | Either | Yes | Performs fileIncremental if possible, or fileFullEnable otherwise. |
streamFull |
Stream | Full | No | |
incrementalStop |
None | None | No | Takes no backup; just disables existing incremental-enabled backup. |
The ttMigrate utility saves one or more migration objects from a TimesTen database into a binary data file or restores the objects from the binary data files into a TimesTen database. Migration objects include tables, cache group definitions, views and sequences.
The following topics describe what occurs with globalization issues during migration:
See also "Copying, migrating and restoring a database" of this guide and the description of ttMigrate in the Oracle TimesTen In-Memory Database Reference.
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).
Note:
The
ttMigrate utility issues a warning whenever there is an implicit or explicit character set conversion while saving or restoring data.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.
Note:
If character set conversion is requested when migrating databases, performance may be slower than if character set conversion is not requested.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.
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.
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.
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.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|