Configuring Oracle GoldenGate DDL Replication Privileges for Zero‑Downtime Migration

Goal: Configure Oracle GoldenGate bidirectional replication so that DDL statements (CREATE, ALTER, DROP) are captured on the source and applied on the target throughout a zero‑downtime migration of a small OLTP application.

Uncertainty: The GGSCI user must hold the EXECUTE privilege on DBMS_GOLDENGATE_AUTH and the ALTER ANY TABLE system privilege to replicate DDL. Granting ALTER ANY TABLE expands the user’s ability to modify any schema object, which may conflict with least‑privilege policies and audit requirements. Alternatively, withholding the privilege requires manual application of DDL after cutover, introducing a window where source and target schemas can diverge.

Specific questions:

• What is the minimal privilege set that allows GoldenGate to replicate DDL without violating least‑privilege guidelines?
• How does granting ALTER ANY TABLE to the GGSCI user impact audit compliance and security policies in typical enterprise environments?
• What are the operational risks and consistency implications of manually applying DDL changes after migration instead of replicating them in real time?