0% found this document useful (0 votes)
56 views5 pages

Enabling Supplemental Logging in OGG

Uploaded by

irum.waqas80
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
56 views5 pages

Enabling Supplemental Logging in OGG

Uploaded by

irum.waqas80
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Enabling Supplemental Logging at DB Level:

SQL>ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

OR
SQL>alter database add supplemental log data (all) columns;

To ensure same has been enabled query V$Database view.

By default, only changed column is logged into transaction logs for any
operations. Normally, this means that primary key columns are not logged
during an update/delete operation. However, Replicat requires the extra
column(primary key/Unique Key columns) in order to apply the
update/delete on the target system. The ADD TRANDATA command in
GGSCI is used to cause Oracle to log extra column in logs for all
transactions on a table.

For enabling Table level Supplemental logging, Database level


supplemental logging is required. Consider DB level supplemental logging
as a gateway to enable supplemental logging at the table level.

Enabling Supplemental Logging at Table Level:


GGSCI>dblogin userid c##gguser@pdb1,password *****

Note: For enabling supplemental logging at table level dblogin to the


pluggable database is required if database architecture is Multitenant.

GGSCI>ADD TRANDATA pdb1.ggtraining1.dept1

The above command at GGSCI level is equivalent at database level as


below depending on supplemental logging has to be enabled on primary
key/Unique key for all columns

SQL> ALTER TABLE “ggtraining1”.”DEPT1″ ADD SUPPLEMENTAL LOG


DATA(PK|UK|ALL) columns;
ADD TRANDATA automatically adds supplemental logging for the table
based on table’s primary key or if that’s missing, using any unique key
constraints defined for that table.

Below is the order of columns in which Supplemental logging is enabled at


table level:

1. Primary Key
2. Unique Key
3. All columns

Once supplemental logging is enabled, along with column which has been
updated/changed an extra column will be logged into redo logs so that a
row could be uniquely identified. Here it could be either of the one
mentioned as above.

If you enable only table-level supplemental logging without database level


then Oracle will not capture all changes.

What If Table doesn’t have Primary Key/Unique Key?


If the table does not have either a primary key or a unique key constraint
defined, then ADD TRANDATA will automatically add supplemental logging
based on sequence mentioned above. Hence in absence of both
Supplemental logging will be enabled on all columns of a table.

Please note it will increase the size of the redo logs and the trail files as
well. More importantly, if you are applying a change on the target database
using all the columns as the key then the DML ( be it an update or a delete
operation) will not be efficient and will cause your REPLICAT to lag behind.

You might need to sit with the application team to find out what key could
be defined for that table.

You can enable supplemental logging based on columns defined by


Application team on a particular object: You can use the following syntax to
ensure only those columns are used to add supplemental logging.
ADD TRANDATA <table name>, COLS (list of column names), NOKEY

Please note the usage of “NOKEY” , usually if you don’t use “NOKEY” and
you try using only “COLS” then you will get an error saying that the
columns you define in “COLS” are already used because by default ADD
TRANDATA adds supplemental logging for all the columns if there is no
primary key defined as stated earlier.

Also, ensure the target database has indexes defined on the columns in
question.

=============================================
============
Supplemental logging must be enabled at database level regardless of the
number of tables to replicate using Oracle GoldenGate.
With supplemental logging enabled on table level (what is required for
OGG, just supplemental logging on database level is not enough),
additionally all unique keys/primary keys will be written to the logs, so not
only the modified values (like in case of an update) - plus few more bytes
for internal information.

Worst case are tables without keys as then all rows will be written. So it
depends on the table design in the source DB, how much additional space
is needed for the logs.
If you have many key values per table, you will need more space as well.

Supplemental logging adds information that uniquely identifies the row in


the redo logs. The presence or absence of a primary key or unique index
can affect supplemental logging as follows:
If the table has a primary key or just one unique index, the amount of
information added to the redo log during supplemental logging is minimal.
If the table does not have a primary key or a unique index, supplemental
logging will automatically log all scalar values for each row to the redo
logs.
Without knowing the complete design and the complete usage (how often
are there inserts/updates/deletes for each table), we cannot give any
estimation except 'you need more space'. You may contact Oracle
Consulting team which can assist you in configuration of Oracle
GoldenGate as per your requirement and application/DB design.

Best approach is probably to have a rough estimation based on the unique


keys and tables without keys in the source, add some additional space to
the estimated ratio, then to enable supplemental logging and to monitor
carefully the space usage for some time.
Prior to extracting data from the Oracle logs, it is necessary to issue the
ADD TRANDATA commands via GGSCI. This requires a DBLOGIN:

By default, Oracle only logs changed columns for update operations.


Normally, this means that primary key columns are not logged during an
update operation. However, REPLICAT requires the primary key columns in
order to apply the update on the target system. The ADD TRANDATA
command in GGSCI is used to cause Oracle to log primary key columns for
all updates. To add supplemental log data, issue the following commands
on Unix. Table names may be wild carded. All tables that will have
captured data must have the TRANDATA added.

GoldenGate requires adding Supplemental Logging at the Table Level,


regardless of the Database Supplemental setting, due to issues with
Multiple Unique Keys and/or lack of Keys.

It is highly recommended to use "ADD TRANDATA" under the GGSCI


interface. If using the SQL command to add Supplemental Logging at the
Table Level, ALL the keys should be included (ex. 2 separate Unique Keys
are all required).

To turn on supplemental logging at the table level, you can execute this
command:
alter table <table_name> add supplemental log group ggs_mytab
(<column_name>, <column_name>) always;

(Note: You must have the ALTER TABLE privilege to execute the above sql
statement.)

Or you can turn on supplemental logging through GGSCI with this


command:

GGSCI> dblogin userid <user>, password <pw>

GGSCI> add trandata <schema>.<table>


NOTE: GoldenGate users should not issue the ALTER
TABLE schema.table ADD SUPPLEMENTAL LOG ... statement on the Oracle
database, as this will by-pass any specific options that GoldenGate may
use.

You might also like