Migrating Oracle Data to Amazon RDS with GoldenGate

The migration of databases to cloud has increased rapidly in recent years and it’s not hard to see why. Moving your capital expenditure (CapEx) costs into operational expenditure (OpEx) budgets offers greater flexibility and lower risk but there’s still a major blocker in the way – how do you get your Oracle data in there without major downtime? We’ve got the answer – Oracle’s GoldenGate.

Did you just spit your coffee out? I know, I know… GoldenGate (GG) is heralded as eye-wateringly expensive with processor costs equal to that of Enterprise Edition Oracle DB! To make things worse you’re likely to only need a license for a short period of time when doing a cloud migration, making the CapEx a double hit. If you listen carefully you can hear the thud of GoldenGate hitting the cutting room floor. But let me ask you this, what if there was a way to use Oracle’s solution using an OpEx model instead? Well, we’ve done just that! Let me tell you how…

The methods we considered were:

• ActiveGuard – ruled out as Enterprise Edition only
• Logical Standby – ruled out as Enterprise Edition only
• Snapshots (of various types) – didn’t offer the real-time reporting data required
• 3rd party tooling – none would work with RDS
• GoldenGate – seemed overkill but was the only solution that met customer requirements

The customer agreed it was the best way forward, and this is when we had our epiphany. RDS environments are heavily locked down by Amazon so we were restricted on what we could deploy, meaning we needed to install the GoldenGate Manager Hub remotely – not uncommon but an interesting project nonetheless. The steps we took were:

Step 1: Create an EC2 instance with security VPC rules to control access

Step 2: Create an S3 bucket with Oracle and GoldenGate binaries

Step 3: Deploy a second RDS instance as the target

Step 4: Set up terraforming scripts to install GoldenGate on the EC2 instance, set up the GG Hub, and initialise the GoldenGate extract and replicate processes including deploying the GG users etc…

Step 5: Initiate monitoring on the GG services to offer the service wrapper needed It ended up a bit like this: What we ended up with is a fully repeatable, secure and efficient method of setting up a GoldenGate extract which we could replicate from anywhere to anywhere via an EC2 hub. So, we can re-deploy this for anyone and, perhaps most importantly, we can REUSE the GG Hub.

So, what’s the epiphany? Well, GoldenGate licensing, just like the Oracle licenses, are not restricted to a specific database. You can shut down one database and start another under the same license, or you can run multiple instances on the same host without invalidating any of your contract. If someone only needs a GoldenGate license for a short time (e.g. to migrate to cloud) then a remote hub can be set up, the source database linked to it and a target built before we define the replication rules, let the migration run (allowing for dual running and a full testing suite to be deployed to ensure everything is perfect), and, finally, terminate the links.

What does all this mean? It means you don’t need a GoldenGate license (as you would use the hub license and reusable processor licenses). This turns the high CapEx costs into more manageable OpEx ones, letting someone else take the risk of the licensing costs while you get a fantastic end result!

Interested to see for yourself how N4Stack can cut costs and mitigate risk by utilising GoldenGate during your cloud migration? Give me a shout!