1. Administering Oracle Database Exadata Cloud Service (OCI-C)
  2. Migrating Oracle Databases to Exadata Cloud Service
  3. Choosing a Migration Method

Choosing a Migration Method

Various different migration methods exist, and each migration method is associated with different benefits, opportunities, requirements and limitations.

Migration Considerations

Some migration methods apply only if specific characteristics of the source (on-premises) and target (Exadata Cloud Service) databases match or are compatible. And even when multiple migration methods are technically feasible, other non-technical factors can affect which method you choose.

For example, Exadata Cloud Service uses a little-endian platform, so if you are migrating from a big-endian platform, some physical migration approaches are not feasible or require extra processing to achieve. Also, the frequency and length of the available maintenance windows is often a key consideration in determining which migration approaches are applicable.

Some of the characteristics and factors to consider when choosing a migration method are:

  • Source and target database versions

  • Source platform and operating system

  • Source database character set

  • Quantity of data, including indexes

  • Methods available for data transportation

  • Database features and data types used

  • Storage for data staging

  • Acceptable length of system outage

  • Network bandwidth

When choosing the right migration approach, you should clearly define what you need to migrate. For example, do you need to migrate a whole database or a whole tablespace or just a selection of database objects? This will help you to choose an approach that avoids considerable wasted effort in order to migrate data that is not required in the target database.

You should also weigh up the short-term requirement to perform the migration with the long-term impact of using the selected migration approach. Specifically, you may need to rule out what seems to be an easy and convenient migration approach if the resulting database configuration is sub-optimal. For example, Exadata performs best with an ASM AU size of 4 MB and database extents that are a multiple of 4 MB. If the source database extent sizes are not a multiple of 4 MB and it is impractical to reorganize the database before migration, then you might favor a migration approach that allows you to reorganize the database during the migration. If you choose an approach that does not allow the extents to be reorganized, you may be able to deliver a quicker and easier migration; however, you may also end up paying an ongoing performance penalty.

It is also worth noting that sometimes it makes sense to extend a migration method by performing additional data processing, or combine multiple migration methods, to deliver the best result. For example, your situation might determine that Transportable Tablespaces are a convenient way to migrate data into Exadata Cloud Service. However, the physical organization of the data in the Transportable Tablespaces may not be ideal for Exadata, so you may choose to redefine the tables by using a series of CREATE ... AS SELECT SQL commands, or to reload the data into fresh segments using Data Pump.

As part of determining your migration approach, you also need to consider how you physically transport your data to Exadata Cloud Service. For smaller data sets you can transfer the data across a network link between your source system and Exadata Cloud Service. However, for larger data sets this is not feasible because it would simply take too long. To accommodate these situations, you can use Oracle Data Transfer Service to physically send large data sets to Oracle Cloud. When you engage Oracle Data Transfer Service, Oracle ships a storage appliance to your data center. After your data is loading on to the storage and shipped back, Oracle transfers the data to an Oracle Storage Cloud Service container that is accessible from your Exadata Cloud Service environment. See Loading Data into the Oracle Database on Exadata Cloud Service.

Finally, Oracle can offer professional services to assist with all aspects of data migration to Exadata Cloud Service. You can engage Oracle to provide specific assistance for your migration efforts, or you can get Oracle to plan and execute the migration for you.

Determining Applicable Methods

To determine which migration methods might be applicable to your migration scenario, gather the following information.

  1. The database version of your source database:

  2. The architecture of the database, for source databases that use Oracle Database 12c, or later:

    • Container database (CDB). A CDB can support one (single-tenant) or more (multitenant) pluggable databases (PDBs).

    • Non-CDB

  3. Your source database host platform and endian format:

    Query V$DATABASE to identify the platform name for your source database.

    Platforms are either little-endian or big-endian depending on the byte ordering that they use. Query V$TRANSPORTABLE_PLATFORM to view all platforms that support cross-platform tablespace transport, along with the endian format of each platform.

    Exadata Cloud Service uses Linux x86–64, which is little endian.

  4. The database character set of your source database:

    By default, databases are configured to use the AL32UTF8 database character set on Exadata Cloud Service.

  5. The target database version that you are migrating to on Exadata Cloud Service:

    With Exadata Cloud Service, databases that use Oracle Database 12c, or later, are configured to use the CDB architecture.

After gathering this information, consider the following migration method outlines to determine the feasibility of each method to your specific scenario.