Introduction to Oracle Goldengate

Name: Introduction to Oracle Goldengate
Uploaded: 2026-09-05T15:45:37.472Z
Duration: 56 min 55 s
Channel: Ashish Agarwal Goldengate Tutorials
Description: This video introduces you to what is Goldengate, its advantages and walk through the architecture of Oacle Goldengate

Ashish Agarwal Goldengate Tutorials

Sep 5, 2026

This video introduces you to what is Goldengate, its advantages and walk through the architecture of Oacle Goldengate

Hi everyone. Welcome to Oracle GoldenGate regular session. My name is Ashish Agarwal and I'll be delivering this training to you. And this training is presented by BISP Solution. So agenda of this training as we discussed in our introduction session, but let us now go through some low level topics. So we'll be discussing introduction to Oracle GoldenGate. Then we'll be discussing about architecture of Oracle GoldenGate. Architecture is one of the most important topic of GoldenGate. Then we'll be downloading the software from Oracle site and installing it on our virtual boxes. We'll be discussing about what are the concepts and components involved in Oracle GoldenGate. How does DML replication works? Whenever you do insert, update, delete the objects which require exclusive commit. So how DML replication works. So in this we'll be discussing about extract data pump and replicate as well. Then we'll be discussing about initial load. What is the difference between database, utilities, export import and arm and duplicate. Then we'll be discussing about bi-directional configuration. So your application can be connected to any environment. One of the main advantages of GoldenGator, it supports bi-directional configuration. So your application can be connected to either or both of the environment. The transactions will get replicated from one environment to other environment. Then we'll be discussing about performance related parameters. How to monitor the lag? What is GoldenGate checkpoint? Then we'll be discussing about troubleshooting. We'll be continuing during the sessions. We'll learn a lot of method of troubleshooting. How you should strategize? Now once the GoldenGate is set up, the next step which comes is how to troubleshoot GoldenGate. So how troubleshoot happens? How to perform troubleshooting in Oracle GoldenGate? We'll be discussing. Then checkpoint. Now checkpoint is one of the most important topic of Oracle GoldenGate. How GoldenGate maintains checkpoint internally? We'll be discussing that. Now remember there are two terms common between GoldenGate and Oracle, datapump and checkpoint. So whenever we are referring to these terms, we are referring to GoldenGate checkpoint and GoldenGate datapump until and otherwise specified. Then we'll be discussing about defgen utility of GoldenGate. So defgen stands for definition generation. So how does GoldenGate replicates the data from source to target between databases having different structures? Or how does GoldenGate replicates the data between Oracle to GDD using the defgen file? So we'll discuss about defgen. Then we'll be discussing another important feature, configuring Oracle GoldenGate security. Parameters we'll be discussing in our fifth fourth session. This again is one of the most important topic of GoldenGate. And then we'll be discussing about logdump. How to read your trail files? Your trail files are binary format trail files. So logdump utility is used to read your trail files. How you can use it? We'll be discussing that in a logdump. So Oracle database architecture. First of all, let us discuss about Oracle database architecture and what all components are required by GoldenGate in case of Oracle database architecture. Now, every database has its own transaction locks wherein the changes are stored. So those changes are recorded in a transaction locks of the database. So in case of Oracle, that transaction locks are redo locks and backup of redo locks, which are known as architecture. So your Oracle database architecture consists of two parts, instance and Oracle database files. Now instance again is divided into two parts, memory structures and background processes. Oracle database is divided into three parts, data files, control files and redo lock files. Now, in memory structures, you have shared pool, database buffer cache, Java pool, redo lock buffer and large pool. Background processes are PMON, SMON, DBWR, log writer, database checkpoint and there are other GoldenGate background processes. Now, the memory structure, whatever changes are happening, first of all, dirty buffer gets returned into the database buffer cache and those changes then are returned into the redo lock buffer. The copy of those changes gets logged, gets returned into the redo lock buffer and then from redo lock buffer to the redo lock file, those changes are returned using the log writer process. The log writer process is responsible for writing the data from redo lock buffer to redo lock file. Now, log writer process writes data from redo lock buffer to redo lock files in the conditions which are mentioned over here. So, whenever the commit happens, the changes are returned from redo lock buffer to redo lock file or when it is one third full, when redo lock buffer is one third full or there is one MB of redo or every three seconds or before database writer process writes. So, these are the conditions with which the redo lock buffer, data from redo lock buffer gets returned to redo lock file using the log writer process. So, actual data is returned into your data files. So, whenever any data in employee table, whenever you do select staff from employer, you get the data from data file. Control files are the metadata or the heartbeat of Oracle database. They contains the metadata information, data about data. And redo lock files contains the changes which are made to the data. Now, database architecture itself is a big topic that we can spend almost two, three days. So, we are not going to discuss all the components over here. We'll be discussing only those components which are required by Oracle GoldenGate. So, the GoldenGate is a change data capture tool. Along with GoldenGate, DataGuard is also a change data capture tool. Oracle Streams was a change data capture tool or IBM ShareFlex, Dell ShareFlex is again a change data capture tool. IBM Mirror is a change data capture tool. Now, what do we mean by change data capture? By change data capture, we mean that they capture the changes, whatever changes are happening in the environment. They capture those changes. So, the changes are captured from where? The changes are captured from the transaction log. So, in case of Oracle, those changes are captured from redo lock files and the backup of redo lock files are known as archive lock files. So, whenever a change is returned, it first gets returned to the redo lock file and then when the backup of redo lock files is taken, it is known as archive lock file. So, as soon as data gets returned into redo lock file, the backup is taken and then they get returned to the archive lock file. So, archive lock files consumes space on your operating system. Again, they are binary format files. You cannot read them directly. So, for GoldenGate, to capture the changes, it reads the changes from redo lock files or archive lock files. First, it searches for the records in redo lock files, then it goes into archive lock files. Now, whenever any change is made to the database, a SCN gets generated, system change number gets generated. So, GoldenGate, how does GoldenGate maintains data integrity is it reads the transaction logs in the sequential manner. It captures the transactions based on SCN, system change number, and then the transactions are output to the target database in the order of CSM. Now, GoldenGate, whenever you do any changes, a SCN gets generated. As GoldenGate captures only committed transactions, it names them as commit sequence number, CSM. So, GoldenGate reads your transaction logs in sequential manner. However, it is going to capture only your committed transactions in the order of your SCN. And then, they get replayed on the target database in the same order as they are happening on the source data. So, for GoldenGate, as it is a change data capture tool, the transaction logs of database, redo lock files and backup of redo lock files, which are archive lock files, these files are important and necessitated for the GoldenGate capture. So, with 12c, now, with 12c multi-tenant architecture, you have container and pluggable combination, means you have a multi-tenant architecture of database, wherein multiple container and pluggables, multiple instances of database is there. So, in those databases, the instance memory structures are shared, along with that, the database files are also shared. So, now, in case of multi-tenant architecture, suppose you have one container and two pluggables. So, basically, you have three files, three databases. So, in those three databases, redo lock files and archive lock files are shared, and then changes are extracted from your redo lock. So, redo lock files and archive lock files are important for GoldenGate replication, in case of Oracle. For MySQL, we call these files as transaction logs. So, different databases have different names, but every database has its own transaction logs, wherein the changes gets recorded. Now, there are various data replication tools, which are available in the market currently. So, following is the list of solutions available today. These are the GoldenGate Competitors, EMC RecoverPoint, IBM Mirror is there. This also is one of the major use, means not that like GoldenGate, but still, in some organization wherein DB2 is used, they are using IBM Mirror. Hitachi TrueCopy is there. HP has its own product, which is known as HP Continuous Access. Semantic Veritas Volume Replicator is there. Then you have DataCore, SenSymphony and SenMelody. Along with that, there is one more tool, Dell ShareFlex, which again is a, means, somewhere, not at many places, but yeah, at some places, that tool is also used. So, when there are so many tools in the market, why GoldenGate? Why GoldenGate is getting used? So, remember, performance of any change data capture tool is measured in two aspects. First is lag, and second is data integrity. So, lag is the time difference between which a record gets committed at source and it is being applied on target. That time difference is known as lag. So, suppose you commit a record at 10 p.m. and it gets applied on the target database at 5 past 10. So, that time difference of five minutes is known as lag. And data integrity is, suppose you want to replicate, whatever you want to replicate, there should be zero data loss. There should be no compromise with data integrity. So, the tool which can replicate the data from source to target with minimum lag maintaining data integrity is the best tool. So, GoldenGate scores above its competitors because of this reason. Also, there are certain restrictions with other tools, like they are not compatible with all the databases, which Oracle does. The lag, the speed with which GoldenGate replicates the data from source to target is very high. So, GoldenGate sends the data in real time with sub-second latency. It supports heterogeneous environments. So, just like DataGuard, you should have, in DataGuard, you should have same platform. If you have Windows on source, Windows on target. Linux on source, Linux on target, which is not the case with GoldenGate. On source, you could have Windows. On target, you could have SunSolaris. On source, you could have HPUX. On target, you could have Linux or Exadata SQL. Also, different databases are supported. So, it also supports now NoSQL database from 12c. In 11gr2, it started the support of Informix database. So, GoldenGate was developed initially for the Enscribe database, which is used in ATM databases. It was initially developed, and it was the only tool for first, after its development for first five to six years, it was the only tool who could have replicated Enscribe. In 2009, then Oracle overtook it, and since then, it is known as Oracle GoldenGate. And since 2009, its capability to support various other databases has been increased drastically. So, almost all the databases on all the platforms, its support is extended. GoldenGate also ensures high performance with low impact. So, the impact, GoldenGate is an external tool. Now, it's a tool which reads data from your transaction logs. It reads data from your redo logs and archive logs. Now, definitely, when the process hits the database, external process, it has some impact. We cannot say it's a no impact. So, the impact it has in comparison to other tools is very low, and the performance is very high. Ability to move large volume of data very efficiently. So, you could replicate the log, blob, all large objects very efficiently and quickly over the network using Oracle GoldenGate. And no single point of failure. So, GoldenGate ensures that your database is highly available. Your source database is kept in New York. Target is kept in, secondary server is kept in California. So, due to some reason, due to some disaster in New York, or due to some power failure, server crash down, your server is not working, your New York server is not reachable. So, what your application can do? Application can switch to your California server and can operate from there. Can ensure that your database is highly available. Your business continuity is not interrupted. Then, GoldenGate supports existing Oracle products as well. So, it ensures that continuous availability for heterogeneous systems. So, your database, as we discussed, is always highly available. Real-time data access for reporting. So, GoldenGate can replicate the data from source to target, and can ensure that your reporting jobs can run from the target server. As we discussed in our intro session, I gave you an example of State Bank of India. So, State Bank of India, earlier their OLTP transactions were coinciding with the reporting job. Now, because of which, the customers of State Bank of India were very frustrated because of very less responsive nature of the database. Due to which, SBI was losing a lot of customer, and it was, in fact, at that moment, we estimated the loss of around 10 crores rupees a day because of that. Then, they switched to GoldenGate, and then reporting jobs were then running from their secondary server, and the loss which they were incurring, it was down to around 50 to 80 lakhs. Still, there was some loss, but it was due to some other reason. We can discuss that later on. Then, real-time data for business intelligence, EPM, Exadata. So, GoldenGate, in current scenario with ODI, when you couple GoldenGate with Oracle Data Integrator, it is one of the best solution for business intelligence. It is, like Informatica, it is one of the best tool available in market for business intelligence. Then, GoldenGate also supports zero downtime migration and upgradation. So, if you have to upgrade your database from 11G to 12C, it requires some downtime. I was working for one of the client of UK two years back. So, while working over there, their database size was only 40 GB, but it was a critical database for them. Now, when they upgraded from 10G to 11G, they had to take the downtime of 12 hours, because of which, that was their main database, which was source for all the other applications. As a result, all the application was done. It is a big telecom giant I'm talking about. As a result, they estimated the loss of one million pounds on that day. Can you assume how much that means to an organization? So, next time when they upgraded, they used GoldenGate, and using GoldenGate, it was zero downtime upgradation. As a result, they were able to save that much amount. Then, these figures are taken from Oracle website, and they are quite old now. 2012 figures are these. So, in 2012, many organization, all the big players were using Oracle GoldenGate. So now, GoldenGate is being used in all the financial sectors, all telecommunication, all telecommunication big giants, Vodafone, British Telecom, AT&T, all are using Oracle GoldenGate. All financial institutions, Royal Bank of America, Royal Bank of Scotland, State Bank of India, HDFC, ICICI, all the financial institutions are using it. It is because of their regulatory reasons as well. The financial organization heading these banks, they have necessitated to use GoldenGate. In fact, in Canada as well, CIBC is using GoldenGate. Then, public sector, retail, utilities, food and drug store, everywhere GoldenGate is being used. So, GoldenGate solutions, it ensures high availability. So, if your source database is down, you can switch your application to the secondary server. It will ensure that your database is highly available. It supports zero downtime migration and upgradation. Live reporting, so you could use a secondary server for reporting queries. Then, business intelligence. GoldenGate with ODI is one of the best tools for business intelligence. So, these are the databases and platforms which are supported by Oracle GoldenGate. So, GoldenGate supports capture from Oracle DB2 SQL Server, Sybase, Ingress, Teradata, Enscribe. Now, this is the database which I was talking about, Enscribe. For which GoldenGate was developed. SQLMP, SQLMX, Exadata. Then, from Oracle on Exadata. Then, with the 11GR2, they have extended their support to Informix database from 12C now. No SQL databases supported as well. So, GoldenGate support has been extended to almost all the databases. Now, GoldenGate is a solution which not only replicates database-to-database replication. You can replicate data from database to flat files. You can replicate data from database to coherence cache using hotkey. So, recently, at my client location, we delivered a solution for Oracle GoldenGate, delivering the data to coherence cache using hotcache. So, during this training, we'll be discussing about database-to-database replication. Later on, once you are thorough with these database-to-database replication, then you can go ahead with database-to-cache replication. Then, platforms and OS which are supported are Windows, Linux, Sun Solaris, all HP variants, IBM, and Exadata. So, GoldenGate support has been extended a lot. You name anything, GoldenGate supports. In fact, GoldenGate is now supported for big data as well. GoldenGate also is supported on mainframe as well. So, let us now discuss about architecture of Oracle GoldenGate. GoldenGate is a tool which is not only supported for Oracle replication, it is supported for heterogeneous databases as well. So, every database has its own transaction logs from where the capture of data is done. So, let us now discuss one of the most important topic of Oracle GoldenGate, which is architecture of GoldenGate. So, this is how your Oracle GoldenGate works. So, you have source database as Oracle or non-Oracle database. Target database may be Oracle or non-Oracle. Now, every database has its own transaction logs wherein the changes are recorded. So, in case of Oracle, the transaction logs are known as redo logs or backup of redo logs, which are known as archive logs. Now, whatever changes are happening, those changes will be logged into your redo logs or archive logs once the backup is taken. So, you create a GoldenGate capture process which reads your transaction logs in your sequential manner. Now, your transaction logs may contain committed as well as uncommitted data. So, GoldenGate capture process is going to read your transaction logs in sequential manner. However, it is going to capture only your committed transaction. As soon as the transaction gets committed, it writes them to the storage on local machine, which are known as local trail. So, local trail consumes the space on your operating system. So, as soon as capture process captures, it writes them to the trail file on data machine, which are known as local trail. As soon as data gets returned into local trail, you create a GoldenGate data pump process which reads the data out of your local trail, sends it over TCP IP network and writes them to the trail file on target machine, which are known as remote trail. Once the data is returned into remote trail, you create a GoldenGate delivery process which reads the data out of your remote trail and applies it to target database. So, you have three GoldenGate processes involved over here, capture, pump and delivery. So, capture process and pump process resides on your source and delivery process resides on your target. So, capture process does the extraction of data. Capture process is responsible for extracting the data, extracting the changes which are happening in your source database. Pump process is responsible for transferring the data over the network. So, pump process reads the data from your local trail, sends it over TCP IP network and writes it to the trail file on target machine, which are known as remote trail. Trail files on local machine are known as local trail, while trail files on target machine are known as remote trail. Once the data gets returned into remote trail, the GoldenGate delivery process, it reads the data from your remote trail and applies it to target database. So, three GoldenGate processes are involved over here, capture, pump and delivery. Each process has a source to read from and a target to write to. So, capture process sources source database. Capture process is reading data from source database and writing data to local trail. Pump process is reading data from local trail and writing data to remote trail. Delivery process is reading data from remote trail and applying data to target data. Each process has a source to read from and a target to write to. Now, these trail files which you create, they consume space on your operating system. These are the binary format trail files and you cannot read them directly. For that, you have to use LogDump utility. We'll be discussing that later. So, binary format trail files are created and the reason why GoldenGate is platform independent, reason why GoldenGate works on any environment is because of these trail files. These trail files are platform independent. The format of trail files which gets created on Windows machine, it will be same on Linux machine. It is going to be same on Sun Solaris. It is going to be same on Exadata server. So, the format of trail files on whatever platform you create is always same. And the reason, this is the reason why GoldenGate is platform independent. It works on almost all the platforms. So, capture process, as soon as it captures, it writes it to the trail files. Now, these trail files have some definite size. Another reason why GoldenGate is fast is we call that GoldenGate replicates the data in real time. Why? Now here, these trail files have some size. By default, the size of trail file is 500 MB. You can increase it up to 10 GB. Now, GoldenGate pump process does not send the trail file over the network. Remember, it is not sending the trail file over the network. It is just sending the data which is written over here. It is just sending the data. So, as soon as capture process write one transaction into the trail file, at the very same moment, pump is going to send that data over the network. So, pump process, just unlike data guard, wherein the FTP process always waits for archive lock to get full. In case of data pump, that is not a case. As soon as capture process captures, it writes to local trail pump process at the very same moment, will send the data over the TCP IP network and write it to remote trail, and then delivery process will apply it to target database. Now, remember the three processes which you have configured over here, capture, pump, and delivery. All these three processes are independent of each other. Now, as capture process captures only committed transaction, remember, your trail files will have only the committed transaction. They cannot have uncommitted transaction. The reason being, the source of local trail is capture process, and capture process captures only committed transaction. So, your trail files of GoldenGate are going to have only the committed transaction. So, in case of bidirectional, what will happen? So, bidirectional is nothing but two-way unidirectional with some consideration. So, just like you have configured the GoldenGate processes from site A to site B. Now, create a GoldenGate unidirectional setup from site B to site A. So, your site B database is now going to have its own transaction log. Just like your site A database has its own transaction log, in the same way, your site B database will have its own transaction log. So, as soon as any transactional change happens on the site B database, you create a GoldenGate capture process, separate capture process on the site B, which will be responsible for the extraction of data from the site B database. And then, whatever it captures, it will write it to the trail file on local machine on the site B server, which are known as local trail. Then, you create a pump process on site B, which reads the data and sends it over TCP IP network and writes it to remote trail on site A. You create a GoldenGate delivery process, which reads the data from your site A database and applies it to target. So, in bidirectional, one of the USP of GoldenGators, it supports bidirectional replication. So here, in case of bidirectional, you will have capture, pump, and delivery process configured on both the environments, along with local trail and remote trail. However, all these processes are independent of each other. So, even if your capture process is down, your pump and delivery can continue to run. Even if your pump is down, your capture and delivery will continue to run. Even though your delivery is down, your capture and pump will continue to run. So, all these processes are independent of each other. So, capture process reads your transaction logs directly and captures only committed transactions. Whatever it captures, it writes them to trail file on local machine, which are known as local trail. Pump process does the data sending part over the network, writes the data to remote trail, then Replicat applies it to target data. In case of bidirectional, it is two-way, unidirectional. So, same process you will be creating on the other side. So, classic capture is the one, what we have discussed here is classic capture, which reads the data directly from the transaction logs of source database. Now, as it is a GoldenGate capture process, and it is reading the transaction logs of database, it generates some performance offset. Now, though the performance offset, which is being generated by GoldenGate, classic capture mode is minimal, but still, it is there. We cannot deny that. As a result, many organizations, like some of the organizations which have big database, they are susceptible to install GoldenGate, because their database performance is vulnerable in that scenario, and it may hamper the performance. Definitely, every organization will be wary of that. If it's a small database, then it's fine, but SBI, which has 43 TB of database around four years back, so they will definitely be susceptible. So, in that scenario, for the solution of that, GoldenGate introduced integrated capture in 11GRD. Now, with the introduction of integrated capture, you have both modes of capture available, classic and integrated. It's up to you. You can choose to use integrated capture, or you can choose to use classic capture. So, in case of integrated capture, what happens is, your extract process does not interact with your transaction logs of source database directly. In case of integrated capture, you have one more layer in between of transaction logs and extract, which is known as log minus. Now, whatever changes are happening in your database, those changes gets returned to the log-minor database. Log-minor database just contains the metadata information. It is just like, you use your log-minor to read the database archive log. So, it is that log-minor. You do not create anything separately in case of integrated capture. We'll be discussing that during our practical setup. So, in case of integrated capture, the extract process does not interact directly with the transaction logs of source database. So, in case of integrated capture, you have one more utility in between, which is known as log-minor. So, whatever changes are happening to your redo logs of database, to your transaction logs of database, those changes, a copy of those changes gets returned to the log-minor database. And then from there, log-minor sends those changes to the extract process in form of LCR. So, here the extract process is not scanning your transaction logs in full. What is happening? The data, whatever data changes are happening, they are happening at log-minor. And then log-minor is passing those changes, whatever changes are required by the extract process. So, there may be hundreds of tables in your database. However, your capture process is capturing the data of only two tables. So, in that scenario, extract process is not going to go ahead and read the transaction logs of data for all 100 tables, even though it has to capture only two tables. This work is done by log-minor database. And then log-minor, once you register your extract process with the log-minor database, then log-minor passes on the changes which are required by the extract process in form of LCRs, Logical Change Records. Now, once the changes are received by the extract process, it writes them to the trail file on local machine, which are known as local trail. And then, Datapump sends the data over the network and writes it to trail file on target machine, which are known as remote trail. And then, Replicate applies the data. Now, how to differentiate between the two? You can look, we'll be discussing this during the session part, how you can differentiate between them. So, log-minor is a database which contains only metadata information. So, it's automatically get created, just like you create a archive log, means whenever you have to mine your archive log, you just register your log-minor database. It is same. So, log-minor is also called a database, yes. So, the changes are returned to the log-minor database from redo logs, and then those changes are passed on to the log, extract process in form of NCR. Now, the question which comes in everybody's mind, in fact, it's a common question that what is the use of integrated capture? Why GoldenGate introduced it? The reason being, the classic capture was reading the transaction logs of source database directly. And as a result, the performance of database was getting hampered. It had some little impact. As we said, it generates some performance offset of around one to 2%, but for a big database, one to 2% is huge. So, with introduction of integrated capture, this performance impact has been reduced drastically. So, here in the extract process is not reading your transaction logs directly. Now, with the introduction of integrated capture, the lag of GoldenGate has been decreased as well. It has been decreased a lot now. In comparison to your classic capture, the integrated capture lag is very less. Now, the question which comes in our mind is, even though there is one extra layer of log minor, still, why lag of integrated capture is less than classic capture? Here in classic capture is reading the transaction logs directly. However, here, in case of integrated one, log minor extract process is receiving data from log minor. So, the answer lies in the architecture. So, here in case of classic capture, extract process scans your transaction logs in sequential manner. Now, even though your extract process has to capture the data of only five objects, even though there are 100 objects, it still has to scan your transaction logs, even though some of the transaction are of no use. But still, it has to scan. And as GoldenGate is an external process to the database, if it scans, it takes a bit time. In case of integrated capture, herein, the extract is receiving the changes, whatever changes are required by the extract process. So, here log minor is doing the scanning part. However, since this log minor is internal to database, as a result, the speed with which and impact which it has, it is not there. And speed is very fast because the log minor is internal to database. However, extract is external to database. So, we did, personally did one test in my organization. So, therein, we found that the classic capture can capture the transactions up to 8,500 per second. The lag was five seconds. And when we increase it to 10,000 to 12,000, lag increased to 30 seconds. And then, when we increase the transactions per second to around 15,000, the lag was very huge. It was, in fact, crossing a minute or two minutes, or more than that. Integrated capture on other case was very performance efficient. With the transactions ratio up to 14,000 to 15,000, the maximum lag which was noticed was two seconds. When we increased to around 18,000, the lag increased to around five to seven seconds. And then, the transactions were increased to 22,000. The lag was around 30 seconds. But lag never crossed a minute. So, integrated capture is very much performance efficient and also, it has very less impact on database. In comparison to the classic capture. So, herein again, you have three processes involved in the GoldenGate architecture. Capture, pump, and delivery. Along with that, you have local trail and remote trail involved. And on top of that, these all are GoldenGate resources. Capture, pump, delivery, and trail file. So, to manage its resources, you have GoldenGate manager process, which we'll be discussing while installing Oracle GoldenGate. So, let us now see how to install Oracle GoldenGate. So, Oracle GoldenGate, let us first of all download it and then we'll move to installation. So, we'll be installing Oracle GoldenGate on our virtual boxes. So, let us first of all download Oracle GoldenGate. So, Oracle GoldenGate software could be downloaded from Oracle website, support.oracle.com. Oracle GoldenGate binaries are available on support.oracle.com. So, you'll have to accept the license agreement. So now, when you download Oracle GoldenGate, so, the latest version which is available is 12.2, 12CR2 GoldenGate is available. So, first of all, you need to identify your source database as well as you need to identify the platform on which your database is hosted on. Based on that, you'll be downloading your binaries. So, remember, for each database and each platform, the binaries will or may vary. So, suppose you are downloading, you want to install Oracle GoldenGate for MySQL database on HPE. The binaries will be different. If you want to download Oracle database on SunSolaris, binaries will be different than the earlier. For Exadata, it will be different. For DB2 on Linux, DB2 on Windows, DB2 on any other platform, binaries will be different. So, before downloading, you have to first of all identify the source database and target database versions as well as what type of database they are. Along with that, you have to identify the platforms on which they are hosted. So, in our case, we have two virtual machines with Linux on both. So, there are two virtual machines which we are going to work on and both virtual machines have Linux x86. So, we'll be, and the database is Oracle. So, we'll be, so if you see here, the binaries here, the binaries for Oracle GoldenGate for Oracle database on AIX is different. Oracle GoldenGate 12.2 for Oracle on HP UX is different. Oracle GoldenGate 12.2 for Oracle on Linux is there. Then for Solaris is there. Solaris Spark and Solaris x86-64 is different. Then Oracle GoldenGate 12.2 for Oracle on Windows, 64-bit binaries are different. Similarly, if you have DB2 database, the binaries are different along with platform. For MySQL, binaries are different. For Postgres, binaries are different. For Informix database, which we were discussing, the support has been started from 11 years. The binaries for Linux, Solaris, Spark, Windows are different. For Sybase, Teradata, Timestamp is different. If you want to download Oracle GoldenGate for big data, binaries are different. Then for mainframe, binaries are different. So, there are so many options. However, you need to, first of all, look for your database version and the database platform. So, as a database version, our platform is Linux x86-64 and database is Oracle. So, we are going to download this binary. Oracle GoldenGate 12.2.0.1.1 for Oracle on Linux x86-64. So, we'll be downloading this binary. So, this binary is already downloaded and kept inside slash home slash Oracle. So, these virtual boxes will also be shared with you. So, you will find the GoldenGate software and database software. Both are kept inside slash home slash Oracle. So, you'll be receiving the instruction document how to set up virtual machine. You'll be receiving the instruction document as well and you can use that to set it up. So, GoldenGate also supports backward compatibility or forward compatibility. So, with GoldenGate, your source could be 12c, target could be 10g. GoldenGate will work. Your source could be 11g, target could be 12c. GoldenGate will work. Also, you could use GoldenGate version 12c on source and GoldenGate version 11c, 11g on target. It is not mandatory that you should have same version of Oracle GoldenGate. The reason for this is, suppose you want to do Oracle and MySQL replication, Oracle to MySQL replication. Now, there may be a case that the latest version for Oracle may be 12.2 and for MySQL, the latest version is 12.1. They haven't released 12cr2 for MySQL. So, in that scenario, you will have separate versions. So, it is not mandatory or any requirement that you should have same GoldenGate version or you can, in fact, have different databases. You can have different structures, different name between source and target. So, the binaries are kept inside slash home slash oracle. So, when I do ls-larg, I will find that GoldenGate binaries are here. FBO, GGS, Linux, x86, shiphome.zip. These are the Oracle binaries, which are downloaded from Oracle website and they are kept in this location, slash home slash oracle. So, the binaries, if you see, the GoldenGate binaries are not big. For Linux, it is only 454 MB. For other platforms and other databases, the binary size is varying. So, for Linux, the one which we have downloaded, the size of binaries are 454. So, these binaries are downloaded and transferred on your virtual boxes, on ggate1 as well as ggate. So, we can verify whether they are present or not. So, on ggate2, when we do ls-larg, yeah, zip file is there. So, these are the GoldenGate binaries which are there. So, first part of downloading the GoldenGate software is completed. So, in our next session, we'll be discussing about how to install Oracle GoldenGate on virtual machine, how to install your Oracle GoldenGate.