Cloud Migration
* The migration method depends on several factors, including the version, character set, and platform endian format of the source and target databases.
* Many of the migration methods apply only if specific characteristics of the source and destination databases match or are compatible.
* We should consider several factor , when choosing a migration method like :-
* On-premises database version
* Database 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
You have several connectivity options when migrating to the Oracle Cloud Infrastructure.
* FastConnect: Provides a secure connection between your existing network and your virtual cloud network (VCN) over a private physical network instead of the internet.
* IPSec VPN: Provides a secure connection between a dynamic routing gateway (DRG) and customer-premise equipment (CPE), consisting of multiple IPSec tunnels. The IPSec connection is one of the components forming a site-to-site VPN between a VCN and your on premises network.
* Internet gateway: Provides a path for network traffic between your VCN and the internet.
There are various ways you can do DB migration to Oracle or Amazon Cloud, including
Export/Import, using SQL Developer, and RMAN based restore.
Other methods are:
Create a DataGuard in the cloud
Perform on-premise backups to the cloud and restore the cloud backup to create the DB in the cloud
Perform a DB server VM backup and restore the machine backup to the cloud, then restore it as new cloud VM
Use Oracle Golden Gate-based DB replication to the cloud
For AWS, Data Migration Services (DMS) is also a very effective method
Using Data Pump
Data Pump Supports cross platform backup and restore.
Using Full Transportable Export Import
The endian should be the same on source and target for this method.
Using Transportable Tablespace
Source and Target database should be on same Operating System version
Endian Format should be the same on source and target.
Using RMAN Transport Tablespace
Supports cross platform backup and restore.
No need to take the source tablespaces in read only mode, which means this method can be applied to production databases
Using RMAN Convert Transportable Tablespace
Source and Target database can be on different Operating System version
Endian Format can be different on source and target.
We should focus on some point before con considerations for migrating a database to the cloud: * Database size * Database version and edition * ARCHIVELOG mode: Migration methods such as RMAN hot backup, DataGuard-based migration, and many other methods require databases to be running in ARCHIVELOG mode.
Some information should be captured before deciding the migration method. * Migration level: Migration can be at different levels, such as DB server, DB schema, or even the table level. * OS endianness (Little endian/ big endian): Cloud providers do not support all OSs, hence chances of having to do a cross-platform migration is very high. For cross-platform migration, it is very important to know the OS endianness so that the appropriate migration method can be selected. * 32-bit/64-bit: 32-bit servers are not very common, but if you have very old legacy systems running on 32-bit, then you need to consider moving them as-is or converting them to 64-bit systems. * Application compatibility: While doing database migration, you need to consider whether the application is compatible with the proposed cloud deployment model. * Cloud deployment model (IaaS, PaaS, DBaaS): The migration method depends on the database deployment model.
Migration is multistep process; the different stages are like :
* Analyse : In the Analyze phase, you go through the customer requirements and key considerations.
* Identify : These inputs help in the next phase, called Identify, where you identify the migration method.
* Prepare : The Prepare phase is all about getting ready for migration by having things in place. For example, you prepare the target environment for DB migration.
* Migrate
* Validate
At a high level, all DB migration method consists of three phases, as shown in
* BAckup
* Transfer
* Restore
There are various ways you can do DB migration to Oracle or Amazon Cloud, including
Export/Import,
using SQL Developer,
and RMAN based restore.
Other methods are:
* Create a DataGuard in the cloud
* Perform on-premise backups to the cloud and restore the cloud backup to create the DB in the cloud
* Perform a DB server VM backup and restore the machine backup to the cloud, then restore it as new cloud VM Use Oracle Golden Gate-based DB replication to the cloud
* For AWS, Data Migration Services (DMS) is also a very effective method
A cross-platform transportable database is that the source and destination platform must share the same endian format.
Restraction
* The source and destination platform must share the same endian format.
* Redo log files and control files from the source database are not transported.
* New control files and redo log files are created for the new database during the transport process, and an Open Resetlogs is performed once the new database is created.
* Similarly, temp files belonging to locally managed temporary tablespaces are not transported.
* The temporary tablespace will be re-created on the target platform when the transport script is run.
* BFiles, External tables and directories, Password files are not transported.
* The Source and the target database version must be equal / greater than 10.2.0. Version
If your goal is to migrate a database to different endian platform, then you need to perform below steps :
* Create a new, empty database on the destination platform.
* Import objects required for transport operations from the source database into the destination database.
* Export transportable metadata for all user tablespaces from the source database.
* Transfer data files for user tablespaces to the destination system.
* Use RMAN to convert the data files to the endian format of the destination system.
* Import transportable metadata for all user tablespaces into the destination database.
* You could also convert the datafiles at the source platform and once converted transfer them to the destination platform.
