To ingest a database is to take Oracle backup files, generated by the Oracle RMAN utility on an external, or source, database, and restore them to a new, or target, database in Data Director.

The Oracle backup files are hosted on an NFS server for Data Director to consume. As the source database evolves, the refresh process can take incremental backup files from the source and apply them to target, so any changes after ingestion can be synced to the target database, regularly or on demand.

You can use ingestion to reproduce a production environment, or to create a one-time clone or golden clone, or refresh an existing database in place.The imported database is a clone of a physical database that exists outside of Data Director.

To ingest an external database, you need the following versions of Oracle, and Linux.

Oracle: 11g Release 2 Linux x86-64 Enterprise/Standard Edition.

Oracle: 10g Release 2 Linux x86-64 Enterprise/Standard Edition.

OS: Linux x86-64.

You must comply with the following rules when backing up the source database.

Turn on control file auto backup and use the default control file auto backup format for device type disk ('%F').

If the database is in archive log mode and open, you must include archive logs in the backup. For example,

 backup INCREMENTAL LEVEL 0 database plus archivelog 

Otherwise, do not include an archive log in the backup. If the database is in nonarchive mode, the refresh from external database feature does not support point in time refresh. The absolute path of any control files, data files, redo log files, or temporary files of source database cannot contain any space, tab, carriage return, asterisk, question mark, backslash, quote or line feed characters.

The database must be included in the backup. You cannot back up only the archive logs.

For golden clone ingestion and golden clone refresh, you must supply a LIST file containing information about the backup operation. See next section for the name convention and format of LIST file.

For a one-time clone (in-place refresh), a full backup or one level 0 incremental backup plus several optional level 1 subsequent incremental backups is required. You can optionallly do several subsequent level 1 incremental backups (L0+nL1). For a point in time refresh, record the modify time so you can refresh to the specified time. For a golden clone, a level 0 incremental backup is required for ingestion, and a level 0 or level 1 (either differential or cumulative) incremental backup is required for a refresh.

You must have an spfile in the control file backup set if you do not specify a pfile.

The database name must be the SID.

If network speed is limited or the database is very large, the ingestion-refresh process can take a long time. If you use DHCP for the database virtual machine, ensure that the DHCP lease time is long enough so that the IP address does not change during the ingestion and refresh process.

You must comply with the following additional requirements when backing up the source database.

The NFS server must be accessible to the DB Access Network or the Internal Network when ingestion and refresh is running, and the backup files, LIST file and pfile must be readable.

You must allocate sufficient storage when ingesting, and estimate future expansion when ingesting a golden clone.

The following Oracle features are supported.

Backup set.

Different block size for various data files.

BLOB data type.

Compressed backup.

The following Oracle features are not supported.

Image copy backup.

External file.

Encrypted backup.

OEM (Oracle Enterprise Manager) is not supported on ingested database.

During the ingestion and refresh process, coordinate your operations with external programs, such as third party backup software, or with manual operations. Familiarize yourself with the backup files, and observe these file based conventions.

Backup files for each ingestion or refresh operation should have their own directory. The directory should be beneath the exported directory.

For a golden clone ingestion and golden clone refresh, you must supply a LIST file that contains information about the backup. The naming convention for a LIST file is database.LIST, where database is the name of the database. The content of the LIST file is a series of key-value pairs, as in this example LIST file.

controlfile=o1 mf_s_774019590_71hv06jn_.bkp

The level value, required in previous versions of Data Director, is no longer needed. The agent automatically checks the bakup level during ingestion and refresh. The optional catalogstart property specifies the location to load the backup files. This means the control file directory and the catalog start directory can be different. The value of catalogstart is a directory relative to the LIST file. If no catalogstart is provided, the directory of the LIST file is used. When you upgrade from Data Director 2.0, make sure your old LIST file works as expected. Otherwise, provide a catalogstart value.

In this LIST file, the controlfile field specifies the control backup file in the backup set. The value is a file relative to the LIST file. It can be in the same directory as the LIST file, or in another directory. Other backup files must be in the same directory as the control backup file.

The pfile field is optional.

To illustrate how to organize the LIST file, a pfile, and backup files, assume that you take a level 0 backup on Sunday and a level 1 backup on all other days. In this case, you would create a backup directory with a LIST file and a pfile in it, for example, sales.LIST and sales.pfile. Also in that directory, you would create subdirectories for each day of the week, with a backup file, LIST file and pfile in each of them.

On Sunday, the sales.LIST file will look like this.


For backwards compatibility, you can retain the level value, as shown for Sunday.

On Monday, the sales.LIST file will look like this.


Ensure that the level information in the LIST file is correct. Information at the wrong level will result in failure of the refresh process. If you retain the level value for backwards compatibility, set it as shown for Monday.

In the directory containing the backup files, a LOCK file is generated during the ingestion and refresh processes to coordinate the operation with external programs. The LOCK file uses the same naming convention as the LIST file. If the LOCK exists at the beginning of an ingestion or refresh process, the process aborts.