---
title: Oracle GoldenGate Installation, Part 1
description: "This is a series about Oracle GoldenGate (GG). This post covers installing GG and creating simple replication using only the \"extract\" and \"replicat\" processes."
---

[Blog | Pythian ](https://www.pythian.com/blog)

# [Oracle GoldenGate Installation, Part 1](https://www.pythian.com/blog/oracle-goldengate-installation-part-1)

 Written by [Gleb Otochkin](https://www.pythian.com/blog/author/gleb-otochkin) | Feb 18, 2010 5:00:00 AM

I want to introduce several post about Oracle GoldenGate (GG), a relatively new replication software from Oracle.

We all know replication using Oracle Streams technology. Streams are improving from version to version of the RDBMS, and now it is a very well managed and reliable technology with a large set of options and capabilities. But, in the document Oracle – GoldenGate Statement of Direction (PDF), GoldenGate software was announced as the strategic replication solution for Oracle Database, and Oracle plans to direct all efforts to improve it.Therefore, I think it is time to make the acquaintance of GoldenGate.

This first post is about installating GG software and creating the simplest replication using only the “extract” and “replicat” processes.

Lets start the installation.

## 1. Preparation

Our first step is preparing the box for our test replication. I am using a VMWare virtual server for my tests.

1. Install linux x64 on your box. I used Linux Centos 5.3. The hostname for our source box will be db1.
2. Install the Oracle software on the box. I am using Oracle 11gr2 for test purposes. The software from can be found on otn.oracle.com. Unzip and install it.Oracle software installation:  
   Copy the two zip files to some location on the machine and unzip them:
   
    
   
   ```
   [oracle@db1 distr]$ export DISTR=/u01/app/oracle/distr
   [oracle@db1 distr]$ cd $DISTR
   [oracle@db1 distr]$ unzip linux.x64_11gR2_database_1of2.zip
   [oracle@db1 distr]$ unzip linux.x64_11gR2_database_2of2.zip
   ```
   
   Edit response file for silent installation:
   
   ```
   [oracle@db1 distr]$ vi $DISTR/database/response/db_install.rsp
   [oracle@db1 distr]$ cd $DISTR/database
   ```
   
   Set proper parameter for kernel, create necessary user and groups and set limits for the Oracle owner. (I used the `oracle` user for this).
   
   Install the software:
   
   ```
   [oracle@db1 database]$ ./runInstaller -silent -responseFile $DISTR/database/response/db_install.rsp
   [oracle@db1 ~]$ su - root
   [root@db1 ~]# /u01/app/oracle/product/11.2.0/db_1/root.sh
   ```
3. Create a test database:
   
   ```
   [oracle@db1 ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1
   [oracle@db1 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
   [oracle@db1 ~]$ dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbName base11r2 -sysPassword qwerty -systemPassword qwerty -emConfiguration NONE -datafileDestination /u01/app/oracle/oradata -storageType FS
   ```
4. Start the listener and set up a network alias:
   
   ```
   [oracle@db1 ~]$ lsnrctl start
   [oracle@db1 ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora
   ```

## 2. Install

With the database created, we can install GoldenGate software to the box:

```
[oracle@db1 gg]$ ./ggsci
```

1. You should now get the prompt to the GoldenGate command line interface:
   
   ```
   Oracle GoldenGate Command Interpreter for Oracle
   Version 10.4.0.19 Build 002
   Linux, x64, 64bit (optimized), Oracle 10 on Sep 22 2009 14:18:08
   Copyright (C) 1995, 2009, Oracle and/or its affiliates.  All rights reserved.
   GGSCI (db1) 1>
   ```
2. Create the necessary working directories for GG.  
   [oracle@db1 gg]$ ./ggsci  
   GGSCI (db1) 1>create subdirs  
   GGSCI (db1) 1>exit  
   [oracle@db1 gg]$ mkdir $GGATE/discard
3. The GoldenGate software has been successfully installed to the box db1.

## 3. Destination-side

We must repeat all the above steps on the destination side. Here, it will be host `db4` with same database.

## 4. Source database

The GoldenGate software having been installed successfully, we must prepare the source database for replication.

1. Switch the database to archivelog mode:
   
   ```
   SQL> shutdown immediate
   SQL> startup mount
   SQL> alter database archivelog;
   SQL> alter database open;
   ```
2. Enable minimal supplemental logging:
   
   ```
   SQL> alter database add supplemental log data;
   ```
3. Prepare the database to support ddl replication (optional).a) Turn off recyclebin for the database . . .
   
   ```
   SQL> alter system set recyclebin=off scope=spfile;
   ```
   
   . . . and bounce it.
   
   b) Create schema for ddl support replication . . .
   
   ```
   SQL> create user ggate identified by qwerty default tablespace users temporary tablespace temp;
   ```
   
   . . . and grant the necessary privileges to the new user..
   
   ```
   [oracle@db1 gg]$ cd $GGATE
   SQL> grant connect,resource,unlimited tablespace to ggate;
   SQL> grant execute on utl_file to ggate;
   ```
   
   c) Run scripts for creating all necessary objects for support ddl replication:
   
   ```
   SQL> @$GGATE/marker_setup.sql
   SQL> @$GGATE/ddl_setup.sql
   SQL> @$GGATE/role_setup.sql
   SQL> grant GGS_GGSUSER_ROLE to ggate;
   SQL> @$GGATE/ddl_enable.sql
   ```
   
    
4. Create test schemas for replication. I will create a replication from schema `sender` to schema `receiver` (the receiving schema can be on the same database or on another).a) Source database:
   
   ```
   SQL> create user sender identified by qwerty default tablespace users temporary tablespace temp;
   SQL> grant connect,resource,unlimited tablespace to sender;
   ```
   
   b) Destination database:
   
   ```
   SQL> create user receiver identified by qwerty default tablespace users temporary tablespace temp;
   SQL> grant connect,resource,unlimited tablespace to receiver;
   ```

## 5. Replication

We’re going to create the simplest replication without the GG data pump (we can add it later). Our goal is to create dml and ddl replication from the `sender` schema on the source database to `receiver` schema on the destination.

Replication also works if you’re using only one database. This is replication between schemas.

1. Create and start manager on the source and the destination.Source:
   
   ```
   [oracle@db1 gg]$ cd $GGATE
   [oracle@db1 gg]$ ./ggsci
   GGSCI (db1) 4> info all
   Program     Status      Group       Lag           Time Since Chkpt
   MANAGER     STOPPED
   GGSCI (db1) 6> edit params mgr
   PORT 7809
   GGSCI (db1) 7> start manager
   Manager started.
   ```
   
   We can check status of our processes:
   
   ```
   GGSCI (db1) 8> info all
   Program     Status      Group       Lag           Time Since Chkpt
   MANAGER     RUNNING
   ```
2. Create the `extract` group on the source side:
   
   ```
   GGSCI (db1) 1> add extract ext1, tranlog, begin now
   EXTRACT added.
   GGSCI (db1) 2> add exttrail /u01/app/oracle/product/gg/dirdat/lt, extract ext1
   EXTTRAIL added.
   GGSCI (db1) 3> edit params ext1
   ```
   
   Add the following lines to the new parameter file for our extract:
   
   ```
   --extract group--
   extract ext1
   --connection to database--
   userid ggate, password qwerty
   --hostname and port for trail--
   rmthost db2, mgrport 7809
   --path and name for trail--
   rmttrail /u01/app/oracle/product/gg/dirdat/lt
   --DDL support
   ddl include mapped objname sender.*
   --DML
   table sender.*;
   ```
   
   We can check our processes again:
   
   ```
   GGSCI (db1) 6> info all
   Program     Status      Group       Lag           Time Since Chkpt
   MANAGER     STOPPED
   EXTRACT     STOPPED     EXT1        00:00:00      00:10:55
   ```
3. Create replicat on the destination side:
   
   ```
   [oracle@db2 gg]$ cd $GGATE
   [oracle@db2 gg]$ ./ggsci
   add checkpoint table to the destination database
   GGSCI (db2) 1> edit params ./GLOBAL
   and put following lines to the global parameter file:
   GGSCHEMA ggate
   CHECKPOINTTABLE ggate.checkpoint
   ~
   GGSCI (db2) 2> dblogin userid ggate
   Password:
   Successfully logged into database.
   GGSCI (db2) 3> add checkpointtable ggate.checkpoint
   Successfully created checkpoint table GGATE.CHECKPOINT.
   Create replicat group:
   GGSCI (db2) 4> add replicat rep1, exttrail /u01/app/oracle/product/gg/dirdat/lt,checkpointtable ggate.checkpoint
   REPLICAT added.
   create parameter file for replicat:
   GGSCI (db2) 5> edit params rep1
   ```
   
   And put following lines in the parameter file:
   
   ```
   --Replicat group --
   replicat rep1
   --source and target definitions
   ASSUMETARGETDEFS
   --target database login --
   userid ggate, password qwerty
   --file for dicarded transaction --
   discardfile /u01/app/oracle/product/gg/discard/rep1_discard.txt, append, megabytes 10
   --ddl support
   DDL
   --Specify table mapping ---
   map sender.*, target receiver.*;
   ```
4. Start extract and replicat:Source:
   
   ```
   GGSCI (db1) 14> start extract ext1
   ```
   
   Destination:
   
   ```
   GGSCI (db2) 15> start replicat rep1
   ```
5. Check all processes.Source:
   
   ```
   GGSCI (db1) 8> info all
   Program     Status      Group       Lag           Time Since Chkpt
   MANAGER     RUNNING
   EXTRACT     RUNNING     EXT1        00:00:00      00:00:05
   ```
   
   Destination:
   
   ```
   GGSCI (db1) 8> info all
   Program     Status      Group       Lag           Time Since Chkpt
   MANAGER     RUNNING
   REPLICAT    RUNNING     REP1        00:00:00      00:00:00
   ```
   
   Our replication has been successfully created.

## 6. Checking

Now we can check our replication. We will create some tables in the `sender` schema on the source, insert some rows, and check how it will replicate to destination side.

1. Source database:
   
   ```
   SQL> create table sender.test_tab_1 (id number,rnd_str varchar2(12));
   SQL> insert into sender.test_tab_1 values (1,'test_1');
   SQL>commit;
   ```
2. Destination database:
   
   ```
   SQL> select * from receiver.test_tab_1;
   ID RND_STR
   ---------- ------------
   1 test_1
   ```

Our GoldenGate DDL and DML replication is now working. The table was created on the destination side and data were replicated.

In the next post in this series, I will show how to modify our replication.

## Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?

[View full post](https://www.pythian.com/blog/oracle-goldengate-installation-part-1)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Gleb Otochkin"
  },
  "dateModified" : "2026-02-23T23:49:13.783Z",
  "datePublished" : "2010-02-18T05:00:00Z",
  "headline" : "Oracle GoldenGate Installation, Part 1",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://www.pythian.com/blog/oracle-goldengate-installation-part-1",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Pythian Blog"
  }
}
```