Cloud databases are increasingly popular for reducing IT complexity and operating costs as well as dependence on specialized IT teams. Oracle Database is great, but it’s also one of the most expensive and complicated options, and it comes with proprietary code elements.
When thinking about migrating your Oracle workload to the AWS Cloud, consider that users have three ways to operate Oracle Database in the AWS:
EC2
Use the AWS compute service along with the block storage service Elastic Block Store (EBS) to run traditional self-managed Oracle Databases in AWS. This requires a significant level of expertise from the IT team.
RDS
Use Amazon RDS for Oracle, which is a managed relational database service. This falls under the database-as-a-service (DBaaS) deployment
model. AWS takes care of installation, hardware setup, configuration, provisioning of storage, and network setups. It also takes care of server maintenance, software patch management, version upgrades, and backups. Scalability/elasticity, reliability, and high availability can be achieved easily.
Aurora
This is an RDBMS developed, designed, and optimized by AWS for its cloud infrastructure and its DBaaS deployment model.
Migration of Database
Moving databases is the trickiest part of cloud migration, which often requires downtime and reworking of the schemas; hence an iterative process is better. Here is a brief checklist to follow:
1. Assess the current environment/database. This is an important step in the overall migration process. Determine the features of the Oracle system currently in use; for example, partitioning, OS-level process control, and size of the database. This will help in determining how much storage you need in the cloud and establish cloud compatibility. This must be done at the schema for each of your databases. Depending upon the results of this assessment, the migration complexity will vary.
2. Choose the deployment model: self-managed cloud database or DBaaS. The easiest choice may be self-managed EC2 servers, as users retain full control of the underlying OS, while a switch to RDS/Aurora is the most involved method to replace an Oracle Database. With a self-managed model, EC2 users retain control and the ability to customize, though it carries additional management and overhead costs for database administrators (DBAs). When users choose the DBaaS model, DB maintenance tasks are handled by AWS, reducing the dependency on the availability of skilled resources for daily operations.
3. Choose the target RDBMS technology. If the target RDBMS is not Oracle, migration becomes a two-step process. The first step is to convert the database schema with the AWS Schema Conversion Tool (SCT). Then, you copy the data to the new data store using the AWS Database Migration Service (DMS). AWS provides a set of Database Migration Playbooks that guide you through the process, including configuration settings, and present best practices to streamline a successful heterogeneous database migration.
Helpful Tools
Two tools, already noted in the preceding checklist, are helpful:
AWS Schema Conversion Tool
SCT will generate a conversion report that identifies the issues, limitations, and actions required for the schema conversion. This report helps with assessing the complexity of an RDBMS conversion, and whether a DBMS can be converted. The tool also generates target schema conversion scripts to be applied before running DMS. These will do any necessary code conversion for objects like procedures and views. Not all objects can be converted, and SCT reports can help identify those clearly.
Database Migration Service
After the schema is converted and updated for Postgres RDS/Aurora, the DMS can load or copy data into the target database. You can arrange for an ongoing replication from source to target with minimal setup and configuration changes on the source database. Validations and CloudWatch logs help debug any issues in migration of data. Following migration and validation, applications can be switched to a migrated database with minimal downtime.
Although the SCT and DMS tools simplify the most tedious tasks in the process of data migration, they are nowhere near complete solutions. Heterogeneous migration does involve significant development efforts and must be implemented after careful consideration.
