Exadata - Non-Exadata Database Migration Approach

In A real time Exadata environment, DBA sometimes get the request or requirement to migrate the database from non-Exadata environment to Exadata environment and to perform this kind of activity DBA need to go through multiple phases and also choose the correct path for the successful migration of the database in Exadata environment.

 

Phases Of Database Migration In Exadata Machine

                  

                      Capacity Planning

                                    ↓

                     Choose The Migration Approach

                                 

                                     ↓

                       Actual Migration

                                    ↓

                     Post Migration Steps OR Validation       

  

Phase 1: Capacity Planning

Whenever DBA have to migrate the database from non-Exadata to Exadata machine then the first and foremost thing they need to consider is the underlying storage capacity because the data will start residing from traditional storage server to Exadata cell servers. During the capacity planning phase in addition to determine the exact database size they also must have to be aware about the workload of their environment because during the capacity planning IOPS and MBPS are also one of the important factor to determine to get the database performance after the migration because once we migrate the database into Exadata machine several other feature start applying in the sql statements like smart scan,hybrid columnar compression , storage index etc. and we can determine the IOPS and MBPS from the physical statistics of the disk and to retrieve this information we can use physical read and physical write of the AWR report, we can retrieve multiple AWR report of peak hour as well as good time so that we can also consider the IOPS and MBPS in addition to disk storage.

 

Phase 2: Choose The Correct Migration Path

 

There are several methods available to migrate the database from Non-Exadata to Exadata environment however there are several pre-checks that we need to be done prior to choose the correct migration path such as:

 (1)  Determine what to migrate

 (2)  Consider the configuration of the source system 

         (2)(A) Determine whether we need to migrate the database into the same version or upper version in Exadata machine

               2(B)Database character set of the source and target system

               2(C) Endian formats of the source database and target database

               2(D)Architecture of the source database whether it’s non-cdb or CDB

          2(E)Choose the architecture of the target whether to migrate source into non- CDB or CDB.

 

Things To Remember Prior To Start Database migration

(1)  DB Parameter

COMPATIBLE = 11.2.0.0 OR Later

DB_BLOCK_CHECKSUM = TYPICAL | FULL

 (2)  ASM DISK GROUP ATTRIBUTE

 

(1)  COMPATIBLE.ASM=11.2.0.0 OR Later

(2)  COMPATIBLE.RDBMS = 11.2.0.0 OR Later

(3)  CELL.SMART_SCAN_CAPABLE=TRUE

(4)  AU_SIZE=4M

 (3) Since The ASM AU unit is 4 MB, so database extent size are must be multiple of   4 MB.

NOTE: The endian format of Exadata machine is little, so if we’re migration from a big-endian format, some physical approaches are not feasible or require extra processing and in addition to that some database objects may also impose some restriction such as materialize views or object data type.

 

Migration Method broadly classified into 2 types:

 

(1)  logical migration and

(2)  physical migration

 

NOTE: In Addition to the above 2 approach, we can also use other available migration Approach.

 

Logical Migration: This approach we basically use when we need to change the database extent size or alter other physical characteristics of the database such as database character set which is not possible by physical migration approach. There are 3 method comes under logical migration approach.

 

Migration Approach	Cross-Version Support	Support Physical Reorganization	Cross-Platform Support	Outage Time for Migration
Logical Standby	Yes, only for rolling upgrade	Yes, but some limitation	Yes, little endian only	LOW
Insert-As-Select, Manual m Migration Using SQL	YES	YES	BROAD	Depends On Data Volume
Data Pump  Export/Import	YES	YES	BROAD	Depends On Data Volume

 

Logical Standby Migration Approach: This approach we can use to replicate the database and merge the changes while the source database runs and after that we can switch the role of logical standby in primary and decommission the source database however there are certain limitation with logical standby database as it doesn’t support all types of database objects and also to include those object we’ve to execute certain parameter or use certain procedure which unnecessary require extra processing.

 

Insert-A-Select: In This approach we can create structure of our database object using Data Pump, SQL Developer etc.  and then use a database link to perform insert as select statement. This approach support to change the physical attribute in target database system.

 

Data Pump: This approach is an easy approach however the issue with this approach is that we need a large outage window if the database size is huge.  This approach also supports cross platform, cross DB version as well as physical reorganization of the target database

 

Physical Migration Approach: Thre are 5 methods comes under physical migration approach

 

Migration Approach	Cross-Version Support	Support Physical Reorganization	Cross-Platform Support	Outage Time For Migration
RMAN BACKUP/RECOVERY BACKUP BASED MIGRATION	NO	NO	Linux, x86x64 only	Depends On Data Volume
Physical Standby Database	NO	NO	Limited,little-Endian Only	LOW
Transportable Database Migration to A different Platform with Same Endian Format	NO	NO	Little-endian Only	Depends On Data Volume
Transportable Tablespae Migration to A Different Platform with a different Endian Format	YES	NO	BROAD	Depends On Data Volume
Unplugging & Plugging, OR Remote Clonning, but for this A PDB or Non-CDB require 12c or later version	Limited	NO	Little-Endian Only	Depends On Data Volume

 

RMAN BACKUP/RECOVERY: This traditional approach we can also use for migrating the database and to perform this operation we need to need take the backup and restore the database using that backup however storage is one of the thing that we need to check in the target database to store those database backup and this approach only works when our source database is running in little-endian format. In addition to manual restore we can also use the duplicate method to perform migration however in that case the duplication depends upon data volume and also the speed of data transfer over the network.

 

Physical Standby Approach: Physical standby is a block-to-block replica of the primary database, this method is widely used for non-Exadata to Exadata migration and this approach also require very low downtime since we can perform the switchover operation and then cutover the old non-Exadata database but this approach allow no physical attribute changes.

 

Transportable Database To A Different Platform: This Approach uses the RMAN to migrate the whole database between platforms that share the same endian format. The target database will be a block-to-block copy of the source database.

 

Transportable Tablespace To A Different Platform: This approach require the database file to put in read only mode and it also require to copy the database files physically from source to target database machine and then we’ve to use the data pump export/import to load the data, The only difference between transportable Database and Transport Tablespace approach is that transportable database approach also copy the administrative tablespaces such as SYSTEM,SYSAUX etc. however transportable tablespace feature doesn’t require those administrative database files. To reduce the downtime, we can use transportable tablespace with incremental backup approach.

Unplugging,Plugging and remote cloning: This approach require the source & target database must be run in 12c or later version where we can unplug the PDB from source database and plug it into the CDB of Exadata machine, similarly we can use remote cloning of PDB with the help of a database link however the data transport depends upon the network capacity between non-Exadata to Exadata machine.

 

Other Migration Approach

 (1)  Golden Gate: Golden gate is also one of the technologies that we can also use for the migration and it also require very less down time.

(2) Hybrid Approach: In this approach we can migrate database using transportable tablespace method from current database to a staging database outside the Exadata machine and then use Data pump to unload data from the staging database and finally load it into Exadata Machine.

 

Phase 3: Actual Migration

 

Execution steps depends on the method we choose for the migration

 

Phase 4: POST MIGATION STEPS

 

One the database migration phase completes successfully from non-Exadata to Exadata machine then we’ve to perform some post approach:

 

(1)  Configure the IORM, DBRM

(2)  validate database performance

(3)   Approach Application team to start load testing

(4)  Ask Application team to validate SLA testing

 

NOTE: In the post migration steps I’ve only mentioned few of the approaches that we need to follow however the post migration steps are not limited to the given above.