OGG Parameter for Exception !!!

DISCARDFILE :
Valid for Extract and Replicat
Use the DISCARDFILE parameter to generate a discard file to which GoldenGate can log records that it cannot process. Records can be discarded for several reasons. For example,
a record is discarded if the underlying table structure changed since the record was written to the trail. You can use the discard file to help you identify the cause of processing errors. Each entry in the discard file contains the discarded record buffer and an error code indicating the reason. GoldenGate creates the specified discard file in the dirrpt subdirectory of the GoldenGate installation directory. You can view it with a text editor or by using the following command in GGSCI.

VIEW REPORT
Where: is the fully qualified name of the discard file.
To prevent having to perform manual maintenance of discard files, use either the PURGE or APPEND option. Otherwise, you must specify a different discard file name before starting
each process run, because GoldenGate will not write to an existing discard file. To set an upper limit for the size of the file, use either the MAXBYTES or MEGABYTES option. If
the specified size is exceeded, the process will abend. Default By default, GoldenGate does not generate a discard file.

DISCARDROLLOVER:
Valid for Extract and Replicat
Use the DISCARDROLLOVER parameter to set a schedule for aging discard files. For long or continuous runs, setting an aging schedule prevents the discard file from filling up and
causing the process to abend, and it provides a predictable set of archives that can be included in your archiving routine.
When the DISCARDROLLOVER age point is reached, a new discard file is created, and old files are renamed in the format of ., where:
? is the name of the Extract or Replicat group
? is a number that gets incremented by one each time a new file is created, for
example: myext0.dsc, myext1.dsc, myext2.dsc, and so forth.
You can specify a time of day, a day of the week, or both. Specifying just a time of day (AT option) without a day of the week (ON option) generates a discard file at the specified time every day.
Default Disabled. No rules specified.

REPERROR:
Use REPERROR to specify an error and a response that together control how Replicat responds to the error when executing the MAP statement. You can use REPERROR at the MAP level to override and supplement global error handling rules set with the REPERROR parameter. Multiple REPERROR statements can be applied to the same MAP statement to
enable automatic, comprehensive management of errors and interruption-free replication processing.
DEFAULT Sets a global response to all errors except those for which explicit REPERROR statements are specified.

GETDELETES | IGNOREDELETES:
Valid for Extract and Replicat
Use the GETDELETES and IGNOREDELETES parameters to control whether or not GoldenGate processes delete operations. These parameters are table-specific. One parameter remains in effect for all subsequent TABLE or MAP statements, until the other parameter is encountered.

GETUPDATES | IGNOREUPDATES:
Valid for Extract and Replicat
Use the GETUPDATES and IGNOREUPDATES parameters to control whether or not GoldenGate processes update operations. The parameters are table-specific. One parameter remains in effect for all subsequent TABLE or MAP statements, until the other parameter is encountered.

GETINSERTS | IGNOREINSERTS:
Valid for Extract and Replicat
Use the GETINSERTS and IGNOREINSERTS parameters to control whether or not insert operations are processed by GoldenGate. The parameters are table-specific. One parameter remains in effect for all subsequent TABLE or MAP statements, until the other parameter is encountered.

Update the parameter file on target as
edit params
REPLICAT rcreator
SOURCEDEFS /u01/app/oracle/product/goldengate/dirdat/defecreator
DISCARDFILE /u01/app/oracle/product/goldengate/dirdat/creator_err, purge
DISCARDROLLOVER ON saturday
USERID goldengate, PASSWORD AACAAAAAAAAAAAKAPATACEHBIGQGCFZCCDIGAEMCQFFBZHVC, ENCRYPTKEY default
REPERROR (DEFAULT, DISCARD)
IGNOREDELETES
IGNOREUPDATES
GETINSERTS
MAP meditate.life, TARGET CONSCIOUSNESS.tenure, &
COLMAP (PERSON_ID=HUMAN_ID, &
INITIALNAME=FIRSTNAME, &
ENDNAME=LASTNAME, &
BIRTH_DATE=DATE_OF_BITH, &
AGE_AT_DEATH=AGE_AT_TIME_OF_DEATH, &
DEED_ID_AT_DEATH=DEED_ID_AT_TIME_OF_DEATH), &
KEYCOLS (PERSON_ID, INITIALNAME,ENDNAME);

Now stop and start the replicat on target as:

GGSCI (goldengate) 9> stop replicat RCREATOR

Sending STOP request to REPLICAT RCREATOR ...
Request processed.
GGSCI (goldengate) 10> info all


=====================================================================================

GETDELETES | IGNOREDELETES

Valid For

Extract and Replicat

Description

Use the GETDELETES and IGNOREDELETES parameters to control whether or not Oracle GoldenGate processes DELETE operations. These parameters are table-specific. One parameter remains in effect for all subsequent TABLE or MAP statements, until the other parameter is encountered.

Because you can selectively enable or disable these parameters between MAP statements, you can enable or disable them for different threads of a coordinated Replicat. Specify the GETDELETES threads in one set of MAP statements, and specify the IGNOREDELETES threads in a different set of MAPstatements.

Default

GETDELETES

Syntax

GETDELETES | IGNOREDELETES

Example

This example shows how you can apply GETDELETES and IGNOREDELETES selectively to different MAP statements, each of which represents a different thread of a coordinated Replicat.

GETDELETES
MAP sales.cust, TARGET sales.cust, THREAD (1);
MAP sales.ord, TARGET sales.ord, THREAD (2);
IGNOREDELETES
MAP sales.loc, TARGET sales.loc, THREAD (3);