Oracle very kindly offered to run through a Proof of Concept installation of their GoldenGate replication product with us, and seeing as how we’re not prone to looking gift horses in their mouths, we’ve accepted!
I’ve written about GoldenGate before so I was particularly interested in seeing how it could work in the real world. The use case of interest to us revolves around zero-downtime upgrades as we have two major system upgrades every year that result in several hours of an outage on a critical energy trading platform. If we can reduce the amount of downtime those upgrades cause it would be a major win for the DBA’s.
The Oracle consultant arrived this morning, over from the UK, and we (me and the rest of the DBA team) got into things straight away. We started off by presenting an overview of our environment, which is always beneficial for everyone as the environment is large and highly complex with a lot of interdependencies between applications all resting on a large (~1.4 TB) database, so I got as much out of the overview as anyone else.
After the environment overview came a run through of the GoldenGate architecture and how it sits alongside the database(s) it’s working on. The brief Q&A session after focused on how GoldenGate can take over some responsibilities from Data Guard and where it can provide functionality not currently available or in use in our environment. From there, the conversation moved on to a more detailed discussion of possible GoldenGate use cases, with particular reference to situations similar to ours.
With the pleasantries over we got down to installing GoldenGate on two servers running Oracle Linux 5.5 and Oracle Database 11.2.0.2.0. The initial installation is easy enough and reminiscent of SQL Developer where all you need to do is unzip and untar some files into the right place (though there are profile parameters like LD_LIBRARY_PATH in use that need to be preconfigured). With the software in position the GoldenGate Command Line Interface (GGSCI) was available for use and configuration could begin in earnest.
Within GGSCI the GoldenGate directory structure is created in readiness for the setup of the processes that actually do the work. Essentially, GoldenGate is made up of a handful of processes running across the source and target systems. On both sides sits a Management process that controls the running of the other processes and handles some inter-process communications. On the source an Extract process captures data as it flows though the redo logs (our GoldenGate setup is running in classic mode as opposed to the newer Integrated mode which apparently starts the data collection inside the database instance) and outputs the data into trail files. Another Extract process pulls the data from the trail files and pumps it into remote trail files sitting on the target server. On the target, another extract process (referred to as the “Replicat”) extracts the data from the trail files and delivers it into the target database.
By the end of the day we’d seen GoldenGate installed and configured to capture and deliver data from a test table in a source database to a target database. Overnight, we have a backup running that we’ll use to clone the database ahead of setting up complete replication tomorrow.
Martin Minnock 