SEND REPLICAT

Use SEND REPLICAT to communicate with a starting or running Replicat process. The request is processed as soon as Replicat is ready to accept commands from users.

Syntax

SEND REPLICAT group_name[threadID],
{
CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEPOOL n} |
FORCESTOP |
GETLAG |
HANDLECOLLISIONS | NOHANDLECOLLISIONS [table_spec] |
INTEGRATEDPARAMS(parameter_specification) |
REPORT [HANDLECOLLISIONS [table_spec]] |
RESUME |
STATUS |
STOP |
TRACE[2] [DDLINCLUDE | DDL[ONLY]] file_name |
TRACE[2] OFF |
TRACE OFF file_name |
TRACEINIT |
THREADS (threadID[, threadID][, ...][, thread_range[, thread_range][, ...])
}
group_name[threadID]

The name of the Replicat group or the name of a specific thread of a coordinated Replicat, for example fin003. If the command is issued for a specific thread, then an option that is used applies only to that thread. As an alternative, you can issue SEND REPLICAT with the THREADS option instead of including threadID with the group name. If Replicat is not running, an error is returned.

CACHEMGR {CACHESTATS | CACHEQUEUES | CACHEPOOL n}

Returns statistics about the Oracle GoldenGate memory cache manager. CACHEMGR should only be used as explicitly directed by Oracle Support.

CACHESTATS

Returns statistics for virtual memory usage and file caching.

CACHEQUEUES

Returns statistics for the free queues only.

CACHEPOOL n

Returns statistics for the specified object pool only.

FORCESTOP

Forces Replicat to stop, bypassing any notifications. This command will roll back any active transaction and stop the process immediately. This command applies to Replicat as a whole and cannot be used for a specific Replicat thread.

GETLAG

Shows a true lag time between Replicat and the trail. Lag time is the difference, in seconds, between the time that the last record was processed by Replicat and the timestamp of the record in the trail. The results are the same as LAG REPLICAT.

HANDLECOLLISIONS | NOHANDLECOLLISIONS [table_spec]

Control HANDLECOLLISIONS behavior. Instead of using this option, you can specify the HANDLECOLLISIONS or NOHANDLECOLLISIONS parameter in the Replicat parameter file. See "HANDLECOLLISIONS | NOHANDLECOLLISIONS" for more information about HANDLECOLLISIONS. This command can be sent directly to an individual thread by means of SEND REPLICAT group_name[threadID] or you can use the THREADS option to send the command through the coordinator thread to affect multiple threads.

HANDLECOLLISIONS

Use HANDLECOLLISIONS to enable automatic error handling when performing initial data loads while the source database is active. Make certain to disable HANDLECOLLISIONS, either by issuing SEND REPLICAT with the NOHANDLECOLLISIONS option or by removing the parameter from the parameter file, after the initial load is complete and online data changes have been applied to the target tables.

Note:

The message returned by SEND REPLICAT with HANDLECOLLISIONS, when issued for a specific Replicat thread, shows that the command set HANDLECOLLISIONS for all MAP statements, not only the one handled by the specified thread. This is a known issue. The command actually affects only the MAP statement that includes the specified thread.
NOHANDLECOLLISIONS

Turns off the HANDLECOLLISIONS parameter but does not remove it from the parameter file. To avoid enabling HANDLECOLLISIONS the next time Replicat starts, remove it from the parameter file.

table_spec

table_spec restricts HANDLECOLLISIONS or NOHANDLECOLLISIONSto a specific target table or a group of target tables specified with a standard wildcard (*).

INTEGRATEDPARAMS(parameter_specification)

(Oracle) Supports an integrated Replicat. Sends a parameter specification to the database inbound server while Replicat is running in integrated mode. Only one parameter specification can be send at a time with this command. To send multiple parameter changes, issue multiple SEND REPLICAT commands as in the following example.

SEND REPLICAT myrep INTEGRATEDPARAMS ( parallelism 4 )SEND REPLICAT myrep INTEGRATEDPARAMS ( max_sga_size 250)

To preserve the continuity of processing, the parameter change is made at a transaction boundary. For a list of supported inbound server parameters, see Installing and Configuring Oracle GoldenGate for Oracle Database.

REPORT [HANDLECOLLISIONS [table_spec]]

Generates an interim statistical report to the Extract report file. The statistics that are displayed depend upon the configuration of the STATOPTIONS parameter when used with the RESETREPORTSTATS | NORESETREPORTSTATS option. See "STATOPTIONS".

HANDLECOLLISIONS

Shows tables for which HANDLECOLLISIONS has been enabled.

table spec

Restricts the output to a specific target table or a group of target tables specified with a standard wildcard (*).

RESUME

Resumes (makes active) a process that was suspended by an EVENTACTIONS SUSPEND event. The process resumes normal processing from the point at which it was suspended.

STATUS

Returns the current location within the trail and information regarding the current transaction. Fields output are:

  • Processing status (per thread, if Replicat is coordinated)

  • Position in the trail file (per thread, if Replicat is coordinated)

  • Trail sequence number (per thread, if Replicat is coordinated)

  • RBA in trail

  • Trail name

Possible processing status messages are:

  • Delaying – waiting for more data

  • Suspended – waiting to be resumed

  • Waiting on deferred apply – delaying processing based on the DEFERAPPLYINTERVAL parameter.

  • Processing data – processing data

  • Skipping current transaction – START REPLICAT with SKIPTRANSACTION was used.

  • Searching for START ATCSN csn – START REPLICAT with ATCSN was used.

  • Searching for START AFTERCSN csn – START REPLICAT with AFTERCSN was used.

  • Performing transaction timeout recovery – Aborting current incomplete transaction and repositioning to start new one (see the TRANSACTIONTIMEOUT parameter).

  • Waiting for data at logical EOF after transaction timeout recovery – Waiting to receive remainder of incomplete source transaction after a TRANSACTIONTIMEOUT termination.

  • At EOF (end of file) – no more records to process

Possible thread status messages when THREADS is used or the command is issued for a specific thread are:

  • Waiting for consensus stop point: This indicates that the threads are attempting to synchronize for a barrier transaction.

  • Waiting for Watermark: Indicates that all threads are attempting to stop at the same transaction boundary in the trail, known as the global watermark.

  • Waiting on all threads to start up: Indicates that the thread is waiting for all of the threads to start after a successful barrier transaction or a Replicat startup.

Possible coordinator thread status messages are:

  • Waiting for all threads to register: Indicates that the MAP statements are all being parsed to determine the thread IDs that are specified in them.

  • Processing data: Indicates that data is being processed normally.

  • Suspended, waiting to be resumed: Indicates that a SEND REPLICAT command with a SUSPEND request was sent to Replicat.

  • At EOF: Indicates that there is no more data in the trail to process.

  • Waiting to register MAP statistics: Indicates that Replicat is collecting processing statistics to send to the report file.

STOP

Stops Replicat gracefully. This command applies to Replicat as a whole and cannot be used for a specific Replicat thread.

THREADS (threadID[, threadID][, ...][, thread_range[, thread_range][, ...])

Issues the command only for the specified thread or threads of a coordinated Replicat. You can use this option or you can use groupname with threadID. Without either of those options, the command applies to all active threads.

threadID[, threadID][, ...]

Specifies a thread ID or a comma-delimited list of threads in the format of threadID, threadID, threadID.

thread_range[, thread_range][, ...]

Specifies a range of threads in the form of threadIDlow-threadIDhigh or a comma-delimted list of ranges in the format of threadIDlow-threadIDhigh, threadIDlow-threadIDhigh.

A combination of these formats is permitted, such as threadID, threadID, threadIDlow-threadIDhigh.

TRACE[2] [DDLINCLUDE | DDL[ONLY]] file_name

Turns tracing on and off. Tracing captures information to the specified file to reveal processing bottlenecks. Tracing also can be enabled by means of the Replicat parameters TRACE and TRACE2.

If the Replicat is in coordinated mode and TRACE is used with a THREADS list or range, a trace file is created for each currently active thread. Each file name is appended with its associated thread ID. This method of identifying trace files by thread ID does not apply when SEND REPLICAT is issued by groupname with threadID (as in SEND REPLICAT fin003 TRACE...) or when only one thread is specified with THREADS.

Contact Oracle Support for assistance if the trace reveals significant processing bottlenecks.

TRACE

Captures step-by-step processing information.

TRACE2

Identifies code segments rather than specific steps.

DDLINCLUDE | DDLONLY

(Replicat only) Enables DDL tracing and specifies how DDL tracing is included in the trace report.

  • DDLINCLUDE includes DDL tracing in addition to regular tracing of transactional data processing.

  • DDL[ONLY] excludes the tracing of transactional data processing and only traces DDL. This option can be abbreviated to DDL.

file_name

file_name specifies the relative or fully qualified name of a file to which Oracle GoldenGate logs the trace information. If a trace is already in progress, the existing trace file is closed and the trace resumes to the file specified with file_name. For example:

SEND REPLICAT group_name TRACE file_name DDLINCLUDE

If no other options will follow the file name, the FILE keyword can be omitted, for example:

SEND REPLICAT group_name TRACE DDLINCLUDE file_name
TRACE[2] OFF

Turns off tracing.

TRACE OFF file_name

Turns tracing off only for the specified trace file. This option supports the EVENTACTIONS feature, where there can be multiple trace files due to multiple EVENTACTIONS statements.

TRACEINIT

Resets tracing statistics back to 0 and then starts accumulating statistics again. Use this option to track the current behavior of processing, as opposed to historical.

Examples

Example 1   
SEND REPLICAT finance, HANDLECOLLISIONS
Example 2   
SEND REPLICAT finance, REPORT HANDLECOLLISIONS fin_*
Example 3   
SEND REPLICAT finance, GETLAG
Example 4   
SEND REPLICAT finance, INTEGRATEDPARAMS(parallelism 10)
Example 5   

The following gets lag for thread 3 of a coordinated Replicat.

SEND REPLICAT fin003, GETLAG
Example 6   

The following enables tracing for only thread 1 of a coordinated Replicat. In this case, because only one thread is being traced, the trace file will not have a threadID extension. The file name is trace.trc.

SEND REPLICAT fin, TRACE THREADS(1) FILE ./dirrpt/trace.trc
Example 7   

The following enables tracing for threads 1,2, and 3 of a coordinated Replicat. Assuming all threads are active, the tracing produces files trace001, trace002, and trace003.

SEND REPLICAT fin TRACE THREADS(1-3) FILE ./dirrpt/trace.trc
Example 8   

The following enables tracing only for thread 1 of a coordinated Replicat. Because the command was issued directly for thread 1 without the use of a THREAD clause, the trace file is named trace (without a thread ID suffix).

SEND REPLICAT fin001 TRACE FILE ./dirrpt/trace.trc