Configure Goldengate Unidirectional Step by step And Monitoring command and Interview Question

Configure Goldengate Unidirectional Step by step

Summary

1) Create New file system for Golden Gate Home

2) Install Oracle GoldenGate software on source and target Machine and create subdirectory from GGSCI .
3)Set up a GoldenGate database user at source database level.
4)Enable supplemental logging at source database level.
5) Enabling Oracle GoldenGate in source the Database
   ENABLE_GOLDENGATE_REPLICATION=true
6) Configure and start change capture to GoldenGate trail files (Extract processes: primary and data pump).
7) Perform initial load to synchronize databases by database-specific or Oracle GoldenGate methods.
8) Configure and start change delivery (Replicat process).

               

Source

1) Set up a GoldenGate database user at source   

          Wallet and master key

                Copy the cwallet.sso created on the target to $OGG_HOME/dirwlt

Credential Store

               

GGSCI (ip-10-190-170-4.eu-west-1.compute.internal) 3> add credentialstore Credential store created in ./dircrd/. GGSCI (ip-10-190-170-4.eu-west-1.compute.internal) 6> alter credentialstore add user SD_OGG@APPPROD,  alias sd_ogg Password: Credential store in ./dircrd/ altered.

Supplemental Logging

DBLOGIN USERIDALIAS sd_ogg ADD SCHEMATRANDATA TEST_DBA [ALLOWNONVALIDATEDKEYS] 2017-04-12 11:10:36  INFO    OGG-01788  SCHEMATRANDATA has been added on schema test_dba. 2017-04-12 11:10:36  INFO    OGG-01976  SCHEMATRANDATA for scheduling columns has been added on schema test_dba.

GLOBALS file

GGSCHEMA SD_OGG ENABLE_HEARTBEAT_TABLE USE_TRAILDEFS

            Manager process

PORT 7809 PURGEOLDEXTRACTS ./dirdat/cp*, USECHECKPOINTS, MINKEEPHOURS 12 AUTORESTART EXTRACT APP_CAP,  RETRIES 6, WAITMINUTES 10, RESETMINUTES 60 AUTORESTART EXTRACT APP_PUMP, RETRIES 6, WAITMINUTES 10, RESETMINUTES 60 --ALLOWNONVALIDATEDKEYS

Heartbeat Table

DBLOGIN USERIDALIAS sd_ogg ADD HEARTBEATTABLE, frequency 120, retention_time 10, purge_frequency 2

Extract (Capture process)

                Register the extract process with the database

ADD EXTRACT TEST_CAP, INTEGRATED TRANLOG, BEGIN NOW ADD EXTTRAIL ./dirdat/cc , EXTRACT TEST_CAP

                TEST_CAP Parameter file

EXTRACT TEST_CAP USERIDALIAS sd_ogg ENCRYPTTRAIL AES256 EXTTRAIL ./dirdat/cc TABLEEXCLUDE TEST_DBA.TC_CREDIT_LIMIT_SNAPSHOT TABLEEXCLUDE TEST_DBA.ACCOUNT_STATUS_PARAMS TABLEEXCLUDE TEST_DBA.IDT_ML5910G01 TABLEEXCLUDE TEST_DBA.SL_PROBLEM_PHONES TABLEEXCLUDE TEST_DBA.IDT_ML5910G03 TABLE TEST_DBA.*

Register the extract process with the database

DBLOGIN USERIDALIAS sd_ogg register extract TEST_cap database 2017-04-12 11:14:10  INFO    OGG-02003  Extract TEST_CAP successfully registered   with database at SCN 25289823.

            For Initial Load
             capture SCN from Source Database
            1) select Current_SCN from V$database   -- on Source Database
             2) Run EXPDP to a specific SCN.

                  expdp parfile=testdb_table.part
                     
                userid="/ as sysdba"
                DIRECTORY=dumptest
               PARALLEL=4
               COMPRESSION=ALL
                flashback_scn=XXXXXXX
               SCHEMAS=TEST_USER
                METRICS=Y
                DUMPFILE=exp_TEST_USER_23Apr_%U.dmp
               logfile=explog_TEST_USER_23Apr.log

              

                Point EXTRACT to that SCN and start it

ALTER TEST_CAP, SCN XXXXX INFO TEST_APPP DETAIL START TEST_CAP

Extract (Pump process)

                Commands to create EXTRACT process:

ADD EXTRACT TEST_PUMP, EXTTRAILSOURCE ./dirdat/oc

                TEST_PUMP Parameter file:

EXTRACT TEST_PUMP PASSTHRU RMTHOST ip-10-190-170-4.eu-west-1.compute.internal, MGRPORT 7809 RMTTRAIL ./dirdat/cp TABLE TEST_DBA.*;

                Start PUMP 

START TEST_PUMP

Target

            Wallet and master key

GGSCI (ip-10-190-170-4.eu-west-1.compute.internal) 2> create wallet Created wallet at location 'dirwlt'. Opened wallet at location 'dirwlt'. GGSCI (ip-10-190-170-4.eu-west-1.compute.internal) 4> add masterkey Master key ' OGG_DEFAULT_MASTERKEY' added to wallet at location 'dirwlt'.

            Credential Store

               

GGSCI (ip-10-190-170-4.eu-west-1.compute.internal) 3> add credentialstore Credential store created in ./dircrd/. alter credentialstore add user SD_OGG@ords1,  alias sd_ogg domain ords1 Password: Credential store in ./dircrd/ altered. alter credentialstore add user SD_OGG@ords2,  alias sd_ogg domain ords2 Password: Credential store in ./dircrd/ altered.

            GLOBALS file

GGSCHEMA SD_OGG ENABLE_HEARTBEAT_TABLE USE_TRAILDEFS --ALLOWNONVALIDATEDKEYS

Manager process

PORT 7809 DYNAMICPORTLIST 7810-7829 PURGEOLDEXTRACTS ./dirdat/cp*, USECHECKPOINTS, MINKEEPHOURS 12 AUTORESTART REPLICAT APP_DEL, RETRIES 6, WAITMINUTES 10, RESETMINUTES 60

Checkpoint Table

DBLOGIN USERIDALIAS sd_ogg domain rds1 add checkpointtable sd_ogg.checkpointtable

Heartbeat Table

DBLOGIN USERIDALIAS sd_ogg domain rds1 ADD HEARTBEATTABLE, frequency 120, retention_time 10, purge_frequency 2

Replicat

                Commands:

ADD REPLICAT TEST_DEL, EXTTRAIL ./dirdat/cp, CHECKPOINTTABLE sd_ogg.checkpointtable

APP_DELIVERY Parameter file

REPLICAT TEST_DEL --HANDLECOLLISIONS USERIDALIAS sd_ogg MAP APP_DBA.*, TARGET APP01PRD_APP_DBA.*; --MAP pdb2.soe2.logon, target pdb2_soe2.logon keycols(logon_id); BATCHSQL BATCHESPERQUEUE 100, OPSPERBATCH 2000

                Start REPLICAT process

START TEST_DEL

Question : How replication work in golden gate

Oracle GoldenGate replicates data in real-time by capturing database transaction logs (such as redo logs or binary logs) rather than using database-specific triggers. It uses a decoupled, log-based architecture that works across diverse environments, from on-premises to multi-cloud ecosystems. 

The Core Replication Process

The standard GoldenGate replication flow involves distinct components working in sequence:

1. Capture (Extract): The Extract process continuously monitors the source database’s transaction or redo logs. It captures all committed Data Manipulation Language (DML) operations (Insert, Update, Delete) and Data Definition Language (DDL) changes in real-time. 
2. Route (Data Pump): The Data Pump process reads the captured data from the local trail files and transmits them across the network to the target system. It acts as a staging and filtering mechanism, keeping the primary Extract process isolated from network latency
3. Apply (Replicat): The Replicat process on the target server reads the remote trail files, reconstructs the captured SQL or DDL operations, and applies them to the target database

Key Technologies that Make it Work

• Continuous Trail Files: The data does not transfer directly from source to target tables. It is stored in platform-independent, compressed files called "trails" at intermediate steps, ensuring fault tolerance and asynchronous delivery. 
• Checkpoints: GoldenGate maintains checkpoint tables to track exactly which transactions have been processed. If a server reboots or network connectivity drops, the system resumes seamlessly without losing or duplicating data. 
• Heterogeneous Support: Because the data is translated into an intermediate GoldenGate Canonical format within the trail files, the source and target databases do not need to be identical (e.g., it can replicate data from an Oracle Database to a Snowflake data warehouse). 
• Parallel Replicat: To handle high-throughput environments, modern GoldenGate uses Parallel Replicat technology. It breaks massive streams of transactions into multiple threads that are applied simultaneously without violating referential integrity (e.g., maintaining the order of parent-child inserts). 

or

Oracle GoldenGate facilitates real-time data replication by capturing committed transactions from a source database's transaction logs and applying them to a target database. It functions as a lightweight, out-of-band asynchronous process ensuring high-speed, heterogeneous data synchronization with minimal overhead. [1, 2, 3, 4, 5]

The Replication Pipeline & Process Flow

The replication flow is achieved through a sequence of specific processes that move the data from the source to the target: 

1. The Source Environment

• Source Database: Where the actual transactions (Insert, Update, Delete) occur. 
• Manager: The supervisor process on both source and target nodes that starts, stops, and monitors all other GoldenGate processes, as well as manages trail file cleanup. 
• Extract: The capture process. In modern databases, this uses "Integrated Capture" to directly read the database's redo/archive logs (or transaction logs), filter the data, and convert it into GoldenGate's internal format (Logical Change Records - LCRs). 
• Trail Files / Local Trail: The Extract writes the captured LCRs into temporary, platform-independent disk files on the source server. 
• Data Pump (Optional but Recommended): Reads the local trail files and securely sends them across the network (via TCP/IP) to the target server's trail files. 

2. The Network

• Distribution Service / Collector: In Classic Architecture, the Collector reconstructs the trail files on the target server. In Microservices Architecture, the Distribution Server handles the transmission, and the Receiver Server manages the secure ingestion of incoming trail files. 

3. The Target Environment

• Remote Trail: The replicated data is staged here on the target machine.
• Replicat: The delivery process. It reads the remote trail files and executes lightweight or dynamic SQL to reconstruct and apply the DML and DDL transactions to the target database in their original committed order.
• Target Database: Where the data ultimately lands. 

---

Step-by-Step Execution of a Transaction

If a user executes a simple UPDATE on the source database, the internal replication steps are as follows:

1. Transaction Capture: The transaction is committed in the source database. The Extract process reads this specific commit from the database transaction/redo log.
2. Translation: The Extract filters out irrelevant data (based on your configuration) and translates the native log data into standard GoldenGate LCRs.
3. Write to Trail: These LCRs are sequentially written to a local Extract Trail (a file on the local OS).
4. Network Transfer: The Data Pump (or Distribution Service) picks up the data blocks from the local trail and pushes them across the network to the target machine.
5. Write to Remote Trail: The Receiver Server on the target system receives the data and writes it to the Target/Remote Trail file.
6. Apply to Target: The Replicat process on the target reads the Remote Trail, creates dynamic SQL statements corresponding to the source UPDATE, and executes them on the target database.

Question :How configure and replicate schema in golden gate

Oracle GoldenGate Schema Replication captures transactional changes from a specific source schema and applies them to a target database. It uses an Extract process to read the database transaction logs, a Data Pump (optional but recommended) to transfer the data, and a Replicat process to apply it. 

---

How Replication Works (Process Flow)

1. Capture (Extract): The Extract process continuously mines the database redo/archived logs to capture Data Manipulation Language (DML) and Data Definition Language (DDL) changes for the defined schema. 
2. Staging & Routing (Data Pump): The Extract writes changes to a local trail file. The Data Pump (running on the source) reads these trail files and securely sends them across the network to a remote trail on the target server. 
3. Delivery (Replicat): The Replicat process on the target reads the remote trail files and applies the SQL operations directly to the target database. Using Integrated Replicat, GoldenGate can apply these transactions in parallel using multiple server processes for maximum throughput. 

---

Detail Steps to Configure Schema Replication

The following steps outline how to configure a unidirectional schema replication. 

Phase 1: Source Database Preparation

1. Enable Archivelog & Force Logging: Ensure your source database is in ARCHIVELOG mode.
   sql

   ALTER DATABASE ARCHIVELOG;
   ALTER DATABASE FORCE LOGGING;
   

   Enable Supplemental Logging: Supplemental logging provides the necessary before-images for updates. Run this for your entire schema.
2. sql

   DBLOGIN USERIDALIAS ogg_admin
   ADD SCHEMATRANDATA <schema_name>
   

   
   

Phase 2: Initial Load (Instantiation)

To sync the target database before starting real-time replication, perform an initial data load. []

1. Export Source: Use Oracle Data Pump (expdp) or GoldenGate Initial Load Extract to export the schema metadata and data.
2. Import Target: Import the metadata and data into the target schema. Ensure you disable constraints and triggers on the target table during import to avoid conflicts. 

Phase 3: Configure Source GoldenGate Processes

1. Register the Integrated Extract:
   bash

   GGSCI> REGISTER EXTRACT ext_sch DATABASE
   

   Add and Edit Extract Parameters:
2. bash

   GGSCI> ADD EXTRACT ext_sch TRANLOG BEGIN NOW
   GGSCI> ADD EXTTRAIL /u01/app/ogg/dirdat/tr EXTRACT ext_sch
   GGSCI> EDIT PARAMS ext_sch
   

   In the Extract parameter file, specify the schema to capture:
   text

   EXTRACT ext_sch
   USERIDALIAS ogg_admin
   EXTTRAIL /u01/app/ogg/dirdat/tr
   TABLE <schema_name>.*;
   

   Configure Data Pump:
3. bash

   GGSCI> ADD EXTRACT dp_sch EXTTRAILSOURCE /u01/app/ogg/dirdat/tr
   GGSCI> ADD RMTTRAIL /u01/app/ogg/dirdat/rt EXTRACT dp_sch
   GGSCI> EDIT PARAMS dp_sch
   

   In the Data Pump parameter file, map to the target:
   text

   EXTRACT dp_sch
   USERIDALIAS ogg_admin
   RMTHOST <target_ip>, MGRPORT 7809
   RMTTRAIL /u01/app/ogg/dirdat/rt
   TABLE <schema_name>.*;
   

   
   

Phase 4: Configure Target GoldenGate Processes

1. Create Checkpoint Table: Required for tracking applied transactions.
   bash

   GGSCI> ADD CHECKPOINTTABLE ogg_admin.gg_checkpoint
   

   Add and Edit Replicat Parameters:
2. bash

   GGSCI> ADD REPLICAT rep_sch INTEGRATED EXTTRAIL /u01/app/ogg/dirdat/rt
   GGSCI> EDIT PARAMS rep_sch
   

   In the Replicat parameter file, handle schema mapping:
   text

   REPLICAT rep_sch
   USERIDALIAS ogg_admin
   ASSUMETARGETDEFS
   MAP <source_schema>.*, TARGET <target_schema>.*;
   

   
   

Phase 5: Start Replication

1. Start the Processes (Source first, then Target):
   bash

   # On Source
   GGSCI> START EXTRACT ext_sch
   GGSCI> START EXTRACT dp_sch
   
   # On Target
   GGSCI> START REPLICAT rep_sch
   

   Verify: Use INFO EXTRACT ext_sch and INFO REPLICAT rep_sch to monitor lag and verify that the status displays as RUNNING. You can also use Oracle GoldenGate Management Pack web interfaces to visually monitor the health

Question : How to configure in golden gate if number of table column in source database is 4 and target database number of column are 6

To replicate a table from a 4-column source to a 6-column target in Oracle GoldenGate, you must explicitly map the matching source columns and instruct GoldenGate to ignore the two extra target columns using the COLMAP and @COLSTAT parameters. 

Step-by-Step Configuration

1. Verify Target Constraints: Ensure the two extra columns on the target table either allow NULL values or have a defined DEFAULT value.
2. Update the Replicat Parameter File: Open your GoldenGate Replicat parameter file and modify your MAP statement to map the source table to the target. Use COLMAP to link matching columns and mark the extra target columns as missing/null. [

MAP source_schema.source_table, TARGET target_schema.target_table, 

COLMAP (USEDEFAULTS, target_col5 = @COLSTAT(MISSING), target_col6 = @COLSTAT(MISSING));

Note: USEDEFAULTS automatically maps source columns to target columns with identical names. 

3. Restart the Replicat: Stop and restart the Replicat process for the changes to take effect. 

Alternative: Using Source Definitions (DEFGEN)

If your column names are completely different between the source and target, you will need to generate a source definitions file using the DEFGEN utility and reference it in your Replicat parameter file: 

text

MAP source_schema.source_table, TARGET target_schema.target_table, 
SOURCEDEFS dirdef/source_tables.def;

or

To replicate data to a target table with more columns than the source, use the Replicat process with the COLMAP and @COLSTAT(MISSING) functions. GoldenGate identifies matching columns by name; for the extra columns on the target, you must explicitly instruct GoldenGate to flag them as missing so the database can apply defaults. 

Step-by-Step Configuration

1. Edit the Replicat Parameter File
   Open your target Replicat parameter file using GGSCI and use the MAP statement to identify the source and target tables.Example parameter format:
   text

   MAP source_schema.source_table, TARGET target_schema.target_table, &
   COLMAP (USEDEFAULTS, extra_col1 = @COLSTAT(MISSING), extra_col2 = @COLSTAT(MISSING));
   

   
   
2. Understand the Clauses
   • USEDEFAULTS: Automatically maps any source and target columns that share identical names. GoldenGate translates the data types automatically based on your trail.
   • extra_col1 = @COLSTAT(MISSING): Explicitly tells GoldenGate to treat the extra target columns as missing data during inserts. The target database will then automatically populate these columns using its predefined default values (e.g., DEFAULT 'Pending', NULL, or IDENTITY values).

Additional Best Practices

• Handling Different Column Names: If the 4 source columns and the target columns don't share identical names, list the explicit mappings inside the COLMAP clause before USEDEFAULTS.
  text

  COLMAP (target_col1 = source_col1, target_col2 = source_col2, USEDEFAULTS)
  

  Supplemental Logging: Always ensure that all key/unique columns used to track updates on the source are covered by ADD TRANDATA.
• Replicat Documentation: Refer to the official Oracle GoldenGate MAP Documentation for full syntax rules regarding the MAP and COLMAP commands

Question What is supplement login in Oracle

Oracle Supplemental Logging is an administrative feature that instructs the database to log extra block change information into the redo logs. By default, Oracle only records the bare minimum data needed to perform crash and media recovery (typically only the modified columns). Supplemental logging writes additional columns—such as primary keys or unchanged column "before-images"—into the redo log stream so that downstream tools can uniquely identify and reconstruct rows for data manipulation language (DML) changes. 

This mechanism is crucial for log-based utilities and Change Data Capture (CDC) technologies. Downstream platforms like Oracle GoldenGate, Oracle LogMiner, Data Guard SQL Apply, and third-party tools like Qlik Replicate or Fivetran rely on it to ensure updates and deletes replicate accurately across distributed data structures. 

---

Core Types of Supplemental Logging

Oracle classifies supplemental logging into two operational layers: database-level and table-level. 

1. Database-Level Supplemental Logging

This configures global constraints across the entire database instance. It acts as a mandatory foundation for most replication workloads. 

• Minimal Supplemental Logging: The base requirement for any log-mining tool. It logs the information necessary for a log-miner to identify row pieces, chained rows, and index-organized tables. 
• Identification Key Logging: Captures specific row identifiers database-wide when an UPDATE occurs. Options include:
  • PRIMARY KEY: Logs before-images of primary keys.
  • UNIQUE: Logs before-images of unique keys when a unique key column changes.
  • FOREIGN KEY: Logs foreign key columns when altered.
  • ALL: Captures the before-images of every single valid column in the row. 

2. Table-Level Supplemental Logging

This fine-grained approach instructs Oracle to apply logging requirements exclusively to specific tables, minimizing database performance penalties. 

• Named Log Groups: Users explicitly define custom column groups to log whenever any column in that group changes.
  • Unconditional (ALWAYS): Logs the historical before-image values of specified columns regardless of which column was modified during an UPDATE.
  • Conditional: Logs before-images of specified columns only if at least one column within that log group is explicitly updated. 

---

Key Commands & Implementations

To configure or analyze supplemental logging settings, run these standard SQL commands within SQL*Plus or an admin IDE: 

Verification

To check the current database-wide supplemental logging status, query the V$DATABASE view: 

sql

SELECT supplemental_log_data_min, force_logging FROM v$database;

To verify enabled key configurations globally, consult the DBA_SUPPLEMENTAL_LOGGING Metadata View. 

Activating Minimal Database Logging

Activate minimal logging globally with the following alter statement: 

sql

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Activating Database-Level Key Logging

sql

-- Enable Primary Key Logging globally
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

-- Enable All-Column Logging globally
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Activating Table-Level Logging

sql

-- Table-Level Primary Key configuration
ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

-- Table-Level All-Column configuration
ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Disabling Logging

To clean up or disable logging options, swap ADD for DROP: 

sql

ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

Trade-offs and Considerations

• Redo Log Volume: Enabling supplemental logging increases the size of the active and archived redo logs. Broad configurations like ALL COLUMNS generate a high volume of log data. 
• System Overhead: Writing additional column values to the redo log stream burns extra CPU cycles and demands faster disk I/O performance. 
• Log Switch Best Practice: After executing any administrative ALTER DATABASE ADD SUPPLEMENTAL LOG DATA command, manually execute an archive log switch (ALTER SYSTEM SWITCH LOGFILE;) at least twice to ensure subsequent transactional history cleanly encapsulates the updated metadata framework

               
Question :How to add new two tables in golden gate

To add two new tables to an existing Oracle GoldenGate configuration, you must enable supplemental logging on the source database, update your parameter files (Extract, Data Pump, and Replicat), and then safely restart the processes to resume synchronization.

Here is the step-by-step procedure:

1. Source: Enable Supplemental Logging

To ensure Oracle captures unique row identifiers for the new tables, you must enable supplemental logging

• Log in to the GoldenGate Command Interface (GGSCI) and connect to the database. [

bash

GGSCI> DBLOGIN USERIDALIAS <source_credential_alias>

• Enable supplemental logging for the two new tables. 

bash

GGSCI> ADD TRANDATA <schema.new_table_1>
GGSCI> ADD TRANDATA <schema.new_table_2>

2. Source: Update Extract & Data Pump Parameter Files

Stop the active replication processes, add the new tables, and restart them.

• Stop the processes cleanly: 

bash

GGSCI> STOP EXTRACT <extract_group_name>
GGSCI> STOP EXTRACT <data_pump_name>

• Edit the Extract parameter file using your text editor (e.g., vi or EDIT PARAMS) and append the new tables: 

text

TABLE <schema.new_table_1>;
TABLE <schema.new_table_2>;

• Make the identical TABLE additions to your Data Pump parameter file.
• Restart both processes: 

bash

GGSCI> START EXTRACT <extract_group_name>
GGSCI> START EXTRACT <data_pump_name>

3. Target: Initial Data Sync & Parameter Update

Before applying ongoing transactions to the target, the two new tables must contain their historical data, and the Replicat must be updated. 

• Stop the Replicat process: 

bash

GGSCI> STOP REPLICAT <replicat_group_name>

• Sync the data from the source to target using either Oracle Data Pump, an import/export, or GoldenGate Initial Load.
• Edit the Replicat parameter file and map the source tables to their target equivalents: 

text

MAP <schema.new_table_1>, TARGET <schema.new_table_1>;
MAP <schema.new_table_2>, TARGET <schema.new_table_2>;

• Start the Replicat: 

bash

GGSCI> START REPLICAT <replicat_group_name>

 Question :How will check and step for troubleshooting of extrac process abended in golden gate

When an Oracle GoldenGate Extract process abends, immediately check the exact error using VIEW GGSEVT and VIEW REPORT in the GGSCI prompt. These files reveal the exact failure reason (e.g., ORA-01403, network drop, missing trail), allowing you to address the root cause directly. 

Use this standardized, step-by-step framework to diagnose and fix the issue.

1. Check the Status and Error Logs

Start the GoldenGate Command Interface (GGSCI) to identify the error: 

• Check Status: Run INFO EXTRACT <extract_name> to confirm the abended status.
• View Report File: Run VIEW REPORT <extract_name>. Scroll to the bottom to find the exact database, OS, or OGG-specific error that caused the abend.
• View Global Log: Run VIEW GGSEVT to review manager or system-level issues. 

2. Common Causes and Troubleshooting Steps

Look for these common failure triggers in your report file:

• Database Archival Issues (ORA-xxxx): The Extract may have aborted because it couldn't read the database redo logs (e.g., logs not found, database crashed, or archive log deletion before GoldenGate processed them).
  • Fix: Register the Extract with the database or restore the required archive logs to the disk. 
• Memory / Out of Bounds (ORA-04031): The extract may run out of memory when heavy transactions are captured.
  • Fix: Increase the streams pool size via SQL: ALTER SYSTEM SET streams_pool_size = 2G; 
• Missing or Corrupted Trail Files (OGG-01044 / OGG-01668): Occurs if trail files were deleted manually or improperly pointed to.
• Fix: Verify the target path and trail parameters in VIEW PARAMS <extract_name>. Add or register the trail explicitly.

3. Take Corrective Action

Once you have identified and corrected the underlying issue (e.g., modifying the parameter file or fixing a database constraint), you need to restart the process.

• Stop the process completely: STOP EXTRACT <extract_name>.
• Restart the process: START EXTRACT <extract_name>. 

If an Extract is hanging or uncooperative, you may have to force-stop it using KILL EXTRACT <extract_name> before attempting to start it again

or

When an Oracle GoldenGate Extract process abends, the standard troubleshooting process is to examine the process report and discard files to identify the exact Oracle error or misconfiguration. The most common causes are memory constraints, missing logs, or table definition mismatches. 

1. The Troubleshooting Framework

In an interview, you should outline a structured, step-by-step approach to identifying and resolving an Extract abend:

• Check the Status: Run INFO EXTRACT <extract_name> or INFO ALL in GGSCI to confirm the current state (ABENDED). 
• Review the Report File: Go to the dirrpt directory and open the most recent .rpt file. This contains the specific error message and exactly where (by CSN or SCN) the process failed. 
• Review the Discard File: Check the .dsc file. If the failure is due to a specific data constraint or bad record, it will be logged here. 
• Check the Database Alert Log: Review the source database alert log, as Extract abends frequently stem from underlying database errors (e.g., LogMiner failing to access archived logs). 

2. Common Causes and Solutions

• Memory Pressure (ORA-04031 or similar): The Extract process runs out of memory, often during large, uncommitted batch transactions.
  • Fix: Increase the CACHEMGR CACHESIZE parameter in the Extract parameter file, or increase the database Streams Pool Size (streams_pool_size). 
• Missing or Purged Archive Logs: The Extract process tries to read a redo log that has already been purged from disk or ASM.
  • Fix: Register the Extract with the database (e.g., REGISTER EXTRACT <name> DATABASE) so the database retains the needed redo logs, or restore the missing archive log. 
• DDL/Table Definition Mismatch: A structural change (like a dropped column) has occurred in the source database without updating the GoldenGate definitions.
  • Fix: Use the OBEY command to generate a new definition file, or ensure supplemental logging is properly updated. 
• Missing Supplemental Logging: Missing database-level or table-level supplemental logging.
  • Fix: Ensure that at least minimal supplemental logging is turned on at the source database level. 

3. Recovery Steps

Once the underlying issue is resolved:

1. Fix the error in the parameter file or at the database level.
2. Start the process in GGSCI: START EXTRACT <extract_name>.
3. Verify the state again using INFO EXTRACT <extract_name> to ensure the status changes to RUNNING

1. How do you troubleshoot and find the exact reason a Replicat process abended?

Answer: I start by running the VIEW REPORT command in GGSCI to check the latest execution log. If the report doesn't provide enough detail, I check the discard file (.dsc), which contains the exact failed SQL statements, database error codes, and sequence numbers.
Command: VIEW REPORT [group_name] or VIEW DISCARD [group_name] 

2. What are the most common causes for a Replicat process to abend?

Answer: The most frequent causes include:

• Data Collisions: Trying to insert a row that already exists, or update a row that is missing.
• Database Errors: Running out of tablespace, missing target indexes, or lock/blocking sessions on the target.
• Missing Target Objects: The target table, column, or schema does not exist.
• Trail File Corruption: Issues reading the trail file or physical disk space exhaustion on the destination. 

3. How do you fix data collision errors like ORA-01403 (No Data Found) or ORA-00001 (Unique Constraint Violated)?

Answer: There are two main approaches:

1. Manual Fix: Insert or delete the conflicting row manually in the target database to match the source, then simply restart the Replicat.
2. Handle Collisions: Use the HANDLECOLLISIONS parameter to temporarily bypass these errors while the processes sync up, then remove it once replication stabilizes. 

4. How do you resume a Replicat process after resolving an abend?

Answer: Once the root cause is resolved (e.g., missing table created, disk space cleared), you navigate to the GoldenGate command interface and start the process:
Command: START REPLICAT [group_name]

5. When should you use the SKIPTRANSACTION parameter?

Answer: If the Replicat abends due to a corrupted or large, unrecoverable transaction, and fixing it manually is not viable, you can skip the transaction causing the issue.
Command: SEND REPLICAT [group_name], SKIPTRANSACTIO

Question : How to daily monitoring command with detail ,example and purpose in golden gate

 Daily GGSCI command toolkit:

• INFO ALL - Displays the overall operating status (RUNNING or STOPPED), lag time, and checkpoint data for all processes on the local system.
• STATUS MGR - Verifies that the GoldenGate Manager process is running.
• SEND <process_name>, GETLAG - Checks the exact latency between records being processed and their timestamp in the source data.
• STATS <process_name> - Shows the total number of inserts, updates, and deletes processed since the last startup.
• VIEW GGSEVT - Views the global GoldenGate error log for any generated warnings, messages, or processing events.
• VIEW REPORT <process_name> - Displays the detailed diagnostic log for a specific Extract or Replicat process

1. Check Overall Process Status

• Command Syntax: INFO ALL 
• Key Details Returned:
  • Type of process (MANAGER, EXTRACT, REPLICAT)
  • Execution Status (RUNNING, STOPPED, ABENDED)
  • Current replication lag
  • Checkpoint lag 
• Operational Purpose: Provides a high-level system snapshot. This is the very first command to run daily to detect if any replication thread has crashed (ABENDED) or stopped unexpectedly. 

2. Investigate Individual Process Contexts

• Command Syntax: INFO <group_name>, DETAIL 
• Key Details Returned:
  • Directory locations of working directories and parameter files
  • Target and source trail file names and sequence numbers
  • Exact Read/Write checkpoint positions (RBA - Relative Byte Address)
  • Environment settings and TCP/IP port information 
• Operational Purpose: Allows deep troubleshooting of a specific process. It helps you verify which trail sequence a group is currently locking or processing. 

3. Track Replication Latency (Lag)

• Command Syntax: LAG <group_name> or LAG ALL
• Key Details Returned:
  • Precise time difference between the timestamp of the last record processed and the current time of the data source. 
• Operational Purpose: Monitors performance health. A sudden spike in lag signals a performance bottleneck on the target database, network latency, or massive long-running source transactions. 

4. Audit Data Volume and Throughput

• Command Syntax: STATS <group_name>, DAILY 
• Key Details Returned:
  • Precise volume of data replicated within the last 24 hours.
  • Discrete count of operations broken down by SQL type (INSERTS, UPDATES, DELETES, DDLs). 
• Operational Purpose: Tracks transactional workload patterns. It ensures GoldenGate is actually processing records actively rather than sitting idle while lag increases. 

5. Verify the GoldenGate Manager Service

• Command Syntax: INFO MANAGER 
• Key Details Returned:
  • Operational status of the master Manager process.
  • The active TCP/IP port allocation (default is 7409).
  • Process ID (PID). 
• Operational Purpose: Ensures the core management service is functioning. If the Manager drops, auxiliary automated tasks like trail file purges and auto-restarts will fail completely. 

6. Inspect Active Trail Files 

• Command Syntax: INFO EXTTRAIL * or INFO RMTTRAIL * 
• Key Details Returned:
  • Path and file prefix of the local or remote trail.
  • The max file size cap (e.g., 500MB).
  • The exact sequence number and byte position of the last written trail file. 
• Operational Purpose: Prevents disk space allocation errors. It tracks file generation rates to verify that your purging parameters (PURGEOLDEXTRACTS) are keeping storage usage within safe bounds. 

---

Non-Command Line Checklist (Daily Requirements)

Beyond running text commands, a robust daily routine must include inspecting local system files: 

• The Error Log (ggserr.log): View this via the OS command line (tail -100f ggserr.log) or via VIEW GGSEXT ERROREND inside GGSCI. It captures all errors, warnings, and internal database connection drops. 
• Discard Files (*.dsc): View via VIEW DISCARD <group_name>. Check this to catch data mismatch or structural constraint errors that forced rows to be skipped instead of replicated. 

OR

Daily monitoring of Oracle GoldenGate is crucial to ensure data replication stays healthy, lag remains minimal, and processes do not unexpectedly halt. These tasks are performed through the Oracle GoldenGate Software Command Interface (GGSCI). 

The most essential daily monitoring commands, along with their purpose, detail, and examples, are organized below by category:

1. Overall System Health

INFO ALL

• Purpose: Provides a snapshot of all GoldenGate processes (Manager, Extract, Replicat) running on the system. It is the absolute first command a DBA runs daily. 
• Detail: Displays the process status (RUNNING, STOPPED, ABENDED), the process name, lag time, and checkpoint lag time. 
• Example:
  text

  GGSCI (server1) 1> INFO ALL
  

  
  
• Output Breakdown: Look for any processes with an ABENDED status (which indicates a crash) and check if the Lag at Chkpt is high, indicating replication delays. [1]

STATUS MGR

• Purpose: Checks if the background GoldenGate Manager process is up and running.
• Detail: The Manager process must be active to manage trail files, clean up disk space, and restart other processes.
• Example:
  text

  GGSCI (server1) 2> STATUS MGR
  

  
  

---

2. Process Performance & Latency

SEND <process>, GETLAG 

• Purpose: Retrieves the real-time latency/lag of a specific process.
• Detail: Unlike INFO ALL which reads from checkpoint files, SEND communicates directly with the active memory of the running process to get immediate lag statistics.
• Example:
  text

  GGSCI (server1) 3> SEND EXTRACT ext_east, GETLAG
  GGSCI (server1) 4> SEND REPLICAT rep_west, GETLAG
  

  
  

STATS <process>

• Purpose: Monitors processing volume by displaying data statistics (inserts, updates, deletes) since the process started.
• Detail: Resets upon process restart. You can append REPORTRATE to see the performance processing speed per hour, minute, or second.
• Example:
  text

  GGSCI (server1) 5> STATS REPLICAT rep_west
  GGSCI (server1) 6> STATS EXTRACT ext_east, REPORTRATE MIN
  

  
  

---

3. Deep-Dive Diagnostics

INFO <process>, DETAIL

• Purpose: Displays underlying operational details for a specific group.
• Detail: Shows trail file locations, target database parameters, error limitations, and the specific read/write checkpoint sequences.
• Example:
  text

  GGSCI (server1) 7> INFO EXTRACT ext_east, DETAIL
  

  
  

SEND <process>, STATUS 

• Purpose: Monitors the current operational state or recovery status of a process.
• Detail: Particularly useful when an Extract process is taking a long time to start up. It tells you exactly what log file and RBA (Relative Byte Address) it is currently reading during its boot/recovery phase.
• Example:
  text

  GGSCI (server1) 8> SEND EXTRACT ext_east, STATUS
  

  
  

---

4. Logs and Troubleshooting

VIEW REPORT <process>

• Purpose: Displays the run report of a process to review errors, memory footprint, or environment mappings.
• Detail: If a process has ABENDED, running this command opens the report file directly inside GGSCI so you can scroll to the bottom and see the specific fatal error.
• Example:
  text

  GGSCI (server1) 9> VIEW REPORT rep_west
  

  
  

VIEW GGSEVT

• Purpose: Views the main Oracle GoldenGate product error log (ggserr.log).
• Detail: Shows an integrated timeline of system messages, startup events, alerts, warnings, and errors across the entire GoldenGate instance.
• Example:
  text

  GGSCI (server1) 10> VIEW GGSEVT
  

  
  

---

Summary Checklist for Daily Checks

Goal	Command Syntax	What to Look For
Quick Health Check	INFO ALL	All components show RUNNING status.
Lag Verification	SEND <process>, GETLAG	Lag time should be at or near 00:00:00.
Crash Diagnosis	VIEW REPORT <process>	Scroll to the very bottom to catch the exact error.
System Event Check	VIEW GGSEVT	Look for critical threshold errors or warnings.

If you want to automate these steps, would you like help writing a shell script to run these daily commands and email you the status? Or do you need assistance configuring automatic alerts for lag threshold

Question : How will check and step for troubleshooting of replicate process abended in golden gate

Troubleshooting an abended Replicat in Oracle GoldenGate involves identifying the exact SQL error or missing dependency causing the halt, resolving it at the target database level, and repositioning the Replicat to resume processing properly. 

Step 1: Check the Status and Locate the Error

1. Check Status: Run the command in GGSCI to see the process status.
   text

   INFO REPLICAT <group_name>

Review the Report File: The report file holds the root cause of the abend. Navigate to your GoldenGate directory and view the latest report for the group:

text

VIEW REPORT <group_name>

Check Discard File: If the report points to a specific database error, the discard file contains the exact failed transaction and the SQL/ORA error code:

text

VIEW DISCARD <group_name>

Step 2: Resolve the Root Cause

Common reasons for a Replicat abend include missing primary keys, unique constraint violations, or missing target tables. 

1. Address the specific error found in the discard file directly on your target database.
2. If it is a duplicate row or unique constraint error, you may need to manually insert or delete the conflicting row on the target depending on your synchronization needs.
3. If the error is an OGG-00918, ensure your target table has an explicit PRIMARY KEY, UNIQUE KEY, or is defined with a KEYCOLS statement in your Replicat parameter file. 

Step 3: Reposition and Restart

Once the issue is resolved on the database, reposition the Replicat to skip the failing transaction and restart. 

1. Start the Replicat: Attempt to simply start it; GoldenGate often manages checkpoints automatically.

text

START REPLICAT <group_name>

Skip a Transaction (If it fails again): If it continues to abend on the same record, skip the offending transaction and resume processing:

text

ALTER REPLICAT <group_name> SKIP
START REPLICAT <group_name>

Question : How will check and step for troubleshooting of extract process running slow in golden gate

A slow GoldenGate Extract process is usually caused by long-running open transactions, heavy I/O on redo logs, memory exhaustion, or network latency. To troubleshoot effectively, follow a phased approach to identify whether the bottleneck lies in the database logminer or the GoldenGate Extract process itself. 

Step 1: Check Current Extract Status and Lag

First, determine the severity of the delay by checking the process information, lag statistics, and checkpoint details. 

1. Log into the GoldenGate Command Interface (GGSCI) or use the Administration Service Console. 
2. Run the status and lag check:
   text

   INFO EXTRACT <extract_name>, DETAIL
   
   Evaluate the output:
   Lag at Chkpt: Indicates how far the Extract is behind the database current state.
   Time Since Chkpt: If this number is increasing while lag is constant, the Extract may be hung, looping, or stuck in recovery. [1, 2]
   Step 2: Identify Long-Running or Large Transactions
   The most common cause of a slow Extract is a large, uncommitted transaction (e.g., a massive batch update), which forces the process to buffer data heavily in memory and spill over to disk. [1, 2, 3]
   Check for open transactions by running:
   text
   SEND EXTRACT <extract_name>, SHOWTRANS
   
   Identify the transaction with the oldest timestamp or the highest number of operations.
   If necessary, check the source database side for heavy locking or uncommitted batch jobs.
   Action: Consider enabling Bounded Recovery to mitigate long restart times and manage cache overflows. 
   Step 3: Analyze the Log and Report Files
   The GoldenGate report and ggserr.log files provide direct warnings about resource contention or specific slow tables.
   Access the report file from the command line:
   
   VIEW REPORT <extract_name>
   
   
   Look for WARNING messages, particularly relating to WARNLONGTRANS (which alerts you to transactions open for an extended duration).
   Check the database alert.log or wait events (e.g., using AWR reports) for I/O waits or heavy redo log switching.
   Step 4: Verify System Resources and I/O
   If your server's memory, swap, or I/O is saturated, Extract processing will plummet. ]
   Memory: Run top or check your OS-level metrics to ensure the Extract process isn't causing heavy swapping due to large transaction loads.
   I/O Bottlenecks: Ensure your source database Redo and Archive logs are stored on high-speed disks (e.g., SSDs). 
   If the database log reader is struggling to parse slow disks, the whole pipeline stalls. 
   Step 5: Check Network Bottlenecks (For Data Pump)
   If you are using a secondary Extract (Data Pump) pushing data to a target server,
   network latency might be causing a backup. 
   Run SEND EXTRACT <data_pump_name>, SHOWTRANS to verify if data is backing up between the primary Extract and Data Pump trail files.
   Run standard network latency diagnostics (like ping or traceroute) against the target server. 
   
   Question : How will check and step for troubleshooting of replicate process running slow in golden gate
   To troubleshoot a slow Oracle GoldenGate Replicat, isolate whether the bottleneck is on the GoldenGate-side or the Database-side. 
   Step 1: Check Replicat Lag and Status
   Execute the following commands in the GoldenGate Software Command Interface (GGSCI): 
   Check the Replicat status and lag:
   INFO REPLICAT [rep_name]
   Get detailed processing stats (low and high watermarks):
   SEND REPLICAT [rep_name], STATUS
   View the latest performance data:
   STATS REPLICAT [rep_name] 
   Step 2: Review Report Files and Error Logs
   Review the process metrics to understand where the Replicat is struggling:

3. Start by analyzing your Replicat lag and throughput using the INFO REPLICAT and SEND REPLICAT commands, then tune your parameters and database indexes. 

1. Examine the Replicat report file. Look for logged messages, ReportCount (apply rate), or serialization warnings indicating that parallelism is suspended.
2. Check the ggserr.log for any database deadlocks or network/I/O warnings.

Step 3: Investigate Database Bottlenecks

If the Replicat is running but applying data slowly, the bottleneck is often the target database. 

1. Wait Events: Check the target database for high wait events such as enq: TX - row lock contention, log file sync, or direct path write during the slow replication windows.
2. Missing Indexes: Ensure the target tables have proper Primary Keys or Unique Indexes. Tables without keys force full table scans on every update or delete. 

Step 4: Implement Performance Tunning

Modify your Replicat parameter file (PARAM rep_name) or apply database optimizations to speed up the process: 

1. Use Parallel/Integrated Replicat: If targeting an Oracle database, use Integrated Replicat mode to partition workloads automatically across multiple parallel apply processes. 
2. Batch SQL processing: Use the BATCHSQL parameter to group similar DML operations (Inserts, Updates, Deletes) together, reducing round trips to the database. 
3. Control Transaction Size: Use GROUPTRANSOPS to combine smaller operations into larger transactions and reduce I/O activity, provided you aren't using an integrated Replicat. 
4. Defer Constraints: Temporarily disable foreign key constraints during massive data loads if your application can tolerate eventual consistency. 

For more official guidelines on adjusting your parameters, refer to the Oracle GoldenGate Tuning Performance Guide.

Question : what possible performance tuning parameter in golden gate

In Oracle GoldenGate, tuning buffer and memory parameters is critical for mitigating lag, preventing disk spilling, and optimizing throughput. Parameters are categorized below by how they impact memory caching, network transfer, and database read/write buffers. 

1. Memory and Cache Buffer Tuning (Extract & Replicat)

GoldenGate uses the CACHEMGR parameter to control virtual memory allocation. By default, it allocates a large memory cache for transactions, swapping to disk when thresholds are breached. 

• CACHEMGR CACHESIZE: Sets the memory limit available to the cache manager. Increasing this size prevents processes from spilling heavy batch transactions to temporary disk files. 
• CACHEMGR CACHEDIRECTORY: Specifies the location on disk where overflow transactions should be swapped. Using a dedicated or SSD-backed directory avoids I/O contention. 

2. Database Buffer Pools (Integrated Capture / Extract)

When using Integrated Extract, performance relies heavily on the database's Streams Pool and internal buffer thresholds. [

• STREAMS_POOL_SIZE (Database Parameter): Allocates memory in the Oracle SGA for LogMiner. Set this using the formula: \((MAX\_SGA\_SIZE \times \text{number of Integrated Extracts}) + \text{25\% headroom}\).
• MAX_SGA_SIZE (Extract Parameter): Controls the max amount of shared memory used by the LogMiner server. The default is 1GB, which is typically sufficient.
• _LOGMINER_READ_BUFFERS (Database Parameter): Controls the number of buffers used by LogMiner to read Redo logs (highly recommended to set to 256). 

3. Network Buffer Tuning (Data Pumps)

For large-latency networks or high-throughput Data Pump pipelines, tuning the network and TCP buffers improves throughput. 

• TCPBUFSIZE: Controls the maximum size of the message buffer sent to the Collector process over TCP/IP. Defaults can be small, but allocating a larger value (like 1MB) decreases protocol overhead. 
• TCPFLUSHBYTES: Determines when the TCP buffer is flushed to the network, regardless of the buffer size. Setting this alongside TCPBUFSIZE ensures that buffers are actively and consistently pushed over high-bandwidth pipelines. 
• SDU Size (Oracle Net): Controls the session data unit buffer size for SQL*Net. Increasing this to 2MB for hub extract processes efficiently utilizes bandwidth. []

4. Read/Write Buffers (Trails and Target DB)

• _log_read_buffers and _log_read_buffer_size (Database Parameter): Source database initialization parameters that improve the LogMiner server's ability to read Online Redo Logs faster by increasing buffer numbers and sizes (recommended sizes: 64 and 128 respectively). 
• BATCHSQL (Replicat Parameter): Groups multiple identical SQL statements across multiple transactions into arrays to be applied simultaneously on the target database, drastically reducing wait/barrier events

or

Oracle GoldenGate (OGG) performance tuning relies on optimizing parameters across the Extract, Data Pump, and Replicat processes to eliminate bottlenecks in disk I/O, network latency, and database processing. 

Here are the critical tuning parameters, including detailed implementation steps and configuration examples. 

---

1. BATCHSQL (Replicat Process)

By default, the Replicat process applies SQL operations one row at a time. Enabling BATCHSQL tells GoldenGate to group similar SQL statements into arrays before executing them, which can improve delivery speeds up to 10 times for heavy row-by-row transaction workloads. 

Detailed Steps:

1. Open the Replicat parameter file using the GoldenGate Software Command Interface (GGSCI).
2. Add the BATCHSQL parameter at the top of the parameter file.
3. Save the file and restart the Replicat process. 

Configuration Example:

text

-- Open the parameter file in GGSCI
GGSCI> EDIT PARAMS REPLAY1

-- Add the following lines to the parameter file
REPLICAT replay1
USERIDGSALIAS target_db_auth
BATCHSQL
BATCHOPS 5000
BATCHMAXBYTES 10000000
MAP sales.*, TARGET sales.*;

• BATCHOPS 5000: Sets the maximum number of operations in a single batch.
• BATCHMAXBYTES: Defines the maximum size of the batch in bytes before forcing an execution.

---

2. DBOPTIONS INTEGRATEDPARAMS (Parallelism for Integrated/Parallel Replicat)

When using Integrated or Parallel Replicat modes, GoldenGate coordinates multiple applier threads inside the target database. The parallelism parameter dictates how many threads simultaneously process trail transactions. 

Detailed Steps:

1. Calculate the ideal number of threads based on your server resources (a common rule of thumb is Total CPU / 2).
2. Open your Replicat parameter file.
3. Insert DBOPTIONS INTEGRATEDPARAMS (parallelism <N>).
4. Restart the Replicat. 

Configuration Example:

text

GGSCI> EDIT PARAMS REPLAY1

REPLICAT replay1
USERIDGSALIAS target_db_auth
DBOPTIONS INTEGRATEDPARAMS (parallelism 8)
MAP sales.*, TARGET sales.*;

• parallelism 8: Forces GoldenGate to spin up 8 background processes in the target instance to parse and execute transactions simultaneously. 

---

3. PASSTHRU (Data Pump Process)

If your Data Pump process is only transferring data from the source to the target without executing any filtering, transformation, or column mapping, GoldenGate wastes CPU cycles looking inside the trail files. PASSTHRU stops this tracking and streams data directly to the remote system. 

Detailed Steps:

1. Identify the Data Pump process parameter file.
2. Ensure no filtering functions (like FILTER or COLMAP) are present in the table definitions.
3. Place PASSTHRU right before your table mappings.
4. Restart the Data Pump. 

Configuration Example:

text

GGSCI> EDIT PARAMS PPUMP1

EXTRACT ppump1
USERIDGSALIAS source_db_auth
RMTHOST target_server, MGRPORT 7809
RMTTRAIL ./dirdat/rt
PASSTHRU
TABLE sales.*;

4. RMTHOST Options: COMPRESS and TCPBUFSIZE (Network Optimization) 

Network delay represents a significant bottleneck for multi-site replication. The COMPRESS option reduces payload size before sending over TCP, while TCPBUFSIZE expands the memory socket buffer sizes to match modern bandwidth capabilities. 

Detailed Steps:

1. Open your Data Pump parameter file.
2. Locate the line containing RMTHOST.
3. Append COMPRESS and TCPBUFSIZE arguments to that line.
4. Restart your Data Pump process. 

Configuration Example:

text

GGSCI> EDIT PARAMS PPUMP1

EXTRACT ppump1
USERIDGSALIAS source_db_auth
RMTHOST 192.168.1.50, MGRPORT 7809, COMPRESS, TCPBUFSIZE 2097152
RMTTRAIL ./dirdat/rt
TABLE sales.*;

• COMPRESS: Instructs the pump to compress trail block blocks before transit.
• TCPBUFSIZE 2097152: Allocates a 2MB TCP window buffer size to optimize high latency or WAN network connections. 

---

5. CACHEMGR (Memory and Disk Paging Optimization)

The GoldenGate cache manager stores transaction tracking records in virtual memory. When it runs out of unallocated memory space, it begins writing (paging) transaction data to disk, causing critical performance lags. 

Detailed Steps:

1. Look up available virtual RAM resources on your host machine.
2. Edit the Extract or Replicat parameter file.
3. Define the CACHEMGR size limits explicitly to bypass default restrictions.
4. Restart the process group. 

Configuration Example:

text

GGSCI> EDIT PARAMS EXTN1

EXTRACT extn1
USERIDGSALIAS source_db_auth
CACHEMGR CACHESIZE 4G, CACHEDIRECTORY /u01/app/gg_cache
EXTTRAIL ./dirdat/lt
TABLE sales.*;

• CACHESIZE 4G: Grants up to 4 Gigabytes of global virtual memory pool capacity before writing swap directories to disk.
• CACHEDIRECTORY: Points to an ultra-fast flash SSD directory path to handle emergency spills.