By far, the simplest and most common configuration is the source to target configuration. Here, we are performing real-time or batch change data replication between two sites in a unidirectional fashion. This could be, for example, between a primary and standby site for DR or an OLTP to the data warehouse for BI and OLAP.

One-to-one architecture provides a data replication solution that offers the following key benefits:

Due to its simplicity, this book refers to one-to-one architecture to effectively demonstrate:

Another popular GoldenGate configuration is the one-to-many architecture, also known as Broadcast. This architecture lends itself perfectly to provide two solutions. One data replication feed for reporting and one for backup and disaster recovery.

The one-to-many architecture offers the following key benefits:

The following example helps to illustrate the method.

The one-to-many architecture is very flexible given that it provides two solutions in one; a reporting and a standby database, both of which can have different table structures.

The many-to-one configuration, also known as Consolidation, comes into play for peripheral sites that update a central computer system, representing a hub and spokes on a wheel. This scenario is common in all industries, from retail outlets taking customer orders to high-street bank branches processing customer transactions. Ultimately, the data needs to be available on the central database and cannot become lost or corrupted. GoldenGate's architecture lends itself perfectly to this scenario, as seen in the next example. Here, we have three spoke sites sending data to the central hub site:

One important point to mention here is Conflict Handling. In a hub and spoke configuration, with concurrent updates taking place, data conflicts are very likely to occur. Should the same database table row or field be updated by more than one source on the target, the conflict must be handled by GoldenGate to allow either one of the transactions to succeed or fail all.

You'll be pleased to learn that Oracle GoldenGate 12c now supports Conflict Handling out of the box. This useful feature has been adopted from the legacy Oracle Streams product.

Another hub and spoke solution includes the one-to-many Broadcast configuration. A typical example is a company head office sending data to its branches. Here, conflict handling is less of an issue.

The cascading architecture, also known as N-way replication, offers data replication at n sites originating from a single source. As the data flows from the originating source database, parts or all of it are dropped off at each site in a cascading fashion until the final target is populated. In the following example, we have one source (Site A) and three targets (Site B, Site C, and Site D). Intermediate Site B and Site C have both source and target trails, whereas Site A has only a source and Site D has only a target trail.

The choice of data to replicate is configured by using filters in the GoldenGate parameter files at each target site, making the Cascade architecture one of the most powerful and complex configurations. Users at each site input data that can also be replicated to the next site.

The following diagram is an example of an active-active configuration, where Site A sends changed data to Site B and vice versa. Again, Conflict Handling is an important consideration. A conflict is likely to occur in a bidirectional environment, where the same row or field is updated at both sites concurrently. When the change is replicated, a conflict occurs. This needs to be resolved by GoldenGate based on the business rules. For example, should data from Site B overwrite Site A or should both transactions fail?

The bidirectional (active-active) architecture provides a data replication solution that offers the following key benefits:

Another key element to include in your configuration is Loop Detection. We do not want data changes to go around in an endless loop, where Site A updates Site B, then Site B updates Site A, and so on.

Do not be put off by the bidirectional architecture. When configured correctly, this architecture offers the most appropriate solution for global companies and organizations, allowing users in two centers or on both the sides of the globe to share the same system and data.

The active-active configuration is very different from the active-passive configuration, which we will discuss in the next section.

The following diagram is an example of an active-passive configuration, sometimes called Live Standby, where a production site sends changed data to its backup site. You'll notice the path from the backup to the production site is grayed out, suggesting the data replication path can be re-enabled at short notice.

Oracle GoldenGate 12c now includes integration with Oracle Data Guard Fast Start Failover (FSFO) that provides automated and transparent disaster recovery of Oracle GoldenGate components. With the failover or switchover of the primary database, replication can continue without any manual intervention.

The GoldenGate bidirectional (active-passive) architecture provides a data replication solution that offers the following key benefits. The differences between GoldenGate and Data Guard are explained in greater detail in Chapter 3, Design Considerations:

The active-passive configuration lends itself to being a DR solution, supporting a backup site should processes fail on the production site.

The solution is almost reminiscent of the traditional ETL process, where staging tables are loaded by the Extract process, enabling the transformation and population of target tables. From Oracle 9i onwards, the ETL process was enhanced through its use of external tables and pipelined functions. The two approaches have since been combined, along with an Oracle Warehouse Builder-based control and management interface to deliver the data in near real time using Oracle GoldenGate (OGG) and Oracle Data Integrator (ODI) together.

ETL has now become E-LT, where OGG performs the data extract and loading from the source system, leaving ODI to do the complex transformation and publication of the data on the target system. The OGG-ODI coupled architecture is illustrated in the following diagram:

The ODI's and OGG's combined configuration allows target databases, such as data warehouses, to be trickle fed with real-time data, thus alleviating the need for lengthy batch windows for ETL processing.

In a similar fashion to the E-LT model for real-time data integration, Oracle GoldenGate interfaces with Java to support Big Data. The Oracle GoldenGate Adapter for Java enables integration with Oracle NoSQL, Apache Hadoop, Apache HDFS, Apache HBase, Apache Storm, Apache Flume, and Apache Kafka, to name a few. Hadoop has emerged as the primary system to organize Big Data for relational databases. Coupled with Oracle Data Integrator and GoldenGate, it provides real-time data streaming into Big Data targets.