Info2soft use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
The ORA-26947 error appears when a database isn’t configured to support Oracle GoldenGate replication. It typically appears when starting or registering an Extract or Replicat process. This guide walks through the root causes and how to fix them.
This error occurs when GoldenGate replication is not enabled at the database level, which blocks replication processes from starting or continuing. Common causes include:
ENABLE_GOLDENGATE_REPLICATION is set to FALSE. This initialization parameter, introduced in Oracle 11.2.0.4, defaults to FALSE. Until it’s set to TRUE, the database blocks GoldenGate from registering, extracting, or applying data.
To resolve the ORA-26947 error, change a database initialization parameter that controls GoldenGate access. The steps below cover connecting to the database, enabling the parameter, and confirming the fix.
Changing this parameter requires SYSDBA privileges. Open SQL*Plus and connect as a user with SYSDBA access:
sqlplus / as sysdbaBefore making any changes, check the current setting:
SHOW PARAMETER ENABLE_GOLDENGATE_REPLICATION;If GoldenGate replication is not enabled, the value will show as FALSE.
ENABLE_GOLDENGATE_REPLICATION is a dynamic parameter, so you can enable it without restarting the database:
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;SCOPE=BOTH applies the change to the running instance immediately and writes it to the server parameter file (spfile), so it persists after a restart.
SID='*' to this command so the change applies across all instances. This is covered in more detail in the RAC section below.Run the same check again to confirm the change took effect:
SHOW PARAMETER ENABLE_GOLDENGATE_REPLICATION;The value should now show as TRUE.
With the parameter enabled, return to GGSCI and start the Extract or Replicat process that originally failed:
GGSCI> START EXTRACT Check its status with INFO EXTRACT <extract_name> and confirm it reaches a RUNNING state without further errors.
In an Oracle Real Application Clusters (RAC) environment, all instances need to use the same parameter setting. If it’s only changed on one node, GoldenGate processes connecting to other nodes will keep raising the ORA-26947 error.
To apply the change across the entire cluster, use the SID='*' clause. This updates every instance in memory and writes the setting to the shared server parameter file (spfile). Run this from any active RAC node:
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH SID='*';After running this, confirm the setting on every instance with:
SELECT inst_id, name, value
FROM gv$parameter
WHERE name = 'enable_goldengate_replication';
Every row should show TRUE in the VALUE column. If a node still shows FALSE, it likely wasn’t running when the command executed, or it was restarted afterward without picking up the new spfile value. Check that the node is online and apply the command directly on it if needed.
In a multitenant Oracle environment, container-level rules affect where you can set replication parameters. Applying the setting at the wrong level in a Container Database (CDB) or Pluggable Database (PDB) will keep GoldenGate processes from starting.
ENABLE_GOLDENGATE_REPLICATION is set from the root container (CDB$ROOT). Running the command from within a PDB will fail.
ALTER SESSION SET CONTAINER = CDB$ROOT;Once connected to the root, run the same command used earlier:
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;ENABLE_GOLDENGATE_REPLICATION is not modifiable at the individual PDB level. Attempting to set it while connected to a PDB returns:
ORA-65040: operation not allowed from within a pluggable databaseThis is expected behavior. The parameter is a CDB-wide setting, so it always needs to be configured from CDB$ROOT, regardless of which PDBs are being replicated.
Enabling the parameter in the root doesn’t help if the target PDB itself is closed or mounted. GoldenGate’s Extract or Replicat processes need the PDB fully open to read from or write to it.
Check the status of each PDB:
SHOW PDBS;Confirm the target PDB shows READ WRITE under OPEN MODE. If it doesn’t, open it:
ALTER PLUGGABLE DATABASE OPEN; Sometimes the ORA-26947 error persists even after the parameter has been updated. When this happens, the next step is to check for environment mismatches or missing logging dependencies.
On a server running multiple database instances, it’s easy to update the parameter on the wrong one. This usually comes down to running the SQL commands under the wrong ORACLE_SID environment variable.
Check the instance name alongside the parameter value to confirm you’re on the right database:
SELECT instance_name, status FROM v$instance;
SHOW PARAMETER ENABLE_GOLDENGATE_REPLICATION;
If the instance name doesn’t match the database GoldenGate is configured to capture from, switch the ORACLE_SID environment variable and reapply the fix on the correct instance.
GoldenGate’s Extract and Replicat processes connect using credential stores or TNS aliases. If the alias in the DBLOGIN command points to the wrong service, such as a read-only Active Data Guard standby or a different container, the process ends up connecting to a database where the parameter was never enabled.
Check the tnsnames.ora file or the GoldenGate credential store configuration:
GGSCI> DBLOGIN USERIDALIAS ggadmin_prodConfirm the alias ggadmin_prod routes to the read-write primary database, not a standby or secondary instance.
GoldenGate reads transaction details from the database’s redo logs. In NOARCHIVELOG mode, those logs get overwritten quickly and aren’t preserved on disk, which blocks replication from reading historical change data.
Check the database’s logging mode:
ARCHIVE LOG LIST;If the output shows “Database log mode: No Archive Mode,” switching to ARCHIVELOG mode needs a brief maintenance window, since the database has to be restarted in mount state:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
By default, Oracle redo logs capture only the minimum needed to recover from a crash. GoldenGate needs more, like primary key and changed-column values, to reconstruct full SQL operations for replication. That’s what supplemental logging provides.
Check and enable minimal supplemental logging at the database level:
SELECT supplemental_log_data_min FROM v$database;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Schema-level or table-level supplemental logging is configured separately, from within GGSCI, before starting replication:
GGSCI> DBLOGIN USERID ggsadmin, PASSWORD password
GGSCI> ADD SCHEMATRANDATA
Some operations, like direct-path loads or bulk inserts, can use the NOLOGGING clause to skip writing to the redo logs for better performance. Since GoldenGate only replicates what’s written to the redo logs, NOLOGGING transactions get missed entirely, which can cause the Extract process to fail or leave data out of sync.
SELECT force_logging FROM v$database;If the result is NO, enable FORCE LOGGING to override local NOLOGGING directives across all transactions:
ALTER DATABASE FORCE LOGGING;The troubleshooting steps above fix ORA-26947, but they don’t address a broader question: how do you keep Oracle databases in sync without depending on GoldenGate licensing or manually tracking parameters like ENABLE_GOLDENGATE_REPLICATION across every RAC node and PDB.
i2Stream is built for this. It replicates Oracle databases in real time through log parsing, without needing an agent installed on the source database. Since it reads directly from the archive and redo logs rather than relying on database-level replication services, there’s no equivalent of ORA-26947 to troubleshoot in the first place.
For teams already dealing with the CDB/PDB and RAC-specific configuration steps covered earlier, i2Stream simplifies the setup:
If your current setup involves both real-time replication and disaster recovery, i2Availability extends this further with automated failover for the standby database, cutting down manual intervention when the primary instance goes down.
Q1: What does ORA-26947 mean?
ORA-26947 means the database has not been configured to allow Oracle GoldenGate replication. It usually appears because the ENABLE_GOLDENGATE_REPLICATION parameter is set to FALSE.
Q2: How do I check whether GoldenGate replication is enabled?
Run SHOW PARAMETER ENABLE_GOLDENGATE_REPLICATION in SQL*Plus. A value of TRUE means it’s enabled; FALSE means it isn’t.
Q3: Do I need to restart Oracle after enabling GoldenGate replication?
No. ENABLE_GOLDENGATE_REPLICATION is a dynamic parameter, so ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH takes effect immediately without a database restart.
Q4: Does ORA-26947 affect Extract or Replicat?
Yes. Both Extract and Replicat processes depend on this parameter being enabled, so either process can fail to start or register while it’s set to FALSE.
Q5: Can ORA-26947 occur in Oracle RAC?
Yes. If the parameter is only set on one RAC instance, other nodes still raise ORA-26947. Use SID='*' when setting the parameter so it applies across all instances.
Q6: Can I set ENABLE_GOLDENGATE_REPLICATION inside a PDB?
No. The parameter can only be set from the root container (CDB$ROOT). Attempting it from within a PDB returns ORA-65040.
Q7: Do I need a GoldenGate license to enable this parameter?
Yes. Oracle requires a valid Oracle GoldenGate license to use the features unlocked by setting ENABLE_GOLDENGATE_REPLICATION to TRUE.
ORA-26947 comes down to one thing: the database hasn’t been told to allow GoldenGate replication. In most cases, setting ENABLE_GOLDENGATE_REPLICATION to TRUE from the root container clears the error right away.
If it persists, the cause is usually somewhere else, like the wrong instance, a misconfigured connection alias, or missing supplemental logging and ARCHIVELOG mode. Working through these one at a time will narrow it down.
For teams that want real-time Oracle replication without managing GoldenGate parameters across RAC nodes and PDBs, Info2soft offers i2Stream as a log-based, agentless alternative.
· Enterprise & Mid-market Customers Worldwide
· Support team available to assist you throughout your trial
· Start a 60-day free trial or view demo to see how Info2Soft protects enterprise data.
