Professional Documents
Culture Documents
DBA - Oracle Golden Gate 12 - Bidirectional Replication - Activ
DBA - Oracle Golden Gate 12 - Bidirectional Replication - Activ
More
Next Blog
Create Blog
DBA
Home
Scripts
Oracle Database
San deep
Follow
Blog Archive
2015 (1)
2014 (46)
December (1)
Oracle Golden Gate 12
Bidirectional replication ...
September (3)
August (1)
July (4)
June (14)
May (23)
Pages
Home
Scripts
Oracle Database
f.
LAG
Oracle GoldenGate is an Asynchronous solution. It is possible that there may be LAG at times depending on the transaction volume or
network issue or when processes are down. This LAG can cause data inconsistencies. To avoid this situation make sure that there is
very little or no LAG or have proper SLAs.
g. OGG CONFLICTS
Conflicts are very common and born to happen in Bi-Directional Replication as Oracle GoldenGate is an Asynchronous solution.
We will see the following four different conflicts in OGG replication.
i. CONFLICT FOR INSERTS
ii. CONFLICT FOR UPDATES
iii. CONFLICT FOR DELETES
iv. CONFLICT FOR UPDATE/DELETE
h. Timestamp Column
A Primary Key alone is NOT sufficient to handle conflicts. We must use another column or combination of columns to handle conflicts.
A Timestamp column stores the commit time of the DML. This column can be populated with the help of Application or a Trigger. We
will make use of timestamp column along with the Primary Key column to identify and resolve conflicts.
Make sure every table part of replication have a column with timestamp or date data type.
i. Conflict Detection And Resolution
Start with OGG version 11.2, Oracle has provided built-in CDRs. These built-in CDRs can be used in OGG 11.2. We will use
RESOLVECONFLICT parameter of MAP statement to resolve conflicts.
3. Limitations
Bi-Directional Replication works only on Windows, UNIX/Linux.
CDR works with numeric, date/timestamp colums and char/varchar2 only.
BATCHSQL is not supported in Bi-Directional Replication.
LOB , Abstract data type (ADT) and User Defined data type (UDT) are NOT supported with CDR.
4. ENVIRONMENT DETAILS
Source
Server IP: 10.10.1.10
Database Name: ggsource
Database Version: 12.1.0.2.1
GG version: 12.1.2.1.0
Backup and
Recovery
Target
Server IP : 10.10.1.20
Database Name: ggtarget
Database Version: 12.1.0.2.1
GG version: 12.1.2.1.0
1.
2.
3. On both source and target servers, create directories to store the Golden gate.
[oracle@TEST01 u02]$ mkdir p /u02/app/oracle/product/gg
[oracle@TEST01 u02]$ chmod 775 /u02/app/oracle/product/gg
[oracle@TEST02 u02]$ mkdir p /u02/app/oracle/product/gg
[oracle@TEST02 u02]$ chmod 775 /u02/app/oracle/product/gg
4.
8.
Now login to Golden gate and create subdirectories on both source and target servers.
9.
c)
d)
e)
f)
Now, we need to ensure redo and archive logs are having supplemental log data.
Now, switch the log files.
SQL> alter system switch logfile;
g) Confirm from the database whether supplemental logging is enabled.
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
-------YES
h) The o/p should be either YES or IMPLICIT.
10. Create tablespace and user for Golden Gate administrator user.
create tablespace ggtest datafile '/u02/app/oracle/oradata/ggsource/ggtest01.dbf' size 10M autoextend on next 5M;
create user gg_admin identified by gg_admin default tablespace ggtest;
11. Give necessary privileges to the user in order to replicate particular table.
grant connect,resource to gg_admin;
grant select any table,select any dictionary to gg_admin;
grant create table to gg_admin;
grant execute on dbms_flashback to gg_admin;
grant execute on utl_file to gg_admin;
grant insert on< schema>.<table_name> to gg_admin; ( insert privileges to the table to be replicated)
12. Go to Golden Gate Installed location (in our scenario /u02/app/oracle/product/gg) and then run the following Golden Gate
inbuild scripts for creating all necessary objects to support DDL replication.
SQL>@marker_setup.sql
SQL>@DDL_setup.sql
SQL>@GGS/role_setup.sql
SQL>grant GGS_GGSUSER_ROLE to gg_admin;
SQL>@DDL_enable.sql
SQL> @marker_setup.sql
Marker setup script
You will be prompted for the name of a schema for the Oracle GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.
Enter Oracle GoldenGate schema name:GG_ADMIN
You will be prompted for the name of a schema for the Oracle GoldenGate database objects.
NOTE: For an Oracle 10g source, the system recycle bin must be disabled. For Oracle 11g and later, it can be enabled.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.
Enter Oracle GoldenGate schema name:gg_admin
Working, please wait ...
Spooling to file ddl_setup_spool.txt
Checking for sessions that are holding locks on Oracle Golden Gate metadata tables ...
Check complete.
Error
Script complete.
SQL> @role_setup.sql
GGS Role setup script
This script will drop and recreate the role GGS_GGSUSER_ROLE
To use a different role name, quit this script and then edit the params.sql script to change the gg_role parameter to the preferred
name. (Do not run the script.)
You will be prompted for the name of a schema for the GoldenGate database objects.
NOTE: The schema must be created prior to running this script.
NOTE: Stop all DDL replication before starting this installation.
Enter GoldenGate schema name:gg_admin
Wrote file role_setup_set.txt
PL/SQL procedure successfully completed.
14. Now, we need to find the tables which need to be replicated. For this, we will create a user GGBI and create a table under GGBI.
On source and target, create a user as below.
SQL> create user ggbi identified by ggbi;
On Source and target database, create a table GGEMP under GGBI.
SQL> create table ggemp
(emp_id number,
emp_name_name varchar2(20),
mgr number,
last_dml timestamp default systimestamp);
SQL> alter table ggemp add constraint pk_ggemp primary key (emp_id) ;
Table altered.
SQL> grant all on ggemp to gg_admin;
Grant succeeded.
15. Create the extract (EXT1) and data pump (DPUMP1) on Site GGSOURCE
GGSCI (TEST01) 5> add extract ext1 tranlog begin now
EXTRACT added.
17. On GGTARGET, create the extract (EXT2) and data pump (DPUMP2)
GGSCI (TEST02) 3> add extract ext2 tranlog begin now
EXTRACT added.
EXTRACT dpump2
USERID gg_admin, PASSWORD gg_admin
RMTHOST 10.10.1.10, MGRPORT 7809, TCPBUFSIZE 100000
RMTTRAIL /u02/app/oracle/product/gg/dirdat/ad
PASSTHRU
TABLE ggbi.ggemp;
REPLICAT rep1
ASSUMETARGETDEFS
USERID gg_admin, PASSWORD gg_admin
DISCARDFILE /u02/app/oracle/product/gg/discard/discardrep1.txt, append,
MAP ggbi.ggemp, TARGET ggbi.ggemp;
19. On both GGSOURCE and GGTARGET sites , add trandata .
GGSCI (TEST01) 12> dblogin userid gg_admin,password gg_admin
Successfully logged into database.
GGSCI (TEST01 as gg_admin@ggsource) 14> add trandata ggbi.ggemp cols(emp_name_name,mgr,last_dml)
Logging of supplemental redo data enabled for table GGBI.GGEMP.
TRANDATA for scheduling columns has been added on table 'GGBI.GGEMP'.
GGSCI (TEST01 as gg_admin@ggsource) 15> info trandata ggbi.ggemp
Logging of supplemental redo log data is enabled for table GGBI.GGEMP.
Columns supplementally logged for table GGBI.GGEMP: EMP_ID, EMP_NAME_NAME, LAST_DML, MGR.
Status
Group
MANAGER RUNNING
EXTRACT RUNNING DPUMP1
00:00:00
00:00:00
EXTRACT RUNNING EXT1
00:00:00
00:00:01
REPLICAT STOPPED REP1
00:00:00
00:00:44
21. Start the Extract and Data Pump process in GGTARGET
GGSCI (TEST02 as gg_admin@ggtarget) 13> start extract ext2
Sending START request to MANAGER ...
EXTRACT EXT2 starting
Status
Group
MANAGER RUNNING
EXTRACT RUNNING DPUMP2
00:00:00
00:13:38
EXTRACT RUNNING EXT2
00:00:00
00:00:00
REPLICAT STOPPED REP2
00:00:00
00:17:21
Status
Group
MANAGER RUNNING
EXTRACT RUNNING DPUMP1
00:00:00
00:00:08
EXTRACT RUNNING EXT1
00:00:00
00:00:06
REPLICAT RUNNING REP1
00:00:00
00:00:04
23. On GGTARGET , add checkpointtable and start the replicat (REP2) process .
GGSCI (TEST02 as gg_admin@ggtarget) 22> add checkpointtable gg_admin.ckptab
Successfully created checkpoint table gg_admin.ckptab.
GGSCI (TEST02 as gg_admin@ggtarget) 23> start replicat rep2
Sending START request to MANAGER ...
REPLICAT REP2 starting
Status
Group
MANAGER RUNNING
EXTRACT RUNNING DPUMP2
00:00:00
00:00:07
EXTRACT RUNNING EXT2
00:00:00
00:00:05
REPLICAT RUNNING REP2
00:00:00
00:00:02
Test Scenario 1
On GGSOURCE, inserted a row and found that the row is replicated on GGTARGET.
SQL> select name from v$database;
NAME
--------GGSOURCE
SQL> insert into ggemp values (1,'goldengate',100,sysdate);
1 row created.
SQL> commit;
Commit complete.
Test Scenario 2
On GGTARGET, we are inserting a row , this row should be replicated on GGSOURCE.
SQL> insert into ggemp values (2,'oracle',101,sysdate);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from ggemp;
EMP_ID EMP_NAME_NAME
MGR LAST_DML
---------- -------------------- ---------- --------------------------------------------------------------------------1 goldengate
100 17-NOV-14 11.50.24.659428 PM
2 oracle
101 17-NOV-14 11.50.55.909332 PM
SQL> select name from v$database;
NAME
--------GGSOURCE
SQL> select * from ggemp;
EMP_ID EMP_NAME_NAME
MGR LAST_DML
---------- -------------------- ---------- --------------------------------------------------------------------------1 goldengate
100 17-NOV-14 11.50.24.659428 PM
2 oracle
101 17-NOV-14 11.50.55.909332 PM
TRANLOGOPTIONS EXCLUDEUSER <GGUSER> - To prevent capture of SQL that is applied by Replicat to other database in Bidirectional replication. This will avoid all transactions generated by GGUSER.
GETBEFORECOLS This parameter is used in Extract file for specific columns to capture the before image we want to capture
and written to trail file upon update or delete operation.
KEYINCLUDING It specifies to capture before image of the primary key and also the specified column/s
On Replicat side, we need 2 parameters,
COMPARECOLS It specifies the columns that replicat uses to deted update or delete conflicts.
RESOLVECONFLICT This will be used in MAP statement to different resolutions for different conflict resolutions.
In our setup, we have 2 databases ( GGSOURCE and GGTARGET )and we need to have the changes to be replicated from
both the sites.
Data Pump and Extract Trail file setup remains same as per the setup for Active-Active replication without CDR.
On GGSOURCE
1.
4.
Now, we have implemented Bi-directional replication with conflict detection and the updated row should have latest value
using DML_TIMESTAMP and in case of any row missing, then overwrite or any row is missing, it should discard while deleting.
Test Scenario 3
Let us update the row from both GGSOURCE and GGTARGET with different values and see the latest values are updated.
On GGTARGET, I am updating the MGR column from 106 to 108 and in GGSOURCE, I am updating from 106 to 107 at same time,
the values in both the database should be 108 as GGTARGET is having latest timestamp.
On GGSOURCE,
SQL> select * from ggemp;
EMP_ID EMP_NAME_NAME
MGR LAST_DML
---------- -------------------- ---------- --------------------------------------------------------------------------1 goldengate
100 17-NOV-14 11.50.24.659428 PM
2 oracle
102 18-NOV-14 05.14.21.405412 PM
3 ggtest
106 18-NOV-14 06.06.54.695195 PM
On GGTARGET
SQL> select * from ggemp;
EMP_ID EMP_NAME_NAME
MGR LAST_DML
---------- -------------------- ---------- --------------------------------------------------------------------------1 goldengate
100 17-NOV-14 11.50.24.659428 PM
2 oracle
102 18-NOV-14 05.14.21.405412 PM
3 ggtest
106 18-NOV-14 06.06.54.695195 PM
SQL> update ggemp set mgr=108 where emp_id=3;
1 row updated.
SQL> commit;
Commit complete.
Result
Now, the output of GGSOURCE and GGTARGET shows the following.
Test Scenario 4
Now, I am going to delete same record from both the sites.
a.
Initially, I am deleting from GGSOURCE and GGTARGET at same time and commiting.
On GGSOURCE
SQL> select * from ggemp;
EMP_ID EMP_NAME_NAME
MGR LAST_DML
---------- -------------------- ---------- --------------------------------------------------------------------------1 goldengate
100 17-NOV-14 11.50.24.659428 PM
4 ggoracle
110 18-NOV-14 06.42.20.953194 PM
3 ggtest
108 18-NOV-14 06.07.43.392792 PM
SQL> delete from ggemp where emp_id=4;
1 row deleted.
SQL> commit;
Commit complete.
On GGTARGET
SQL> delete from ggemp where emp_id=4;
1 row deleted.
SQL> commit;
Now, since GGSOURCE timestamp is proceeded earlier and deleted the record, the other delete statement from GGTARGET got
discarded.
This can be seen in the trail file.
000000: 67 67 6f 72 61 63 6c 65
|ggoracle
6 comments:
Murthy June 24, 2015 at 6:42 AM
Hi
Have you performed Initial load before the above steps. or you have cloned source database to target has your initial load?
i am getting error in my target side stating table doesnot exist. and replicat is getting abended.
I remember in 11 version golden gate We did initial load first before started our processes.
kindly confirm
Reply
Reply
Comment as:
Publish
Newer Post
Select profile...
Preview
Home
Subscribe to: Post Comments (Atom)
Older Post