AWS Oracle Classic RDS Features & Limitataion

Edition and licensing => License included (SE2) or BYOL (SE2/EE)

Multitenant PDB in CDB (licence & Maint cost reduction)  => 1 PDB

No of Database => 1 DB per RDS instance

Applications require access to underlying OS =>  N/A

Applications require access to underlying DB Env =>  N/A

sysdba privilege access  => N/A

Huge Pages (better Performance) => N/A

Local Undo => N/A

Data Guard Max Availability => with Multi AZ (no access on secondary) 

RDS database Patching =>  AWS Managed

Create a Multi-AZ deployment => Yes

Change CPU cores and threads per core on DB instance class => Yes

Turn on storage autoscaling => Yes

Automatic minor version upgrade => Yes

Kerberos authentication. => Yes

Performance Insights => Yes

TDE Encryption => Yes

Billing can be stopped => Yes

Scaling AWS          => Yes

High availability =>  AWS Managed

Database backups =>  AWS  Managed

Database software install => AWS Managed

OS patching =>  AWS Managed

OS installation => AWS Managed

Storage Limit => 64TB

Migrate Oracle Database to Any Cloud (AWS,Azure,Google,IBM etc ) Using Native Tool - Datagaurd

Oracle Database Migration to Any Cloud (AWS,Azure etc )

 Pre-communication (No-Downtime)

• Ensure and agreed with plan & cutover window 
• Ensure all stakeholder should be on same page 
• Ensure everyone copid in mail and meetings
• Ensure all issue should be documented database & application wise during iteration/testing
• Dicussed and aggred who is from available during cutover winodw (application owner,database lead,infa lead etc)   

Pre-Migration Pahse (No-Downtime) 

On Source Database 

• Delete/Remove all backup tables /unused objects from database with help of application team 
• Do username & password backup  
• Get read only access to database server
• Ensure db_unique_name is the same as the db_name
• Set and crosscheck all parameter related to dataguard configuration 
• check remote connectivity is working fine and port should be open at firewall level 
• check and validate database corruption 
• prepare & test  shared mout point  (NFS/EFS/S3FS)  
• Take the database backup including archivelogs and standby control file to create standby database
• check and backup networkfiles (tnsnames.ora,listiner.ora)
• check if wallet is configured
• check if any encryption (TDE )is enables 

Prepare Target envirnoment (No-Downtime) 

• Install oracle binrary software & Build the target database server 
• Install Grid software if required 
• Install Oracle database binary 
• Configure & enable SSH & SCP (with help of root account - Infra team)
• Configure and validate all  mount points (database/aplication)
• Configure and validate same shared  mount points (NFS/EFS/S3FS) in the target server/s.
• Restore the database backup and configure standby database 
• Incase ASM add spfile to grid software using srvctl 
• Validate remote database connctivity  
• Setup dataguard replication  from primary (source) to standby (target) database 

Migration pahse (Downtime start)

• check and validate primary and standby database in sync and no GAP 
• Stop Application associated database 
• create test user/test tablespace and test table on primary database 
• Do 4-5 archive log switch on primary (source) database .
• Again check  and validate primary and standby database in sync and no GAP
• Check active database sessions in primary (source)  database. if still acitve after stopping the application ,  kill those users  
• Create a guaranteed flashback restore point - for this enough FRA space should be available 
• Multiple way to do 
• Using manual swithover 
• Using DGMGRL ( need to configure DGMGRL )
• Using manual Failover (No rollback in this case) 
• Validate the migated database
• Setup & validate connection with application  
• Configure & update on premise DNS with new IP address (target) and create load balancer rules (if using)
• Handover to application team for validation 

Post Migration phase (No-downtime) 

• Take golden database backup after successful migration 
• Configure & schedule  database jobs 
• Configure & setup database monitoring

Rollback Phase 

• Stop the application on target database 
• Rollback the database using restore point (source database)
• Update the DNS with old entry for rollback (if required)
• Start and validate the database 
• Connect with database & start the application 

 

High Level Oracle Database Migration Plan – Datapump

 Pre-Migration Phase: No Downtime

• Review the Source database configuration
• Build target environment in AWS Cloud
• Prepare target database 

 Migration Phase (cutover) : Downtime

• Source database backup 
• Transfer the backup to target
• Import backup in target database
• Validate the migrated database

 

Post-Migration Phase : Downtime

• Handover database to application team
• Application team start validation
• Decide Go-Live /No Go-Live
• Target database golden backup
• Release database and application

 

Note : Normally good for small database 

High Level Maria DB Migration Plan

Pre-migration Phase (No -downtime)

• Validate source and target database versions and engines.
• Identify hardware requirements for the target server instance.
• Identify storage requirements (storage type and capacity).
• Choose the proper instance type based on capacity, storage features, and network features.
• Identify the network access security requirements (firewall, port etc. ) for source and target databases.
• Prepare target database
• Configure and start an Amazon RDS DB instance running MariaDB.

 

Migration Phase (downtime)

• Using native tools to migrate database objects and data.
• In the source database, use mysqldump or mariadb-dump to create an output file that contains database objects and data.
• Transfer the backup to target (AWS RDS)
• In the target database, use mysql or mariadb to restore the data.
• Validate the migrated database.

 Post-migration Phase (downtime)

• Handover database to application team
• Switch the application clients over to the new migration database in AWS RDS .
• Application team start validation
• Decide Go-Live /No Go-Live
• Target database golden backup
• Release database and application

Rollback Plan 

• Start source database (Assume no data chnage on target database  after migration)
• Connect & validate Application with source database