YPDNGG: You Probably Don’t Need Golden Gate

Before launching into this, I must give due deference to Mogens Nørgaard’s landmark article, You Probably Don’t Need RAC (YPDNR), available here, but originally published Q3 2003 in IOUG Select Journal.  Mogens showed that you can be a friend of Oracle without always agreeing with everything they do.

Suddenly, everyone is asking about Golden Gate.  In July 2009, Oracle bought Golden Gate Software, just one of several companies that have developed log-based replication mechanisms for Oracle and other databases.  This was one of many major acquisitions by Oracle in 2009, including Sun and Relsys. But unlike most of Oracle’s acquisitions, Golden Gate provides very little new functionality not already available in Oracle Streams. Nevertheless, at OpenWorld 2009, Oracle made a shocking announcement.  They declared that Golden Gate would be the primary replication channel for Oracle, and that development would cease on Streams and related components.

Usually, Oracle watches these little third-party products for good ideas, then implements them independently (and better) on their own in the Oracle kernel, then watches as the little third-party companies fizzle out.  A case in point is direct memory access performance sampling.  Precise Software and several other companies in the early 2000s developed  low-impact performance sampling and visualization products for Oracle based on sampling the SGA periodically from an external program.  In version 10g, Oracle answered them with Active Session History (ASH), which did the same thing but better.  Although ASH required customers to purchase the Diagnostic Pack, it still more or less spelled the downfall of competing products.

But in the case of Golden Gate, Oracle already has a log-based replication technology (Streams) built into the kernel, available for a very reasonable price (free with Enterprise Edition).  The only major components that Streams lacks compared to Golden Gate is the ability to replicate across database platforms (Oracle to MSSQL, MySQL, etc. and vice versa).  Even that capability was clearly around the corner: In 11g, Logical Standby (Data Guard), a technology that uses essentially the same stack of components as Streams, gained cross-platform capabilities.

By 11g, Streams has become a mature and stable product, and is far more scalable and configurable than Golden Gate in many ways.  Streams can mine logs on the source or the target, or even a third system.  Depending on the load profile, you can use a wide variety of configuration choices, including parallelism at almost any point.  Streams also allows customers to choose to enforce transaction order or not.

In contrast, Golden Gate’s parallelism is restricted to the apply side, and in parallel mode, does not have the option of guaranteeing transaction order (it is non-ACID). Golden Gate’s parallel apply splits work up by schema, relying on the assumption that interdependent data at the business process level is confined to a single schema at a time.  In other words, if all the tables reside in one schema, then parallel apply doesn’t work, and if they reside in many schemas, the changes in one schema may be applied out of order vis à vis the changes to the other schemas.

Streams is only one of Oracle’s preexisting features that can compete successfully in specific use cases with Golden Gate.  Even more ancient and time-tested solutions such as advanced replication and remote materialized views remain supported and highly effective, depending on the requirement.

If you look at many of the use cases where our customers have deployed Golden Gate, I find that the simplest and most scalable engineering solution would have been remote fast-refresh materialized views.  Our customers often replicate core look-up data, like exchange rates, inventory levels, and other slowly-changing data between Oracle databases within an enterprise.  For this, Golden Gate is completely unjustified, due to cost and complexity compared to remote materialized views.  If it were a question of heterogeneous (inter database product) replication, I completely understand.  But in the majority of situations where we see Golden Gate in use, it is Oracle to Oracle. Given that, I wonder how it could come to pass that responsible people would recommend and implement a solution for such a requirement involving Golden Gate.  Why would Oracle essentially abandon ten years of development and stabilization on a platform like Streams for a less mature, rudimentary product like Golden Gate? Oracle can’t possibly be asking customers to pay additional license fees for a worse version of a product they already own.

So let’s review…

Streams: Mature, complex, requires engineering, highly configurable, scalable, Oracle-only, free.

Golden Gate: Simple, east to deploy, few configuration options, less scalable, expensive, heterogeneous (inter-RDBMS), might break your data.

For me, the corporate direction with regard to Golden Gate is perplexing and smacks of sales-driven (as opposed to requirements and cost-driven) engineering.  I can only imagine what it must be like for the team at Oracle that built Log Miner and AQ into an impressive suite of options including Streams.

Related posts:

1. New whitepaper: High availability without breaking the bank
2. Oracle Support and Certification on AWS
3. A Cloud over San Francisco for OpenWorld 2010