Thursday, January 28, 2016

How to install and configure Oracle Golden Gate – Initial Setup


source

How to install and configure Oracle Golden Gate – Initial Setup

A while ago I was presented with the challenge of synchronizing several databases in order to move data from a source database to a stage database and finally to a target database.  Although there are several ways to achive this, it was decided to use Oracle Golden Gate to migrate the data, in real time, to a stage server and then to a target server.
There was also a need of creating some interfaces in order to mask the database structure on source server and fullfil the customer’s demands. There the Oracle Data Integrator comes in, but we will discuss the ODI on another blog.

A.- Topology

I have installed Oracle VirtualBox 5.0.2 on my computer. I have created two virtual servers which contain Oracle Enterprise Linux 6.7 x86-64 and Oracle Database 12c, version: 12.1.0.2. The Oracle Golden Gate I installed is version: 12.1.2.1.
  • Source server: dbsrc
  • Stage server: stgdb
  • Target server: dbtgt
The stage and target databases reside on the same server for simplicity. In this blog I will focus on Oracle Golden Gate initial setup on both source database dbsrcand target database stgdb. The database dbtgt will be used as an example in my future blog on Oracle Data Integrator.
Source database dbsrc and target database stgdb
I downloaded the Oracle Golden Gate file:
121210_fbo_ggs_Linux_x64_shiphome.zip from http://otn.oracle.com. There are several download files to choose from. One has to choose the one corresponding to the relevant technology. In this case Oracle Golden Gate for Oracle Linux x86-64.

B.- Installing Oracle Golden Gate

I logged on source and target servers as oracle user that owns the software of Oracle Database and Oracle Golden Gate.
I moved the file 121210_fbo_ggs_Linux_x64_shiphome.zip to source and target server andunzipped the file.
The folder created on source and target servers is then: fbo_ggs_Linux_x64_shiphome
SourceServer
Then change directory to fbo_ggs_Linux_x64_shiphome/Disk1.
At this point one has to check that the following environment variables are set on source server:

- ORACLE_HOME = /db0/oracle/product/12.1.0.2/db_1
- ORACLE_SID = dbsrc

and on target server:

- ORACLE_HOME = /db0/oracle/product/12.1.0.2/db_1
- ORACLE_SID = stgdb

The images below show the installation of Oracle Golden Gate on source server and the same installation should be performed on target server.
Installation Oracle Golden Gate on source server
Press Next:
Installation - step 2 of 5
Specify the home of Oracle Golden Gate. Choose an Oracle_Home different from the one of the Oracle database and press Next:
Installation Step 3 of 5
Then press Install.
Installation Step 5 of 5
Press Close.
At this point the OGG software is installed on source and target servers.

C.- Configuring Oracle Golden Gate for initial setup

I will show here the initial configuration on source and target servers for initial extract and replicat. There are several steps to be performed on the source and target databases.

1.- Update LD_LIBRARY_PATH in the profile file on both source and target servers.

For example my file .bash_profile on source server looks like this:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
# Oracle Settings
export TMP=/tmp
export TMPDIR=$TMP
export ORACLE_HOSTNAME=srcdb.localdomain
export ORACLE_UNQNAME=dbsrc
export ORACLE_BASE=/db0/oracle
export ORACLE_HOME=$ORACLE_BASE/product/12.1.0.2/db_1
export ORACLE_GG_HOME=$ORACLE_BASE/product/12.1.2.1/ogg_1
export ORACLE_SID=dbsrc
export PATH=/usr/sbin:$PATH
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_GG_HOME:$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
And the .bash_profile on target server should look similar, but the variables ORACLE_UNQNAME and ORACLE_SID have to be set to stgdb to reflect the target database.

2. - Enabling Supplemental logging on source database dbsrc in order to log all transactions and loads. This step is not required for target database stgdb.

Log on source database as sys. I use Oracle SQLDeveloper which gives a nice graphical interface against the database:
SELECT supplemental_log_data_min, force_logging FROM v$database;
If the result is NO then run:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE FORCE LOGGING;
Then run again:
SELECT supplemental_log_data_min, force_logging FROM v$database;
The result should be YES now.
Then switch the log files:
ALTER SYSTEM SWITCH LOGFILE;
Alert sstem switch logfile


3.- Enable archivelog. The Oracle source database must have archivelog enabled. This step is not required for target database.

Log on source database dbsrc as sys and run:
SQL> archive log list;
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> archive log list;

4.- Create Oracle Golden Gate user on source and target databases:

Log on source and target databases as sys:
a.- Create tablespace for OGG user:
CREATE TABLESPACE ogg_data LOGGING
DATAFILE '/db0/oracle/oradata/dbsrc/ogg_data_01.dbf'
SIZE 1024M REUSE AUTOEXTEND ON NEXT 512M MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
Here I have changed the location of datafile on target server to:
DATAFILE '/db0/oracle/oradata/stgdb/ogg_data_01.dbf'
b.- Create Golden Gate user:
CREATE USER ogg_user IDENTIFIED BY oracle
DEFAULT TABLESPACE ogg_data
TEMPORARY TABLESPACE temp;
c.- Grant relevant privileges to user ogg_user:
GRANT CONNECT, RESOURCE TO ogg_user;
GRANT SELECT ANY DICTIONARY, SELECT ANY TABLE TO ogg_user;
GRANT CREATE TABLE TO ogg_user;
GRANT FLASHBACK ANY TABLE TO ogg_user;
GRANT EXECUTE ON dbms_flashback TO ogg_user;
GRANT EXECUTE ON utl_file TO ogg_user;
GRANT CREATE ANY TABLE TO ogg_user;
GRANT INSERT ANY TABLE TO ogg_user;
GRANT UPDATE ANY TABLE TO ogg_user;
GRANT DELETE ANY TABLE TO ogg_user;
GRANT DROP ANY TABLE TO ogg_user;
GRANT ALTER ANY TABLE TO ogg_user;
GRANT ALTER SYSTEM TO ogg_user;
GRANT LOCK ANY TABLE TO ogg_user;
GRANT SELECT ANY TRANSACTION to ogg_user;
ALTER USER ogg_user QUOTA UNLIMITED ON ogg_data;
d.- Authenticate the user ogg_user with Golden Gate package:
exec DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('ogg_user');
e.- Enable Golden Gate on both databases:
ALTER SYSTEM SET enable_goldengate_replication=TRUE;

5a.- Edit manager parameter on source server:

Go to Golden Gate home:
$ cd $ORACLE_GG_HOME 
Then run:
$ ./ggsci
Golden gate home
Then type:
ggsci > edit param mgr
Then the parameter manager file on source server should look like this:
PORT 7809
PurgeOldExtracts /db0/oracle/product/12.1.2.1/ogg_1/dirdat/* UseCheckPoints, MinKeepHours 48

5b.- Edit manager parameter on target server:

ggsci > info mgr
ggsci > edit param mgr
Then the parameter manager file on target server should look like this:
PORT 7809
Save the changes and then return to ggsci command interface.
Then run the following commands:
ggsci > stop mgr
ggsci > start mgr 
ggsci > info mgr detail
Edit manager parameter on target server


6.- Storing credentials on wallet. This step is performed on both source and target servers.

Run the following commands on Golden Gate interface ggsci. The connect string dbsrc below is the tnsnames of the source database.
ggsci > create wallet
ggsci > Add CredentialStore
ggsci > alter CredentialStore Add User ogg_user@dbsrc Password oracle Alias ogg_user
ggsci > info CredentialStore
Similarly the commands on Golden Gate interface ggsci on target server are:
ggsci > create wallet
ggsci > Add CredentialStore
ggsci > alter CredentialStore Add User ogg_user@stgdb Password oracle Alias ogg_user
ggsci > info CredentialStore
Storing credentials on wallet
Then we test the credentials. Run the following command on ggsci interface on both source and target servers:
ggsci > DBLogin UserIDAlias ogg_user
Successfully logged into database.
At this point the inital Oracle Golden Gate setup is completed and ready on source and target database servers.
On the next blogs I will cover examples of Oracle Golden Gate initial load and Oracle Data Integrator.

Sources:

*Photo: "GoldenGateBridge-001" by Rich Niewiroski Jr. - http://www.projectrich.com/gallery. Licensed under CC BY 2.5 via Wikimedia Commons

Wednesday, January 27, 2016

ALTER REPLICAT



ALTER REPLICAT

Use ALTER REPLICAT to change the attributes of a Replicat group that was created with the ADD REPLICAT command. Before using this command, stop Replicat by issuing the STOP REPLICAT command. If this is a coordinated Replicat group, the ALTER takes effect for all threads unless thethreadID option is used.
Note:
ALTER REPLICAT does not support switching from regular Replicat mode to coordinated mode. You must stop processes, make certain all of the en route data is applied to the target, roll the trail to a new trail, drop and recreate the Replicat group in coordinated mode, and then start the processes again.
Syntax
ALTER REPLICAT group_name[threadID], {
   ADD REPLICAT option [, ...] |
   INTEGRATED | NONINTEGRATED, CHECKPOINTTABLE owner.table 
}
[, CPU number]
[, PRI number]
[, HOMETERM device_name]
[, PROCESSNAME process_name]
group_name[threadID]
The name of the Replicat group or a thread of a coordinated Replicat that is to be altered. To specify a thread, use the full thread name, such asALTER REPLICAT fin003, EXTSEQNO 53. If a thread ID is not specified, the ALTER takes effect for all threads of the Replicat group.
ADD REPLICAT option
An ADD REPLICAT option. For a non-integrated Replicat, you can change the description or any service option that was configured with the ADD REPLICAT command, except for the CHECKPOINT and NODBCHECKPOINT options.
INTEGRATED
Switches Replicat from non-integrated mode to integrated mode. Transactions currently in process are applied before the switch is made. SeeAdministering Oracle GoldenGate for Windows and UNIX for the full procedure for performing the transition from non-integrated to integrated Replicat.
NONINTEGRATED, CHECKPOINTTABLE owner.table
(Oracle) Switches Replicat from integrated mode to non-integrated mode.
For CHECKPOINTTABLE, specify the owner and name of a checkpoint table. This table must be created with the ADD CHECKPOINTTABLE command before issuing ALTER EXTRACT with NONINTEGRATED.
See Administering Oracle GoldenGate for Windows and UNIX for the full procedure for performing the transition from integrated Replicat to non-integrated Replicat.
See Installing and Configuring Oracle GoldenGate for Oracle Database for more information about integrated Replicat.
CPU number
Valid for SQL/MX. Specifies the number of the CPU to be used for the process. Valid values are numbers 1 - 15 and -1 is default, which is assigned 1 higher than the last Manager started.
PRI number
Valid for SQL/MX. Specifies the Extract process priority. Valid values are numbers are 1 - 199 and -1 is the default, and is the same as the manager process priority.
HOMETERM device_name
Valid for SQL/MX. Specifies the name of the device to be used and must be a terminal or process. It can be entered in either Guardian $ or OSS/G/xxxxx form. The default is $zhome or the current session HOMETERM when $zhome is not defined.
PROCESSNAME process_name
Valid for SQL/MX. Specifies the name of the process as alphanumeric string up to five characters and can be entered in either Guardian $ or OSS/G/xxxxx form. The default is a system generated process name.
Examples
Example 1   
ALTER REPLICAT finance, EXTSEQNO 53
Example 2   
ALTER REPLICAT finance, EXTRBA 0
Example 3   
ALTER REPLICAT finance, BEGIN 2011-01-07 08:00:00
Example 4   
ALTER REPLICAT finance, INTEGRATED
Example 5   
ALTER REPLICAT finance, NONINTEGRATED, CHECKPOINTTABLE ogg.checkpt
Example 6   
ALTER REPLICAT fin001, EXTSEQNO 53

Example 7   
The following alters a Replicat on a SQL/MX NonStop platform.
ALTER REPLICAT reptcp, CPU 3, PRI 150, HOMETERM /G/zhome,  PROCESSNAME default

Tuesday, January 26, 2016

OGG Re-initiate with SCN


How to import with flashback_SCN :
==========================


> select scn_to_timestamp(8697520) from dual;

> select timestamp_to_scn('10-JUN-14 10.50.55.000000000 AM') from dual;

My workaround is ,

 I take the backup dump from source machine with flashback_scn (10616719792607). My source machine is running on .
After one day ,  I import it to the target pc and replicate database from source to target end .


Solution :

  On source ,

        - delete all trail files and all extract : delete extract *

        - Add the extract again

        - take the timestamp of the scn :

                   select scn_to_timestamp(10616719792607) from dual;

             output :   2016-01-25 17:12:41.000000   << should be 24 Format . (YYYY-MM-DD HH:MM:SS )

     

   On Target ,

               - delete replicate (REP3) as well as checkpoint

                - DBLOGIN USERID ggs_owner, PASSWORD ggs_owner
                   delete CHECKPOINTTABLE GGS_OWNER.CHKPTAB

                   ADD CHECKPOINTTABLE GGS_OWNER.CHKPTAB
                   ADD REPLICAT rep3, EXTTRAIL /u01/oracle/ggs/dirdat2/rt


now Start the service :

        On Source :
                       ALTER EXTRACT ext1, TRANLOG, BEGIN 2016-01-25 17:12:41.000000
                        START ext1 ;

                        START DPUMP ; // No need to mention date/time .



        On Target :

                       start replicat REP3, aftercsn 10616719792607




Check Status :
==============

           
Skipping a transaction, or starting at or after a CSN, might cause Replicat to start more slowly
than normal, depending on how much data in the trail must be read before arriving at the
appropriate transaction record. To view the startup progress, use the SEND REPLICAT
command with the STATUS option. To omit the need for Replicat to read through transactions
that ultimately will be skipped, you can use the ATCSN or AFTERCSN option when starting Extract
and the data pumps, so that those transactions are omitted from the trail. See "START EXTRACT".


GGSCI (testpbl.pbl.com) 1> send rep3 status

Sending STATUS request to REPLICAT REP3 ...
  Current status: At EOF
                  Searching for START AFTERCSN 10616719792607
                                   Current CSN Unknown                        <<<<
  Sequence #: 0
  RBA: 0
  0 records in current transaction




After reinitiate:
=================

GGSCI (testpbl.pbl.com) 1> send rep3 status

Sending STATUS request to REPLICAT REP3 ...
  Current status: At EOF
  Sequence #: 0
  RBA: 5347
  0 records in current transaction
 
                     
                     

Friday, January 22, 2016

M1: Oracle GoldenGate – Monitoring GoldenGate

oracle doc
PT 

---------------------------

My experience is that when the checkpoint is increasing, that there is a transaction executing. For example if someone has updated a million rows and then committed, while replicat is processing the million rows the checkpoint will grow until it has completed with all the rows in the transaction. Also, could be the transaction isn't large, but is blocked by a lock or archiver error or something like that...
Regards, Paul
-----------------------------------

GGSCI (devu007) 21> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     DPUMP       00:00:00      00:00:04
EXTRACT     RUNNING     EXT1        00:00:00      00:00:09
EXTRACT     RUNNING     EXT2        00:00:00      00:00:07
EXTRACT     ABENDED     GAVIN       00:00:00      73:29:25
EXTRACT     STOPPED     WORKPLAN    00:00:00      191:44:18
REPLICAT    RUNNING     MYLOAD2     00:00:00      00:00:09
REPLICAT    RUNNING     MYREP       00:00:00      00:00:08


Find the run status of a particular process

GGSCI (devu007) 23> status manager

Manager is running (IP port devu007.7809).

GGSCI (devu007) 24> status extract ext1
EXTRACT EXT1: RUNNING


Detailed information of a particular process


GGSCI (devu007) 6> info extract ext1, detail

EXTRACT    EXT1      Last Started 2010-02-19 11:19   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:02 ago)
Log Read Checkpoint  Oracle Redo Logs
                     2010-02-26 10:45:18  Seqno 786, RBA 44710400

  Target Extract Trails:

  Remote Trail Name                                Seqno        RBA     Max MB

  /u01/oracle/software/goldengate/dirdat/lt            2      55644         10

  Extract Source                          Begin             End

  /u02/oradata/apex/redo03.log            2010-02-19 11:13  2010-02-26 10:45
  /u02/oradata/apex/redo02.log            2010-02-19 11:04  2010-02-19 11:13
  /u02/oradata/apex/redo02.log            2010-02-18 10:42  2010-02-19 11:04
  Not Available                           * Initialized *   2010-02-18 10:42


Current directory    /u01/oracle/software/goldengate

Report file          /u01/oracle/software/goldengate/dirrpt/EXT1.rpt
Parameter file       /u01/oracle/software/goldengate/dirprm/ext1.prm
Checkpoint file      /u01/oracle/software/goldengate/dirchk/EXT1.cpe
Process file         /u01/oracle/software/goldengate/dirpcs/EXT1.pce
Stdout file          /u01/oracle/software/goldengate/dirout/EXT1.out
Error log            /u01/oracle/software/goldengate/ggserr.log

Monitoring an Extract recovery


GGSCI (devu007) 35> send extract ext1 status

Sending STATUS request to EXTRACT EXT1 ...


  EXTRACT EXT1 (PID 1925238)
  Current status: Recovery complete: At EOF
  Sequence #: 786
  RBA: 40549888
  Timestamp: 2010-02-26 09:59:57.000000

  Output trail #1
  Current write position:
  Sequence #: 2
  RBA: 55644
  Timestamp: 2010-02-26 09:59:54.337574
  Extract Trail: /u01/oracle/software/goldengate/dirdat/lt


Monitoring processing volume - Statistics of the operations processed

GGSCI (devu007) 33> stats extract ext1

Sending STATS request to EXTRACT EXT1 ...

Start of Statistics at 2010-02-26 09:58:27.

DDL replication statistics (for all trails):

*** Total statistics since extract started     ***
        Operations                                  19.00
        Mapped operations                            2.00
        Unmapped operations                          9.00
        Other operations                             8.00
        Excluded operations                         17.00

Output to /u01/oracle/software/goldengate/dirdat/lt:

Extracting from GGS_OWNER.GGS_MARKER to GGS_OWNER.GGS_MARKER:

*** Total statistics since 2010-02-19 11:21:03 ***

        No database operations have been performed.

*** Daily statistics since 2010-02-26 00:00:00 ***

        No database operations have been performed.

*** Hourly statistics since 2010-02-26 09:00:00 ***

        No database operations have been performed.

*** Latest statistics since 2010-02-19 11:21:03 ***

        No database operations have been performed.

Extracting from MONITOR.WORK_PLAN to MONITOR.WORK_PLAN:

*** Total statistics since 2010-02-19 11:21:03 ***
        Total inserts                                4.00
        Total updates                               46.00
        Total deletes                                0.00
        Total discards                               0.00
        Total operations                            50.00

*** Daily statistics since 2010-02-26 00:00:00 ***
        Total inserts                                0.00
        Total updates                               16.00
        Total deletes                                0.00
        Total discards                               0.00
        Total operations                            16.00

*** Hourly statistics since 2010-02-26 09:00:00 ***

        No database operations have been performed.

*** Latest statistics since 2010-02-19 11:21:03 ***
        Total inserts                                4.00
        Total updates                               46.00
        Total deletes                                0.00
        Total discards                               0.00
        Total operations                            50.00

End of Statistics.


View processing rate - can use 'hr','min' or 'sec' as a parameter


GGSCI (devu007) 37> stats extract ext2 reportrate hr

Sending STATS request to EXTRACT EXT2 ...

Start of Statistics at 2010-02-26 10:04:46.

Output to /u01/oracle/ggs/dirdat/cc:

Extracting from SH.CUSTOMERS to SH.CUSTOMERS:

*** Total statistics since 2010-02-26 09:29:48 ***
        Total inserts/hour:                          0.00
        Total updates/hour:                      95258.62
        Total deletes/hour:                          0.00
        Total discards/hour:                         0.00
        Total operations/hour:                   95258.62

*** Daily statistics since 2010-02-26 09:29:48 ***
        Total inserts/hour:                          0.00
        Total updates/hour:                      95258.62
        Total deletes/hour:                          0.00
        Total discards/hour:                         0.00
        Total operations/hour:                   95258.62

*** Hourly statistics since 2010-02-26 10:00:00 ***

        No database operations have been performed.

*** Latest statistics since 2010-02-26 09:29:48 ***
        Total inserts/hour:                          0.00
        Total updates/hour:                      95258.62
        Total deletes/hour:                          0.00
        Total discards/hour:                         0.00
        Total operations/hour:                   95258.62

End of Statistics.


View latency between the records processed by Goldengate and the timestamp in the data source


GGSCI (devu007) 13>  send extract ext2, getlag

Sending GETLAG request to EXTRACT EXT2 ...
Last record lag: 3 seconds.
At EOF, no more records to process.


GGSCI (devu007) 15> lag extract ext*

Sending GETLAG request to EXTRACT EXT1 ...
Last record lag: 1 seconds.
At EOF, no more records to process.

Sending GETLAG request to EXTRACT EXT2 ...
Last record lag: 1 seconds.
At EOF, no more records to process.
Viewing the GoldenGate error log as well as history of commands executed and other events
We can use the editor depending on operating system – vi on Unix for example to view the ggserr.log file which is located at the top level GoldenGate software installation directory.
We can also use the GGSCI command VIEW GGSEVT as well.
View the process report
Every Manager, Extract and Replicat process will generate a report file at the end of each run and this
report can be viewed to diagnose any problems or errors as well as view the parameters used, the environment variables is use, memory consumption etc
For example:
GGSCI (devu007) 2> view report ext1

GGSCI (devu007) 2> view report rep1

GGSCI (devu007) 2> view report mgr

Information on Child processes started by the Manager


GGSCI (devu007) 8> send manager childstatus

Sending CHILDSTATUS request to MANAGER ...

Child Process Status - 6 Entries

ID     Group     Process    Retry Retry Time            Start Time
----  --------  ----------  ----- ------------------    -----------
   0     EXT1     1925238      0  None                 2010/02/19 11:07:54
   1    DPUMP     2195496      0  None                 2010/02/19 11:08:02
   2   MSSQL1      422034      0  None                 2010/02/22 13:54:59
   4    MYREP     1302702      0  None                 2010/02/23 09:08:34
   6  MYLOAD2     1200242      0  None                 2010/02/23 11:05:01
   7     EXT2     2076844      0  None                 2010/02/26 08:29:22