Page Comparison

• YES (default)
• NO

Pass values to APPLY SQL as-is instead of converting them to strings and using to_number/to_date on the result. Value YES improves APPLY speed, value NO can lead to value conversions if the source value is invalid. Applies for OCI only and currently for DATE/NUMBER only. This applies to number values with excessive decimal places and completely invalid date values (such as 0000-00-00 00:00:00). If the source has invalid dates, then set to YES.

• NO (default)
• YES

If set to YES, then APPLY will postponing the last LCR or SQL until the next SQL for the same object is found. This can sometimes help with locking issues or "APPLY hung" issues. This can also assist if there are killed sessions on the source database and the APPLY is waiting on the detection of the killed process to rollback (or commit).

By setting to YES it means that APPLY is always one SQL behind. This means APPLY always keeps one SQL in each open transaction unapplied. It processes the changes it gets from MINE, but stops short of the last one available so far.

As soon as APPLY receives the commit, it applies even the last SQL. So there is never any data loss, although it can be noticed that APPLY lags behind MINE until the commit arrives. But this is probably most visible for manual test cases (like insert 10.000 rows and see that 9.999 has been applied) because in production systems there is always some activity from the source (and with commits), so this situation is rarely seen.

Setting _APPLY_POSTPONE_LAST_LCR = Yes can help if the following message is seen in Apply log:

ERR-3112: Apply waiting on lock on DBVREP user. This is either an internal deadlock, multiple running appliers using the same data, or someone manually changing data using this account.

Adjusts the behaviour of adding supplemental log to the database during the setup.

• AUTO (default): 10/11g checks if PK suplog exists and does not run the DDL if it does
• NO: ignore all requests for suplog
• YES: skip the check

• NO (default)
• YES

Set to YES to turn on extra memory counting for support purposes. It incurs overhead as it adds 16 bytes to each allocation. Negative counts may be possible when the data is read before applier is actually allocated.

• NO (default)
• YES

Set to YES to automatically dump information into the trace file on each applier(=transaction) close. Negative counts maybe possible when the data is read before applier is actually allocated.

Set this to NO to turn off the housekeeping of the PLOG files.

• YES (default)
• NO

Example to stop the automatic removal of PLOG files on APPLY:

set APPLY._DELETE_OBSOLETE_PLOGS NO

Set this to NO to turn off the housekeeping of the redo log files transferred from the Fetcher process to the mine_stage directory on the MINE server.

• YES (default)
• NO

_DELETE_OBSOLETE_DEBUG

• NO (default)
• YES

Turns on debugging for housekeeping of PLOG and redo logs. Extra information will appear in the MINE and or APPLY log files which indicate why PLOGS or redo logs have been deleted or not.

Example of debugging information is:

2013/11/28 10:16:43 INFO> Redolog file /home/oracle/d112F/mine_stage/o1_mf_1_45897_99dph3dl_.arc eligible (1) for deletion; size 0<524288000, age 2532<3600
2013/11/28 10:16:43 INFO> Redolog file /home/oracle/d112F/mine_stage/o1_mf_1_45897_99dph3dl_.arc eligible (2) for deletion; size 0<524288000, age 2532<3600
2013/11/28 10:16:43 INFO> Redolog file /home/oracle/d112F/mine_stage/o1_mf_1_45898_99dph6gh_.arc eligible (1) for deletion; size 0<524288000, age 2531<3600
2013/11/28 10:16:43 INFO> Redolog file /home/oracle/d112F/mine_stage/o1_mf_1_45898_99dph6gh_.arc eligible (2) for deletion; size 0<524288000, age 2531<3600

Skip replicating records being inserted by datapump with jobname beginning with DP_ddcname

• YES (default)
• NO

The program name must begin with ORACLE or oracle and contain DW or udi.

Enables or disables processing of auditing information. This information is used by CDC/Audit function or by querying the DBRSAPPLY_PKG package on the target database (e.g. in triggers).

This information includes source sid, serial#, transaction id, os user, os machine, login name.

• YES: (default) enables this information
• NO: disables this information

Setting this to NO can improve the performance of the MINE process.

Changing this requires a restart of the MINE process

Specify if both online redo logs and archive logs should be use or archive log only (archivelogs only) files exclusively.

• FOREVER (default, use both online redo and archive logs)
• ARCHONLY (use only archive logs)

Set this in the *MINE.ddc only.

Changing this requires a restart of the MINE process.

Deprecated in 2.6.0.4. See MINE parameter  REDO_READ_METHOD.

Log errors to the Dbvisit Replicate data dictionary. Values are:

• YES (default)
• NO

• NO (Default)
• YES

Specific for RAC source database. Setting to YES ensures threads are synched in the correct order.

Setting can create MINE gap up to _MINE_FORCE_LOGSWITCH_IDLE_TIME (180s) on an idle database

Debug RAC thread merging.

• NO
• ARCHONLY
• ALL

• 1 Turn on debugging
• 0 Turn off debugging

To set use the following command from the Dbvisit Replicate command console:

dbvrep> engine mine send memory_set _NETWORK_TRAFFIC_DEBUG 1

Enable network traffic debugging. Useful for Dbvisit support when PLOG files are not being transferred consistently from MINE to APPLY.

Turn on the debugging for about 1 hour and then upload the MINE log file to Dbvisit support.

The following messages in the APPLY log are indication of network issues:

INFO> PLOG 699697 not yet available. 
INFO> Contacting mine to switch logs. 
WARN> WARN-4502: Timeout waiting for incoming data (timeout 300s) - get command.

_SUBPROFILER

In some cases, sub profiling can also be enabled to obtain finer grained profiling information.

Profiling needs to be enabled before sub profiling can be turned on. Please see Dbvisit Replicate Profile Performance Statistics

To turn on sub profiling:

_SUBPROFILER=YES

How long to wait for connection until timeout.

Default is 60 seconds.

If the following message is seen in the APPLY log:

WARN-4502: Timeout waiting for incoming data (timeout 60s) - get command.

Then increase this to 300 seconds.

Requires MINE and APPLY process restart: Yes

How long to wait for receive until timeout.

Default is 60 seconds.

If the following message is seen in the APPLY log:

WARN-4502: Timeout waiting for incoming data (timeout 60s) - get command.

Then increase this to 300 seconds.

Requires MINE and APPLY process restart: Yes

How long to receive confirmation of send until timeout.

Default is 60 seconds.

If the following message is seen in the APPLY log:

WARN-4502: Timeout waiting for incoming data (timeout 60s) - get command.

Then increase this to 300 seconds.

Requires MINE and APPLY process restart: Yes

• YES (default)
• NO

Determines if multiple Apply processes should be run to apply the changes. Yes, means that there are multiple Apply process and that changes are being applied in parallel. Setting to NO, means there is only one Apply process and the changes will be applied serially.

For more explanation, please see Apply processes overview

• YES
• NO (default)

Internal use only.

Setting to YES, adds extra logging information into the trc files. The extra information containing rollbacks and safepoints in querymode. For example what was really applied, what was skipped, what was rolled back and replayed.