Learn and leverage database migration best practices from moving off commercial Oracle databases to Amazon RDS or Aurora. We’ll cover common pitfalls, issues, the biggest differences between the engines, migration best practices, and how some of our customers have completed these migrations.
Datavail is in process of doing a benchmark to determine where organizations are in their cloud adoption with a cloud adoption industry benchmark survey. The results of the survey will be shared on a future Database Trends & Applications (DBTA) webinar and you’ll be able to learn how your company compares to your peers in the industry on cloud adoption. We’ll be selecting a winner from our lab today to win a pair of Bose noise cancelling headphones.
As organizations look to migrate to the cloud, there are 3 core types of database migration paths:
Self-service: For many migrations, the self-service path through the use of the Database Migration Service (DMS) and Schema Conversion Tool (SCT) offers the tools necessary to execute With over 200,000 migrations completed through DMS, customers have successfully migrating their instances to AWS.
Migration partners: For assistance in the migration process, there are several migration partners that offer expertise to
Database Freedom program – this type of migration is the best for customers looking to move away from the punitive licensing costs of commercial database vendors and avoiding the vendor lock-in. This is Database Freedom. Most of these migrations have been from Oracle and SQL Server to our open source databases and Aurora but there are use cases for migrating to NoSQL databases as well. For example, an online store may have started on a commercial or open source database but now is growing so fast that they would need a NoSQL database like DynamoDB to scale to millions of transactions per minute. Re-factoring, however, typically requires application changes and does more time to migrate than the other migration methods.
Using the Database Migration Service (DMS), you can make homogeneous migrations from your legacy database service to a managed service on AWS, such as from Oracle to RDS Oracle.
Alternatively, leveraging both DMS and the Schema Conversion Tool (SCT), heterogeneous conversions are possible, such as converting from SQL Server to Amazon Aurora.
The Schema Conversion Tool assesses the source compatibility and recommends the best target engine. The tool attempts conversion of all schema and code objects to the target engine, including stored procedures and functions. It scans and converts embedded SQL statements in app code, and generates a report with recommendations.
Level 200
Level 300
Level 200
Level 200
Level 200
It wasn’t possible to backfill without tooling.. We found DMS
Backfill process involves moving data from Oracle to DynamoDB without invoking the application
Backfill using DMS involves creation of replication instances, tasks and endpoints
DMS configurations are used to specify source, destination, attribute mapping, conditional expressions for writing to DDB etc…
Log miner (D) Oracle utility (Impact on the Source) , ** CDC with BLOB and CDC 12C
Binary reader Copy the redo on to DMS and we mine the redo log (Decrease cpu, memory on On source but Network usage)
NumberDataTypeScale 38 precision, pg -- > 128
Standbydelaytime Delayed replication
maxFileSize mine the data and creates csv files
Session replication role = replica
session_replication_role='replica’ FK disable
LOB columns are excluded from the migration.
Full Lob Mode - Migrate complete LOBs regardless of size. AWS DMS migrates LOBs piecewise in chunks controlled by the Max LOB size parameter. This mode is slower than using Limited LOB mode.
Limited Lob Mode - Truncate LOBs to the value of the Max LOB size parameter. This mode is faster than using Full LOB mode.
In Limited LOB mode, LOB columns which exceed Maximum LOB size will be truncated to “Max LOB size”