Learn About Reducing Downtime During a Database Migration

Planned downtime to migrate a production database to a new platform can be as disruptive to operations as unplanned downtime. This is especially true for global enterprises that support users in multiple time zones, and for enterprises that provide internet access to customers 24 hours a day, 7 days a week. Whether you're migrating a database from on-premise to the cloud, or from your current cloud service to a new infrastructure or platform, you can reduce downtime by using Oracle technologies that provide high availability.

Learn About Expected Downtime

When you migrate a database from on-premises to the cloud, some options result in less downtime than others.

The following table shows the expected downtime for high availability migration solutions.

Oracle Solution	Expected Outage Time
Oracle GoldenGate	Zero to seconds
Oracle Data Guard	Less than 5 minutes
Oracle Recovery Manager	Less than 2 hours
Instantiate from Oracle Cloud backup	Minutes to hours, depending on database size

Considerations for Migrating a Database to Oracle Database Cloud Service

Various methods and tools are available to migrate your on-premises Oracle Database to Oracle Database Cloud Service.

Not all migration methods apply to all migration scenarios. Many of the migration methods apply only if specific characteristics of the source database and the destination database match or are compatible. Additional factors can affect which method you choose for your migration from among the methods that are technically applicable to your migration scenario.

Some of the characteristics and database options to consider when you choose a migration method are:

Source database version
Oracle Database Cloud Service database version
On-premises host operating system and version
On-premises database character set
Quantity of data, including indexes
Data types used in the on-premises database
Storage for data staging
Acceptable length of system outage
Network bandwidth and connectivity

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

Database version of your source, on-premises database.

Note that an Oracle Database 11g Release 2 version lower than 11.2.0.4 requires an upgrade to at least version 11.2.0.4.
For on-premises Oracle Database 12c Release 1 version 12.1.0.2 or higher databases, the architecture of the database:
- A container database (CDB) can support one (single-tenant) or more (multitenant) pluggable databases (PDBs).
- A non-CDB
Your on-premises source database host platform and endian format.
Platforms are either little-endian or big-endian, depending on the byte ordering that they use. Oracle Database Cloud Service uses the Linux x86–64 platform, which is little endian.

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

Query V$TRANSPORTABLE_PLATFORM to view all platforms that support cross-platform tablespace transport, along with the endian format of each platform.
Database character set of your on-premises database and Oracle Database Cloud Service database.

Some migration methods require that the source database and the target database use compatible database character sets. By default, databases are configured to use the AL32UTF8 database character set.
The target database version that you are migrating to on Oracle Database Cloud Service.

Databases on Oracle Cloud that use Oracle Database 12c, or later, use the CDB architecture. Databases created using the Enterprise Edition option are single-tenant, and databases created using the Enterprise Edition - High Performance or Enterprise Edition - Extreme Performance option are multitenant.
- Oracle Database 11g Release 2
- Oracle Database 12c Release 1
- Oracle Database 12c Release 2
- Oracle Database 18c

Considerations for Migrating a DBCS Database to New Cloud Services

You can migrate an Oracle Database from one Oracle Database Cloud Service environment to another.

Examine your current environment for factors that can affect the migration, such as the size of the database files, the workload level, and versions of the software that you are using.

Consider the requirements of the target environment, such as versions, patches, and storage, that would affect how you might optimize your source database before migration.

To help you determine which cloud services are appropriate for your migration, gather the following information.

Determine the size of the database files in the source database, to determine how much space to allocate in the target database system.

You can find the total size of the database files in the database that you plan to migrate, including the size of the redo logs, by running the following query:
```
SELECT SUM(BYTES)/1024/1024 SIZE_IN_MB FROM DBA_SEGMENTS;
```
To find the sizes of the redo logs, query the V$LOG dynamic view.
```
SELECT GROUP#, BYTES FROM V$LOG;
```
Determine the workload level.

You can generate an Oracle Automatic Workload Repository (AWR) report to find a sample of the workload for the source database. Alternatively, you can generate an Automatic Database Diagnostic Monitor (ADDM) report to find the source database performance over a period of time between specified snapshots. The time model statistics, operating system statistics and wait events provide a relatively clear measure of the workload, in terms of the operating system capacity.
Determine the environment variables that are set in the source database.

You may want to use these same settings in the target database.
Check the database character sets in the source database.

You can find the database character sets by executing the following query:
```
SELECT NLS_CHARACTERSET, NLS_NCHAR_CHARACTERSET
 FROM NLS_DATABASE_PARAMETERS;
```
The target database must also have these character sets.
Determine the disaster recovery plan that is currently in place.

For example, if Oracle Data Guard is already deployed, then you can create a standby database for the migration procedure. If off-site backups are used, then you should plan on making a new backup to Oracle Cloud, using Oracle Recovery Manager (RMAN).
Check if you have Oracle GoldenGate configured with the source database.

To find information about Oracle GoldenGate, execute the ggsci utility. Oracle GoldenGate can be used as an alternative migration tool if you do not want to use Oracle Data Guard for the migration.

Simplify and Optimize Your Database Before Migration

Before you migrate your database, you can reduce downtime by upgrading to the target platform version, dropping unused objects, and performing other optimizations.

Any database platform migration should include a significant amount of testing in addition to the following simplification and optimization strategies.

Simplify: Most database environments that have evolved through different versions and different database administrators contain old information (and the current DBA might question why some object, data, policy, or similar, is used in the system). The purpose of simplifying is to make administration easier and more reliable. This simplification leads to a more highly available system.

Consider dropping schema objects that are not needed in the source database before the migration. This can reduce the amount of data that is migrated.
Optimize: In many cases, the migration involves an updated database version including new features. While performing a migration you should consider adopting new features and best practices recommendations.

Consider upgrading the source database to match the target database version as this may improve the migration (in some cases significantly). For example, the parallel capabilities of Data Pump are enhanced with each new Oracle Database release, so a database export from the source system could be improved and completed faster if the source database is upgraded to match the target database version.

Consider whether you can perform the migration in stages. For example, if the source database contains a large amount of read-only data, it might be migrated before the live data migration, to reduce downtime.