...
The supplemental log groups created by Dbvisit Replicate start with a G and then a random hex string: G575B4B0CC2E511E2A20CB8ADB3813
| Note |
|---|
|
...
Please see variable _ADD_SUPLOG in Internal Variables on the default supplemental log behaviour and how to modify this.
How Dbvisit Replicate works with supplemental logging
Dbvisit Replicate does not use primary key definition directly. It uses all the columns that are supplementally logged by Oracle.
When a table is prepared, Dbvisit Replicate issues: alter table xx.xx add supplemental logging (primary key) columns.
This enables the following Oracle behaviour:
- If there is an enabled PK, it will add supplemental logging to only the columns of the PK
- If there is no PK, but there is unique key that is guaranteed to be unique (none of the columns are NULL) - use columns of this UK
- As last resort, log all columns (except those that can never be logged - LOBs, LONGs, nested tables etc.)
This means that as long as there is a way on how to uniquely identify rows, replication will work as expected. Oracle will supplementally log all the columns needed.
In certain cases such as filtering, you must ensure that that column is always present in the redo logs.
Here is an example of a conditional user-defined supplemental log group for jobcode and sdate columns where ID is primary key.
| No Format | ||
|---|---|---|
| ||
ALTER TABLE AVI.SAMPLE
ADD SUPPLEMENTAL LOG GROUP sample_jobcode (ID,JOBCODE,SDATE) ALWAYS; |
The ALWAYS keyword is required to create an unconditional supplemental log group to ensure the column(s) in the filter condition are always logged in the redo log, regardless of whether they appear in the DML statement.