Goldengate Interview Questions

What People Actually Ask in GoldenGate Interviews

GoldenGate interview questions tend to fall into a few predictable buckets. Most people preparing for these interviews spend too much time memorizing definitions and not enough time thinking through edge cases. The truth is that most interviewers want to see how you handle problems, not whether you can recite documentation. I have sat on both sides of those tables, and the difference between a hire and a reject usually comes down to one thing: whether you can talk about what happens when things break. The foundational questions always start with architecture. Expect to explain Extract, Pump, and Delivery processes. That is basic. But the moment you get to change data capture (CDC) mechanics, that is where most candidates stumble. Interviewers will ask how GoldenGate handles transactions across distributed systems, how it maintains ordering, and what happens during network partitioning. The answer involves the trail files, sequence numbers, and checkpoint mechanisms. Be precise about that. Here is a specific scenario I deal with constantly. Someone set up a GoldenGate replication between two Oracle databases across a transatlantic link with high latency. The extraction process was fine, but the delivery process kept throwing ORA-26653 errors because the apply lag exceeded the retention threshold. The fix was not adjusting the parameter file. It was redesigning the topology to add a intermediate pump process and setting up parallel apply with multiple worker threads. During an interview, mentioning this kind of concrete troubleshooting separates people who have actually deployed GoldenGate from people who have only read about it.

Transaction boundary handling is another area that comes up repeatedly. Interviewers will ask about atomicity in replication. GoldenGate captures transactions at the log level, so it reads redo or trail data. The key insight most beginners miss is that GoldenGate does not guarantee zero data loss in every failure scenario unless you explicitly configure exttrail checkpoint and tune the heartbeat parameters. Without that configuration, you can lose transactions during a failover. That is not obvious from reading the quickstart guide. When they ask about conflict detection and resolution, most candidates give the textbook answer about conflict resolution methods like default handling or stored procedure resolution. The deeper answer involves understanding that GoldenGate's built-in conflict detection is limited compared to something like CDC-enabled application-level logic. If you are replicating from multiple source systems into a single target, GoldenGate alone will not save you from update conflicts. You need either a deterministic key strategy or a conflict resolution framework at the application layer. I learned that the hard way when a client had two systems updating the same row within the same transaction window and the replication silently applied the wrong value. Parameter tuning questions are fair game. Expect to discuss GETUPDATEBEFORES, dynamic filtering, and table parallelism. These are not trivia. They directly affect performance. Setting GETUPDATEBEFORES to YES on a high-volume transaction table can double your trail file size. Nobody warns you about that upfront. Interviewers who know what they are asking about will probe your understanding of trade-offs.

Another area where experience matters is GoldenGate Manager process configuration. People often treat the Manager as background noise. It controls port bindings, startup sequences, and process routing. A misconfigured STOPRESETTIME parameter can cause a Manager restart loop during failover scenarios. I have seen this crash a production environment at 2 AM on a Friday. It is worth knowing. When it comes to performance and scaling, the counter-intuitive part is that more cores do not always mean better throughput. GoldenGate's capture process is largely single-threaded per instance. Parallelism helps at the apply stage, but the bottleneck is often the redo log consumption rate, not CPU. Upgrading hardware without addressing the trail file layout and network bandwidth first is a common mistake I see in production environments. The topic of heterogeneous replication also comes up. Moving data from Oracle to SQL Server or PostgreSQL through GoldenGate works, but the data type mapping is painful. Boolean fields, decimal precision, and Unicode handling all require careful parameter configuration. Interviewers who have dealt with this will ask about datatype compatibility issues, and the honest answer is that it is rarely smooth. You will spend more time on data type mapping than on anything else in a heterogeneous setup.

Failure mode questions separate the experienced practitioners. What happens if a trail file fills up? What happens if the target table has a primary key constraint violation? GoldenGate handles some of this through its error handling parameters, but it is easy to misconfigure. The default behavior on a replicated update failure is to terminate the apply process. That means your entire replication stops because one bad row exists. You need to understand ERRORREPORTING and COMMITTRANSACTIONOPTIONS to manage this properly. Monitoring and alerting is another practical area. GoldenGate provides GGSCI commands and integrated reporting, but most production environments rely on custom scripts or third-party tools. Knowing how to set up lag thresholds, process state monitoring, and automated failover alerts shows you understand operational reality, not just theory. Finally, certification and version differences matter less than people think, but they do come up. GoldenGate 12c introduced significant changes to the administration framework and integrated replicate support for Oracle. If you are being interviewed for a role that still runs 11g, they will expect you to know the older command syntax. If it is a greenfield deployment, they will assume you are working with the current version. Either way, knowing the differences between integrated and standalone capture modes is essential.

What GoldenGate Cannot Do Well

No replication tool is perfect, and GoldenGate has well-known limitations. It is expensive, both in licensing and in administrative overhead. The setup complexity for heterogeneous platforms is not trivial. It struggles with certain data types and schema changes that require manual intervention. For small-scale replication needs, open-source alternatives like Debezium or pg_replication may be more appropriate. GoldenGate excels at high-volume, low-latency Oracle-to-Oracle replication with strict consistency guarantees. Beyond that scope, you are paying a premium for features you may not need.