The following chapter discusses how to migrate data from a TimesTen Classic database, work with repositories, and how to back up and restore data in a TimesTen Scaleout database.
TimesTen Scaleout enables you to migrate a database from TimesTen Classic to TimesTen Scaleout. TimesTen Scaleout supports and includes most of the features of TimesTen Classic; it does not support any of the features of the TimesTen Cache or TimesTen Replication. See "Comparison between TimesTen Scaleout and TimesTen Classic" for more information on what features are supported in TimesTen Scaleout. These procedures are for TimesTen Classic databases. You cannot migrate the following objects:
Tables containing a LOB column.
Tables that contain ROWID columns.
Tables with in-memory columnar compression.
Tables with aging policies.
Cache groups.
Replication schemes.
Prerequisites before migrating a database from TimesTen Classic to TimesTen Scaleout:
Create a grid with management and data instances. See Chapter 4, "Setting Up a Grid" for more information.
Create a backup of your TimesTen Classic database. See "ttBackup" and "ttRestore" in Oracle TimesTen In-Memory Database Reference for more information.
See "Backing up and restoring a database" in the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide.
After you have created a backup of your TimesTen Classic database, consider removing LOB columns from your tables. TimesTen Scaleout cannot import a table with LOB columns and the import process displays an error message if a table contains LOB columns. Use the ALTER TABLE statement with the DROP keyword to drop these columns. See "ALTER TABLE" in the Oracle TimesTen In-Memory Database SQL Reference for more information.
In case that you have tables with ROWID columns consider not using ROWID based access in your applications. The semantics of ROWID columns are different in TimesTen Classic than in TimesTen Scaleout. See "Understanding ROWID in data distribution" for more information.
Understand the performance trade-off between table distribution schemes. See "Defining table distribution schemes" for more information.
The procedures in this section explain how to remove the objects that cannot be migrated from your TimesTen Classic database.
To migrate a database from TimesTen Classic to a TimesTen Scaleout database, export your database schema, and migrate supported objects out of the TimesTen Classic database. Then restore these into a new TimesTen Scaleout database.
Disconnect all applications from your TimesTen Classic database.
On the TimesTen Classic instance, export the database schema with the -list option of the ttSchema utility. The -list option only specifies objects that are supported in TimesTen Scaleout. Ensure that you replace database1 with the name of your database:
% ttSchema -list tables,views,sequences,synonyms database1 > /tmp/database1.schema
For more information about the ttSchema utility, see "ttSchema" in the Oracle TimesTen In-Memory Database Reference.
On the TimesTen Classic instance, save a copy of your database with the ttMigrate utility.
% ttMigrate -c database1 /tmp/database1.data Saving user PUBLIC User successfully saved. ... Sequence successfully saved.
For more information about the ttMigrate utility, see "ttMigrate" in the Oracle TimesTen In-Memory Database Reference.
Copy the database schema and the migrate object files to a file system that is accessible by one of your data instances. You can choose any data instance and you need to complete all further procedures from this same data instance unless stated otherwise.
On your selected data instance, use a text editor to edit the database schema file to remove SQL statements and clauses that are not supported in TimesTen Scaleout and add distribution scheme clauses for your tables. This is the database schema file that you created in step 3.
Remove the following SQL statements:
CREATE CACHE GROUP
CREATE REPLICATION
CREATE ACTIVE STANDBY PAIR
CREATE INDEX (Before removing these statements review the note below)
Note:
CREATE INDEX statements are supported in TimesTen Scaleout, but it is more efficient to create indexes once your data has been distributed. However, for child tables which you want to distribute with the DISTRIBUTE BY REFERENCE distribution scheme, you should not remove the FOREIGN KEY clause of the child table, nor the CREATE INDEX statement of the referenced parent table. Step 9 restores your indexes once your data has been inserted into your TimesTen Scaleout database.Remove the following CREATE TABLE clauses:
COMPRESS BY
FOREIGN KEY (Before removing these statements review the note above)
AGING
Add CREATE USER statements to create the schema owners referenced by the objects in database1.schema. For example, hr.employees, would require a CREATE USER hr IDENTIFIED BY password statement. You also may need to add privileges to these users if you want to log in as the users.
Add distribution scheme clauses for all of your table definitions. If you do not specify a distribution scheme for a CREATE TABLE statement, TimesTen Scaleout distributes the data of that table with the DISTRIBUTE BY HASH distribution scheme.
Note:
When you use theDISTRIBUTE BY REFERENCE distribution scheme, ensure that you declare the child key columns of a foreign key constraint as NOT NULL.Before adding distribution schemes to your table definitions, ensure that you understand the performance trade-off between the distribution schemes. For more information on distribution schemes in a TimesTen Scaleout database, see "Defining table distribution schemes" for more information.
From a TimesTen Scaleout management instance, create a TimesTen Scaleout database. See "Creating a database" for more information.
On your selected data instance, log in as the instance administrator to create the database schema from the database schema file. Ensure that you replace new_database1 with the name of your new TimesTen Scaleout database:
% ttIsql -connStr "DSN=new_database1" -f /tmp/database1.schema Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=new_database1"; Connection successful: ... exit; Disconnecting... Done.
Note:
It can be useful to redirect the output of the ttIsql command to an output file. You can then review this output to ensure that the command ran successfully. To redirect output to a file, add> myoutput.txt after the ttIsql -connStr "DSN=new_database1" -f /tmp/database1.schema command.On your selected data instance, use the following ttMigrate command to restore rows for all user tables:
% ttMigrate -r -gridRestoreRows new_database1 /tmp/database1.data Restoring table HR.EMPLOYEES ... 10/10 rows restored. Table successfully restored.
On your selected data instance, use the following ttMigrate command to restore indexes and foreign keys:
% ttMigrate -r -gridRestoreFinale new_database1 /tmp/database1.data Restoring table HR.EMPLOYEES ... 10/10 rows restored. Table successfully restored.
Note:
If you did not removeFOREIGN KEY clauses in step 5 because you are using a DISTRIBUTE BY REFERENCE distribution scheme, you may see error messages that TimesTen Scaleout is unable to create some foreign keys. If you already created these foreign keys in step 5, you can ignore these messages.Once the database is operational on TimesTen Scaleout, create a backup of the TimesTen Scaleout database to have a valid restoration point for your database. See "Backing up and restoring a database" for more information. Once you have created a backup of your database, you may remove the database schema file (in this example, /tmp/database1.schema) and the ttMigrate copy of your database (in this example, /tmp/database1.data).
In a grid, a repository is used to store backups of databases, database exports, and collections of log files and configuration files. TimesTen Scaleout enables you to define a repository as a directory path mounted using NFS on each host or as a directory path that is not directly mounted on each host. Multiple grids can use a single repository.
A repository contains a number of collections. A collection can be a backup of a database, a database export, or a set of saved daemon logs and configuration files. Collections are essentially subdirectories that use the name of the collection and are stored inside of a repository. Each collection can contain a combination of files and sub-collections.
Ensure that you create your repository where there is enough file system space to store your database backups, database exports, and collections of log and configuration files.
You must create a repository for your grid before attempting to backup a database, export a database, or create a daemon log collection.
TimesTen Scaleout enables you to perform the following procedures with repositories:
Before you back up a database, export a database, or create a daemon log collection, you need to configure a repository for your grid. Depending on the value of the -method parameter, the ttGridAdmin repositoryCreate command creates a repository as a directory path mounted using NFS on each host or as a directory path that is accessible on each host with SSH or SCP.
Note:
For more information on valid names for repositories, see "Grid objects and object naming" in the Oracle TimesTen In-Memory Database Reference.The mount (NFS) method can only be used if all instances are on the same network and all instances must use the same NFS. The SCP method can be used on any system but may be slower for larger grids.
Example 10-1 Create a repository as a directory path mounted using NFS on each host
This example creates a repository as a directory path mounted using NFS on each host of your grid. Ensure that the directory specified by the -path parameter exists and is accessible by the instance administrator on each element. This directory must have the same identical mount path on every element. For example, if the directory path is mounted at /repositories on one element, it must be mounted at /repositories on all elements.
% ttGridAdmin repositoryCreate repo1 -path /repositories -method mount Repository repo1 created
Example 10-2 Create a repository as a directory path that is accessible on each host with SSH or SCP
This example creates a repository as a directory path that is not directly mounted on each host of your grid. Ensure that the path value specified by the -path parameter exists on the host that you specify with the -address parameter. The address parameter is the fully qualified domain name of the host on which the repository exists. Also, ensure that each host can use the scp command to access files in the path value specified by the -path parameter. You can use the ttGridAdmin gridSshConfig command to verify that your hosts can communicate through SSH with each other. For more information, see "Configure SSH (gridSshConfig)" in the Oracle TimesTen In-Memory Database Reference.
% ttGridAdmin repositoryCreate repo2 -path /repositories -method scp -address host1.example.com Repository repo2 created
For more information about the ttGridAdmin repositoryCreate command, see "Create a repository (repositoryCreate)" in the Oracle TimesTen In-Memory Database Reference.
Multiple grids can use a single repository as long as each grid is associated with that repository. If you have an existing repository, you can attach it to another grid as long as each host from your grid has access to the path of the repository. Depending on the value of the -method parameter, you can attach a repository as a directory path mounted using NFS on each host or as a directory path that is accessible on each host with SSH or SCP. However, you can only attach a repository with the same -method as which was used to create it. For example, if you created a repository with -method mount, you can only attach it to another grid with -method mount.
Example 10-3 Attach a repository as a directory path mounted using NFS on each host
This example attaches a repository as a directory path mounted using NFS on each host of your grid. Ensure that the path value specified by the -path parameter exists and is accessible by the instance administrator on each host of your grid.
The name of the repository needs to be the same on each grid to which you attach your repository.
% ttGridAdmin repositoryAttach repo1 -path /repositories -method mount Repository repo1 attached
Example 10-4 Attach a repository as a directory path that is accessible on each host with SSH or SCP
This example attaches a repository as a directory path that is not directly mounted on each host of your grid. Ensure that each host can use the scp command to access files in the path value specified by the -path parameter. The address parameter is the fully qualified domain name of the host on which the repository exists.
The name of the repository needs to be the same on each grid to which you attach your repository.
% ttGridAdmin repositoryAttach repo2 -path /repositories -method scp -address host1.example.com Repository repo2 attached
For more information about the ttGridAdmin repositoryAttach command, see "Attach a repository (repositoryAttach)" in the Oracle TimesTen In-Memory Database Reference.
TimesTen Scaleout enables you to detach, but not destroy, a repository from a grid when you no longer need to use that repository with your grid.
To detach a repository from a grid, specify the name of the repository to detach from your grid:
% ttGridAdmin repositoryDetach repo1 Repository repo1 detached
Detaching a repository from a grid does not delete the directory or the contents of that repository.
For more information about the ttGridAdmin repositoryDetach command, see "Detach a repository (repositoryDetach)" in the Oracle TimesTen In-Memory Database Reference.
TimesTen Scaleout enables you to view a list of all repositories that are attached to a grid and all collections within the repository.
To view a list of all repositories that are attached to a grid:
% ttGridAdmin repositoryList Repository Method Location Address ---------- ------ ------------------- -------- repo1 mount /repositories/repo1
To view a list of all collections that are part of every repository that are attached to a grid:
% ttGridAdmin repositoryList -contents Repository Collection Type Date Details ---------- ------------- ------------- ------------------------ ------------------ repo1 B20170222145544 Backup 2017-02-22T14:55:48.000Z Database database1 repo1 B20170615142115 Backup 2017-06-15T14:21:20.000Z Database database1 repo2 L20170615143145 gridLogCollect 2017-06-15T14:31:48.000Z repo2 L20170616102242 gridLogCollect 2017-06-16T10:22:50.000Z
Note:
You can add the name of a repository to only view the collections that are part of a specific repository. For example,ttGridAdmin repositoryList repo1 -contents shows all collections of the repo1 repository.For more information about the ttGridAdmin repositoryList command, see "List repositories (repositoryList)" in the Oracle TimesTen In-Memory Database Reference.
The TimesTen Scaleout backup and restore functionality is essential in order to protect your data. It is recommended to perform regular backups in order to minimize the risks of potential data loss. When you perform a backup of a database, TimesTen Scaleout performs the backup asynchronously on each replica set and creates a sub-collection for each replica set that is backed up.
When you are considering backing up and restoring a TimesTen Scaleout database, keep in mind that:
The current grid topology must be the same size or larger than the topology from the grid of the database backup. If your current grid topology is not large enough for n replica sets, TimesTen Scaleout displays an error message. That is, if you backup a database with three replica sets and you want to restore into a database that has only two replica sets, this operation will fail. However, you can use the export and import feature of TimesTen Scaleout to import a database from a grid topology with more replica sets into a database of a grid topology with less replica sets. See "Exporting and importing a database" for more information.
You can restore a backup into a grid of the same grid topology, even the same grid from which the backup was created. That is, if you create a backup of a database where there are three replica sets, then you can restore into the same grid or a new grid where there are three replica sets.
You can restore a backup into a grid that has a larger topology than the grid where the backup was created. If you back up a database that has n replica sets, the restore operation creates a database with exactly n replica sets. However, if your current grid topology is larger than the original grid topology, TimesTen Scaleout creates the additional elements, but TimesTen Scaleout does not add these elements to the distribution map of the database and no data is stored on these elements. Instead, the restore only populates the same number of replica sets as the original grid topology. That is, if you create a backup of a grid where there are three replica sets, you can restore a backup into a new grid where there are four replica sets. However, the restore only populates three of those four replica sets. Thus, in order to populate all replica sets, you must redistribute the data across all replica sets after the restore using the ttGridAdmin dbDistribute command. See "Redistributing data in a database" for more information.
There are two type of backups: normal or staged.
Normal backups can be performed either on a repository mounted using NFS on each host of your grid or on a repository where each host of your grid uses SSH/SCP to connect to it. The time it takes to create a normal backup varies based on the size of your database, but you should expect every backup to take roughly the same time to complete.
Staged backups can only be performed on a repository where each host of your grid uses SSH/SCP to connect to it. Even though the first staged backup may take a similar time to complete as a normal backup (or even longer based on the performance of your network), all subsequent staged backups should take only a small fraction of that time to complete. Staged backups are ideal when you want to make regular backups on a second site that is independent to your main site.
See "Determining the size of a backup or export" for information on the file system space each backup operation requires.
Note:
If the database where the data would be restored is from a version of TimesTen Scaleout that is not patch-compatible, such as for a major upgrade, then you cannot backup and restore a database. Instead, you must export and import that database. See "Exporting and importing a database" for more information.TimesTen Scaleout enables you to perform the following procedures with backups:
Regular backups minimize the risks for potential data loss. Before attempting to back up your database, ensure that you have configured a repository for your grid. See "Working with repositories" for more information.
This example creates a backup of the database database1 and stores that backup in the repository repo1. By default, TimesTen Scaleout names your backup with the current date and time, Byyyymmddhhss. The prefix of the backup name, B, stands for backup. Ensure that you run the ttGridAdmin dbBackup command on a management instance.
Note:
You can add the-name parameter to specify a backup name. For example, ttGridAdmin dbBackup database1 -repository repo1 -name mybackup creates a backup named mybackup.% ttGridAdmin dbBackup database1 -repository repo1 dbBackup B20170222145544 started
Depending on the size of your database, the number of replica sets that your database uses, the performance of your secondary storage device, and the performance of your network the backup time varies. The ttGridAdmin dbBackup command only starts the backup process and the output does not indicate that the backup is complete. Use the ttGridAdmin dbBackupStatus command to see the status of your backup. See "Check the status of a backup" for more information.
For more information about the ttGridAdmin dbBackup command, see "Back up a database (dbBackup)" in the Oracle TimesTen In-Memory Database Reference.
Normal backups to repositories using the SCP method require two copies of the most recent checkpoint and transaction logs files for each replica set. One copy consists of the checkpoint and log files of one element for each replica set, which are temporarily copied to a directory in the instance home. The second copy consists of the same checkpoint and log files per replica set after they are sent and stored at the repository, which construct the backup itself.
TimesTen Scaleout enables you to create staged backups to SCP repositories. This type of backup eliminates the overhead of creating local copies of the checkpoint and log files and reduces the network traffic required to create a remote copy in the repository. To accomplish this, staged backups use symbolic links instead of temporary local files (with the exception of the latest log file) and maintain a staging directory on the repository with the checkpoint and log files per replica set used for the latest backup. The next staged backup will copy the latest log files from each replica set and synchronize the rest of the files in the staging directory over the network. Finally, the repository uses the resulting files in the staging directory to create the backup, which removes the load of that task from the data instances and network.
Note:
The system hosting the repository makes use of the Linux cp and rsync commands and the TimesTen ttTransferAgent utility to perform staged backup operations. The ttTransferAgent utility is copied to the staging directory at the beginning of a staged backup if it is not already available from a previous staged backup.
See "Working with repositories" for more information on SCP repositories.
The next sections describe the recommended settings for staged backups and how to create a staged backup:
Consider these before starting staged backups for your database:
Staged backups have these prerequisites:
Passwordless SSH access: Staged backups require that all hosts with instances (data and management) have passwordless SSH access for the instance administrator to the system hosting the repository. See "Setting passwordless SSH" for more information.
The rsync command: Staged backups require that the rsync command is available on hosts with data instances and on the system allocating the repository.
Staged backups depend on SSH for data transport and control. On every host with a data instance, consider updating the SSH configuration file for the instance administrator (/home/instance_administrator/.ssh/config) or the global SSH configuration file (/etc/ssh/ssh_config) to improve the reliability of staged backups. These options may prove useful:
HostName: You can use this option to specify multiple aliases for the repository. SSH tries them in order. Provide a list of multiple aliases in a different order to every host.
Port: SSH uses by default port 22. You may need to use a different port number if SSH has to pass through a NAT gateway.
BindAddress or BindInterface: You can use these options to control which Ethernet interface SSH will use to contact the repository.
ConnectionAttempts: By default SSH only makes one connection attempt. You can use this option to set how many connection attempts SSH will make before aborting and returning a failure notification.
ConnectTimeout: By default SSH uses the system TCP timeout. You can use this option to set the timeout (in seconds) to establish a SSH connection. Consider increasing this connection timeout on high-latency WAN links.
ProxyJump: You can use this option to set bastion hosts to serve as proxies to connect to the repository. The hosts with a data instance may be able to access the bastion hosts but not other hosts, like the repository. Likewise, the bastion hosts may be able to access the remote repository. You can configure multiple bastion hosts for high availability.
ServerAliveCountMax: You can use this option to set the maximum number of keepalive messages sent through the encrypted channel by a host without receiving any message back from the repository. The connection is terminated after reaching this threshold. You must use this option in conjunction with the ServerAliveInterval option.
ServerAliveInterval: You can use this option to set the time (in seconds) between receiving no data from the repository and the host sending a keepalive message. This serves to detect if the repository has crashed or the network has gone down.
On the system hosting the repository, consider setting this option in the global SSH daemon configuration file (/etc/ssh/sshd_config):
MaxStartups: You can use this option the set the maximum number of concurrent unauthenticated connections to the SSH daemon. Consider setting the start parameter to a value larger than the number of replica sets and the full parameter to ten times the value of the start parameter. For example, if you have ten replica sets, set this option as:
MaxStartups 15:30:150
The BackupFailThreshold first connection attribute determines the number of transactions log files that can accumulate in the LogDir directory since the start of a backup before TimesTen is forced to release the hold on checkpoint operations. If a checkpoint is initiated before the completion of a backup, the backup is invalidated.
Set the BackupFailThreshold attribute to a value that is high enough to ensure the safe completion of your backup. For example, if a backup typically takes n seconds to complete and your database creates m transaction log files per second, then set BackupFailthreshold to a value greater than n * m. The number of log files generated by your database per any given unit of time is directly proportional to your write workload and inversely proportional to the value set for the LogFileSize attribute.
See "Modifying the connection attributes of a database" for information on how to modify the value of a first connection attribute.
For more information on the BackupFailThreshold, LogDir, and LogFileSize connection attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
To avoid out-of-space failures due to staged backups, ensure that:
The file system used by each data instance has enough space for one transaction log file (LogFileSize) in the instance home plus enough space to store in LogDir all the transaction log files that may be generated while the backup operation is in progress (BackupFailThreshold * LogFileSize).
The file system used by the repository has enough space to store as many backups you wish to retain plus enough space in the staging directory for 1.25 backups for all staged backups of the same database.
See "Determining the size of a backup or export" for information on the file system space each backup operation requires.
For more information on the LogFileSize, LogDir, and BackupFailThreshold connection attributes, see "Connection Attributes" in the Oracle TimesTen In-Memory Database Reference.
The minimum WAN throughput required by a subsequent staged backup depends on the aggregate size of the database, the desired time for the backup to take, and the speed-up factor provided by the staging repository and the defined transfer compression. You will need to perform a series of staged backups to test how much the performance of your network and overall setup (plus the inherent advantages subsequent staged backups over normal backups provide) reduces the backup time for regular staged backups under typical workload conditions. Consider this formula:.
Minimum WAN throughput = file size of a backup/(desired backup time * (first staged backup time/average subsequent staged backups time))
See "Determining the size of a backup or export" for information on the file system space each backup operation requires.
This example creates a staged backup named stgbackup1 of the database1 database and stores that backup in the scprepo1 repository. The staged backup is set to use an aggregate network traffic of 62 MB per second and a compression level of 9 for that network traffic.
% ttGridAdmin dbBackup database1 -repository scprepo1 -name stgbackup1 -backupType staged -bwlimit 62 -compression 9 dbBackup stgbackup1 started
Note:
Ensure that you run thettGridAdmin dbBackup command as the instance administrator on the active management instance.Depending on the size of your database, the number of replica sets that your database uses, the performance of your secondary storage device, and the performance of your network the backup time varies. The ttGridAdmin dbBackup command only starts the backup process and the output does not indicate that the backup is complete. Use the ttGridAdmin dbBackupStatus command to see the status of your backup. See "Check the status of a backup" for more information.
For more information about the ttGridAdmin dbBackup command, see "Back up a database (dbBackup)" in the Oracle TimesTen In-Memory Database Reference.
The ttGridAdmin dbBackupStatus command enables you to view the progress of all backup processes for a specific database.
This example displays the status of all backup processes for the database database1.
% ttGridAdmin dbBackupStatus database1
Database Backup Repository Host Instance Elem State Started Finished
--------- --------------- --------- ----- --------- ---- --------- ---------------------- --------
database1 B20170222145544 repo1 Completed 2017-02-22T14:55:44.000Z Y
host4 instance1 2 Complete
host5 instance1 3 Complete
Ensure that the ttGridAdmin dbBackupStatus output shows that the overall state of the backup process is marked as Completed. In case that you see a state value of Failed, perform these tasks:
Use the ttGridAdmin dbStatus database1 -details command to ensure that the host and instance of that element are up and running. If at least one host from each replica set is up, the ttGridAdmin dbBackup command can create a full backup of your database. For more information, see "Monitor the status of a database (dbStatus)" in the Oracle TimesTen In-Memory Database Reference.
Ensure that the repository where you are attempting to create the backup has enough free file system space to create a backup of your database.
If the backup failed, you may attempt to perform another backup using a different backup name. If a new backup name does not perform a successful backup, diagnose the issue and perform any necessary fixes. After you have resolved the problem, use the ttGridAdmin dbBackupDelete to delete any failed backups. TimesTen Scaleout does not automatically delete a failed backup. Then, use the ttGridAdmin dbBackup command to start a new backup. Depending on your available file system space, you can use these commands in any order. See "Delete a backup" and "Back up a database" for more information.
For more information about the ttGridAdmin dbBackupStatus command, see "Display the status of a database backup (dbBackupStatus)" in the Oracle TimesTen In-Memory Database Reference.
TimesTen Scaleout does not automatically delete backups. In some cases, you may want to delete backups that have failed or old backups to free up file system space.
Use the ttGridAdmin repositoryList -contents command to view all of your available backups and their respective repositories. See "List repositories and collections" for more information.
This example deletes the backup named B20170222145544 from repository repo1.
% ttGridAdmin dbBackupDelete -repository repo1 -name B20170222145544 Backup B20170222145544 deleted
TimesTen Scaleout deletes the collection and all of the sub-collections that are part of the backup.
For more information about the ttGridAdmin dbBackupDelete command, see "Delete a database backup (dbBackupDelete)" in the Oracle TimesTen In-Memory Database Reference.
Before attempting to restore a database, consider the following:
The database definition name must not be in use by other databases when you attempt to perform a database restore. For example, you cannot name the restored database database1 if another database is using the database1 name.
The database definition of the backed up database does not need to match the database name of the database that you are restoring. For example, you can restore a backup of the payroll database to the new_payroll database definition.
The K-safety value of the database that you backed up does not need to match the K-safety value of the restore database.
The database definition must have at least as many connections as the database definition of the backed up database.
This example restores the database res_db1 from the backup B20170222145544 from repository repo1. Ensure that you run the ttGridAdmin dbRestore command on the management instance.
% ttGridAdmin dbRestore res_db1 -repository repo1 -backup B20170222145544 dbRestore B20170222145544 started
Note:
Ensure that theres_db1 database definition exists before attempting to perform a restore. You do not need to create a database from this database definition. See "Create a database definition" for more information.Depending on the size of your backup, the number of replica sets that your database uses, the performance of your secondary storage device, and the performance of your network the restore time varies. The ttGridAdmin dbRestore command only starts the restore process and the output does not indicate that the restore is complete. The restore process is performed asynchronously on every element. Use the ttGridAdmin dbRestoreStatus command to see the status of your restore. See "Check the status of a restore" for more information.
For more information about the ttGridAdmin dbRestore command, see "Restore a database (dbRestore)" in the Oracle TimesTen In-Memory Database Reference.
The ttGridAdmin dbRestoreStatus command enables you to view the progress of the restore process for a specific database.
This example displays the status of all restore processes for the database res_db1.
% ttGridAdmin dbRestoreStatus res_db1
Database Restore Repository Host Instance Elem State Started Finished
-------- ------- ---------- ----- --------- ---- ------------------------------------------------ -
res_db1 mybkup repo1 Restore_Finale_Complete 2017-03-03T13:19:39.000Z Y
host3 instance1 Restore_Instance_Complete
host4 instance1 Restore_Instance_Complete
host5 instance1 Restore_Instance_Complete
host6 instance1 Restore_Finale_Comnplete
Ensure that the ttGridAdmin dbRestoreStatus output shows that the restore has been completed for every element of your grid. The restore operation is fully completed when the State column of the row with the database name is marked as Completed.
Ensure that the ttGridAdmin dbRestoreStatus output shows that the overall state of the restore process is marked as Completed. In case that you see a state value of Failed or Restore_Instance_Failed for an element or an overall state of Restore_Finale_Failed or Restore_Init_Failed, stop the database with ttGridAdmin dbClose and ttGridAdmin dbUnload commands. Once you have stopped the database, use the ttGridAdmin dbDestroy command to delete the database that did not restore successfully. Then, attempt the restore operation again. See "Unloading a database from memory" and "Destroying a database" for more information.
For more information about the ttGridAdmin dbRestoreStatus command, see "Display the status of a database restore (dbRestoreStatus)" in the Oracle TimesTen In-Memory Database Reference.
The TimesTen Scaleout export and import functionality enables you to migrate data between two grid databases.
In these circumstances you must export a database:
The source database is from a version of TimesTen Scaleout that is not patch-compatible such as for a major upgrade. See "Upgrading a grid" for more information on both types of upgrades (patch-compatible or otherwise).
The destination database is in a grid topology that has fewer replica sets than the grid topology where the database is exported.
When you export a database, TimesTen Scaleout performs the export asynchronously of each replica set and creates a sub-collection for each replica set that is exported.
See "Determining the size of a backup or export" for information on the file system space each export operation requires.
TimesTen Scaleout enables you to perform the following procedures with database exports:
Before attempting to export a database, ensure that you have configured a repository for your grid. See "Working with repositories" for more information.
Ensure that you disconnect all application connections to the database before performing a database export to ensure that no applications are modifying data during the database export operation. Also, ensure that you close the database to prevent any new connections to the database. Any transaction committed during an export operation may result in an inconsistent database.
This example creates a database export of the database database1 and stores that export in the repository repo1. By default, TimesTen Scaleout names your database export with the current date and time, Myyyymmddhhss. Ensure that you run the ttGridAdmin dbExport command on a management instance.
Note:
You can add the-name parameter to specify a database export name. For example, ttGridAdmin dbExport database1 -repository repo1 -name myexport creates a database export named myexport.% ttGridAdmin dbExport database1 -repository repo1 dbExport M20170302144218 started
Depending on the size of your database, the number of replica sets that your database uses, the performance of your secondary storage device, and the performance of your network the database export time varies. Use the ttGridAdmin dbExportStatus command to see the status of your database export. See "Check the status of a database export" for more information.
For more information about the ttGridAdmin dbExport command, see "Export a database (dbExport)" in the Oracle TimesTen In-Memory Database Reference.
The ttGridAdmin dbExportStatus command enables you to view the progress of all database export processes for a specific database.
This example displays the status of all database export processes for the database database1.
% ttGridAdmin dbExportStatus database1
Database Export Repository Host Instance Elem State Started
--------- --------------- ---------- ---- -------- ---- ---------- ------------------------
database1 M20170321073022 repo1 Completed 2017-03-21T07:30:27.000Z
host3 instance1 Complete
host5 instance1 Complete
Ensure that the ttGridAdmin dbExportStatus output shows that a database export has been completed for every replica set of your grid. In case that you see a state value of Failed for an element, perform these tasks:
Use the ttGridAdmin dbStatus database1 -details command to ensure that the host and instance of that element are up and running. For more information, see "Monitor the status of a database (dbStatus)" in the Oracle TimesTen In-Memory Database Reference.
Ensure that the repository where you are attempting to create the backup has enough free file system space to create a backup of your database.
After you have resolved the issues that caused the export to fail, use the ttGridAdmin dbExportDelete to delete the failed database export. TimesTen Scaleout does not automatically delete a failed database export. Then, use the ttGridAdmin dbExport command to start a new database export. See "Delete a database export" and "Export a database" for more information.
For more information about the ttGridAdmin dbExportStatus command, see "Display the status of a database export (dbExportStatus)" in the Oracle TimesTen In-Memory Database Reference.
TimesTen Scaleout does not automatically delete database exports. In some cases, you may want to delete database exports that have failed or old database exports to free up file system space.
Use the ttGridAdmin repositoryList -contents command to view all of your available database exports and their respective repositories. See "List repositories and collections" for more information.
This example deletes the database export named M20170321073022 from repository repo1.
% ttGridAdmin dbExportDelete -repository repo1 -name M20170321073022 Export M20170321073022 deleted
TimesTen Scaleout deletes all of the sub-collections that are part of the database export.
For more information about the ttGridAdmin dbExportDelete command, see "Delete a database export (dbExportDelete)" in the Oracle TimesTen In-Memory Database Reference.
Before attempting to import a database export, consider the following:
The database to which you import must exist when you attempt to perform a database import. The database can either contain data or be empty. It is not necessary to create the users or tables of the original database.
The database name of the database that you exported does not need to match the database name of the database where you are importing the database export. For example, you can import a database export of the payroll database in the new_payroll database.
The K-safety value of the database that you exported does not need to match the K-safety value of the grid where you are importing the database export.
Ensure that you disconnect all application connections to the database before performing a database import to ensure that no applications are modifying data during the database import operation. Also, ensure that you close the database to prevent any new connections to the database. Any transaction committed during an import operation may result in an inconsistent database. See "Close a database (dbClose)" in the Oracle TimesTen In-Memory Database Reference for more information.
This example imports the database import_db from the database export M20170321073022 from repository repo1. Ensure that you run the ttGridAdmin dbImport command on a management instance.
% ttGridAdmin dbImport import_db -repository repo1 -name M20170321073022 -numThreads 8 dbImport M20170321073022 started
Note:
Ensure that theimport_db database exists before attempting to perform a restore. See "Create a database definition" for more information.Depending on the size of your database export, the number of replica sets that your database uses, the performance of your secondary storage device, and the performance of your network the import time varies. To increase the performance of the import operation, use the -numThreads option to specify the number threads that concurrently read rows from the export database and insert them into the import database.
For more information about the ttGridAdmin dbImport command, see "Import a database (dbImport)" in the Oracle TimesTen In-Memory Database Reference.
The ttGridAdmin dbImportStatus command enables you to view the progress of the import process for a specific database.
This example displays the status of all import processes for the database import_db.
% ttGridAdmin dbImportStatus import_db
Database Import Repository Host Instance Elem State Started
--------- ----------------------------- -------- ---- ---------- ----------------------------------
database1 M20170321073022 repo1 Import_Finale_Complete2017-03-21T10:30:27.000Z
host3 instance1 1 Import_Rows_Complete
host5 instance1 1 Import_Rows_Complete
Ensure that the ttGridAdmin dbImportStatus output shows that the import operation has been completed for every element of your grid. The import operation is fully completed when the State column of the row with the database name is marked as Completed.
In case that you see a state value of Failed for an element, use the ttGridAdmin dbDestroy command to delete the database that did not import successfully. Then, recreate the database and attempt the import operation again. See "Destroying a database" for more information.
For more information about the ttGridAdmin dbImportStatus command, see "Display the status of a database import (dbImportStatus)" in the Oracle TimesTen In-Memory Database Reference.
Every database backup and export stored in a repository requires file system space (in megabytes) that is equivalent to the value assigned to the PermSize attribute plus the sum of file sizes of the transaction log files created after the latest checkpoint, per replica set.
The file size of transaction log files and how many are typically written between background checkpoints is dependent of the configuration of your database. Your typical workload and the settings of attributes like CkptFrequency, CkptLogVolume, and LogFileSize have direct impact in determining how many transaction log files would need to be considered for a backup or export operation. See "Storage provisioning for transaction log files" in the Oracle TimesTen In-Memory Database Operations Guide for more information.
Additionally, each data instance requires available temporary file system space (/instance_home/grid/admin/temp/) that is equivalent to the size of a database backup or database export divided by the number of replica sets for every normal backup, export, restore, or import operation. Staged backups only require temporary file system space equivalent to one transaction log file (LogFileSize).