Methods for moving a geodatabase in Oracle

There are several options for moving a geodatabase: you can create a new geodatabase and move the data, or you can move the whole database.

Creating a new geodatabase then moving the data

You can create a new Oracle database, create a geodatabase in it, then move your existing data to the new geodatabase. This can be done using copy and paste, the Export tool, the Extract Data wizard, or XML workspace documents in ArcGIS.

Be aware that the user logged in when loading the data to the new geodatabase will own the data. If you want the data to have the same owner in the new geodatabase, have users move their own data.

You can also use Oracle's export and import utilities to transport data between databases, but remember that feature classes and rasters exist as a number of tables and related database objects. Leaving any related object behind renders the data inoperable in the target database. Therefore, it is recommended that the export include the data owner's entire schema plus the SDE user's schema.

The entire SDE user's schema is needed because geodatabase data objects rely on the metadata repository in the geodatabase administrator's schema to manage the data and provide structure to it. The SDE user's schema also contains the ST_Geometry type and functions.

Moving an Oracle database

You can back up then restore the Oracle database or use Oracle's transportable tablespaces. Be sure all necessary objects are exported along with the data tables.

Using Oracle transportable tablespaces is especially efficient when moving large databases. You can use the recovery manager (RMAN) utility to move the tablespaces.

Things to consider when transporting tablespaces are as follows:

• Each tablespace must be self-contained; tables and their indexes must be in the same tablespace before that tablespace can be transported. In other words, all the table's dependencies must share its tablespace.
• The size of the transfer media must accommodate the data files to be transported.
• You cannot import the tablespace if the destination database already has a tablespace with the same name.
• You cannot import the tablespaces if a table or index stored in the tablespace already exists on the destination server. Tables and indexes must be uniquely named within their schema.
• If the source and destination platforms are not both big endian or both little endian, you must convert the tablespace being transported to the format of the destination platform.
• The source and destination database must use the same character sets.
• Exports must be performed by a user with EXP_FULL_DATABASE privileges.

See the Oracle documentation for the release you are using for information on using import/export, backup and restore, and transportable tablespaces.